エージェント・サンドボックスを大規模化するため再設計されたCloudflare Containers、静的デプロイから実行時制御へ

エージェント・サンドボックスの大規模化に向けて再設計されたCloudflare Containersは、起動速度が6倍超に向上したと同社は述べている。9月30日のリリースでは、実行時のイメージ選択、実行時のインスタンス・サイジング、ファイルシステム・スナップショットもパブリックベータとして追加された。

重要な変更は、単にコールドスタートが短縮されたことではない。Cloudflareは各サンドボックスの制御を、リクエストと永続的なアプリケーション状態を調整するステートフルなサーバーレス・コンポーネントであるDurable Objectへ移した。この判断は、Cloudflare Containers初期版を形作った静的デプロイモデルに異を唱えるものだ。

開発者は現在、エージェントに各タスクで必要な環境を選択させられる。コーディング作業には、より大きなインスタンスと完全なLinuxツールチェーンが必要になる場合がある。より小規模な自動化には、軽量な環境を利用できる。作業が中断した際には、システムがファイルシステムを保存し、コンピュートを停止し、後でワークスペースを復元できる。

これによりCloudflareは、活発なエージェント・インフラ市場へより直接的に参入する。E2B、Modal、Daytona、Vercel、そしてハイパースケール・クラウドサービスは、すでに分離実行に対する異なるアプローチを提供している。Cloudflareの主張は、グローバルにアドレス可能なコントローラー、分離されたLinuxワークスペース、永続状態が、ひとつのプログラマブルな単位として動作すべきだというものだ。

このアーキテクチャは、コーディング・エージェント、評価、長時間実行ワークフローに適しているように見える。ただし、6倍という起動速度の主張はCloudflareによるものであり、スナップショットは依然としてパブリックベータで、複数の運用上の制約も重要である。本当の試金石は、チームがライフサイクルの複雑さを過度に引き継がずに、信頼できる制御を得られるかどうかだ。

エージェント・サンドボックスを大規模化するため再設計されたCloudflare Containersが、制御プレーンを変える

Cloudflareにおける中心的な変更は、サンドボックス設定をデプロイ時から、エージェントがタスクを開始する瞬間へ移すことにある。

従来のモデルでは、アプリケーションは通常、デプロイ設定で単一のコンテナ・イメージとインスタンス・タイプを宣言していた。いずれかの設定を変更すると、アプリケーションレベルのロールアウトが発生した。このパターンは予測可能なサービスには適しているが、エージェントはリクエストごとに異なるワークロードを生成する。

コード修正エージェントには、リポジトリ、コンパイラ、パッケージマネージャー、ブラウザ、テストスイートが必要になる場合がある。評価ワーカーには、入力を厳密に制御した、クリーンで再現可能な環境が必要になることがある。別のタスクでは、限られたメモリとインターネットアクセスなしで動作する短いスクリプトだけが必要かもしれない。

Cloudflareの新しいdurable_objectスケジューリングポリシーにより、アプリケーションコードは実行時にそれらの選択を行える。制御するDurable Objectはctx.container.start()を呼び出し、そのタスクに適したイメージ、スナップショット、インスタンス設定を渡す。

利用可能な事前定義サイズには、liteと4種類のstandard構成が含まれる。開発者は、プラットフォームの制限内でカスタムのCPU、メモリ、ディスク値を渡すこともできる。runtime scheduling policyは、中央で選択する1つの構成を、サンドボックスごとの判断に置き換える。

イメージ選択も同じモデルに従う。開発者は、Cloudflareのコマンドライン・デプロイツールであるWranglerを通じて名前付きイメージを宣言する。プラットフォームは不変の参照を準備し、Durable Objectがサンドボックス起動時にそのひとつを選択する。

この仕組みにより、アプリケーションはエージェントの役割ごとに別のコンテナ・アプリケーションをデプロイせずとも、複数のエージェントロールをサポートできる。コーディネーターは、軽量なリサーチタスクをあるイメージへ振り分け、その後、より多くのリソースを備えた別のイメージにビルド作業を割り当てられる。

Cloudflareは、Node.jsを含むマネージドDebianイメージcloudflare/debian-trixieも導入した。エージェントはその基盤から開始し、exec()を通じてツールをインストールし、作成されたワークスペースをスナップショットとして保持できる。

