Cloudflare Dynamic Workers：AI Agent サンドボックスがコンテナより 100 倍速い秘密

AI Agent がデータ分析コードを生成し、実行しようとした瞬間——コンテナの起動に 3 秒、メモリ使用量は 200MB。ユーザーのリクエストはすでにタイムアウト。これは一部の問題ではなく、業界全体でコンテナを使って AI コードを実行する際の一般的な課題です。

Cloudflare が 2026 年 3 月にリリースした Dynamic Workers は、V8 Isolates を使ってこの起動時間を数ミリ秒に短縮し、メモリ使用量を数 MB まで圧縮しました。100 倍のパフォーマンス向上です。その背後には、根本的に異なる隔離哲学があります。

つまり、Dynamic Workers は単なる「より速いコンテナ」ではありません。「リクエストごとに 1 つのサンドボックス」を技術的に可能から経済的に可能にするものです。本記事では、V8 Isolates と従来のコンテナの本質的な違いを深く分析し、Dynamic Workers の実践的なコード例を提供して、技術選定の判断を支援します。AI Agent のサンドボックスソリューションを選定しているなら、この記事でコストとメリットを明確に理解できます。

なぜコンテナが AI Agent のパフォーマンスボトルネックなのか

以前はどうしていたか？コンテナが主流のソリューションでした。Kubernetes で Pod をスケジュールし、イメージをプルし、環境を設定する——成熟したプロセスですが重い。AI Agent のシナリオには特徴があります：コード実行は短時間で、データ分析スクリプトなら数秒で終わるかもしれませんが、コンテナの起動には 3 秒以上かかります。これでは釣り合いません。

知乎の 2026 年 AI Agent Sandbox 研究レポートによると、Docker コンテナの起動は約 500ms です。しかし、これは単なる「起動」に過ぎません。イメージのプル、ネットワーク設定、依存関係の初期化を加えると、実際に使用可能になるまで 3 秒以上かかることが多いです。メモリはどうでしょう？数十 MB から始まり、複雑な環境では 200MB 以上になることもあります。

「ウォームアップ池を使えばいいのでは？」と思うかもしれません。事前にコンテナを起動して待機させる。確かに、これは主流のアプローチです。しかし、問題があります。

第一にコスト。ウォームアップ池は常に一定数のコンテナをオンラインに保つ必要があり、リクエストの有無に関わらず。100 個のウォームアップコンテナ、各 200MB メモリなら、メモリコストだけで大変です。さらに、コンテナ再利用のセキュリティリスクも考慮が必要——前のリクエストのデータがメモリに残る可能性があります。

第二に複雑さ。ウォームアップ池はコンテナのライフサイクル管理、ヘルスチェック、オートスケーリングが必要です。このインフラ自体が大変です。以前 Kubernetes ウォームアップ池を使ったプロジェクトでは、メンテナンスコストがビジネスロジックより高かったです。

第三にシナリオのミスマッチ。AI Agent のコード実行は多くの場合、一回限りです。ユーザーが CSV をアップロードし、AI が分析コードを生成し、実行後に破棄。各リクエストは独立した隔離環境が必要ですが、ウォームアップ池のコンテナ再利用はこの隔離を壊します。

シナリオを想像してみましょう。ユーザー A の AI Agent がコードを実行し、機密データを処理しました。コンテナはウォームアップ池に戻り、ユーザー B のリクエストが同じコンテナを受け取ります。クリーンアップメカニズムがあっても、データ残留のリスクは常に存在します。これは理論上の問題ではありません——2025 年にはコンテナ残留によるデータ漏洩の報告がありました。

つまり、AI Agent シナリオにおけるコンテナソリューションの矛盾は明確です：起動が遅い、メモリが高い、ウォームアップ池にセキュリティリスク、メンテナンスが複雑。コンテナが悪いのではなく、コンテナの設計哲学と AI Agent の実行パターンが合わないのです。

V8 Isolates はどうやって起動時間をミリ秒に圧縮するのか

V8 Isolates とは何か？Chrome の JavaScript エンジンで、JS コードをマシンコードにコンパイルして実行します。Isolate は V8 の隔離単位——独自のメモリヒープ、コンパイルキャッシュ、グローバルオブジェクトを持つ独立した実行環境です。

