Claude Codeサンドボックスで安全に自動実行【2026】

「--dangerously-skip-permissions を付けて Claude Code を回したいけど、暴走したら何をされるか分からなくて怖い」——これは Claude Code をエージェントとして本気で使い始めた開発者なら、ほぼ全員がぶつかる壁です。正直、私も最初は「YOLO モード」と呼んで毎回ビクビクしながら走らせていました。

でも実際のところ、リスクの正体は「Claude が間違ったコマンドを出すこと」よりも、「Claude が読み込んだファイルや Web ページに紛れ込んだ悪意ある指示（プロンプトインジェクション）に乗っ取られること」のほうが厄介です。プロンプトをいくら頑張って書いても、これは防げません。Claude の判断を信じる設計には限界があるからです。

そこで効いてくるのが Claude Code のサンドボックスです。これは Claude の判断とは独立して、OS が「このコマンドは作業ディレクトリの外には書き込めない」「許可していないドメインには接続できない」を物理的に強制する仕組みです。この記事では、2026年6月時点の公式ドキュメントをベースに、隔離実行の仕組みと権限設計の組み合わせ方を、開発者目線で具体的に整理します。

なぜ隔離が要るのか — 権限とプロンプトインジェクションのリスク

Claude Code の permissions は強力ですが、ひとつ構造的な弱点があります。公式ドキュメントが明記している通り、permission ルールはコマンド文字列（と auto モードでは分類器の判定）に基づいて「実行前」に評価されるのに対し、サンドボックスは走っているプロセスそのものに OS が境界を強制するという違いです。

この差が決定的です。permission ルールは「Claude が何を実行しようとしたか」を見ます。しかし許可したコマンドが、名前から想像する以上のことをやってしまったら？ たとえば Bash(npm run build *) を許可していて、ビルドスクリプトの中に汚染された依存パッケージが紛れ込み、ビルド中に ~/.ssh/id_rsa を外部に送信したら——permission ルールはこれを止められません。「npm run build」というコマンド名は許可されているからです。

サンドボックスは別の角度から守ります。OS レベルの境界なので、Claude が何を選んだかに関係なく、許可されたコマンドが名前以上のことをやろうとしても境界が効きます。ビルドがネットワークに出ようとしても、許可ドメイン以外なら OS が遮断します。これが「permissions だけでは足りず、サンドボックスが必要」な理由です。

公式ドキュメントは、効果的なサンドボックスにはファイルシステムとネットワークの両方の隔離が必要だと警告しています。ネットワーク隔離がなければ、侵害されたエージェントが SSH 鍵などの機密ファイルを外部に持ち出せてしまう。ファイルシステム隔離がなければ、システムリソースにバックドアを仕込んでネットワークアクセスを得られてしまう。どちらか一方を緩めると、もう一方の制限が無意味になりかねません。

サンドボックス機能の仕組み — ファイルシステムとネットワークの隔離

Claude Code のサンドボックスは「sandboxed Bash tool」と呼ばれ、Bash コマンドとその子プロセスに OS レベルの隔離を適用します。Read・Edit・Write といった組み込みファイルツールはサンドボックスを通らず、permissions システムで直接制御される点に注意してください（後述）。

ファイルシステム隔離のデフォルト挙動

• 書き込み：デフォルトでは現在の作業ディレクトリとそのサブディレクトリのみ。~/.bashrc などのシェル設定や /bin/ のシステムバイナリは変更不可
• 読み取り：デフォルトではコンピュータ全体を読み取り可能（一部の拒否ディレクトリを除く）。ここが見落としがちで、デフォルトのままだと ~/.aws/credentials や ~/.ssh/ も読めてしまいます。これらをブロックするには denyRead に明示的に追加する必要があります

これらの制限は OS レベルで強制されるため、kubectl・terraform・npm など、Claude のファイルツールではなく Bash から呼ばれるサブプロセス全般に適用されます。

ネットワーク隔離の仕組み

ネットワークアクセスは、サンドボックスの外で動くプロキシサーバーで制御されます。重要な点として、デフォルトでは事前許可されたドメインは一切ありません。コマンドが新しいドメインを必要とした最初の一回で、Claude Code が承認を求めます。プロンプトを避けたいなら allowedDomains でドメインを事前許可します。

