OpenAI Agents APIとは？Codex・Responses API・Agents SDKとの違い

先に結論：Agents APIは、Codexのmanaged harnessをアプリから使う公開ベータ

OpenAI Agents APIは、Codexを支えるagent harnessをOpenAI管理のAPIとして利用し、アプリから長時間動くagent sessionを開始・観察・継続するための仕組みです。OpenAIはsession、orchestration、context compaction、recoveryを管理し、開発者側はagentに渡す指示やtoolsを設定し、どのexecution environmentで動かすかを選びます。OpenAIは2026年9月10日にpublic betaとして発表しました。2026年9月25日時点で、ここでは一般提供済みとは扱いません。

Responses API・Agents SDK・Codexとの違い

名前に「Agents」が入るAPIやSDKは、モデル、tool、実行ループ、sessionをそれぞれ違う層で扱います。最初に比較するのはベンチマークではなく、どこまで自分のアプリで制御し、どの運用を管理基盤へ任せるかです。

OpenAIのAgents SDK Docsは、新しいagent applicationではmanaged Codex harness上で動くAgents APIを推奨しています。一方で、SDKとAPIは同じ製品の別名ではありません。Responses APIを使ってアプリ側に実行ループを残す方法も引き続き選べます。Agents APIは、モデルを一度呼び出す方法よりも、session・実行環境・進捗イベントをどう運用するかまでまとめて選ぶときに検討します。

Agent・Environment・Session・Events/itemsを分けて設計する

基本の流れは、sessionを作成し、taskを送信し、streamingまたはwebhookで進捗を受け、必要なら同じsessionへ追加指示を送る形です。function toolの呼び出しにはアプリ側handlerが必要です。handlerが結果を返さない場合、agentが結果待ちになることがあります。webhookやself-hosted environmentの接続・停止処理も、アプリ運用の一部として設計します。

OpenAI-hostedとself-hostedは責任の置き場所で選ぶ

self-hostedは、OpenAIが自前環境を管理してくれるという意味ではありません。アプリ側でcomputeを準備し、executorをsessionへ接続し、処理終了を確認して停止する責任が残ります。逆にOpenAI-hostedを選んでも、実行中のagentへ渡すtool、network、dataの範囲を自動で安全に絞ってくれるわけではありません。

料金はtoken・tool・sandboxに分けて見積もる

OpenAIのAgents API発表はAPI自体に追加料金はないと案内しています。ただし利用が無料という意味ではありません。現行Docsでは、選んだmodelのtoken料金に加え、OpenAI toolsは各toolの通常料金、OpenAI-hosted sandboxはcontainer料金の対象です。self-hostedではcomputeやproxyなど自分側の運用費も加わります。

• 1回のtaskで使うmodel、input/output token、tool呼び出し回数を記録する
• 再開・追加指示・subagentによる作業を含むsession全体で予算を測る
• OpenAI-hosted sandboxのcontainer料金をtoken料金と別に確認する
• beta中は固定の価格表だけで判断せず、利用直前にAPI料金Docsと利用状況を照合する

データ所在地と保持条件は実行環境とは別に確認する

Agents APIのmanaged session stateはAPI側で保持されます。現行のAgents API Docsでは、data residencyは米国のみで、Zero Data Retention（ZDR）には対応していません。self-hosted environmentを選ぶとcommandやfileを動かすcomputeは自分の環境になりますが、OpenAI管理のharnessとsessionを使う点は変わらず、ZDR対象にもなりません。

• 米国以外のdata residencyやZDRが必須なら、現行Agents APIを適合済みと判断せず、送信する前に組織のデータ要件と対象projectのData Controlsを確認する
• session stateや公開artifactは不要になった時点で削除できるが、その削除機能をZDRの代わりとして扱わない
• self-hostedかどうかは実行computeの管理場所を選ぶ設定として扱い、API側のretention・residency条件と分けて記録する

最初に決めるのはpromptよりcredentialとnetwork

OpenAIのsandbox security Docsは、agentが生成したcodeは実行環境にあるfile、credential、networkへアクセスできると説明しています。sandboxという名前だけで、内部の秘密情報や外向き通信まで無害化されるとは考えず、専用環境、workloadごとの分離、許可先だけのoutbound networkを先に決めます。

• アプリ用API keyをagent environmentへ置かない。session管理用APIには必要なscopeだけを付ける
• 環境接続用keyとアプリ用keyを分け、environment keyもagent-generated codeから読める前提で扱う
• 長期credentialはagentへ直接渡さず、OpenAI-hostedならVault、self-hostedなら信頼できるproxyやserverを介して接続する
• MCP serverごとにconnection origin、認証方法、allowed_toolsを確認する。MCP toolを登録しただけでscopeや承認が適切になるわけではない
• 外向き通信は必要なendpointに絞り、session結果・tool output・logsに秘密値が残らないか確認する

特にMCPでは、環境内executorから接続するserverと、OpenAI側serviceから接続するremote serverでnetworkの出所が異なります。接続先のallowlistとcredentialの渡し方は、MCP serverの置き場所ごとに確認してください。承認画面やinstructionsは、最小権限、credential分離、network制限の代わりにはなりません。

個人開発で試すときの判断順

• ユーザーが応答を待つ通常の1回処理なら、まずResponses APIや既存のSDKで足りるか確認する
• 状態をまたいで長く動き、進捗監視・steering・session再開が必要ならAgents APIを候補にする
• agent runtimeやproviderを自分で細かく制御したいならAgents SDKやResponses APIを比較する
• 人が自分のrepositoryを操作する用途なら、Agents APIをCodex app/CLIの代替と決めつけず、利用面とenvironmentを分ける
• 最初の実験はread-onlyまたは使い捨てsandboxのtaskにし、出力、tool call、停止条件、実測費用を記録する