Cloudflare Computerとは｜AIエージェント永続ファイルシステム

AI エージェントに「コード実行環境」と「永続的なファイルシステム」を持たせる基盤として、E2B・Daytona・Cloudflare 自身の sandbox-sdk など複数の OSS が並び立つ状況になっています。多くはコンテナや microVM を隔離単位に据える設計ですが、2026 年 8 月に early preview として公開された @cloudflare/computer は、状態の中心に Durable Object + SQLite を置くという異色のアプローチを取っています（Cloudflare Changelog: Cloudflare Computer より）。

とはいえ、公開直後のパッケージであり、README や公式ブログには「Container backend」「Isolate shell backend」「Isolate JavaScript backend」といった 3 種のバックエンドや、Workspace / workspace.runtime などの新しい抽象が並びます。既存の E2B や Daytona との差分、そして自社プロジェクトで採用してよいかを短時間で判断したい読者にとって、概要記事だけでは全体像を掴みづらい構成になっています。

本記事は初見のエンジニアが「Cloudflare Computer とは何か」「類似 OSS とどう違うのか」「PREVIEW 段階でどこまで踏み込んでよいか」を意思決定できる粒度で整理することを目的とします。動作検証は行わず、GitHub リポジトリ（cloudflare/computer）の README、公式ブログ、Cloudflare Changelog、docs/ ディレクトリの設計仕様書のみを一次情報として参照します。

本記事では、リポジトリ基本情報と PREVIEW ステータス、設計思想、アーキテクチャの全体像、3 つの実行バックエンド、モノレポのパッケージ構成、examples/ の読み方、類似 OSS（cloudflare/sandbox-sdk / E2B / Daytona）との差分、そして採用判断のポイントを順に解説します。

Cloudflare Computer とは

@cloudflare/computer は、AI エージェントに「1 台のコンピューター」を与えるための仮想ファイルシステム + 実行環境の基盤 OSS です。GitHub 上のリポジトリ cloudflare/computer で MIT ライセンスの下で公開されています。README の説明を要約すると、Durable Object 内に住む「仮想ファイルシステム」を提供し、Durable Object 側が権威ある状態（authoritative state）を SQLite で保持したうえで、workspace.runtime という 1 つのプラガブルな実行サーフェスを公開する構造になっています。

対象読者は、ファイル操作・データ処理・シェル実行・Git リポジトリ連携などを行う AI エージェントの開発者です。Cloudflare の Durable Objects を Workspace（ファイルシステム）のホストとし、Workers / Dynamic Workers を隔離ランタイム、Containers をフル Linux 環境が必要なタスク向けに使い分ける構成が公式に案内されています（Cloudflare Changelog: Cloudflare Computer より）。

リポジトリの基本情報

本記事執筆時点のリポジトリ基本情報は以下のとおりです（値は gh api /repos/cloudflare/computer で取得したメタデータに基づきます）。

archived=false かつ fork=false であり、Cloudflare 本体がアクティブに開発しているリポジトリです。最終コミット時刻も執筆日（2026 年 8 月 22 日）の前日に更新されており、リリース直後らしい高頻度のコミット活動が続いています。

PREVIEW ステータスと本番採用可否

一方で、README では明確に「PREVIEW ONLY」であることが強調されています。パッケージはフィードバック目的のプレビュー版であり、API は不安定で設計変更もあり得ること、そして「実験・探索・プロトタイプ向け」であって本番用途は想定されていないことが示されています（cloudflare/computer README より）。また、docs/ ディレクトリは「現在のコード動作の記述ではなく、意図を示す前方参照ドキュメント」であることも明記されており、docs の記載と現在の実装挙動が食い違い得る点にも注意が必要です。

Cloudflare 公式の Changelog でも「early preview」として位置づけられており、本番採用の前段階として設計思想やインタフェースへのフィードバックを収集するフェーズであることが読み取れます（Cloudflare Changelog: Cloudflare Computer より）。したがって現時点で採用を検討する場合、対象フェーズは POC・プロトタイプ・研究開発が中心となります。

「なぜコンテナではなくコンピューターなのか」の設計思想

Computer の設計思想を最も端的に説明しているのが、リリースと同日に公開された Cloudflare 公式ブログ「Your agent needs a computer, not a container」（日本語版もあります）です。この記事の主張を踏まえないと、なぜ「コンテナが第一級市民ではないアーキテクチャ」を選んだのかが理解しづらくなります。

