Claude Codeのサンドボックスの選び方 — 6種の隔離範囲と目的別の早見表

Claude Codeの隔離手段は6種類あります。分かれ目は1つで、隔離されるのが「Bashコマンドだけ」か「Claude Codeのプロセス全体」かです。この線を先に引くと、残りの選択はほぼ決まります。

結論から書きます。普段使いで確認の回数を減らしたいだけなら、組み込みのBash sandboxで足ります。--dangerously-skip-permissionsで無人実行するなら、プロセス全体を囲う手段（sandbox runtime・コンテナ・VM）が前提です。信頼できないリポジトリは、専用のVMかcloud sessionsに寄せます。

6種類は何を隔離するのか

Claude Code公式のSandbox environmentsページは、6つの方式を次の4観点で並べています。上の2つはコンテナなしでホストOS上で動き、下の4つはClaude Codeをコンテナか仮想マシンの中に置きます。

Bash sandboxだけが「コマンド単位」で、残りの5つは境界の内側にClaude Code本体ごと入ります。読み方は次のとおりです。

• Bash sandboxの外側にいるのは、Read・Edit・WebFetchなどの組み込みツール、ローカルのMCPサーバー、hooks、プラグインのmonitorです
• 組み込みツールはパスやドメインの権限ルールで制御されます
• MCPサーバーとhooksは、ホスト上で制限なしに動きます

目的から選ぶ早見表

方式の名前から入るより、やりたいことから逆引きするほうが速く決まります。

Bash sandbox：最も軽く、最も範囲が狭い

組み込み機能で、macOSはSeatbelt、LinuxとWSL2はbubblewrapで制限します。既定ではオフで、セッション内で/sandboxを実行するか、sandbox.enabledをtrueにして有効にします。設定キー単体の解説はsandbox.enabledにあります。

/sandbox

既定の境界は、次の表のとおりです。

つまり、何も足さない状態では認証情報ファイルは読めます。sandbox.credentialsやdenyReadで塞ぐ前提で使います。

制約も押さえておきます。

• ネイティブWindowsでは非対応で、コマンドは隔離なしで動きます
• 組み込みのファイルツール、MCPサーバー、hooksは範囲外です
• 自分で!プロンプトに打ったコマンドは、多くのセッションで隔離されません
• 無人実行には、単体では足りないと明記されています

最後の点が選び方の肝です。Bash sandboxは「確認を減らす」には向きますが、「確認なしで任せる」境界としては不足します。ただし層は重ねられます。コンテナやVMの内側でBash sandboxを動かせば、外側の境界に加えてコマンド単位の制限が効きます。

sandbox runtime：Dockerなしでプロセス全体を囲う

@anthropic-ai/sandbox-runtimeパッケージは、Bash sandboxと同じSeatbeltかbubblewrapで、プロセス全体を包みます。ファイルツール、MCPサーバー、hooksまで同じ境界に入ります。ベータの研究プレビューで、設定形式は変わる可能性があります。起動はこの形です。

npx @anthropic-ai/sandbox-runtime claude

起動前に設定ファイル（~/.srt-settings.json、または--settingsで渡すファイル）を用意します。既定ではネットワークが拒否され、書き込みもごく限られたパスに限定されるためです。書き込みを許すのは最低限、プロジェクトのディレクトリ、~/.claudeと~/.claude.json、Claude Codeの一時ディレクトリ（Linux・WSL2は/tmp、macOSは/private/tmp）です。通信を許すのはapi.anthropic.comのほか、OAuth認証ならclaude.aiとplatform.claude.comです。

LinuxとWSL2では、書き込み許可は既に存在するパスにしか適用されません。新しい環境では先に作っておきます。

mkdir -p ~/.claude && { [ -f ~/.claude.json ] || echo '{}' > ~/.claude.json; }

落とし穴は2つあります。設定ファイルがなくても起動はするので、「起動できた」は設定が読まれた証拠になりません。一方、ファイルが空・読めない・不正なときは起動を拒否します。詳しい設定と遮断範囲はsandbox-runtimeの設定解説にまとめています。

dev containerとcustom container：環境ごと閉じる

