Claude Codeのセキュリティと安全な使い方｜サンドボックス・権限・--dangerously-skip-permissions徹底解説【2026年版】

Claude Codeはデフォルトで「読み取り専用」で動作し、ファイル編集・コマンド実行・ネットワーク要求は必ずユーザーの承認を要する設計です。 そのうえで「Permissions（権限）」「Sandboxing（サンドボックス）」「Permission modes（権限モード）」の3層で危険行為を抑止しているため、正しく設定すればローカル環境への実害は現実的にほぼ防げます。一方で、--dangerously-skip-permissions（bypassPermissions モード）をホストマシン上で使うのは公式が明確に非推奨で、2025年以降に実際の事故事例も複数報告されています。

この記事では、公式ドキュメント（code.claude.com/docs）と Anthropic Engineering Blog の最新仕様（Claude Code v2.1.126 時点）をベースに、個人開発者からエンタープライズまでの安全運用パターンを整理します。

この記事でわかること

• Claude Codeの3層セキュリティ（Permissions / Sandboxing / Permission modes）の全体像
• 6つのPermission mode の挙動と使い分け
• --dangerously-skip-permissions の正確な仕様と「使ってよい場面 / 使ってはいけない場面」
• 2026年3月にローンチした Auto mode（--dangerously-skip-permissions の安全な代替）の最新仕様
• 個人 / チーム / エンタープライズそれぞれの安全な設定テンプレート（コピペ可）
• 2025年10月以降に実際に起きた rm -rf 事故の事実関係と教訓
• Managed Settings（MDM配信）の優先順と組織統制機能

誰向けの記事か

• Claude Codeを個人・チームで導入したいが、AIに自動でコマンド実行させる不安を解消したいエンジニア
• --dangerously-skip-permissions の使いどころと危険性を正確に把握したい開発者
• 組織にClaude Codeを展開するIT・セキュリティ担当者（MDM・Managed Settings・監査対応）
• Bedrock / Vertex / Foundry 経由で Claude Code を使うため Auto mode が使えず、代替策を検討中の方

Claude Codeのセキュリティ設計：3層防御の全体像

出典: Anthropic公式「Claude Code」製品ページ

Claude Codeのセキュリティは「Permissions（権限）」「Sandboxing（サンドボックス）」「Permission modes（権限モード）」の3層構造になっています。 公式ドキュメント（code.claude.com/docs/en/security）で、以下のように位置づけられています。

加えて、Bash実行前後に任意スクリプトを差し込む「Hooks」 を使えばAIの出力を信用せずに決定論的にブロックできます。実務ではこの「Sandbox × Permissions × Hooks」を3層防御と呼んで設計するのが定番です。Hooksの詳細はClaude Code Hooks の使い方を参照してください。

デフォルトで効いている保護

設定を一切触らなくても、Claude Codeは起動時点で以下の保護が有効です（現時点で公式ドキュメントに記載のもの）。

• 書き込みは起動ディレクトリとサブディレクトリに限定（親ディレクトリやユーザーホーム直下は書けない）
• 編集・実行は必ずユーザー承認を要する（読み取りは自由）
• curl / wget などWeb取得コマンドは基本ブロック
• WebFetchは別コンテキストで処理（本体セッションへのプロンプトインジェクション混入を抑止）
• Bashコマンドインジェクション検知：許可済みでも「怪しい」と判定されれば手動承認を要求
• 初回MCPサーバーは信頼確認プロンプト

公式は「Claude Codeは既定で読み取り専用。編集・実行には必ず承認が必要」という Permission-based architecture を明言しています。 いきなり rm -rf が走るのは、通常のデフォルト設定では起こりません。

Claude Code 本体の概要や他機能も把握したい場合はClaude Code とは？機能・使い方・料金を徹底解説も合わせてご覧ください。

Permission mode 6種類の使い分け

出典: Anthropic公式ドキュメント「Choose a permission mode」

Permission modeは「どれだけ承認を省略するか」の基本姿勢を決める設定で、6種類あります。 CLIでは Shift+Tab を押すたびに default → acceptEdits → plan と循環し、claude --permission-mode plan のように起動時指定もできます。

