OpenAIがAgents APIを公開：1回の呼び出しでCodex同等のクラウドAgentを実行

OpenAIは、パブリックベータ（Public Beta）段階となるAgents APIを正式にリリースしました。AI Agentの開発や本番導入を計画しているチームに向けて、公式にホストされたオーケストレーション基盤（ハーネス：harness）と実行環境を提供し、開発者が単一のAPI呼び出しによって、本番環境で長時間のタスクを実行可能なクラウドAgentを構築・実行できるようにします。

対話ボックスから長時間タスクへ：OpenAIは今回何をリリースしたのか？

Agentを構築する際、実際のエンジニアのようにオンライン障害を調査させたり、複数ファイルにまたがるコードを処理させたり、外部システムを呼び出させたりするには、開発者自身が多くの連携ロジックを実装する必要がありました。プロンプトチェーンの手書き、ツール呼び出しの自己管理、コンテキストウィンドウの上限超過への対処、さらにはコード実行用のコンテナや権限の維持管理などを自前で行う必要があったのです。

OpenAIは、CodexやChatGPT for Workを世界中の数百万人のユーザーへと展開していく過程で、長時間実行されるAgentが実践において何を必要とするのかを突き止めました。実用的なAgentには、コンテキストを管理し、ツールを効率的に利用し、サブAgentを協調させるオーケストレーション基盤（ハーネス）が不可欠であり、数日間にわたって確実に連続稼働し、その中でAgentがファイルの読み書き、コードの実行、中間結果の保存を行えるインフラストラクチャも求められます。

Agents APIを通じて、OpenAIはCodexを駆動しているものと同一のハーネスおよびインフラストラクチャを開発者に開放しました。従来はプロンプトチェーンの作成やツール管理を手動で行っていたワークフローを、単一の標準API呼び出しへと集約できます。開発者はタスク、モデル、ツール、環境を指定するだけでよく、セッション管理、オーケストレーション、コンテキストの圧縮や復元といった複雑なロジックは、OpenAIがホストするCodexハーネスがすべて担います。

料金面において、Agents API自体に追加のプラットフォーム管理費用はかかりません。開発者はAgentが使用したモデルトークンおよび組み込みツールの実際の実績に基づいて支払うだけです。OpenAIマネージドサンドボックスを選択した場合、コンテナのコンピュート料金は標準のコンテナレートに従って課金されます。

単一のAPI呼び出しでクラウドAgentを構築

Agents APIでは、マルチタスク協調機能を備えたAgentの作成と実行は、1回のセッション作成リクエストを発行するだけで完了します。公式リリースノートには以下のJavaScriptの例が掲載されています：

import OpenAI from "openai";

const client = new OpenAI();

const session = await client.beta.agents.sessions.create({
  agent: {
    model: "gpt-6-astra",
    tools: [
      {
        type: "mcp",
        server_label: "observability",
        transport: {
          type: "http",
          server_url: "https://observability.example.com/mcp",
        },
      },
    ],
    multi_agent: { enabled: true, max_concurrent_subagents: 3 },
  },
  vault_ids: ["vault_YOUR_VAULT_ID"],
  environment: {
    type: "openai_hosted",
    capability_directories: ["/workspace/capabilities/skills"],
  },
  input:
    "Investigate service-api’s elevated 5xx rate over the last 30 minutes. " +
    "Delegate deployment, error, and dependency analysis to subagents. " +
    "Save findings, evidence, and recommended mitigation in /workspace/outputs.",
});

このコードは、各コア要素がどのように連携するかを明確に示しています：

• agent.model：ベースモデルを指定します。ここではgpt-6-astraを使用しています。
• agent.tools：Agentが呼び出し可能なツールを宣言します。サンプルではmcpタイプのツールが構成され、HTTP transport経由で外部の可観測性サービスobservabilityに接続されています。
• agent.multi_agent：マルチAgent委任のサポートを有効化し、max_concurrent_subagents: 3を設定して、メインAgentが最大3つのSubagentを同時に並行稼働させることを許可しています。
• vault_ids：公式サンプルには["vault_YOUR_VAULT_ID"]が含まれていますが、リリースノートおよび付属のドキュメントにはこのパラメータの用途についての説明はありません。
• environment：コンピュートサンドボックスを指定します。ここではopenai_hosted（OpenAIマネージドサンドボックス）を採用し、capability_directoriesを通じて/workspace/capabilities/skillsディレクトリを指定しています（開発者ドキュメントによれば、skills、plugins、capability_directoriesはいずれもマネージドサンドボックス内のAgentに事前定義された機能を注入するために利用できます）。
• input：Agentに渡す初期タスク指示です。このタスクでは、直近30分間に発生したservice-apiの5xxエラー率上昇の原因調査を要求し、デプロイ、エラー、依存関係の分析をそれぞれSubagentに委任し、最終的な調査結果、証拠、緩和策の提案を/workspace/outputsディレクトリに保存するよう指示しています。

