OpenAIがAgents APIを公開ベータで提供開始｜Codexの実行基盤をAPIで借りるとき、自前実装から何を手放し何を残すか

OpenAIが、Agents APIを公開ベータとして提供を始めました。OpenAI API公式のChangelogでは2026年9月10日の項目です。一言でいえば、Codexで使われているエージェントの実行基盤(公式の表現では「Codex harness」)を、OpenAIが管理する形でAPIから使えるようにしたものです。エージェントのループを回し、会話の状態を保存し、長くなったコンテキストを圧縮し、途中で落ちたら復旧する。これまで自前で書いていたこの部分をOpenAI側に任せ、アプリケーションはツールと実行環境を用意する、という分担になります。

新しいAPIが出ると「移行すべきか」という話になりがちですが、実務で先に考えるべきなのは「任せることで何が楽になり、何が自分たちの責任として残るのか」です。この記事では、公式ドキュメントで確認できた仕様だけを使って、既存のResponses APIやAgents SDKとの使い分け、実行環境の選択肢、認証情報とネットワークの責任分界、料金の読み方、そしてベータ段階の制約を切り分けます。

何が発表されたのか#

公式Changelogの2026年9月10日の項目には、Agents APIを公開ベータとしてリリースしたこと、管理されたCodex harnessでエージェントを構築でき、セッションのオーケストレーション、コンテキスト圧縮、復旧をOpenAIが担うことが書かれています。あわせて、ターンをまたいで作業を続けられる永続的なセッション、進捗のストリーミング、自前のツールやMCPサーバーの接続、OpenAIホスト型サンドボックスか自前インフラ・対応プロバイダのサンドボックスでの実行、という特徴が挙げられています。

概要ページの説明もほぼ同じで、OpenAIがセッション、オーケストレーション、コンテキスト圧縮、復旧を管理し、アプリケーションはツールを提供して実行環境を選ぶ、とされています。エージェントはサンドボックス内でコードを実行し、ファイルを編集し、MCPサーバーに接続し、成果物を作れます。

管理されたハーネスが提供する機能として、概要ページには次のものが並んでいます。

• サンドボックスでのコマンドとコードの実行
• 関連するスキルや指示の適用
• ツールやMCPを通じた外部データへの接続
• 作業中のエージェントへの指示の追加(ステアリング)
• 過去の作業を要約してコンテキストウィンドウを管理すること
• 作業をサブタスクに分けてサブエージェントに委譲すること
• 中断したところからのセッションの再開

APIとしてはベータ扱いで、クイックスタートによればリクエストにはOpenAI-Beta: agents=v1ヘッダーが必要です(公式SDKは自動で付与し、SDKではbeta.agents名前空間を使います)。

なお同じ9月10日のChangelogには、プロジェクトのAPIキーに有効期限を設定できる機能と、組織・プロジェクト単位でキーの最長有効期間を強制できる管理機能(強制の対象は新しく作成するキー)の追加も載っています。後述するとおりAgents APIでは複数種類のキーを使い分けることになるため、キーのローテーション方針を見直すきっかけとして、あわせて押さえておくとよい変更です。

4つの構成要素と、誰が何を担うか#

Agents APIは、概要ページで4つの概念を中心に説明されています。

Agentの設定はセッション作成時に渡すこともできますし、保存して複数セッションで再利用することもできます。保存したエージェントを使いつつ、特定のセッションだけ設定を上書きすることも可能です。Configuring Agentsのページには、上書き時は配列やオブジェクトはマージではなく丸ごと置き換わる(たとえばtoolsを渡すと保存済みのツール一覧が置き換わる)と明記されているので、差分のつもりで渡すと事故になります。

アーキテクチャのページでは、実行時の役割分担が3つに整理されています。

• Harness: OpenAIがホストするCodexのインスタンス。モデルとツールのループを回し、セッションを維持する
• Environment: コマンド実行、コード実行、ファイル操作を行う場所。リモートのサンドボックス、手元のノートPC、Dockerコンテナ、AWS Lambda関数などがありうる
• Application server: エージェントを自社プロダクトにつなぐ自前のコード。タスクを送り、イベントを受け取り、関数ツールを処理する。環境を自前で用意する場合は、そのライフサイクル管理もここが担う

