OpenAIがAgents APIを公開、Codexの実行基盤を開発者に提供

OpenAIは2026年9月10日、長時間動くAIエージェント向けの「Agents API」を全開発者に公開ベータとして提供した。モデルへの問い合わせ口を一つ増やした発表ではない。Codexで使ってきたセッション管理、文脈の圧縮、失敗からの復旧、複数エージェントの調整を担う制御層を、OpenAIが運用するAPIとして切り出したのである。開発者はその制御を預けながら、コードとファイルを置く実行環境を選べる。便利さの範囲を見極めるには、何をOpenAIが引き受け、費用とデータ管理のどこが利用者側に残るかを分けて考える必要がある。

OpenAIが引き受けるエージェントの運用制御

Agents APIが外部化したのは、モデルそのものよりも、モデルを仕事へ結び付けて走らせ続ける仕組みだ。OpenAIはこれを、Codexを支えるものと同じCodex harness（Codexハーネス）と説明している。ハーネスはモデルを呼び、ツールを選ばせ、作業状態を持ち、途中で失敗しても再開へつなぐ。従来はアプリケーション開発者が自前で組み合わせていた部分を、サービス側が受け持つ。

公式文書は、OpenAIの3つの開発手段を管理主体で分けている。

手段	主な用途	ループと状態を主に管理する側
Agents API	長時間の仕事を進め、進捗を保存する	OpenAIがCodexハーネスを動かす
Agents SDK	再利用できるエージェント、ツール、引き継ぎをアプリに組み込む	開発者のアプリケーション
Responses API	モデル応答を直接呼ぶ、または一からエージェントを組む	開発者のアプリケーション

選択を分けるのは、どのモデルを使うかより、ループと状態を誰が管理するかである。細かな分岐や応答をアプリ側で制御したいならSDKやResponses APIが合う。数時間から数日に及ぶ作業で、再開や文脈管理を保守する負担を減らしたいならAgents APIが候補になる。既存の2方式を置き換える関係ではなく、運用責任をどこまで委ねるかという違いだ。

Agents APIには4つの中核資源がある。Agentはモデル、指示、ツール、MCP接続を定める設定で、Environmentはファイルやコマンドを扱う場所だ。Sessionはターンをまたいで作業を続ける単位であり、Events and itemsは入力、出力、進捗を記録する。設定、実行場所、継続状態、記録を別々の資源にしたため、途中指示やWebhook、再開を同じ運用面で扱える。

ハーネスと実行環境を切り離す設計

OpenAIがハーネスを動かしても、生成コードを必ずOpenAIのコンピューターで実行するわけではない。公式アーキテクチャは、制御するハーネス、コードとファイルを扱う実行環境、タスクを投入してイベントを受けるアプリケーションサーバーを分けている。実行環境は不要ならnoneにでき、OpenAIホスト型、自社インフラ、提携事業者の環境も選べる。

OpenAIホスト型サンドボックスを選ぶと、Python、Node.js、CLIツールを備えたLinux環境が用意される。作業ディレクトリは/workspaceで、パッケージや初期化コマンド、入力ファイル、環境変数、スキル、プラグインを設定できる。各セッションは独立したworkspaceを持ち、ファイルはサンドボックスが存在する間、ターンをまたいで残る。/workspace/outputsへ出した成果物はターン完了時に不変の出力として公開され、サンドボックスが失効した後も取得できる。

Cloudflareが公開した公式チュートリアルは、この分離を具体的に示す。署名付きのOpenAI WebhookをCloudflare Workerが受け、セッションごとにDurable Objectで管理するContainerへ接続する。Containerではcodex exec-serverと生成コードが動き、workspaceはCloudflareアカウント側に残る。OpenAIが仕事の進め方を制御し、Cloudflareがコードの実行場所を持つ構成である。

この分離により、組織はハーネスを一から保守せず、ファイルやコードの置き場所を要件に合わせられる。ただし、workspaceを自社や提携先へ置くことと、Agents APIが持つセッション状態の保存先は別の問題だ。実行環境の選択だけで、保持地域や保存禁止の要件が満たされるわけではない。

長時間の作業を支える文脈管理と並列実行

長時間の仕事では、モデルの一回の性能より、途中経過を失わずに続けられるかが結果を左右する。Agents APIはセッションを継続資源として持ち、ストリーミング接続が切れても処理を続けられる。イベントストリームを閉じる操作はキャンセルではない。アプリケーションは後から同じセッションへ戻り、進捗を読み、追加指示を送れる。

文脈上限へ近づくと、context compaction（コンテキスト圧縮）が過去の作業を要約し、次の文脈窓へ引き継ぐ。さらにツール検索は、登録済みツールの定義をすべて毎回読み込まず、必要になったものを取得する。プログラムによるツール呼び出しでは、複数の呼び出しをコードで並列化したり連結したりし、結果を絞ってから関連部分をモデルへ戻す。長時間化で膨らみやすい文脈を、履歴、ツール定義、ツール出力の三方向から抑える設計だ。

マルチエージェントを有効にすると、主担当は独立した文脈を持つサブエージェントへ作業を分けられる。既定の同時実行数は、主担当を除いて6である。サブエージェントを作っても新しい実行環境は増えず、全員が同じファイルシステムを共有する。調査や検査を並行化しやすい反面、仕事の切り分けと共有ファイルの競合防止は利用者側の設計に残る。