このワークフローにおいて、マネージドCodexハーネスがモデルの駆動、セッション管理、Subagentのオーケストレーションを担当します。ツールはMCP経由で外部システムとやり取りし、コードと分析タスクはサンドボックス内で実行されます。最終的な出力結果は/workspace/outputsに保存され、ターン（Turn）終了時に不変の成果物（Artifact）として自動的に公開されます。

コアアーキテクチャの解体：フレームワークと環境の役割分担

Agents APIを理解するには、まずシステムアーキテクチャにおける役割分担を把握する必要があります。OpenAIの公式アーキテクチャ図は、3者の役割分担を示しています：

このアーキテクチャにおいて、役割は明確に3つの部分に分かれています：

1. あなたのアプリケーション（Application）：Agents APIにタスクを送信し、返送されるイベントストリーム（Events）と出力結果を受信します。
2. マネージドCodexハーネス（Managed Codex Harness）：OpenAIによってホストおよび保守され、モデルの実行、ツール呼び出しの調整、セッション状態の維持、コンテキストのスケジューリング、サブAgentの管理を担当します。
3. コンピュートサンドボックス（Sandbox）：OpenAIまたは利用プロバイダーによって提供され、Agentはその中でファイルの読み書き、Shellコマンドの実行、コードの実行を行います。

4つのコアコンセプトとライフサイクル

公式のAgents APIの概要（overview）では、システム全体が4つのコアコンセプトを中心に展開されています：

• Agent：Agentに割り当てられたモデル、指示（instructions）、ツール、およびMCPサーバー設定を含みます。
• Environment：任意のサンドボックスまたは計算環境。Agentはこの環境内でファイルにアクセスし、スキル（skills）をロードし、コマンドを実行します。
• Session：具体的なタスクを実行し、後続の入力に応答する、永続的なAgentインスタンスです。
• Events and items：セッション期間全体を通じてAgentに送信される入力コンテンツ、およびAgentの実行プロセス中に生成される一連のイベントと出力項目です。

セッションの完全なライフサイクルは次の4つのステップで構成されます：

1. セッションの作成（Create a session）：アプリケーションがAgent設定を送信し、OpenAIが環境を準備します（これはOpenAIマネージドサンドボックスを使用する場合の流れです。セルフホストサンドボックスを使用する場合、実行環境は開発者側で起動して接続し直します）。
2. タスクの付与（Give it a task）：環境の準備が整ったら、タスク入力を渡すことで作業ターン（Turn）を開始します。
3. 進捗の追跡（Follow progress）：イベントストリームを介してリアルタイムに出力を監視するか、Webhookを使用してAgentが作業を完了した時点や人間の入力を必要とする時点を検知します。
4. 継続または誘導（Continue or steer）：同一セッション内で後続のタスクを引き続き割り当てたり、現在のターンの中途でAgentに軌道修正や指示を提供したりできます。

ビジネスに適したサンドボックス環境の選択

ワークロードによって、コンピュートリソース、ストレージ、デプロイ形態への要件は異なります。Agents APIでは、ユースケースに応じて適切なサンドボックスを選択できます：

• OpenAIマネージドサンドボックス（OpenAI-hosted）：迅速に立ち上げ、効率的に拡張したいケースに適しています。このサンドボックスはCodexおよびChatGPTを駆動するのと同じサンドボックスインフラを再利用しています。OpenAIが環境のプロビジョニングと管理を担当し、Python、Node.js、コマンドラインツールを含むLinuxワークスペース（作業ディレクトリは/workspace）をAgentに提供します。
• エコシステム・サンドボックスパートナー（Sandbox Partners）：OpenAIは複数のエコシステムプロバイダーとファーストクラスの統合を確立しています（詳細はセルフホストおよびパートナーサンドボックスガイドを参照）。これにはModal、Cloudflare、Daytona、Blaxel、Runloop、Vercel、Oracle、E2B、DigitalOceanが含まれます。
• セルフホストサンドボックス（Self-hosted）：自社で管理するコンピュートリソースを使用したい場合は、ローカルPC、自社コンテナ、またはクラウドサーバー上で実行環境を動作させることができます。

パートナーサンドボックスは主に次の3つの要件を満たします：

1. フルマネージド環境、または企業のVPC内部へのデプロイ。
2. 特定のファイルおよびシークレットのストレージメカニズム。
3. パフォーマンス、コールドスタート、コストに関する特定のワークフロー要件に合わせた、異なるCPU、GPU、メモリ構成。

なお、パートナーサンドボックスもセルフホストサンドボックスと同じ接続メカニズムを利用しており、実行マシンを提供するのが提携サービス事業者である点のみが異なります。

