「エージェントが書いたコードを実行させたいが、社内インフラには絶対に直接走らせたくない」「ブラウザ操作系のエージェントを動かす VM を増やすたび運用コストが膨らむ」——4 月以降、エージェントの 実行環境（ランタイム）に関する相談が一気に増えました。背景には、Cloudflare が AI エージェント向けの永続化対応隔離実行環境「Cloudflare Sandboxes」を GA（一般提供）に格上げしたことがあります。エージェントが任意コードを実行・ファイル操作・ブラウザ操作する際の隔離環境を、自社で持たずに Cloudflare 側に寄せられるようになりました。
本記事では、エージェントが「実行する側」になる時代の受託設計指針と、既存サンドボックス基盤（自前 K8s / Firecracker / コンテナ）からの移行ステップを整理します。
なぜ「エージェント専用サンドボックス」が必要なのか
「エージェントが書いたコードを動かす」という要件は、2026 年現在ほぼすべての本格的なエージェント案件で発生します。しかし、これを既存のインフラに直接走らせるのは複数の意味で危険です。
| リスク | 影響 |
|---|---|
| 任意コード実行 | 社内ネットワーク全体への横展開 |
| 永続化されないファイル系操作 | エージェントの状態が次回ターンで消える |
| ブラウザ操作の VM コスト | 1 セッションごとに VM 起動が必要 |
| 監査証跡の断絶 | 何のコードが何のリソースを触ったか不明 |
これらを「自社で K8s + Firecracker + ストレージ + ネットワーク隔離」で組むと、インフラチーム 2〜3 名張り付きの構成になります。Cloudflare Sandboxes は、ここを丸ごと引き受けてくれるため、受託案件で組むときの責任分界点が明確になります。
アーキテクチャ全体像
弊社が受託案件で標準化している構成は次の 4 層です。
- エージェント層 — Claude / Gemini / OpenAI（Workers AI 上または外部）
- オーケストレーション層 — Workers / Durable Objects、ツール呼び出し管理
- 隔離実行層（Cloudflare Sandboxes） — 永続ファイルシステム付き隔離 VM
- 業務 UI 層 — Slack / 社内ポータル / Web UI
エージェントが「コードを書いて実行する」「ブラウザを操作する」「ファイルを保存する」という処理は、すべて Sandboxes 内で完結させます。エージェントは外側から命令するだけで、本体ロジックは Sandbox に閉じ込めるのがセキュリティの肝です。
受託で押さえる 5 つの設計指針
1. 「セッション = サンドボックス」マッピングを明確にする
Cloudflare Sandboxes は永続化されているため、次回呼び出し時に前回の状態を引き継げます。受託で組むときに最初に決めるのは 「サンドボックスの単位は何か」 です。
| マッピング | 適用例 |
|---|---|
| ユーザー単位 | ChatGPT 風の対話エージェント |
| プロジェクト単位 | 顧客プロジェクト用の調査エージェント |
| タスク単位 | 1 回のジョブで使い捨て |
ユーザー単位だと長期コンテキストが豊かになる反面、データ保持責任が重くなります。プロジェクト単位が、受託案件ではバランスが良いことが多いです。
2. 入出力境界での「Sanitize」を必ず入れる
エージェントが Sandbox 内で吐いたコマンドや結果を、外部に渡す前に必ずサニタイズします。
async function runInSandbox(sandboxId: string, code: string) {
const result = await env.SANDBOX.get(sandboxId).exec({
language: "python",
code,
timeout_ms: 30_000,
network: "deny", // デフォルトで外向き通信は拒否
});
return {
stdout: redactSecrets(result.stdout),
stderr: redactSecrets(result.stderr),
files: result.files.filter(f => isAllowedPath(f.path)),
};
}ポイントは network: "deny" をデフォルトにし、必要なドメインだけ allowlist で開けることです。これだけで、SSRF や外部送信系の事故を大幅に減らせます。
3. ストレージは「セッション内 / セッション間」で分離
Cloudflare Sandboxes の永続ストレージは便利ですが、用途を整理しないとデータの寿命が把握不能になります。受託案件では次の 3 階層で整理しています。
- セッション内（揮発）:
/tmp相当、セッション終了で破棄 - セッション間（永続）:
/workspace相当、サンドボックス単位で保持 - 永続ストレージ（外部）: R2 / KV、サンドボックス越しに保存
「ユーザーが次回も使うファイル」は /workspace、「他ユーザーと共有する成果物」は R2、と明確に分けます。
4. 監査証跡は「Sandbox 起動 / コマンド実行 / ファイル変更」の 3 階層で残す
監査要件があるエンタープライズ案件では、次の 3 階層を別ストレージに永続化します。
- sandbox_id ─┬─ start_event (user_id, project_id, started_at)
├─ command_event (cmd, exit_code, duration_ms)
└─ file_event (path, op, size, hash)特に 「どの会話でどのコードが実行され、どのファイルが書き込まれたか」 を conversation_id まで紐づけて残しておくと、PII 漏洩や誤実行の事後検証が圧倒的に速くなります。
5. コスト管理は「タイムアウト × アイドル破棄」で
Cloudflare Sandboxes は永続化が便利な反面、放置するとサンドボックスがどんどん溜まります。受託では次の 2 つを必ず仕込みます。
- コマンド実行タイムアウト: 30 秒〜 5 分（用途による）
- アイドル時の自動破棄: 24 時間アクセスがなければ削除
これだけで月額コストの肥大を 7〜8 割抑えられます。
既存サンドボックス基盤からの移行ステップ
「すでに自前で Firecracker / K8s ベースのサンドボックス基盤を持っている」案件では、いきなり全面切り替えではなく段階移行が安全です。
Step 1: 新規ユースケースだけ Cloudflare Sandboxes へ
既存基盤はそのまま、新規エージェント案件のみ Cloudflare Sandboxes で実装。
Step 2: 短命サンドボックスから移行
タスク単位の使い捨てサンドボックス（コード実行、Web スクレイピング）を先に移行。
Step 3: 永続セッションの移行
ユーザー単位 / プロジェクト単位のサンドボックスを、データ移行とともに切り替え。
Step 4: 自前基盤の縮退
トラフィックを Cloudflare 側に寄せきった後、自前基盤の運用を縮退。
弊社が OpenAI Agents SDK v2 のサンドボックス・メモリ運用 で整理した「実行環境とエージェントの責任分離」は、Cloudflare Sandboxes でも同じ整理が活きます。
適用判断 — Cloudflare Sandboxes が「向く」ケース、「向かない」ケース
| ケース | 向く / 向かない | 理由 |
|---|---|---|
| 一般的な業務エージェント | 向く | Workers/Durable Objects との統合がスムーズ |
| ブラウザ操作系エージェント | 向く | ヘッドレスブラウザを Sandbox 内で完結 |
| 機密データを扱う基幹連携 | 要検討 | データ保管場所のリージョン要件次第 |
| GPU が必要な ML ワークロード | 向かない | Sandboxes は CPU 中心 |
| 100ms 未満のレイテンシ要件 | 要検討 | コールドスタート設計を別途必要 |
「向く / 要検討 / 向かない」の判断は、受託の初期ヒアリングで必ず確認します。誤った判断のまま PoC を進めると、後段で大幅な手戻りになります。
Anthropic Computer Use を業務に組み込むガイド で触れたブラウザ操作系のサンドボックス要件は、Cloudflare Sandboxes と組み合わせる場合の好適例です。
まとめ
Cloudflare Sandboxes の GA は、エージェントが「実行する側」に回る時代に、自社で隔離環境を運用しなくて済む現実解を提供します。受託で押さえる 5 点は次の通りです。
- セッション = サンドボックスのマッピングを最初に決める
- 入出力境界で Sanitize、ネットワークはデフォルト deny
- ストレージを「セッション内 / セッション間 / 外部」の 3 階層で分離
- 監査証跡を 3 階層で残す
- タイムアウトとアイドル破棄でコストを抑制
弊社では Cloudflare Sandboxes を採用したエージェント案件を進めています。「自前でサンドボックスを運用するコストが重い」「セキュリティ部門の承認が下りない」案件があれば、お気軽にご相談ください。