重要なのは、Isolate はホスト OS のカーネルを呼び出さないということです。

コンテナはどう動くか？プロセスを起動し、ホストカーネルのシステムコール（syscall）を実行します。隔離はカーネルレベルの namespace と cgroup に依存します。問題は、この「隔離」が擬似的であること——コンテナとホストは同じカーネルを共有しています。syscall は同じカーネルパスを通ります。

V8 Isolates は完全に異なります。JavaScript コードは Isolate 内で実行され、syscall を生成しません。すべての操作はプロセス内で完結——メモリ割り当て、ガベージコレクション、コンパイル実行。つまり、隔離境界はプロセス内部にあり、カーネルレベルではありません。

テンセントニュース 2026 年のレポートは具体的なデータを提供しています：V8 Isolates の起動時間は数ミリ秒、メモリ使用量は数 MB。コンテナと比較して、起動は 100 倍速く、メモリ効率は 10-100 倍高い。

隔離技術の完全な比較表を見てみましょう。技術選定の参考に：

隔離技術	セキュリティレベル	起動速度	メモリ使用量	syscall ターゲット
Docker コンテナ	⭐⭐	~500ms	数十 MB	ホストカーネルを共有
gVisor	⭐⭐⭐⭐	~100ms	高め	ユーザー空間カーネルでインターセプト
Firecracker microVM	⭐⭐⭐⭐⭐	~150ms	~1GB	独立した仮想カーネル
V8 Isolates	⭐⭐⭐	数 ms	数 MB	呼び出さない

この表は重要な情報を示しています：セキュリティレベルと起動速度はトレードオフ。Firecracker が最も安全（独立した仮想カーネル）ですが、起動が最も遅く、メモリが最も高い。V8 Isolates が最も速く最も経済的ですが、セキュリティレベルは中程度です。

なぜ V8 Isolates のセキュリティレベルは星 3 つか？隔離境界がプロセス内部にあるからです。ある Isolate が攻撃された場合、理論上、同じプロセス内の他の Isolate に影響する可能性があります。これはコンテナより安全（コンテナはカーネルを共有するが、少なくとも namespace 隔離がある）ですが、microVM より弱い（microVM は独立したカーネルを持つ）。

しかし、Cloudflare の Dynamic Workers は多層のセキュリティメカニズムを追加し、この「星 3 つ」のセキュリティレベルを実際には許容可能なレベルまで引き上げています。後でこの 5 層防御について詳しく説明します。

話を戻すと、V8 Isolates の核心的な利点は「より安全」ではなく「より安い」ことです。各リクエストで独立したサンドボックスを起動し、使用後に破棄——これはコンテナの世界では贅沢ですが、Isolate の世界では標準です。

Dynamic Workers API：load() と get() の設計哲学

Dynamic Workers は 2 つの API モードを提供し、設計哲学は明確です：一つは短時間実行用、一つは長いライフサイクル用。

load()：一回限りの実行、使用後に破棄

load() モードは単一実行シナリオに適しています。AI が生成したコードが入ってきて、Isolate を起動し、実行し、破棄。全体のプロセスはミリ秒単位で完了します。

// load() モード：一回限りの実行
import { DynamicWorkerLoader } from 'cloudflare:sandbox-sdk';

const loader = new DynamicWorkerLoader();

// コードをロード、リソースをバインド、制限を設定
const dynamicWorker = await loader.load({
  code: aiGeneratedCode,  // AI が生成したコード文字列
  bindings: {
    db: env.DB,           // D1 データベースバインディング
    kv: env.KV,           // KV ストレージバインディング
  },
  limits: {
    cpuMs: 100,           // CPU 時間制限：100ミリ秒
    memoryMB: 128,        // メモリ制限：128MB
  }
});

// コードを実行、結果を取得
const result = await dynamicWorker.execute();

// 実行完了後、Isolate は自動的に破棄
console.log(result);

主要パラメータの説明：

• code：実行するコード文字列、AI が動的に生成可能
• bindings：外部リソースのバインディング、データベース、ストレージ、API など
• limits：実行制限、リソース濫用を防止

load() の適用シナリオ：

