Claude Codeのサンドボックスとは？ファイル・ネットワーク隔離で安全に自動化【2026】

Claude Codeを使い込むと、必ずこのジレンマにぶつかる。コマンドのたびに「実行していい？」と確認されて手が止まる。かといって全確認をオフにする --dangerously-skip-permissions（権限バイパス）は、プロンプトインジェクションや誤操作で家じゅうのファイルを触られかねない。安全と自動化はトレードオフ——長らくそう思われてきた。

この二択を崩すのが サンドボックス（sandbox＝砂場） だ。OSレベルで「触れる範囲」を先に囲っておけば、その中では確認なしで自由に走らせても、外には手が出せない。本記事は、Claude Codeのサンドボックスが何を・どう隔離するのか、/sandbox での始め方、settings.json での設定、権限モードとの違い、そして過信してはいけない限界までを実務目線で整理する。

1. なぜサンドボックスが要るのか

Claude Codeは、テストを走らせたりファイルを書き換えたりと実際に手を動かすAIエージェントだ。だからこそ、危険なコマンドの前で「実行していい？」と確認する。安全のためには正しい。だが一日に何十回も確認が挟まると、作業が細切れになり、しまいには読まずにEnterを押すようになる。これが「確認疲れ（permission fatigue）」だ。

疲れた開発者が手を伸ばしがちなのが、全確認をオフにする --dangerously-skip-permissions（別名 YOLOモード）。快適だが、名前どおり危険だ。次の3つが同時に牙をむく。

サンドボックスの発想はシンプルだ。「何を確認するか」を毎回聞くのをやめ、「どこまで触れるか」を最初に囲う。囲いはClaude自身の判断ではなくOS（カーネル）が強制するので、たとえ乗っ取られても、たとえ許可済みコマンドが名前以上のことをしても、境界の外には出られない。だから境界の内側は確認なしで走らせても安全——確認疲れと全バイパスの二択が消える。Anthropicは公式エンジニアリングブログ「Making Claude Code more secure and autonomous with sandboxing」で、社内利用において権限確認を安全に84%削減できたと報告している（2025年10月公開）。

2. サンドボックスとは何か——2つの隔離

Claude Codeのサンドボックスは、Bashコマンド（と、それが生む子プロセス全部）に対して2種類の境界をかける。この2つは必ずセットで機能させる——片方だけでは穴が残る（理由は §7）。

肝は「Claudeが行儀よくするか」に頼らない点だ。境界をOSのセキュリティ機構——macOSは標準のSeatbelt、Linux/WSL2はbubblewrap——が強制する。だから、コマンドが呼び出したスクリプトや孫プロセスにまで同じ境界が及ぶ。これはAIガードレールのような「モデルへのお願い」ではなく、機械的に効く物理的な壁だと考えるといい。

3. 始め方——/sandbox と対応OS

サンドボックスはClaude Codeに内蔵されている。追加のアカウントやツールは不要だ。セッション内で次を実行する。

/sandbox

パネルが開き、3つのタブが並ぶ。Mode（承認方式＝次章）、Overrides（サンドボックスで失敗したコマンドを外で再実行させるか）、Config（解決済みの設定を確認）。Linux/WSL2で必要パッケージが未導入なら、代わりに Dependencies タブが出て、何が足りないかを教えてくれる。

OSごとの前提

Linux/WSL2では、bubblewrap（ファイル隔離を担う非特権サンドボックス）と socat（通信をプロキシへ中継）を入れる。

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

1つ有効化しておくと便利なのが seccompフィルタ（Unixドメインソケットの遮断を追加）。任意だが、npm install -g @anthropic-ai/sandbox-runtime で導入できる。導入状況は /sandbox のDependenciesタブに ripgrep / bubblewrap / socat / seccomp として表示される。パッケージを入れたらClaude Codeを再起動してから /sandbox を開き直すこと（起動時に検出するため）。

4. 2つのモード（自動許可／通常）

Modeタブで選ぶのは、サンドボックス内のコマンドをどう承認するかだ。

どちらのモードでもファイル／ネットワークの境界は同一で、違うのは「自動で通すか、確認するか」だけだ。なお自動許可モードでも、次の安全弁は生き続ける。

