AIエージェントの作り方：OpenAI Agents SDKによる実践ガイド

AIエージェントの定義と仕組み：AIエージェント 作り方の基本

AIエージェントとは、作業ループ内で動作するモデルのことです。目標を受け取り、次に何をすべきかを判断し、必要に応じて許可されたツールを実行し、その結果を確認したうえで、処理を継続するか停止するかを決定します。

これは、新人のオペレーターを採用するようなものだと考えてください。指示文（Instructions）は職務記述書です。モデルは判断力を提供します。ツールは、注文システム、カレンダー、ナレッジベース、ブラウザ、ファイルストレージなどへのアクセス権限です。メモリは業務ノートであり、ガードレールや承認フローは上司のチェックに該当します。

これは従来のチャットボットとは根本的に異なります。チャットボットは回答の下書きを作成するだけですが、エージェントは注文の検索、ポリシーとの照合、不足情報の質問、そして担当者への案件引き継ぎまでを実行できます。この「アクションループ」の有無が決定的な違いです。

OpenAIの公式エージェント概要では、エージェントを「計画を立て、ツールを呼び出し、状態を保持し、時には専門エージェント同士で連携するアプリケーション」と定義しています。SDKにおける中心オブジェクトは意図的に小さく設計されており、指示、ツール、ガードレールやハンドオフといったオプションの制御機構を備えたモデルで構成されています。

Agents SDKとResponses APIの使い分け

ツール呼び出しの繰り返し、状態管理、ガードレール、ハンドオフ、承認フローの管理をランタイムに任せたい場合は、Agents SDKを使用します。そのループ自体を自前で記述・制御したい場合は、Responses APIを直接呼び出します。OpenAIは、モデルの直接的な制御にはResponsesアプローチを、会話型やトランザクション型の反復ワークフローにはSDKの利用を推奨しています。

ノーコードツールを使う場合でも、基本設計は同じです。明示的なツール設定、承認ステップ、実行ログ、ループ停止機能がプラットフォームに備わっていることを確認してください。ビジュアルな開発環境であっても、これらの制御機構が不要になるわけではありません。

実用的な最初のエージェントを作る8つの手順

最短で成果を出す方法は、技術を広げる前にタスクの範囲を絞り込むことです。

1. 1文で業務契約（ジョブコントラクト）を定義する

対象ユーザー、トリガー、実行するアクション、完了基準を明記します。「カスタマーサポートを支援する」では範囲が広すぎます。「注文APIを使用して注文状況の問い合わせに回答し、返金や住所変更が関係するものはすべて担当者に引き継ぐ」と定義すれば、実装可能な仕様になります。

同時に、禁止事項も定義してください。これにより、曖昧な自律性が明確な製品仕様へと変わります。

2. その業務にエージェントが必要かを検証する

エージェントの複雑さが正当化されるのは、人間の判断が必要な業務、非構造化テキストや書類の処理、通常のルールベースでは破綻しやすい例外処理が含まれる場合のみです。OpenAIの実践ガイドでも、それらの条件が当てはまらない場合は確定的な（デターミニスティックな）システムの利用を推奨しています。

税計算、決まったフォームのバリデーション、定期的なデータコピーなどは、通常のソフトウェアとして実装すべきです。一方、会話履歴を読み解き、規約を確認し、注文内容を精査して、人間の承認が必要かを判断する返金対応などは、エージェントに適した業務といえます。

3. デモではなく本番業務に合わせたモデルを選ぶ

Agents SDKは現在、低レイテンシワークフロー向けとして、推論負荷（reasoning effort）なし・低冗長度の gpt-5.4-mini をデフォルトに設定しています。モデルガイドでは、より高い判断品質が求められアクセス権がある場合には gpt-5.6-sol の利用を推奨しています。

まずは、用意したテストケースを通過できる低コストな選択肢から始めてください。ツールの不足、指示の曖昧さ、データの不備ではなく、純粋に「判断の質」が原因で失敗する場合にのみモデルのアップグレードを検討します。注文APIが古いステータスを返している場合、モデルを強力にしても問題は解決しません。

4. 読み取り専用ツールを1つだけ与える

最初に実装するツールは、データを変更するものではなく、情報取得（リードオンリー）に限定すべきです。注文照会、規約検索、在庫確認、カレンダーの空き枠取得などは、返金、キャンセル、決済、外部メール送信と比べて評価が容易で、再試行も安全に行えます。

SDKを使用すると、型定義されたPython関数をツールへ変換し、入力スキーマを自動生成できます。また、ホスト型のウェブ検索、ファイル検索、Code Interpreter、MCP、画像生成ツールも利用可能です。ローカル環境でのPC操作、シェル実行、ファイル編集ツールを扱うには、自身で管理できる実行環境が必要です。