ただし公式はセキュリティ上の限界も明記しています。組み込みプロキシは要求されたホスト名でallowlist を判定するだけで、TLS を終端・検査しません。そのため github.com のような広いドメインを許可すると、ドメインフロンティング等でallowlist 外のホストに到達される（データ流出経路になる）可能性があります。より強い保証が必要な場合は、TLS を終端して検査するカスタムプロキシを設定します。

OS プリミティブと前提パッケージ

サンドボックスは OS のセキュリティ機構を使います。macOS は組み込みの Seatbelt で、追加インストール不要。Linux と WSL2 は bubblewrap（ファイルシステム隔離）と socat（ネットワークプロキシへの中継）の2パッケージが必要です。native Windows は非対応で、Windows では WSL2 ディストリビューション内で動かします。WSL1 は bubblewrap が必要とするカーネル機能を欠くため使えません。

手元で有効化する手順

1. Claude Code のセッションを開始し、/sandbox コマンドを実行する
2. 表示されたパネルで、不足パッケージがないか確認する（不足があると Dependencies タブだけが表示される）
3. Linux/WSL2 なら不足パッケージをインストールする（Ubuntu/Debian は sudo apt-get install bubblewrap socat）
4. Claude Code を再起動する（依存チェックは起動時に走るため）
5. Mode タブで承認方式を選ぶ（auto-allow か regular permissions）
6. ビルドやテストなど Bash コマンドを実行させ、隔離内で走ることを確認する

パネルで Mode を選ぶと、設定はプロジェクトの .claude/settings.local.json に書き込まれます（git にはコミットされない）。全プロジェクトで有効にするには、ユーザー設定 ~/.claude/settings.json で sandbox.enabled を true にします。

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

上記は、kubectl などが作業ディレクトリの外に書き込む必要がある場合に、特定パスへの書き込みを許可する例です。逆に機密ディレクトリの読み取りを塞ぐなら、プロジェクトの .claude/settings.json に次を置きます。

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

この例はホームディレクトリ全体の読み取りをブロックしつつ、allowRead の .（プロジェクト設定なのでプロジェクトルートに解決される）からの読み取りだけを再許可します。サンドボックスのパス記法は標準的で、/tmp/build は絶対パス、~/ はホーム相対です。これは Read/Edit の permission ルール（絶対は //path）とは異なる点に注意してください。

dev container での隔離実行 — 無人運用の定石

サンドボックスは Bash コマンドの隔離には強力ですが、Claude Code プロセス全体を包む隔離が欲しい無人運用では、dev container（開発コンテナ）が定石です。Claude Code をコンテナ内で動かせば、Claude が実行するコマンドはホストではなくコンテナ内で実行され、プロジェクトファイルの編集だけがホストのリポジトリに反映されます。

最小構成は、リポジトリに .devcontainer/devcontainer.json を置いて Claude Code Dev Container Feature を追加するだけです。

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

無人運用で --dangerously-skip-permissions を使えるのは、コンテナが Claude Code を非 root ユーザーで動かすからです。実際、この CLI フラグは root で起動すると拒否されます（後述）。remoteUser が非 root アカウントになっていることを必ず確認してください。

egress firewall でネットワークを絞る

Anthropic 公式リポジトリのリファレンスコンテナには init-firewall.sh が含まれ、Claude Code と開発ツールが必要とするドメイン以外の outbound 通信をすべてブロックします。コンテナ内でファイアウォールを動かすには追加権限が要るため、リファレンスは runArgs 経由で NET_ADMIN と NET_RAW capability を付与しています。リファレンス設定は3ファイルで構成されます。

• devcontainer.json：ボリュームマウント、runArgs capability、拡張機能、containerEnv
• Dockerfile：ベースイメージ、開発ツール、Claude Code のインストール
• init-firewall.sh：許可ドメイン以外の outbound をすべてブロック

組織ポリシーを効かせたいなら、Dockerfile で /etc/claude-code/managed-settings.json を配置します。これは設定階層の最上位で適用され、エンジニアが ~/.claude やプロジェクトの .claude/ で設定した値を上書きします。ただし Dockerfile はリポジトリ内にあるため、書き込み権限があれば改変できます。本当にバイパスさせたくないポリシーは、server-managed settings や MDM で配信します。

なお公式は重要な注意も付けています。--dangerously-skip-permissions で実行した dev container は、悪意あるプロジェクトがコンテナ内からアクセスできるもの（~/.claude 内の Claude Code 認証情報を含む）を流出させるのを防げません。dev container は信頼できるリポジトリでのみ使い、~/.ssh やクラウド認証ファイルをホストからマウントするのは避けて、リポジトリスコープか短命トークンを使うべきです。