公式 code.claude.com/docs/en/permission-modes の現行仕様を整理すると以下の通りです。

UI ラベル（VS Code / Desktop）と対応：

• Ask before edits = default
• Edit automatically = acceptEdits
• Plan mode = plan
• Auto mode = auto
• Bypass permissions = bypassPermissions

個人・チーム・組織でのおすすめ

• 個人開発（ローカルPC）: 通常は default、慣れたら acceptEdits。bypassPermissions は基本使わない
• チーム開発: plan で調査 → acceptEdits で実装 → PRレビュー の流れが安全
• CI/CD・バッチ: dontAsk ＋ 明示的な allow リスト。該当しないものはすべて拒否で止まる
• 隔離コンテナ／devcontainer: 完全自動化したいなら auto を第一候補。bypassPermissions は最終手段

Permission rules（allow / ask / deny）の書き方と4つの落とし穴

Permission rulesは allow / ask / deny の3種類で、評価順は「deny → ask → allow → デフォルト」です。 deny が最優先で、最初にマッチしたルールが勝ちます。書き方を間違えると「effectiveに何も守られていない」状態になりやすいため、落とし穴を把握することが重要です。

ルールの基本形

.claude/settings.json に以下のように書きます（公式サンプルに準拠）。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Read(./src/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "WebFetch(domain:*.untrusted.example.com)"
    ]
  }
}

• Bashルールはワイルドカード対応：Bash(git * main) のように任意位置で使える。Bash(*) は Bash と等価で全許可
• 複合コマンドは各サブコマンドを独立評価：&& || ; | |& & 改行で分割。1つでも deny に該当すれば全体ブロック
• 自動剥離されるラッパー：timeout, time, nice, nohup, stdbuf, flag なしの xargs は剥がされて内部コマンドで判定
• Read/Edit ルールは gitignore 構文：//path = 絶対、~/path = ホーム相対、/path = プロジェクトルート相対、./path = カレント相対
• Symlink の扱い：allow は実体とリンク両方が一致して許可（厳格）、deny はどちらか一致で拒否（fail-safe）

落とし穴①：剥離されない実行ラッパーがある

devbox run *、docker exec *、direnv exec *、mise exec *、npx * は 自動剥離の対象外 です。つまり Bash(devbox run *) を allow に入れると、内部で devbox run rm -rf . まで通ってしまいます。公式 permissions ページでも明確に警告されている要注意パターンです。さらに watch, setsid, ionice, flock, find -exec / find -delete は常に手動承認が必要な特別扱いとなっています。

落とし穴②：Read deny は Bashサブプロセスの読み取りを止めない

Read(./.env) を deny に入れても、それはClaude Code内蔵のReadツールと、Claude Codeが認識する cat / head / tail / sed をブロックするだけです。Python や Node スクリプトが内部で open() するような任意のサブプロセスからの読み取りは止められません。OS レベルで封じるには Sandbox 併用が必須です。

落とし穴③：Read/Edit と Sandbox でパス構文が違う

ここは公式ドキュメントを跨いで初めて気付く罠です。同じ /path でも意味が異なります。

Read で Read(/etc/shadow) と書いてもプロジェクトルート配下の /etc/shadow を指すだけで OS の /etc/shadow は守れません。OS の絶対パスを指したいときは Read/Edit では //etc/shadow、Sandbox では /etc/shadow と覚えておきましょう。

落とし穴④：広すぎるドメイン許可は Domain fronting で迂回される

WebFetch(domain:github.com) のように広いドメインを許すと、Domain fronting と呼ばれる回避手法で許可外サーバーにトラフィックを流される恐れがあります。公式は可能な限りサブドメイン単位で絞ることを推奨しています。また WebFetch だけを deny しても Bash の curl / wget で迂回可能なため、Bash 側の deny も併用するのが基本です。

Sandboxing（サンドボックス）の仕組み

出典: Anthropic公式ドキュメント「Sandboxing」

