実行環境 ─ Firecracker・永続性・Egress

2026/05/10

実行環境 ─ Firecracker・永続性・Egress

ch5 のメモリにツール呼び出しの結果が溜まる前に、そのツール呼び出しが実際に走る場所を決めなければならない。subprocess.run("python script.py") をホスト OS で叩いていいのは、ローカルで自分一人が遊んでいるときだけだ。業務投入では、コード実行・ブラウザ操作・ファイル操作はすべて隔離された環境で走らせるのが前提になる。これが Layer 4：実行環境だ。

本章では、5 つの軸で業務投入できる実行環境の組み立て方を扱う。

軸 1：隔離技術の選択肢が「Firecracker microVM」に収束した

2025-2026 で、エージェント向け sandbox の隔離技術は Firecracker microVM がデフォルトに統一されつつある。NVIDIA は 2026 年に明示的に発信している：

kernel 共有型（macOS Seatbelt / Linux Bubblewrap / Windows AppContainer）は、信頼できないコード実行には不十分。full virtualization か gVisor を推奨。

各隔離技術の比較：

技術	起動時間	オーバーヘッド	用途	採用例
Firecracker microVM	~125ms	<5 MiB/VM、150 VMs/s/host	信頼できないコード・規制データ必須	E2B / Vercel / Fly
gVisor	サブ秒	I/O 重で 10-30% 性能低下	compute-heavy multi-tenant	Modal / OpenAI Code Interpreter
Kata Containers	~100ms	VMM 抽象化、k8s API	k8s ネイティブ	（汎用）
V8 isolate	ms 級	MB 級メモリ、JS/WASM 限定	エッジ・大量 agent	Cloudflare
❌ Bubblewrap / Seatbelt	-	-	ローカル・1 ユーザーのみ	OpenAI Codex CLI

OpenAI Codex CLI が macOS Seatbelt と Linux bubblewrap を使っているのは「ローカル・1 ユーザー前提だから可」と理解するのが正しい。SaaS で multi-tenant に出すなら microVM 必須だ。

軸 2：クラウドサンドボックス 5 製品の住み分け

2026-05 時点で本番運用候補は 5 つ。価格はほぼ収束しているので、差別化軸は egress policy・persistence・OS ネイティブ感だ。

E2B (e2b.dev)

隔離：Firecracker microVM、KVM、jailer プロセスで二重防御
起動：boot 125-200ms、cold start 80ms（同一リージョン）
価格：Hobby 無料 ($100 一回クレジット、1 時間セッション、20 並列)、Pro $150/月（24h、100 並列）
従量：$0.000014/vCPU-s、$0.0000045/GiB-s（Pro 換算で約 $0.07/CPU-h）
採用：Manus が採用（150ms 起動、最大 14 日のデータ保持）
強み：Firecracker の信頼性、LangChain / OpenAI / Anthropic SDK と直結、OSS で self-host 可

Daytona Cloud

隔離：標準 Docker 互換（Firecracker / gVisor 採用は明示なし[要検証]）
起動：71ms 作成 / 67ms exec / 59ms cleanup
価格：完全 PAYG、$0.0504/vCPU-h、$0.0162/GiB-h、$200 無料、スタートアップ $50k 枠
特徴：Stateful（filesystem / env / process が会話間で保持）、OpenAI Agents SDK の組み込み provider
強み：月額固定費なし、Stateful sandbox で長期タスク向き

隔離：gVisor、user-space kernel
起動：サブ秒、5 万並列まで autoscale
価格：$0.0000131/CPU/s、$30/月クレジット
強み：GPU 推論 / fine-tuning と同居可能なのは Modal だけ、egress policy がビルトイン
弱み：gVisor は I/O 重で 10-30% 性能低下

Vercel Sandbox

隔離：Firecracker microVM
環境：Amazon Linux 2023、node24/22 + python3.13
制約：Hobby 45min / Pro 5h、persistent sandbox（停止時 state 自動保存）は beta
特徴：2026/04 に Open Agents OSS リリース

Cloudflare Sandboxes / Project Think