パーミッションモードと allow/ask/deny の組み合わせ

サンドボックスは「Bash コマンドが何にアクセスできるか」を制御しますが、「どのツール呼び出しを実行するか・プロンプトを出すか」は permission モードと permission ルールが決めます。両者は補完的なレイヤーです。

permission ルールの評価順

ルールは deny → ask → allow の順で評価され、最初にマッチしたルールが勝ちます。つまり deny ルールは常に最優先です。Bash ルールはワイルドカード * をサポートし、コマンドのどの位置にも置けます。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(.env)",
      "Read(~/.ssh/**)"
    ]
  }
}

ここで Bash(ls *) のように * の前にスペースがあると単語境界を強制するため ls -la にはマッチしても lsof にはマッチしません。一方 Bash(ls*) はスペースがないため両方にマッチします。この差はよくハマるポイントです。

permission モードと保護パス

permission モードは、ツール呼び出しごとに止まって承認を求める頻度を変えます。2026年6月時点で利用できるモードは次の通りです。

• default：読み取り以外は都度プロンプト
• acceptEdits：作業ディレクトリ内のファイル編集と mkdir・touch・mv・cp 等の一般的なファイルシステムコマンドを自動承認
• plan：読み取りと読み取り専用シェルのみ。ソースは編集しない
• auto：分類器がアクションを審査したうえでプロンプトなしに実行（リサーチプレビュー）
• dontAsk：事前承認済みツール以外は自動拒否。CI 向け
• bypassPermissions：すべてのプロンプトと安全チェックをスキップ

bypassPermissions 以外のすべてのモードでは、保護パスへの書き込みは自動承認されません。保護パスには .git・.config/git・.vscode・.idea・.husky・.cargo・.devcontainer・.yarn・.mvn といったディレクトリと、.bashrc・.zshrc・.npmrc・.mcp.json などのファイルが含まれます。これにより、リポジトリ状態と Claude Code 自身の設定が誤って破壊されるのを防ぎます。

bypassPermissions は隔離環境専用

bypassPermissions（--dangerously-skip-permissions と等価）は、すべてのプロンプトと安全チェックをスキップします。v2.1.126 以降は保護パスへの書き込みも含めてスキップします。ただし rm -rf / や rm -rf ~ のような root・ホーム削除だけは、モデルの誤りに対するサーキットブレーカーとして依然プロンプトを出します。

公式はこのモードをコンテナ・VM・dev container などの隔離環境でのみ使うことを明記しています。プロンプトインジェクションや意図しないアクションに対する保護がないからです。さらに Linux と macOS では、root や sudo で起動すると拒否されます。

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

このチェックは、認識されたサンドボックス内では自動的にスキップされます。だからこそ「コンテナで非 root ユーザーとして無人実行する」のが正攻法になるわけです。プロンプトを減らしつつ安全チェックは残したい場合は、bypassPermissions ではなく auto モードの利用が推奨されています。

CI・自律実行での安全設計と組織への強制

無人実行を本番運用に乗せるなら、設計の勘所は「フォールバックでこっそり隔離が外れないようにする」ことです。デフォルトでは、依存パッケージ不足や非対応プラットフォームでサンドボックスが起動できないと、Claude Code は警告を出して隔離なしでコマンドを実行してしまいます。これをハードな失敗にするには sandbox.failIfUnavailable を true にします。

また、サンドボックス内で失敗したコマンドを dangerouslyDisableSandbox パラメータで隔離外に再試行する「エスケープハッチ」も存在します。これを完全に無視させ、すべてのコマンドを隔離内で走らせるには allowUnsandboxedCommands を false にします（/sandbox の Overrides タブでは Strict sandbox mode として表示）。

組織全体に強制する managed settings の例が次です。

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

さらに次の点を押さえると、defense-in-depth として堅くなります。

• denyRead に ~/.aws・~/.ssh を追加する（デフォルトの読み取りポリシーではこれらが読めてしまうため）
• ネットワークドメインを managed 値に固定するなら allowManagedDomainsOnly を true にする（非許可ドメインはプロンプトなしで自動ブロック）
• boolean キー（enabled 等）は managed 値が優先されるが、excludedCommands のような配列キーは全スコープでマージされる。開発者が緩める余地があるので managed リストは狭く保つ

