2026年9月10日、OpenAIはAgents APIを正式にパブリックベータ段階へ移行させた。今回のリリースの核心は、OpenAIが長期にわたって社内で使用してきたエージェント実行インフラ——CodexプログラミングエージェントおよびChatGPT Workを支える同一の実行フレームワーク——を外部デベロッパーに直接開放したことにある。このAPIはすべてのデベロッパーへ無償でアクセス資格が付与され、追加のプラットフォームサービス料は発生しない。ユーザーはモデルのトークン消費量、ツール呼び出し、コンテナ実行時間に応じた従量課金のみとなる。
フレームワークが内部から外部へ開放されるまでの経緯
今回のリリースを理解するには、まずOpenAIがこのタイミングでこのインフラを開放する理由を把握する必要がある。OpenAIチームは公式ドキュメントの中で明確に説明している。CodexとChatGPT Workを大規模に運用する過程で、長時間稼働するエージェントに必要な能力について深い知見を蓄積したと。エージェントにはコンテキストを継続的に管理し、ツールを効率的に呼び出し、サブエージェントを協調させる実行フレームワーク、そして数日間にわたって継続稼働できる信頼性の高いインフラが必要とされる。このフレームワークは本番環境での実戦を通じて磨かれたものであり、デベロッパー向け製品として一から設計されたものではない。
Agents APIはオープンソースのCodex実行フレームワークをベースに構築されており、API全体は四つのコア概念を中心に構成されている。エージェント（Agent：モデル、指示、ツールセット、MCPサーバー設定を含む）、環境（Environment：コードの実行、ファイルの読み書き、スキルの読み込みに使用できるオプションのサンドボックス）、セッション（Session：タスクを実行し入力に応答する永続的なエージェントインスタンス）、イベントとアイテム（Events and Items：エージェントへ送信するタスク入力とエージェントが生成する出力）の四つである。セッションの実行は四段階で完了する。セッションを作成してタスクを割り当て、ストリーミングまたはWebhookで進捗を追跡し、タスク完了後に新たなタスクを割り当てるか現在の実行方向を調整する。
公式ドキュメントに掲載されているサンプルコードは、このフレームワークの設計意図を示している。障害調査エージェントが単一のAPI呼び出しで生成され、使用モデルはgpt-6-astraで、最大3つの並行サブエージェントが設定される。各サブエージェントはそれぞれデプロイ分析、エラー分析、依存関係分析を担当し、メインエージェントが結果を集約・調整したうえで、調査結論、証拠、修復提案を指定のワークスペースパスに保存する。
三種類の実行環境、三つのデプロイ上の判断
実行環境の選択において、Agents APIは三種類のサンドボックス構成をサポートしており、サンドボックスなしで直接実行することも可能だ。
一つ目はOpenAIマネージドサンドボックスで、CodexおよびChatGPTと同一のサンドボックスインフラを再利用する。デベロッパーはファイル、パッケージ、スキル、プラグインを設定でき、運用コストをゼロに抑えて迅速に導入したいチームに適している。二つ目はセルフホスト型で、デベロッパーが自社インフラ上でcodex exec-serverを実行し、制限付きキーで登録後にWebSocket経由でプラットフォームと接続する。すべての接続はアウトバウンド方向であり、データはOpenAIのサーバーを経由しない。三つ目はパートナーサンドボックスで、現在Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercelの9社とファーストクラスインテグレーションが確立されており、CPU、GPU、メモリ、ストレージの異なる構成に対応した実行オプションが提供される。
このアーキテクチャ設計は明確なシグナルを発している。OpenAIはエージェントの実行レイヤーを独占しようとしているのではなく、エコシステムパートナーのコンピューティングオプションを公式フレームワークに組み込む意図がある。しかしこれは同時に、デベロッパーがどのサンドボックス構成を選ぶかが、単なる技術的な好みの問題ではなく、データフロー、運用責任、コスト構造に関わるアーキテクチャ上の判断であることを意味する。
長時間稼働に対応する三つの重要なエンジニアリング機能
Agents APIには長時間稼働シナリオに特化した三つのエンジニアリング機能が組み込まれており、これが通常のステートレスなAPI呼び出しとの本質的な差別化ポイントだ。一つ目は自動コンテキスト圧縮で、セッションがトークンウィンドウの上限に近づいた際、システムが早期の情報を自動的に圧縮し、デベロッパーがコンテキストの切り詰めを手動管理することなくエージェントが複数のコンテキストウィンドウを跨いで継続実行できるようにする。二つ目はツール検索とオンデマンドロードで、エージェントは実行中に必要に応じてツール定義をロードし、複数のツール呼び出しを並行実行したり、結果を連鎖させたり、戻り値をフィルタリングしたりすることができ、不要なコンテキスト消費を抑えつつモデルキャッシュを維持する。三つ目はマルチエージェント調整で、デベロッパーは複雑なタスクを複数の独立したサブタスクに分割してサブエージェントに並行処理させることができ、メインエージェントが調整と集約を担う。公式サンプルでは最大3つの並行サブエージェントが設定されているが、実際の数は設定で変更可能だ。
アーリーアクセスユーザーのデータ：コストと信頼性の具体的な改善
OpenAIはリリース時にアーリーアクセスユーザーの実測データを公開した。コンプライアンステック企業のSafetyKitはケース審査ワークフローをAgents APIに移行した結果、1ケースあたりのコストが60%削減された。エージェント開発プラットフォームのHyphaは実行フレームワークとサンドボックスを分離した後、エージェントの応答失敗率が86%低下した。評価企業Cirridaeのエージェントスコアは0.71から0.85に向上し、サブエージェントフローのレイテンシは以前の4分の1に短縮された。物流企業Nash.aiはこれを活用してグローバルネットワーク上で数千の長時間実行エージェントを運用している。
上記のデータはいずれもOpenAIが公開を選択したアーリーアクセスパートナーのケーススタディに基づくものであり、それぞれの垂直領域における最適化結果であって、汎用的なデプロイの期待ベンチマークとして直接外挿することはできない。
明確な現時点の制限：データコンプライアンスのギャップ
Agents APIパブリックベータには現時点で二つの制限がある。データは米国内にのみ保存され、ゼロデータリテンション（Zero Data Retention）はサポートされない。この二点は技術的な細部ではなく、企業の導入判断に直接影響するコンプライアンス上の閾値だ。
ゼロデータリテンションは多くのエンタープライズ向けAI調達契約の標準要件であり、OpenAI Enterpriseプランの主要な売りの一つでもある。Agents APIパブリックベータがこの機能を暫定的に欠いていることは、金融、医療、政府機関、および欧州・アジア太平洋地域のデータコンプライアンスに敏感な企業ユーザーが、パブリックベータ段階においてコンプライアンス適合の利用可能範囲から実質的に除外されることを意味する。こうしたユーザーにとって現時点で唯一実行可能な回避策はセルフホスト型の選択だが、セルフホスト型は企業がcodex exec-serverのデプロイと運用コストを自ら負担することを意味し、「マネージドサービスによる運用負担の軽減」という核心的な訴求を部分的に相殺することになる。
競争環境：三大クラウドベンダーのマネージドエージェントプラットフォームとの比較
OpenAIがこの製品を投入するのは空白市場ではない。AWS Bedrock AgentCore、Azure AI Foundry Agent Service、Google Vertex AI Agent Engineはいずれも2025年末から2026年第1四半期にかけて順次一般提供（GA）のマイルストーンに到達しており、三社はそれぞれ独自のマネージドエージェントランタイム製品を構築済みだ。
三社のマネージドエージェントプラットフォームにはそれぞれポジショニングの差異がある。AWS Bedrock AgentCoreは認証と権限管理をランタイムのファーストクラス機能として位置づけており、各エージェントはIAMまたはOAuthで身元をバインドでき、セキュリティ認証情報の保管庫がトークンを自動ローテーションする。AWSエコシステムにすでに深く統合された企業に適している。Google Vertex AIの強みはGeminiとのネイティブな深い統合、およびBigQueryなどデータウェアハウスとの自然な連携にあり、GCPネイティブでデータ集約型のワークロードに適している。Azure AI Foundryの強みはMicrosoftエンタープライズソフトウェアエコシステムとの親和性、および欧州の規制コンプライアンス対応の成熟度にある。
OpenAI Agents APIの参入ロジックは上記三者とは異なる。特定のクラウドプラットフォームに依存せず、モデルとインフラを一体化したフルスタックのマネージドサービスを提供する。デベロッパーが使用するのはOpenAIのモデル、OpenAIがメンテナンスするCodexフレームワーク、そしてOpenAIまたはパートナーが提供するサンドボックス環境だ。この設計は使いやすさの面で明確な優位性を持つ——OpenAIモデルをコア技術として選択しているチームにとって、プロトタイプから本番環境のエージェントに至るまでの道のりが最も短い。しかし同時に、コアの依存関係が単一ベンダーに高度に集中することを意味し、ベンダーロックインのリスクは相対的に高い。
それに対してAWSとGoogleのマネージドエージェントサービスはより「モデル非依存」のポジショニングを志向しており、いずれも複数のモデルプロバイダーの接続をサポートしている。データ主権、IAM権限、ローカルコンプライアンス認証の統合の深さについては、特定のクラウドプラットフォーム上にコアビジネスを構築した企業にとって、選定時の優先考慮事項になることが多い。
戦略的見通し：次に最も起こりうること
Agents APIのリリースには戦略的に明確な論理がある。OpenAIはCodexとChatGPT Workの運用を通じてエージェントの本番稼働に関する豊富な知見を蓄積した後、そのインフラを外部に開放した。これは本質的に「エージェントアプリケーションの実行レイヤー」という新興市場でのポジション争いだ。この動きはOpenAIのビジネスモデルが構造的に拡張されていることを示している。「最高の言語モデルAPIの提供」から「最高のエージェント実行プラットフォームの提供」への進化だ。このフレームワークにおいて、モデルは徐々に実行プラットフォームの一構成要素となり、その逆ではなくなっていく。
注目すべき主要なシグナルは三つある。第一に、ゼロデータリテンションとデータローカライゼーションのサポートが正式版にいつ登場するか——この二つの機能の実現は企業採用曲線の顕著な加速を直接引き起こす。第二に、9社のパートナーサンドボックスエコシステムの拡大速度が、米国外市場での実際の利用可能性と規制コンプライアンスのカバレッジを左右する。第三に、AWS、Azure、GoogleがAgents APIのリリース後にどう応答するか——三社はすでにGA製品を持っており、今後の競争はコンテキスト管理コスト、マルチエージェント調整効率、コンプライアンス認証の深さをめぐる機能の収束と迅速な反復イテレーションへと展開する可能性が高い。
デベロッパーにとって現時点での現実的な判断は次の通りだ。プロトタイプと検証段階にあるチームにとって、OpenAI Agents APIは現在市場で最もアイデアから本番稼働レベルのエージェントへ到達する道のりが短い選択肢だ。コンプライアンス評価段階に入った後は、データ主権要件とクラウドプラットフォームの所属に応じて、そのまま維持するか、移行するか、ハイブリッドデプロイにするかを判断すればよい。パブリックベータ期間中の料金モデル（従量課金のみ、プラットフォーム固定費なし）は試行錯誤のコストを下げるものであり、活用すべき機会の窓だ。しかしコンプライアンスの制限は回避可能な技術的細部ではなく、実質的な閾値である点を忘れてはならない。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接