隔離：V8 isolate（コンテナの ~100× 高速・10-100× メモリ効率）
アーキ：Durable Objects で agent ごとに SQLite + R2 のワークスペース、hibernation で idle コストゼロ
GA：2026/04
強み：globalOutbound: null で default-deny egress、capability binding で許可制
弱み：JS/WASM 限定（Python は実行できない）

選択軸を整理するとこうなる。

要件	おすすめ
Firecracker で信頼性最優先	E2B or Vercel Sandbox
GPU 推論 / fine-tuning と同居	Modal
Stateful で長期タスク	Daytona
大量 agent + idle コストゼロ	Cloudflare Project Think
月額固定費を払いたくない	Daytona or Modal

軸 3：永続 sandbox の「二段構え」設計

業務投入の第一の壁は **「sandbox の lifecycle をどう設計するか」**だ。短命 vs 長命のトレードオフは厳密には 5 軸ある。

軸	短命（ephemeral）	長命（persistent）
state	外部 storage に逃がす	sandbox 内に保持
再現性	高い（毎回クリーン）	低い（実行履歴に依存）
コスト	0（idle 時）	sandbox 維持コスト
タスク向き	RAG / 単発計算 / 1 ショット	multi-step / 長時間 / 学習型
クラッシュ耐性	弱い（再実行は最初から）	強い（state を保持）

業務投入の実用解は 「短命 + 外部 state」の二段構えだ。

graph TB
    subgraph "Control Plane (永続)"
        H[Harness / Workflow Engine]
        S[(External State<br/>S3 / R2 / SQLite-DO)]
    end

    subgraph "Execution Plane (短命)"
        E1[Sandbox 1<br/>Firecracker]
        E2[Sandbox 2<br/>Firecracker]
    end

    H --> E1
    H --> E2
    E1 -.write.-> S
    E2 -.write.-> S
    S -.restore.-> E1
    S -.restore.-> E2

このパターンは OpenAI Agents SDK が公式に採用している（harness = control plane、sandbox = execution plane の分離）。Manus も Cloudflare Project Think も、本質的にこの設計だ。

実装の要点：

Sandbox 内で書く state は、全部 external state に書き出す前提でコードを書く
Sandbox は「いつでも消える」想定で扱う
Container loss から復旧するときは、external state から state を読み戻して新しい sandbox に注入

軸 4：Egress policy ── default-deny からスタートする

「Egress policy がない sandbox は本番に出してはいけない」── これが NVIDIA / Microsoft / Cloudflare 各社の共通指針だ。

理由は単純で、ツールが書く出力先がフリーだと、

Cloud metadata（169.254.169.254）から credentials を盗まれる
DNS over HTTPS で内部データを exfiltrate される
RFC1918（プライベート IP）経由で社内サービスに到達される

という典型的な攻撃が成立する。

ベスプラの最低セット：

1. default-deny + allowlist
   - 169.254.169.254 を完全ブロック
   - RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ブロック
   - 必要な outbound だけ allowlist で許可

2. DNS は信頼レゾルバに固定
   - Cloudflare 1.1.1.1 / Google 8.8.8.8 など
   - DNS over data exfil 対策

3. secret は task-scoped で短命トークン
   - host env をそのまま継承させない
   - credential broker（HashiCorp Vault / AWS Secrets Manager）から都度発行

4. workspace 外への write 禁止
   - sandbox の指定ディレクトリ以外は read-only
   - ~/.ssh、~/.aws、.cursorrules などは read 禁止

Cloudflare は globalOutbound: null + capability binding でコードレベルで default-denyを強制する設計をデフォルト化した。E2B / Daytona は egress proxy を別途書く必要があり、ここでセキュリティ事故が起きやすい。

軸 5：Computer Use / Browser 環境の本番設計

ch4 で扱った Computer Use は、本番運用するなら Anthropic 公式の reference Docker image を起点に組むのがベストプラクティスだ。

✅ Computer Use の本番運用構成（最小）
─────────────────────
- VM: Firecracker microVM（E2B / Vercel）
  └── Docker container (Anthropic reference image)
        └── 仮想 X server + Chromium
              └── Computer Use API がここに接続