セッションの中の作業単位は「ターン」です。待機中のセッションにメッセージを送ると新しいターンが始まり、作業中のターンにメッセージを送るとそのターンの舵取り(ステアリング)になります。ターンは非同期に実行され、進捗はストリーミングかWebhookで受け取ります。

この構造で押さえておきたい実装上の注意も、公式にいくつか書かれています。ストリームは取りこぼしたイベントを再送しないため、切断後はセッションと保存済みのitemsを取得して復旧すること。セッションが待機状態(idle)になっただけでは成功を意味しないこと。ターンが完了しても、すべてのツールが成功したとは限らないこと。つまり「完了イベントが来たら成功」という単純な判定では足りず、ターンの結果とエージェントの出力を確認する処理がアプリ側に必要です。

Responses API・Agents SDKとの違いと選び方#

OpenAIには、エージェントを作るための選択肢がすでに複数あります。公式のAgentsページには、3つの実行方式を比べた表が載っています。要点を日本語にすると次のとおりです。

同じページには、Agents SDKについて「デプロイ、ストレージ、承認、ランタイム統合の制御をアプリケーションに与える」「ランナーがエージェントのループとハンドオフを処理する」とも書かれています。Agents APIとAgents SDKは名前が似ていますが、ループがどこで回るかが根本的に違います。

この表を業務の判断に置き換えると、Agents APIに移すことで手放すもの、残るものは次のように整理できます。

手放せる(OpenAIに任せられる)もの:

• エージェントのループの実装と、長時間タスクでの状態保存
• コンテキストが溢れたときの圧縮(要約)の仕組み
• サブエージェントの生成・待機・中断といった協調の仕組み
• ホスト型を選んだ場合のサンドボックスの払い出しと管理

手放すことになる(自由度が下がる)もの:

• ループの細かな制御。どの時点で何を要約するか、どう再試行するかといった判断はハーネス側にあります
• 状態の置き場所。セッションの設定・ターン・itemsはOpenAI側に保存されます
• トレースの取り回し。後述するとおり、公開ベータではトレースをAPIで取得したり外部の監視基盤へエクスポートしたりできません

自分たちに残るもの:

• 関数ツールの実装と、その副作用の管理
• 実行環境に何を置き、どこへの通信を許すか
• 認証情報の置き場所と権限設計
• 人の承認をどこに挟むか
• コストの見積もりと上限管理

ループの挙動を細かく作り込みたい、状態を自社のデータベースで完結させたい、既存の監視基盤にトレースを流したい、という要件があるなら、現時点ではAgents SDKやResponses APIのほうが素直です。逆に、長時間のタスクを落とさずに回すための基盤作りに工数を割けないチームにとっては、Agents APIは有力な選択肢になります。

2026年8月26日に停止したAssistants APIの移行先は、公式Changelogの8月26日の項目でResponses APIとConversations APIと案内されています。Changelogの移行案内にAgents APIは挙がっていないので、Responses APIへの移行作業中のチームが、その計画を慌てて変える必要はないと考えます。

実行環境の3択#

Agents APIでは、セッション作成時にenvironment.typeで実行環境をnone・openai_hosted・self_hostedから選びます。ここが設計判断の中心になるので、順に見ます。

環境なし(none)#

質問に答える、ツール経由で外部サービスを使う、といったエージェントなら、専用の計算資源やファイルは不要な場合があります。この場合、ハーネスはリモートMCPツールを直接呼び出し、関数ツールは自社コードが受け取って実行し結果を返します。

ただし環境なしでは、組み込みのBashツールやapply-patchツール、ワークスペースのファイル、環境内で動くMCP(executor MCP)は使えません。出力はセッションのitemsから読み取ります。

OpenAIホスト型サンドボックス(openai_hosted)#

スクリプトの実行、ファイル編集、成果物の作成が必要なら、OpenAIがセッションごとにサンドボックスを作って管理します。PythonとNode.jsとコマンドラインツールを備えたLinuxのワークスペースで、作業ディレクトリは/workspaceです。