コンテナ中心の従来アプローチの限界

公式ブログは、従来のコンテナ化アプローチが「全企業・全ユーザーごとに個別のエージェント環境を作る」というスケールに耐えないという課題認識から出発しています。同ブログの言葉を借りれば「世界中のあらゆる企業のあらゆるユーザーのエージェント分のコンテナ計算基盤を提供できるほどの compute は、この星に存在しない」という前提です（Your agent needs a computer, not a container より）。

そのうえで、エージェントに必要なのは「隔離されたコンテナ」ではなく「完全なコンピューティング環境」であり、開発者が手動でオーケストレーションする必要のない、プラットフォーム側で最適な実行環境を選択する仕組みだと述べられています。従来は「頭脳（エージェントループ）」と「手（サンドボックス）」が別々のインフラに分離していたのを、Computer は「インテリジェントなランタイム選択」で再統合する、という位置づけです。

ハイブリッド実行と統一 API

もう一つの重要なメッセージは「10% 未満の作業がコンテナを必要とする」という目標です。多くのファイル操作・スクリプト実行は軽量な Isolate（Cloudflare Workers のランタイム）で十分にこなせるはずであり、真にフル Linux ユーザーランドが必要な作業だけをコンテナに落とせば、コストを抑えつつ性能・スケール要件を満たせるという設計判断です（Your agent needs a computer, not a container より）。

このハイブリッドを支えるのが、後述する workspace.runtime.exec(source, { backend }) という統一実行 API と、read / write / edit / ls / exec を提供する AI SDK ツールキットです。開発者は 1 つのインタフェースを通してタスクを投げ、どの実行バックエンドが処理するかは Workspace 側で選択・切り替えできます。

アーキテクチャの全体像

Computer のアーキテクチャは、公式リポジトリの docs/ 以下に 19 本の設計仕様書として整理されています。全体像を掴むうえでの起点は、docs/01_vfs.md（ワークスペースツリー・予約パス）と docs/05_runtime_interface.md（Workspace.runtime の exec/getExec/killExec/disposeExec）の 2 本になります。

権威ある状態としての Durable Object + SQLite

Computer のアーキテクチャで最も特徴的なのは、ファイルシステムの権威ある状態が Durable Object 内の SQLite に存在するという点です。README でも「Durable Object 内に住む仮想ファイルシステム」であることが最初に説明されており、コンテナ側のディスクや外部ストレージが SSOT（Single Source of Truth）ではありません（cloudflare/computer README より）。

その結果として、Workspace は「バックエンドなしでも構築可能」で、単にファイルシステム単体としても利用できます。実行環境（コンテナ / Isolate）は、Workspace に対して必要に応じて後付けで接続する二次的な存在として扱われます。これが後述する cloudflare/sandbox-sdk や E2B・Daytona との重要な差分になります。

SQLite スキーマそのものは docs/03_filesystem_schema.md、Durable Object と実行環境間の同期プロトコルは docs/02_sync_protocol.md に整理されています。

workspace.runtime.exec による統一実行 API

もう一つのアーキテクチャ上の要は、workspace.runtime という単一のインタフェースにすべての実行バックエンドを集約している点です。README の記述を要約すると、Workspace には複数のバックエンドを stable ID で登録できます。実行はすべて workspace.runtime.exec(source, { backend }) という 1 つのエントリポイントを通り、選択されたバックエンドが source をシェルコマンドとして扱うか ECMAScript モジュールとして扱うかを決定します。バックエンドは最初の使用時に遅延接続されるため、登録しただけではリソースを消費しません（cloudflare/computer README より）。

この統一 API は、公式ブログでも exec(string, options) インタフェースが「ランタイム横断で統一される」ものとして紹介されています。呼び出し側から見ると、コンテナで動くか Isolate で動くかを毎回意識する必要がなく、backend オプションで切り替えるだけで済む設計です。既存の API から workspace.runtime への移行マッピングは docs/18_runtime_migration.md に整理されています。

3 つの実行バックエンド

README で紹介されている実行バックエンドは 3 種類あります。それぞれ「フル Linux 環境が必要か」「Isolate で完結してよいか」「シェルスクリプトを動かしたいのか、JavaScript を評価したいのか」で使い分ける形になります。

Container backend（computerd + FUSE マウント）

Container backend は、SQLite に保持された Workspace の状態を、サンドボックスコンテナに FUSE マウントとして投影する方式です。コンテナ側では computerd というデーモンが動作し、状態をファイルシステムとしてマウントしたうえで、変更を capnweb RPC チャネル経由で Durable Object 側と同期し戻します（cloudflare/computer README より）。

