OpenAI Agents APIとは？Codexハーネスを使えるクラウドエージェント基盤の機能・料金・Agents SDKとの違い【2026年9月最新】

OpenAI Agents APIは、Codexを動かしている「Codexハーネス」を、OpenAIが運用するマネージドAPIとして開放したものです。 公式ドキュメントの定義は「The Agents API gives your application access to the Codex harness through an OpenAI-managed API.」であり、セッション・オーケストレーション・コンテキストの圧縮・リカバリをOpenAI側が持ち、開発者はツールと実行環境（サンドボックス）だけを用意します。2026年9月10日にパブリックβとして、全API開発者向けに公開されました。

Agents API自体の利用料は追加料金なし（$0）で、課金されるのはモデルのトークン料金・OpenAI組込ツールの料金・OpenAIホスト型サンドボックスのコンテナ料金の3つだけです。一方で、現時点ではデータ所在地が米国のみ・Zero Data Retention（ZDR）非対応という明確な制約があり、ここが日本企業の採用可否を分ける最大の分岐点になります。

この記事でわかること

• Agents APIの正体（Codexハーネスのマネージド提供）と4つのコア概念
• パブリックβで使える機能（自動コンパクション／サブエージェント／ステアリング／MCP）
• 3つの実行環境（none / openai_hosted / self_hosted）の選び分け
• 「追加料金なし」の内訳と、1セッション単価・月額の実額試算
• Agents SDK / Responses API との使い分け
• 米国限定・ZDR非対応をはじめとする制約と、運用上の落とし穴
• セキュリティ設計で最低限やるべきこと（環境キーの分離など）

想定読者: 自社プロダクトに長時間稼働のAIエージェントを組み込みたい開発者・技術責任者、Agents SDKから移行すべきか判断したいエンジニア、コストと情報管理の両面から導入可否を決めたい情報システム部門の方。

OpenAI Agents APIとは — 基本情報の整理

出典: OpenAI 公式ドキュメント「Agents API overview」

Agents APIは、「エージェントを動かし続けるための土台（ハーネス）」をOpenAIが代わりに運用してくれるAPIです。モデルを呼ぶだけのAPIではなく、セッションを保持し、コンテキストが溢れそうになれば自動で要約し、中断地点から再開できるところまでがサービス側の責任範囲に入っています。

公式ドキュメントで示されている責任分界点は明確です。

• OpenAIが管理するもの: セッション / オーケストレーション / コンテキストのコンパクション（圧縮） / リカバリ
• 開発者が用意するもの: ツール / 実行環境（サンドボックス）の選択

つまり「エージェントループを自前で書くか、OpenAIに任せるか」という選択であり、機能の優劣ではなく運用責任をどこに置くかの選択だと理解するのが正確です。

AIエージェントという概念そのものの整理は「AIエージェントとは？仕組み・種類・活用例をわかりやすく解説」で扱っています。

「Codexハーネス」とは何か — なぜハーネスが重要なのか

出典: OpenAI 公式GitHubリポジトリ openai/codex

ハーネス（harness）とは、モデルの周りでプロンプト整形・ツール呼び出し・コンテキスト管理・リトライ・再開を担う実行層のことです。同じモデルを使っても、ハーネスの設計次第で結果が大きく変わるというのが、OpenAIがAgents APIを出した前提にあります。

OpenAIの開発者ブログ「Codex as a platform」では、推論の保持とコンテキストコンパクションを適用した結果、ARC-AGI-3におけるGPT-5.6 Solのスコアが13.3%から38.3%へ向上し、出力トークンは約6分の1になったと報告されています。エージェントの精度・コストは、モデル選定と同じかそれ以上にハーネス設計に左右される、という主張です。

Codexハーネス自体はgithub.com/openai/codexでオープンソース公開されており、Codex CLI / app-server / Codex SDK も同様です。ただし同ブログでは「OSSなのはハーネスと統合面であって、モデルアクセスとマネージドサービスは別」と明記されています。Agents APIは、そのOSSハーネスを自分でホストせずにAPI経由で叩ける形にしたものと捉えると整理しやすいはずです。

Codex本体の位置づけについては「OpenAI Codexとは？ChatGPTアプリ統合の使い方・料金・旧APIとの違い」を参照してください。チーム共有での使い方は「ChatGPT workspace agentsとは？Codex搭載チーム共有AIエージェント」で扱っています。

