Cloudflare Containers、AIエージェント用サンドボックスのオンデマンド実行向けに再アーキテクチャ

Cloudflareは、AIエージェントの動的なニーズにより適切に対応するため、Containersプラットフォームを根本的に再アーキテクチャしました。2026年9月30日に公開されたこのアップデートでは、新しいスケジューリングポリシーが導入され、アプリケーションコードがデプロイ時ではなくランタイム時にコンテナイメージとインスタンスタイプを選択できるようになります。これらの変更は、従来のコンテナオーケストレーションに伴うレイテンシーペナルティを排除し、サンドボックスを1秒未満で起動できるようにすることを目的としています。

何が起きたか

以前、Cloudflare Containersは従来のアプリケーションデプロイと同様に動作していました。開発者はビルドプロセス中にコンテナイメージと計算リソースを定義する必要があり、各構成を個別のアプリケーションとしてデプロイしていました。このモデルでは、イメージとインスタンスタイプのすべての組み合わせに対して異なるDurable Object名前空間が必要でした。エージェントが軽量なNode.js環境と大容量のPythonビルド環境の両方を必要とする場合、開発者は2つの別々のアプリケーションを管理し、トラフィックを手動でルーティングしなければなりませんでした。環境への変更を行うたびに新しいデプロイサイクルが必要となり、AIエージェントの不規則なリソース要件に適応することが困難でした。

新しいアーキテクチャでは、これらの決定をアプリケーションロジック自体に移行します。durable_objectスケジューリングポリシーを導入することで、Cloudflareはタスクが到着した際にコードが特定のイメージとインスタンスサイズを選択できるようにします。これにより、単一のDurable Objectクラスで異なる種類のサンドボックスを並行して起動できるようになりました。例えば、エージェントは単純なクエリ用に軽量な環境を要求し、複雑なタスク用に高負荷なビルド環境を要求できますが、事前のプロビジョニングは不要です。この変化により、インフラストラクチャ設定は静的なデプロイ成果物から、リクエスト時に実行される動的なコードへと変貌します。

この柔軟性に加え、Cloudflareは重要な問題である起動レイテンシーにも対処しました。AIエージェントは個々のタスクのためにオンデマンドでサンドボックスを作成することが多く、ユーザーは作業を開始する前に環境の初期化を待たなければなりません。以前のグローバルコントロールプレーンモデルでは、ネットワーク全体で設定を解決し配置を調整するために大きなオーバーヘッドが発生していました。新しいシステムはこの処理をローカル化し、制御するDurable Objectと同じマシン上で可能な限りコンテナを起動します。これにより、中央値の起動時間は4秒強から648ミリ秒に短縮され、独立したベンチマークで確認された6倍以上の改善が実現されました。

仕組み

この速度と柔軟性を可能にする中核メカニズムは、ContainersとDurable Objectsの密接な統合です。各コンテナインスタンスはDurable Objectにアタッチされており、これは永続的でプログラム可能なコントローラーとして機能します。新しいモデルでは、Durable Objectはライフサイクルを管理するだけでなく、ネイティブのctx.container APIを通じてコンテナの設定を直接制御します。リクエストが到着すると、コードはタスク要件を確認し、設定ファイル内の事前定義リストからイメージを選択します。その後、スケジューラーはまずローカルホスト上の容量を探し、ダウンロード遅延を避けるために必要なイメージまたはスナップショットが既にローカルストレージにあるマシンを優先します。

起動時間をさらに短縮するため、ランタイムはすべてのリクエストに対して仮想マシンをゼロからブートしなくなりました。代わりに、初期化済みだが未割り当ての状態にある準備済みの仮想マシンを復元します。このアプローチにより、ネットワークおよびファイルシステムのセットアップを再利用し、以前は逐次実行されていた操作をバッチ処理します。さらに、Cloudflareはcloudflare/debian-trixieという既製システムイメージを導入しました。このベースイメージにはDebian Trixie SlimとNode.js 24.20.0 LTSが含まれており、事前に各ホストに配布されています。エージェントはこのサンドボックスを即座に起動し、実行コマンドを使用してリポジトリをクローンしたりパッケージをインストールしたりできるため、単純なタスクのためにカスタムDockerイメージをビルドしてプッシュする必要がありません。

