Cloudflare Computerとは：AIエージェントにDurable Object上の仮想FSと実行環境を与えるOSS

Cloudflare Computer（cloudflare/computer）は、AIエージェントに「ファイルの読み書き」と「コマンド実行」の両方を与えるためのCloudflare発OSSだ。多くの人はこの用途にサンドボックスVMやコンテナを立ち上げ、その中でシェルを叩かせる。しかしサーバーレスのエッジ環境では、そもそも永続ディスクも常駐プロセスも無い。この断絶を「Durable Object内の仮想ファイルシステム」という一手で埋めにきたのがcloudflare computerで、リポジトリのタグラインはそのものずばり「Give your agent a computer 👾」。2026年6月の公開からわずか2か月でGitHubスターは約7,500に達している（2026-08-11時点で7,492）。

本記事では、cloudflare computer の正体・アーキテクチャ・3つの実行バックエンド・最小コード・制限までを、公式README／docs／npmの一次情報だけを根拠に日本語で整理する。日本語の単体解説がまだほぼ存在しないOSSなので、「結局これは何ができて、何を解決し、既存のサンドボックスと何が違うのか」に的を絞る。

このテーマの全体像（LangGraphやCrewAIなど主要フレームワークの位置づけ）を先に押さえたい場合は、まずAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を読むと、Computerが「フレームワーク」ではなく「エージェントに持たせる下回りのプリミティブ」であることが掴みやすい。

Cloudflare Computerとは——AIエージェントに“コンピュータ”を与えるプリミティブ

READMEの冒頭はこう定義している。「Cloudflare Computer is a virtual filesystem that lives inside a Durable Object. The Durable Object holds the authoritative state in SQLite and exposes one pluggable execution surface through workspace.runtime.」——つまり 「Durable Objectの中に住む仮想ファイルシステムで、SQLiteに正本の状態を持ち、workspace.runtime から1つのプラガブルな実行面を露出する」 ものだ。

ここで言う「コンピュータ」は、VMを丸ごと1台という意味ではない。エージェントが1つの作業ディレクトリを持ち、そこにファイルを書き、コマンドを走らせ、結果をまた同じディレクトリに残せる——その最小単位を指す。パッケージ版READMEはさらに直截で、「A persistent, SQLite-backed virtual filesystem for Durable Objects, with pluggable command and code execution. Built for agents that need a small, portable working directory and the tools to read, write, and run things in it.」と書いている。キーワードは persistent（永続）／portable（持ち運べる）／agent-scale（エージェント規模） の3つだ。

この設計が効くのは、Cloudflare Workers というランタイムの制約が背景にあるからだ。Workersは各リクエストを短命なアイソレートで処理し、ローカルの永続ディスクを持たない。そこで状態を持てる唯一の一級市民が Durable Object であり、ComputerはそのDOのSQLiteストレージをファイルの実体として使う。言い換えれば、Cloudflare Workers上で「作業ディレクトリを持つエージェント」を成立させるための、ステートフルな受け皿がComputerだ。

同じ「エージェントに隔離された実行環境を与える」という課題に対し、TencentのCubeSandbox：AIエージェント向けmicroVMサンドボックスは「起動の速いmicroVMを1エージェント1台で割り当てる」方向で解いている。Computerはこれと対照的に、専用VMを立てずにDurable ObjectのSQLiteを正本にする——エッジのステートフルプリミティブ（DO）を作業ディレクトリの実体として使い切る発想だ。どちらが優れているという話ではなく、「常駐リソースを持つか／持たないか」で設計思想が割れている。

アーキテクチャ：SQLiteが正本、3つの実行バックエンドを1つの入口で

Computerの心臓は 「Durable Object内のSQLiteが唯一の正本（source of truth）」 という一点だ。ファイルの実体はSQLiteに入っており、Durable Objectが再起動してもデータは消えない。上に載る「Node Virtual FS」はそのSQLiteをnode:fs/promises風に見せる薄い層で、冒頭のアーキ図で言えば下段のDurable Object側がこれにあたる。

実行系（execution surface）はこの正本に対して差し込む。READMEは「Three backends ship today（今日出荷されている3つのバックエンド）」として次を挙げる。