SandboxingはOSレベルのプリミティブで Bashコマンドと子プロセスを隔離する仕組みで、Anthropic 内部利用では権限プロンプトが 84% 削減されたと報告されています（Anthropic Engineering Blog、2025-10-20）。Read/Editのdenyルールで防げないBash経由のアクセスを、OS層で物理的に封じる役割を担います。

OS別の実装

WSL2 ではサンドボックス内から Windows バイナリ（cmd.exe / powershell.exe / /mnt/c/ 配下）を起動できません。必要なら excludedCommands で除外します。

有効化の方法

セッション中の即時有効化と、settings.json での常時有効化の2通りです。

# セッション内で有効化
/sandbox

// settings.json
{
  "sandbox": {
    "enabled": true,
    "mode": "auto-allow",
    "failIfUnavailable": true
  }
}

依存パッケージが欠落しているとデフォルトでは「警告して非サンドボックスで実行」となるため、組織配信時は failIfUnavailable: true を明示してハードフェイル化するのが安全です。

2つのサンドボックスモード

• Auto-allow mode: サンドボックス内で動くコマンドは自動承認。外に出る必要があるコマンド（非許可ホスト等）は通常の権限フローへ。rm / rmdir で /、ホーム、その他クリティカルパスを狙うものは常にプロンプト
• Regular permissions mode: サンドボックスはするが通常通り権限プロンプトを経由

両モードとも同じファイルシステム・ネットワーク制限を OS レベルで強制します。

ファイルシステム分離の設定例

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

• allowWrite / denyWrite / denyRead / allowRead は複数スコープでマージ（置換ではない）
• allowRead は denyRead より優先
• 管理者が allowManagedReadPathsOnly: true を設定すると、Managed Settings 側の allowRead のみが尊重される

ネットワーク設定

{
  "sandbox": {
    "network": {
      "allowedDomains": ["api.github.com", "registry.npmjs.org"],
      "deniedDomains": ["*.untrusted.example.com"],
      "allowManagedDomainsOnly": true,
      "httpProxyPort": 8080,
      "socksProxyPort": 8081
    }
  }
}

• 内蔵プロキシは TLS 検査・終端をしません（ホスト名ベースのみ判定）。厳格な要件があるならカスタムプロキシで TLS 終端＋CA を sandbox 内にインストール
• deniedDomains は allowedDomains のワイルドカード許可を上書きしてブロック可能

Escape hatch と完全封鎖

• dangerouslyDisableSandbox パラメータで個別コマンドをサンドボックス外実行（通常権限フロー経由）
• 完全に塞ぐなら "allowUnsandboxedCommands": false を明示する。管理者配信ではこれを推奨

Unix socket と enableWeakerNestedSandbox の警告

allowUnixSockets で /var/run/docker.sock を許可すると、サンドボックス脱出経路になるため公式が強く警告しています。同様に enableWeakerNestedSandbox（非特権namespaceなしDocker内でも動くモード）は公式が「セキュリティが著しく弱まる」と明言しているため、本番運用では避けるべきです。

docker や watchman はサンドボックスと相性が悪いため、excludedCommands での除外、または jest --no-watchman などで回避します。

OSS の sandbox-runtime

npx @anthropic-ai/sandbox-runtime <command> を使えば、任意プロセス（MCP server や CI スクリプト等）を Claude Code と同じサンドボックスに閉じ込められます。リポジトリは github.com/anthropic-experimental/sandbox-runtime。

--dangerously-skip-permissions の危険性と正しい使いどころ

--dangerously-skip-permissions（= bypassPermissions モード）は、すべての権限プロンプトをスキップして完全自動で動作するモードです。公式は「コンテナ／VM／インターネット切断済み devcontainer 以外では絶対に使わないでください」と明確に警告しています。

何がスキップされるか（v2.1.126時点の最新仕様）

⚠️ v2.1.126 で挙動が変更されました。

• 旧バージョン: 保護パスへの書き込みはプロンプトを出していた
• 現行（v2.1.126以降）: 保護パスへの書き込みも auto-approve され、rm -rf / と rm -rf ~ のみが circuit breaker として残る

