Claude Code の sandbox 完全ガイド｜claude sandbox と Docker Sandboxes の違い・使い分け

Claude Code を日常的に使い込み始めると、多くの開発者がぶつかるのが「承認疲れ（Approval Fatigue）」です。リファクタリングの一括適用やテストの追加、ビルドの自動化など、少し長めのタスクを任せるたびに「Yes」を押し続ける必要があり、集中力も生産性も削がれていきます。

かといって --dangerously-skip-permissions を使うのは怖い、というのが正直なところではないでしょうか。誤操作で ~/.ssh が書き換えられたり、意図しない外部ホストに通信が飛んだりするリスクを考えると、迂闊に自動実行モードに倒すわけにはいきません。

この「安全に、かつ自動で動かしたい」という要求に応えるために存在するのが、Claude Code の sandbox 機能です。そして最近では Docker 社が提供する Docker Sandboxes（microVM ベース）も登場し、「どちらを、どのような場面で使えばよいのか」という選択の問題が新たに発生しています。

本記事では、Claude Code に組み込まれたネイティブ sandbox（macOS の Seatbelt / Linux・WSL2 の bubblewrap）と、Docker Sandboxes（microVM）を横並びで比較し、「1 人開発 / チーム開発 / 長時間自律実行」の 3 パターンに分けて使い分けの判断軸を提示します。

加えて、競合記事では散発的にしか触れられていない settings.json の実践テンプレート（最小設定・プロジェクト別・チーム管理の 3 パターン）と、実運用でハマりやすい docker / watchman / WSL2 周りの対処法も 1 ヶ所にまとめました。

この記事を読み終えるころには、ご自身の開発環境とチーム体制に合わせて sandbox の構成を選び、コピペ可能な settings.json を手元に置いて今日から運用を開始できる状態になっているはずです。

なぜ Claude Code に sandbox が必要なのか

Claude Code のデフォルト動作は「Bash コマンドを実行するたびにユーザーに承認を求める」というものです。これはセキュリティ上は理にかなった設計ですが、実際に使い続けると以下のような痛みを生みます。

• 承認疲れ（Approval Fatigue）: 承認ボタンを押し続けるうち、内容を精査せずに「Yes」を押す習慣がついてしまう。これでは本来ゲートしたかった危険操作も素通りしかねません。
• 生産性の低下: リファクタリングやテスト追加など 30 分以上かかるタスクを自律実行させたいのに、途中で何度も手が止まります。
• 自律性の制限: バックグラウンドで CI や長時間ビルドを走らせる使い方が事実上できません。

これを解決するために用意された逃げ道が --dangerously-skip-permissions ですが、フラグ名が示すとおり「文字通り危険」です。Claude Code 公式ドキュメントも、プロンプトインジェクションや悪意のある依存関係によってシステム全体が侵害されるリスクを明示的に警告しています（Claude Code 公式: サンドボックス）。

sandbox はこの「承認の細かさ」と「スキップの危険性」のギャップを埋めるための仕組みです。OS レベルでファイルシステムとネットワークの境界を先に定義しておき、その境界内の操作だけを自動承認する、という発想で「安全 × 自動化」を同時に成立させます。

本記事で比較対象とするのは、次の 2 系統です。

1. Claude Code ネイティブ sandbox: Claude Code に組み込まれた OS ネイティブのサンドボックス機能。macOS では Seatbelt、Linux / WSL2 では bubblewrap を使用します。追加費用なしで利用できます。
2. Docker Sandboxes: Docker 社が 2026 年 1 月に macOS / Windows 向けに正式リリースした microVM ベースのサンドボックス。Claude Code 以外のコーディングエージェント（Gemini CLI、Copilot CLI 等）にも対応します。

以降のセクションでは、まずネイティブ sandbox の仕組みと設定方法を押さえ、Docker Sandboxes との比較に進みます。

claude sandbox（ネイティブ）の仕組み

Claude Code のネイティブ sandbox は、OS が提供するセキュリティプリミティブを使って「ファイルシステム分離」と「ネットワーク分離」を同時に実施します。どちらか片方だけでは意味がない、というのが公式ドキュメントでも強調されている重要なポイントです。ネットワーク分離がなければ、侵害されたエージェントが SSH キーを外部に流出させる可能性があり、逆にファイルシステム分離がなければ、バックドアを仕込まれてあとからネットワーク経由で侵入される可能性があります。

