お問い合わせ
ブログ一覧
Matsuo Tatsuhiko

エージェントに渡すのはコンテナではなく「コンピュータ」 — Cloudflare の @cloudflare/computer を実際に動かした

本記事は公開時点（2026年08月12日）の情報です。AI関連のサービスや仕様は変化が速いため、最新の情報は各公式サイトをご確認ください。

先日の記事でエージェントにブラウザを渡してE2Eテストをさせたとき、いちばんの学びは「信頼性を決めるのはモデルではなく実行環境」ということでした。ちょうどその実行環境の側で、Cloudflare から面白い提案が出ています。Your agent needs a computer, not a container（2026年8月3日、Matt Carey / Aron Carroll）——エージェントに必要なのはコンテナではなく「コンピュータ」だ、というタイトルの通り、@cloudflare/computer というエージェント向けランタイムのオープンソースプレビューです。

読むだけでは分からないことが多かったので、手元で動かしました。

何が新しいのか: ファイルシステムが主役

エージェントにコード実行環境を渡すやり方は、コンテナ型サンドボックス（E2B や Cloudflare 自身の Sandbox SDK など）が定番になりつつあります。@cloudflare/computer の設計はそこから一歩ずれていて、主役は実行環境ではなくファイルシステムです。

Durable Object の中に SQLite で仮想ファイルシステム（VFS)を持ち、これが唯一の正のデータとして永続化されます。その上に実行バックエンドが3枚差し替え可能になっています。

  • worker-shell: just-bash というシェルの JavaScript 再実装を、動的に生成した Worker（isolate）の中で走らせる。ミリ秒起動
  • container: 本物の Linux コンテナを起動し、VFS を FUSE マウントとして投影する
  • worker-javascript: シェルなしで ECMAScript モジュールを直接実行する

どのバックエンドで作業しても同じファイルツリーに読み書きするので、「軽い処理は isolate、本物の Linux が要るときだけコンテナ」という使い分けが1つのワークスペース内で成立します。Cloudflare は作業の9割を isolate に寄せ、コンテナは1割未満に抑えることを目標に掲げていて、フロンティアモデルは適切なランタイムを自分で選べる、というのが彼らの主張です。余談ですが、isolate 側の心臓部である just-bash が Vercel Labs 製の OSS というのは、両社の関係を考えるとなかなか味わい深い採用です。

動かしてみる: まず本番デプロイで弾かれる

リポジトリの examples/worker-shell を Cloudflare アカウントにデプロイしようとしたところ、最初の学びがありました。

The compatibility flag experimental is experimental and cannot yet be
used in Workers deployed to Cloudflare. [code: 10021]

isolate バックエンドが依存する Worker Loaders（動的 Worker 生成）はまだ experimental フラグが必要で、そのフラグ付き Worker は本番にデプロイできません。つまり執筆時点の isolate バックエンドは wrangler dev（ローカル）専用です。「early preview」は誇張ではなく文字通りの意味でした。以降の計測はすべてローカル実行（miniflare + OrbStack 上の Docker）のもので、エッジ本番の数字ではない点は割り引いてください。

isolate バックエンド: 2〜3ms で返ってくるシェル

ローカルで起動した worker-shell に、HTTP 経由でシェルコマンドを投げます。

curl -X POST localhost:8899/c/demo/exec \
  -H 'content-type: application/json' \
  -d '{"command":"cat /workspace/notes/memo.txt | grep -o SQLite | wc -l"}'
# => {"status":"completed","exitCode":0,"stdout":"1\n",...}

ウォーム状態の exec は実測2〜3ms。パイプも grep も wc も普通に動きます。R2 バケットを /workspace/r2 にマウントする機能もあり、読み取りは透過的、書き込みは read-only mount としてきちんと拒否されました。

面白いのはコマンドがopt-in 制なところです。Worker のコードで @cloudflare/computer/shell/jq のように import したコマンド群だけがバンドルされ、それ以外は存在しません。試しに python3 --version を投げると、こう返ってきます。