このバックエンドではフル Linux ユーザーランド・実バイナリ・実ネットワークが使えます。pandoc のようなネイティブツールを走らせたい、任意の shell スクリプトや Python 環境を動かしたいといった要件はこのバックエンドで処理する想定です。computerd の詳細仕様は docs/07_injected_service.md に整理されています。

Isolate shell backend（just-bash を Dynamic Worker で実行）

Isolate shell backend は、コンテナを立てずに Cloudflare Workers の Isolate 上でシェル相当の処理を動かす方式です。実装は vercel-labs の just-bash を Dynamic Worker で実行する構成で、Workers RPC を通じて権威ある Workspace に直接到達するため、二次ストアや同期ラウンドトリップが不要になります（cloudflare/computer README より）。

Isolate 実行なのでコールドスタートやランニングコストの面で Container backend より軽量ですが、動くのはあくまで just-bash の範囲であり、任意のネイティブバイナリを持ち込むことはできません。Worker backend の仕様は docs/12_worker_backend.md にまとまっています。

Isolate JavaScript backend（ECMAScript モジュールを Dynamic Worker で実行）

Isolate JavaScript backend は、新鮮な Dynamic Worker 上で ECMAScript モジュールを実行する方式です。構造化された入出力、耐久的な相対 import（ワークスペース内のファイルを import できる）、設定済みライブラリ、Workspace ベースの node:fs/promises 互換 API、信頼済みの ws:git / ws:artifacts モジュールなどが提供されます（cloudflare/computer README より）。

つまり、AI エージェントに「JavaScript コードを書かせて評価する」用途では、シェル経由でスクリプトを実行するのではなく、直接モジュールとして評価できます。仕様の詳細は docs/17_isolate_javascript.md に整理されています。

リポジトリ構成とパッケージ

Computer のリポジトリはモノレポ構成で、packages/ 以下に 5 つのパッケージが並びます。「消費者としてどれを install すべきか」と「下位ビルディングブロックとして参照されるもの」を区別しておくと、依存関係を理解しやすくなります。

消費者が使う @cloudflare/computer

利用者が直接 install するトップレベルのパッケージが @cloudflare/computer です。Durable Objects の内側から Workspace / Runtime にアクセスするための API を提供します。README では「Work in progress」と付記されており、PREVIEW ステータスと合わせて API 面はまだ変動があり得ることが示されています。

Cloudflare Changelog に記載されているインストール手順は次のとおりです。

npm install @cloudflare/computer

（出典: Cloudflare Changelog: Cloudflare Computer）

下位ビルディングブロック（dofs / computer-rpc / computerd）

@cloudflare/computer の内部で使われている下位パッケージは以下のとおりです。それぞれ独立した npm パッケージとして公開されていますが、通常のアプリケーション開発者が直接 install することは想定されていません。

加えて computer-computerd-linux-x64 は、プリビルドの computerd linux-x64 バイナリを含む Docker イメージのコンテキストです。npm パッケージではなく、リリース成果物として Docker イメージが提供される点に注意が必要です（cloudflare/computer README より）。

パッケージのソースツリー構成そのものは docs/10_project_layout.md にまとまっています。

用途別に見る examples/ の使い分け

README では 9 種類の examples/ が紹介されています。初見で全部を読むと迷子になりやすいので、「バックエンド比較を試す例」「エージェント統合の例」「作成物（成果物）を扱う例」の 3 グループに分けて眺めると、自分の関心に合うサンプルから読み始められます。

バックエンド比較を試す例（container / worker-shell / worker-javascript / egress）

3 つの実行バックエンドを実際にどう組み立てるかを確認したい場合は、以下の 4 つが起点になります（cloudflare/computer README の examples/ 節より）。

• examples/container: computerd をコンテナで実行し、Workspace をマウントして Durable Object と capnweb で通信する例。HTTP で write / read / exec 面を公開
• examples/worker-shell: 同じ HTTP 面をコンテナなしで実現する例。シェルは just-bash を Dynamic Worker で実行
• examples/worker-javascript: exec が Dynamic Worker 上で ECMAScript モジュールを評価する例
• examples/egress: 1 つの URL を 3 バックエンドすべてに通し、none / all / カスタムのエグレスポリシーを比較する例