4つのコア概念とターンの流れ

出典: OpenAI 公式ドキュメント「Agents API overview」

Agents APIを理解するうえで最小限おさえるべきなのは、公式Overviewに挙げられている4つの概念です。

ターン（Turn）という単位

セッション内の1サイクルの作業をターンと呼びます。動作は以下のようになります。

1. エージェント設定を指定してセッションを作成する
2. 環境の準備完了を確認し、最初のタスクを投入する（ここで1ターン目が始まる）
3. 進捗をストリーミングまたはWebhookで受け取る
4. アイドル中のセッションにメッセージを送ると新しいターンが始まる
5. 作業中にメッセージを送ると、走っているターンを「ステアリング（軌道修正）」できる

ターンは非同期で実行されるため、レスポンスを待ち続ける必要はありません。この「走っている最中に方向を変えられる」点が、1リクエスト1レスポンスで完結する従来型のAPIとの体験差になります。

Agents APIでできること — パブリックβ時点の機能

マネージドハーネスとして提供される機能を、公式Overviewの記載ベースで整理します。

サブエージェント（マルチエージェント）の仕様

agent.multi_agent.enabled = true で有効化します。サブエージェントの作成・メッセージ送信・待機・中断のためのツールはハーネス側が自動供給するため、自分で定義する必要はありません。

• max_concurrent_subagents の既定値は6（コーディネーターを除く）
• サブエージェントはそれぞれ独自のコンテキストを持ち並列実行される
• 環境がある場合、コーディネーターとサブエージェントはファイルシステムを共有する（サブエージェントを作っても環境が増えるわけではない）
• 無効化するには multi_agent を省略するか、enabled: false かつ上限を省略する

公式の推奨は「独立したタスクに使う」ことです。別文書のレビュー、障害の別原因の調査などが該当します。逆に短いタスクや依存関係のあるステップはメインエージェントに残すべきで、同じファイルを編集するエージェント同士は調整が必要になります。

なお、Codex側のサブエージェント文書には「既定値3」という記述が見られますが、これは別プロダクトの話です。Agents APIとして扱うなら6が正しい値です。

並列エージェントの設計論そのものは「マルチエージェントAIとは？仕組み・活用事例・フレームワーク・導入判断まで徹底解説」で整理しています。MCPの仕組みは「MCPとは？仕組み・できること・対応ツール・セキュリティを総合解説」、スキルとMCPを束ねる規格については「Agent Plugins 1.0.0とは？MCPとAgent Skillsを束ねる新標準」を参照してください。

エージェント設定の再利用

client.beta.agents.create() で設定を保存し、セッション作成時に agent_id で指定できます。agent_id と agent を併記すればそのセッションだけ設定を上書きでき、省略した項目（モデルを含む）は保存済み設定から継承されます。共通の社内エージェント定義を1つ持ち、用途ごとに差分だけ渡す運用が可能です。

3つの実行環境（サンドボックス）と選び方

Agents APIでは environment.type に3つの値のいずれかを指定します。ここが最初に決めるべき設計判断です。

重要な前提として、ハーネス自体は常にOpenAI側で動きます。セルフホストで自社側に移るのは「サンドボックス（実行環境）」であってハーネスではありません。ここを誤解すると、データ所在地やZDR要件の判断を間違えます。

選び分けの判断基準

self_hosted を選ぶ場合、プロビジョニング・再接続・停止・ファイル保全はすべて自己責任になります。公式ドキュメントには、Blaxel / Cloudflare / Daytona / DigitalOcean / E2B / Modal / Oracle Cloud Infrastructure（OCI）/ Runloop / Vercel の9社についてプロバイダ別ガイドが用意されています（各社側の料金は各社ページを確認してください）。

OpenAIホスト型サンドボックスの主な設定項目

ネットワークアクセス制御

restricted は1〜100件の完全一致ホスト名で指定します。ワイルドカード・プロトコル・パス・ポートは使えず、サブドメインとリダイレクト先は別途登録が必要です。ここは実装時に最もハマりやすい箇所で、「許可したつもりのドメインでリダイレクト先が弾かれる」事故が起きやすい仕様です。なお、ホスト型のstdio MCPサーバーは現状 enabled が必要とされています。

料金 — 「追加料金なし」の内訳と実額試算

Agents APIそのものの利用料は無料です。 課金されるのは次の3つに限られます。

コンテナレート（Hosted Shell / Code Interpreter）

