Cloudflare Computer、エージェントのコンピューターをIsolateとコンテナに分割

Cloudflareは2026年8月3日、3つの実行バックエンドにまたがる単一の永続ワークスペースをエージェントへ提供するCloudflare Computerを、オープンソースのプレビューとして公開した。対立点はこの設計そのものにある。開発者は軽量なWorkers Isolateへ単純な作業を振り分け、より重いジョブにはLinuxコンテナを割り当てられるが、このプロジェクトは明確に本番利用には未対応とされている。

この違いが重要なのは、エージェント向けインフラが完全に隔離されたマシンへと向かってきたためだ。Cloudflare Computerは別の前提を検証する。エージェントにはコンピューターの機能が必要だが、すべてのアクションで同じコンピューターランタイムを必要とするわけではない。各コマンドを実行する環境とは別に、ファイルを永続化できる。

その結果、サンドボックス、コンテナ、あるいはmicroVMをエージェントセッションの基本単位として扱うプロバイダーに圧力がかかる。また、開発者が専用コンテナを必要とする場面を、Cloudflare既存のSandbox SDKが正当化する必要も生じる。このプレビューは完成品というより、エージェントコンピューティングをどう分割すべきかをめぐる公開の主張に近い。

Cloudflare Computerはファイルと実行を分離する

中心となる変更はアーキテクチャにある。エージェントのワークスペースは、もはや単一の稼働中コンテナに属さない。

プロジェクトのオープンソースリポジトリによると、Cloudflare Computerは信頼できる仮想ファイルシステムをDurable Object内に保存する。Durable Objectは、プライベートで永続的なストレージと単一の調整ポイントを備えた、状態を持つCloudflareコンポーネントだ。

このファイルシステムの状態はSQLiteが保持する。実行はworkspace.runtimeと呼ばれる共通インターフェースを通じて別の場所で行われる。異なるバックエンドがコマンドを実行しても、エージェントは同じファイルを読み書きできる。

プレビューには3つのバックエンドが含まれる。コンテナバックエンドは、実際のバイナリ、パッケージマネージャー、ネットワークアクセスを備えた完全なLinuxユーザーランドを提供する。Worker shellバックエンドは、Dynamic Worker内でjust-bashを通じてシェル風のコマンドを実行する。3つ目のバックエンドは、毎回新しいDynamic Worker内でJavaScriptモジュールを評価する。

開発者は、1つのワークスペースに複数のバックエンドを登録できる。それぞれに安定した識別子が与えられ、workspace.runtime.exec()が共通のエントリーポイントになる。呼び出し元はバックエンドを直接選べるほか、エージェントフレームワークは開発者が提供する説明に基づいて選択できる。

この構成では、ファイルシステムがセッションの安定した中心となる。コンピュートは交換可能だ。軽量なコマンドはIsolateで実行でき、パッケージのインストールやネイティブビルドは、別の論理ワークスペースを作ることなくLinuxへ移せる。

Cloudflareはこのパッケージを、プラグ可能な実行機構を備えた永続的なSQLiteバックの仮想ファイルシステムと呼ぶ。パッケージドキュメントでは、ワークスペースあたりの上限は約10 GBと説明されている。ストレージはDurable Objectの制限を共有する。

このパッケージは、実行バックエンドなしでも動作する。アプリケーションは永続ファイルシステムだけを使い、ワークフローで必要になった時点で実行機構を追加できる。これにより、ストレージモデルはサンドボックスを支える補助機能以上の意味を持つ。

公開APIは、よく知られたNode.jsのファイルシステム操作に似ている。ファイルの読み取り、書き込み、一覧表示、削除、検索のための関数が含まれる。文字列はデフォルトでUTF-8を使い、バイナリデータはバイト配列またはストリームで扱える。

コンテナへのアクセスには、さらに1層が必要となる。computerdというデーモンがサンドボックス内で動作し、永続ワークスペースをFUSEマウントとして公開する。FUSEは、ユーザー空間のプロセスが通常のファイルシステムインターフェースを通じてファイルを提供できるようにする。

