Docker Sandboxes（sbx）入門｜Claude Code を microVM で安全に無人実行

Docker Sandboxes（CLI: sbx）は、AIコーディングエージェントをホストから分離したmicroVMで動かすDocker公式の仕組みです。この記事では、隔離の範囲と導入手順を確認したうえで、workspace・ポリシー・認証情報をどう管理するかを整理します。

対象読者: Claude Code / Codex などをローカルで無人・長時間回したい開発者です。公式ドキュメントと独立解説をもとに、隔離モデル → 前提条件 → 導入 → YOLO / skip-permissions の条件 → 比較と採用チェックリスト、の順で整理します。

読後に取る行動は、次の4つに絞れます。

1. OS / ハイパーバイザ前提を確認して sbx を入れる
2. まず1プロジェクトで小さく始め、Balanced ポリシーで sbx run claude を試す
3. sbx policy ls と workspace / clone を点検する
4. 不要になったら sbx rm で捨てる

エージェント内蔵の軽いサンドボックスとの切り分けは、別記事 Claude CodeとCodexのサンドボックス選び方 もあわせて参照してください。

---

1. Docker Sandboxes とは何か（microVM と sbx）

結論から言うと、Docker Sandboxes は「共有カーネルのコンテナ」ではなく、ハイパーバイザ境界の microVM 上で AI エージェントを動かす公式ツールです。

各サンドボックスが独立して持つもの

Docker 公式 docs によれば、各サンドボックスは次を独立して持ちます。

• 独自の Docker daemon（サンドボックス内でイメージ取得・コンテナ起動が可能）
• 独自のファイルシステム（パッケージ導入がホストに漏れにくい）
• 独自のネットワーク（許可ドメインとホスト proxy 経由が基本）

このため、エージェントが npm install や docker build を走らせても、ホストの Docker socket やホスト全体の FS を直接いじる前提にはなりません。

Docker Desktop は必須ではなく、sbx CLI 単体で導入できます。対応エージェントには Claude Code、Codex、Copilot、Cursor、Gemini、Kiro、OpenCode などが公式に列挙されています。

---

実行方式の比較（ざっくり）

実行の仕方	隔離のイメージ	エージェントが Docker を使うとき	典型的な弱点
ホスト直実行 + skip-permissions	ほぼなし	ホスト daemon を直撃し得る	ホスト汚染・誤削除の影響が最大
Docker socket マウント / DinD 的運用	コンテナ境界中心	ホスト側 daemon と境界が曖昧になりやすい	共有カーネル・権限の取り違え
Docker Sandboxes (sbx)	microVM / ハイパーバイザ	サンドボックス内 daemon で完結	workspace 共有・性能・ポリシー保守

出典：Docker Docs: Sandboxes、Security model（2026年7月時点）

---

なぜ microVM か（一文での位置づけ）

独立解説でも「コンテナではなく microVM」「エージェントごとに独自 kernel と in-VM Docker」と説明されています（例: Andrew Lock）。

「なぜ DinD やホスト YOLO では足りないか」 への一文回答は次のとおりです。

• 信頼境界をホストカーネル共有からハイパーバイザへ上げる
• エージェント用 Docker を VM 内に閉じる

---

2. 導入手順 — インストールから sbx run claude まで

最短経路は、前提確認 → sbx 導入 → login → 認証 → sbx run claude です。

前提（公式 get-started）

• macOS: Sonoma 14 以降 + Apple silicon
• Windows: Windows 11 x86_64 + Hypervisor Platform
• Linux: Ubuntu 24.04 以降 + KVM（例: docker-sbx と kvm グループ）
• Docker Desktop は不要

---

インストール例

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Linux（Ubuntu 例: apt パッケージ docker-sbx + kvm グループ）
# 公式 docs の Linux 手順に従う

# ログイン（初回にネットワークポリシーを選択）
sbx login

login 時のネットワークポリシーは、おおむね次の3段階です。

ポリシー	意味合い	最初の試用
Open	広い通信を許容	検証用には広すぎることが多い
Balanced	よく使う開発向けサイトを許可しつつ default deny 寄り	まずここ
Locked Down	厳格	許可ドメインを明示してから

---

Claude Code の起動

# 認証: サンドボックス内 /login（OAuth）または
sbx secret set -g anthropic

# プロジェクトで起動
cd /path/to/project
sbx run --name my-sandbox claude

# プロンプトを渡す例 / clone でホスト tree を汚さない例
# sbx run claude -- "fix the failing test"
# sbx run --clone claude -- agents

# ライフサイクル
sbx ls
sbx policy ls
sbx stop my-sandbox
sbx rm my-sandbox