主要な詳細

• ランタイム設定: 新しいdurable_objectスケジューリングポリシーにより、コードはランタイム時にコンテナイメージとインスタンスタイプを選択でき、各環境タイプごとに個別のデプロイを行う必要がなくなります。
• 起動パフォーマンス: 中央値の起動時間は4.049秒から648ミリ秒に低下し、95パーセンタイルは5.839秒から910ミリ秒に改善されました。
• ファイルシステムスナップショット: ベータ版として公開されている機能により、コンテナファイルシステムの保存と復元が可能になり、エージェントは状態を失ったりセットアップ手順を繰り返したりすることなく、長時間実行されるタスクを一時停止および再開できます。
• 準備済みベースイメージ: cloudflare/debian-trixieイメージは事前に各ホストに配布されており、エージェントはカスタムイメージをビルドせずにLinux環境を即座に起動できます。
• バースト容量: 予備テストでは、システムが6箇所にわたって5.387秒間で10万個のコンテナを起動できることが示され、バーストワークロードに対する高いスケーラビリティを実証しました。
• ロールアウト制御: ロールアウトは現在、Durable Object内のコードによって管理されており、カナリアリリースやアクティブプロジェクトを特定イメージにピン留めするなどの戦略を、プラットフォームレベルの設定変更なしに採用できます。

なぜ重要なのか

AIエージェントプラットフォームを構築するエンジニアにとって、このアップデートはユーザー体験における主要なボトルネックを解消します。従来のコンテナオーケストレーションは長期実行サービス向けに設計されており、瞬時に起動しなければならない一時的なタスクには適していません。設定をランタイムへ移行することで、開発者は必要なときのみリソースを消費するより効率的なシステムを構築できます。これは、数千もの隔離された環境を必要とするコーディングエージェント、評価フレームワーク、強化学習システムにとって特に重要です。サンドボックスを1秒未満で起動できるということは、ユーザーが環境のプロビジョニング待ちに費やす時間が減り、エージェントとの対話に費やす時間が増えることを意味します。

ファイルシステムスナップショットの導入は、サーバーレス環境における状態管理の方法も変えます。以前は、エージェントの作業を保持するために複雑な外部ストレージソリューションが必要か、コンテナを無期限に稼働させ続ける必要があり、コストが増加していました。現在では、エージェントはワークスペースを保存し、コンテナを終了し、後で中断した場所から正確に復元できます。この機能は非同期ワークフローや数日間にわたる長時間実行タスクをサポートし、永続的なサーバーを管理せずにサーバーレスインフラストラクチャ上でより洗練されたエージェントアプリケーションを構築することを可能にします。

実施できること

• wrangler.jsoncを更新し、durable_objectスケジューリングポリシーを含めて、Durable Objectがアクセスできるイメージを宣言してください。
• 既存のコンテナロジックをリファクタリングし、Durable Objectクラス内でタスクパラメータに基づいてイメージとインスタンスタイプを選択するようにしてください。
• カスタムDockerビルドを必要としないタスクについては、事前配布された資産を活用するためにcloudflare/debian-trixieベースイメージをテストしてください。
• ワークフローにファイルシステムスナップショットを実装し、重要なマイルストーン後にエージェントの状態を保存し、再開時に復元してください。
• Durable Objectストレージを使用してロールアウト戦略を管理し、移行期間中に特定のIDを古いイメージにピン留めするなどしてください。
• 新しいctx.container APIを使用して起動メトリクスを監視し、エージェントがローカライズされたスケジューリング改善から恩恵を受けていることを確認してください。