この 2 系統の分離は OS レベルで強制されるため、Claude のファイル編集ツールだけではなく、kubectl、terraform、npm などサブプロセスで呼ばれるすべてのコマンドに適用されます。

ファイルシステム分離（Seatbelt / bubblewrap）

ファイルシステム分離のデフォルト動作は以下のとおりです。

• 書き込み: 現在の作業ディレクトリ（cwd）とそのサブディレクトリのみ許可
• 読み取り: コンピュータ全体が許可（ただし denyRead で指定したディレクトリは除外）

実装は OS ごとに異なります。

プラットフォーム	実装
macOS	Seatbelt（macOS 組み込みのサンドボックスフレームワーク）
Linux	bubblewrap
WSL2	bubblewrap（Linux と同じ）
WSL1	非対応（bubblewrap が WSL2 でのみ利用可能なカーネル機能を要求するため）

デフォルト挙動をカスタマイズしたい場合は、sandbox.filesystem 配下の 4 つのキーで設定します。

• allowWrite: 書き込みを許可する追加パス（例: ~/.kube、/tmp/build）
• denyWrite: 書き込みを拒否するパス
• denyRead: 読み取りを拒否するパス
• allowRead: denyRead 領域内で読み取りを再許可するパス（denyRead より優先される）

これらの配列は複数の設定スコープで定義された場合、置き換えではなくマージされます。管理設定で /opt/company-tools への書き込みを許可し、個人の設定で ~/.kube を追加すれば、両方とも有効になります。

ネットワーク分離（プロキシ方式）

ネットワークアクセスは、sandbox の外で動くプロキシサーバー経由でフィルタされます。許可されていないドメインへの通信は、ユーザーに許可プロンプトを出すか、allowManagedDomainsOnly が有効なら即座にブロックされます。

ここで重要なのは、この制限が「サブプロセスで呼ばれた npm や pip など、あらゆる子プロセス」にも適用される点です。悪意のある npm パッケージが外部にデータを送ろうとしても、プロキシ層で止まります。

一方で、ネットワーク分離の限界も明確に認識しておく必要があります。フィルタリングはドメイン単位で、プロキシを通過するトラフィックの中身までは検査しません。github.com のような広いドメインを許可した場合、そのドメイン内にアップロード可能な任意のエンドポイント（Gist など）を経由したデータ流出は防げません。公式ドキュメントも、広いドメイン許可とドメインフロンティングのリスクに明示的に言及しています。

自動許可モードと通常許可モード

Claude Code の sandbox には 2 つのモードがあります。後述の /sandbox コマンドで選択します。

モード	挙動
自動許可モード	sandbox 内で実行可能な Bash コマンドは許可プロンプトなしで自動承認。サンドボックス外が必要なコマンド（未許可ホストへの通信など）は通常の許可フローにフォールバック
通常許可モード	sandbox 内であっても全 Bash コマンドを標準の許可フローにかける。より厳格だが承認回数は多い

両モードの違いは「自動承認するかどうか」だけで、分離の強さそのものは同じです。自律実行度を上げたいなら自動許可、慎重に手動確認したいなら通常許可、と整理できます。

claude code sandbox の設定方法

ここからは、実際に claude sandbox を有効化し、settings.json を書いていく手順を説明します。macOS は追加インストール不要ですぐに動きますが、Linux / WSL2 は bubblewrap と socat のインストールが先に必要です。

有効化（/sandbox コマンドと 2 つのモード選択）

Claude Code を起動した状態で以下を実行します。

サンドボックスモードを選択するメニューが開きます。自動許可モードか通常許可モードを選べば有効化は完了です。依存パッケージ（Linux の bubblewrap / socat 等）が不足している場合、メニュー側がプラットフォーム別のインストール手順を表示します。

macOS は追加インストールなしでそのまま有効化できますが、Linux / WSL2 では先に bubblewrap を入れておくのが安全です。次項で対応します。

プラットフォーム別の前提セットアップ

macOS は Seatbelt が OS に組み込まれているため、追加操作は不要です。

Linux / WSL2 は次のコマンドで bubblewrap と socat をインストールします。

Ubuntu / Debian

Fedora

WSL2 の場合も、上記の Linux 向け手順と同じものを WSL2 ディストリビューション内で実行します。ただし WSL1 は非対応です。bubblewrap が WSL2 限定のカーネル機能に依存しているためで、WSL1 を使っている場合は WSL2 にアップグレードしてから再実行してください。

