OpenAI Agents APIの登場により、生成AIのAPIは、質問に答えるだけの仕組みから、複数のツールを使って仕事を進める基盤へと変わりつつあります。CRM、在庫管理システム、申請システム、監視システムなどと接続すれば、情報の収集から処理の実行までを一つの依頼として扱えます。ただし、活用するには、業務APIやMCPを通じて各システムと接続できるようにし、権限管理、監査、データ管理の仕組みを整えなければなりません。
【関連記事】GPT-Live-1がAPIで提供開始！ボイスボット開発と無人コールセンター構築への影響は？
Agents APIとは
Agents APIの特徴は、文章生成の性能ではなく、AIが行う一連の作業を管理できる点にあります。モデルへの指示と回答の受け取りに加え、エージェントが外部システムから情報を取得し、必要なツールを選び、途中経過を保持しながら処理を続けられます。
Agents APIは、スケジューラ、監視システム、CRM、社内チャットなどから呼び出して利用します。利用者から依頼が届いたときや業務上のイベントが発生したときに、これらのシステムがAgents APIを呼び出し、処理の完了後に結果を受け取ります。
パブリックベータの公開
OpenAIは2026年9月10日、Agents APIをパブリックベータとして公開しました。Agents APIでは、OpenAIが管理するCodexの実行基盤や長期間保持できるセッションを利用できます。進捗をストリーミングで受け取り、MCPや独自ツールに接続し、OpenAIまたは利用企業が用意するサンドボックスも一つのAPIから利用できます。
OpenAIはAgents APIの公開以前から、エージェント開発に取り組んでいました。2025年3月11日には、モデルがツールを利用できるResponses APIと、エージェントの処理を組み立てるAgents SDKが公開されました。Agents APIは、Responses APIやAgents SDKを置き換えるものではありません。Agents APIでは、セッションの進行、コンテキストの圧縮、障害からの復旧を含め、長時間の作業に必要な実行基盤もOpenAIが管理します。
今回の発表により、OpenAIがAPIで提供する機能は、回答の生成だけでなく、作業状態を保ちながら成果物を完成させるための実行基盤にまで広がりました。ただし、現時点ではパブリックベータです。本番業務への導入を検討する場合は、仕様変更の可能性や利用条件を確認し、まずは対象業務を限定して検証しましょう。
回答単位からセッション単位へ
Responses APIでも、モデルにFunctionを呼び出させたり、バックグラウンドで処理を続けたりできます。ただし、複数のツールを使う順序、会話や作業状態の保存、失敗した処理の再開などを一つの仕事として管理するには、アプリケーションで、ツールの実行順や作業状態をまとめて扱う仕組みを用意しなければなりませんでした。
Agents APIでは、OpenAIが管理するCodexの実行基盤がモデルとツールのやり取りを進めます。エージェントごとに、使用するモデル、指示、利用できるツールを設定し、必要に応じてコードやファイルを扱える実行環境も設定します。アプリケーションはセッションを作成し、具体的な依頼内容を送信します。
セッションには、エージェントの設定、会話履歴、ツールの呼び出し履歴、作業の状態が保持されます。 セッション内の処理は、1回ごとにターンとして管理されます。待機中のセッションへ新しい指示を送ると新しいターンが始まり、処理中に指示を送れば、進行中の作業の内容を変更できます。途中まで進めた調査に条件を追加したり、作成したファイルを修正させたりする場合でも、最初から情報を渡し直す必要はありません。
Agents API、Agents SDK、Responses APIは、それぞれ役割が異なります。Agents APIは、実行基盤とセッションの管理をOpenAIに任せて、長時間の作業を行う場合に向いています。Agents SDKは、アプリケーションでエージェントの処理手順や引き継ぎを細かく制御する場合に使います。Responses APIは、モデルを直接呼び出す場合や、企業が独自の実行基盤を構築する場合に適しています。
自動実行の起点は業務システム
Agents APIは、指定した時刻の到来や業務上のイベントを検知して、自ら処理を始める仕組みではありません。定時処理ならスケジューラ、障害対応なら監視システム、問い合わせ対応ならCRMが起点になります。これらのシステムがAgents APIへ依頼を送ると、エージェントが必要な情報を調べ、使用するツールを選びます。
例えば、監視システムが異常を検知したとき、Agents APIへ機器名、発生時刻、アラートの内容を送ります。エージェントは監視データ、変更履歴、過去の障害記録を調べ、原因の候補と対応案をまとめます。エージェントに必要な権限があれば、診断コマンドの実行や担当者への通知まで行えます。
CRMに問い合わせが登録された場合は、顧客情報、契約内容、過去の応対履歴、在庫や納期を複数のシステムから取得し、回答案を作成できます。スケジューラから定時にAgents APIを呼び出せば、前日の売上や問い合わせを集計し、報告書を作成して指定の保管先に保存する一連の処理も自動化できます。
これらの処理は非同期で進みます。業務システムは、イベントストリームを通じて進捗を受け取るか、Webhookによる状態変更の通知を待ちます。通信が切れた場合も、再接続後にセッションの状態と処理結果を取得し、作業を続けられます。画面を開いたまま応答を待つ必要がないため、数分から数十分に及ぶ処理も業務フローに組み込みやすくなります。
依頼を完了まで追跡する
質問応答型のAPIでは、依頼に対して適切な回答が返ったかどうかが主な評価対象でした。業務を進めるAPIでは、要求された情報を取得できたか、外部システムへの登録が成功したか、失敗時に処理を止められたかまで確認しなければなりません。
Agents APIは、ターンの完了、失敗、キャンセルをイベントとして通知します。セッションには、モデルの応答だけでなく、FunctionやMCPツールの呼び出し履歴も保存されます。呼び出し元のシステムは、受け取ったイベントの内容を業務上の完了条件と照合できます。
OpenAIは利用例として、インシデント対応、社内チャットを通じた調査依頼、データ分析、GitHubに登録された問題の調査、文書レビューを示しています。いずれも、質問に答えるだけでなく、複数の情報源とツールを使い、調査結果や文書などが完成するまで処理を続けます。
Agents APIを使えば、業務システムからAIへ、一連の仕事を依頼できるようになります。 ただし、エージェントが利用できる業務APIやツールが用意されていなければ、AIに任せられる業務は情報の整理や文章の作成に限られます。
MCPで自動化の範囲が決まる
Agents APIを導入しただけでは、CRMの顧客情報を検索したり、在庫を照会したり、申請内容を登録したりすることはできません。エージェントが業務を進めるには、各システムの機能をAPIから呼び出せるようにする必要があります。
自社のプログラムを呼び出すFunctionと、ツールを共通の形式で公開するMCPは、エージェントと業務システムを接続する役割を担います。どちらを使う場合でも、業務システム側のAPI仕様が曖昧だと、エージェントは安定して処理できません。
Functionで自社業務を呼び出せるようにする
Functionを利用するには、関数名、処理内容、引数をあらかじめ定義します。エージェントがFunctionの実行を必要と判断すると、Agents APIからアプリケーションへ実行要求が届きます。アプリケーションが処理結果を返すと、エージェントはその結果を読み、次の処理へ進みます。
例えば、顧客番号から契約情報を取得するFunction、商品番号から在庫と納期を取得するFunction、確認を終えた回答をCRMへ登録するFunctionを用意できます。エージェントは依頼の内容に応じて必要なFunctionを選び、取得した情報を組み合わせます。
Functionを登録しても、それだけでAgents APIから自社のプログラムが実行されるわけではありません。実際の処理は、アプリケーションサーバーやワーカー上のプログラムが担います。このプログラムが実行要求を受け取り、呼び出し元の認証情報と入力値を確認して、処理結果をAgents APIへ返します。
この仕組みなら、既存システムの内部構造や認証情報をエージェントへ直接渡す必要はありません。エージェントに許可する操作をFunctionに限定し、権限の確認と実際の処理は、既存の業務ロジックに任せられます。
MCPサーバーとは
MCPサーバーは、利用できるツールの名前、説明、引数を公開し、呼び出された処理を実行します。Agents APIはMCPサーバーからツールの定義を取得し、仕事に必要な操作を選びます。Agents APIからMCPサーバーを直接呼び出せるため、アプリケーションが個々のツール呼び出しを仲介する必要はありません。
インターネット上に公開されたMCPサーバーには、OpenAIのサービスから直接接続できます。社内ネットワークにあるMCPサーバーや、実行環境にインストールしたツールを使う場合は、利用企業が管理する実行環境を経由します。社内システムを外部へ公開できない場合も、この構成なら接続経路を自社で管理できます。
MCPは業務APIの機能そのものを提供するのではなく、エージェントから共通の方法で呼び出せるようにする仕組みです。 顧客検索、契約照会、在庫確認、予定の登録、申請、通知などの処理は、業務システム側で実装します。MCPサーバーは、それらの処理をツールとしてエージェントへ提供します。
MCPサーバーが公開するすべてのツールを、エージェントから利用できるようにする必要はありません。Agents APIでは、エージェントが利用できるツールを制限できます。問い合わせ対応では情報を参照するツールだけを許可し、契約変更や削除を行うツールは公開しないといった設定が可能です。
エージェントが扱いやすいAPI設計
既存の業務APIをそのまま公開しても、安定した自動実行につながるとは限りません。一つのAPIで検索、更新、削除を引数によって切り替える設計では、エージェントが操作を取り違えるおそれが高まります。参照と更新を分け、エージェントが関数名と説明から操作内容を判断できる設計が適しています。
業務APIを整備する際は、次の点を明確にします。
- 操作の範囲：検索、登録、更新、削除を分け、実行できる対象を限定する
- 入力値：必須項目、形式、選択肢、上限値を定義し、実行前に検証する
- 処理結果：成功、失敗、確認待ち、再実行の可否を判別できる形式で返す
- 完了条件：登録番号や更新後の状態を返し、処理が完了したか判定できるようにする
- 重複実行の防止：同じ依頼を再送しても、二重登録や二重発注が起きないようにする
- 承認の要否：金額、対象、操作内容に応じて、業務システムで承認を求める
Functionを実行するプログラムでは、呼び出しごとにセッションID、ターンID、呼び出しID、実行結果を保存します。通信断などによって同じ呼び出しが再送されても、保存済みの結果を返せます。処理の成否を確認できない場合は、外部システムの状態を確認してから再実行しなければなりません。
自動化の範囲を一度に広げる必要はありません。まずは情報の参照と整理から始め、登録内容の下書き、承認後の更新、条件を限定した自動更新へと段階的に広げていきましょう。処理の完了後は、結果を呼び出し元のCRMや申請システムへ書き戻し、利用者が別の画面を開かなくても確認できるようにします。
エージェントが実行できる範囲は、業務APIやMCPで決まります。 モデルの性能だけでなく、業務を安全に実行できる単位でAPIを設計できるかが、Agents APIの導入効果を左右します。
システム担当者が設計すべきこと
Agents APIを業務システムへ接続すると、エージェントが判断や操作を誤った場合の影響は、不正確な回答にとどまりません。顧客情報の誤登録、不要な通知、重複発注などが発生する可能性があります。
システム担当者は、エージェントへの指示だけでなく、与える権限、接続先、認証情報、監査方法、データの保存範囲まで設計します。
権限と認証をエージェントから分離する
エージェントへ一律の管理者権限を与えると、一度の誤った判断が複数のシステムに影響を及ぼします。業務ごとに利用できるツールを限定し、参照、登録、更新、削除の権限を分けます。利用者の依頼を受けて起動する場合は、エージェントが依頼者の権限を超えて処理しないようにします。
重要な更新処理は、エージェントだけで確定させず、承認者が内容を確認してから実行します。契約変更、送金、発注、削除などは、実行内容を承認者へ示し、承認結果を受け取った後にFunctionを実行する構成が適しています。Agents APIとは別に承認処理を設ければ、既存の職務分掌や決裁規程も維持できます。
認証情報の扱いにも注意が必要です。エージェントが生成したコードは、実行環境内のファイルや認証情報を参照し、許可されたネットワークへ接続できます。長期間有効な認証情報を実行環境へ直接置くと、生成されたコードに認証情報を読み取られたり、その内容がログに残ったりするおそれがあります。
Agents APIでは、MCPサーバーへ接続する認証情報をVaultに保存できます。ただし、実行環境内のプログラムから第三者サービスへ接続する場合は、認証情報を環境の外に置き、許可された宛先への通信にだけ認証情報を付与する中継サーバーの利用も検討しましょう。認証情報ごとに接続先と操作範囲を限定し、定期的に更新できる仕組みを用意します。
ネットワーク通信も、業務に必要な範囲へ制限します。サンドボックスからの外部通信を許可された宛先に絞り、不要なインターネット通信は遮断します。利用者間や業務間でデータを共有できない場合は、実行環境とOpenAIのプロジェクトを分けます。
処理の成功と業務の完了を分けて監視する
Agents APIは、セッション、ターン、モデルの応答、ツールの呼び出し、サブエージェントの処理を記録します。システム担当者は、イベントやトレースを使って、どの指示を受け、どのツールを呼び出し、どの結果が返ったかを確認できます。
ただし、セッションが待機状態になっても、直前の処理が成功したとは限りません。ターンが完了していても、一部のツールがエラーを返し、エージェントが代替の回答を生成している場合があります。ターンの完了だけでなく、顧客情報を取得できたか、申請番号が発行されたか、通知が送信先へ届いたかといった業務上の完了条件も確認しましょう。
Functionを実行するプログラムが結果を返さないまま停止すると、セッションは結果待ちになります。ワーカーが停止した場合や通信が切れた場合に備え、結果待ちになっているFunctionの呼び出しを検索し、処理を再開できるようにします。実行済みのFunctionを再実行しないように、呼び出しIDと外部システムの処理番号を対応づけて保存します。
Webhookの受信処理は、同じ通知が複数回届くことを前提に設計します。同じ完了通知を複数回受けても、後続の登録や通知は一度だけ実行するようにします。失敗、キャンセル、タイムアウトの扱いを定め、再試行する処理と担当者へ引き継ぐ処理を分けます。
トレースには、モデルへの入力と出力、FunctionやMCPの引数と結果、処理時間などが記録されます。これらの記録は障害調査に役立ちますが、機密情報が含まれる可能性もあります。閲覧権限、保存先、保存期間を定め、通常のアプリケーションログと同じ管理基準を適用します。利用量にはルートエージェントだけでなく、サブエージェントや再試行も含まれるため、処理単位で費用を把握する仕組みも求められます。
MCPの接続先と保存されるデータを管理する
MCPサーバーは、データを参照するだけでなく、外部サービスへデータを送ったり、保存されたデータを更新したりできます。信頼できないMCPサーバーへ接続すると、業務データが想定外の場所へ送られたり、ツールの動作が後から変更されたりするおそれがあります。提供元、運用主体、利用規約、保存方針を確認し、利用できるツールを限定しましょう。
外部文書やMCPの応答に、エージェントの動作を変える指示が埋め込まれる場合もあります。プロンプトインジェクションへの対策として、外部から取得した文章をエージェントが命令として扱わないようにし、重要な更新を行う前には、入力内容と実行内容が一致しているかをアプリケーション側でも検証します。
OpenAI APIへ送信したデータは、利用企業が明示的に同意しない限り、モデルの学習や改善には使われません。ただし、学習に使われないからといって、データが保存されないわけではありません。不正利用を監視するため、入力や出力を含むログが原則として最長30日間保存される場合があります。
セッションをはじめ、Agents API上で作成・保存した情報は、利用企業が削除するまで残ります。Agents APIは現時点でZero Data Retentionに対応しておらず、データの保存場所も米国に限られます。サンドボックスを自社で管理しても、Agents API上のセッションの保存条件は変わりません。
MCPサーバーに送ったデータの保存期間や保存場所は、接続先の方針に従います。OpenAI側の設定だけを確認しても、業務全体のデータ管理要件を満たしたとは判断できません。システム担当者は、データの区分、外部送信の可否、保存期間、削除手順、監査ログ、障害時の対応、MCPサーバーの変更管理を接続先ごとに確認して定めます。
システム担当者は、Agents APIと業務システムを接続するだけでなく、エージェントの誤動作にも備えます。 利用できる権限と接続先を限定し、実行した処理を追跡できる仕組みまで整えてから、業務への導入を進めましょう。
まとめ
Agents APIは、企業や開発者が業務システムに組み込んで使うAPIです。一般の利用者が直接操作するものではないため、公開されたからといって、日々の操作がすぐに大きく変わるわけではありません。
CRM、販売管理システム、在庫管理システム、予定表、申請システム、社内文書などを、業務APIやMCPを介してAgents APIと接続すれば、利用者は各システムを個別に開き、検索、転記、登録を繰り返す手間を減らせる可能性があります。一つの依頼を受けたエージェントが、複数のシステムから必要な情報を集め、許可された処理を実行し、結果をまとめて返せるようになるためです。
複数のシステムを横断して業務を進めるには、業務画面にAI機能を追加するだけでは足りません。そのためには、業務APIを用意したうえで、権限管理、承認、監査、データ管理の仕組みを整え、どの業務をどこまで自動化するかを決める必要があります。まずは、完了条件が明確で、処理の影響範囲を限定できる業務を選び、Agents APIの導入を検討してはいかがでしょうか。
参考文献
この記事を書いた人