セルフホストサンドボックスの接続メカニズムとセキュリティ境界

セルフホストサンドボックスにより、コードとファイルは信頼できる自前マシン上で実行され、すべての接続は内側から外側へ向けて（アウトバウンド）確立されます。ただし、コンプライアンス境界には十分注意する必要があります：セッション状態とオーケストレーションロジックは依然としてOpenAIのクラウド上で保持されます。Agents APIは現在、米国データレジデンシーのみをサポートし、ゼロデータ保持（ZDR: Zero Data Retention）には対応していません。セルフホストサンドボックスを選択しても、セッションがZDR要件を満たすことにはなりません。

セルフホストサンドボックスの具体的なセットアップと実行フローは以下の通りです。まず内部コンテナまたはマシンにCodex CLIをインストールします：

mkdir -p /workspace
npm install -g @openai/codex@alpha

実行側のコンポーネントはCodex CLIに同梱されているデーモンプロセスcodex exec-server（エグゼキューター、executor）です。起動コマンドは以下の通りです：

codex exec-server \
  --remote "<session.environment.remote_url>" \
  --environment-id "<session.environment.id>"

そのネットワークおよび認証設計には、以下のセキュリティ特性があります：

• 完全アウトバウンドネットワーク接続：環境はHTTPS（https://api.openai.com）経由で登録された後、WebSocket（wss://codex-cloud-environments.chatgpt.com）を通じてOpenAIとの持続的接続を確立してコマンドを受信し、結果を送り返します。社内ネットワークでインバウンドポートを開放する必要は一切ありません。
• 制限付き認証情報の分離：セルフホストサンドボックスに注入する環境変数には、専用の制限付き環境キーCODEX_API_KEYを使用すべきです（プラットフォームダッシュボードで作成する際、他の権限をすべてNoneに設定します）。このキーは環境接続にのみ使用可能で、他のいかなるAPI操作も実行できません。Agentが生成したコードはこのキーを読み取ることができるため、ソースコード、イメージ、ログに書き込まないようにし、必要に応じて迅速にローテーションまたは失効させてください。
• ワークロードの分離：同一のサンドボックス環境内にいるAgentは同じファイルや認証情報にアクセスできるため、ユーザーごと、または特定のワークロードごとに実行環境を厳格に分離する必要があります。

オーケストレーション基盤のコア機能：Codex Harnessの重要メカニズム

OpenAIはCodexを展開する過程で、長時間実行されるAgentが実践において何を必要とするのかを突き止め、これらの機能をハーネスに凝縮しました。

ハーネスはモデルのアップグレードに合わせてバージョン管理される

新しいモデルの能力を最大限に引き出すためには、通常、独自のスケジューリングフレームワーク（ハーネス）に手を加える必要があり、アプリケーションの改善に充てるべき時間が奪われてしまいます。Agents APIはモデルがリリースされるたびに、それに見合った機能をバージョンごとに提供します。OpenAIがハーネスとモデルを協調して維持管理し、継続的に改善するため、アップグレードのたびにAgentのパフォーマンス向上を享受できます。

公式リリースノートでは、ハーネスにおける最近の代表的な改善例が挙げられています（これは完全な機能リストではなく、直近で重点的に改善された方向性を示しています）：自動コンテキスト圧縮、より効率的なツール利用（ツール検索とプログラムによるツール呼び出し）、およびマルチAgent協調です。

自動コンテキスト圧縮（Compaction）：複数ウィンドウをまたいでタスクを継続

Agentが連続して実行され、頻繁にツールを呼び出すと、履歴レコードはモデルの単一ウィンドウ上限に容易に近づいてしまいます。

モデルが数時間にわたって継続作業できるようにするため、Agents APIはネイティブなコンテキスト管理機能を提供しています（詳細はコンテキスト圧縮ガイドを参照）。セッションがコンテキスト上限に近づくと、システムは初期のコンテキスト内容を自動的に圧縮し、後続の作業継続に必要な情報を保持します。開発者は自前で圧縮ロジックを実装することなく、複数のコンテキストウィンドウをまたぐワークフローを構築できます。

注：記事内でリンクされている圧縮ガイドはResponses APIを例に圧縮メカニズムを解説しており、リリースノートではAgents APIにおける圧縮の具体的なフォーマットについては詳述されていません。

ツール検索（Tool Search）：ツール定義をオンデマンドで読み込む

最初からすべてのツールの完全な定義をモデルのコンテキストにすべてロードしてしまうと、使用されない定義が貴重なコンテキスト領域を浪費するだけでなく、ツール定義を変更した際に以前キャッシュされたプレフィックスが無効化されるリスクもあります。

ツール検索ガイドによると、このメカニズムにより、モデルは必要に応じてツール定義を動的に検索してロードできるようになります。新しく検出されたツールはコンテキストの末尾に追加されるため、それ以前にキャッシュされたコンテンツへの影響を防ぐことができます。