• 単一データ分析：ユーザーが CSV をアップロード、AI が分析コードを生成、一回実行して破棄
• 一時的なコード実行：AI が生成した変換スクリプト、検証ロジック
• リクエストレベルの隔離：各リクエストが独立したサンドボックス、残留リスクなし

get()：キャッシュウォームアップ、長いライフサイクルシナリオ

get() モードはウォームアップ状態が必要なシナリオに適しています。Isolate 作成後、メモリに保持され、後続の呼び出しで直接再利用されます。

// get() モード：キャッシュウォームアップ
const cachedWorker = await loader.get({
  id: 'persistent-analyzer',  // 固定識別子、キャッシュ検索用
  code: analysisCode,         // プリロードされたコード
  bindings: {
    vectorize: env.VECTORIZE, // ベクトルデータベースバインディング
  }
});

// 複数回呼び出し、ウォームアップ状態を維持
const result1 = await cachedWorker.execute({ input: data1 });
const result2 = await cachedWorker.execute({ input: data2 });
const result3 = await cachedWorker.execute({ input: data3 });

// 手動破棄不要、Cloudflare が自動的にライフサイクル管理

get() の適用シナリオ：

• バッチ処理：同じ分析ロジックで複数のデータセットを処理
• 長期実行 Agent：状態を維持する分析タスク
• ウォームアップ高速化：初回実行の遅延を削減

2 つのモードの本質的な違い：load() は「部屋を借りて一晩だけ」、get() は「部屋を借りて長期滞在」。前者は短時間のシナリオ、後者は継続的なシナリオに適しています。

Cloudflare 公式 Sandbox SDK の AI Code Executor チュートリアルはより完全な例を提供しています。本記事を読んでから実践に進むことをお勧めします。

Dynamic Workers の 5 層セキュリティ防御

前述の通り、V8 Isolates の基本セキュリティレベルは星 3 つです。しかし、Cloudflare は Dynamic Workers に多層防御を追加し、実際のセキュリティレベルを本番環境で使用可能なレベルまで引き上げています。

InfoQ 2026 年 4 月の分析レポートは、この 5 層防御を詳しく解説しています。

第一層：V8 セキュリティパッチの自動配信

V8 エンジン自体にセキュリティ脆弱性があります——これは避けられません、複雑なソフトウェアには必ずあります。Chrome チームが脆弱性を発見してパッチをリリースすると、Cloudflare は数時間以内に世界中のすべてのノードに配信します。

従来のソリューションと比較：コンテナ環境のセキュリティパッチはホストシステムに依存し、更新サイクルは数週間から数ヶ月になる可能性があります。V8 パッチの対応速度は「時間単位」で、「週単位」ではありません。

第二層：動的リスク Tenant Cordoning

ある Dynamic Worker が異常な動作（メモリ急増、CPU スパイクなど）を示した場合、Cloudflare はそれを「高リスク」としてマークし、専用の隔離ノードに移動します。

これは tenant cordoning と呼ばれます——リスクのあるテナントは単独で隔離され、他の正常な Worker に影響しません。

第三層：MPK ハードウェア保護

MPK（Memory Protection Keys）は Intel ハードウェアレベルのメモリ隔離メカニズムです。各 Isolate は独立したメモリアクセス権限を持ち、ハードウェアレベルで境界越えアクセスを阻止します。

これは物理レベルの保護で、ソフトウェア隔離より突破が困難です。

第四層：コードスキャン

実行前にスキャン。悪意あるパターンの識別——無限ループ、メモリ爆弾、機密 API 呼び出しなど——は自動的にブロックされます。

この防御層は AI が生成した悪意あるコードに対処します。プロンプトインジェクションにより AI が危険なコードを生成する可能性がありますが、コードスキャンは実行前に阻止できます。

第五層：ネットワーク隔離

Dynamic Worker はデフォルトで外部ネットワークアクセスを完全にブロックします。外部 API へのアクセスが必要な場合、Cloudflare の egress proxy を経由し、クレデンシャル注入メカニズムにより、Worker は認可された API にしかアクセスできません。

セキュリティアーキテクチャ図を簡単に描きます：

AI が生成したコード
     |
     v