Cloudflareのsandbox announcementによると、新しいスケジューリング経路はContainersを6倍超高速に起動する。同社は、従来はDurable Objectとコンテナ・ランタイムの間に存在した複数の調整ステップを削除したとしている。

この主張は慎重に解釈する必要がある。Cloudflareは、代表的なイメージ、リージョン、ワークロードの種類を比較する独立したベンチマークを提示していない。コンテナの準備完了は、イメージサイズ、エントリポイントの挙動、容量、アプリケーションレベルのヘルスチェックにも左右される。

Cloudflare自身のアーキテクチャ文書では、コールドスタートは多くの場合1〜3秒の範囲に収まるとされている。また、起動時間はイメージとその初期化処理によって変動するとも記している。高速なスケジューラーでも、イメージ内部で生じる遅延を排除することはできない。

このプラットフォームは、プロセスが必ずしもトラフィックを受け付ける準備ができていない段階でもrunningプロパティを公開する。開発者は、最初のリクエストを送る前に、引き続きポートの準備状況を確認しなければならない。エージェントにとって、「コンテナが起動した」と「ワークスペースが有用な作業の準備を終えた」は、依然として異なる測定値である。

こうした留保があっても、実行時設定は製品の運用モデルを変える。Cloudflare Containersは、エージェントがたまたま利用するデプロイ済みサービスだけではなくなる。エージェント・コントローラーが個々のタスクに応じて組み立て、サイズを決め、停止し、再構築できるリソースとなる。

高速なエージェント・サンドボックスが静的デプロイモデルに圧力をかける

エージェントのワークロードが求めるのは、単に1つのイメージを効率よく実行するインフラではなく、タスクごとに形を変えられるインフラだ。

従来のコンテナ・プラットフォームは、開発者がデプロイ前にアプリケーションの形を把握していることを前提にしている。チームはイメージ、リソース割り当て、ネットワークポリシー、スケーリング構成を選択する。その後、スケジューラーがそれらの特性を概ね共有するレプリカを作成する。

エージェント・システムはこの前提を揺るがす。次の行動は、ユーザーのリクエスト、モデルの判断、ツールの結果、以前の作業で残された状態に依存する。同じ製品内で連続する2つのタスクでも、異なるオペレーティングシステム、依存関係、リソース制限、ネットワーク権限を必要とする場合がある。

この変動性は、静的なアプリケーション構成を中心に構築されたプロバイダーに圧力を与える。チームは複数のサービスをデプロイし、その間で作業をルーティングすることはできる。しかし、新しいワークロードの種類ごとに、デプロイ単位、ロールアウト経路、容量判断、設定ドリフトの原因が増える。

Cloudflareの実行時モデルは、その判断の一部をアプリケーションコードへ移す。エージェント・コントローラーは、タスクを検討した後でサンドボックスのイメージとインスタンス・タイプを選択できる。また、そのサンドボックスにインターネットアクセスを与えるか、保存済みスナップショットから開始するかも決定できる。

したがって、主な対抗対象は特定のベンダーではない。アプリケーション内のすべてのサンドボックスを、同一の事前定義済みサービスのコピーとして扱う静的デプロイモデルである。

E2B、Modal、Daytona、Vercelは、すでに独自の抽象化を通じてこの市場に対応している。開発者に使いやすいサンドボックスAPIを重視するものもあれば、関数、仮想マシン、ワークスペース、より広範なクラウド・オーケストレーションを中心に構築するものもある。KubernetesやFirecrackerを直接運用するチームはより多くの制御を得るが、その分より多くのインフラを担うことになる。

Cloudflareの差別化要因は、各コンテナとそのDurable Objectの関係にある。Durable Objectは、安定したアイデンティティ、アプリケーションコード、ストレージ、アラーム、Linux環境の外部での調整を提供する。コンテナは、従来型のオペレーティングシステムを必要とするツール向けに分離されたコンピュートを提供する。

Linuxワークスペースが休止している間も、エージェントの意思決定ループは稼働を続けられる。より重いサンドボックスを実行し続けなくても、ユーザーと通信し、認可状態を保持し、モデルを呼び出せる。コンパイラや開発サーバーが必要になった時点で、コントローラーがコンテナを起動する。

Cloudflareはこの分離を、エージェントの「脳」を「手」から切り離すものと表現している。コントローラーは意図と状態を保持し、サンドボックスは失敗、停止、置き換えが生じうるコマンドを実行する。