/sandbox コマンド実行時に「起動できない」旨のメッセージが出た場合、デフォルトでは Claude Code は警告を出すだけで、サンドボックスなしでコマンド実行を続けます。ここを厳格にしたい場合は、後述する sandbox.failIfUnavailable: true を設定します。

settings.json の設定サンプル（3 パターン）

Claude Code は settings.json で sandbox 挙動を細かく制御できます。読者の環境に合わせて、ここでは 3 パターンのテンプレートを用意しました。そのままコピーして出発点に使えます。

パターン A: 最小設定（動作確認用）

まずは sandbox を「とりあえず有効化」して挙動を見たい、というケース向けの最小構成です。

これだけで、cwd への書き込み・全域読み取り・デフォルトのネットワーク制御が適用されます。ここから必要に応じて allowWrite や allowedDomains を足していくのが推奨の進め方です。

パターン B: プロジェクト別設定（実務で使うベースライン）

プロジェクト直下の .claude/settings.json に置く想定の、実務レベルの設定例です。kubectl や npm が ~/.kube や /tmp/build に書き込めるようにし、ビルドで必要な外部ドメインを許可し、docker コマンドは sandbox 外に逃がします。

ポイントは次の 3 点です。

1. allowWrite に ./dist のようなプロジェクト相対パスを入れる場合は ./ プレフィックスを使う（.claude/settings.json 内の場合はプロジェクトルート起点で解決されます）
2. denyRead で ~/.ssh や ~/.aws など機密ディレクトリを明示的にブロックしておく
3. docker は sandbox 内で動かないため、excludedCommands で外出しする（詳細は H2-6 で後述）

パターン C: チーム管理設定（Managed settings で厳格化）

組織の管理設定（Managed settings）として配布する、チーム共通のガードレール設定例です。個々の開発者が勝手にバイパスできないよう、失敗時フェイルクローズと管理ドメインのみ許可を強制します。

このテンプレートの意図は以下のとおりです。

• failIfUnavailable: true: サンドボックスが起動できなかった場合、警告だけで継続せず明確に失敗させる
• allowUnsandboxedCommands: false: Claude Code が自動で dangerouslyDisableSandbox を使うエスケープハッチを完全に無効化する
• allowManagedDomainsOnly: true: ユーザー側で追加したドメインを無視し、管理設定のホワイトリストだけを有効にする

「内部開発基盤としてサンドボックスが必須、逸脱は許容しない」という要件に近いチームで使う想定の構成です。

設定スコープとマージ挙動

settings.json は 4 つのスコープに分かれており、優先順位があります。

優先度	スコープ	配置場所
最高	Managed	OS 組織管理領域（管理者が配布）
高	Project	プロジェクトルートの .claude/settings.json
中	Local	プロジェクトの .claude/settings.local.json
低	User	~/.claude/settings.json

重要なのは、allowWrite / denyWrite / allowRead / denyRead / allowedDomains などの 配列は上書きではなくマージされる点です。これにより、管理設定が共通のガードレールを敷き、ユーザーやプロジェクトがその上にプロジェクト固有の追加許可を重ねる、という使い方が自然にできます。

ただし管理設定で allowManagedReadPathsOnly や allowManagedDomainsOnly を有効にした場合、上位スコープの許可エントリのみが尊重され、ユーザー・プロジェクトの追加分は無視されます。組織で厳格運用する場合はこの 2 つを覚えておくと便利です。

Docker Sandboxes（microVM）とは

ここまでで claude sandbox（OS ネイティブ）の仕組みを押さえました。対照となる Docker Sandboxes は、同じ「コーディングエージェントを安全に動かす」問題を、別のアプローチで解決するプロダクトです。

2026 年 1 月に Docker 社が macOS / Windows 向けに正式リリースしたもので、Claude Code だけでなく Gemini CLI、Codex CLI、Copilot CLI などの主要コーディングエージェントに対応します（Docker 公式ブログ）。

microVM による 4 層隔離

Docker Sandboxes の特徴は、コンテナよりも強固な microVM（軽量仮想マシン） を使って以下の 4 層で隔離する点にあります。

層	隔離内容
ハイパーバイザ層	エージェントごとに専用 microVM を起動。ハイパーバイザレベルのハードなセキュリティ境界を確保
マウント / ファイルシステム層	プロジェクトワークスペースだけを microVM にマウント。ホスト OS への直接アクセスはできない
ネットワーク層	ホワイトリスト / ブラックリスト方式でネットワークアクセスを制御
Docker デーモン層	microVM 内で Docker-in-Docker を実行可能。ホストの Docker デーモンには到達できない