進捗はセッションログとイベントで追え、主担当とサブエージェントのトークン使用量も確認できる。ただし公開ベータでは、トレースを取得する専用APIと外部エクスポーターは提供されていない。OpenAIホスト型サンドボックスも無期限には残らず、活動とkeep-aliveが1時間止まると削除され得る。この1時間は変更できないが、セッション自体の最大寿命を表す数字ではない。

自動圧縮が重要情報を常に保つ保証も、サブエージェントが必ず速さや品質を改善する保証も示されていない。したがって長時間運用で測る対象は、タスクの成否に加え、圧縮をまたいだ指示保持、再開後の一貫性、並列化で増えた利用量まで広がる。

「追加料金なし」が消さない3層のコスト

OpenAIは発表文で、Agents API自体に追加のサービス利用料はないと説明した。これはAPIを使うための上乗せ料金がないという意味であり、実行全体がトークン料金だけに収まるという意味ではない。Agents APIに追加のサービス利用料はないが、実際の請求にはモデルのトークン、OpenAI製ツール、OpenAIホスト型サンドボックスのコンテナ料金がそれぞれ加わる。

課金層	対象	公式文書での扱い
モデル	入出力やキャッシュされたトークン	選んだモデルのAPI料金
OpenAI製ツール	Web検索など	各ツールの標準料金
ホスト型サンドボックス	Shell、Code Interpreter用コンテナ	容量と稼働時間に応じた標準コンテナ料金

2026年9月11日に確認した公式料金表では、ホスト型ShellとCode Interpreterのコンテナ料金は20分セッション・コンテナ当たり、1GBが0.03ドル、4GBが0.12ドル、16GBが0.48ドル、64GBが1.92ドルである。対象セッションは分単位で請求され、最低5分という注記もある。Web検索は1,000回当たり10ドルで、検索内容のトークンにはモデル料金が加わる。

つまり総費用は、選ぶモデル、呼び出すツール、コンテナ容量、稼働時間で変わる。長いセッションやサブエージェントが成功率を高めても、処理量が増えれば請求額は上がり得る。逆に、ツール結果の絞り込みや適切な分業が再試行を減らせば、総費用が下がる可能性もある。比較すべきなのは一回のトークン単価ではなく、仕事を完了するまでの成功率、時間、モデル・ツール・環境費の合計である。自社や提携先で実行する場合は、その環境の料金も別に発生する。

自社ホストでも残るデータ保持と安全性の責任

Agents APIのセッション状態は、実行環境を自社側へ置いてもAPI側に保持される。OpenAIの概要文書によると、2026年9月11日時点のデータレジデンシーは米国のみで、Zero Data Retention（ゼロデータ保持、ZDR）には対応しない。利用者はセッションと公開済み成果物を削除できるが、規制地域や保存禁止要件を持つ組織は、自社ホスト型を選ぶだけで要件を満たしたと判断できない。

もう一つの境界は、エージェントが生成して実行するコードである。そのコードは、実行環境に置いたファイル、資格情報、許可したネットワークへアクセスできる。OpenAIホスト型では、テンプレートの方針を継承しない場合、外向きネットワーク接続がenabledで始まる。完全に止めるdisabledか、1〜100個の完全一致ホスト名を許すrestrictedも選べるため、本番では必要な通信先を先に限定する設計が要る。

資格情報も用途別に分ける必要がある。OpenAIは、アプリケーションのAPIキーを実行環境の外に置き、環境接続に使う制限付きキーを分離するよう案内している。第三者サービスの資格情報は、可能ならブローカーを介して注入する。Cloudflareの例でも、モデルの読み取りと環境接続だけを許す実行キーと、セッション状態を読むアプリケーションキーを分けている。

ハーネスを管理サービスに移すと、セッション制御や復旧を保守する負担は減る。しかし、どのファイルを渡すか、どこへ通信させるか、どの権限を与えるかという判断は消えない。実行場所、API側の保持、ネットワーク、資格情報を別々に監査して初めて、責任分担を実際の運用へ反映できる。

公開ベータで確かめたい運用上の条件

公開資料からは、一般提供へ移る時期、正式版のサービス品質保証、障害時の復旧保証、セッションの最大寿命を確定できない。米国外のデータレジデンシーやゼロデータ保持をいつ提供するかも未公表である。したがって導入判断では、提供側に確認する条件と、自分のワークロードで測れる性能を分ける必要がある。

試用で測れるのは、長時間セッションの完了率、圧縮後に条件を守れた割合、切断やツール失敗から再開できた割合である。マルチエージェントは、同じ課題を単独で処理した場合と比べ、待ち時間、総トークン、ツール利用、共有ファイルの競合数を記録するとよい。OpenAIが紹介する顧客事例には評価改善や待ち時間短縮があるが、比較条件と母数が公開されていないため、自社の期待値にはそのまま使えない。

一方、正式版SLA、保持地域、削除と監査の条件は、実験で確定できない。組織の必須条件を先に定め、公開ベータの提供範囲が届かない用途を切り分けるべきだ。保持地域や資格情報の権限といった必須条件を満たす用途に限って、実際の仕事が完了する確率と、完了までに消費した総額を測る。その数字が、Codexで磨かれた運用制御を採用するかどうかを決める。