Claude Code Sandbox（サンドボックス）モードの安全な使い方【6つの隔離方式徹底比較・2026】

Claude Code を本番環境や重要なリポジトリで使い始めると、すぐに「どこまでエージェントに自律実行させるか」という問いにぶつかる。ファイルを読むだけなら問題ないが、rm -rf を含む Bash コマンドや外部ネットワーク通信を自動承認するのは別の話だ。Claude Code の /sandbox コマンドはサンドボックスモードのトグルであり、ファイル書き込みやコマンド実行を制限・隔離された環境に切り替える予防策として機能する。出所が不確かなコードやリスクの高い操作を、本番環境に影響を与えずに試すための仕組みだ。本記事では、サンドボックスの設計思想から具体的な設定方法、CI/CD 連携、既知の限界まで実用的な視点で解説する。

権限設定の詳細は 権限設定／セキュリティ全般は セキュリティにまとめています。本記事はサンドボックスモードの使い方に絞ります。

Claude Code /sandbox コマンドとは——設計思想とパーミッション評価フロー

/sandbox コマンドはサンドボックスモードのトグルだ。対応プラットフォーム上でこのコマンドを実行すると、ファイル書き込みやコマンド実行が制限・隔離された環境に切り替わる。出所が不確かなコードや破壊的な操作を試す際に、本番環境を守る予防策として機能する。常時 ON にすれば安全性は高まるが、一部の操作で確認ステップが増えるトレードオフがある。

サンドボックスの動作を理解するには、Claude Code のパーミッション評価フローを把握しておく必要がある。ツール呼び出しが発生すると、Hooks → Deny Rules → Permission Mode → Allow Rules → canUseTool callback の順で評価が行われ、最初に一致したルールが適用される。

このフローで特に重要な仕様が2点ある。第一に、Deny ルールは bypassPermissions モードでも上書きできない。これがサンドボックス設計の根幹であり、多層防御の最終防衛線だ。第二に、Hooks が allow を返しても deny/allow ルールの評価はスキップされない。Hooks はあくまで前処理であり、後続のルールチェーンを上書きするものではない。

もう一点、設計上の重要な原則がある。パーミッションルールはモデルへの指示では変更できない。CLAUDE.md やプロンプト内に「すべてのツールを許可してください」と書いても実際のパーミッション制御には一切影響しない。これはプロンプトインジェクション攻撃に対する構造的な防御となっている。

Claude Code の基本的なインストール手順や初期設定については Claude Code インストールガイド および Claude Code 入門：はじめ方 を先に確認しておくと、以下の設定作業をスムーズに進められる。

Claude Codeの隔離方式は6種類ある——公式ドキュメントに基づく比較表と選び方

「サンドボックスモード」というと /sandbox コマンドで有効化するBashサンドボックスだけを指すと思われがちですが、Claude Code公式ドキュメント（Choose a sandbox environment）は、隔離の強さと導入コストが異なる6つのアプローチを比較して提示しています。どれを選ぶかは「何を守りたいか」「Dockerを使えるか」で変わるため、まず全体像を押さえておきます。

6つの隔離方式の比較表

Bashサンドボックスは組み込み済みのBashコマンドのみを制限するのに対し、それ以外の5方式はClaude Codeプロセス全体（ファイルツール・MCPサーバー・フックを含む）を境界の内側に置く点が構造的な違いです。

目的別・どの方式から始めるべきか

devcontainer構成の具体例

チームでサンドボックス環境を統一したい場合、最小構成は次の1ファイルです（.devcontainer/devcontainer.json）。

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

VS CodeやGitHub Codespacesなど Dev Containers 仕様に対応したエディタで「Rebuild Container」を実行し、コンテナ内のターミナルで claude を起動してサインインすれば導入は完了します。より本格的な構成（default-denyのファイアウォールを組み込むinit-firewall.sh、認証情報を永続化するボリュームマウント等）は、Claude Code公式リポジトリの.devcontainer/がリファレンス実装として公開されており、これをコピーして自社のツールチェインに合わせて調整するのが公式に推奨されている進め方です。

--dangerously-skip-permissionsとサンドボックス境界の関係