この分離には、運用上の利点だけでなくセキュリティ上の利点もある。Durable Objectは認証情報をコンテナの外部に保持し、送信リクエストを仲介できる。エージェントが、認可済みのサービス呼び出しに必要なすべてのシークレットへ直接アクセスする必要はない。

Cloudflareは以前、動的に生成されるエージェントコードには分離された実行環境が必要だと主張していた。以前のcode sandbox modelは、完全なLinuxシステムを必要としないタスク向けの軽量なDynamic Workersに焦点を当てていた。

Containersは、その分割におけるより重量級の側面を担う。パッケージマネージャー、ネイティブバイナリ、リポジトリ、コンパイラ、ターミナル、開発サーバーをサポートする。Dynamic Workersは、より限定されたランタイムで小規模なコード実行タスクを処理できる。

これにより、階層化された実行戦略が生まれる。コントローラーは短いAPIワークフローには軽量なサンドボックスを使用し、Linuxを必要とする作業にはコンテナを確保できる。すべてのタスクをフルコンテナ内に置くと、起動時間とリソースが無駄になるため、実行時選択は重要だ。

この圧力はサンドボックス・ベンダーにとどまらない。社内プラットフォームチームは、プロビジョニングの遅延を隠すため、ウォーム状態の開発環境プールを維持することが多い。高速なコールドスタートと再開可能なファイルシステムは、大規模なアイドルプールを待機させる根拠を弱める。

ただし、Cloudflareがオーケストレーションを不要にするわけではない。オーケストレーションをDurable Objectとそのアプリケーションコードに移しているのである。チームは依然として、受付ルール、並行性制御、リトライ動作、認可、クリーンアップ、可観測性を設計しなければならない。

勝つモデルは、最小の分離環境起動時間を示すプラットフォームではない。エージェントの判断から検証済みのタスク結果までの総時間を最小化するモデルだ。

そこには、イメージ準備、リポジトリアクセス、依存関係の復元、コマンド実行、ネットワーク遅延、後処理が含まれる。また、セッション失敗や作業喪失によって生じる人間側の遅延も含まれる。

選択肢を比較するエンジニアリングチームにとって、関連性の高いベンチマークは、完全なワークフローを再現すべきである。空のコンテナを使った合成テストでは、大規模リポジトリ、パッケージのインストール、ブラウザ起動、テストスイートを表現できない。

こうした評価は、チームが保持すべき設計上の知見も生み出す。検索可能なengineering knowledge baseは、ベンチマークの前提、セキュリティ判断、移行時の発見事項を実装とともに保存できる。

Durable ObjectsがContainersをタスク固有のコンピュートへ変える

このリリースの基盤となる仕組みは、コンテナを永続的なアプリケーション状態ではなく、置き換え可能なコンピュートとして扱うステートフルなコントローラーだ。

すべてのCloudflare ContainerはDurable Objectに関連付けられている。リクエストはまずWorkerに到達し、その後コンテナに到達する前にそのオブジェクトを経由してルーティングされる。Durable Objectは特定のワークスペースをアドレス指定し、そのアイデンティティに結び付いた状態を保持できる。

新しいAPIでは、開発者はDurableObjectを直接拡張し、this.ctx.containerを通じて接続されたコンテナにアクセスする。これにより、Cloudflareが当初Containersを従来型のサンドボックスサービスに似せるために使用していたラッパークラスが不要になる。

コントローラーはコンテナの起動、コマンド実行、状態の検査、終了の監視、プロセスシグナルの送信、非アクティブ・タイムアウトの設定、インスタンスの破棄を行える。これらの制御をDurable Objectのストレージ、アラーム、WebSockets、リモート・プロシージャ・コールと組み合わせることができる。

バグ報告に応答するコーディングエージェントを考えてみよう。Durable Objectはセッション識別子、承認済みリポジトリ、ユーザー権限、現在のタスクフェーズを保存できる。その後、適切な言語ツールチェーンを含むイメージを選択し、適したインスタンスを起動できる。

コンテナはリポジトリをクローンし、依存関係をインストールし、テストスイートを実行してファイルを編集する。その間、Durable ObjectはWebSocket経由で進捗を送信し、コンテナ外にチェックポイントを記録できる。

コンテナプロセスが終了しても、コントローラーはセッションのIDとメタデータを保持する。障害を調査し、既知の状態から再起動するか、対話全体を失うことなく問題を報告できる。