① Container — READMEいわく「projects the SQLite state into a sandbox container as a real FUSE mount」。コンテナ側のデーモン computerd がSQLiteの状態を実FUSEマウントとしてマウントし、変更を capnweb のRPCチャネルでDOに同期し戻す。「Full Linux userland, real binaries, real network」——本物のLinuxユーザーランドで、実バイナリと実ネットワークが使える。重い外部ツール（例：pandoc）を回すのはこの系だ。

② Isolate shell — 「runs just-bash in a Dynamic Worker」。軽量シェル実装 just-bash をDynamic Worker上で走らせる。正本のWorkspaceにはWorkers RPCで直接届くため、別ストアも同期のラウンドトリップも無いのが利点。コンテナを立てない分、起動が軽い。

③ Isolate JavaScript — 「runs an ECMAScript module in a fresh Dynamic Worker」。まっさらなDynamic WorkerでJSモジュールを評価し、構造化した入出力・相対import・Workspace連動のnode:fs/promises・ws:git／ws:artifactsといった信頼モジュールを与える。シェルコマンドではなく「関数呼び出しに近いJS実行」をしたいときに使う。

これら3つは workspace.runtime.exec(source, { backend }) という単一の入口 に集約される。READMEは「workspace.runtime.exec(source, { backend }) is the single execution entry point; the selected backend defines whether source is a shell command or an ECMAScript module. Backends connect lazily on first use.」と説明する。選んだバックエンドによって、渡す source がシェルコマンドかJSモジュールかが決まり、バックエンドは初回利用時に遅延接続される。バックエンドを1つも登録せず、ファイルシステム単体でWorkspaceを作ることもできる。

ここで登場する capnweb は、Cloudflareのオブジェクトケーパビリティ型RPC（cloudflare/capnweb。「low-boilerplate, object-capability RPC system」）で、Container側のcomputerdとDurable Objectの間のワイヤープロトコルとして使われている。姉妹パッケージ @cloudflare/computer-rpc が「capnweb wire types and server/client helpers shared between the Durable Object and computerd」として、この同期の土台を担う（capnweb は ^0.8.0 を依存に持つ）。

ファイルシステムAPI（workspace.fs）

workspace.fs は見た目も使い勝手も node:fs/promises に寄せてある。READMEで確認できるメソッドは readFile / writeFile / mkdir / readdir / rm / grep（加えてstat）。すべて非同期・絶対パスで、DO再起動をまたいで永続する。文字列はUTF-8既定、バイナリはUint8ArrayかReadableStreamを渡す。grep(pattern, path, { ignoreCase }) はヒットを .path／.line／.text で返す実装だ。R2バケットを mounts で読み取り専用マウントすることもでき、その配下への書き込みは EROFS で弾かれる。

Cloudflare Computerのインストールと最小コード

導入は npm 一発だ。

npm install @cloudflare/computer

ファイルシステムだけを使う最小構成では、Workerに nodejs_compat 互換フラグとDurable Objectバインディング、SQLiteマイグレーションを設定する。

{
  "compatibility_flags": ["nodejs_compat"],
  "durable_objects": { "bindings": [{ "name": "Agent", "class_name": "Agent" }] },
  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["Agent"] }]
}

worker-shell などIsolate系で exec を使うなら、experimental フラグと Worker Loader バインディングを足す。

{
  "compatibility_flags": ["nodejs_compat", "experimental"],
  "worker_loaders": [{ "binding": "LOADER" }]
}

コード側の最小例はこれだけだ。ファイルを書き、そのファイルをシェルで読む——fs の書き込みと exec の実行が同じ正本を見ていることがわかる。

using ws = await getWorkspace(env.Agent.get(id));
await ws.fs.writeFile("/hello.txt", "world");
using run = await ws.runtime.exec("cat /hello.txt");
const { stdout, exitCode } = await run.result();

exec の戻り値は 「バッファ済み結果としても待てるし、ライブなイベントストリームでもある」 二面性を持つ。await run.result() で { stdout, stderr, exitCode } をまとめて受け取れる一方、同じハンドルは ReadableStream なので run.pipeThrough(...) でSSEのように逐次流せる。exec の周辺には getExec / killExec / disposeExec が用意され、実行の取得・停止・破棄ができる。