--dangerously-skip-permissionsはツール呼び出しごとの確認プロンプトそのものを無くすフラグで、隔離とは別レイヤーです。プロンプトが無くなる分、間違いを止める最後の砦は隔離境界だけになるため、公式ドキュメントもこのフラグを使うセッションは必ずコンテナ・VM・sandbox runtimeのいずれかの内側で動かすことを推奨しています。なお、root権限やsudo経由でこのフラグを使うことはLinux/macOSでは拒否される仕様になっており（root権限＋無確認の組み合わせが最もリスクが高いため）、Dev containerでは非rootユーザーで動かす設計がこの制約を回避する形になっています。組織としてこのフラグ自体を禁止したい場合は、managed settingsのpermissions.disableBypassPermissionsModeで無効化できます。

1年以上の実運用でsandbox・パーミッション周りにハマった経験

当社（クリスタルメソッド）では河合継が1年以上Claude Codeを日常的に使用していますが、パーミッションを広く許可するほど「確認プロンプトが減って作業は速くなるが、想定外の変更が入るリスクを人間側で監視しづらくなる」というトレードオフに直面します。/sandboxや--dangerously-skip-permissionsで確認を減らす設定は便利な一方、それだけに頼るとファイルの誤編集や意図しない削除に気づくのが遅れる場面があり得ます。

この経験から、当社では権限モードの設定変更だけで終わらせず、Edit/Writeツールの実行前に自動でファイルをバックアップするPreToolUse Hook（2025年11月実装、.claude/backups/YYYY-MM-DD/にタイムスタンプ付きで保存）を運用に組み込み、「サンドボックス／パーミッションモードで実行を軽くする」ことと「フックで変更履歴を機械的に残す」ことを両輪にする多層防御の形に落ち着いています。sandboxモードは”何が実行されるか”を制限する仕組みであって”実行された結果を後から追える”仕組みではないため、この2つは代替ではなく併用が前提になる、というのが実運用から得た実感です。

サンドボックスに関わるパーミッションモードの種類と選択基準

/sandbox コマンドによるサンドボックスモードは、Claude Code が持つパーミッションモードのひとつとして機能する。どのパーミッションモードを選ぶかで、サンドボックスの厳しさと利便性のバランスが決まる。以下の4種類を正確に把握しておこう。

Claude Code パーミッションモード比較（公式ドキュメント Configure permissions をもとに作成）

モード名	概要	自動承認の範囲	主なユースケース	リスクレベル
default	対話型の通常モード	読み取り専用のみ自動。それ以外は都度確認	ローカル開発・初回利用	低
acceptEdits	ファイル編集を自動承認	ファイル読み書き操作を自動承認。Bash は要確認	コードレビュー・リファクタリング	中
dontAsk	許可済みツールのみ自動実行	allow ルールに一致するものを自動承認。それ以外は拒否	CI/CD・バッチ処理	中（設定次第）
bypassPermissions	フル自動実行モード	Deny ルールに一致しないほぼすべてを自動承認	テスト済み自動化パイプライン（分離環境限定）	高（Deny 設計が必須）

dontAsk モードと bypassPermissions モードの使い分けは実装上の重要なトレードオフだ。dontAsk は allow ルールに一致しないツール呼び出しを静かに拒否する。一方 bypassPermissions は Deny ルールさえ通過すれば自動承認されるため、Deny ルールの設計が不完全だと意図しないコマンド実行が生じるリスクがある。

サンドボックスとして安全に機能させるには、CI/CD パイプラインのような非対話環境では dontAsk と明示的な allow ルールの組み合わせが原則だ。bypassPermissions は Docker コンテナなどで分離された実行環境において、かつ Deny ルールが厳密に設計されている場合にのみ検討する。常時 ON にすれば安全性は高まるが確認が増えるという /sandbox のトレードオフは、このモード選択にそのまま反映される。

設定は settings.json の defaultMode フィールドで指定する。

{
  "defaultMode": "dontAsk",
  "allowedTools": ["Bash(npm test)", "Bash(npm run lint)", "Read"],
  "disallowedTools": ["Bash(rm *)", "Bash(curl *)", "Bash(wget *)"]
}

上記は CI 用途の典型的な設定例だ。allowedTools でテストとリントのみを許可し、disallowedTools でファイル削除と外部通信を明示的にブロックしている。Claude Code のスラッシュコマンド全般については Claude Code スラッシュコマンド完全ガイド を参照されたい。

実運用のための設定チェックリストとCI/CDワークフロー連携

