Puppyoneのサンドボックス比較:Docker vs Cloudflare — AIエージェントにはどちらが向いているのか?

AIエージェントを本番で動かす以上、隔離(アイソレーション)は「あったほうがいい」ものではなく必須です。エージェントはコードを実行し、ファイルシステムに触り、外部サービスを呼び出します。きちんとしたサンドボックスがなければ、たった一度の暴走出力で取り返しのつかない事態を招きかねません。

Puppyoneは、用途の異なる2つのサンドボックス環境を提供しています。フル機能で柔軟に動かせるDockerベースのサンドボックスと、グローバルに分散され高速・軽量なCloudflareベースのサンドボックスです。本記事では、それぞれが実体として何なのか、どこが違うのか、そしてどう選ぶべきかを整理します。

サンドボックスとは

サンドボックスとは、エージェントの行動 — コード実行、ファイル操作、ツール呼び出し — をすべて閉じ込めた、コントロール可能な隔離実行環境です。良いサンドボックスは、次のような境界を明確に強制します。

• 何を読めて、何を書けるか
• どんなネットワーク呼び出しが可能か
• CPUとメモリをどれだけ使えるか
• どこまで走らせたら停止されるか

これらの境界はどちらのサンドボックスでも強制されます。面白いのはどうやって強制しているかであり、それぞれにどんなトレードオフがついてくるかです。

Dockerサンドボックス vs Cloudflareサンドボックス:本質的な違い

すべての違いは、結局このひと言に尽きます。Dockerサンドボックスは「Linuxマシン」を1台丸ごと与えてくれる。Cloudflareサンドボックスは「JavaScriptを動かすスロット」を1つ与えてくれる。

Dockerサンドボックスはコンテナの上に成り立っています。1つのサンドボックスは事実上、独立したLinuxサーバーです。パッケージのインストール(apt install、pip install)、任意のランタイム(Python、Node、Goなど)の実行、サブプロセスの起動、本物のファイルシステムへの読み書き、何時間も走り続けるタスク — すべて可能です。代償は数秒単位のコールドスタートと、存在している間ずっと実CPUとメモリを消費することです。

CloudflareサンドボックスはV8 Isolateの上に成り立っています。これはChromeがブラウザのタブ同士を分離するのと同じ仕組みです。動かせるのはJavaScript / WebAssemblyのみ。パッケージのインストール不可、サブプロセス不可、ローカルファイルシステム不可、1回の実行は通常CPU30秒で打ち切られます。その代わり、コールドスタートは5ミリ秒未満。1台のマシンに数千のIsolateを載せ、Cloudflareの300以上のグローバルエッジ拠点に自動で展開されます。

やりたいこと	選択
Pythonスクリプトを動かす、ライブラリを入れる、データ処理	Docker
エージェントにファイルを編集させる、レポート生成、gitを実行	Docker
数分〜数時間にわたるタスク	Docker
ミリ秒で応答を返したい	Cloudflare
高並列なJavaScriptロジック(ルーティング、変換、フィルタ)	Cloudflare
複数リージョンでユーザーの近くで実行したい	Cloudflare

以下、それぞれを詳しく見ていきます。

Dockerベースのサンドボックス

仕組み

各エージェントタスクは、それぞれ独立したコンテナの中で動きます。コンテナはnamespaceとcgroupでホストから隔離されたLinux環境です。タスクが届くと、Puppyoneは事前ビルド済みイメージから新品のコンテナを起動し、入力をマウントし、作業ディレクトリを割り当て、リソースクオータを適用します。タスクが終われば、コンテナはまるごと破棄されます。すべての実行は既知のクリーンな状態から始まり、前回のプロセスやファイル、環境変数が残ることはありません。

できること

カスタマイズ可能なイメージ。 デフォルトのベースイメージはUbuntuで、Python、Node、Git、curlがプリインストール済みです。それで足りなければ独自のDockerfileを持ち込めます。Puppyoneは標準命令(FROM、RUN、COPY、WORKDIR、ENV)に対応しており、必要なランタイムやCLIツール、社内専用の依存関係を組み込めます。エージェントは、自分のワークフローに合わせて整えられた環境にいきなり立ち上がります。

設定可能なリソース上限。 デフォルトは2 vCPU・512 MBで、タスクごとに最大8 vCPU・8 GBまで引き上げられます。サンドボックスがメモリを使い切った場合、コンテナはきれいに殺されるだけで、ホストには影響しません。