• 明示的な deny（禁止）ルールは常に優先される
• /・ホームディレクトリ・重要システムパスを狙う rm / rmdir は依然として確認が入る
• Bash(git push *) のような内容指定の ask ルールは、サンドボックス内でも確認を強制する

5. settings.json で設定する

/sandbox パネルでの選択は、プロジェクトの .claude/settings.local.json に書き込まれる（gitには載らない）。全プロジェクトで常時オンにするなら、ユーザー設定 ~/.claude/settings.json に sandbox.enabled を true で置く。設定は 権限ルール（allow/ask/deny）と同じ settings.json ファミリーで管理する。

書き込み先を足す・読み取りを禁じる

初期状態で書けるのは作業ディレクトリと一時フォルダだけ。kubectl や terraform が別の場所に書く必要があるなら、allowWrite でパスを足す。逆に、機微なフォルダの読み取りを塞ぐこともできる。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

上の例は「ホーム全体の読み取りを禁止しつつ、いまのプロジェクトだけ読める」設定だ（. はプロジェクト設定に置いたときプロジェクトルートに解決される）。パスはOSレベルで強制されるので、npm や terraform などの子プロセスにも等しく効く。

認証情報を守る

重要な落とし穴：読み取りの初期値は「広く許可」なので、~/.aws/credentials や ~/.ssh/ はそのままだと読めてしまう。専用の sandbox.credentials（比較的新しい機能）でファイルの読み取り拒否や環境変数の除去を宣言できる。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

接続先を許可する

ネットワークは初期状態で接続先ゼロ。新しいドメインは繋ごうとした時点で確認が入る（記事執筆時点の新しめのバージョンでは、一度許可すればそのセッション中は再確認されない）。毎回聞かれたくない相手は allowedDomains に先に登録しておく。組織で強制配布する管理設定（managed settings）では、許可リスト以外を確認せず自動遮断する運用もできる。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    }
  }
}

6. 権限モード・権限ルールとの関係

混同しやすいが、Claude Codeの安全機構は役割の違う3層だ。サンドボックスはその1層で、他の2つを置き換えるものではなく補完する。

決定的な違いは「いつ・誰が」効くかだ。権限ルールとモードは実行前にClaude Codeがコマンド文字列を見て判断する。サンドボックスは実行中にOSがプロセスを縛る——だからモデルが何を選ぼうと、許可済みコマンドが名前以上のことをしようと、境界は揺るがない。

これが --dangerously-skip-permissions（バイパス）との決定的な差でもある。バイパスは確認を消すだけで環境は素っ裸のまま。対してサンドボックスの自動許可は、OSの壁があるから確認を省ける。バイパスモードを使うなら、必ず隔離されたコンテナやVMの中で——という従来の鉄則を、サンドボックスは日常のマシン上でも安全側に倒せるようにした、と捉えるとよい。

7. 限界と注意点——過信は禁物

サンドボックスは強力だが、完全な隔離ではない。ハードなセキュリティ境界として頼り切る前に、公式が明示する限界を押さえておく。

加えて押さえるべき点：対象はBashだけ——内蔵のRead/Edit/Write、MCPサーバー、フックは別枠だ。SkillsやMCPを含めてプロセス丸ごと隔離したいなら、公式のオープンソース @anthropic-ai/sandbox-runtime（GitHub・npmで公開、2025年10月公開のリサーチプレビュー）でClaude Codeプロセス自体を包む。攻撃者を相手取る「壁」ではなく、事故と暴走を桁違いに減らす「安全帯」——それが実務的な位置づけだ。

8. dev container・VMとの使い分け

Claude Codeの隔離手段はサンドボックスだけではない。手軽さと隔離の強さはトレードオフなので、用途で選ぶ。

実務の勘どころ：まず内蔵サンドボックスを常時オンにして日々の確認を減らし、無人で回す・信頼できない依存を扱うときだけ sandbox-runtime やコンテナ／VMへ格上げする。クラウド操作をAIに任せるような本番に手が届く作業では、最小権限の資格情報と併せて隔離を一段強くしておくと安心だ。

まとめ

安全と自動化はトレードオフ、という前提そのものを崩すのがサンドボックスだ。まず /sandbox を一度開いてみる——それだけで、Claude Codeの手綱の握り方が大きく変わる。設定の正確な最新仕様は、公式のサンドボックス設定ドキュメントを一次情報として確認してほしい。

FAQ