bash: python3: command not available in browser environments.
Exclude 'python3' from your commands or use the Node.js bundle.

さらに just-bash の curl で外部サイトを叩いたら、Workers らしいエラーに遭遇しました。

curl: (1) This worker is not permitted to access the internet via
global functions like fetch(). It must use capabilities (such as
bindings in 'env') to talk to the outside world.

動的に生成された Worker は素の fetch() すら持たず、ホストが明示的に渡した capability（binding）経由でしか外に出られない。エージェントに任意コマンドを実行させる前提のランタイムとして、デフォルトが「外に出られない」側に倒してあるのは好感が持てる設計です。

コンテナバックエンド: RPC 不整合を踏んでから本領

次に examples/container を動かしたところ、あらゆるコマンドが /bin/sh: 1: undefined: not found で落ちる状態に遭遇しました。原因は GitHub の main ブランチからビルドしたライブラリと、コンテナ内で動く公開版 computerd 0.1.1 の RPC プロトコル不整合。npm の公開版 0.1.1 にライブラリを固定したら解消しました。プレビュー段階の OSS を main で追いかけるとこうなる、という教訓です。

揃えてしまえばコンテナ側は素直で、中身は本物の Debian です。

curl -X POST localhost:8898/c/demo/exec -H 'content-type: application/json' \
  -d '{"command":"node -v && uname -a && git --version"}'
# => v22.23.2 / Linux ... x86_64 GNU/Linux / git version 2.47.3

肝心の「同じファイルを見ているか」も確かめました。VFS の HTTP API で書いたファイルをコンテナの bash から cat すると読め、逆にコンテナ内で echo > したファイルは VFS API から読めます。SQLite が正、コンテナは FUSE 越しの投影というアーキテクチャは、実際にその通りに動きました。

実測値を並べるとこうなります（いずれもローカル環境の参考値）。

バックエンド 実体 exec 実測 できること
worker-shell just-bash を動的 Worker で実行 2〜3ms import したコマンド群のみ（curl, jq, python 等を選択）
container Debian コンテナ + FUSE ウォーム35ms / コールド1.9秒 制約なし（node, git, apt なんでも）

ウォーム同士でも10倍強、コールドスタートまで含めれば3桁の差。「9割を isolate に」という Cloudflare の目標値は、この差を見ると経済合理性の話として腑に落ちます。

冷静な注意点

触ったからこそ書ける制約を挙げておきます。まず前述の通り、isolate バックエンドは本番デプロイ不可（Worker Loaders が experimental のため）で、料金も未公表。RPC 不整合のようなプレビュー品質の荒さも現役です。just-bash は bash の再実装であって完全互換ではなく、コマンドの opt-in 制は安全装置であると同時に「エージェントが使いたいコマンドを事前に予想して仕込む」設計負担でもあります。そして全体が Durable Objects 前提なので、この仕組みに乗る＝Cloudflare に乗る、です。VFS が SQLite ということは、巨大なリポジトリや大容量ファイルをどこまで捌けるかも未知数で、ここは今後の検証課題です。

エージェントには「安全に壊せる場所」が要る

エージェントテストの記事で、エージェントは障害を報告するより先に回避してしまう、と書きました。だからこそ実行環境側には「何をしても外に影響が出ない」保証が要ります。@cloudflare/computer の capability ベースの閉じたネットワーク、読み取り専用マウント、SQLite に正を置いて実行環境を使い捨てる構造は、その要件への一つの答えに見えます。プロダクションで使うのはまだ早い。でも「エージェントに何を渡すか」の設計を考えるうえで、コンテナ一択の前提を疑わせてくれる良いプレビューでした。

エージェントにどこまで実行権限を渡すか、業務のどこなら安全に任せられるか——そうした設計の相談はAI・業務自動化の支援で承っています。