コントロールされた実行時間。 デフォルトのタイムアウトはタスクあたり5分、最大24時間まで設定できます。さらに長い処理にはサンドボックスがpause / resumeをサポートしており、ファイルシステムとメモリ状態をスナップショットして保存し、再開時に復元します。環境を一から立ち上げ直すコストを払わずに済みます。

きめ細かな送信トラフィック制御。 外向きトラフィックはデフォルトで全遮断です。エージェントが到達してよいドメインやポート(例:api.openai.com、*.github.com)を明示的にAllowlistし、それ以外は拒否します。プロンプトインジェクションを食らったエージェントが、こっそりデータを持ち出すのを防ぐ仕組みがこれです。

ファイルシステムに直結したワークスペース。 各サンドボックスはPuppyoneファイルシステム上のnamespaceをマウントします。一時的なスクラッチディレクトリではありません。コンテナ内でエージェントがファイルを書けば、それは事実上Puppyoneへのコミットです。バージョン管理され、権限が付き、監査可能です。ロールバックも、別のエージェントへの引き渡しも、生成元のタスク・ステップへのトレースもできます。

コンテナの存続時間で課金。 コンテナが存在している秒数すべてに課金されます。CPUが何かをしているかどうかは関係ありません。これは「走らせて、終わったら破棄する」パターンを推奨する設計です。タスクを始め、終え、コンテナを殺す。エージェントの大半の時間がLLMの応答待ちやユーザー入力待ちに費やされる場合、その待ち時間にも当然課金されます。

向いていない用途

• 100ms以下のレスポンスパス(コールドスタートはミリ秒ではなく秒単位)
• 1秒に数千リクエストの独立処理(コンテナ1つ1つが実リソースを食う)
• ほんの数行の軽量JavaScriptロジック(完全にオーバースペック)

向いている用途

• ファイルに触ったり、ライブラリを使ったり、成果物を生成するPython / Node / shellスクリプト
• 各ステップが前のステップのワークスペースを引き継ぐ多段ワークフロー
• パッケージのインストールやコードのコンパイル、システムユーティリティ呼び出しを伴う処理
• 要するに、本当にマシンが必要な処理すべて

Puppyoneでの位置付け

PuppyoneのDockerサンドボックスはE2BとAPI互換です。すでにエージェントがE2Bで動いているなら、ビジネスロジックを一切変えずにPuppyoneに向け先を切り替えられます。Sandbox.create()、runCode()、commands.run()、ファイルI/O — すべてそのまま対応します。代わりに得られるのは、サンドボックスとファイルシステムが一体になっていることです。「サンドボックス内のファイル → オブジェクトストレージに保存 → 次のサンドボックスにシンク」という面倒な連鎖を管理する必要はもうありません。書き込みはすべてPuppyoneファイルシステムに着地し、バージョン履歴・権限・監査ログがついてきます。同じ状態を、タスクを越え、エージェントを越え、サンドボックスの種類すら越えて見ることができます。

---

Cloudflareベースのサンドボックス

仕組み

エージェントのコードは、Cloudflareのグローバルエッジネットワーク上のV8 Isolateの中で動きます。Chromeがタブを分離するのと同じ技術です。各IsolateはミリJavaScript実行コンテキストで、ミリ秒で立ち上がり(OSを起動する必要はありません)、リクエストが終われば破棄されます。リクエストはユーザーに最も近いエッジ拠点に振り分けられ、往復遅延は数十ミリ秒に抑えられます。

できること

ミリ秒のコールドスタート。 Isolateは1つあたり5ms未満で立ち上がります。コンテナよりおよそ3桁速いオーダーです。リクエストごとに新品のサンドボックスを起こすことすら現実的で、Warm Poolも常時稼働インスタンスも要りません。

JavaScript / WebAssemblyのみ。 Pythonもshellもネイティブバイナリも使えません。ロジックはJS/TSか、WASMにコンパイルしたもの。Node.jsの組み込みは大半が利用可能ですが、システムコールに依存するもの(fs、child_process、ネイティブC拡張)は動きません。

メモリ128 MB上限、リクエストあたりCPU30秒。 各リクエストは最大128 MBのメモリと30秒のCPU時間を持ちます(有料プランでは最大5分まで設定可能)。覚えておくべきポイントは、計上されるのは実CPU時間のみということです。fetch()やデータベースクエリの待ち時間はカウントされません。CPU30秒の制限内のリクエストでも、実時間では数分間オープンに保てます。

ローカルファイルシステムなし。 Isolateはステートレスです。永続化が必要なものはすべて外部ストレージへ — Cloudflare KV、R2、D1、または独自のデータベース。リクエスト間で中間状態を共有したいなら、シリアライズして書き出し、読み戻す。あるいは別のステートフルなサービスに投げます。