つまり「bypassPermissions でも .git や .zshrc は守ってくれる」という旧情報を信じてホスト上で起動すると、現行版では普通に上書きされる恐れがあります。

起動方法

# 同じ挙動
claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions

--dangerously-skip-permissions は root/sudo 権限では起動できません（Linux/macOS）。cannot be used with root/sudo privileges for security reasons エラーで拒否されます。逆に、認識されたサンドボックス内では自動的に skip 判定になります。

使ってよい場面 / 使ってはいけない場面

公式の警告（抜粋）

"Only use this mode in isolated environments like containers, VMs, or devcontainers without internet access, where Claude Code cannot damage your host system."

--dangerously-skip-permissions はプロンプトインジェクションへの保護を一切持ちません。外部からの悪意ある指示がタスクに混入した場合、AIがそれを信じて破壊的操作を行ってもユーザーは止められません。

組織で完全に封じる

Managed Settings（後述）で以下を設定すると、組織全体で bypassPermissions モードを無効化できます。disableBypassPermissionsMode は任意のスコープで動作するため、ユーザー設定で「自分を bypass から締め出す」用途にも使えます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Auto mode：--dangerously-skip-permissions の安全な代替

出典: Anthropic Engineering Blog

Auto modeは、Anthropic が公式ブログ（2026-03-24）で「--dangerously-skip-permissions の安全な代替として設計した」と明言する権限モードです。 Classifier（分類器モデル）が各アクションを事前評価し、危険判定のものだけブロックする設計で、Claude Code v2.1.83 以降 で利用可能です。

デフォルトでブロックされるもの

• curl | bash のようなダウンロード即実行
• 機密データの外部送信
• 本番デプロイ・マイグレーション
• クラウドストレージの mass delete
• IAM / リポジトリ権限付与
• 共有インフラの改変
• セッション開始前から存在するファイルの不可逆削除
• git push --force、main ブランチへの直接 push

デフォルトで許可されるもの

• 作業ディレクトリ内のローカルファイル操作
• lock file / manifest 由来の依存インストール
• .env を読み、対応する API に認証情報送信
• 読み取り専用 HTTP リクエスト
• セッション開始ブランチへの push

対応プラン・対応プロバイダ・対応モデル

Auto modeはプラン・プロバイダ・モデルによって利用可否が異なります。ここを誤解すると「契約したのに使えない」事故が起きるため、最新仕様の整理を確認しましょう。

プラン別の詳細はClaude Code 料金プラン完全ガイドも併読してください。

Classifier の挙動

• 2段階分類: Stage 1 で高速 1-token 判定（誤検知 8.5%）、疑わしいものだけ Stage 2 で chain-of-thought 再判定（誤検知 0.4%）
• 対象データ: ユーザーメッセージ・ツール呼び出し・CLAUDE.md。ツール結果は剥がされる（プロンプトインジェクション緩和）
• コスト: classifier はサーバー側固定モデル。/model 選択と独立だが、トークン使用量にはカウントされる
• 読み取り・作業ディレクトリ内編集（保護パス除く）は classifier をスキップ

Auto mode の安全停止

連続 3 回 または累計 20 回 ブロックされると auto mode が一時停止し、通常プロンプトに復帰します。閾値は変更不可。非対話 -p モードではこの時点で abort します。各 denial は /permissions の Recently denied に表示され、r キーで手動承認して再試行できます。

サブエージェントの扱い（要注意）

サブエージェントでは spawn 前の delegated task 評価、実行中の各アクション、完了時の return check の3点で評価されます。重要な点として、サブエージェント frontmatter の permissionMode は無視され、auto mode のポリシーが常に適用されます。 「Plan サブエージェントだから安全だろう」と思っても、Auto mode 下ではメインと同じ classifier 判定が走ります。

Auto mode 進入時の自動安全化

広い allow ルール（Bash(*), Bash(python*), Agent allow など）は auto mode 進入時に自動で剥がされます（auto mode を抜けると復元）。一方、Bash(npm test) のような narrow なルールはそのまま残ります。

設定例