以下は、最小限の実装パターンです。

from agents import Agent, Runner, function_tool

@function_tool
def lookup_order(order_id: str) -> str:
    """注文システムから現在の注文ステータスを取得します。"""
    return "注文 123 は梱包済みで、配送業者の集荷待ちです。"

agent = Agent(
    name="Order status agent",
    instructions=(
        "lookup_order を使用して注文状況の質問に回答してください。"
        "注文の変更やキャンセルは絶対に行わず、それ以外は担当者に引き継いでください。"
    ),
    tools=[lookup_order],
)

result = Runner.run_sync(agent, "注文 123 は今どこにありますか？")
print(result.final_output)

Python SDKは pip install openai-agents でインストールし、APIキーは環境変数 OPENAI_API_KEY に設定します。技術スタックに応じて、現在のTypeScript SDKでも全く同じ構造で実装できます。

5. ループを確実に停止させる

Runnerはモデルを呼び出し、要求されたツールを実行し、その結果をモデルに戻すサイクルを繰り返します。ツール呼び出しを伴わない最終出力がモデルから返された時点で処理は終了します。また、ターン数の上限に達した際に MaxTurnsExceeded を発生させて停止させることも可能です。

本番環境のエージェントには、最大ステップ数、タイムアウト、明確な失敗時の処理が不可欠です。「確認できなかったため、担当者に引き継ぎました」という結果は立派な完了基準です。終わりのない再試行は粘り強さではなく、単なるシステム障害です。

6. メモリ戦略を1つに絞る

メモリとは、次のターンに関連するコンテキストを引き継ぐ仕組みです。SDKではクライアント側の履歴をセッションに保持することも、conversation_id や previous_response_id を使ってOpenAI側の管理下で継続処理を行うことも可能です。

1つの会話に対して採用する戦略は1つに限定してください。履歴の重複によるコンテキスト肥大化を防ぐため、SDKでは同一実行内でセッションとサーバー管理ステートの併用を明示的に禁止しています。また、エージェントにどこまでの履歴が必要かを精査することも重要です。サポートエージェントに必要なのは現在の問い合わせ内容であり、顧客の全過去ログではありません。

7. リスクのある境界すべてにチェックを設ける

業務範囲外のリクエストを拒否するには入力ガードレールを使用します。社内データの読み取りや変更を行うカスタム関数にはツールガードレールを適用し、最終回答の検証には出力ガードレールを用います。取り消しができない処理や高コストなアクションの前には、必ず人間の承認ステップを挟みます。

注意すべき点として、入力ガードレールはデフォルトで並列実行されます。これはレイテンシ改善に寄与しますが、チェックが失敗する前にエージェントがトークンを消費したり、ツールの実行を開始したりする可能性があります。副作用を伴うリクエストや機密データを扱う場合は、ブロッキング（同期）モードを使用してください。

より高度な本番設計パターンについては、影響範囲を抑えるガードレール設計ガイドを参照してください。基本原則は極めてシンプルです。費用発生、データ変更、権限を伴うすべてのアクションを、単一の制御可能な境界線を経由させることです。

8. トレースと評価を行い、必要に応じてサンドボックスを追加する

Agents SDKではトレーシングがデフォルトで有効になっています。モデル生成、関数呼び出し、ガードレール、ハンドオフがすべて記録されるため、実行の成否原因を正確に把握できます。ツールを追加する前に、実際の問い合わせと期待される出力結果をまとめたテストデータセットと照らし合わせてトレースを検証してください。

トレースにはモデルや関数の入出力が含まれる場合があるため、必要に応じて機密データの収集を無効化してください。なお、Zero Data Retention（データ非保持）環境ではOpenAIのトレーシング機能は利用できません。

サンドボックスの導入は、ファイル操作、コマンド実行、パッケージインストール、長時間のワークスペース状態保持がどうしても必要な業務に限定してください。OpenAIが2026年4月に実施したSDKアップデートにより、制御された環境、ポータブルなワークスペースマニフェスト、スナップショット機能、および複数のサンドボックスプロバイダーのサポートがネイティブで追加されました。サポートの問い合わせ対応エージェントにコンテナは不要ですが、書類分析やコーディングを行うエージェントには不可欠となるケースが多くあります。

運用コストの目安

SDKやResponses API自体のプラットフォーム追加利用料はありません。支払うのは選択したモデルのトークン費用と、使用したホスト型ツールの費用のみです。