公式Pricingページに記載のレートは以下です（コンテナ1台・20分セッションあたり）。

対象セッションは分単位課金・1セッションあたり最低5分です。GBは2^30バイト（gibibyte）基準。なお、Agents APIのOpenAIホスト型サンドボックスがどのメモリ階層で課金されるか（既定がどれか）は公式ドキュメント上で確認できていないため、試算は4GBを仮置きしています。

組込ツール・モデルの料金

• Web検索: $10.00 / 1,000コール ＋ 検索コンテンツトークンはモデルレートで課金
• 主要モデル（Standard・100万トークンあたり）

Batch / Flex はStandardの約半額、Fast modeは約2倍です。また、データレジデンシー対応リージョン経由は10%上乗せ（2026年3月5日以降リリースのモデル）となります。

公式ドキュメントのサンプルコードは全言語で gpt-6-astra を使用しています。Agents APIで利用可能なモデルの完全な一覧は現時点のドキュメントに明記がないため、他モデルが使えるかどうかは断定できません。試算はすべて gpt-6-astra を前提としています。

1セッションあたりの実額試算

「追加料金なし」という言葉だけでは予算が立たないため、典型的なワークロードで金額を出します。

前提: 入力10万トークン（うち70%がキャッシュヒット）・出力2万トークン・4GBコンテナを10分使用・Web検索2コール

月間セッション数別の目安

この試算から読み取るべきポイントは2つあります。

1. コンテナ料金は全体の約4%にすぎない。 話題になりやすい「サンドボックス代」より、コストの大半はモデルの出力トークンです。
2. 最も効くコスト最適化は、出力トークン削減とキャッシュ活用。 推論の深さを必要なタスクだけに絞る設計が直接効きます。

推論の深さとコストのトレードオフは「GPT-6 Astraのreasoning effort設定ガイド」、モデル自体の位置づけは「OpenAI Astraとは？次期メジャーモデルの正体」で扱っています。主要モデルの単価横比較は「生成AI料金比較【2026年最新】」を参照してください。

Agents SDK / Responses API との違いと使い分け

出典: OpenAI 公式GitHubリポジトリ openai/openai-agents-python

3つは上位互換の関係ではありません。公式の比較ドキュメントが示しているのは、「エージェントのオーケストレーションをどこで動かすか」の選択です。

選び分けの目安は次の通りです。

• Agents APIを選ぶ: 数分〜数時間かかるタスクを走らせたい／エージェントループの実装と保守をやりたくない／コンテキスト管理を任せたい
• Agents SDKを選ぶ: エージェントの挙動・承認フロー・ツール実行を自社で完全に制御したい／デプロイ先やデータ経路を自社で決めたい／ZDRやデータレジデンシーの要件がある
• Responses APIを選ぶ: 単発の推論が中心で、エージェント的なループが不要／自前のオーケストレーション基盤がすでにある

実務的には、「ZDR・データ所在の要件があるならAgents SDK側に残す」というのが2026年9月時点で最も明確な分岐です。

Agents SDK側の最新仕様（sandbox・subagents・code mode）は「OpenAI Agents SDK 新ハーネスとは？sandbox・subagents・code modeの使い方」で詳しく解説しています。

他社のマネージドハーネスとの位置づけ

「ハーネスをベンダーに任せる」という発想はOpenAI固有のものではありません。選定時には横並びで見ておくと判断しやすくなります。

データ所在やコンプライアンス要件が厳しい場合、現時点ではAWS側の選択肢のほうが社内説明がしやすい、というケースは十分あり得ます。

使い始めるまでの流れ

出典: OpenAI 公式ドキュメント「Agents API quickstart」

パブリックβのため詳細は変わり得ますが、現時点の基本フローは次の通りです。

1. APIキーの権限を確認する — api.agents.read / api.agents.write / api.responses.write（Vaultを使うならapi.vaults.read / api.vaults.writeも付与）
2. βヘッダーを付ける — OpenAI-Beta: agents=v1。公式SDKを使えば自動で付与される
3. エージェント設定を決める — モデル・instructions・ツール・MCPサーバー。再利用するなら client.beta.agents.create() で保存
4. 実行環境を選ぶ — none / openai_hosted / self_hosted。ホスト型ならpackages・setup_commands・network.accessを設定
5. セッションを作成する — POST /v1/agents/sessions。名前空間は client.beta.agents.sessions.*
6. 環境の準備完了を確認してからタスクを投入する
7. 進捗を受け取る — ストリーミングで追うか、Webhookで状態変化を受ける
8. 結果とアーティファクトを回収する — /workspace/outputs 配下がターン完了時に成果物として公開される
9. ダッシュボードで検証する — platform.openai.com/logs?api=agents でセッションID検索・ターン・ツール呼び出し・サブエージェントを確認