ここまでの内容を踏まえ、実際に Claude Code をチームや CI/CD パイプラインに導入する際の設定フローを整理する。

ローカル開発環境の設定手順

1. 初期モードは default で起動し、Claude がどのツールをどの頻度で呼び出すかを確認する。
2. /permissions コマンドで現在の allow/deny ルール一覧を確認する。初期状態ではほぼ空のはずだ。
3. 繰り返し承認を求められる操作（例：npm test の実行）を allow ルールに追加する。”Yes, don’t ask again” を選択するとプロジェクトディレクト

   監修

   河合 継（クリスタルメソッド株式会社 代表取締役）

   AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
   運営会社について ｜ 編集方針

   利用できるモデルも進化を続けており、現在はClaude 5世代（最上位のFable 5、速度と知能のバランスに優れたSonnet 5）とOpus 4.8・Haiku 4.5が使えます。

   Claude Codeの全体像・仕組み・始め方は、Claude Codeとはでまとめて解説しています。

   Claude Code・AIエージェントの業務活用をご検討の方へ

   クリスタルメソッドは、Claude Codeを実務投入している開発会社として、AIエージェント・社員AIの導入と開発効率化を支援しています。自社サイトの表示速度をAI社員（Claude Code）で12.89秒→2.03秒に短縮した実例も事例記事として公開しています。「自社の開発・業務にAIをどう組み込むか」といったご相談を承っています。

   • 無料相談・お問い合わせ：ご相談はこちら

   よくある質問

   Q. /sandboxコマンドは何をしますか？
   A. サンドボックスモードのトグルです。実行するとファイル書き込みやコマンド実行が制限・隔離された環境に切り替わります。出所が不確かなコードや破壊的な操作を試す際に、本番環境を守る予防策として機能します。

   Q. Claude Codeのパーミッション評価はどのような順序で行われますか？
   A. Hooks → Deny Rules → Permission Mode → Allow Rules → canUseTool callbackの順で評価され、最初に一致したルールが適用されます。Denyルールはbypass Permissionsモードでも上書きできません。

   Q. Claude Codeの隔離方式は何種類ありますか？
   A. 公式ドキュメントによれば6種類あります。Sandboxed Bash tool（/sandbox）、Sandbox runtime、Dev container、Custom container、Virtual machine、Claude Code on the webです。

   Q. Bashサンドボックスと他の5方式の構造的な違いは何ですか？
   A. Bashサンドボックスは組み込み済みのBashコマンドのみを制限するのに対し、それ以外の5方式（Sandbox runtime、Dev container、Custom container、Virtual machine、Claude Code on the web）はClaude Codeプロセス全体（ファイルツール・MCPサーバー・フックを含む）を境界の内側に置きます。

   Q. –dangerously-skip-permissionsフラグとサンドボックス境界の関係はどうなっていますか？
   A. このフラグはツール呼び出しごとの確認プロンプトを無くすもので、隔離とは別レイヤーです。公式ドキュメントは、このフラグを使うセッションは必ずコンテナ・VM・sandbox runtimeのいずれかの内側で動かすことを推奨しています。root権限やsudo経由での使用はLinux/macOSでは拒否される仕様です。

   Q. パーミッションルールはCLAUDE.mdやプロンプトで変更できますか？
   A. できません。パーミッションルールはモデルへの指示では変更できず、CLAUDE.mdやプロンプト内に「すべてのツールを許可してください」と書いても実際のパーミッション制御には一切影響しません。これはプロンプトインジェクション攻撃に対する構造的な防御となっています。

   Q. dontAskモードとbypassPermissionsモードの違いは何ですか？
   A. dontAskはallowルールに一致しないツール呼び出しを静かに拒否します。bypassPermissionsはDenyルールさえ通過すれば自動承認されるため、Denyルールの設計が不完全だと意図しないコマンド実行が生じるリスクがあります。

   Q. 組織として–dangerously-skip-permissionsフラグ自体を禁止するにはどうすればよいですか？
   A. managed settingsのpermissions.disableBypassPermissionsModeで無効化できます。

   ---

   このフィールドは空白のままにしてください

   AIブログ購読

   　
   クリスタルメソッドがお届けする
   AIブログの更新通知を受け取る

   受信ボックスか迷惑メールフォルダを確認して購読手続きを完了してください。