標準的な短いコンテキストでの現行料金は、gpt-5.6-sol が入力100万トークンあたり$5、出力100万トークンあたり$30です。gpt-5.6-terra は$2および$12、gpt-5.6-luna は$0.20および$1.20です。ウェブ検索は1,000回あたり$10に加えて検索コンテンツのトークン代がかかります。Responsesのファイル検索は1,000回あたり$2.50で、ストレージは最初の1GB無料枠以降、1GBあたり日額$0.10です。1GBのホスト型シェルまたはCode Interpreterコンテナは、20分のセッションで$0.03から利用できます。

これらの単価だけでは、業務1件あたりの完了コストは分かりません。それを把握できるのがトレースログです。タスクの成功1件ごとに、モデルのターン数、ツール呼び出し回数、リトライ回数、人間へのエスカレーション件数を測定してください。そのうえで、品質を保てるモデルとツールの予算枠を決定します。

開発価値の高いエージェント業務ベスト7

優れたエージェント業務には、明確な発注者、制約されたワークフロー、そして人間が評価可能な成果物が存在します。

1. カスタマーサポート解決エージェント

ECのサポートチームであれば、承認済みのヘルプ記事と読み取り専用の注文データへのアクセス権をエージェントに付与できます。顧客を特定し、配送状況を確認し、次の手順を案内したうえで、返金や配送先変更のみを担当者に引き継ぎます。この価値は人間の完全な代替ではなく、一次応答の迅速化と引き継ぎメモの精度向上にあります。

2. 根拠重視のリサーチエージェント

経営企画チームは、一連のレポートを管理されたワークスペースに配置し、すべての主張に出典ファイル名を付与した比較資料の作成を指示できます。エージェントは検索、抽出、クロスチェックを行い、構造化されたサマリーを出力します。これにより、アナリストは書類探しから解放され、内容の精査と判断業務に集中できます。

3. 商談事前調査・リード選別エージェント

B2B営業チームでは、エージェントに問い合わせ内容を読み取らせ、承認済みソースから企業情報を付加し、選別基準と照合したうえで商談ブリーフィングを作成させることができます。明確な基準を満たしたリードのみ商談予約を行います。営業担当者が顧客関係に注力できる環境を整え、準備の均一化とCRM入力作業の削減を実現します。

4. バックオフィス受付・仕分けエージェント

不動産管理会社では、修繕依頼メールをエージェント経由で処理し、物件名、部屋番号、トラブル内容、緊急度、希望訪問日時を抽出できます。入居者データと照合してチケットの下書きを作成し、安全に関わる問題は即座にアラートを上げます。再入力の手間と記載漏れのある作業指示書を減らすことができます。

5. 契約書・社内規程の比較検証エージェント

購買部門では、ベンダーの契約書と自社の標準条項を比較し、差異をハイライトして該当ページを明記する処理をエージェントに任せられます。法的効力の最終判断を弁護士に残したまま、確認用資料をまとめることで一次レビューの手間を大幅に短縮できます。

6. 社内ITヘルプデスクエージェント

情報システム部門では、従業員向けエージェントを端末インベントリ、システム稼働状況、公式トラブルシューティングガイドと連携させられます。端末の診断情報を収集し、安全な対処法を提案したうえで、必要な証拠を添付してチケットを作成します。エンジニアが対応を開始する前のやり取りを最小限に抑えられます。

7. 管理されたファイル・コード処理エージェント

財務や開発部門では、サンドボックス内に書類やリポジトリを展開し、制限されたコマンド実行と出力ディレクトリの指定を行うことができます。エージェントはファイルを精査し、分析を実行し、下書きを修正して、レビュー用の成果物を生成します。ここでは、実環境と安全な履歴管理が求められるため、最新のサンドボックス機能が威力を発揮します。

事業化を検討すべき3つのプロダクト案

「AIエージェント」という漠然とした言葉自体は市場になり得ません。しかし、以下の3つの業務には明確な購買需要が存在します。

最も有力：バーティカル型カスタマーサポート解決エージェント

Shopifyストア、不動産管理、訪問サービスなど、特定の業界システムに特化したサポートエージェントを構築します。購入者が対価を払うのは一般的なチャット画面ではなく、実際に解決された問い合わせ件数と精度の高い引き継ぎ処理です。

市場のシグナルは明白です。「AI customer service agent」はGoogleで月間約720回検索されており、明確な商用意図を持ち、クリック単価（CPC）は$264.61に達します。また、AIアシスタントに対しても同等の依頼が月間約69回行われています。Intercomの現行基準では、チャットやメールの解決、定型手順の引き継ぎ、リードの対象外判定の完了1件につき$0.99が設定されています。