設定できる主な項目は、パッケージ(Python・システム・npm)、エージェント開始前に実行するセットアップコマンド、入力ファイル、環境変数、スキルやプラグイン、そして設定を再利用するための環境テンプレートです。環境変数については、PATH、CODEX_*、OPENAI_API_KEYといった予約名は拒否されると書かれています。セットアップコマンドが0以外の終了ステータスを返すとエージェントは開始しません。

ネットワーク制御はnetwork.accessで次の3つから選びます。

restrictedで指定できるのは1〜100件の完全一致のホスト名(例: api.example.com)で、ワイルドカード、プロトコル、パス、ポートは含められません。サブドメインやリダイレクト先もそれぞれ個別に登録が必要です。また、ホスト型のstdio MCPサーバーは現時点でenabledが必要とされています。テンプレートを使う場合、ネットワーク設定の上書きでテンプレートのポリシーを広げることはできません。

既定値がenabledである点は、見落とさないでください。業務データを扱うなら、まずdisabledかrestrictedから始めて、必要な通信先だけを足していくのが安全側の設計です。

ファイルの扱いにも特徴があります。ファイルはサンドボックスが存在する間はターンをまたいで残ります。/workspace/outputs配下のファイルはターン完了時に不変の成果物(artifact)として公開され、そのコピーはサンドボックスが消えた後もダウンロードできます。

サンドボックスの寿命については、接続中のサンドボックスはターンの合間も含めてkeep-aliveを受けており、活動とkeep-aliveが1時間止まるとサンドボックスは削除されうる、この時間は変更できない、と書かれています。ストリームを閉じてもタスクはキャンセルされないことも明記されています。

ファイルの上限は次のとおりです(Files and artifactsページ)。

成果物は1リクエスト1ファイルでのダウンロードで、一括ダウンロードのエンドポイントはありません。複数ファイルをまとめて受け取りたい場合は、エージェントにZIPを作らせて/workspace/outputsに置く方法が案内されています。

セルフホスト型(self_hosted)#

自社のインフラ、プライベートネットワーク、独自ソフトウェアが必要な場合は、自前の環境を接続します。OpenAIがハーネスを動かし、利用者は環境内で実行器(executor)であるcodex exec-serverを動かします。実行器は環境IDと制限付きAPIキーでAPIに登録し、WebSocketで接続してコマンドを受け取り結果を返します。接続はすべて外向き(アウトバウンド)で、切断時は再接続します。

環境側で外向き通信を許可する必要があるのは、環境登録用のhttps://api.openai.comと、コマンドと結果のやり取りに使うwss://codex-cloud-environments.chatgpt.comです。受け入れ側のポートを開ける必要がない構成なので、社内ネットワークに置く場合も検討しやすい形です。

公式ドキュメントには、Modal、Cloudflare、Vercel、Daytona、Blaxel、E2B、Runloop、DigitalOcean、Oracle Cloud Infrastructure(OCI)の各プロバイダ向けのセットアップガイドが用意されています。

一方で、セルフホスト型では運用の責任が増えます。公式は、プロビジョニング、再接続、停止、残したいファイルの保存を利用者が担うと明記しています。ライフサイクルのページには、次のような注意が並びます。

• セッションを削除しても環境は停止せず、削除のWebhookも発行されない。計算資源は別途止める
• idleイベントだけでは安全な停止の合図にならない
• 入力時の環境接続は最大5分待ち、期限切れで送信は失敗する
• プロセスのクラッシュ時に保留中の入力が回復される保証はない
• 環境IDを再利用しても、置き換えた計算資源にファイルは復元されない

成果物の取り出しにも違いがあります。Files and artifactsページによれば、セルフホスト環境のファイルは/workspace/outputs配下であってもArtifacts APIでは公開されません。ターン完了後にプロバイダや自社インフラから取り出し、環境が消える前に自社のストレージへ保存する必要があります。

3つの環境の比較#

セキュリティで利用者側に残る責任#

