Cloudflareが公開している cloudflare/computer というリポジトリをご存知でしょうか。名前だけ見ると「Cloudflare上で何かを操作する管理ツール」のようにも読めますが、実態は少し違います。
この記事では、「AIエージェントにコードを書かせたい」「MCPと何が違うのか気になる」という人向けに、よくある疑問をFAQ形式で整理しつつ、リポジトリの中身と実運用のTipsをまとめます。
- リポジトリ: https://github.com/cloudflare/computer
- 現状: プレビュー版(API不安定、本番利用非推奨)
まず結論: 一言でいうと何なのか
「AIエージェントに、クラウド上で消えない“作業場”(ファイルシステム＋実行環境)を持たせるための基盤ライブラリ」です。
エージェントAIの「頭脳」(LLM呼び出しの部分)はこのリポジトリの範囲外で、Cloudflareのagentsリポジトリなど別レイヤーが担当します。computerが担当するのは、エージェントが実際にファイルを書いたり、gitやnpm、シェルコマンドを実行したりするための「体」の部分です。
FAQ
Q1. MCP(Model Context Protocol)と何が違うの?
似たような文脈で語られがちですが、レイヤーが異なります。
| MCP | cloudflare/computer | |
|---|---|---|
| 役割 | LLMと外部サービス(Gmail、GitHub等)を繋ぐ会話プロトコル | エージェントにファイルシステムと実行環境そのものを与えるインフラ |
| 例えるなら | 「ツールを呼び出す窓口」 | 「エージェントが作業する部屋そのもの」 |
MCPが「何ができるか(機能呼び出し)」を定義するのに対し、computerは「どこで作業するか(実行環境)」を提供する、と考えると整理しやすいです。
Q2. Cloudflareで運用している複数のWebサービスを、これで一括管理できる?
できません。 これは既存の本番サービス群を横断的に操作する管理コンソールではなく、「エージェント1体につき1つの作業スペース(Durable Object)を安価に大量生産するための土台」です。
複数サービスを個別にエージェントへ触らせたい場合は、サービスごとに専用のWorkspaceインスタンスを立てる、という設計になります。「複数Workspaceを束ねて横断操作する上位のオーケストレーション層」は、このリポジトリの守備範囲外なので自前で組む必要があります。
Q3. 「専用のエージェントAIをクラウド上で稼働させるためのもの」という理解で合ってる?
方向性としては正しいです。ただし2点補足が必要です。
- エージェントAI自体(LLM呼び出し)は範囲外。
computerが提供するのは実行環境(体)の部分のみ。 - 「常時フル稼働」ではなく「必要な時だけ低コストで展開」に近い。 Cloudflareの Durable Objects はアイドル時に休眠し、必要な時に起きる設計のため、ユーザー単位・セッション単位で大量に並行稼働させてもコストを抑えられます。
Q4. クラウド上のサンドボックスと何が違う?
「クラウド上のサンドボックス」という理解でほぼ正解ですが、一般的なサンドボックスとの決定的な違いは状態が永続化されることです。
| 一般的なサンドボックス | cloudflare/computer | |
|---|---|---|
| ライフサイクル | 実行が終わったら消える(使い捨て) | Durable Object内のSQLiteに正規の状態として保持され続ける |
| ファイルシステム | コンテナのローカルディスク | 仮想ファイルシステムがDurable Object側にあり、実行環境側は後から同期される |
| 実行方式 | 1環境=1コンテナが基本 | 3種類の実行バックエンドを同じWorkspaceに対して使い分け可能 |
つまり「サンドボックス」＋「その中身が消えないように保存される仕組み」がセットになったもの、という理解が近いです。エージェントが同じプロジェクトに何日も断続的に作業しても、前回のファイルがそのまま残っている状態を安く維持できるのが売りです。
Q5. 今すぐ本番サービスで使ってもいい?
現時点では非推奨です。READMEには「プレビューのみの提供であり、APIは不安定でデザインも変更される可能性がある。実験・探索・プロトタイプ向けであり、現時点では本番利用に適さない」と明記されています。技術トレンドとして押さえつつ、実運用は今後のアップデートを待つのが無難です。
リポジトリ構成の解説
cloudflare/computer は小規模なモノレポで、主要なディレクトリ・パッケージは以下の通りです。
cloudflare/computer/
├── .agents/skills/ # エージェント向けのスキル定義
├── docs/ # 設計仕様(将来構想。現在のコードの説明ではない点に注意)
├── examples/ # 実際に動かせるサンプル群
├── packages/ # 中核パッケージ群
├── AGENTS.md # エージェントとして作業する際の手引き
└── CONTRIBUTING.md # 開発・テスト・コミット規約コアパッケージ(packages/)
| パッケージ | 役割 |
|---|---|
@cloudflare/dofs | Durable Object SQLite上に構築された仮想ファイルシステム本体。同期プロトコルの部品も含む |
@cloudflare/computer-rpc | Durable Objectとcomputerdの間で使われるcapnweb通信の型・ヘルパー |
@cloudflare/computerd | サンドボックスコンテナ内で動く常駐デーモン。FUSEマウント＋HTTP/WebSocket RPCサーバー |
@cloudflare/computer | 上記を束ねる、Durable Objectから利用するトップレベルパッケージ(開発中) |
3つの実行バックエンド
- Container — サンドボックスコンテナ内で
computerdがFUSEマウントとして仮想ファイルシステムを展開。完全なLinux環境・実バイナリ・実ネットワークが使える、最も「本物のマシン」に近い方式。 - Isolate shell — Dynamic Worker内で軽量シェル(
just-bash)を実行。Workers RPC経由で直接Workspaceにアクセスするため同期のオーバーヘッドがない。 - Isolate JavaScript — Dynamic Worker内でECMAScriptモジュールを実行。
node:fs/promises相当のAPIやgit/artifacts用の信頼済みモジュールも使える。
用途に応じてこの3つをworkspace.runtime.exec(source, { backend })という単一のエントリポイントで切り替えられる設計になっています。
サンプル(examples/)
examples/container— コンテナ内でcomputerdを動かし、Durable Objectとcapnweb経由で通信する一番フルスペックな例examples/worker/examples/worker-shell— コンテナなしでDynamic Worker上のシェルだけを使う軽量版examples/think— エージェントがWorkspaceを作業ディレクトリとして使うチャットエージェントの例。一番イメージが掴みやすいサンプルexamples/tutorial— 最小構成のチュートリアル。エージェントがコンテナ上でmarkdownを書き、pandocを実行するだけのシンプルな例
パフォーマンス傾向(ベンチマークより)
公開されているベンチマーク(script/fs-bench.sh)によると、傾向は以下の通りです。
- 得意な領域:
stat、rm、mkdir tree、find tree、git init、git clone、npm initなどメタデータ操作中心の処理は、実ディスク(ext4)より高速なケースが多い - 苦手な領域: 64MiB単位の大きなファイルの逐次読み書きはtmpfsや実ディスクより大幅に遅い(数十倍のオーダー)
- 実利用への影響: 大きなファイルI/Oが遅い一方、
npm installのような実際の開発ワークロードでは実ディスクと同等程度の速度になっており、日常的な開発作業への実害は限定的
コンテンツアドレス化されたブロックストアに512KiBチャンク単位でハッシュを取りながら書き込む設計のため、生スループットは犠牲になるが、変更差分だけを同期できる・重複排除できるというトレードオフになっています。
運用するならこう使う: Tips
現時点はプレビュー版という前提で、試すなら以下のような使い方がおすすめです。
Tip 1: まずは examples/tutorial から触る
いきなりexamples/containerのフル構成に挑むより、最小構成のexamples/tutorial(markdown書き込み＋pandoc実行)から始めると、Workspace・runtime・execの関係性が掴みやすいです。
Tip 2: 「1エージェント=1サービス」の粒度でWorkspaceを分ける
複数サービスを扱いたい場合は、サービスごとに別々のWorkspace(Durable Object)を立てる設計にする。横断オーケストレーションは自前実装が前提になる点を最初から織り込んでおく。
Tip 3: 大きなファイルを大量に読み書きする用途には向かない
ベンチマーク上、64MiB級の大きいファイルの連続読み書きは大きく遅くなります。ビルド成果物のキャッシュや動画・大容量データセットの置き場としてではなく、ソースコードや設定ファイルなど「メタデータ操作が多い軽量なファイル群」の置き場として使うのが現実的です。
Tip 4: バックエンドは要件で使い分ける
- 本物のLinux環境やネットワークアクセスが必要 → Container
- 軽量なシェル操作だけで十分・同期オーバーヘッドを避けたい → Isolate shell
- JavaScriptロジックをサンドボックス内で完結させたい → Isolate JavaScript
Tip 5: 本番投入は避け、PoC・社内ツールから
READMEが明言している通り、まだAPI変更が入りうる段階です。エージェント基盤の技術検証や、社内向けプロトタイプでの採用に留め、本番のミッションクリティカルなサービスへの組み込みは次のメジャーアップデートを待つのが安全です。
まとめ：作業場を持つエージェントという発想
cloudflare/computer を一言でまとめるなら、AIエージェントに「消えない作業場」を持たせるためのインフラであり、MCPと競合するものではなく組み合わせて使うものだ、ということに尽きる。MCPが「何ができるか」の窓口だとすれば、computerは「どこで作業するか」の部屋を用意する役割で、両者はレイヤーがそもそも違うわけだ。
象徴的なのは、Durable Object内のSQLiteに仮想ファイルシステムを保持する設計で、エージェントが同じプロジェクトを何日も断続的にいじっても前回の続きから作業できる点。使い捨てのサンドボックスとは前提が違う分、メタデータ操作は速いが大容量ファイルの逐次I/Oは遅いというトレードオフも受け入れる必要がある。
私自身はCloudflareを使っていないので今すぐ触る予定はないけれど、AIエージェントを常駐させて長期プロジェクトを任せたい人にとっては、状態を安く持続させる仕組みとして視野に入れておく価値があるはずだ。プレビュー版である今のうちにPoCレベルで触っておくのが、次のメジャーアップデートに備える一番現実的な動き方じゃないかなと思っている。