最小限の販売可能版（MVP）に必要なのは、1つのチャネル、1つの承認済みナレッジソース、1つの読み取り専用アカウント連携ツール、人間への引き継ぎ機能、そして成果確認ダッシュボードです。参入障壁となる競争優位性は、モデルの呼び出しそのものではなく、業界特化のシステム連携、評価データセット、エスカレーション設計、そして「解決」が本当に顧客満足につながったかの証明にあります。

業務範囲が狭く、購買担当者が明確で、成功基準を数値化できるため、これが最も堅実な機会といえます。極めて高額なCPCは、すでにベンダー各社がこの顧客獲得に向けて激しい競争を繰り広げている証拠でもあります。

特定専門職向けの根拠重視リサーチエージェント

コンプライアンス担当、助成金申請作成者、医療市場アナリスト、デューデリジェンス担当など、特定の専門職向けにリサーチワークスペースを構築します。承認された資料群を検索し、すべての主張に出典を紐付け、相反する情報を比較し、定型フォーマットでレポートを出力します。

「AI powered research assistant」は月間約18,100回、「AI research assistant」は2,400回検索されており、高い購買意欲を示しています。Elicitは現在、Proプランを月額$49、Scaleプランを月額$169で提供しており、構造化されたリサーチ業務に対してユーザーがすでに対価を支払っていることを証明しています。

MVPの構成要素は、1種類の資料タイプ、1つのレポートテンプレート、出典付きエビデンステーブル、レビューキューです。留意すべきは「汎用化の罠」です。汎用的なリサーチツールは大手プラットフォームと正面衝突します。差別化の源泉は、一般的なツールが対応していない専門データソース、特有の業務フロー、あるいは厳格な品質基準の担保にあります。

商談選別およびフォローアップエージェント

製品に関する質問に答え、導入適合性を判定し、CRMにレコードを作成し、商談概要を作成したうえで、条件を満たした場合にのみカレンダーを予約するインバウンド対応エージェントを構築します。まずはインバウンド対応から着手してください。監視体制のないアウトバウンド配信は、ブランド毀損やコンプライアンス違反のリスクが格段に高くなります。

「AI sales agent」は月間約1,000回検索され、商用意図を持ち、CPCは$74.89です。Intercomは現在、リードの選別成功1件あたり$9.99の価格を設定しており、具体的な市場価格の指標となっています。

MVPに必要なのは、Webチャットまたはメール窓口、読み取り専用のCRM連携、明確な選別ルール、カレンダー連携、そして重要な連絡の前に入れる人間による確認ステップです。最大の落とし穴は元データの不備です。不完全なCRMデータに基づいて動作するエージェントは、誤った見込み顧客を極めて自信ありげに商談化してしまいます。

設計時に避けるべき重大な落とし穴

エージェントを導入しても、不確実なソフトウェアが決定論的なシステムに変わるわけではありません。不確実性の所在が、観測と制御が可能なループの中へと移動するだけです。

• 通常のコードで記述できる確定的なロジックにエージェントを使用しないこと。
• 読み取り専用バージョンで実際のケースを十分にテストする前に、書き込み権限を与えないこと。
• 最上位のガードレールだけに頼らないこと。エージェント向けガードレールはすべてのホスト型ツールや組み込みツールを網羅するわけではないため、アプリケーション層やツール層でも権限チェックを行う必要があります。
• メモリシステムを安易に併用しないこと。コンテキストの重複は予期せぬ動作を招き、無駄なトークン消費につながります。
• 最初から複数エージェント構成にしないこと。OpenAIは、マルチエージェントオーケストレーションを検討する前に、ツールを備えた単一エージェントの最適化を徹底することを推奨しています。
• 取り消し不能なアクションの最終承認をモデルに委ねないこと。十分な稼働実績に基づいて承認範囲を徐々に狭められるようになるまでは、高リスクなステップには必ず人間を介在させてください。

セキュリティツールの導入は有効ですが、アーキテクチャ設計そのものが負うべき役割の方がはるかに大きいです。エージェントが具体的にどのようなリスクを生み出すかを把握した段階で、AIセキュリティツールの比較が役立ちます。

率直に言えば、モデルの選定や実装はプロジェクトの中で最も容易な部類に入ります。真に困難で価値のあるプロダクト開発とは、ツール設計、権限管理、データ整備、評価体制の構築、エスカレーションフロー、そして採算性の管理です。これらを綿密に作り込めば、エージェントは真に実用的な戦力となります。これらを軽視すれば、完成度の高そうに見えたデモは、本番環境のアクセス権を持った極めて不安定な問題児へと変わってしまいます。

自社の既存システムや承認ルールに適合した設計・実装をご検討の際は、AI agent development をご覧ください。