グローバルエッジ実行+オートスケーリング。 コードはCloudflareの300以上のエッジ拠点に自動展開され、ユーザーに最も近い拠点で動きます。0から数万QPSまで、容量計画は不要 — プラットフォームが面倒を見ます。

Cloudflareのセキュリティレイヤーが標準装備。 DDoS対策、レートリミット、ボット対策、TLS終端 — すべてネットワーク側に組み込まれています。これらのために別途レイヤーを立てる必要はありません。

実CPUミリ秒のみ課金。 Isolateがfetch()、データベース、ユーザーイベントを待っている間は課金されません。請求対象はV8が実際にコードを動かしているミリ秒だけです。LLMを呼んでAPIレスポンスを集約することがほとんどといったI/OバウンドなエージェントなどI/O中心のワークロードでは、待ち時間のコストは実質ゼロです。

向いていない用途

• パッケージのインストール、Python / shell、ネイティブバイナリの実行が必要なタスク
• 1リクエストで数分以上のCPUを必要とするワークロード
• サンドボックス内でローカルファイルを読み書きしたり、リクエストをまたいだ状態を保持するワークフロー
• メモリ128 MBを超える重めのタスク

向いている用途

• 高並列・短時間のリクエスト(パース、変換、フィルタ、ルーティング)
• エージェントの「玄関口」 — 高速に判断し、パラメータを抽出し、次に呼ぶツールを選ぶ
• グローバル分散・低遅延サービス(賢いAPIゲートウェイ、エッジRAG)
• Cloudflareのプリミティブ(KV、R2、D1、Queues)を繋ぐグルーコード

Puppyoneでの位置付け

Cloudflareサンドボックスは現在開発中で、まだ一般公開されていません。 Dockerサンドボックスと同じ仕組みでPuppyoneファイルシステムに繋ぎ込みを進めています。Isolate内のJSコードが「ファイルを書く」と、それはPuppyoneへの版管理・権限付き・監査可能なコミットになり、Dockerサンドボックスとも状態を共有します。同じエージェントが、重い計算はDockerサンドボックスで走らせ、エッジでの応答はCloudflareサンドボックスで返す — 両方が同じワークスペースを見ている。そんな構成が組めるようになります。

エッジ実行が必要なユースケースの方は、アップデートを購読してください。利用可能になり次第お知らせします。

---

並べて比較

ここまでの内容をひと目で見比べられる表にまとめます。

観点	Dockerサンドボックス	Cloudflareサンドボックス
基盤技術	Linuxコンテナ(namespace + cgroup)	V8 Isolate
コールドスタート	2〜10秒	< 5ミリ秒
ランタイム	Python、Node、Go、shell — 任意のLinuxバイナリ	JavaScript / TypeScript / WebAssembly
パッケージインストール	✅ apt、pip、npm、独自Dockerfile可	❌ 事前にバンドルが必要
サブプロセス	✅	❌
ローカルファイルシステム	✅ POSIX完全対応、Puppyoneにマウント	❌ 外部ストレージのみ(KV / R2 / D1)
デフォルトリソース	2 vCPU + 512 MB	128 MBメモリ
リソース上限	8 vCPU + 8 GB(設定可)	128 MBメモリ(固定)
1実行あたり時間	デフォルト5分、最大24時間	デフォルトCPU 30秒、有料で最大5分
状態の保持	pause / resumeスナップショット(メモリ + FS)	なし(リクエストごとに新品Isolate)
並列モデル	サンドボックスごとに1コンテナ(実リソース消費)	1台あたり数千Isolate
地理的分散	シングルリージョン	300以上のエッジ拠点に自動ルーティング
送信制御	ドメイン/ポートAllowlist	Workersで設定
プラットフォームのセキュリティ	自前で構築	DDoS / レートリミット / ボット / TLS標準装備
課金粒度	コンテナ存続秒数(待機時間も含む)	実CPU時間ミリ秒(待機は無料)
プロセスモデル	走らせて破棄	オンデマンド、保守不要
API互換性	E2Bと互換	Cloudflare Workers API
Puppyoneでの状況	✅ 提供中	🚧 開発中、未公開
典型的なユースケース	5分のデータ処理、パッケージありのPython、多段ワークフロー	ミリ秒ルーティング、高並列JSロジック、エッジAPI
10分動くエージェントは?	実際に計算しているならDocker	90%がLLM/API待ちならCloudflare