Cloudflareは各コンテナを、独自のカーネルとネットワークを備えた軽量仮想マシンであるFirecracker microVM内で実行する。顧客のイメージは、その仮想マシン内でLinuxコンテナとして実行される。

プラットフォームのコンテナアーキテクチャでは、他のCloudflareワークロードがそのカーネルを共有しないと説明されている。この分離は重要だ。エージェントが生成したコマンドを、信頼されたユーザーデータを扱うアプリケーション内で直接実行すべきではないためだ。

配置は引き続き動的である。Cloudflareは、必要なイメージが利用可能な適格なキャパシティを選択し、ルーティングと起動速度が配置先に影響する。Durable Objectとコンテナが同じ場所で実行される保証はない。

この注意点は、レイテンシに敏感な制御ループにとって重要である。グローバルに到達可能なIDがあるからといって、すべての操作がユーザー、モデルプロバイダー、またはサンドボックスの近くで実行されるわけではない。チームは、想定するリージョン全体で完全なリクエスト経路を測定すべきだ。

セッション間でキャパシティが移動することもある。コンテナが停止し、後に再起動した場合、Cloudflareは代替インスタンスを別の場所に配置する可能性がある。アプリケーションは、1台のマシンにおけるローカルIDを永続的なものとして扱ってはならない。

Durable Objectは継続性のレイヤーとなる。ワークスペースを見つけ、再構築し、復元するために必要な情報を保存する。Linuxインスタンスは、アイドル時に消失し得る実行リソースとなる。

このアーキテクチャは、分岐するワークロードも支える。コーディネーターは、同じ準備済みベースラインから複数の独立した試行を開始できる。各試行では、異なるモデル、システムプロンプト、スキルセット、または修復戦略をテストできる。

コントローラーはそれらの実行を監視し、結果を比較して、優先する出力を保持できる。強化学習システムも同様のパターンを用いて、制御された環境を作成し、結果を評価し、試行間で状態をリセットできる。

ランタイムでのインスタンスサイズ指定は、このモデルを強化する。コントローラーはビルドにより多くのリソースを割り当て、軽量なコマンドではリソースを減らせる。アプリケーション全体で静的にサイズを決める場合、チームは最も大きな一般的タスクに合わせてプロビジョニングするか、別個のデプロイメントを維持する必要がある。

ただし、プログラマビリティは責任をアプリケーション側へ移す。コントローラーは、モデルが制限なくリソースを選択することを防がなければならない。任意のモデル出力をインフラAPIに渡すのではなく、エージェントのリクエストを承認済みポリシーへマッピングすべきだ。

同じ原則はイメージにも当てはまる。ランタイムでの選択を許可することは、未審査のイメージをエージェントが実行できるようにすることではない。Cloudflareは、宣言済みでダイジェスト固定されたイメージ参照を要求しており、これはデプロイメントの再現性維持に役立つ。

チームは依然としてイメージの許可リストを維持し、依存関係をスキャンし、アウトバウンドアクセスを制限し、認証情報をゲスト環境から分離すべきだ。サンドボックスは露出を抑えるが、完全なセキュリティポリシーを定義するものではない。

運用面では、Durable Objectをライフサイクル状態の唯一の信頼できる情報源として維持すべきだ。Cloudflareの直接APIは制御機能を提供するが、タスクがいつ復旧可能、放棄、完了、または安全に再試行可能となるかは、アプリケーションが判断しなければならない。

これこそが、より高速なエージェントサンドボックスを支える真の仕組みである。スケジューラーの改善は重要だが、持続的な変化は、単一のコンテナプロセスを超えて存続する明示的なコントロールプレーンにある。

ファイルシステムスナップショットはファイルを保持するが、実行中のセッションは保持しない

スナップショットは繰り返し行うセットアップ作業を減らすが、完全な中断・再開イメージではなく、不変のファイルシステムチェックポイントである。

Cloudflareのネイティブなファイルシステムスナップショットは、durable_objectスケジューリングポリシーを通じてパブリックベータで提供されている。実行中のコンテナはsnippetContainer()ではなく snapshotContainer()を呼び出して、ある時点の書き込み可能なルートファイルシステムをキャプチャする。

返されるハンドルには、識別子、サイズ、任意の名前が含まれる。Worker APIにはスナップショットを一覧表示するコマンドがないため、開発者はそのハンドルを保存する必要があり、多くの場合はDurable Objectストレージに保存する。