setup_commands の終了ステータスが0以外だとエージェントが起動しないため、初回構築時はここでつまずくケースが多くなります。ログを見ながら1コマンドずつ固めるのが安全です。

セキュリティ設計で最低限やるべきこと

公式の「Sandbox security」ガイドは、エージェントが生成したコードは、その環境で参照できるファイル・認証情報・ネットワークにすべてアクセスできるという前提から始まっています。これは「AIが悪意を持つか」ではなく、「生成されたコードが何を読めるか」という設計の話です。

1. ワークロードを分離する

• VMなど隔離されたコンピュートで実行する
• データを共有してはいけないユーザー／ワークロード同士は環境を分ける
• アプリ専用のOpenAIプロジェクトを作る

2. ネットワークを絞る

• 承認済みエンドポイントのみにアウトバウンドを許可する（network.access: restricted）
• executor MCPは自社環境から、リモートMCPはOpenAI側から接続される。接続元が違うので、ファイアウォールの許可設計を分けて考える
• allowed_domains はワイルドカード不可・完全一致。サブドメインとリダイレクト先は別途登録する

3. 認証情報を分離する（最重要）

公式は、環境キーは環境の接続しか許可せず、他のAPI操作を認可しないと明記しています。そしてエージェントが生成したコードは環境キーを読めることを前提に設計すべきだとしています。つまり、アプリ用APIキーを環境内に置いた時点で、それはエージェント生成コードに読まれる可能性のある情報になります。イメージ・ソース・ログにキーを埋め込まないことも合わせて必須です。

4. サードパーティの秘密情報はブローカー経由にする

シークレットマネージャに保管していても、環境に注入した時点でエージェント生成コードに露出します。公式が案内しているのは、秘密情報を環境の外に置き、承認済みの送信リクエストにだけシークレットを注入するクレデンシャルブローカーを挟む構成です。

5. 「完了したターン」を成功と見なさない

公式は「完了したターン ＝ すべてのツールが成功した」ではないと明記しています。agent.session.turn.completed / failed / cancelled を必ず確認し、加えて出力そのものを検査する必要があります。

エージェント運用のリスク全体像とチェックリストは「AIエージェントのセキュリティ対策｜リスクの全体像と実務で使えるチェックリスト」、実際に起きた事故から学ぶ隔離の重要性は「AIエージェントがデータを全削除した事故まとめ」で扱っています。

制約と運用上の落とし穴

パブリックβであり、できないことも明確に文書化されています。採用判断では、機能の多さよりも制約の把握が先に来ます。

導入可否を左右する最大の制約：米国限定・ZDR非対応

公式ドキュメントの原文は次の通りです。

The Agents API currently supports data residency only in the United States and does not support Zero Data Retention (ZDR).

さらに、セルフホスト型サンドボックスを選んでもZDR対象にはなりません（"Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible."）。理由は明快で、サンドボックスを自社に置いてもハーネスはOpenAI側で動いているためです。

したがって、以下に当てはまる組織は2026年9月時点では採用が難しいと考えるのが妥当です。

• ZDRが契約要件になっている
• EU・日本国内でのデータレジデンシーが必須
• 金融・医療・行政など、処理データの所在地に規制上の制限がある

逆に、機微データを扱わない用途（公開情報の調査、社内の非機密ドキュメント整形、OSSコードの改修など）であれば、この制約は実質的な障害になりません。

その他の主な制約

• トレースの取得APIや外部トレースエクスポーターは、パブリックβのAPIに含まれない（ダッシュボードでの確認のみ）
• environment.type: "none" では、組込のBashツール・apply-patchツール・ワークスペースのファイル・executor MCPが使えない
• サンドボックスは活動とキープアライブが1時間止まると削除され得る。このタイムアウトは設定不可
• セルフホスト環境のファイルは、/workspace/outputs 配下であってもArtifacts APIでは公開されない
• アーティファクトは一括ダウンロード不可（1リクエスト1ファイル）。アップロード・編集も不可。公式にはZIPにまとめさせる回避策が案内されている
• レートリミット・同時セッション数の上限は、現時点の公式ドキュメントでは確認できていない

