OpenAI、Codexのハーネスを Agents API へ:状態管理はプロバイダー側に移る

2026年9月10日、OpenAI は Agents API をパブリックベータで公開した。Codex が土台にしているのと同じマネージドハーネスを、開発者にそのまま開く仕組みである。このアーキテクチャは、これまで自前のコードやサードパーティ製フレームワークに任されてきたオーケストレーションの負荷 —— セッション、履歴とコンテキストの圧縮、エラー後の再開 —— を、同社のサービスの内側へ直接移す。技術ドキュメントは四つの基本要素を挙げる。Agent(モデル・指示・ツール・MCP サーバーをひとまとめにするもの)、Environment(任意の実行サンドボックス)、Session(プロセスの永続的なインスタンス)、そして Events/Items(入出力のストリーム)である。公式クイックスタートの呼び出しは、`OpenAI-Beta: agents=v1` ヘッダーの下でモデル "gpt-6-astra" を参照し、`POST /v1/agents/sessions` などのエンドポイントを使う。処理の追跡には `agent.session.turn.completed` や `turn.failed` といった JSON イベントがストリーミングで流れる。

課金にハーネス単体の料金はない。費用は、選んだモデルのトークン消費、有効にしたツールの料金、そして OpenAI が管理するサンドボックスのコンテナ計算時間(分)に一致する。公式ドキュメントが記述するのは hosted と self-hosted の二つだけだが、専門メディアは第三の選択肢としてパートナーのサンドボックスを伝えており、名前は九つ —— Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel。Environment に関するドキュメントページには到達できない。2026年4月には、以前の Agents SDK がすでに七つの統合プロバイダーによるネイティブのサンドボックス対応を導入していた。加えて、公開された仕様は肝心の数値を明らかにしていない。レート制限、セッションの最長時間、コンテナの正確な時間単価、セッションをまたいだ環境の状態の永続性、そしてクイックスタートのコード例で使われている gpt-6-astra 以外にどのモデルが使えるのか。

データガバナンスについて、ドキュメントは厳しい線を引く。データの所在地は米国のみに限定され、Zero Data Retention はサポートされない。同じドキュメントは、自社インフラ上の self-hosted サンドボックスを選んでも Agents API が ZDR の対象にはならないと明記している —— つまり、もっとも分かりやすい手当てでは足りない。この条件は、厳格な機密保持の義務を負う欧州の組織にとって、採用の範囲をはっきりと狭める。開発者の反応は割れていると報じられている。ベンダーロックインの深化と読む向きもあれば、自前のサンドボックス VM を維持せずに済む安堵と受け取る向きもある(BigGo Finance)。

オーケストレーションを API 呼び出し一本に縮めることは、アプリケーションから仕事を取り去り、それをプロバイダーのサーバーへ移すことだ。欧州で規制対象のデータを扱う側にとって、判断の分かれ目は保守の節約ではなく、ドキュメントの二行にある。データは米国のみ、Zero Data Retention なし。欧州での提供可否と時期については、何の示唆もない。 — Olya