3 バックエンドの挙動差を掴む段階では、まず worker-shell と container を並べて眺めるのが分かりやすい構成になっています。

エージェント統合の例（mcp / think / think-compare-runtimes）

Computer を AI エージェントのエコシステムに組み込むイメージを掴みたい場合は、次のサンプルが該当します。

• examples/mcp: Computer MCP の例。永続 Workspace に紐づく 1 つの Code Mode code ツールを公開
• examples/think: @cloudflare/think チャットエージェントが Workspace を作業ディレクトリとして利用する例

MCP（Model Context Protocol）経由でエージェントに公開するパターンと、Cloudflare のエージェントフレームワークに組み込むパターンの両方を確認できます。

作成物を扱う例（tutorial / artifacts / assets）

Workspace 上に成果物を書き出し、外部に配信する用途のサンプルは以下のとおりです。

• examples/tutorial: 1 エンドポイント・1 エージェントで markdown レシピカードをホスト上に書き、コンテナで pandoc を実行して PDF 化するチュートリアル
• examples/artifacts: Workspace 内で Worker プロジェクトを生成し、Cloudflare Artifacts に clone-ready リポジトリとして公開する例
• examples/assets: プロンプトを Workers AI で画像化し、Workspace に書き出したうえで @cloudflare/computer/assets 経由で共有可能リンクを返す例

「エージェントに何かを作らせて外部に届ける」までのループを設計するときの参考になります。workspace.git と isomorphic-git 対応の git CLI は docs/13_git_interface.md、Artifacts バインディングのラッパーは docs/15_artifacts_interface.md に整理されています。

類似 OSS との違い

Computer を評価する際に必ず比較対象になるのが、同じ Cloudflare の sandbox-sdk、Firecracker microVM ベースの E2B、Codespace 型の Daytona です。以下の比較表は README・公式ブログ・各サービスの公開情報を基に整理したものです（コールドスタート値の一次計測は行っておらず、第三者計測記事の引用値を記載しています）。

cloudflare/sandbox-sdk との違い（同じ Cloudflare 内での立ち位置）

cloudflare/sandbox-sdk は、Cloudflare 自身が以前公開していたエージェント向けサンドボックス SDK です。Computer の README では、computerd の FUSE マウントの性能比較対象として名指しされており、sandbox-sdk の npm install を用いたベンチマークが docs/19_performance.md（docs/19_performance.md 参照）で紹介されています。

両者の差分の要点は、sandbox-sdk がコンテナベースの一次的な実行環境である一方、Computer は Durable Object 内 SQLite を SSOT に置き、コンテナはあくまで FUSE マウントで投影する副次的な存在として扱う点にあります。加えて Computer は Container を使わない Isolate バックエンドも持つため、「コンテナなしでも成立する」設計になっています。

E2B との違い（Firecracker microVM vs Cloudflare Workers Isolate）

E2B（e2b-dev/E2B 系リポジトリ）は、Firecracker microVM をベースにした AI エージェント向けサンドボックスです。ハードウェア（microVM）レベルでの隔離を提供し、コールドスタートは 2026 年の第三者計測で 150ms 前後と報告されています（LogRocket: Comparing AI agent sandbox platforms より）。

Computer との差分は次のとおりです。E2B が「セッション単位で使い捨ての一時的環境」を提供するのに対し、Computer は Workspace が Durable Object として恒常的に存在します。また E2B が microVM 単位の HW 隔離を売りにするのに対し、Computer は Cloudflare Workers Isolate + オプションで Container というハイブリッド構造を選び、コスト最適化を優先しています。

Daytona との違い（Codespace 型永続 vs DO ベース永続）

daytonaio/daytona は、永続ワークスペース + コンテナベースの隔離を提供する AI エージェント向けサンドボックスです。Daytona は「デフォルト永続」で、削除するまでワークスペースが残る Codespace 型の設計を取っており、2026 年計測でコールドスタート 90ms 前後と最速級です（E2B vs Daytona vs Blaxel 比較（2026） より）。

Computer も永続的なワークスペースを提供しますが、状態を Durable Object 内 SQLite に持ち、実行環境（Container / Isolate）はオンデマンドで接続する二層構造である点で異なります。Daytona のように「ワークスペース = コンテナ」のように 1:1 で結びつかず、同じ Workspace に対して複数バックエンドを stable ID で登録できるのは Computer 独自のポイントです。

採用判断のポイント（PREVIEW 段階での踏み込み方）