┌─────────────────────────────────────┐
│ Dynamic Worker (V8 Isolate)         │
│ ┌─────────────────────────────────┐ │
│ │ 第一層：コードスキャン           │ │
│ ├─────────────────────────────────┤ │
│ │ 第二層：V8 セキュリティパッチ    │ │
│ ├─────────────────────────────────┤ │
│ │ 第三層：tenant cordoning        │ │
│ ├─────────────────────────────────┤ │
│ │ 第四層：MPK ハードウェア保護     │ │
│ └─────────────────────────────────┘ │
│         |                           │
│         v                           │
│  Cap'n Web RPC ブリッジ              │
│         |                           │
│         v                           │
│  第五層：egress proxy クレデンシャル注入 │
└─────────────────────────────────────┘

この多層防御により、V8 Isolates の「星 3 つ」セキュリティレベルは本番環境で信頼できるレベルになります。絶対的に安全だというのではありません——絶対的に安全なシステムは存在しません——「許容可能なリスクレベル」に達しています。

Dynamic Workers 定価：なぜ「リクエストごとに 1 つのサンドボックス」を実現できるのか

「リクエストごとに 1 つのサンドボックス」は贅沢に聞こえます。しかし、Dynamic Workers のコストモデルでは、これは現実的です。

まず、Cloudflare の料金体系を見てみましょう（ベータ期間は無料、正式料金は以下）：

• $0.002 per unique Worker loaded per day：1 日あたり各独立 Worker 0.002 ドル
• 標準 CPU 時間料金：$0.02 per million CPU milliseconds
• invocation 料金：$0.50 per million requests

VentureBeat 2026 年 4 月のレポートは比較を提供しています：E2B（Firecracker microVM ソリューション）はリクエストあたり $0.01+ ですが、Dynamic Workers は $0.002 です。

具体的なコスト比較を見てみましょう：

ソリューション	リクエストあたりコスト	月額コスト（100万リクエスト）	複雑さ	メンテナンスコスト
コンテナウォームアップ池	$0.02+	$2000+	高	高（池のメンテナンス必要）
E2B microVM	$0.01+	$1000+	中	低
Dynamic Workers	$0.002	$200	低	なし

計算してみましょう：1 日 100 万リクエスト、各リクエストが異なるコードを実行（unique Worker）と仮定。

コンテナウォームアップ池ソリューション：

• 100 個のウォームアップコンテナ、各 200MB メモリ：$500/月 メモリコスト
• ウォームアップ池インフラのメンテナンス：最低 $1500/月 人件費
• 総コスト：$2000+、さらにセキュリティリスク

E2B ソリューション：

• リクエストあたり $0.01：100万リクエスト = $10000/月（いや、E2B にはバッチ割引がある）
• 実際の月額コストは約 $1000+ だが、起動遅延 150ms

Dynamic Workers ソリューション：

• unique Worker 料金：100万 * $0.002 = $2000/月（これも違う、これは 1 日あたり unique）
• 正しい計算：1 日 1000 unique Worker と仮定、$0.002 * 1000 * 30 = $60/月
• invocation と CPU 時間を加え、月額コストは約 $200

重要な洞察：Dynamic Workers の料金は「リクエスト回数」ではなく「unique Worker」に基づきます。AI Agent が実行するコードがテンプレート化されている（固定の分析スクリプトなど）場合、unique Worker 数はリクエスト数よりはるかに少なく、コストはさらに下がります。

これが「リクエストごとに 1 つのサンドボックス」が経済的に可能な理由です：

• 起動が速い（ミリ秒単位）、ウォームアップ池不要
• メモリが省エネ（数 MB）、大容量メモリ予約不要
• 料金は unique Worker 単位、リクエスト単位ではない

従来のソリューションの課題と比較：

• ウォームアップ池のメンテナンスが複雑、人件費が高い
• コンテナ再利用にセキュリティリスク、追加のクリーンアップメカニズムが必要
• 3 秒の遅延がユーザー体験に影響

Dynamic Workers はこの 3 つの問題を解決し、コストもさらに低い。この計算は明確になりましたか？

Dynamic Workers vs E2B vs gVisor：どう選ぶか

Dynamic Workers の利点を多く説明しましたが、万能ではありません。異なるシナリオには異なるソリューションが適しています。