- 全 outbound traffic を MCP gateway 経由に
- secret は HashiCorp Vault から短命トークンで注入
- 全画面操作を録画（事後監査用）
- prompt injection monitor を併設（ChatGPT Agent の watch mode 相当）

ブラウザ自動化を業務に乗せるなら、Browserbase（汎用）vs Anchor Browser（規制業務）の二極選択になる。

製品	強み	価格
Browserbase	Stagehand SDK、LangChain / CrewAI / Mastra 連携	$20/月〜（25 並列、100h）
Anchor Browser	CAPTCHA 自動解決、anti-bot fingerprinting、SOC2 Type 2 / ISO27001 / HIPAA / GDPR	$50〜、$0.10/タスク従量

金融・医療・行政ポータルのような 規制業務 なら Anchor、それ以外は Browserbase が無難だ。

❌ アンチパターン：subprocess + ホスト OS で Computer Use

症状
─────────
- ホスト OS の secret が agent に読まれる
- Tool Poisoning 経由で sandbox escape が起きる
- Code Interpreter のコストが破裂する（短命 sandbox にせず垂れ流し）

根本原因
─────────
- 隔離なし（kernel 共有型のローカル実行）
- Egress policy なし（cloud metadata に到達可能）
- Sandbox が長命のままで idle 課金が続く

脱出法
─────────
1. Firecracker microVM（E2B / Vercel）or V8 isolate（Cloudflare）に切り替え
2. default-deny egress + allowlist + DNS 固定 + workspace 外 write 禁止
3. 短命 sandbox + 外部 state の二段構えに変更
4. Computer Use は Anthropic 公式の reference Docker image を起点に

業務投入の観点で重要な 3 点

隔離は Firecracker microVM がデフォルト：NVIDIA も「kernel 共有型は不十分」と明示。SaaS で multi-tenant に出すなら microVM 必須。Cloudflare の V8 isolate は JS/WASM 限定だが、大量 agent + idle コストゼロという別の利点がある
Sandbox は「短命 + 外部 state」の二段構え：control plane（永続）と execution plane（短命）を分離。Sandbox は「いつでも消える」想定で扱う
Egress policy がない sandbox は本番に出さない：default-deny + allowlist + DNS 固定 + workspace 外 write 禁止 + secret は短命トークン。Cloudflare の globalOutbound: null + capability binding が最も筋が良い設計

次章への接続

実行環境はクラッシュする。Firecracker microVM もコンテナも、ハードウェア障害・ネットワーク断・OOM で落ちる。落ちた瞬間に完了済みの作業をやり直さないためには、Layer 5 のオーケストレーションで Durable Execution（journal + replay） を組み込む必要がある。次の ch7 で扱う。

この章のまとめ

隔離は Firecracker microVM がデフォルト：kernel 共有型（Seatbelt / Bubblewrap）はローカル限定
5 製品の住み分け：E2B / Vercel = 信頼性、Modal = GPU 同居、Daytona = stateful、Cloudflare = 大量 agent + idle 0
「短命 sandbox + 外部 state」の二段構え：control plane と execution plane を分離
Egress policy は default-deny からスタート：169.254.169.254 / RFC1918 を完全ブロック
Computer Use は VM + reference Docker image + MCP gateway + 録画：本番運用の最小構成
Browser は Browserbase（汎用）vs Anchor（規制業務）の二極

実行環境 ─ Firecracker・永続性・Egress

軸 1：隔離技術の選択肢が「Firecracker microVM」に収束した

軸 2：クラウドサンドボックス 5 製品の住み分け

E2B (e2b.dev)

Daytona Cloud

Modal Sandboxes

Vercel Sandbox

Cloudflare Sandboxes / Project Think

軸 3：永続 sandbox の「二段構え」設計

軸 4：Egress policy ── default-deny からスタートする

軸 5：Computer Use / Browser 環境の本番設計

❌ アンチパターン：subprocess + ホスト OS で Computer Use

業務投入の観点で重要な 3 点

次章への接続

この章のまとめ