Agents APIを使っても、セキュリティの責任がすべてOpenAIに移るわけではありません。Sandbox securityのページは冒頭で、エージェントが生成したコードは、その環境で利用可能なファイル、認証情報、ネットワークにアクセスできる、と明言しています。ここを前提に設計します。

アプリ用のキーと環境用のキーを分ける#

Agents APIでは、少なくとも2種類のキーが登場します。

1つ目はアプリケーション用のAPIキーです。セッション操作にapi.agents.readとapi.agents.write、推論にapi.responses.writeを付与し、Vaultを管理するならapi.vaults.readとapi.vaults.writeを加えます。公式は、このキーをサンドボックスの外に置くよう繰り返し書いています。

2つ目は、セルフホスト型の実行器に渡す環境キーです。プラットフォームのダッシュボードのAgentsタブで作成し、他の権限はすべてNoneにして、CODEX_API_KEYとして環境に渡します。公式によれば、エージェントが生成したコードはこの環境キーを読めますが、キーで許可されるのは環境の接続だけで、他のAPI操作は認可されません。それでもソースコード、コンテナイメージ、ログに埋め込まないこと、必要に応じてローテーションや失効を行うことが求められています。

「環境内のコードはキーを読める」という前提が明記されている以上、環境に置くキーの権限を最小にすることが、そのまま被害範囲の上限になります。前述の有効期限の機能は、Changelogでは「プロジェクトのAPIキー」を作成するときの機能とされており、最長有効期間の強制がかかるのも新しく作成するキーだけです。アプリ用のプロジェクトAPIキーには有効期限を付けておくのが素直ですが、Agentsタブで発行する環境キーにも同じ設定が効くかは、今回確認した公式ドキュメントからは読み取れませんでした。発行画面で確認してください。

第三者の認証情報は環境に置かない#

GitHubや社内SaaSなど第三者サービスの認証情報について、公式は環境の外に置き、可能ならクレデンシャルブローカーを経由させるよう求めています。ブローカーは承認済みの外向きリクエストにだけ秘密情報を差し込み、エージェントの環境には置きません。さらに、シークレットマネージャーに保管した秘密情報でも、環境に注入すればエージェントが生成したコードからは見えてしまう、とも書かれています。

MCP接続の認証には、いくつかの選択肢があります。

• 1セッション限りのHTTP認証情報: セッション作成時にtransport.authorizationやtransport.headersで渡す。暗号化され、返却されるセッションリソースからは除かれる
• 再利用するHTTP認証情報: Vaultに保存してセッションに添付する。VaultはOpenAI側から接続するMCPにのみ適用される
• stdio MCPの認証情報: 環境に値を置く。環境内で動くコードから読める

Vaultはベアラートークンと既存のOAuthグラントに対応します。OAuthグラントはauth.type: "mcp_oauth"で保存し、その際にrefresh(トークンエンドポイントやリフレッシュトークン)を含めれば、トークンの更新もAgents API側に任せられます。更新できずに期限が切れたトークンは、有効なものに差し替える必要があります。認証と同意のフロー自体はアプリケーション側が処理します。Vaultや資格情報を取得しても秘密の値は返されません。

見落としやすいのは削除時の挙動です。Vaultから資格情報を削除しても、提供元でのトークン失効や、実行中のセッションの停止にはならないと明記されています。退職者対応やインシデント時には、提供元側での失効とセッションのキャンセルを別の手順として持っておく必要があります。

隔離とネットワーク#

公式は、仮想マシンなどの隔離された計算資源でワークロードを動かすこと、データを共有してはならないユーザーやワークロードごとに環境を分けること、アプリやワークロード専用のOpenAIプロジェクトを作ることを推奨しています。セルフホスト型のページにも、同じ環境を共有するエージェントは同じファイルや認証情報にアクセスできる、と書かれています。

マルチエージェントを有効にした場合も、サブエージェントは親と環境のファイルシステムを共有し、サブエージェントを作っても別の環境は作られません。サブエージェントは設定済みのMCPツールとその認証情報、Web検索の設定を引き継ぎます。「調査だけのサブエージェントだから権限は弱い」とは限らない点に注意してください。