以上を踏まえ、初見のエンジニアが Computer を採用検討する際のチェックポイントを整理します。

PREVIEW 段階で適した検証フェーズ

README で明示されているとおり Computer は PREVIEW ONLY のパッケージで、API は不安定・本番不可の位置づけです。加えて docs/ は「意図」を示す前方参照ドキュメントであり、現在の実装挙動と食い違い得る点にも留意が必要です（cloudflare/computer README より）。

このため、現時点で採用検討する場合の推奨フェーズは次のとおりです。

• POC・プロトタイプ: 3 バックエンド構成や workspace.runtime.exec のインタフェースを触ってフィードバックを返すフェーズ。適合
• 社内向け実験プロダクト: 障害時の SLA が緩く、破壊的変更を随時取り込める社内エージェント。適合するが、破壊的変更に対応する運用工数を織り込む必要あり
• 顧客向け本番プロダクト: 現時点では非推奨。GA（一般提供）や docs/ と実装挙動の整合が明確に宣言されるフェーズまで待つ判断が妥当

裏を返せば、AI エージェント基盤の技術選定を本気で行っているチームにとっては、GA 前にインタフェースの方向性を早期にキャッチアップしておく価値のあるリポジトリです。

メンテナンス指標とコントリビューションポリシー

メンテナンス活動の健全性を示す指標として、リポジトリメタデータからは次のことが読み取れます。

• スター数 8,467 / フォーク数 463 と、リリース直後のタイミングとしては十分なコミュニティ関心を集めている
• pushed_at が 2026-08-21T19:19:57Z と、執筆日（2026 年 8 月 22 日）の前日に更新されており、Cloudflare 本体による活発なコミット活動が続いている
• ライセンスは MIT で、社内利用・受託開発いずれの用途でも導入判断のブロッカーになりにくい
• archived=false / fork=false で、本家が現行のメインライン開発を行っているリポジトリ

一方でコントリビューションポリシーには特徴があります。README では 未依頼の Pull Request は受け付けない ことが明記されており、コードコントリビューションは Issues / Discussions を通じたバグ報告・修正提案・機能要望・設計提案が中心で、実装貢献は Approved collaborators に限定されます（cloudflare/computer README より）。

したがって、コミュニティ主導での機能追加を期待する OSS ではなく、Cloudflare 主導の設計・実装に対してフィードバックする タイプのプロジェクトである点は認識しておく必要があります。

まとめと次のステップ

Cloudflare Computer は、Durable Object 内 SQLite を権威ある状態として持ち、Container / Isolate shell / Isolate JavaScript の 3 バックエンドを workspace.runtime.exec という 1 つの API に統合する、AI エージェント向けの永続ファイルシステム基盤 OSS です。「10% 未満の作業だけがコンテナを必要とする」という前提でハイブリッドを組み、コスト最適化と永続性の両立を狙っています。

類似 OSS との差分は次のように整理できます。cloudflare/sandbox-sdk に対しては「状態の SSOT が SQLite」「コンテナなしでも成立」という点で新しく、E2B に対しては「セッション単位ではなく DO 単位の永続」「microVM ではなく Isolate + Container のハイブリッド」で対比され、Daytona に対しては「ワークスペース = コンテナ」ではない二層構造である点が異なります。

現時点では PREVIEW ONLY のパッケージであり、本番採用の判断はまだ避け、POC・プロトタイプ・社内実験の範囲で 3 バックエンドの挙動と workspace.runtime の抽象を評価するのが妥当なフェーズです。次に読み進める際の入り口としては、以下の順序が効率的です。

1. リポジトリの README を通読し、全体像と 3 バックエンドの位置づけを確認する（cloudflare/computer）
2. 公式ブログで設計思想を掴む（Your agent needs a computer, not a container / 日本語版）
3. 設計仕様書の入り口 docs/ から、01_vfs.md → 05_runtime_interface.md → 気になるバックエンド仕様（07_injected_service.md / 12_worker_backend.md / 17_isolate_javascript.md）の順に読む
4. Cloudflare Changelog で Cloudflare 製品群との関係を確認する（Cloudflare Changelog: Cloudflare Computer）

関連情報

AI エージェント基盤の設計や、Cloudflare Workers / Durable Objects を活用した受託開発をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。

エンジニアの方へ

Cloudflare Workers / Durable Objects や AI エージェント基盤の開発案件を探しているフリーランス・複業希望のエンジニアの方は、Workee で案件を探す をご覧ください。