完全な比較軸を見てみましょう：

軸	Dynamic Workers	E2B (Firecracker)	gVisor	Docker
起動速度	⭐⭐⭐⭐⭐ (数ms)	⭐⭐⭐⭐ (~150ms)	⭐⭐⭐⭐ (~100ms)	⭐⭐⭐ (~500ms)
セキュリティレベル	⭐⭐⭐ (中)	⭐⭐⭐⭐⭐ (最高)	⭐⭐⭐⭐ (高)	⭐⭐ (低)
コスト効率	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
言語サポート	JS/TS only	Any	Any	Any
状態永続化	なし（DO と組み合わせ必要）	あり	なし	あり
メンテナンス複雑さ	低	低	中	高

いつ Dynamic Workers を選ぶか？

適したシナリオ：

• AI Agent が JavaScript または TypeScript を使用
• 高頻度の短時間実行、各リクエストが独立した隔離
• コスト重視、ウォームアップ池インフラをメンテナンスしたくない
• 既に Cloudflare 技術スタック（Workers、KV、D1）を使用

適さないシナリオ：

• AI Agent が Python、Rust、Go コードを実行する必要がある
• 最高レベルのセキュリティが必要（金融データ処理など）
• 永続状態が必要（Durable Objects の追加設定が必要）

いつ E2B を選ぶか？

E2B は Firecracker microVM を使用し、セキュリティレベルが最高、起動時間は 150ms。

適したシナリオ：

• Python コードの実行が必要（データ分析、機械学習）
• 最高レベルのセキュリティが必要
• 150ms の起動遅延を受け入れ可能
• 機密データを処理（金融、医療）

いつ gVisor を選ぶか？

gVisor は Google が開発したユーザー空間カーネルで、コンテナとの互換性が良い。

適したシナリオ：

• コンテナ互換性が必要（既存 Docker イメージ）
• セキュリティとパフォーマンスのバランス
• 技術スタックを変更したくない、セキュリティレベルだけを向上したい

いつ Docker を使い続けるか？

正直に言うと、多くのシナリオで Docker で十分です。

適したシナリオ：

• 各リクエストの独立した隔離が不要
• 長時間実行するサービス（短時間実行ではない）
• 成熟したコンテナインフラが既にある
• 言語が JS/TS ではない

技術選定は「どれが最善か」ではなく「どれが最適か」です。Dynamic Workers は特定のシナリオ（JS/TS AI Agent、高頻度短時間実行、コスト重視）で明確な利点がありますが、万能の代替ではありません。

Cloudflare Agent エコシステム：サンドボックスから永続状態までの完全ソリューション

Dynamic Workers は孤立した製品ではなく、Cloudflare Agent エコシステムの一部です。

2026 年 4 月、Cloudflare は Project Think をリリースしました——長期実行 Agent のフレームワークオーケストレーション。Dynamic Workers と Durable Objects と組み合わせ、完全な Agent 技術スタックを形成します。

3 層アーキテクチャ

Project Think (Think 基底クラス - Agent オーケストレーション)
     |
     +-- Agent Memory (SQL データベース - 永続状態)
     |
     +-- Sub-agents (サブ Agent 協調)
     |
     +-- Dynamic Workers (サンドボックス実行)
     |     |
     |     +-- Durable Objects Facets (各サンドボックスの独立した SQLite)
     |
     +-- Tools (API 呼び出し - egress proxy クレデンシャル注入)

Durable Objects Facets

Durable Objects Facets は 2026 年 4 月にリリースされた新機能です。各 Dynamic Worker は独立した SQLite データベースを持つことができ、状態は永続化され、サンドボックス破棄後も失われません。

これは Dynamic Workers の課題を解決します：サンドボックスは実行後に破棄され、状態を保持できない。Facets により、各サンドボックスは独自の「ノート」を持ち、実行後も以前の記録を参照できます。

Project Think

Project Think は Agent フレームワークで、Think 基底クラスを提供します。Think 基底クラスを継承し、独自の Agent ロジックを実装できます——サブ Agent 協調、状態管理、ツール呼び出しを含みます。

公式ブログの例：データ分析 Agent が Dynamic Workers で分析コードを実行し、Durable Objects Facets で履歴結果を保存し、Project Think で複数のサブ Agent を協調させます。