claude sandbox との「分離の強さ」の違い

コーディングエージェントのサンドボックス技術は、分離の強さで 3 段階に整理できます。

レベル	技術	代表例
Lv1: OS ネイティブ分離	Seatbelt / bubblewrap	Claude Code ネイティブ sandbox
Lv2: コンテナ分離	Linux namespaces / cgroups	一般的な DevContainer
Lv3: microVM 分離	ハイパーバイザ（軽量 VM）	Docker Sandboxes

Lv1（ネイティブ sandbox） は追加の仮想化レイヤーを使わないため、起動が速く導入コストが低いのがメリットですが、カーネルはホストと共有します。

Lv3（Docker Sandboxes） はハイパーバイザによってカーネルごと分離するため、理論上の隔離強度は最も高く、microVM 内で Docker を動かすような重い処理にも耐えられます。一方で起動オーバーヘッドと Docker Desktop 導入の前提があります。

詳しいセットアップは既存記事へ

Docker Sandboxes の具体的な導入手順（Docker Desktop の準備、microVM の起動、Claude Code からの接続）は、本サイトの既存記事で詳しく解説しています。本記事は「選び方の上位概念」に徹するため、セットアップの詳細はこちらを参照してください。

内部リンク: Claude Code × Docker Sandbox 入門

claude sandbox vs Docker Sandboxes の比較・使い分け

ここからが本記事の主役セクションです。両者を 8 軸で横並び比較したうえで、ユースケース別の推奨を表と意思決定フローで提示します。

比較表

比較軸	claude sandbox（ネイティブ）	Docker Sandboxes（microVM）
隔離強度	OS ネイティブ（カーネル共有）	microVM（カーネル分離）
対応プラットフォーム	macOS / Linux / WSL2（WSL1 非対応）	macOS / Windows（Linux は今後対応予定）
導入コスト	Claude Code に組み込み。Linux は bubblewrap インストールのみ	Docker Desktop + Sandboxes セットアップが必要
起動オーバーヘッド	極小（プロセス起動と同等）	microVM 起動分のオーバーヘッドあり（秒単位）
docker コマンド対応	sandbox 内では非対応（excludedCommands で外出し）	microVM 内で Docker-in-Docker 実行可能
長時間自律実行の適性	○（OS レベル保護で妥当）	◎（カーネル分離で最も安心）
料金	追加費用なし（Claude Code に組み込み）	Docker 社提供の別製品。料金は Docker 公式ページ を参照
セットアップ難易度	低〜中	中

用途別の推奨マトリクス

3〜4 パターンの典型的な利用シーンで、どちらを選ぶべきかを整理します。

利用シーン	推奨	理由
1 人開発 / 短時間タスク（リファクタ・テスト追加）	claude sandbox（自動許可モード）	セットアップが軽く、起動も速い。cwd 書き込み + 主要ドメイン許可で十分
チーム開発 / 統一ガバナンス	claude sandbox + Managed settings	Managed settings で failIfUnavailable と allowManagedDomainsOnly を効かせ、開発者ごとの逸脱を防げる
長時間自律実行 / docker ビルドを含む	Docker Sandboxes	docker build や docker compose up を sandbox 内で動かせるのは microVM ならでは。失敗しても microVM を捨てて作り直せる
Windows ネイティブ環境	Docker Sandboxes	claude sandbox は Windows ネイティブ非対応。WSL2 を使えば claude sandbox も可だが、Docker Sandboxes のほうが選択肢が広い

選び方フロー

上の表を意思決定の流れに落とすと、以下のような 3 分岐フローになります。

1. タスクで docker build や Docker-in-Docker が必要か？
   • Yes → Docker Sandboxes
   • No → 次へ
2. チームで統一ガバナンスが必要か？（Managed settings で縛りたいか）
   • Yes → claude sandbox + Managed settings
   • No → 次へ
3. 1 タスクで 30 分以上エージェントに任せる想定があるか？
   • Yes → Docker Sandboxes（カーネル分離の安心感が効いてくる）
   • No → claude sandbox（自動許可モード）

「まず claude sandbox で始め、docker や長時間自律実行が本格化したら Docker Sandboxes を検討する」という段階的な導入が、多くのチームにとって現実的な進め方になります。

よくあるハマりどころと対処法

最後に、sandbox を有効化した直後にぶつかりやすい具体的な問題と、その対処法を一覧化します。事前に把握しておくことで、本番運用への移行をスムーズにできます。