GitHub トークンなどは sbx secret set -g github -t "$(gh auth token)" のように secret 経由で渡すのが公式の流れです。平文の API キーをエージェント環境にべた書きしない方針とセットで考えると安全です。

---

初回起動とホスト側の接点

初回はベースイメージ（例: Claude 向けテンプレート）の取得で時間がかかることがあります。再実行ではキャッシュが効きやすくなります。

ホスト側でエージェントが触れるのは、既定では workspace（作業ツリー） が中心です。パッケージ・イメージ・コンテナはサンドボックス内に閉じます。

運用上の補足:

• 独立解説では sbx のメモリ指定（--memory）があり、既定がホストメモリの約 50% といった注意も指摘されています（Andrew Lock）
• クリップボードからの画像貼り付けは公式 FAQ 上 opt-in（sbx settings set clipboard.imagePaste true）です

---

3. 隔離モデルと「YOLO が安全に近づく」条件

microVM があるからといって、無条件に安全になるわけではありません。 公式セキュリティモデルは、主境界を microVM としつつ、境界を越える経路と越えない経路を明確に分けています。

5つの隔離レイヤ（公式整理）

1. Hypervisor — ホストとの主信頼境界。VM 内では sudo を含む強い権限があり得る
2. Network proxy — default deny 寄り。許可ドメインへの HTTP(S)。ホスト localhost や生の TCP/UDP/ICMP は基本的に届かない
3. Per-sandbox Docker Engine — エージェント用 Docker を VM 内に閉じる
4. Workspace isolation（--clone） — 既定の direct mount ではなく、作業ツリーのクローンで分離を強める
5. Credential isolation — ホスト側 proxy が認証ヘッダを注入し、生鍵を VM に入れない設計

---

実務で見落とされやすい条件

• 既定の direct mount は working tree をホストと RW 共有します。microVM の外側でも、共有ディレクトリ上の破壊・汚染は起こり得ます
• Git hooks は git diff に出ないことがあるため、成果物レビューを diff だけに頼らない
• Claude Code の既定起動は claude --dangerously-skip-permissions です（Claude Code agent ページ）。ホスト直実行なら危険なフラグでも、sbx では microVM を safety boundary とみなして承認プロンプトを省略する、というのが公式 FAQ の説明です
• ホストの ~/.claude はマウントされません。skills はプロジェクト配下へコピーが必要で、symlink は不可
• default allow に広い wildcard（AI サービスやパッケージマネージャ向けなど）が含まれることがあるため、sbx policy ls で点検し、不要なら sbx policy allow の範囲を絞る
• 長時間・並列・破壊的変更が多いタスクでは --clone や named multi-sandbox を検討する（公式 Claude agent ページでは sbx run --clone claude -- agents のような agents view も案内）
• Claude Code 本体の /sandbox はホスト上の軽い封じ込めであり、Docker Sandboxes の microVM とは別物（Shipyard）

---

独立解説での位置づけと限界

独立記事でも、YOLO を「インフラ側のガードレール付き」で使う箱として位置づける説明が見られます（Shipyard）。

一方で、次のような限界も指摘されています（Andrew Lock）。

• commit signing と ssh-agent 共有の難しさ
• ネットワークポリシー保守
• 性能ヒット

「YOLO が安全に近づく」条件は、次が揃ったときです。

• microVM
• 狭い allow リスト
• secret 注入
• workspace 戦略
• ホスト側レビュー

---

4. 比較表 — ローカル microVM / エージェント内蔵 / ホスト型

方式ごとの比較

方式	隔離境界	エージェント内 Docker	典型ユース	注意
Docker Sandboxes (sbx)	microVM / ハイパーバイザ	可（in-VM daemon）	ローカル無人実行・YOLO	workspace 共有・性能・policy 保守
Claude Code /sandbox 等	OS sandbox（Seatbelt / bubblewrap 等）	制限あり	対話中の軽い封じ込め	ホスト上・境界が薄い
ホスト直実行 + skip-permissions	なし	host daemon	信頼済みの短時間作業	ホスト汚染リスク最大
クラウド / ホスト型 sandbox（例: E2B 等）	リモート VM 等	製品依存	チーム共有・CI 寄り	データ所在・レイテンシ・課金

出典：Docker security、Shipyard、Zenn hands-on（2026年7月時点）

---

判断の目安

判断の目安は次のとおりです。

• ローカルでエージェントに Docker を触らせたい → sbx が主戦場
• 対話中の軽い封じ込めだけでよい → エージェント内蔵 sandbox を先に検討（詳細は サンドボックス選び方）
• ホスト tree を一切共有したくない → --clone かリモート sandbox
• マルチエージェント連携そのもの → 例: Codex plugin for Claude Code など別レイヤの話題