dev containerは、Dockerコンテナの中でClaude Codeを動かし、プロジェクトをマウントする方式です。Claude Codeのリポジトリには、既定で外向き通信を拒否するiptablesファイアウォール付きの参照構成があります。これをコピーして、許可リスト・ベースイメージ・固定するClaude Codeのバージョンを調整するのが出発点です。ファイアウォールがあるため、--dangerously-skip-permissionsでの無人運用を支える構成になります。構築の詳細はDevContainer完全実装、通信制限はinit-firewall.shで扱っています。

ただし、dev containerにも限界があります。フラグ付きで実行すると、悪意あるプロジェクトによるコンテナ内の持ち出しは防げません。~/.claudeの認証情報もコンテナ内にあるためです。信頼できるリポジトリに限り、~/.sshなどのホストの秘密情報はマウントしないでください。

custom containerは、任意のDocker・OCIイメージに自前のネットワークポリシー、ボリューム、seccompプロファイルを組み合わせる形です。既存のコンテナ基盤やCI実行環境を持つ組織で最も多い経路とされています。確認項目は3つです。

• 書き込み可能でマウントしているもの
• コンテナ内から届く認証情報とトークン
• ネットワークの外向き通信ポリシー

特権なしのコンテナでBash sandboxを重ねる場合はenableWeakerNestedSandboxが必要になります。この設定は隔離を大きく弱めるので、外側のコンテナが十分な境界を持つときだけ使います。経緯はenableWeakerNestedSandboxとbwrapPathにあります。

VMとcloud sessions：OS単位で分ける

VMは専用のカーネルを持つため、最も強い分離になります。クラウドのインスタンス、ローカルのハイパーバイザー、FirecrackerのようなマイクロVMが選択肢です。信頼できないコードを評価するとき、セキュリティ方針でカーネルレベルの分離が求められるとき、ホスト側の方式ではコンプライアンスを満たせないときに向きます。Docker Sandboxesは独自のDockerデーモンとワークスペース同期を持つマイクロVMで、Docker Desktopなしの無償の単体製品です。

cloud sessionsはAnthropicが管理する隔離VMで動きます。ネットワークプロキシが既定の許可リストを強制し、別のプロキシがGitHubトークンをサンドボックスの外に保持して、内側にはリポジトリ用の限定的な認証情報を発行します。インフラの用意が要らず、手元に開発環境のない端末からタスクを渡せる点が利点です。

条件も確認します。

• Pro・Max・Team、およびプレミアムシートかChat + Claude Codeシートを持つEnterpriseで使えます
• 利用量は他のClaude利用と同じプラン上限に数えられ、クラウドVMの追加課金はありません
• CLIからclaude --cloudで起動する場合は、ローカルのリポジトリをバンドルしてアップロードできるため、GitHub連携が必須ではありません
• 起動しない場合の切り分けはCloud sessions拒否の記事にあります
• Bedrockなどのサードパーティプロバイダー設定では--cloudは使えません
• 組織でIPアドレス許可リストを有効にしていると、Anthropic管理のcloud sessionsは認証エラーになります

組織で強制できるのはどの方式か

個人はどの方式も選べますが、組織が強制できる範囲は方式で違います。

Bash sandboxを必須にする管理設定は、たとえば次の形です。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

failIfUnavailableは、bubblewrapなどが欠けたときにフォールバックせず起動を止めます。allowUnsandboxedCommands: falseは、隔離下で失敗したコマンドを隔離なしで再試行する抜け道を閉じます。個別の解説はfailIfUnavailableとallowUnsandboxedCommandsにあります。

ネイティブWindows端末を含む組織では注意が要ります。サンドボックスが動かないため、failIfUnavailableを付けるとそのマシンではClaude Codeが起動時に終了します。MDMでOS別に配布するか、WSL2やコンテナへ移す必要があります。サーバー管理設定は組織の全ユーザーに適用されるので、前者の分け方はできません。

よくある組み合わせ

方式は排他ではありません。ありがちな組み合わせは3つです。

他社エージェントとの実装差はサンドボックス実装比較で扱っています。

選ぶときの判断

最初に決めるのは、フラグを使うか、リポジトリを信頼できるかの2点です。auto modeは分類器がアクションを審査する仕組みで、隔離境界ではありません。ただし無人実行の防御を一段厚くする意味で、境界を足す価値は残ります。--dangerously-skip-permissionsではその境界が必須になります。

LinuxとmacOSでは、このフラグはroot実行だと起動を拒否します。コンテナもVMもsandbox runtimeも、非rootのユーザーで動かす構成にしてください。