Agents APIにおけるツール検索の設定ルールは以下の通りです：

• MCPツール：モデルとプロバイダーがツール検索をサポートしている場合、Agents APIはMCPツールに対して自動的に遅延ロード（lazy loading）を適用し、ツール検索を自動で有効化するため、開発者による追加設定は不要です。
• カスタム関数ツール：デフォルトでは依然として一括ロード（eager loading）されます。オンデマンド検出を利用したい場合は、agent.tools配列内で{"type": "tool_search"}を宣言し、遅延ロードさせたい関数に個別にdefer_loading: trueを指定する必要があります。
• 遅延ロードの適用範囲：遅延ロードが指定された個別の関数について、モデルは初期状態でもその名前と機能説明を確認できます。主に読み込みが遅延されるのは、具体的なパラメータスキーマ（parameter schema）です。（この仕様はツール検索ガイドのResponses APIセクションに基づきます。）
• （注：「各名前空間内のツール数を10個未満に抑えることを推奨する」という記述は、Responses APIドキュメントに記載されているパフォーマンス上の推奨事項です）。

プログラムによるツール呼び出し（Programmatic Tool Calling）：分離されたランタイムでのフィルタリングと集約

従来の呼び出し方式では、Agentがツールを1回呼び出すたびに、返された生の生データすべてを直接コンテキストに書き込む必要がありました。ツールが大量の不要データを返した場合、コンテキストはすぐに枯渇してしまいます。

プログラムによるツール呼び出しガイドでは、モデルが自身のツールをオーケストレーションするためのJavaScriptコードを記述できる新しいパターンが解説されています。Agents APIでは、プログラムによるツール呼び出しがデフォルトで有効になっています（無効化する場合は明示的にenabled: falseを設定する必要があります）。

そのランタイム環境には厳格な境界が設けられています：

• コードは独立かつ分離されたV8ランタイム内で実行され、トップレベルのawaitをサポートします。
• ランタイムには直接のネットワークアクセスやNode.jsはなく、サードパーティ製パッケージのインストールも不可、汎用ファイルシステムも存在せず、プログラムの実行間で状態は保持されません。
• コードは現在のリクエストで有効化されているツールを通じてのみ外部システムと対話でき、text(...)またはimage(...)を介して結果を出力します。

このメカニズムにより、モデルは分離環境内でループ処理、条件分岐を実行したり、有効化された複数のツールを同時に呼び出したりできます。例えば、100件のログを分析して頻度を集計する調査タスクを想定してみましょう。従来モデルでは、100件のログを含む完全なJSONを丸ごとコンテキストに投入する必要がありました。一方、プログラムによる呼び出しでは、コードがV8ランタイム内部でフィルタリング、重複排除、集計を完結させ、最終的な簡潔な統計結果のみをモデルのコンテキストに返します。この方式により、コンテキストに入る中間データを削減できます。実際にどれほどのトークンが節約できるかは、個々のタスクの性質に依存します。

エンジニアリング実装においては、タスクの特性に応じて直接呼び出しとプログラム呼び出しを適切に選択する必要があります：

• 単一のクエリまたは単一の操作：直接ツール呼び出し（Direct tool calling）を推奨
• フィルタリング、連結、ソート、重複排除、集約、バリデーションを行うコードを必要とする複数の結果：プログラムによるツール呼び出し（Programmatic Tool Calling）を推奨。コードから簡潔で構造化された結果を返却
• 予測可能なデータフローを持つ依存関係のある呼び出し：プログラムによるツール呼び出しを推奨。コード側で後続パラメータを導出し、境界とエラー処理を明確化
• 適応型検索やセマンティック評価（各ステップの結果についてモデルの再判断が必要な場合）：直接呼び出しを推奨。各結果がモデルの次の判断にリアルタイムで影響を与えるようにする
• 書き込み操作や承認を要する高機密なアクション：デフォルトでは直接呼び出しを推奨。明確な権限と確認の境界を維持するため
• 最終的な引用検証やネイティブ成果物の検証：直接呼び出しを推奨。プログラム側でネイティブ出力を完全に保持し、必須項目をすべて検証できる場合を除く リリースノートでは、Agents APIがMCP、カスタム関数、およびウェブ検索などの組み込みツールをサポートしていることが特筆されています。例えば、以下の設定によりOpenAI公式ドキュメントのMCPサービスをマウントできます：

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "openai_docs",
      "transport": {
        "type": "http",
        "server_url": "https://developers.openai.com/mcp"
      }
    },
  ]
}

マルチAgent並列協調（Multi-Agent Subagents）：分業と並行委任

複雑な分析や比較作業に向けて、Agents APIはネイティブなマルチAgentサポートを提供しています（詳細はマルチAgentドキュメントを参照）：

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3,
  }
}