後続のコンテナは、保存されたハンドルから起動できる。これにより、元のコンピュートが停止した後でもコーディングワークスペースを復旧できる。リポジトリ、インストール済み依存関係、ビルドキャッシュ、設定ファイル、編集内容は、復元されたファイルシステムとともに戻せる。

このモデルは、エージェントインフラでよくある不一致に対処する。空のサンドボックスの起動には数秒しかかからない一方、有用な開発環境の準備には数分かかる場合がある。依存関係インストールの繰り返しが、ユーザーが実際に体験する起動時間の大部分を占めることがある。

スナップショットは評価のための安定したベースラインも提供する。チームは1つのリポジトリとツールチェーンを準備して保存し、同一のチェックポイントから複数の実験を開始できる。復元後、各サンドボックスには独立した書き込み可能環境が与えられる。

これにより、試行間の環境ドリフトを減らせる。2つのモデルバージョンが異なる依存関係の状態を見ていると、テスト結果の比較は難しくなる。共有された不変のチェックポイントは、評価対象の変数を分離するのに役立つ。

この機能は、より長期的なプロジェクトも支援する。ユーザーが離席したときにエージェントがワークスペースを保存し、コンピュートを停止し、ユーザーが戻ったときにファイルを復元できる。これにより、ファイルシステムの継続性と継続的なリソース使用を分離できる。

ただし、「スナップショット」という言葉は、Cloudflareが現在保持する範囲以上のものを示唆する可能性がある。スナップショットのドキュメントによると、システムはコンテナの完全なファイルシステムをキャプチャするが、メモリ、実行中プロセス、または別途マウントされたファイルシステムはキャプチャしない。

復元されたコンテナはエントリーポイントを再度実行する。メモリ上のビルド、ライブデバッガー、ターミナルプロセス、開発サーバーは、停止した正確な命令位置から再開されない。アプリケーションはそれらのプロセスを再構築する必要がある。

スナップショットは、作成時に使用したイメージバージョンにも紐付けられる。開発者は別のイメージへ復元できない。ベースイメージが変わる場合、チームは新しい互換性のあるスナップショットを作成しなければならない。

各スナップショットハンドルには、暗黙的な30日間の有効期限がある。復元するとその期間は更新されるが、開発者は現時点で別の保持期間を設定できない。この制約により、外部での保存計画なしにスナップショットを無期限アーカイブとして利用することは適さない。

スナップショットは不変である。復元後に加えた変更を保存するには、チームが別のスナップショットを作成する必要がある。したがって、アプリケーションには、復旧価値とストレージ、レイテンシ、運用上の複雑性のバランスを取るチェックポイントポリシーが必要となる。

パブリックベータであることも、注意を要する理由となる。本番チームは、中断、同時アクセス、イメージ更新、リージョン配置の変更がある状況で、スナップショットの作成と復元を検証すべきだ。

障害境界についてもテストすべきである。チェックポイント作成中にコンテナが停止した場合、どのスナップショットが有効なままかをアプリケーションが明確に記録する必要がある。タスクが外部システムを変更した場合、そのファイルシステムを復元しても外部アクションは元に戻らない。

この区別は、自律型エージェントにとって特に重要である。ロールバックはローカルファイルを復元できる一方で、プルリクエスト、データベース更新、メール、クラウドリソースは変更されたままになる可能性がある。タスクを無条件に再試行すると、不可逆的なアクションが重複するおそれがある。

そのためコントローラーには、サンドボックス外部にタスク台帳が必要となる。承認済み操作、外部副作用、完了済みチェックポイントを記録すべきだ。ファイルシステムだけでは、エージェントの作業に関する完全な真実を表せない。

セキュリティチームは、スナップショットが何を保持するかも検討する必要がある。リポジトリ、生成コード、ログ、キャッシュされたパッケージ、一時的な認証情報は、いずれも書き込み可能なファイルシステムに到達し得る。スナップショットは、機密情報を実行中セッションより長く保持する可能性がある。

Cloudflareはアウトバウンドリクエストのインターセプトと外部認証情報の処理を提供しており、ゲスト内でのシークレット露出を抑えられる。とはいえ開発者は、ツールがトークンを設定ファイル、シェル履歴、パッケージキャッシュへコピーしないことを確認すべきだ。