このデーモンはRPCチャネルを通じて、信頼できるDurable Objectと変更を同期する。これによりLinuxツールには通常のディレクトリを提供しつつ、SQLiteをコンテナ外部の信頼できる情報源として維持する。

Isolateバックエンドはより短い経路を取る。ファイルシステム操作はWorkers RPC経由で同じDurable Objectを呼び出すため、2つ目のストアを維持する必要がない。また、コンテナでの作業後に必要となる同期ステップも不要だ。

これにより、この発表は単なるコード実行サービス以上のものになる。Cloudflare Computerは、よく知られたコンピューターを、永続ファイル、選択可能な実行、同期、公開支援機能へと分解する。基盤インフラはコマンドごとに変わり得るが、エージェントからは1つのワークスペースに見える。

エージェントが単一ランタイムに収まらなくなった理由

エージェントのワークロードは小規模なファイル操作と時折必要になるシステムレベルの作業を混在させるため、固定された単一実行環境は非効率なデフォルトとなる。

コーディングエージェントが一様な仕事だけを行うことはほとんどない。設定ファイルの確認、リポジトリの検索、数行の編集、テスト実行、依存関係のインストール、画像の作成、成果物の公開を行うことがある。これらのアクションには、それぞれ異なるランタイム要件がある。

ファイルの読み取りに完全なLinuxコンテナは不要だ。テキストの解析や、制御されたJavaScriptモジュールの評価も同様である。一方、ネイティブコンパイル、パッケージのインストール、OSツールには通常それが必要となる。

従来のリモートサンドボックスは、こうしたニーズをまとめてパッケージ化する。サンドボックスは単一環境内で、ファイルシステム、シェル、プロセス、ネットワークアクセスを提供する。このモデルは理解しやすいが、永続性と実行を同じライフサイクルに結び付ける。

Cloudflareの従来のSandbox SDKも、そのモデルの多くを踏襲している。同社は、Sandboxesをコマンドおよびファイルシステム環境として最初に発表してから9カ月後の2026年4月13日、一般提供を開始した。

一般提供時点で、各Sandboxはターミナル、バックグラウンドプロセス、ファイル監視、ライブプレビューURL、外向き通信制御、スナップショットを備えた開発環境になっていた。Cloudflareによると、標準アカウントではliteインスタンスを15,000、basicインスタンスを6,000、より大規模なインスタンスを1,000超同時実行できるという。

同社はSandboxesをアクティブCPU課金へ移行し、アイドル状態での待機では課金対象のCPU時間を消費しないようにもした。この変更は、長時間実行されるエージェントセッションに伴うコストの1つに対応した。ただし、コンテナを起動することと軽量なIsolateでコードを実行することのアーキテクチャ上の違いをなくしたわけではない。

Cloudflare Computerは、この違いをルーティングの判断へと変える。バックエンドは遅延接続されるため、最初に作業が到達した時点で初期化される。ワークフローはファイルとIsolateから始め、コマンドが実際に必要とした場合にのみLinuxを利用できる。

この戦略は、エージェントのワークロードには複数のコンピュート規模が必要だというCloudflareのより広範な立場を反映する。同社のAgents Week recapでは、一部のエージェントには完全なOSが必要である一方、大半のタスクにはミリ秒単位で起動する軽量環境が必要だと主張した。

Cloudflare Computerは、この主張に具体的なプログラミングモデルを与える。開発者に無関係なサービス間でファイルを手作業で移すよう求めない。実行境界が変わっても、ワークスペースが継続性を提供する。

フレームワークの作者にとって、この継続性は重要だ。エージェントはread、write、edit、ls、execという標準ツールを受け取れる。このパッケージはAI SDKアプリケーション向けアダプターを提供し、開発者は各バックエンドが処理できる内容を説明する。

するとモデルは、高速なテキスト操作をIsolateへ、より重いコマンドをコンテナへ送れる。これによりバックエンド選択はエージェントのツールポリシーの一部となる。同時に、その説明が不明確だったり、モデルが選択を誤ったりした場合には、新たな障害モードも生まれる。