{
  "autoMode": {
    "environment": "信頼できるリポジトリ: my-org/*。本番バケット prod-data への書き込みは常に拒否。",
    "soft_deny": ["Bash(git push origin main)"],
    "allow": ["Bash(npm install)"]
  }
}

⚠️ 重要: autoMode.soft_deny や autoMode.allow を書くと デフォルトルールが全置換 されます。先に claude auto-mode defaults でデフォルト値を出力し、それを編集する形が安全です。

Bedrock / Vertex / Foundry ユーザーへの代替策

クラウドベンダー経由（Bedrock / Vertex / Foundry）では Auto mode が現時点で使えません。AWS/GCP/Azure 上で Claude Code を利用している組織は、以下の組み合わせで近い体験を作るのが現実的です。

1. dontAsk モード ＋ プロジェクトごとの narrow な allow リスト
2. Sandbox を auto-allow モードで有効化（プロンプト 84% 削減効果を活用）
3. Managed Settings で allowManagedDomainsOnly: true allowUnsandboxedCommands: false を強制
4. PreToolUse Hook で組織固有の deny を確実に動かす（Claude Code Hooks 詳細）

--dangerously-skip-permissions との使い分けフローチャート

自動化したい？
├─ No → default / acceptEdits で十分
└─ Yes
   ├─ 作業環境は隔離されているか（VM/コンテナ）？
   │  ├─ Yes かつ プランが Auto mode 対応 → Auto mode 推奨
   │  ├─ Yes かつ プランが Auto mode 非対応 → bypassPermissions（コンテナ内でのみ）
   │  └─ No → Auto mode（ホスト上でも比較的安全）
   └─ CI/CDで自動実行したい
      └─ dontAsk ＋ 明示的 allow リスト

3層防御の実践的な設定例（個人開発者向け）

実務では「Sandbox（OS層）× Permissions（AI指示層）× Hooks（決定論層）」を組み合わせることで、AIの出力を信用せずに確実にブロックできます。 以下は個人開発者向けの最小構成例です。

{
  "permissions": {
    "deny": [
      "Read(//~/.env)",
      "Read(//~/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gh/**)",
      "Bash(rm -rf /*)",
      "Bash(sudo *)",
      "Bash(curl * | sh)",
      "Bash(curl * | bash)",
      "Bash(devbox run *)",
      "Bash(docker exec *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)",
      "Bash(rm -rf *)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git add *)",
      "Bash(git commit -m *)",
      "Bash(npm test)",
      "Bash(npm run *)",
      "Read(./**)",
      "Edit(./**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "mode": "auto-allow",
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": [
        "api.github.com",
        "registry.npmjs.org",
        "api.anthropic.com"
      ],
      "deniedDomains": ["*.untrusted.example.com"]
    }
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": ".claude/scripts/deny-check.sh"
      }
    ]
  }
}

各層の役割

個人開発者向け「最初の3ステップ」

1. Sandboxを有効化する（macOSは標準。Linux/WSL2は bubblewrap / socat を APT 導入）
2. .env / .ssh / .aws / .config/gh など機密ファイルを deny に入れる
3. --dangerously-skip-permissions は使わない。自動化したいなら Auto mode を選ぶ

組織向けセキュリティ管理（Managed Settings / MDM）

出典: Anthropic公式ドキュメント「Claude Code settings」

Team / Enterprise プランでは Managed Settings（MDM配信可能な設定ファイル）を使い、組織全体で一律のセキュリティポリシーを強制できます。 ユーザーやプロジェクトが個別に緩める設定を書いても、Managed Settings が最優先で上書きされます。

設定の優先順（高→低）

1. Managed Settings（MDM / OSポリシー / managed-settings.json）
2. CLI 引数
3. Local project（.claude/settings.local.json）
4. Shared project（.claude/settings.json）
5. User（~/.claude/settings.json）

必ず入れたい Managed-only 設定

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowManagedPermissionRulesOnly": true,
  "forceRemoteSettingsRefresh": true,
  "sandbox": {
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowManagedReadPathsOnly": true
    },
    "network": {
      "allowManagedDomainsOnly": true
    }
  }
}

ConfigChange Hook で設定変更を監査

