Cloudflare Containers が OpenAI Agents API の実行環境に — エージェントの「頭脳」と「手を動かす場所」を分離する

要約

Cloudflare は 2026-09-10、Containers を OpenAI Agents API の「自己ホスト実行環境」として使えるようにしました。

同日、OpenAI は Agents API をパブリックベータで公開しています。 その告知には「OpenAI ホストの環境で動かすほか、自社インフラや対応ベンダーのサンドボックスへ接続できる」と書かれていました。今回の Cloudflare の発表は、その「外部サンドボックス接続」の最初の具体的な実装例です。

役割分担が明確に示されているのが、この発表の要点です。

• OpenAI 側: セッション、オーケストレーション、コンテキスト圧縮、復旧
• アプリケーション側: ツールの提供
• Cloudflare Containers: 実際にコードが動く実行環境

つまり、エージェントの「頭脳と進行管理」と「手を動かす場所」を分離する構成です。前者はプラットフォームに任せ、後者は自分で持つ、という形になります。

オープンソースの OpenAI Agents API Workers テンプレートがリファレンス実装として提供されます。この Worker の挙動は具体的に説明されています。Codex のセッションごとに Cloudflare Container を1つ維持し、実行中の作業を保ち続け、追加入力が来たら再接続し、アイドルになれば自動で停止します。

テンプレートは拡張されることを前提に書かれています。Container を拡張してデータとネットワークへのアクセスを制御された形で与える、あるいは他の Cloudflare 製品と統合する、という改変が想定されています。

何が変わったか

• OpenAI Agents API の実行環境として Cloudflare Containers を指定できる
• OpenAI がセッション・オーケストレーション・コンテキスト圧縮・復旧を担当し、Containers が実行環境を担当する
• オープンソースの Workers テンプレートがリファレンス実装として公開された
• テンプレートは Codex セッションごとに Container を1つ維持し、再接続に対応し、アイドルで自動停止する
• Container を拡張してデータとネットワークのアクセス範囲を制御できる

業務インパクト（一般企業向け）

この発表が実務的に効くのは、「エージェントを業務で使いたいが、どこで動くのかが分からないと承認できない」という場面です。

エージェントの導入検討が止まる理由は、性能ではないことが多くあります。コードがどこで実行され、そこから何に接続でき、実行が終わったら何が残るのか。 ここに答えられないと、情報システム部門も法務も承認できません。「OpenAI のサーバーで動きます」という答えは、業種によっては、それだけで話が終わります。

Containers を実行環境にできるということは、この問いに具体的に答えられるようになるということです。 実行環境は自社が構成し、Container がどのデータに触れ、どのネットワークへ出られるかを自社で決められます。

ただし、正確に理解すべき点があります。これは「すべてを自社に閉じる」という話ではありません。

セッション管理とコンテキスト圧縮は OpenAI 側で行われます。つまり、会話の文脈は OpenAI 側を通ります。 分離できるのは「コードが実行される場所」と「そこから触れる範囲」であって、モデルへのやり取りそのものではありません。「自社インフラで動くから外部に何も出ない」と説明すると、それは誤りです。 稟議書に書く前に、この線を正確に把握してください。

設計上の実用的なポイントは、「アイドルで自動停止する」という挙動です。

エージェントの実行環境は、常時起動させるとコストが読めなくなります。セッション単位で立ち上がり、使わなくなれば落ちるという構成は、課金が実際の作業量に連動するということです。PoC の段階で「思ったよりコストがかかる」という理由で止まる案件は多いので、この挙動は評価しておく価値があります。

導入の順序としては、PoC を OpenAI ホスト環境で行い、本番移行時に Containers へ切り替えるという進め方が現実的です。 最初から自社環境を構成すると、検証したいこと（そもそも業務に使えるか）とは関係ない作業で時間を使います。実行環境を後から差し替えられるという前提が立つこと自体が、今回の発表の価値です。

副業・個人活用視点

個人開発者にとって、これは「顧客のデータを扱うエージェント案件」を請けられる条件が整った、という意味を持ちます。

受託でエージェントを作るとき、必ず聞かれるのが「うちのデータはどこへ行くのか」です。「OpenAI のサーバーで処理されます」としか答えられない状態では、扱えない案件が相当数あります。 実行環境を顧客の Cloudflare アカウント側に置ける構成が取れるなら、答えられる範囲が広がります。

ただし、提案する側として絶対に外してはいけない線があります。 上で書いたとおり、セッション管理とコンテキストは OpenAI 側を通ります。 ここを曖昧にしたまま「自社環境で完結します」と説明すると、後で発覚したときに信頼を失います。**「実行環境は御社側、モデルとのやり取りは OpenAI 経由」**と、最初から正確に分けて説明してください。正確に説明できること自体が、この領域では差別化になります。

技術的な参入しやすさという点では、テンプレートが公開されているのが大きいです。

ゼロから「セッションごとにコンテナを立ち上げ、アイドルで落とす」仕組みを書くのは、それなりの作業です。リファレンス実装から始めて、Container の中身とアクセス範囲だけを案件に合わせて作り込むという進め方ができるなら、見積もれる規模の仕事になります。

コスト面も個人には有利に働きます。 アイドルで自動停止する構成なら、検証中に放置して課金が膨らむ事故が起きにくいということです。個人で試すときの心理的なハードルが下がります。

注意点としては、OpenAI Agents API がパブリックベータであることです。 仕様変更で動かなくなる可能性があります。納品物に含める場合は、ベータであること・変更時の改修は別途であることを見積書に明記してください。テンプレートが公式提供されていることは、追随のしやすさという意味では有利に働きますが、変更が起きないという保証ではありません。