この設計は、頻繁に停止するエージェントにとりわけ関連性が高い。モデル推論、人間による承認、ネットワークリクエスト、外部API呼び出しはアイドル時間を生む。そのすべての間隔で完全な環境を稼働させ続けることは利便性をもたらすかもしれないが、エージェントの作業を保持する唯一の方法ではない。

永続ファイルシステムによって、セッション状態を消去することなく実行レイヤーを消せる。次のアクションでは、別のバックエンドを通じて同じファイルを再び開ける。単一のマシンがセッション全体を保持していなくても、エージェントの視点ではコンピューターに似たものとなる。

この抽象化はコンテナ優先のプロバイダーに圧力をかけるが、彼らの最も強い主張をなくすわけではない。完全に隔離された環境は、予測可能なツール、慣れたデバッグ、整合性のあるセキュリティ境界を提供する。セッションを複数のランタイムに分割すると、調整と同期に関する懸念が加わる。

また、Cloudflareの製品境界にも圧力をかける。開発者はSandbox SDK、Cloudflare Computer、Dynamic Workers、あるいはその組み合わせのどれが必要かを理解しなければならない。プレビューパッケージは重複を探れるが、本番プラットフォームには最終的に明快な答えが必要となる。

答えはワークロード次第となる可能性が高い。Cloudflare Computerは、多数の小さな操作を行い、ときどきLinuxを必要とするエージェントに適している。ほぼすべての手順がネイティブツール、大規模なローカル依存関係、または高スループットのディスクアクセスに依存する場合には、コンテナの方が明快なままだ。

ここに本当の争点がある。このプレビューは、開発者がプロビジョニングすべき単位がマシンなのか、それとも異なるマシンを借りられるワークスペースなのかを問うている。

Cloudflare Computerが1つのワークスペースを3つのバックエンドに振り分ける仕組み

Cloudflare Computerはランタイム選択を明示的にすることで柔軟性を得る一方、各バックエンドは異なる機能と同期プロファイルを持つ。

Worker shellバックエンドは、一般的なコマンドにとって最も軽量な経路だ。OSプロセスを起動せずに動作するよう設計された、Bash風環境のTypeScript実装であるjust-bashを使用する。

このバックエンドは、永続ワークスペースに対するテキスト中心のシェル作業を処理できる。DockerやCloudflare Containerは必要ない。ファイル操作はDurable Objectへ戻るため、信頼できる状態は1カ所に保たれる。

Worker JavaScriptバックエンドは、シェルコマンドではなくECMAScriptモジュールを処理する。各実行は新しいDynamic Worker内で行われ、構造化された入力を受け取り、構造化された結果を返せる。ワークスペースを利用したファイルアクセスと、設定済みライブラリをサポートする。

CloudflareはGitおよびCloudflare Artifacts向けの信頼済みモジュールも提供する。Git操作は、仮想ファイルシステムに直接接続するisomorphic-gitクライアントを通じて実行できる。コンテナや従来のGitバイナリは不要だ。

コンテナバックエンドは、Isolateでは実行できないタスクを担う。Linux、ネイティブバイナリ、Node.js、npm、ネットワーキング、その他のOS機能を提供する。ワークスペースはcomputerdのFUSEマウントを通じて内部に表示される。

このバックエンドは、最も難しいデータ問題を生む。CloudflareはSQLiteバックの状態をコンテナへ投影し、通常のツールでそれを変更できるようにし、その後に変更を同期しなければならない。このパッケージは、登録されたバックエンドごとに独立した同期カーソルを維持する。

コマンドが成功しても、コマンド後のpullに失敗した場合、実行結果は保留中の同期状態を報告できる。アプリケーションは、上限付き指数バックオフによる再試行を設定できる。ただし、ライブラリはDurable Objectのアラームスケジューリングを管理しない。

この詳細は、依然として多くの責任が開発者に属していることを示す。ユーザーには1つのワークスペースが見えるが、アプリケーションはバックエンド登録、再試行スケジューリング、実行ライフサイクル、未解決の同期を処理しなければならない。

この設計には、規律あるリソース解放も必要だ。RPCレイヤーはリモートスタブを自動回収しない。ワークスペースまたは実行ハンドルを繰り返し取得する長期セッションでは、アプリケーションが各ハンドルを解放しない限り、それらが蓄積する可能性がある。

