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 の 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 を発生させません。メモリ割り当て、GC、コンパイル実行はすべてプロセス内で完結します。隔離境界はカーネルではなくプロセス内部にあります。

テンセントニュース 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つなのは、隔離境界がプロセス内部にあるためです。1 つの Isolate が突破されると、同一プロセス内の他 Isolate へ影響する可能性があります。コンテナ（namespace 隔離あり）よりは強く、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：DB、ストレージ、API など外部リソースのバインド
• limits：リソース濫用防止の実行制限

load() の向いている場面：

• 単発データ分析：CSV アップロード → AI が分析コード生成 → 1 回実行して破棄
• 一時的なコード実行：変換スクリプト、検証ロジック
• リクエスト単位の隔離：残留データリスクなし

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：状態を保ちたい分析タスク
• 初回遅延の削減：ウォームアップによる高速化

本質的な違いは、load() が「1 泊だけ部屋を借りる」、get() が「長期契約で部屋を確保する」イメージです。前者は瞬間的、後者は継続的なシナリオ向きです。

Cloudflare 公式 Sandbox SDK の AI Code Executor チュートリアルに、より完全な例があります。本記事を読んでから実践に進むのがおすすめです。

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

前述のとおり、V8 Isolates の基本セキュリティは星3つです。Dynamic Workers では多層防御を重ね、本番で使える水準まで引き上げています。

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

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

V8 エンジンにも脆弱性は避けられません。Chrome チームがパッチを出すと、Cloudflare は数時間以内に全世界のノードへ配信します。

従来のコンテナ環境はホスト OS 依存で、パッチ周期が数週間〜数ヶ月になることもあります。V8 パッチの対応は「時間単位」です。

第二層：動的リスク Tenant Cordoning

メモリ急増や CPU スパイクなど異常挙動の Dynamic Worker は「高リスク」とマークされ、専用隔離ノードへ移されます。

tenant cordoning——リスク tenant を単独隔離し、他の正常 Worker への影響を防ぎます。

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

MPK（Memory Protection Keys）は Intel のハードウェアメモリ隔離です。各 Isolate に独立したアクセス権限があり、ハードウェアレベルで越境アクセスを阻止します。

物理層の保護で、ソフトウェア隔離より突破が困難です。

第四層：コードスキャン

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

Prompt 注入で AI が危険コードを生成するケースへの防御層です。

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

Dynamic Worker はデフォルトで外部ネットワークを完全ブロック。外部 API が必要な場合は Cloudflare の egress proxy 経由で、認可 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 の料金体系（Beta 期間は無料、正式価格は以下）：

• $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 秒遅延が UX を損なう

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）

向いていない：

• Python、Rust、Go の実行が必要
• 最高セキュリティ（金融データなど）
• 永続状態（Durable Objects の追加設定が必要）

E2B を選ぶとき

Firecracker microVM で最高セキュリティ、起動 150ms。

向いている：

• Python（データ分析、機械学習）
• 最高セキュリティ要件
• 150ms 起動遅延を許容
• 金融・医療など機密データ

gVisor を選ぶとき

Google 製ユーザー空間カーネル。コンテナ互換性が高い。

向いている：

• 既存 Docker イメージの互換性
• セキュリティと性能のバランス
• スタックを変えずセキュリティだけ上げたい

Docker を使い続けるとき

多くの場面では Docker で十分です。

向いている：

• リクエストごと独立隔離が不要
• 長時間稼働サービス（瞬間実行ではない）
• 成熟したコンテナインフラがある
• JS/TS 以外の言語

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

Cloudflare Agent エコシステム：サンドボックスから永続状態まで

Dynamic Workers は単体製品ではなく、Cloudflare Agent エコシステムの一部です。

2026 年 4 月、Cloudflare は長期稼働 Agent 向けフレームワーク Project Think を発表しました。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

2026 年 4 月リリースの新機能です。各 Dynamic Worker に独立 SQLite を持たせ、サンドボックス破棄後も状態を保持できます。

Dynamic Workers の弱点——実行後に状態が消える——を Facets が補います。各サンドボックスが独自の「ノートブック」を持ち、過去の記録を参照できます。

Project Think

Agent フレームワークで Think 基底クラスを提供します。継承してサブ Agent 協調、状態管理、ツール呼び出しを実装できます。

公式例：データ分析 Agent が Dynamic Workers でコード実行、Durable Objects Facets で履歴保存、Project Think で複数サブ Agent を協調。

Agents SDK

Dynamic Workers、Durable Objects、Project Think の統合を SDK がラップしています。

// 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;
  }
}

状態永続、サブ Agent 協調、ツール呼び出しが必要なら、複数サービスを寄せ集めるより Cloudflare 一式の方が楽です。Dynamic Workers は「単なるサンドボックス」から Agent スタックの中核へと位置づけが変わります。

まとめ

Dynamic Workers はすべてのサンドボックスを置き換えるものではありません。特定シナリオで約100倍の性能向上を選べるオプションです。

核心価値は、「リクエストごと1サンドボックス」を技術的・経済的に両方可能にすること。

JavaScript / TypeScript の AI Agent で、ユーザーごと独立隔離が必要かつコスト重視なら、現時点で Dynamic Workers は有力な選択肢です。

次のステップ：

• Cloudflare Dynamic Workers 公式ドキュメント
• Sandbox SDK の AI Code Executor チュートリアルで最初のサンドボックスを構築
• Durable Objects Facets で状態永続化
• 長期稼働・協調が必要なら Project Think を検討

技術選定の核心は勘所をはっきりさせること。起動速度、メモリコスト、セキュリティ、保守の複雑さ——Dynamic Workers は4軸すべてに答えを出しています。あとは自分のシナリオが合うかどうかを判断するだけです。