Agents SDK

Cloudflare は Agents SDK も提供し、Dynamic Workers、Durable Objects、Project Think の統合をカプセル化しています。SDK を使って完全な AI Agent を迅速に構築できます。

// Agents SDK サンプル
import { Agent } from 'cloudflare:agents-sdk';

class DataAnalysisAgent extends Agent {
  async analyze(data: string) {
    // Dynamic Workers で分析コードを実行
    const worker = await this.sandbox.load({
      code: this.generateAnalysisCode(data),
      bindings: { db: this.memory }
    });

    const result = await worker.execute();

    // 結果を Facets に保存
    await this.memory.save(result);

    return result;
  }
}

このエコシステムにより、Dynamic Workers は「単なるサンドボックス」から「Agent 技術スタックの一部」にアップグレードされました。AI Agent が状態の永続化、サブ Agent の協調、ツール呼び出しを必要とする場合、Cloudflare の完全なソリューションは複数のサービスを組み合わせるより簡単です。

結論

Dynamic Workers はすべてのサンドボックスソリューションを置き換えるものではありません——特定のシナリオで 100 倍のパフォーマンス向上を提供するオプションです。

核心価値：「リクエストごとに 1 つのサンドボックス」を技術的に可能から経済的に可能にすること。

AI Agent が JavaScript または TypeScript を使用し、各ユーザーリクエストに独立した隔離環境を提供する必要があり、コスト重視なら——Dynamic Workers は現在、最も適したソリューションです。

次のステップ：

• Cloudflare Dynamic Workers 公式ドキュメントにアクセス
• Sandbox SDK の AI Code Executor チュートリアルで最初のサンドボックス環境を構築
• Durable Objects Facets を組み合わせて状態永続化を実現
• Agent が長期実行と協調を必要とする場合、Project Think フレームワークを探索

最終的に、技術選定の核心は計算を明確にすること：起動速度、メモリコスト、セキュリティレベル、メンテナンス複雑さ。Dynamic Workers は 4 つの軸すべてで答えを提供し、残りは自分のシナリオが適合するかを判断することです。

FAQ

Dynamic Workers は Python コードを実行できますか？

できません。Dynamic Workers は V8 Isolates に基づいており、JavaScript と TypeScript のみサポートします。Python の実行が必要な場合、E2B（Firecracker microVM）ソリューションの使用をお勧めします。任意の言語をサポートしています。

V8 Isolates のセキュリティレベルは十分ですか？

多くのシナリオで十分です。Cloudflare は 5 層防御を追加：V8 パッチの自動配信、テナント分離、MPK ハードウェア保護、コードスキャン、ネットワーク隔離。金融や医療データを処理する場合、E2B（最高セキュリティレベル）の使用をお勧めします。

load() と get() の違いは何ですか？

load() は一回限りの実行で、単一データ分析や一時的なコード実行に適しています。実行後、Isolate は自動的に破棄されます。

get() はキャッシュウォームアップで、バッチ処理や長期実行 Agent に適しています。Isolate はメモリに保持され、後続の呼び出しで直接再利用されます。

Dynamic Workers の料金はどう計算されますか？

unique Worker 単位の課金で、リクエスト回数ではありません。$0.002/unique Worker/日 + CPU 時間料金 + invocation 料金。コードがテンプレート化されている（固定の分析スクリプトなど）場合、unique Worker 数はリクエスト数よりはるかに少なく、コストはさらに下がります。

状態永続化はどう実現しますか？

Durable Objects Facets を使用します。各 Dynamic Worker は独立した SQLite データベースを持つことができ、状態は永続化され、サンドボックス破棄後も失われません。Project Think フレームワークと組み合わせて完全な Agent 技術スタックを構築できます。

ウォームアップ池と Dynamic Workers はどちらが適していますか？

シナリオによります。ウォームアップ池は長時間実行するサービスに適しており、言語は限定されません。

Dynamic Workers は高頻度の短時間実行（AI Agent コード実行）に適しており、JS/TS のみ、コストがより低く、各リクエストが独立した隔離でセキュリティリスクがありません。

9 min read · 公開日: 2026年4月25日 · 更新日: 2026年4月25日