3つのバックエンドの使い分け

同じ exec でも、選ぶバックエンドで「できること」と「重さ」が変わる。用途に応じて登録IDを切り替える。

構造化したinputを受けてvalueを返せるバックエンド（worker-javascriptなど）は callable: true を宣言する。非callableなバックエンドにinputを渡すと「静かに握り潰さず、明確なエラー」になる設計だ。Containerのプレビルド・デーモンイメージは ghcr.io/cloudflare/computer-computerd-linux-x64:0.1.1 として配布され、computerd は PID 1 で動かす必要がある（MOUNT_POINT=/workspace、FUSE_MOUNT=auto）。

同じCloudflare発でも、CloudflareのAIコードレビュー・マルチエージェントが「複数エージェントの協調でPRを読む」プロダクト寄りの実装なのに対し、Computerは「そのエージェント達が土台として踏むFS＋実行環境」を提供する層だと捉えると、Cloudflareのエージェント・スタックの中での役割分担が見えてくる。

何に使える？8つの公式サンプルで見るユースケース

READMEには8つの動くサンプルが並ぶ。抽象的な「仮想FS」が、具体的に何を作れるのかはここを見るのが早い。

とりわけ tutorial は「ホスト側でファイルを書き、コンテナ側で外部ツールを実行し、結果をR2の署名付きリンクで返す」という一連の流れを最短で体験できる。READMEのASCII図がそのパイプラインを端的に示している。

POST /prompt ──► RecipeAgent
                   │ fetch_url https://openstove.org/...      (host)
                   │ write     /workspace/card.md             (host)
                   │ bash      pandoc card.md -o card.pdf     (container)
                   ▼
                 R2 ──► signed link, good for a day

このパターンは、OpenHandsのような「ファイルシステム上でコードを編集し、コマンドを回して自律的に開発するエージェント」を、専用VMではなくエッジのDurable Object上で軽量に組み直したい場合の下地になりうる。もちろん現時点はPREVIEWなので、実運用ではなく「作れるかを試す」段階だ。

パッケージのエントリポイント（export map）も用途別に切られている。@cloudflare/computer/tools（AI SDK向けのread/write/edit/lsツール）、@cloudflare/computer/git（isomorphic-git連携）、@cloudflare/computer/assets（R2への共有リンク化）、@cloudflare/computer/artifacts（Cloudflare Artifacts連携）などがあり、シェル機能もcurl／python／sqlite／jq／yqなどをフィーチャーグループとして必要な分だけimportできる。

制限と注意点

魅力的なプリミティブだが、READMEの「Limits」は現実的な線引きをしている。

・1ワークスペース約10GBまで：ストレージはDurable Objectと共有する
・Container側のFSはメモリ保持：「Aim for agent-scale workspaces, not full monorepos（巨大monorepoではなくエージェント規模を狙え）」と明記
・コンテナI/OはFUSE経由：大きなnode_modulesや巨大tarballの展開はネイティブディスクより遅い
・PREVIEW ONLY：APIは不安定、本番非推奨。docs/の仕様は「将来の意図」
・PRは受け付けない設定：pull_request_creation_policy: collaborators_only。フィードバックはDiscussions経由

つまりComputerは「巨大リポジトリのビルド基盤」ではなく、エージェントが持ち歩く小さな作業机として設計されている。ここを取り違えて重いワークロードを載せると、メモリ制約とFUSE I/Oの遅さに当たる。逆に「LLMが数ファイルを書いて外部ツールを1本回す」程度の粒度なら、VMを立てるより圧倒的に軽い。

参照ソース

・cloudflare/computer（公式リポジトリ・README） — アーキテクチャ・3バックエンド・Limits・PREVIEW表記の一次情報
・cloudflare/computer docs/README.md（設計仕様） — Workspaceインターフェイス・アーキ図（arch.png）・コンテナ要件
・@cloudflare/computer（npm） — 配布バージョン（latest 0.1.1）・依存（capnweb ^0.8.0 / just-bash ^3.0.1）
・cloudflare/capnweb（RPC基盤） — Container↔Durable Object間で使われるobject-capability RPCの一次情報