Cloudflareは、こうした漏洩を検出するためのデバッグ支援を文書化している。それでも、これはプレビュー段階のインフラであり、目に見えないプラットフォームサービスではない。試用する開発者は、その仕組みを理解する必要がある。

ファイル公開は、もう一つの境界をもたらす。このパッケージはワークスペース内のファイルをR2にアップロードし、事前署名付きリンクを返せる。また、コードやビルド出力向けのGit互換ストレージサービスであるCloudflare Artifactsにセッションを接続することもできる。

含まれているチュートリアルの一つは、意図された役割分担を示している。エージェントがワークスペースにMarkdownのレシピカードを書き込み、コンテナ内でpandocを使ってPDFを作成する。ストレージは永続性を保ち、Linuxツールが形式変換を処理する。

別の例では、画像生成をWorkers AIに送信し、結果をワークスペースに書き込み、共有可能なアセットを返す。比較インターフェースでは、同じタスクをコンテナとWorkerランタイムで並行して実行する。

これらの例は、より広範なエージェントのパターンを示唆している。ワークスペースは共有の作業台となり、異なるランタイムは専門ツールのように機能する。エージェントは、すべてのバックエンドを別々のコンピューターとして扱う必要がない。

この仕組みは、知識集約型の開発も支援できる。エンジニアリングチームは、タスクファイル、生成されたレポート、テスト出力をワークスペースに保持し、永続化すべき成果を検索可能なナレッジベースにコピーできる。ランタイムは一時的なままでも、有用な成果物はエージェントセッションを超えて利用可能になる。

ただし、この抽象化には限界がある。コンテナ側のファイルシステムはメモリ上に保持され、Cloudflareは完全なモノレポではなく、エージェント規模のワークスペースを推奨している。およそ10 GBという上限は文書や小規模プロジェクトには十分だが、このサービスが開発用ディスクの汎用的な代替になるわけではない。

Workerバックエンドには、実験的なCloudflare機能とWorker Loaderバインディングも必要となる。パッケージ自体にはnodejs_compat互換性フラグが必要だ。これらの要件は、プレビュー段階であることを裏付けている。

このCloudflare Computerの解説分析において最も重要な点は、isolateがコンテナを置き換えるということではない。置き換えない。この仕組みにより、アプリケーションはコンテナの起動、能力、同期に伴うコストを負担する価値があるかを判断できる。

その選択はアプリケーション層で行うことも、エージェントフレームワークを通じて行うこともできる。モデルはバックエンドの説明を参照し、実行先を選択できる。したがって開発者には、自然言語によるヒントだけでなく、ポリシー制御が必要となる。

本番システムでは、各バックエンドがアクセスできるコマンド、ファイル、ネットワーク、認証情報を制限する可能性が高い。また、なぜコマンドが特定のランタイムに到達したのかを示す信頼できる記録も必要になる。現行のリポジトリは可観測性フックを公開しているが、ガバナンス上の問題全体を解決しているわけではない。

Cloudflare Computerが最も説得力を持つのは、作業を自然に分割できる場合だ。isolateで検索と編集を行い、Linuxでコンパイルし、その後アーティファクトサービスを通じて公開する。すべての操作でコンテナが必要になる場合や、タスクが大きなファイルを繰り返し移動する場合には、その利点は明確ではなくなる。

プレビューに関する警告とベンチマークが訴求を複雑にする

リポジトリは、明示的な本番利用への警告と、大規模な連続ファイル操作で大きなペナルティが生じることを示すベンチマークを含め、異例なほど直接的に制約を提示している。

Cloudflareは、このパッケージが実験、探索、プロトタイプに適しているとしている。APIは不安定であり、設計は変更される可能性があり、このパッケージは本番利用に適していないとしている。

この警告は、Cloudflare Computerが現在提供しているものに関するすべての主張の前提となるべきだ。リポジトリには動作するパッケージ、例、数百件のコミットが含まれるが、設計ドキュメントの一部は将来を見据えたものとなっている。Cloudflareは、これらの仕様を現行コードの説明ではなく、意図として扱うよう読者に求めている。