マルチAgentメカニズムにおいては：

• メインAgent（コーディネーター）がタスクを分解し、Subagentに委任して並行作業を行わせます。
• 同時実行制限パラメータmax_concurrent_subagentsのデフォルト値は6（コーディネーターを含まない）で、必要に応じて正の整数にカスタマイズ可能です。
• オーケストレーション基盤（ハーネス）は、Subagentの作成、メッセージ送信、待機、中断を行う組み込みツールを自動的に提供します。開発者がこれらツールを独自に宣言する必要はありません。
• 適用シナリオ：相互に独立したタスク（異なるドキュメントの独立したレビューや、障害の異なる根本原因の個別調査など）に適しており、各サブタスクには明確な課題と期待される成果物が必要です。短いタスクや前後に依存関係があるステップは、メインAgent内で実行し続けるべきです。
• ファイル協調における注意事項：各Subagentはタスクへの集中を維持するために独立したコンテキストウィンドウを持ちますが、サンドボックスに接続している場合、すべてのAgentは同一のサンドボックスファイルシステムを共有します。複数のAgentが同一のファイル群を変更する必要がある場合は、プロセス上で明確な協調メカニズムを設計しなければなりません。

制約事項（マルチAgentドキュメントより）：Subagentは、メインセッションに設定されたMCPツール（アクセス認証情報と許可ツールリストを含む）およびウェブ検索設定を継承し、サンドボックス環境内のファイルやコマンドラインツールも利用できますが、現時点でSubagentは関数ツール（Function Tools）をサポートしていません。

編集部のアドバイス：業務においてSubagentに処理させる必要があるカスタムロジックが存在する場合は、MCPサービスとしてカプセル化するか、サンドボックス内のコマンドラインスクリプトとして実装することをお勧めします。

オープンソース基盤：Codex Harness

Agents APIを駆動しているのは、オープンソースのCodexハーネスです。モデル呼び出し、ツール利用、コンテキスト管理を調整するコアスケジューリングロジックは、公開リポジトリopenai/codexで確認・学習できます。Agents APIを通じて、OpenAIがクラウド上でこのハーネスの運用と保守を担当するため、開発者は自前で基盤を構築・維持することなく直接利用できます。

公式ミニマムサンプル（quickstart）

公式のクイックスタートガイド（quickstart）では、Python SDK（beta.agents名前空間）を使用して、コード実行とファイル操作機能を備えたセッションを起動するコードが示されています：

from openai import OpenAI

with OpenAI() as client:
    with client.beta.agents.sessions.create(
        agent={
            "model": "gpt-6-astra",
            "instructions": "Write clean code, run it, and report the actual output.",
        },
        environment={"type": "openai_hosted"},
        input="Create tree.py, a Python script that prints a readable tree of the files in the current directory. Run it and show me the output.",
        stream=True,
    ) as events:
        for event in events:
            print(event.to_json(indent=None), flush=True)

このコードの実行プロセスにおいて、システムは以下のアクションを完了します：

1. 環境の準備：OpenAIはクラウド上でこのセッション用にopenai_hostedサンドボックス環境をプロビジョニングします。作業ディレクトリは/workspaceです。
2. コードの生成と実行：Agentはワークスペース内にtree.pyファイルを作成し、サンドボックスのターミナルでスクリプトを実行して、ディレクトリツリーの出力を取得します。
3. イベントストリームの追跡とステータス確認：クライアントはイベントストリームを通じて進捗を監視します。ターンが終了すると、システムはagent.session.turn.completedイベントを発行しますが、これは各ツール呼び出しが正常に実行されたことを保証するものではありません。Agentが報告した実際の実行結果を確認する必要があります。turn.failed、turn.cancelled、またはsession.failedを受信した場合は、ターンが失敗またはキャンセルされたことを示します。agent.session.idle状態だけではタスクの成功を表すことにはなりません。ストリームが予期せず中断された場合は、再試行を判断する前に、まずセッションおよび保存されたitemsを取得してください。
4. 成果物のアーカイブと保持：タスクがレポートやデータグラフを生成した場合、/workspace/outputsディレクトリに書き込まれていれば、ターン完了時に不変の成果物（Immutable Artifacts）として公開されます。サンドボックスがその後アイドル状態によってクリーンアップされたとしても、これらの成果物コピーは引き続きダウンロード可能です。セッションをクリーンアップして削除する前に、必要なファイルを先にダウンロードしておく必要があります。

マネージドサンドボックスの環境構成とネットワーク制御

OpenAIマネージドサンドボックス構成ガイドによると、サンドボックスはきめ細やかな環境カスタマイズ機能を提供しています：