docker コマンドが sandbox 内で動かない

sandbox を有効化した途端、docker ps や docker build がエラーになることがあります。これは仕様で、公式ドキュメントにも明記されています。対処法は excludedCommands に docker を指定し、sandbox 外で実行させることです。

なお、allowUnixSockets で /var/run/docker.sock を開く裏技もありますが、セキュリティ上は強く推奨されません。公式ドキュメントも「docker ソケットを悪用してホストシステムへのアクセスを効果的に付与する」としてリスクを警告しています。本格的に docker を回したいなら、後述する Docker Sandboxes 側に移るのが筋です。

docker を sandbox 内で動かしたいのであれば、Docker Sandboxes のセットアップガイドを参照してください: Claude Code × Docker Sandbox 入門

watchman が非対応

jest を普通に実行すると、内部で watchman が立ち上がりますが、watchman は sandbox 内での実行と互換性がありません。ハマりやすいポイントです。

対処は単純で、--no-watchman オプションを付けます。

恒久対応として package.json の test スクリプトに --no-watchman を組み込んでおくとよいでしょう。

WSL2 での bubblewrap 導入（WSL1 非対応に注意）

Windows 開発者が WSL 経由で Claude Code を使うケースでよく起きるのが、「sandbox が有効化できない」というエラーです。原因の多くは次の 2 つです。

1. bubblewrap / socat が未インストール
2. 使っているディストリビューションが WSL1 で動いている

インストールは Linux と同じコマンドで済みます。

WSL1 か WSL2 かは、PowerShell で次のコマンドで確認できます。

VERSION 列が 1 になっているディストリビューションは、以下のコマンドで WSL2 に変換します。

WSL1 でこのまま使い続ける限り bubblewrap は動作せず、/sandbox も有効化できない点に注意してください。

ネイティブサンドボックス起動失敗時のフォールバック挙動

/sandbox を有効化しても、何らかの理由で sandbox が起動できないことがあります（依存パッケージ不足、サポート外プラットフォーム等）。デフォルトでは警告を表示するだけで、sandbox なしで実行を継続します。これは利便性重視の挙動ですが、厳格に運用したい場合は明確に失敗させたほうが安全です。

CI 環境や Managed settings で配布する構成では、failIfUnavailable: true を明示的に設定しておくことを推奨します。これで「sandbox が動かないのに気づかず自動実行している」という事故を防げます。

dangerouslyDisableSandbox エスケープハッチの扱い

Claude Code には、sandbox 内で動かないコマンドに遭遇したときに、Claude が判断して sandbox 外で再試行するためのエスケープハッチ dangerouslyDisableSandbox が用意されています。このエスケープハッチを使うコマンドはユーザー許可フローにかかる仕様ですが、「常にサンドボックス内でのみ動かしたい」という要件の場合は無効化できます。

allowUnsandboxedCommands: false を設定すると、dangerouslyDisableSandbox パラメータは完全に無視され、すべてのコマンドは sandbox 化されるか excludedCommands に明示的にリストされている必要があります。チーム共通のガードレールとして Managed settings に入れておくのが推奨の使い方です。

まとめ（推奨設定パターン）

本記事では、Claude Code のネイティブ sandbox（Seatbelt / bubblewrap）と Docker Sandboxes（microVM）を比較し、ユースケース別の使い分けを整理しました。最後に、今日から始められる「最初の 3 ステップ」を構成別に提示します。

1 人開発 / 短時間タスク向け

1. /sandbox で自動許可モードを選択
2. プロジェクトの .claude/settings.json にパターン B（プロジェクト別設定）を配置
3. excludedCommands に docker を追加し、denyRead で ~/.ssh をブロック

チーム開発 / 統一ガバナンス向け

1. Managed settings にパターン C（チーム管理設定）を配布
2. failIfUnavailable: true と allowUnsandboxedCommands: false でバイパス経路を塞ぐ
3. allowManagedDomainsOnly: true で組織が許可したドメインのみに制限

長時間自律実行 / docker ビルド向け

1. Docker Desktop をインストールし、Docker Sandboxes を有効化
2. Claude Code から Docker Sandboxes に接続し、microVM 上で作業
3. 具体的な手順は Claude Code × Docker Sandbox 入門 を参照

「まずは claude sandbox から始め、docker や長時間自律実行が本格化したら Docker Sandboxes を追加検討する」が、多くのチームにとって無理のない導入ルートです。本記事のテンプレートをベースに、ご自身の環境に合わせてカスタマイズしてみてください。