OpenAI、Agents APIをパブリックベータで公開 - Codexのハーネスをマネージドで借りる

OpenAIが2026年9月10日、Agents APIをパブリックベータで公開した。セッション管理・コンテキスト圧縮・復旧をOpenAI側が担うマネージドなCodexハーネスで、データ所在地は米国のみ・ZDR非対応という制約も明記されている。

OpenAI agents Codex MCP API developer-tools

OpenAIは2026年9月10日、API changelogでAgents APIのパブリックベータ公開を告知した。Codexのハーネスをマネージドで提供し、セッションのオーケストレーション、コンテキストの圧縮（compaction）、復旧をOpenAI側が引き受ける¹。

エージェントを社内システムに組む側から見ると、論点は「ループとセッション状態を誰が持つか」になる。OpenAIはドキュメント上でエージェントのランタイムとしてAgents API・Agents SDK・Responses APIの3つを並べており、そのうちAgents APIだけが「OpenAIがマネージドなCodexハーネスを実行する」側に置かれている³。

セッションを作って、タスクを投げる

公式ドキュメントはAgents APIを「OpenAIが管理するAPIを通じて、アプリケーションにCodexハーネスへのアクセスを与えるもの」と説明している²。役割分担は明快で、セッション・オーケストレーション・コンテキスト圧縮・復旧をOpenAIが管理し、ツールの提供と実行環境の選択をアプリケーション側が担う。

基本概念は4つに整理されている。エージェント（モデル・指示・ツール・MCPサーバー）、環境（ファイルにアクセスしスキルを読み込みコマンドを実行するサンドボックス。任意）、セッション（タスクに取り組み入力に応答する、持続するエージェントの実体）、そしてイベントとアイテム（入力と、セッション中に生成される出力）である²。利用の流れは、セッションを作る→タスクを与える→ストリーミングかWebhookで進捗を追う→同じセッションに次のタスクを送るか、作業中のエージェントを操舵する、という4ステップになる。

マネージドハーネスが引き受ける処理として挙げられているのは、サンドボックスでのコマンドとコードの実行、関連するスキルと指示の適用、ツールやMCP経由での外部データ接続、作業中のエージェントの操舵、コンテキストウィンドウを管理するための過去作業の要約、サブタスクへの分割とサブエージェントへの委譲、中断したセッションの再開である²。エージェント基盤を自作したことがあれば、このリストはほぼそのまま「自前で書くと面倒な部分」と重なる。ツールの接続にMCPサーバーを使える点は、7月に確定した MCP の大型仕様改訂を追ってきた読者には馴染みのある形だろう。

サンプルコードでは、モデルにGPT-6 Astraを指定し、multi_agent で同時実行するサブエージェント数の上限を設定し、MCPサーバーとWeb検索をツールとして並べる形が示されている²。エンドポイントは POST /v1/agents/sessions で、リクエストには OpenAI-Beta: agents=v1 ヘッダが必要になる。

実行環境は3通り、課金は積み上げ

実行環境は、OpenAIがホストするサンドボックス、自社インフラや対応プロバイダのサンドボックス、そしてサンドボックスなしの3通りから選べる³。サンドボックス内ではコードの実行、ファイルの編集、MCPサーバーへの接続、成果物の生成ができる。

課金は積み上げ方式で、モデル利用は選んだモデルのAPI料金、OpenAI製ツールは各ツールの標準料金、OpenAIホストのサンドボックスは標準のコンテナ料金が適用される²。Agents API自体に別建ての料金が乗るという記述は、ドキュメント上には見当たらない。実行環境を自社側に持つ構成を選べば、コンテナ料金にあたる部分は自前のインフラコストに置き換わると考えられる。エージェントの実行を自社ネットワーク内に置く構成は、Cursorのself-hosted machinesでも取られていた。

公式ドキュメントには、インシデント対応やデータ分析、GitHubのissue調査などを題材にした実装例が5件挙げられている²。一度の応答で完結せず、複数の道具を使って調べたうえで結果を返す種類の仕事が並んでいる。

統合の手間と、預けるものの釣り合い

OpenAIはドキュメント上で3つのランタイムを並べて比較している³。Agents APIは「OpenAIがエージェントを管理し進捗を保存する、長時間実行のタスク」向けで、統合の手間は「低」。Agents SDKは「アプリケーション内でカスタムツールとワークフローを使ってエージェントを作る」向けで手間は「中」。Responses APIは「モデルを直接呼ぶか、エージェントを一から作る」向けで手間は「高」とされている。タスク間の状態も、Agents APIは保存されたセッション設定・ターン・アイテム、Agents SDKは自前のストレージかSDKセッション、Responses APIは手動の履歴管理という形で分かれる。

手間が下がる代わりに預けるものがある。ドキュメントは、Agents APIが現時点で米国のデータ所在地のみに対応し、Zero Data Retention（ZDR）には対応していないと明記している。さらに、自社ホストのサンドボックスを選んでもAgents APIがZDR適格になるわけではない、とも書かれている²。セッション状態はターンをまたいで会話コンテキストを再構築せずに済むよう保持され、不要になったセッションと公開された成果物は削除できる。

この制約は、選択の分かれ目になりやすい。データ所在地やZDRが調達要件に入っている組織では、Agents APIをそのまま採用するのは難しく、Agents SDKやResponses APIで自前のループを維持するほうが要件に合う。逆に、要件が緩い領域の社内ツールから始めるなら、ハーネスの保守を丸ごと外に出せる利点は大きい。OpenAIは企業向けのエージェント運用基盤としてPresenceも出しているが、今回のAgents APIは完成した運用製品ではなく、自社アプリケーションに組み込むための部品として提供されている。

なお、公式ドキュメントは「Agents APIのセッション、SDKのセッション、Responsesの会話、サンドボックスはそれぞれ別のリソースであり、選んだランタイムの状態管理とクリーンアップの手順に従うこと」と注意を促している³。3つのランタイムが並存する以上、混在させたときの後始末は利用側の責任になる。

パブリックベータであることも織り込んでおきたい。changelogにGAの時期は書かれておらず¹、SDK上も beta 名前空間の下、HTTPでは OpenAI-Beta ヘッダの下に置かれている。同じCodexの名を冠するCLIも短い間隔で更新が続いていることを踏まえると、API側の仕様も当面は動くものとして扱っておくのが無難だろう。