ファイル関連の上限

実装前に把握しておきたい落とし穴

• イベントストリームを閉じてもタスクはキャンセルされない — 止めたいなら明示的にキャンセルする
• セッション削除が実行中だと409を返すことがある — リトライ制御を前提に実装する
• Function toolのハンドラが応答しないと、エージェントは結果待ちのまま停止し得る — タイムアウトを必ず設ける
• setup_commands が非0終了するとエージェントは起動しない — 初期化コマンドの失敗ハンドリングを固める
• none では組込Bashが使えない — 「コードを実行させたいのに動かない」原因の大半はこれ
• restricted のドメイン許可はリダイレクト先を別登録 — 外部APIのCDN・認証ドメインを忘れない
• サンドボックスは1時間の無活動で消え得る — 長時間の待ちが入る設計なら成果物を早めに退避する
• 環境テンプレートより緩いネットワークポリシーには上書きできない — テンプレートは最も緩い側を基準に設計する

発表時に公開された導入事例

2026年9月10日の発表に合わせて、いくつかの導入企業の成果が紹介されています。以下は公式発表ページの内容を二次ソース（MarkTechPost等）経由で確認した、発表時点の各社報告値です。測定条件は公開されていないため、参考値として扱ってください。

共通しているのは「エージェントの精度そのもの」より、失敗率・レイテンシ・単価といった運用指標の改善が語られている点です。マネージドハーネスの価値は、賢さよりも安定稼働にある、という整理と一致します。

こんな人・こんなチームにおすすめ

以下に当てはまるなら、パブリックβの段階から触っておく価値があります。

• エージェントループの実装・保守に時間を取られている開発チーム — セッション管理・コンパクション・再開を自作している場合、その保守コストをまるごと外せる
• 数分〜数時間かかる長時間タスクをプロダクトに組み込みたいケース — レポート生成、コードベースの一括改修、大量文書のレビューなど
• すでにCodexを使っていて、同じ挙動をAPIから呼びたいチーム — ハーネスが同一なので挙動の予測がつきやすい
• 並列調査・並列レビューを設計したいチーム — サブエージェントがハーネス側から供給されるため、オーケストレーションを書かずに済む
• 機微データを扱わない業務から自動化を始めたい企業 — 公開情報の調査、社内の非機密文書の整形など
• PoCを最短で回したいチーム — 統合の手間が「低」に分類されており、初期実装の速度が出る

開発プロセス全体をエージェント前提に再設計する考え方は「エージェンティックエンジニアリングとは？」で扱っています。

現時点では見送ったほうがよいケース

• ZDRが契約・社内規程上の必須要件になっている組織 — セルフホストサンドボックスでも要件を満たせない
• EU・日本国内のデータレジデンシーが必須の企業 — 現時点で対応リージョンは米国のみ
• 金融・医療・行政など、処理データの所在に規制がかかる業務 — 少なくとも本番の機微データ処理には現状使えない
• 外部トレース基盤（OpenTelemetry等）への出力が監査要件になっている組織 — トレース取得APIとエクスポーターはβのAPIに含まれない
• エージェントの挙動・承認フローを完全に自社制御したいチーム — Agents SDKやResponses APIのほうが目的に合う
• 仕様変更を吸収する余力がないプロジェクト — パブリックβであり、料金・上限・機能は短期で変わり得る
• コストの上振れを許容できない固定予算の案件 — 出力トークン主導の従量課金であり、エージェントの試行回数がそのまま金額に反映される

今後チェックすべき項目（定点観測リスト）

パブリックβである以上、仕様変更が前提です。2026年9月13日時点で未発表・未確認の項目を挙げておきます。導入検討中なら、2〜4週間おきに公式ドキュメントで以下を確認することを推奨します。

よくある質問

Q. Agents APIを使うと、追加のサブスクリプション契約が必要ですか？

いいえ。Agents API自体の利用料は発生せず、既存のOpenAI APIアカウントとAPIキー（適切なスコープ付き）があれば利用できます。請求されるのはモデルのトークン料金、組込ツールの料金、OpenAIホスト型サンドボックスのコンテナ料金です。

Q. Codexとは何が違うのですか？