• プレインストール構成：packagesを通じてPython、システム、またはnpmの依存関係をインストール可能。setup_commandsを通じてAgentの起動前に準備シェルコマンドを順次実行可能（setupコマンドがゼロ以外の終了コードを返した場合、Agentは起動しません）。filesを通じて初期ファイルをアップロード可能。envを通じて環境変数を設定可能（ただし、PATH、CODEX_*、OPENAI_API_KEYなどのシステム予約名は拒否されます）。そしてskills、plugins、capability_directoriesを通じて事前定義された機能をロードできます。
• アウトバウンドネットワーク制御：設定でnetworkを明示的に宣言しない場合、サンドボックスはデフォルトで外部へのアウトバウンドアクセスを許可します（enabled）。ネットワーク権限を絞り込みたい場合は、network.accessをdisabled（アウトバウンド接続を完全禁止）またはrestricted（制限付きアウトバウンド）に設定できます。restrictedモードでは、allowed_domainsに1〜100個の正確なホスト名を設定する必要があります（例：api.example.com。ワイルドカード、プロトコルヘッダー、パス、ポートはサポートされておらず、各サブドメインやリダイレクト先を個別にリストする必要があります）。なお、マネージドstdio MCPサーバーは現時点でネットワークモードがenabledである必要があります。
• バックグラウンド実行メカニズム：クライアントのイベントストリーム接続を切断しても、サンドボックス内で実行中のタスクはキャンセルされません。

顧客の声（リリースノート上のカスタマーコメント）

リリースノートの中で、OpenAIは8社のアーリーアダプターによるコメントを公開しています。そのうちCiridae、Hypha、SafetyKitは移行前後の定量的指標を提示し、その他のチームはそれぞれのシナリオにおけるエンジニアリング体験を共有しています：

• Ciridae（Jack Weissenberger氏、CTO）· Subagentワークフロー（具体的な業務内容は未詳）：ベンチマークスコアが0.71から0.85に向上し、レイテンシは従来の1/4に低下。Subagentストリームがすぐに利用でき、従来行っていたSubagentのオーケストレーションや可観測性の自前運用の負担が大幅に軽減された。
• Hypha（Serhii Shchoholiev氏、Lead Engineer）· 金融サービス：金融サービス分野では、顧客の信頼を獲得することが極めて重要。ハーネスとサンドボックスを疎結合にしたことで、Agentの応答失敗が86%減少し、本番環境で運用する上での顧客の安心感が高まった。
• SafetyKit（Bhavyansh Sabharwal氏、Member of Technical Staff）· ケースレビュー業務（Case review）：ケースレビュー業務をAgents APIに移行した結果、1案件あたりのコストが60%削減され、レイテンシが短縮し、トークン効率が顕著に改善される一方で、成果の品質は同等を維持できた。
• WithCoverage（Cole Striler氏、Director of Engineering）· 複雑なマルチステップワークフロー：従来はプロンプトチェーンの作成やツール呼び出しの自前管理が必要だったが、ノートPC上でCodexを実行するのと同じように、コード内でAgentを直接利用できるようになった。自前でAgentインフラを構築しなければならなかった複数の課題が解消された。
• Dwelly（Dmitry Khanukov氏、Co-founder & CTO）· バースト型ワークロード：テストで最も際立っていたのは、突発的な負荷を処理する能力。数百のAgentにタスクを分散して非同期で実行させ、後から結果を回収できるため、業務ピークの合間にインフラをアイドル状態で稼働させ続ける必要がなくなった。
• deepsense.ai（Maks Operlejn氏、Senior ML Engineer）· 実リポジトリにおけるエンジニアリングタスク：Agentは、実際に稼働しているアクティブなリポジトリにおいて機能実装、独立レビュー、不具合修正、さらには実ブラウザによる検証を完遂し、エンジニアリング全体の品質において極めて力強い成果を示した。
• Nash.ai（Aziz Alghunaim氏、Co-founder & CTO）· グローバル物流配送スケジューリング：数億件に及ぶ配送を管理するため、長期稼働する数千のAgentをデプロイ。Agents APIが永続セッションとオーケストレーション層（コンテキスト管理、リカバリ、マルチステップ実行を担当）を提供し、Nash独自の実世界接続ツールおよび実行環境と組み合わせることで、Agentが数時間または数日間にわたり協調と自己修復を継続できるようになった。
• Long Lake（Rasmus Wissmann氏、CTO）· 業界横断型AIプラットフォーム（Nexus）：Agents APIがハーネスを提供しつつ、環境、コンテキスト、インタラクション体験は企業側が制御し続ける。Nexusプラットフォームにより、住宅サービスから建築設計に至る多様な業界において、わずか数時間でAgentを立ち上げることが可能となった。

料金体系と技術的制約

Agents APIを実際の業務に導入する前に、その費用構成と現段階における技術的制約を明確に把握しておく必要があります。

料金構成