性能は最も明確なトレードオフだ。同社は、仮想CPU 1基、メモリ6 GiB、ディスク12 GBを備えた標準コンテナ上でcomputerdをベンチマークした。FUSEワークスペースをインメモリファイルシステムおよびコンテナのext4ディスクと比較している。

結果は、メタデータ負荷の高い複数の操作では仮想ファイルシステムに有利だった。1,000ファイルの削除はext4の約3分の2の時間で完了した。ネストしたディレクトリツリーの作成は約4分の3で済み、そのツリーの検索にも同程度の時間しかかからなかった。

100ファイルを含むGitの初期化とコミットは、ext4の635.4ミリ秒に対し、computerdでは459.2ミリ秒だった。約1 MBのリポジトリのshallow cloneは、ディスクの576.2ミリ秒に対し、549.1ミリ秒だった。

大規模な連続操作では逆の結果になった。64 MiBファイルの書き込みは、ext4の16.8ミリ秒に対し、computerdでは230.6ミリ秒かかった。同じ容量のコピーは、39.8ミリ秒に対し1,037.2ミリ秒だった。

64 MiBの単純な読み取りは、ディスクのベースラインより約30倍遅かった。単純なコピーは41倍以上遅かった。こうした差は、アーカイブ、依存関係ツリー、メディア、モデルファイル、データ処理ワークロードで重要になる。

Cloudflareのファイルシステムベンチマークは、速度低下の仕組みを説明している。書き込みパスでは、512 KiBのチャンクをコンテンツアドレス型blobストアへハッシュ化する。これにより重複排除と、変更されたチャンクだけの同期が可能になる一方、生のスループット操作には追加の処理が加わる。

CloudflareのSandbox SDKを完全にインストールしたテストでは、そのコストがより具体的になった。テスト対象は854パッケージと36,675ファイルだった。インストールには、FUSEワークスペースで124.7秒、ext4で63.9秒、メモリ上で34.3秒かかった。

Cloudflareは、ext4をより現実的な汎用利用のベースラインとして位置付けている。そのベースラインと比べると、FUSEでのインストールはおよそ2倍の時間を要した。依存関係の多いJavaScriptプロジェクトを構築する開発者は、この差を実感するだろう。

これらのベンチマークは、設計を無効にするものではない。多くのエージェントタスクは、継続的な連続I/Oではなく、メタデータ、小さな編集、検索、増分変更を伴う。むしろ結果は、バックエンドルーティングが重要になる場面を定義している。

合理的なワークフローでは、ソースファイルを永続ワークスペースに保持しつつ、大きなアーカイブの繰り返し展開を避けることができる。依存関係を別の場所にキャッシュするか、同期オーバーヘッドを上回る価値のあるタスクを選ぶこともできる。Cloudflareはまだ最適な本番パターンを確立していない。

セキュリティには二つ目の不確実性がある。リポジトリは実行面とストレージの挙動を説明しているが、3つのバックエンドすべてが同一の分離を提供すると主張しているわけではない。JavaScript isolate、TypeScriptで実装されたシェル、Linuxコンテナは、本質的に異なる実行環境だ。

Workerシェルが高速なのは、部分的には完全なOSではないためだ。これは互換性を制限するが、コマンドが実行できる範囲を狭めることにもつながる。コンテナはより幅広い機能を提供するため、ネットワークアクセス、パッケージ、認証情報に対してより強力な制御が求められる。

こうした環境間の移動は、ポリシー上の隙間を生む可能性がある。あるバックエンドで拒否されたコマンドが、別のバックエンドでは実行されるかもしれない。タスクが必要としていない場合でも、説明により高い能力が約束されているため、エージェントがLinuxを選択する可能性がある。

パッケージには、ワークスペース接続、同期、実行、ファイルシステム操作のためのobserverフックが含まれる。これらのフックはCloudflareのトレーシングや別のレコーダーにデータを提供できる。有用な基盤ではあるが、本番利用者には認可ルールと監査可能なバックエンド選択ポリシーが必要になる。

