Claude Code sandboxサンドボックスモードの安全な使い方と設定完全ガイド

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 入門：はじめ方 を先に確認しておくと、以下の設定作業をスムーズに進められる。

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

/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 スラッシュコマンド完全ガイド を参照されたい。

allow/deny ルールの設定方法と実装上の注意点

パーミッションルールには「ベア名（ツール名のみ）」と「スコープ付きルール（パターン指定）」の2種類がある。この違いを誤解すると意図しない挙動を招くため、正確に把握しておく必要がある。

Bash のようなベア名 Deny ルールはツールそのものを Claude のコンテキストから除去する。その結果、Claude はそのツールの存在を認識しないため、呼び出しを試みることすらない。一方 Bash(rm *) のようなスコープ付きルールは、ツールは利用可能なまま保ちつつ、パターンに一致する呼び出しのみをブロックする仕組みだ。

実装上の注意点を以下に整理する。

• ルール評価の優先順位は deny → ask → allow。最初に一致したルールが適用され、deny ルールが allow ルールより常に優先される。
• ベア名 deny ルールはパーミッション評価前にコンテキストから除去される。Bash を deny に設定した場合、評価フローの deny チェック段階に到達する前にツール自体が消える。スコープ付きルールのみが通常の評価フローで処理される。
• bypassPermissions モードでも Deny ルールは必ず適用される。これがサンドボックスの安全性を担保する最終防衛線だ。
• パーミッションルールはモデルへの指示では変更できない。プロンプトインジェクション対策として、CLAUDE.md やシステムプロンプトからパーミッション設定を操作することはできない。
• Hooks が allow を返しても deny/allow ルールはスキップされない。Hooks は前処理であり、後続ルールを上書きしない。

設定ファイルは /permissions コマンドで GUI から管理できるほか、settings.json を直接編集してバージョン管理に含めることもできる。チーム開発では後者が推奨される。エージェント SDK 向けの設定（Configure permissions — Agent SDK）では、disallowed_tools と canUseTool コールバックによるより細粒度な制御が可能だ。自動化パイプラインでプログラマティックに承認フローを実装する場合は Agent SDK のドキュメントを合わせて参照してほしい。

セキュリティ設計のベストプラクティスとサンドボックスの限界

Claude Code のサンドボックスを安全に運用するには、パーミッション設定だけでなく、実行環境そのものの分離を組み合わせる多層防御の考え方が必要だ。以下にベストプラクティスと既知の限界を整理する。

最小権限原則の徹底と段階的な allow ルール追加

開発初期は default モードから始め、実際の作業パターンを観察してから allow ルールを段階的に追加するアプローチが堅実だ。最初から bypassPermissions を設定し後から制限を絞ろうとすると、どのコマンドを許可しているかの全体像を把握しにくくなる。

CI/CD 環境での推奨設定パターンを以下に示す。

# .claude/settings.json（リポジトリルートに配置しバージョン管理）
{
  "defaultMode": "dontAsk",
  "allowedTools": [
    "Read",
    "Grep",
    "Bash(npm test)",
    "Bash(npm run build)",
    "Bash(npm run lint)"
  ],
  "disallowedTools": [
    "Bash(rm *)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(ssh *)",
    "Bash(sudo *)",
    "Bash(su *)"
  ]
}

この設定では、テスト・ビルド・リントのみを自動承認し、ファイル削除・外部通信・権限昇格はすべてブロックする。/permissions コマンドで定期的にルール一覧を棚卸しし、不要になった allow ルールを削除することも重要だ。

コンテナ・OS レベルの隔離との併用

Claude Code のパーミッションシステムはソフトウェアレベルの制御であり、悪意あるプロンプトインジェクションや予期しないツール呼び出しに対して完全な保護を保証するものではない。本番データや機密認証情報が存在する環境では、Docker コンテナや macOS Sandbox（Seatbelt）などの OS レベル分離と組み合わせることで、より堅固な境界を実現できる。

IPA「AI白書 2024（発行にあたって）」（IPA.go.jp）においても、AI システムのリスク管理として技術的制御と組織的制御を組み合わせることの重要性が示されており、ツール単体のパーミッション設定に依存しきらない設計方針はエンタープライズ導入において特に重要だ。

データ利用ポリシーとプライバシーの考慮

Team・Enterprise プランおよび API 利用（商用利用）の場合、Anthropic はコードやプロンプトをモデル改善のために使用しない。一方、Free・Pro・Max プランの個人ユーザーは設定によってデータがモデル学習に使用される可能性がある。機密コードや個人情報を含むコードベースを扱う場合は、商用プランの使用が前提となる。Claude Code の料金体系については Claude Code 料金・プラン比較 および Claude Code API 料金解説 を参照されたい。

サンドボックス機能の既知の限界

サンドボックスを過信しないために、以下の限界を運用前に把握しておくことが不可欠だ。

• パターンマッチングの網羅性に限界がある：Bash(rm *) を deny に設定しても、find . -delete や truncate -s 0 といった別の手段によるファイル削除はブロックされない。すべての危険なコマンドパターンを deny ルールで列挙することは現実的でなく、OS レベルの環境分離との組み合わせが実用上の前提となる。
• ルール設定の複雑性が増大しやすい：allow/deny ルールが増えるほど、どのルールが実際に適用されているかの把握が難しくなる。/permissions コマンドで定期的に棚卸しを行うことを推奨する。
• CLI と Agent SDK で設定インターフェースが異なる：Claude Code CLI は settings.json と /permissions コマンドが中心で、Agent SDK は disallowed_tools フィールドと canUseTool コールバックが主な制御手段だ。両者を混在させる構成では、どちらの設定が実際に有効かを設計段階で明確にしておく必要がある。
• deny ルール適用のタイミングがルール種別で異なる：ベア名 deny ルール（例: Bash）はコンテキスト除去のため評価フロー開始前に処理される一方、スコープ付き deny ルール（例: Bash(rm *)）は評価フロー内の Deny Rules ステップで処理される。この非対称性を理解せずに設定すると、意図と異なるブロック動作が生じる可能性がある。

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

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

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

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

   AIブログ購読

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

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