新規追加された ConfigChange フックを使えば、セッション中の設定変更を監査・ブロックできます。PreToolUse の Exit code 2 は blocking で、これは allow ルールより優先される「真の最後の砦」として機能します。

組織でClaude Codeを安全に展開する全体手順はClaude Code チーム導入ガイドで詳細に解説しています。

Claude Code on the web と Remote Control のセキュリティモデル

クラウドベース実行には2つのモードがあり、それぞれセキュリティ境界が大きく異なります。規制業界・監査要件のある組織では、ローカル実行よりこちらを第一選択にする方が運用上シンプルになることが多いです。

Claude Code on the web は、特にSOC2 / ISO 27001 監査対応が必要な組織で運用負荷を大きく下げる選択肢です（Anthropic 自身も trust.anthropic.com で SOC 2 Type 2 / ISO 27001 を公開）。

実際に起きた事故事例と教訓（2025〜2026）

公式ドキュメントの外、GitHub Issue や開発者ブログから確認できる事案を、公式の責任範囲を断定しない形で整理します。

事案①：2025-10-21 Mike Wolak 事案（GitHub Issue #10077）

• 環境: Ubuntu / WSL2
• 指示: Makefile プロジェクトの再ビルド
• 発生: Claude Code が rm -rf を / から実行。/bin, /boot, /etc 等は permission denied で失敗したが、ユーザー所有ファイルは全て削除
• 重要な事実: 投稿者は --dangerously-skip-permissions を使っていなかったと報告

教訓は 「bypassPermissions を使っていなくても、AI が destructive command を実行することはありうる」 という点です。Permission system は AI 指示層の防御に過ぎず、OS 層の Sandbox を併用しないと止めきれないシナリオがあることを示唆しています。

事案②：2025-12 GitHub Issue #24196

• 指示: 古いリポジトリのクリーンアップ
• 発生: Claude が rm -rf tests/ patches/ plan/ ~/ を生成。シェルが ~/ をホームディレクトリ全体に展開し、デスクトップ・Keychain・アプリケーションデータが全消失
• 追加報告: Claude が stderr を 2>/dev/null でリダイレクトしてエラーを隠していた

教訓は、チルダ展開を含む rm -rf のリスクと、stderr 抑止を含む生成コマンドは PreToolUse Hook で検知すべきという点です。

この2件から導かれる対策

1. Bash(rm -rf *) は deny ではなく ask に置き、必ず人間が中身を確認する
2. Sandbox を必ず有効化 し、/、~/、~/Library/、~/.config/ などへの書込を OS 層で封じる
3. PreToolUse Hook で 2>/dev/null を含むコマンドを警告するスクリプトを差し込む
4. プロンプトインジェクションリスクを下げるため、信頼できないコンテンツを直接プロンプトに流さない

Claude Code に限らず、AIコーディング全般のセキュリティ論点はAIコーディング セキュリティ リスクも参考になります。

よくある誤解と本当の危険

誤解と事実の切り分け

本当に警戒すべきリスク

• --dangerously-skip-permissions をホスト上で使う（最大リスク）
• 実行ラッパーを広く許可する：Bash(devbox run *) Bash(docker exec *) Bash(npx *) は剥離対象外
• 広すぎるドメイン許可：github.com など広範な許可は Domain fronting でデータ流出経路に
• MCPサーバーの野良利用：MCP は Anthropic の監査対象外。信頼できる提供元か自前実装に限定する（参考：Claude Code MCP連携ガイド）
• Windows WebDAV：WebDAV 有効化や \\* パス許可は権限システムのバイパス経路。Microsoftも非推奨化
• allowUnixSockets で /var/run/docker.sock を許可：サンドボックス脱出経路
• enableWeakerNestedSandbox：公式が「セキュリティが著しく弱まる」と明言。本番運用では避ける

プロンプトインジェクションの完全防御は不可能であることを公式も明記しています。 推奨対策は「提案コマンドを必ずレビュー」「信頼できないコンテンツを直接パイプで流さない」「VM で実行」「/feedback で怪しい挙動を報告」「脆弱性は HackerOne 経由で報告」の5点です。