永続性は、独自のセキュリティ上の疑問をもたらす。ファイルはDurable Objectの再起動後も残るため、これは長時間タスクにエージェントが必要とする機能だ。永続ワークスペースは、機密性の高いプロンプト、ソースコード、生成された認証情報、ダウンロードしたデータを、意図したより長く保持する可能性もある。

アプリケーションには、リスクに見合う削除ポリシーとテナント分離が必要だ。読み取り専用のR2マウントは参照データの保護に役立つが、データ保持や外部アクセスに関するすべての問題に答えるものではない。

GitHubでの反応は、導入の兆候であって、本番での証拠ではない。リポジトリは8月6日時点で約3,100スターと141フォークを表示していた。特にGitHub Trendingでの位置を考慮すると、これらの数字は発表後の開発者の関心を示している。

しかし、それは信頼性、セキュリティ、継続的な利用を裏付けるものではない。魅力的なアーキテクチャの周囲では、スターが急速に集まることがある。本当の検証は、数週間にわたって稼働し、部分的な失敗から復旧し、ランタイムの変更をまたいでファイルを一貫して保持するワークロードから得られる。

Cloudflareの透明性は、この点で役立つ。不利なI/O数値を公開することで、開発者は実験のためのより良い基盤を得られる。明示的な警告も、Trendingでの順位が一般提供開始と誤解されることを防ぐ。

慎重な結論は明快だ。Cloudflare Computerは、エージェントの状態と実行を分離するための信頼できる仕組みを提供するが、このプレビューは、追加の連携が本番環境で専用サンドボックスを上回ることをまだ証明していない。

GitHubでの急伸後に開発者が注視すべきこと

次の段階は、APIの安定化、実際のワークロードによる証拠、そしてバックエンド選択に対する強制可能なポリシーという3つのシグナルに左右される。

最初のシグナルは、バージョン管理された本番志向のリリースだ。Cloudflare Computerは現在、不安定なAPIと実験的なバックエンド要件を掲げている。安定したインターフェースへの移行は、CloudflareがComputer、Sandbox SDK、Dynamic Workers、Durable Objectsの間にある責任範囲を解決したことを示すだろう。

そのリリースでは、復旧動作を明確にすべきだ。コンテナコマンドが完了したものの同期に失敗した場合、開発者には予測可能な結果が必要になる。また、同時アクセス、クリーンアップ、ストレージ制限、長時間稼働するRPCセッションについての保証も必要だ。

Cloudflareが移行ガイダンスを伴う安定版リリースを公開すれば、アーキテクチャ上の主張はより強くなる。APIが頻繁に変わる、またはパッケージが実験のままなら、チームは引き続きこのリポジトリを設計研究として扱うだろう。

二つ目のシグナルは、完全なエージェントワークロードからの証拠だ。マイクロベンチマークはすでに、FUSEが優れる場面と苦戦する場面を示している。より難しい問いは、isolateとコンテナにコマンドを振り分けることで、総タスク時間、信頼性、リソース使用量が改善するかどうかだ。

有用な評価では、同一のコーディング、調査、データ分析エージェントを比較する必要がある。起動遅延、実行時間、同期失敗、転送ストレージ量、タスクの正常完了を測定すべきだ。生のファイルシステムベンチマークでは、これらを組み合わせた効果を捉えられない。

リポジトリ内の例は出発点であり、特に同じタスクでランタイムを比較するインターフェースは有望だ。独立したテストでは、より大きなリポジトリ、繰り返し行うパッケージインストール、並列エージェント、中断後に再開するセッションを追加すべきだ。

混合ランタイムのワークフローが、より少ないコンテナ起動で信頼性高く完了するなら、Cloudflareの仕組みへの支持は強まる。同期とルーティングがその節約を打ち消すなら、永続的なサンドボックスの方がより単純な選択肢であり続ける。

三つ目のシグナルは、バックエンドポリシーだ。現在、アプリケーションは利用可能なバックエンドを説明し、エージェントに選択させることができる。本番の購入者は、各バックエンドがアクセスできるファイル、ネットワーク、シークレット、コマンドを管理する決定論的な制御を求めるだろう。