ネットワークについては、外向き通信を承認済みのエンドポイントに限るよう求められています。このとき、環境内から接続するMCP(executor MCP)は環境のネットワークから、リモートMCPはOpenAIのサービスから接続する、という違いを踏まえて許可先を決める必要があります。

人の承認はどこに置くか#

今回確認したAgents APIのガイド(概要、アーキテクチャ、セッション、ツール、環境、セキュリティ)には、ツール実行の前に人の承認を挟む専用の設定項目の記載は見当たりませんでした。一方で、公式のサンプルアプリ一覧には「アラートを調査し、復旧操作の承認を求めるインシデント対応エージェント」が挙がっています。

ドキュメントの仕組みから考えると、承認を挟みやすいのは関数ツールです。関数ツールはエージェントが呼び出しを要求するとセッションがrequires_actionになり、アプリケーション側のハンドラが実行して結果を返すまでターンが進みません。副作用のある操作(本番環境への変更、送金、外部への送信など)は、サンドボックス内のシェルから直接行わせるのではなく関数ツールとして切り出し、そのハンドラで承認フローを挟む、というのが筆者の考える自然な設計です。ただしこれは公式が承認の方法として示したものではない点は、明記しておきます。

関数ツールのページには、副作用のある関数の結果をセッション・ターン・呼び出しIDごとに永続的に保存し、実行が成功したかもしれないのに結果を保存できていない場合は、再実行の前に結果を確認するよう書かれています。承認後の二重実行を防ぐうえで、ここは必ず実装しておきたいところです。なお、サブエージェントは関数ツールをサポートしないと明記されているため、承認を挟みたい操作はメインのエージェントに担わせる設計になります。

データの保存と保持#

概要ページには、Agents APIは現在、データレジデンシーを米国でのみサポートし、Zero Data Retention(ZDR)には対応していないと書かれています。さらに、セルフホスト型のサンドボックスを選んでもZDRの対象にはならないと明記されています。

データコントロールのページにあるエンドポイント別の表では、/v1/agentsは学習への利用なし、不正利用監視のための保持が30日、アプリケーション状態の保持は削除されるまで、ZDRの対象外、と記載されています。セッションは不要になったら削除できますが、削除はAPIからの除去であり、物理的な後片付けは非同期に続く場合があるとされています。

ZDRを前提に社内審査を通しているシステムや、国内・特定地域でのデータ保管を求められる業務では、機能を検証する前にこの条件で止まる可能性があります。ここは法務・情報セキュリティの担当と先に確認してください。

料金とコストの読み方#

概要ページによれば、Agents APIには固有の料金はなく、次の組み合わせで課金されます。

• モデルの利用: 選んだモデルのAPI料金
• OpenAIのツール: 各ツールの標準料金
• OpenAIホスト型サンドボックス: 標準のコンテナ料金

料金ページの組み込みツール欄では、Hosted ShellとCode Interpreterのコンテナ料金が、1コンテナの20分セッションあたり1GBで$0.03、4GBで$0.12、16GBで$0.48、64GBで$1.92と掲載されています。対象となるコンテナセッションは分単位課金で、1セッション最低5分とも書かれています。ただし、Agents APIのホスト型サンドボックスがどのメモリ容量に該当するのか、選べるのかは、今回確認したAgents APIのドキュメントからは読み取れませんでした。見積もりに使う前に、実際の請求で確認するのが確実です。

タスク単位で見積もる#

Observabilityのページは、エージェントは1つのタスクを完了するまでに複数回モデルを呼び出すことがあり、それぞれがResponses APIと同じくモデルのトークン料金とプロンプトキャッシュの規則に従うので、タスク完了に必要な全呼び出しを通じてコストを見積もるように、と書いています。1回あたりの呼び出しには、指示、ツール定義、会話履歴、ユーザー入力、ファイルや画像、ツールの結果が入力トークンとして載り、推論トークンは出力トークンとして課金されます。

さらに、サブエージェントもモデルを呼び出します。ルートエージェントとサブエージェントの作業(再試行を含む)に加えて、ツール、サンドボックスの計算資源、第三者サービスの料金を合算するよう求められています。