サブエージェントについては、公式が明記しています。サブエージェントは親セッションと同じプロセスで動き、同じサンドボックス設定を使うため、親でサンドボックスが有効なら、サブエージェント内の Bash コマンドも隔離されます。auto モードでは、サブエージェントの委譲タスクが起動時に審査され、各アクションも親と同じルールで分類器を通ります。

失敗パターン

• ❌ サンドボックスを有効化したつもりが、Linux で bubblewrap/socat 未インストールのまま走らせていた → ⭕ /sandbox の Dependencies タブで確認し、managed 運用では failIfUnavailable: true で起動を止める
• ❌ allowedDomains に github.com を広く許可して流出経路を作っていた → ⭕ プロキシは TLS を検査しないことを理解し、必要最小のドメインに絞るか TLS 検査するカスタムプロキシを使う
• ❌ デフォルト読み取りで ~/.ssh が読める前提を見落としていた → ⭕ denyRead に認証情報ディレクトリを明示追加する
• ❌ root で --dangerously-skip-permissions を使おうとして起動拒否された → ⭕ dev container で非 root ユーザー（remoteUser）として動かす

まとめ — 多層防御で「安全な自動化」を組む

Claude Code の安全な自動実行は、ひとつの魔法のフラグではなく、性質の違う3つのレイヤーを重ねる設計で成り立ちます。permission ルール（Claude が実行前に止められる）、permission モード（プロンプトの頻度と保護パス）、そしてサンドボックス（OS が走るプロセスに境界を強制する）。プロンプトインジェクションで Claude の判断が乗っ取られても OS の境界は効く——ここがサンドボックスを足す最大の意味です。

無人運用なら dev container で Claude Code プロセス全体を非 root で包み、init-firewall.sh で egress を絞り、managed settings で failIfUnavailable と allowUnsandboxedCommands: false を効かせる。この型に乗せれば、2026年6月時点で「都度承認なしの自動化」と「壊れない・漏れない」を現実的に両立できます。

関連して、法人での導入・運用チェックはClaude Code法人導入セキュリティ完全チェックリストに、Hooks による自動化の組み方はClaude Code Hooks実践ガイドに、編集前の安全な探索フローはClaude Code Plan Mode実践ガイドにまとめています。

FAQ

Q. サンドボックスを有効にすると permission ルールは不要になりますか？
いいえ。両者は別レイヤーで、補完関係です。サンドボックスは Bash とその子プロセスのファイルシステム・ネットワークに OS 境界を強制しますが、Read・Edit・WebFetch・MCP など他のツールには適用されません。deny ルールは「Claude がアクセスを試みること自体」を止めるので、両方を使う defense-in-depth が推奨されます。

Q. Windows でサンドボックスは使えますか？
native Windows は非対応です。Windows では WSL2 ディストリビューション内で Claude Code を動かし、bubblewrap と socat をインストールします。WSL1 は非対応です。

Q. auto-allow モードと auto モードは同じものですか？
別物です。サンドボックスの auto-allow はサンドボックス境界がコマンドを封じ込めているから Bash を自動承認するもので、permission モードの auto は分類器がアクションを審査するものです。両者は独立して動き、組み合わせられます。

出典

• Claude Code Docs — Configure the sandboxed Bash tool
• Claude Code Docs — Configure permissions
• Claude Code Docs — Choose a permission mode
• Claude Code Docs — Development containers
• Claude Code Docs — Sandbox environments

---

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。

関連記事（Claude Code 実践ガイド）

• まとめ：Claude Code 実践テクニック完全ガイド（12スキル）
• コスト・トークン最適化ガイド
• ヘッドレス自動実行ガイド｜-p・SDK・CI
• Skills作成ガイド｜SKILL.md入門
• Agent Teams｜複数AIで協調開発

あわせて読みたい：【2026】Claude Code rewindで巻き戻す｜会話とコード復元

あわせて読みたい：【2026】Claude CodeでQA・テスト自動化を加速する実践ガイド

あわせて読みたい：【2026】Claude Codeで脆弱性対応を効率化する実践ガイド

関連記事（自動）

• ▸ Claude Codeでライブラリ選定・技術調査を効率化する【2026】
• ▸ Claude Codeで技術的負債を返済する実践ガイド【2026】
• ▸ Claude Codeでプロトタイプ・MVPを高速に作る実践ガイド【2026】
• ▸ Claude Codeの拡張思考活用ガイド｜難問で深く考えさせる【2026】
• ▸ Claude Code IDE統合｜VSCode・JetBrains【2026】