こんな人におすすめ／こんな使い方はおすすめしない

安全運用に向いている使い方

• 個人開発で、デフォルト設定のままターミナルから利用：読み取り専用＋都度承認で運用できる開発者
• VM／隔離コンテナ／devcontainer 内で Auto mode を使う：プロンプト疲れを避けつつ分類器で危険行為だけブロック
• Team / Enterprise で Managed Settings を配信：IT部門が MDM 経由で一律ポリシーを強制できる組織
• Claude Code on the web を第一選択に：監査要件・規制業界向け
• Bedrock / Vertex / Foundry で Sandbox + dontAsk + Hooks の三段構え：Auto mode 非対応環境での実用解

この使い方はおすすめしません

• ホストOS上で --dangerously-skip-permissions を常用：公式も警告する最も危険な使い方
• 企業で個人PCに無管理配布：Managed Settings なしでは .ssh や本番アクセスを抑止できない
• .env や機密ファイルを deny に入れずに業務PCで使う：Bashサブプロセス経由の読み取りが素通り
• MCPサーバーを野良で入れ続ける：監査外の MCP は情報流出経路になりうる
• サンドボックス無効のままLinuxホストで使う：cat /etc/shadow 相当のリスクが残る
• enableWeakerNestedSandbox を本番運用：セキュリティが著しく弱まる

FAQ

Q1. Claude Codeはデフォルトで危険ですか？

いいえ、デフォルトは読み取り専用で、編集・Bash実行はすべて承認が必要です。危険なのは --dangerously-skip-permissions をホスト上で使ったり、実行ラッパーを広く許可するなど「デフォルトを大きく外した使い方」をした場合です。

Q2. --dangerously-skip-permissions は本当に使ってはいけないのですか？

ホストOS上では公式が明確に非推奨としています。隔離コンテナ／VM／インターネット切断済み devcontainer に限定すれば使用可能です。v2.1.126 以降は保護パスへの書き込みもプロンプトせず通すように変わったため、旧バージョンよりさらに慎重な扱いが必要です。2026年以降は公式が「安全な代替」と位置づける Auto mode（Team / Enterprise / API / Max で利用可）を優先しましょう。

Q3. .env を deny に入れれば API キー流出は防げますか？

Claude Code の Read ツール経由の読み取りは防げますが、Bash の cat .env や Python / Node スクリプトの open() は防げません。Sandboxing でファイルシステム分離を併用してください。

Q4. Windowsネイティブでサンドボックスは使えますか？

現時点では公式にネイティブWindowsはサンドボックス非対応です。WSL2 環境で bubblewrap と socat を導入して利用する形が標準です。WSL1 は Linux namespace 要件を満たさないため非対応。Windowsネイティブ対応は公式に「予定」と記載されています。

Q5. Managed Settings はどうやって配信しますか？

Jamf / Intune / Workspace ONE などの MDM を使い、プラットフォーム別の所定パスに managed-settings.json を配置します。配置先は macOS / Windows / Linux で異なり、公式ドキュメントに記載があります。Managed Settings は CLI 引数やユーザー設定より優先され、ユーザーが上書きすることはできません。組織導入の詳細はClaude Code チーム導入ガイドを参照してください。

Q6. Auto mode はどのプランで使えますか？対応モデルは？

Max（Opus 4.7 のみ）、Team、Enterprise、Anthropic API 直接利用で使えます。Team / Enterprise / API は Sonnet 4.6 / Opus 4.6 / Opus 4.7 が対象。Pro は非対応、Bedrock / Vertex / Foundry 経由も非対応、Haiku / Claude 3系も非対応です。Claude Code v2.1.83 以降 が必要。料金プランの詳細はClaude Code 料金プラン完全ガイドへ。

Q7. サンドボックスはどれくらい効果がありますか？

Anthropic の内部利用テストでは、Sandboxing により権限プロンプトが 84% 削減されたと報告されています（Anthropic Engineering Blog、2025-10-20）。ただし自社環境で同じ効果が出るとは限らないため、あくまで目安としてください。