規模感の参考として、Tracingのページには、ルートエージェントと2つのサブエージェントによる1ターンの記録例が載っています。10回のツール呼び出しで所要時間は1分37秒、トークン数は合計252,468で、内訳はルートエージェントが127,957、サブエージェントAが34,540、サブエージェントBが89,971でした。1回の依頼で数十万トークンが動きうる、という感覚は持っておいたほうがよいでしょう(もちろんタスクとモデルと設定によって大きく変わります)。

マルチエージェントの同時実行数はmax_concurrent_subagentsで制限でき、既定値はコーディネーターを除いて6です。コストと並列度のトレードオフを取るつまみとして使えます。

使用量の数字は「最終請求」ではない#

セッションとターンのリソースには使用量(usage)が含まれますが、公式はこれをbest-effortとしています。不明な場合はnullになりえ、記録された値は後から変わることがあり、nullは使用量ゼロを意味せず、請求額の確定値でもありません。サブエージェント別の使用量は、ターン一覧で各ターンのusageとsubagent_id(ルートエージェントならnull)を見て確認できます。

また、キャッシュ書き込みに料金がかかるモデルの場合、Agents APIの使用量フィールドにはキャッシュ書き込みの件数が別に出ないため、正確なモデル料金は算出できないと書かれています。

プロンプトキャッシュについては、初期の指示とツール定義をなるべく固定し、新しいタスクの詳細は後続メッセージで渡すことが推奨されています。一方で、キャッシュ入力の割合が高いことはタスク全体のコスト削減を示すものではない、とも書かれています。キャッシュされた入力も課金され、呼び出しを重ねれば長い履歴を何度も処理するからです。同じ品質とレイテンシでタスクを完了させるコストで比較するのが筋です。

公開ベータ段階での制約と注意点#

ドキュメントに明記されている制約のうち、業務で効いてきそうなものをまとめます。

• トレースの取得と外部トレースエクスポーターは公開ベータのAPIの対象外です。トレースは新規セッションで既定で有効ですが、確認はプラットフォームのダッシュボード(LogsのAgentsタブ)で行います。ダッシュボードのトレース用エンドポイントは別途のアクセスが必要で、サポートされた顧客向けAPIではないとされています
• 使用量はbest-effortで、nullになったり後から変わったりします
• コマンド出力が切り詰められたかどうかは、顧客向けAPIでは通知されません
• マルチエージェントのイベントストリームは、エージェント間の会話の完全な記録を提供しません
• サブエージェントは関数ツールを使えません
• ホスト型のstdio MCPサーバーは、ネットワークがenabledである必要があります
• ホスト型サンドボックスは、活動とkeep-aliveが1時間止まると削除される可能性があり、この時間は変更できません
• データレジデンシーは米国のみで、ZDRには対応していません

特にトレースの制約は、既存の監視基盤(OpenTelemetry系のツールや自社のログ基盤)でエージェントの挙動を追っているチームにとって大きいはずです。当面は、ストリームのイベントとセッションのitems、ターン情報を自社側で保存し、そこから必要な監査ログを組み立てることになります。

向く業務・向かない業務#

ここまでの仕様から、向き不向きを整理します。

向いていそうなのは、次のような業務です。

• 数分から数十分かかる調査・分析・レポート作成など、途中で落ちると困る長時間タスク
• データ分析のように、コードを書いて実行し、ファイルとして成果物を返すタスク
• 独立した複数の資料や原因候補を並行して調べ、最後に統合するタスク
• エージェントの実行基盤を作り込む人員がおらず、プロダクト側の価値に集中したいチーム

公式のサンプルアプリにも、インシデント対応、Slackボット、読み取り専用SQLによるデータ分析、GitHubのissue調査、ポリシーに基づく文書レビューが並んでおり、この方向性と一致します。

一方で、次のような条件では慎重に判断したほうがよいでしょう。