Codexは製品、Agents APIはその製品を動かしているハーネスへのAPIアクセスです。同じハーネスを使うため挙動は近いものの、Agents APIは自社アプリケーションに組み込む前提で、セッション・ツール・環境をコードから制御します。

Q. 自社サーバー上でサンドボックスを動かせば、データはOpenAIに渡らないのですか？

渡ります。セルフホストで自社側に移るのはサンドボックス（実行環境）だけで、ハーネス自体は常にOpenAI側で動作します。公式も「セルフホストサンドボックスを選んでもAgents APIはZDR対象にならない」と明記しています。

Q. サブエージェントは何体まで同時に動きますか？

max_concurrent_subagents の既定値は6です（コーディネーターを除く）。Codexのサブエージェント文書に登場する「3」は別プロダクトの記述なので混同しないでください。

Q. エージェントが作ったファイルは、セッションが終わっても取り出せますか？

OpenAIホスト型サンドボックスの場合、/workspace/outputs 配下のファイルはターン完了時にイミュータブルな成果物として公開され、サンドボックス失効後もダウンロードできます。ただし一括ダウンロードはできず、1リクエスト1ファイルです。セルフホスト環境のファイルはArtifacts APIでは公開されません。

Q. 実行中のエージェントを途中で止めたいときはどうしますか？

イベントストリームを閉じてもタスクはキャンセルされません。明示的にキャンセル操作を行う必要があります。また、実行中にセッション削除を呼ぶと409が返る場合があるため、リトライ制御を実装しておくのが安全です。

Q. どのモデルが使えますか？

公式ドキュメントのサンプルコードは全言語で gpt-6-astra を使用していますが、利用可能モデルの完全な一覧は現時点のドキュメントに明記がありません。採用前に公式ドキュメントで最新の対応状況を確認してください。

まとめ

OpenAI Agents APIは、Codexを動かしているハーネスをOpenAI管理のAPIとして開放したもので、2026年9月10日からパブリックβとして全API開発者が利用できます。セッション永続化・自動コンパクション・ステアリング・サブエージェント・MCP接続といった、エージェントを長時間動かすために必要な仕組みがサービス側に載っており、開発者はツールと実行環境の選択に集中できます。

判断のポイントを3つに絞ると次のようになります。

1. 料金構造はシンプルだが、コストの主役は出力トークン。 API自体は$0、コンテナは4GBで20分$0.12。1セッション約$1.45という試算のうち、コンテナ費は4%程度にすぎません。
2. Agents SDKとの選択は優劣ではなく責任分界の問題。 オーケストレーションをOpenAIに預けるか、自社に残すかで選びます。
3. 米国限定・ZDR非対応が最大の分岐点。 セルフホストサンドボックスでも解消しないため、規制要件のある業務は現時点で見送りが妥当です。

まずは機微データを含まない用途で openai_hosted を試し、コストと挙動の実測値を取ったうえで、本格採用の可否をデータ所在の要件と突き合わせる——というのが、2026年9月時点で最も現実的な進め方です。

次に読むべき記事

• OpenAI Agents SDK 新ハーネスとは？sandbox・subagents・code modeの使い方 — 自社アプリ側でエージェントを動かす選択肢
• OpenAI Codexとは？ChatGPTアプリ統合の使い方・料金・旧APIとの違い — Agents APIの元になっているCodexの全体像
• MCPとは？仕組み・できること・対応ツール・セキュリティを総合解説 — ツール接続の標準規格
• AIエージェントのセキュリティ対策｜リスクの全体像と実務で使えるチェックリスト — 導入前のリスク整理
• Claude Managed Agentsとは？機能・料金・使い方・Messages APIとの違いを解説 — 他社のマネージドハーネスとの比較

参考（一次ソース）

• Agents API 概要: https://developers.openai.com/api/docs/guides/agents-api/overview
• エージェントランタイムの比較: https://developers.openai.com/api/docs/guides/agents
• マルチエージェント: https://developers.openai.com/api/docs/guides/agents-api/multi-agent
• OpenAIホスト型サンドボックス: https://developers.openai.com/api/docs/guides/agents-api/environments/openai-hosted
• サンドボックスセキュリティ: https://developers.openai.com/api/docs/guides/agents-api/environments/security
• ファイルとアーティファクト: https://developers.openai.com/api/docs/guides/agents-api/environments/files
• 料金: https://developers.openai.com/api/docs/pricing
• 開発者ブログ「Codex as a platform」: https://developers.openai.com/blog/codex-as-a-platform