リリースノートによると、Agents API自体には追加費用は発生せず、Agentが実際に消費したトークンとツールに対してのみ課金されます。各単価は料金ページに記載されています：

• モデルトークン費用：選択したベースモデルの標準APIレートに従って課金されます。サンプルで示されたgpt-6-astra（ショートコンテキスト価格）を例にとると、未キャッシュ入力が$10.00 / 1Mトークン、キャッシュ済み入力が$1.00、キャッシュ書き込みが$12.50、出力が$50.00です。ロングコンテキストの価格はさらに高くなります（入力$20.00、キャッシュ入力$2.00、キャッシュ書き込み$25.00、出力$75.00）。（注：料金表にあるgpt-5.6-solに着目すると、入力は$4.00 / 1M、出力は$20.00 / 1Mですが、この価格はプロモーション料金であり、少なくとも2026年11月21日まで継続されます。また現行の公式資料ではAgents APIがこのモデルをサポートしているかは確認されていません）。
• 組み込みツールの呼び出し費用：組み込みウェブ検索は1,000回呼び出しあたり$10.00で、検索コンテンツによって導入されるトークンは選択したモデルの入力レートに応じて別途課金されます。（注意：料金表のファイル検索（File search）ツールの呼び出し費用はResponses APIにのみ適用され、Agents APIには適用されません）。
• コンテナコンピュート料金（OpenAIマネージドサンドボックスにのみ適用）：
  • 1 GB構成：$0.03 / 20分
  • 4 GB構成：$0.12 / 20分
  • 16 GB構成：$0.48 / 20分
  • 64 GB構成：$1.92 / 20分 料金ページにはGBがどのリソースを指すのか、マネージドサンドボックスがデフォルトでどのティアを使用するのかについての記載はありません。対象（Eligible）となるコンテナセッションは分単位で課金され、1セッションあたりの最低課金時間は5分です。OpenAIのコンテナ料金はマネージドサンドボックスにのみ適用され、セルフホストまたはパートナーのサンドボックスを使用する場合、計算リソースの費用は利用者自身またはプロバイダーが負担します。

技術およびコンプライアンス上の制約

公式開発者ドキュメントによると、現行バージョンには以下の明確な境界と制約が存在します：

• データレジデンシーおよびゼロデータ保持（ZDR）の制約： 開発者ドキュメントには、Agents APIは現時点で米国データレジデンシー（US data residency）のみをサポートし、ゼロデータ保持（Zero Data Retention, ZDR）には非対応であることが明記されています。セルフホストサンドボックスを選択したとしても、ZDR要件を満たすことにはなりません。 編集部の見解：これは、セッション状態の管理、オーケストレーション、ハーネスのスケジューリングが依然としてOpenAIクラウドに集中しているためです。ビジネス上ZDRが必須要件である場合、ドキュメントではResponses APIの一部の機能（store=falseを併用したサーバーサイド圧縮、プログラムによるツール呼び出しなど）がZDRワークフローをサポートしていると述べられていますが、ZDRは事前に組織またはプロジェクト単位で有効化しておく必要があります。米国以外のデータレジデンシーが求められる場合、提供資料にはAgents APIの代替手段は提示されていません。
• サンドボックスのライフサイクルと1時間のアイドルクリーンアップ： OpenAIマネージドサンドボックスのドキュメントによると、接続中のサンドボックスは自動的にキープアライブ信号を受信します（ターンの合間も同様）。サンドボックスのアクティビティとキープアライブ信号の両方が1時間停止すると、サンドボックスは削除される可能性があります（このタイムアウト時間はカスタマイズ不可）。したがって、永続化が必要なファイルは必ず/workspace/outputsディレクトリに保存しなければなりません。このディレクトリ配下のファイルはターン完了時に不変の成果物として公開され、サンドボックスの期限切れ後も引き続きダウンロード可能です。
• セッション削除時の409コンフリクト： サンドボックスの初期化中またはコマンド実行中にSDKのclient.beta.agents.sessions.deleteを呼び出すと、HTTP 409 Conflictが返される場合があります。本番環境のコードにはリトライメカニズムを組み込み、最大試行回数を設定しておく必要があります。また、イベントストリーム接続を切断しても、バックグラウンドタスクがキャンセルされるわけではありません。

導入選定と実践チェックリスト

環境選定のアドバイス（開発者ドキュメントに基づき編集部整理）

Agentの実行環境を選定する際は、以下の基準に照らし合わせて検討してください：

