仕組み — microVM による隔離

Docker Sandboxes が microVM で何を隔離するのか、コンテナやエージェント同梱サンドボックスとの違いを説明する。動機とリスクの整理ははじめる：なぜ必要か、ネットワークや認証情報の運用境界は安全性へ。

microVM多層隔離

検証: sbx v0.35.0・macOS (Apple Silicon)

先に動かしてみたい方へ

インストールと最初の実行は「はじめる」、作業フォルダの渡し方や日常操作は「使い方」へ。

1.このページの位置づけ

ホスト上でエージェントに全権を渡す構造的リスクと、Docker Sandboxes がそれを microVM で区切る、という動機ははじめるにまとめた。ここから先は、その境界が技術的にどう実装されているか （microVM・ネットワーク・専用 Docker Engine・ワークスペース・認証情報の各層）を述べる。

YOLO モード（確認を全部飛ばして全自動で走らせる運用）という用語も「はじめる」で定義している。本稿の隔離比較や注意書きでも同じ意味で使う。

2.仕組み — microVM による多層隔離

📖 この記事での用語

サンドボックス — sbx で作成・停止・削除する利用者向けの単位。
microVM — サンドボックスの主要な隔離境界。独自の Linux カーネルを持つ。
エージェント用コンテナ — microVM 内で Claude Code などを実行する環境。
専用 Docker Engine — 同じ microVM 内でエージェントが利用する dockerd。

コンテナではなく microVM である理由

「Docker なんだからコンテナで隔離すればいいのでは？」と思いがちだが、通常の Linux コンテナは 名前空間の分離とリソース制限の仕組みであって、セキュリティ境界ではない （minamijoyo 氏の解説でも強調されているポイント）。コンテナはホストとカーネルを共有するため、カーネル脆弱性を突かれれば脱出できてしまう。

Docker Sandboxes は各サンドボックスを軽量 microVM として起動する。ゲスト OS（Ubuntu）が独自のカーネルを持つためホストとカーネルを共有せず、ハイパーバイザーが信頼境界になる。それでいて従来の VM ほど重くなく、 VM 内には専用の Docker Engine が立つので、エージェントはサンドボックスの中で自由に docker build / docker run までできる。

🐳 ホストに Docker Desktop / Docker Engine は不要

組み込みエージェントのデフォルトテンプレートは、名前が claude-code-docker や shell-docker のように -docker で終わる（いわゆる -docker 版）。これは「ホストの Docker を借りる」のではなく、 サンドボックス（microVM）の中に Docker Engine（dockerd）が同梱されたイメージを指す。ホストの Docker ソケットやイメージ保存領域は使わないため、ホストに Docker Desktop / Docker Engine がなくても、サンドボックス内では docker build / docker run が動く。Engine・イメージ・コンテナ・ボリュームはサンドボックスごとに独立する。

専用 Docker Engine を確認

# ホスト側
$ sbx exec -it mybox bash

# サンドボックス内
# docker version
# docker run --rm hello-world
# docker build -t my-app .

-docker 版（例: …:claude-code-docker）のエージェント用コンテナは microVM 内では特権モードで動き、デフォルト 50 GB の疎なブロックボリュームを /var/lib/docker に使う。これはホスト上で特権コンテナを動かすのとは異なり、外側の microVM が信頼境界になる。対してサフィックスのない非 Docker 版（例: --template docker.io/docker/sandbox-templates:claude-code）は、イメージに専用 Engine を含まない軽量構成である。イメージの取得はネットワークポリシーにも従う。

ホスト上の microVM・ネットワークプロキシ・プロジェクトのマウントの関係。エージェントの HTTP(S) はプロキシ経由で外部へ出る一方、生の TCP/UDP/ICMP はネットワーク層で遮断される。

microVM 内のコーディングエージェントと Docker デーモンが、ネットワークプロキシとファイルシステム管理を介して外部へアクセスする構成。プロキシ管理のサービス資格情報（緑）は、リクエストがネットワークプロキシを通るときに付与される。図の出典: 根本征「コーディングエージェントを安全に実行させる新しいアプローチ」p.10

5 層の隔離モデル

公式ドキュメントが説明する隔離のレイヤーは次の 5 つ。

1️⃣ ハイパーバイザー隔離

各サンドボックスが独自カーネルを持つ microVM。ホストとカーネルを共有しないため、これが主要な信頼境界になる。エージェントは VM 内では root 相当の全権を持つが、VM の外には出られない。

2️⃣ ネットワーク隔離

HTTP/HTTPS は許可ドメインのみホスト側プロキシ経由で通る（デフォルトは拒否）。生の TCP・UDP・ICMP はネットワーク層で遮断される。

3️⃣ Docker Engine 隔離

サンドボックスごとに専用の Docker Engine。エージェントがコンテナを立てても、ホスト側 Mac の Docker 環境（イメージ・ボリューム・ネットワーク）とは完全に分離。

4️⃣ ワークスペース隔離

追加マウントは読み取り専用（ro）にできるほか、--clone ならホストの Git 作業ツリーを読み取り専用にし、VM 内のプライベートクローンで作業させられる。

5️⃣ 認証情報隔離

サービス資格情報はホスト側プロキシが外向き HTTP リクエストへ注入するため、生の値を VM に渡さずに使える。レジストリ資格情報など、この保護の対象外になる方式もある。

隔離レベルの比較

方式	カーネル隔離	リソース効率	環境内での docker 実行	総合評価
ホスト直接実行	✗ なし	—	ホストと共用	危険。YOLO モードとの組み合わせは特に。
エージェント同梱のサンドボックス（Claude Code の sandbox 等）	△ ホストカーネル上の制限（macOS Seatbelt / Linux bubblewrap 等）	◎ ほぼオーバーヘッドなし	△ ホスト側 Docker と共用になりやすい	エージェントが起動する Bash 等への内側の行儀制限。ホスト OS そのものは共有する。
通常のコンテナ (devcontainer 等)	✗ カーネル共有	◎ 軽量	△ dind は要特権	利便性は高いがセキュリティ境界ではない。
Docker Sandboxes	◎ microVM	○ 軽量 VM	◎ デフォルトの `-docker` 版イメージに microVM 内専用 Engine	ゲスト OS を持つ外側の実行環境隔離。自律エージェント用途で隔離と開発体験のバランスがよい。
従来のフル VM	◎ 完全分離	△ 重量級	○ 可能	安全だがセットアップと運用が重い。

「既に Claude Code の sandbox を ON にしているのに、なぜ sbx が要るのか」への答えは、役割が違うことだ。エージェント同梱のサンドボックスは、主にエージェントが起動するコマンドに対する OS 機構ベースの制限（Claude 公式の説明では macOS の Seatbelt、Linux / WSL2 の bubblewrap など）。適用面はツール実装に依存し、Bash 中心に偏っている場合は他のツール呼び出し経由ですり抜けうる、と指摘されることもある（版で変わりうる。過信しにくい）。 Docker Sandboxes はゲスト OS を持つ microVM で、ホストとカーネルを共有しない外側の境界になる。併用はあり得るが、内側の行儀制限と外側の実行環境隔離は置き換えではなく補完関係（Codex の seatbelt との二重境界は使い方のエージェント節でも触れている）。 Claude 公式ドキュメントも、仮想マシンでサンドボックスを作るケースとして Docker Sandboxes を紹介している。

次の一歩

ネットワークポリシー、認証情報・SSH エージェントの境界、clone モード、注意点と参考リンクは安全性へ続く。