---

5. 料金・ガバナンス・テレメトリの境界

料金の境界

sbx CLI 本体は商用利用を含めて無料と公式 FAQ に明記されています。per-seat 課金はなく、無料の Docker アカウントで利用できます。

有料になるのは organization governance 側です。対象は次のような組織統制です。

• 中央のネットワーク / FS ポリシー
• サインイン強制
• 監査ログ

個人検証や小規模チームの「まず試す」段階では、CLI 無料枠で十分なことが多いです。

---

テレメトリと login

テレメトリは CLI コマンド名・成否・所要時間・username などで、コードやプロンプトは対象外と説明されています。不要なら SBX_NO_TELEMETRY=1 でオプトアウトできます。

login 必須の理由としては、次が挙げられています。

• 個人 identity のアンカー
• チーム機能
• Docker インフラ認証

---

6. 採用前チェックリスト

読者がそのまま実行できるチェックリストです。

• ✓ OS / ハイパーバイザ前提（macOS Sonoma+ Apple silicon / Win11 Hypervisor / Ubuntu 24.04+ KVM）を満たす
• ✓ sbx を入れ、sbx login で Balanced から試す
• ✓ sbx policy ls で allow を確認し、必要な registry / API だけに絞る
• ✓ API キーは sbx secret set またはサンドボックス内 OAuth にし、平文をエージェント環境に置かない
• ✓ 長時間・並列・破壊的変更なら --clone または named multi-sandbox を検討する
• ✓ skills / hooks を project 配下へコピーする（~/.claude は非マウント、symlink 不可）
• ✓ 成果物をホストで review する（Git hooks を含む）。diff だけで完了扱いにしない
• ✓ 終わったら sbx rm でディスクを戻す
• ✓ チーム一律の中央ポリシーが必要なら org governance の要否を判断する
• ✓ 全社一斉ではなく、まず1リポジトリで小さく始めてから拡大する

---

関連記事:

• CodexプラグインでClaude Codeからレビュー委譲
• AI Agentjacking攻撃：Sentry MCP経由でClaude Code・Cursor・Codexが乗っ取り被害
• Keystrokeとは？Claude Code/Cursor向けn8n代替の使い方と採用判断

よくある質問（FAQ）

Q1. Docker Desktop は必要ですか？

不要です。公式 get-started は sbx CLI 単体の導入を案内しています。

---

Q2. Claude の skip-permissions は危険では？

ホスト直実行なら危険です。

sbx では microVM を safety boundary とみなし、既定で claude --dangerously-skip-permissions が使われます。

ただし次は別管理が必要です。

• workspace 共有
• allow ドメイン

権限プロンプトを戻したい場合は、Claude 側の /permissions や kit による entrypoint 上書きが公式 FAQ で触れられています。

---

Q3. 商用利用は有料ですか？

CLI は商用含め無料です。組織の中央ポリシー・監査などの governance が有料領域です。

---

Q4. ホストの skills が効きません

~/.claude は取り込まれません。skills はプロジェクトへコピーしてください（symlink 不可）。

---

Q5. サンドボックス内サービスの URL にブラウザから届きません

in-sandbox のコンテナはホストから直接見えないことがあります。公式・独立 hands-on では sbx ports で publish する流れが示されています。

---

まとめ — いつ sbx を選ぶか

Docker Sandboxes は、「無人・長時間・Docker を使う AI コーディングエージェントを、ホスト汚染を抑えながらローカルで回す」ための公式 isolation パスです。microVM と in-VM Docker が主価値で、YOLO / skip-permissions をインフラ境界付きで使う箱として位置づけられます。

一方で、workspace の共有方法、ネットワークポリシー、credential 注入、Git hooks レビューを省略すると、microVM があっても実務リスクは残ります。完全無共有が必要なら clone かリモートへ寄せ、対話中の軽い封じ込めだけならエージェント内蔵 sandbox と比較してください。

次の一手: 今日1プロジェクトで sbx run claude を試し、sbx policy ls を点検し、終わったら sbx rm する——この採用チェックリストを一度通すのが最短です。

関連する新しい記事:

• Claudeエージェントの敵対的検証入門｜レビューとの違いとチェックリスト – This published update adds current operational context for Docker Sandboxes（sbx）入門｜Claude Code を microVM で安全に無人実行.
• Agent Teamsの役割設計｜FableとGPT-5.6の使い分け【2026】 – This published update adds current operational context for Docker Sandboxes（sbx）入門｜Claude Code を microVM で安全に無人実行.