Q8. Bedrock / Vertex / Foundry で Auto mode が使えません。代替はありますか？

dontAsk モード ＋ narrow な allow リスト ＋ Sandbox（auto-allow）＋ Managed Settings（allowManagedDomainsOnly: true、allowUnsandboxedCommands: false）＋ PreToolUse Hook の組み合わせが現実的です。AWS / GCP / Azure 経由の組織で Claude Code を導入する場合は、この5層構成で Auto mode に近い体験を作れます。

Q9. プロンプトインジェクション対策は何をすればよいですか？

公式は完全防御は不可能と明記しています。推奨対策は以下の5点です。

1. AI が提案するコマンドを必ず人間がレビュー
2. 信頼できない外部コンテンツをプロンプトに直接パイプしない
3. 自動化は VM / コンテナで実行
4. 怪しい挙動を見たら /feedback で報告
5. 脆弱性は HackerOne プログラム経由で正式報告

Q10. rm -rf 事故は実際にどれくらい起きていますか？

確認できる範囲では、2025年10月以降に GitHub Issue #10077（WSL2環境、--dangerously-skip-permissions 不使用と報告）、#24196（2025-12、~/ 展開によるホーム消失）など複数件のユーザーレポートが存在します。Anthropic の公式声明は限定的ですが、「bypassPermissions を使っていなくても起こりうる」 ことを示唆しているため、Sandbox + Hooks の併用が現実的な防御策です。

まとめ：Claude Codeを安全に使うためのチェックリスト

• ✅ デフォルトは読み取り専用という前提を理解している
• ✅ Permission mode の6種類を把握し、用途別に使い分けている
• ✅ .env / .ssh / .aws / .config/gh を deny に入れている
• ✅ Sandbox を有効化している（macOSは標準、Linux/WSL2 は bubblewrap 導入）
• ✅ Bash(devbox run *) Bash(docker exec *) Bash(npx *) のような実行ラッパー全通し設定を避けている
• ✅ --dangerously-skip-permissions は VM / コンテナでのみ使っている（v2.1.126 で保護パス警告が外れた点を理解している）
• ✅ 自動化が必要なら Auto mode（対応プランの場合）を優先している
• ✅ Bedrock / Vertex / Foundry 経由なら dontAsk ＋ Sandbox ＋ Hooks の代替構成を採っている
• ✅ 組織導入時は Managed Settings で disableBypassPermissionsMode allowUnsandboxedCommands: false forceRemoteSettingsRefresh を設定している
• ✅ MCP サーバーは信頼できる提供元／自前実装に限定している
• ✅ 監査要件があるなら Claude Code on the web を第一選択にしている

Claude Codeは、適切に設定すれば「AI にコマンドを任せる不安」のほとんどを技術的に解消できる設計になっています。一方で、「全部承認を飛ばしたい」という誘惑に負けてホスト上で --dangerously-skip-permissions を使うと、最悪の場合ファイルシステムの破壊まで起こり得ます。

「どこを隔離するか」「どこに境界線を引くか」を明示して設計することが、Claude Codeを長く安全に使うための本質です。本記事で紹介した3層防御テンプレートをベースに、自組織の脅威モデルに合わせてチューニングしてみてください。

関連記事

• Claude Code とは？機能・使い方・料金を徹底解説 — Claude Code 本体の概要と全体像
• Claude Code 料金プラン完全ガイド — Pro / Max / Team / Enterprise の違い
• Claude Code Hooks の使い方 — PreToolUse Hooks で決定論的制御
• Claude Code Skills と Hooks の使い分け — Skills と Hooks の役割分担
• Claude Code MCP連携 ガイド — MCP サーバー連携とセキュリティ
• Claude Code チーム導入 ガイド — チーム・組織への展開手順
• Claude Code コスト最適化 — Auto mode の classifier コストも踏まえた節約術
• Awesome Claude Code 活用集 — 実務ノウハウ集
• AIコーディング セキュリティ リスク — AIコーディング全般のセキュリティ論点
• 生成AI セキュリティ リスク — 生成AI 全般のリスクと対策