Cloudflareにはすでに関連インフラがある。Sandboxプラットフォームにはプログラム可能な外向き通信制御があり、Durable Objectsは非公開で永続的な状態を提供する。Cloudflare Computerは、これらの要素を開発者が理解・推論できるポリシーモデルへ統合する必要がある。

成熟した実装では、権限昇格が可視化されるべきだ。エージェントがWorkerシェルからLinuxへ移行する際、アプリケーションは理由、新たに利用可能になった機能、境界を越えたデータを把握できる必要がある。

この問いはCloudflareにとどまりません。LangChain、Daytona、Ona、Modalなどのプラットフォームも、microVM、コンテナ、永続性、開発者向けツールをさまざまに組み合わせたエージェント環境を追求しています。競争の焦点は、単なる実行速度ではなく、エージェントコンピュータの定義そのものです。

一部のプロバイダーは、信頼できないエージェントコードにはハードウェアレベルの隔離と完全なマシン境界が必要だと主張しています。一方、Cloudflare Computerは分解を重視し、ワークスペースがLinuxを必要とするまで、より軽量な実行環境を利用できるようにしています。タスクごとに求められる隔離の度合いは異なるため、これらの立場は共存し得ます。

エンタープライズ向けコーディングエージェントでは、再現可能なツールチェーンと厳格なテナント境界を備えた専用環境が依然として好まれるかもしれません。大量の文書を扱うエージェントは、永続ファイルと軽量なコマンドの方が恩恵を受ける可能性があります。大規模な入力を扱うデータエージェントでは、FUSE設計のスループット上の制約が明らかになるかもしれません。

したがって開発者は、この概念を採用する前に自らのタスク構成を検証すべきです。ネイティブバイナリを本当に必要とするステップがいくつあるかを数え、ワークスペース内を移動するデータ量を測定してください。意図的に同期障害を起こし、復旧を確認することも重要です。

また、魅力的なエージェント体験と十分なセキュリティ設計を分けて考える必要があります。「一つのワークスペース」は有用なインターフェースですが、すべての実行経路が同じ信頼境界を持つことを意味するわけではありません。ランタイムの昇格は、権限昇格と同じ厳しさで検証に値します。

Cloudflare Computerが重要なのは、この設計上の選択を明示しているからです。開発者に対し、ファイルを永続状態として、実行を選択可能なサービスとして、そして見かけ上のコンピュータを各タスクのために組み立てられる抽象化として扱うよう促しています。

このプレビューが大きく変化したとしても、その枠組みはエージェントインフラに影響を与えるでしょう。エージェントが後からファイルを必要とするという理由だけで、単一のコンテナやmicroVMを稼働し続けることに代わる選択肢を提示しています。

GitHubでの急増は、このアイデアへの関心を裏付けています。ただし、開発者が1台のマシンの運用上の単純さを好むのか、それとも1つのワークスペースを共有する複数ランタイムが約束する効率性を好むのかについて、結論を出すものではありません。

今後数か月は、スター数ではなくリポジトリを注視してください。安定したAPI、エンドツーエンドのベンチマーク、厳格なバックエンドポリシーが、Cloudflare Computerが本番インフラになるのか、それとも魅力的なプレビューにとどまるのかを決定するでしょう。

cloudflare computer previewを評価するチームは、まず限定的なワークロードから始め、すべてのランタイム遷移を記録し、永続状態を信頼する前に復旧をテストすべきです。本当にLinuxを必要とする操作はどれで、ファイルと小さな実行環境だけで足りる操作はどれでしょうか。トレースと障害テストによってこの問いに答えれば、ハイブリッドモデルが自社のエージェントに適しているかどうかが分かります。同時に、従来型のサンドボックスの方が保護と運用を容易に行える場面も明らかになります。より大きな教訓はすでに有用です。エージェントのコンピュータは、恒久的に稼働する1台のマシンである必要はありません。しかし、それをサービスに分割すれば、複雑さはルーティング、同期、ポリシーへと移ります。これらの仕組みは実装詳細ではなく、中核インフラとして扱うべきです。