1. コンプライアンスの厳格な要件評価：業務シナリオでゼロデータ保持（ZDR）が必須とされている場合、またはデータを必ず米国外に保持しなければならない場合、現時点ではAgents APIを採用できません。ZDRが必要な場合は、Responses APIでZDRをサポートするワークフローの利用を検討してください（組織またはプロジェクトで事前にZDRを有効化する必要があります）。米国外のデータレジデンシーが必要な場合、資料には代替策は示されていません。
2. 迅速な検証と低メンテナンスコストを追求する場合：OpenAIマネージドサンドボックス（OpenAI-hosted）を優先的に選択してください。公式がLinux環境を自動的にプロビジョニングし、restrictedまたはdisabledによるアウトバウンドネットワークポリシーの厳格化をサポートしています。制御されたネットワークポリシーを導入するからといって、必ずしもサンドボックスを自作する必要はありません。
3. 専用のコンピュートリソース、特定のカスタムイメージ、または社内ネットワークアクセスが必要な場合：セルフホストサンドボックス（Self-hosted）またはエコシステム・サンドボックスパートナー（Sandbox Partners）を選択してください。特定のシステム依存関係のカスタマイズ、専用GPUリソースの利用、プライベートストレージのマウント、あるいは独自のVPC内部への配置が必須となるユースケースに適しています。

本番稼働前チェックリスト（Checklist）

Agents APIを本番環境に接続する前に、公式仕様に沿って以下の項目を1つずつ確認することをお勧めします：

• [ ] キー権限と環境の分離：
  • メインアプリケーションのAPIキー（api.agents.read/writeおよびapi.responses.write権限が必要）は、サンドボックス環境の外部に安全に保持されているか。
  • セルフホストサンドボックスには制限付き環境キーCODEX_API_KEYのみを付与し、プラットフォーム作成時に他の権限をすべてNoneに設定して、環境接続権限のみを保持させているか。
  • ユーザー別、またはワークロード別に実行環境を厳格に分離し、共有環境内でのファイルや認証情報の漏洩を防止しているか。
• [ ] アウトバウンドネットワークポリシーの絞り込み：
  • OpenAIマネージドサンドボックスを使用する際、networkを明示的に設定しない場合、システムはデフォルトで外部へのアウトバウンドアクセスを許可する。絞り込みが必要な場合は、自発的にdisabledまたはrestrictedを設定しているか。
  • restrictedモードでは、allowed_domainsに正確なホスト名を1つずつ設定しているか（1〜100個、ワイルドカード不可、リダイレクト先もリストアップが必要）。
  • 注意：マネージドstdio MCPサーバーは現時点でネットワークをenabledに設定しておく必要がある点に留意しているか。
• [ ] 成果物の永続化：
  • タスクで生成されるコアデータ、レポート、コードファイルは、/workspace/outputsディレクトリへの書き込みが明確に指示されているか。このディレクトリの内容はターン完了時に不変の成果物として固定され、サンドボックスのアイドル削除によるデータ消失を防げる。セッション削除APIを呼び出す前に、必要なファイルをダウンロードしているか。
• [ ] マルチAgentメカニズムの適合：
  • タスクの分解が相互に独立した作業であることを確認したか。複数のSubagentがサンドボックスを共有する場合、同一ファイル群を変更する際の明確な協調順序を設計しているか。
  • SubagentはMCPツールやウェブ検索を継承するが、通常の関数ツール（function tools）はサポートしていない点に対応しているか。
• [ ] 例外および切断時の耐障害性処理：
  • イベントストリームでturn.completed、turn.failed、turn.cancelled、session.failedをリッスンしているか。turn.completedは各ツール呼び出しの成功を保証するものではないため、Agentが報告した実際の実行結果を確認する必要がある点、単にagent.session.idleを受信しただけではタスク成功を意味しない点に注意しているか。
  • イベントストリームが予期せず切断された場合、ドキュメントの指示に従って「セッションおよび保存されたitemsを取得」して状態を回復し、むやみにセッションの新規作成を繰り返さないようにしているか。

パブリックベータと利用開始方法

Agents APIは現在、すべての開発者に向けてパブリックベータ（Public Beta）として提供されています。ベータ期間中、OpenAIは開発者からのフィードバックをもとに迅速な反復改善を行い、正式版（GA）へと進める予定であり、その過程でAPIインターフェースに変更が加えられる可能性があります。

Agents APIの利用に追加のプラットフォーム費用はかからず、開発者はモデルトークン、使用した組み込みツール、およびマネージドサンドボックスのコンテナコンピュートリソースに対してのみ費用を支払います。

開発者は公式ドキュメントを参照してさらに理解を深め、利用を開始できます：

• アーキテクチャ全体とコアコンセプトを理解するには、Agents APIの概要（overview）をご覧ください。
• 最初のAgentセッションを実行するには、クイックスタート（quickstart）に従ってください。cURLでリクエストを発行する場合、リクエストヘッダーにOpenAI-Beta: agents=v1を明示的に追加する必要があります（公式SDKは自動的にこのヘッダーを付与します）。メインアプリケーションのAPIキーにはapi.agents.read/writeおよびapi.responses.writeの権限が必要です。