同社の移行方針は、別の実務上の課題ももたらす。高速化されたパスやネイティブスナップショットを含む新機能には、ctx.containerへの直接アクセスが必要となる。Cloudflareは、古いContainerおよびレガシーSandboxクラスを2026年12月31日まで維持するとしている。

同社によれば、既存のデプロイメントはその日以降も継続して実行されるが、それらのクラスは更新を受けなくなる。新機能を求めるチームは、ライフサイクルロジックを直接Durable Object APIへ移行しなければならない。

これは、すべてのチームが安全に有効化できるフラグではなく、意味のあるアーキテクチャ変更である。直接APIは、システムのIDおよび協調モデルをより多く公開する。同時に、以前はベースクラスに隠れていた挙動を、開発者が明示的に所有することも求める。

CloudflareはSandbox SDK 1.0をスーパークラスではなく、ユーティリティの集合へと転換している。これにより、チームは便利なヘルパーとネイティブなライフサイクル制御を組み合わせられるはずだ。また、CloudflareがSDKラッパーではなくDurable Objectを中核抽象化として位置づけたいことも裏付けている。

次に注目すべきは信頼性、採用、そして競合の反応

このリリースが重要になるのは、実際のエージェントシステムが新たな制御機能を、より低いタスクレイテンシと信頼できる復旧へ転換できた場合に限られる。

最初に注目すべきシグナルは、完全なワークロード全体における本番パフォーマンスである。Cloudflareが報告した6倍の改善は起動パスに関するものだが、開発者にはタスクのディスパッチからアプリケーションが利用可能になるまでの測定が必要だ。

有用なテストは、小規模・大規模イメージ、複数リージョン、復元されたスナップショット、新規ファイルシステム、異なるインスタンスサイズを対象にすべきだ。スケジューラーのレイテンシと、イメージ初期化、依存関係復元、サービスの準備完了を区別する必要がある。

こうした測定でエンドツーエンドの遅延が一貫して短縮されるなら、Cloudflareの主張は強まる。リポジトリや開発サーバーがワークフローに加わると改善効果が消えるなら、起動速度はより限定的な優位性となる。

第2のシグナルは、パブリックベータが要求の厳しいワークロードに到達した後のスナップショットの信頼性である。チームは、復元失敗率、チェックポイント作成時間、ストレージの挙動、イメージ更新手順、中断されたセッションからの復旧を注視すべきだ。

コーディングエージェントによる採用成功は、特に示唆的だろう。Cloudflareはすでに、Base44とKilo Codeがエージェント作業向けに分離環境を利用している例として挙げている。Cloudflareの以前の資料では、Figma Makeも信頼できないコードの実行におけるContainers顧客として特定されていた。

これらの顧客事例は実際のユースケースを示しているが、比較可能なパフォーマンスデータを提供するものではない。独立したエンジニアリングレポートのほうが、ローンチ時の推薦コメントよりも重みを持つだろう。

大規模リポジトリにおけるスナップショットの挙動も重要となる。パッケージディレクトリやビルド出力は急速に肥大化する可能性がある。チームは、繰り返しのチェックポイントを経てワークスペースが成長しても、スナップショットが高速かつ管理可能であり続けるかを理解する必要がある。

Cloudflareがスナップショットの保持期間制御、一覧API、可観測性、クロスバージョン移行ツールを拡張するなら、その機能がより広範な本番利用へ進んでいることを示唆するだろう。制約が残り続ける場合、長期間稼働するワークスペースという見通しは弱まる。

第3のシグナルは、競合他社がCloudflareの統合されたコントローラーとサンドボックスのモデルにどう反応するかである。エージェントサンドボックス市場には、特化型プロバイダーとより広範なコンピュートプラットフォームが含まれ、それぞれ異なる強みを持つ。

E2Bは、エージェント向けに設計された専用クラウド環境を重視している。Modalは、サンドボックス化されたコンピュートをより大規模なサーバーレスプラットフォームへ接続する。Daytonaは開発環境に焦点を当て、Vercelはサンドボックス機能を自社のアプリケーションプラットフォームと統合している。

ハイパースケールクラウドは、仮想マシン、コンテナ、IDシステム、オーケストレーションサービスを通じて、チームに幅広い制御を提供する。一方で、その部品群を低レイテンシーのエージェント製品へ組み立てるために必要なエンジニアリング作業が欠点となることが多い。