---

選び方

サンドボックス選びは「どっちが優れているか」の話ではなく、「自分のワークロードがどう見えるか」の話です。次の5つの観点で、現実の判断はだいたいカバーできます。

1. ランタイム言語

Python、shell、Go、ネイティブバイナリ(ffmpeg、pandoc、gitなど)を動かす必要があるなら、Docker一択です。CloudflareはJavaScript / TypeScript / WebAssemblyしか動きません。pip installすらできません。

ビジネスロジックがすでにJS / TSでシステムコールに踏み込まないなら、両方が候補に入ります。続きを読んでください。

2. タスクの長さ

タスクの長さ	選ぶ	理由
< CPU 30秒	Cloudflare	ミリ秒起動 + ミリ秒課金 — 圧倒的に安い
CPU 30秒〜5分	Cloudflare(有料プランで5分まで)	上限内に収まる
数分〜数時間	Docker	CloudflareのCPU上限に当たる
数日にわたるワークフロー	Docker + pause / resumeスナップショット	状態を凍結して後で再開

3. コスト構造(最もよく間違える観点)

2つの課金モデルは本質的に別物です。同じワークロードでも選び方を間違えるとコストが1桁変わり得ます。

• Dockerはコンテナが存在している時間で課金。 コンテナが起動した瞬間からメーターが回り、CPUが何かをしているかは関係ありません。短く密な仕事を奨励する設計です。タスクを始め、終え、コンテナを殺す。アイドルコンテナがユーザー入力やLLM応答を待っている間も、ずっと課金されます。
• CloudflareはCPUの実ミリ秒だけ課金。 Isolateがfetch()、データベース、LLMのストリーミング応答を待っている間は課金されません。V8が実際にコードを実行しているミリ秒だけが請求対象です。

具体的には:

• 5分のデータ処理タスク(CPUがずっと張り付き) → Dockerのほうが安い
• 毎秒1万ユーザー、各リクエストが50msのロジックを発火 → Cloudflareが桁違いに安い
• 30分稼働するエージェントの90%がLLMストリーム待ち → Cloudflareが圧倒的に安く、Dockerは30分丸ごと課金される

時間単価で比較してはいけません。比較すべきは、ワークロードの実時間のうち、本当に計算している割合です。その比率がどちらの勝ちかを決めます。

4. 並列度

• 毎秒数件〜数十件のリクエスト → どちらでも可
• 毎秒数百件の短時間タスク → Cloudflare(1台あたり数千Isolate。Dockerなら同時実行ぶんのコンテナが必要)
• 毎秒数件だが1件あたり数分の計算 → Docker(Cloudflareはそこまで持たない)

5. データ量と状態

• 多数のファイルの読み書き、GB級の成果物の生成、多段ワークスペースの維持 → Docker(本物のFSがPuppyoneにマウントされ、自動で版管理)
• APIを少し叩いて軽く変換し外部ストレージに書き戻すだけ → Cloudflare(ローカルFSはないが、KV / R2 / D1の読み出しは速い)
• メモリ128 MB超 → Docker(CloudflareのIsolateは1つあたり128 MBが上限)

---

まだ迷うなら? 既定でDockerにしてください。Dockerの能力はCloudflareの厳密な上位集合 — まず選択を間違うことはなく、極端な高並列・I/O重視のシナリオで多少コストが上がる程度です。トラフィックが本当に大きくなったら、ホットパスをCloudflareに移せばよいだけです。

Cloudflareサンドボックスが公開されたあとの理想的なアーキテクチャ: 2つを組み合わせて使います。Cloudflareサンドボックスがエージェントの玄関口として、ミリ秒オーダーのルーティング、パラメータ抽出、軽い判断を担当。重い計算が本当に必要になったらDockerサンドボックスに渡します。Cloudflareは速い経路、Dockerは重い仕事、そしてどちらも同じPuppyoneファイルシステムで繋がっている — そんな姿です。

---

Puppyoneでサンドボックスを使い始める

すでにエージェントがE2Bで動いているなら、向け先をPuppyoneに変えるだけ。Sandbox.create()、runCode()、commands.run()はすべてAPI互換で、ビジネスロジックの変更は不要。即座にファイルシステムレベルのバージョン管理・権限・監査ログが手に入ります。

ゼロから始める方は、Puppyoneのドキュメントにクイックスタートが用意されており、数行のコードで版管理付きファイルシステム付きのサンドボックスが立ち上がります。

Cloudflareエッジサンドボックスが必要な方は、アップデートを購読してください。公開され次第お知らせします。