• ZDRや、米国以外でのデータレジデンシーが必須の業務
• エージェントの挙動を自社の監視基盤で完全に追跡する必要がある業務
• ループの制御や再試行の方針を業務要件に合わせて細かく作り込みたい場合
• 1回のモデル呼び出しで終わる単純な分類・抽出。ハーネスを挟む利点が薄く、コストの見通しも立てにくくなります
• すでにAgents SDKやResponses APIで安定稼働しているエージェント。公開ベータの段階で急いで移す理由は、少なくとも仕様上は見当たりません

導入を検討するときの進め方#

PoCに入るなら、次の順番で進めると手戻りが減ります。

よくある質問#

2026年9月10日にAgents APIを公開ベータとしてリリースしたこと、セッションのオーケストレーション・コンテキスト圧縮・復旧をOpenAIが担うという説明、同日のAPIキー有効期限機能の追加、Assistants APIの移行先がResponses APIとConversations APIであることは、OpenAI API公式Changelogの記載に基づきます。管理されたハーネスの機能一覧、4つの構成要素、料金の考え方、データレジデンシーが米国のみでZDR非対応という条件はAgents API概要ページ、保存済みエージェントの上書きで配列やオブジェクトが丸ごと置き換わる点はConfiguring Agentsページ、3つの実行方式の比較表とAgents SDKの説明はAgentsページ、Harness/Environment/Application serverの役割分担と環境なしの制約はArchitectureページ、ベータヘッダーとアプリ用キーの権限はクイックスタート、ターンとステアリング・ストリームの非再送はセッションのページ、required_actionsとセッション削除はManage sessionsページの記載に基づきます。ホスト型サンドボックスの設定項目・予約済み環境変数・network.accessの3つの値とallowed_domainsの条件・成果物の公開・1時間での削除はOpenAI-hosted sandboxesページ、ファイル上限とセルフホスト環境のファイルがArtifacts APIで公開されない点はFiles and artifactsページ、codex exec-server・外向き接続先・環境キーとプロバイダ一覧はSelf-hosted sandboxesページ、セッション削除で環境が止まらない点・5分の接続待ち・ファイルが復元されない点はSandbox lifecycleページ、隔離・キー権限・ブローカーはSandbox securityページ、関数ツールの結果の永続保存はFunctionsページ、MCPの接続元と認証の選択肢はMCP connectionsページ、Vaultの挙動とrefreshを含めた場合のトークン更新はVaultsページ、サブエージェントの既定同時実行数6・環境共有・関数ツール非対応はMulti-agentページ、コストの考え方・usageのbest-effort性・コマンド出力の切り詰め非通知・トレース取得の対象外はObservability and usageページ、トレースの既定有効と1ターンの記録例(252,468トークン、1分37秒)はTracingページの記載に基づきます。コンテナ料金はPricingページ、/v1/agentsのデータ保持はData controlsページの記載です。承認を関数ツールで挟む設計は公式の記載ではなく筆者の考えです。すべて2026年9月13日時点の確認です。

まとめ#

Agents APIは、「エージェントを動かすための基盤」をOpenAIが管理するサービスとして切り出したものです。ループ、状態保存、コンテキスト圧縮、サブエージェントの協調、ホスト型を選べばサンドボックスの管理まで任せられるので、長時間タスクを落とさずに回す仕組みを自前で作ってきたチームにとっては、実装と運用の負担を大きく減らせる可能性があります。

一方で、任せても消えない責任もはっきりしています。環境内のコードはファイル・認証情報・ネットワークにアクセスできる前提で、キーの置き場所と権限、第三者の認証情報の扱い、ネットワークの許可先、副作用のある操作の承認、そしてタスク単位のコストは、引き続き利用者側で設計する必要があります。加えて公開ベータの現時点では、米国のみのデータレジデンシー、ZDR非対応、トレースをAPIで取り出せないといった制約があります。

進め方はいつもと同じです。まずデータの条件で止まらないかを確認し、用途を1つに絞り、ネットワークを閉じた状態から代表タスクで品質とタスク単価を測ります。既存のResponses APIやAgents SDKの実装を急いで移すのではなく、「自前で作るのが一番つらかった部分」を任せられるかどうかで判断するのが、手戻りの少ない入り方だと考えています。