Cloudflareは、Durable Objectsがその組み立てを圧縮できると見込んでいる。ID、状態、通信、ポリシー、ライフサイクルを、サンドボックスコントローラーの隣に置くことができる。同社のグローバルネットワークは、ルーティングと事前に用意されたキャパシティを提供する。

競合による対抗策には、いくつかの形が考えられる。他社は、より強力なステートフルな協調機能、より柔軟なスナップショット、より細かなランタイムサイズ設定、あるいはより緊密な認証情報の仲介を追加するかもしれない。Cloudflareの起動時間に関する主張に異を唱えるベンチマークを公開する可能性もある。

競合各社が外部のステートフルなコントローラーへ収束すれば、顧客が別のプラットフォームを選んだとしても、Cloudflareのアーキテクチャは先見性のあるものに映るだろう。開発者がよりシンプルなホスト型サンドボックスAPIを好む場合、Durable Objectモデルはインフラ寄りすぎると受け止められるかもしれない。

導入は、アプリケーションチームがどの程度の制御を求めるかにも左右される。コーディングエージェントを構築するスタートアップは、ライフサイクルを直接プログラミングできることを重視するかもしれない。一方、コード実行機能を1つ追加するチームは、判断すべき事項が少ない、意見を組み込んだサービスを好む可能性がある。

Cloudflareは、プラットフォームを差別化する機能を隠すことなく、両方のグループに対応しなければならない。新しいSDKの方向性は、別の必須抽象化ではなくネイティブAPI周辺のユーティリティを提供することで、その折衷を試みている。

セキュリティインシデントも、もう1つの決定的な評価指標となる。エージェント用サンドボックスは、ネットワークアクセスや独自コードへの近接性を伴うことが多い、信頼できない、あるいは予測不能なコマンドを実行する。認証情報を漏えいさせたり、テナント間アクセスを許したりする高速な環境は、その中核的な目的を果たせない。

CloudflareによるFirecracker microVMsの利用は、ワークロード間のカーネル分離を実現する。それでも安全な運用は、イメージの衛生管理、アウトバウンド制御、認可、シークレット管理、ログ、アプリケーションポリシーにも依存する。

チームはこのモデルを、エージェントが生成したコードを信頼してよいという許可ではなく、多層的な封じ込めとして扱うべきだ。Durable Objectはポリシー適用のポイントになり得るが、開発者はそのポリシーを実装し、テストしなければならない。

このリリースは、エージェント製品のアーキテクチャに関するより広い問いも提起している。エージェントはワークスペースの外に置き、それを交換可能なツールとして扱うべきなのか。それとも、エージェントは自身のコンピューター内で動作すべきなのか。

Cloudflareは両方のパターンをサポートする。エージェントをDurable Object内で実行すれば、コンピュートが休止している間も通信と状態を利用できる。コンテナ内で実行すれば、親しみやすいLinuxプロセスモデルを利用でき、オブジェクトが外部からそれを監督する。

最初のパターンでは、脳と手の境界が明確になる。2番目のパターンは、ローカルファイルやプロセスを想定する既存のエージェントランタイムを単純化するかもしれない。実際の導入状況が、どちらのモデルを開発者が運用しやすいと感じるかを示すだろう。

エージェントサンドボックスを拡張するために再構築されたCloudflare Containersは、コールドスタートの改善以上の意味を持つ。ランタイムの選択、ファイルシステムの継続性、ライフサイクルポリシーを、永続的な状態によって制御されるアプリケーションレベルの意思決定へと変える。

この変化は、静的なデプロイメントや単純なサンドボックスAPIに圧力をかける。同時に、開発者が微妙な障害を生み出す余地も増やす。ランタイムの柔軟性には、厳格なポリシー、永続的なタスク記録、空のプロセスではなく実用的な準備完了を測定するベンチマークが必要だ。

このリリースを評価するチームは、まず実際のワークロードを1つ用意すべきである。新規起動、復元後の起動、依存関係の準備完了、障害復旧、タスク全体の完了を測定する。次に、外部アクションを繰り返すことなく、コンテナ喪失後もコントローラーが存続できるかをテストする。

今後数か月で、Cloudflareのパブリックベータ版スナップショットが信頼性を維持するか、顧客が独立したレイテンシー結果を公開するか、競合他社が類似のステートフルな制御を採用するかが明らかになるはずだ。こうした兆候によって、このアーキテクチャが長時間稼働するエージェントの共通基盤となるのか、それとも競争が激化する市場における別の専門的選択肢にとどまるのかが決まる。