Claude Codeのセキュリティと危険性｜auto mode・サンドボックス・--dangerously-skip-permissionsの安全な使い方【2026年9月最新】

Claude Codeは「付与した権限の範囲でしか動かない」設計で、権限モード・権限ルール・サンドボックスを正しく組み合わせれば、ローカル環境での実害は大きく減らせます。 ただし --dangerously-skip-permissions（bypassPermissions）をホストマシン上で使うのは公式が明確に非推奨で、2026年9月時点では対話型ターミナルの既定モードが「auto」に変わったため、「何もしなければ毎回確認される」という古い前提も通用しなくなっています。

この記事では、公式ドキュメント（code.claude.com/docs）・公式ブログ・GitHubの変更履歴をもとに、Claude Code v2.1.285（2026年9月29日公開）時点の仕様で安全な使い方を整理します。

この記事でわかること

• Claude Codeのセキュリティを支える4つのレイヤー（権限モード／権限ルール／サンドボックス／隔離環境）
• 2026年8〜9月の仕様変更（auto modeの既定化、サーバー側分類器、--restricted、危険な rm の2分自動拒否など）
• 権限モード6種類の違いと、用途別のおすすめ構成
• --dangerously-skip-permissions を使っても消える保護・残る保護の一覧
• rm -rf による全削除事故を防ぐ「重要パス（Critical paths）」の仕組み
• 個人・CI・組織向けにそのまま使える settings.json の例

こんな方に向けた記事です

• Claude Codeを使い始めたが、AIにコマンドを実行させることに不安があるエンジニア
• --dangerously-skip-permissions やauto modeの危険性・使いどころを正確に知りたい開発者
• 組織にClaude Codeを展開するIT・セキュリティ担当者

Claude Code自体の概要から知りたい方は、先にClaude Codeとは？できること・料金・使い方を読むと全体像をつかみやすくなります。

Claude Codeは危険か？現時点の安全性まとめ

Claude Codeは「設定次第で安全にも危険にもなるツール」です。 既定でも多くの安全装置が効いていますが、CLAUDE.mdやプロンプトで「危険なことはしないで」と書いても、それはセキュリティ境界になりません。公式ドキュメントも「権限ルールはモデルではなくClaude Code本体が強制するもの」と明記しています。

主なリスクと、現時点で有効な対策を一覧にすると次のとおりです。

一般的には、「確認プロンプトを増やす」よりも「壊されても困らない境界を先に作る」ほうが効果的です。Anthropicの公式ブログによると、ユーザーは権限プロンプトの97%を承認しており、テスト環境で人間が危険なコマンドを見抜けたのは13.6%にとどまりました。確認疲れで監視が形骸化するため、決定論的な境界（サンドボックス・denyルール・隔離環境）を優先するのが現在の基本方針です。

AIエージェント全般のリスクを俯瞰したい場合はAIエージェントのセキュリティ対策ガイド、エージェントという仕組みそのものについてはAIエージェントとはも参考になります。

2026年8〜9月の主な仕様変更

2026年8〜9月にかけて、Claude Codeのセキュリティ関連仕様は大きく変わりました。 春以前の情報をもとに書かれた解説記事は、既定モードやauto modeの対応範囲が古くなっている可能性が高いので注意してください。

なお claude -p（非対話モード）とAgent SDKは原則 default（Manual）で開始しますが、v2.1.285でサードパーティプロバイダ利用時やテレメトリ無効時は権限モード未設定だとautoで開始するよう変更されています。「-p なら必ず確認が入る」とは言い切れないため、CIでは --permission-mode を明示するのが安全です。

auto mode自体の詳細はClaude Code Auto modeとはでも解説しています。

Claude Codeのセキュリティの仕組み：4つのレイヤー

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

Claude Codeの安全性は、独立した4つのレイヤーの組み合わせで成り立っています。 どれか1つで完璧に守れるわけではなく、それぞれ守れる範囲が異なります。

このほか、設定なしで効いている保護として、公式ドキュメントでは次のものが挙げられています。

• 作業ディレクトリ境界：Manualモードでは起動したフォルダ配下にしか書き込めない
• curl / wget は既定で自動承認されない
• WebFetchは別のコンテキストウィンドウで処理され、取得したページの指示が本体セッションに混ざりにくい
• 初回のコードベース・新しいMCPサーバーは信頼確認が入る（-p 実行時は出ない）
• コマンドインジェクション検出：allow済みのコマンドでも不審なら確認を求める
• 認証情報はmacOSではキーチェーン、Windows／Linuxではファイル権限で保護

Anthropicは SOC 2 Type 2 や ISO 27001 の認証状況を Trust Center（trust.anthropic.com）で公開しています。ただし、これはAnthropic側の体制の話であり、ローカルで動くClaude Codeが何をしてよいかは利用者の設定で決まる点は押さえておきましょう。

権限モード6種類の違いと選び方

出典: Claude Code 公式ドキュメント「Permission modes」

権限モードは6種類あり、日常作業ならauto、機密作業ならManual（default）、CIならdontAsk、bypassPermissions は隔離環境専用と覚えておけば大きく外しません。 CLIでは Shift+Tab で auto → default → acceptEdits → plan の順に切り替わり、起動時は --permission-mode <モード名> で指定できます。

とくに見落としやすいのは、次のような挙動です。

• acceptEdits でも作業ディレクトリ内の rm は確認なしで通る。「編集だけ自動」と思い込むと危険です
• どのモードでもdenyルールは有効。一方、allowルールは bypassPermissions では意味を持ちません
• 明示的なaskルール、ユーザー入力を必要とするMCPツール、重要パスを狙う削除などは、bypassPermissions を含むすべてのモードで自動承認されません

開始モードの決まり方

起動時のモードは次の優先順で決まります。

1. --permission-mode フラグ、または --dangerously-skip-permissions
2. 設定ファイルの permissions.defaultMode
3. 組み込みの既定値（対話型ターミナル／VS Codeは auto、claude -p とAgent SDKは原則 default）

重要なのは、プロジェクトの .claude/settings.json や .claude/settings.local.json に "auto" や "bypassPermissions" を書いても効かない点です。クローンしたリポジトリ経由で危険なモードを強制されないための設計で、autoを既定にしたい場合は ~/.claude/settings.json（ユーザー設定）に書きます。

逆に、毎回確認してほしい場合は、ユーザー設定で次のようにManualへ固定できます。ステータスバーに ⏸ manual mode on と表示されれば反映されています。

{
  "permissions": {
    "defaultMode": "default"
  }
}

権限ルール（allow / ask / deny）の書き方と4つの落とし穴

権限ルールは「deny → ask → allow」の順で評価され、この順序は具体性に関係なく固定です。 広いdeny（Bash(aws *)）は狭いallow（Bash(aws s3 ls)）より優先されます。セッション中は /permissions で一覧・追加・削除ができます。

基本形は次のとおりです。

{
  "permissions": {
    "allow": [
      "Bash(npm run test)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

Bashルールは && || ; | 改行などで区切られたサブコマンドを個別に判定するため、Bash(safe-cmd *) を許可しても safe-cmd && other-cmd 全体が通るわけではありません。denyとaskはサブシェルやコマンド置換の中にも一致します。

落とし穴①：Bashルールは「セキュリティ境界ではない」

公式ドキュメント自身が、Bashの権限ルールはセキュリティ境界ではないと明言しています。コマンド文字列の一致で判定しているため、別の書き方をされると止められません。

確実に止めたい操作は、サンドボックスのネットワーク・ファイル制限か、PreToolUse Hook で判定するのが公式の推奨です。Hookの書き方はClaude Code Hooksの使い方、SkillsとHooksの役割分担はClaude Code SkillsとHooksの違いで解説しています。

URLを引数で縛るルール（Bash(curl http://github.com/ *)）も脆弱です。公式は「curl／wget をdeny＋WebFetch(domain:github.com) をallow＋サンドボックスのネットワーク許可リスト」という組み合わせを推奨しています。

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

timeout time nice nohup stdbuf やフラグなしの xargs などは自動で剥がされ、中のコマンドで判定されます。一方、npx docker exec devbox run mise exec direnv exec は剥がされません。たとえば Bash(devbox run *) をallowすると、devbox run rm -rf . まで許可してしまいます。ラッパー系のコマンドを丸ごとallowするのは避けましょう。

落とし穴③：Read denyはすべての読み取りを止めるわけではない

Read(./.env) のdenyは、組み込みのReadツールに加えて cat head sed などClaude Codeが認識できるコマンドやリダイレクトには効きます（同じパスへのEdit／Writeもブロック）。しかし、grep -r pattern . のようにファイル名を指定しない読み取りや、Python・Nodeスクリプト内部の open() までは止められません。OSレベルで封じるにはサンドボックスの併用が必要です。

また、Write(...) Glob(...) MultiEdit(...) のパスルールは参照されません（起動時に警告が出ます）。書き込みを制限したい場合は Edit(...) で書きます。

落とし穴④：パスの書き方がルールとサンドボックスで違う

たとえばReadルールで Read(/etc/passwd) と書くと、OSの /etc/passwd ではなくプロジェクト配下の etc/passwd を指します。OSの絶対パスを指定したいときは、ルールでは //etc/passwd、サンドボックスでは /etc/passwd と書き分けてください。

なお、プロジェクトの .claude/settings.json にあるallowルールは、ワークスペースの信頼ダイアログを承認するまで適用されません。

保護パスと重要パス：rm -rf全削除事故を止める仕組み

「AIに全部消された」という事故の多くは、現行の「重要パス（Critical paths）」の仕組みで止まる類型です。 Claude Codeには、設定ファイルの改ざんを防ぐ「保護パス」と、致命的な削除を防ぐ「重要パス」の2種類の安全装置があります。

保護パス（Protected paths）：設定ファイルの改ざんを防ぐ

次のパスへの書き込みは、bypassPermissions 以外のモードでは自動承認されません。allowルールに Edit(.claude/**) と書いても事前承認はできない仕様です。

モード別の扱いは、Manual／acceptEditsでは確認、autoでは分類器が判断、dontAskでは拒否、bypassPermissions では許可です。つまり --dangerously-skip-permissions を使うと .bashrc や .git/hooks も書き換えられる状態になります。

重要パス（Critical paths）：致命的な削除を止める

ファイルシステムのルート、/usr や /etc などルート直下、ホームディレクトリ、作業ディレクトリとその親などを対象にした rm rmdir は「重要パス」として扱われます。さらに、次のような変数やコマンド置換の展開次第でルートやホームを消しかねない書き方も検出対象です。

• rm -rf "$DIR"/*（$DIR が空ならルート直下を削除）
• rm -rf "$(pwd)"、D=$(pwd); rm -rf "$D"
• rm -rf ~/$(cmd)

sh -c や bash -c、サブシェルの中も検査されます。この安全装置はallowルールやPreToolUse Hookの「allow」でも承認できないサーキットブレーカーとして動きます。

v2.1.281以降は、確認に2分以内に応答しないと自動で拒否され、Claudeに代替手段を取るよう指示が返ります。無応答が3回続くと、以降は即拒否になります。スクリプトでどうしても変数を使う場合は、rm -rf "${DIR:?}"/* のように変数が未設定なら停止する書き方にしておくと引っかかりません。

Windowsでは、PowerShellの Remove-Item によるシステムパスやワイルドカード削除は全モードで拒否され、v2.1.283以降は cmd /c rd /s /q C:\Users のような削除も既定で拒否されます。

AIエージェントによるデータ削除事故の全体像はAIエージェントによるデータ削除事故まとめで整理しています。

サンドボックスの仕組みと設定方法

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

サンドボックスは、Bashコマンドとその子プロセスが触れられるファイルとネットワークをOSレベルで制限する機能です。 権限ルールでは止めきれない「別表記のコマンド」や「スクリプト内部のファイル操作」を物理的に封じられるのが強みで、Anthropicの社内利用では権限プロンプトが84%減ったと報告されています。

対応OS

ネイティブWindowsで隔離したい場合は、WSL2内でサンドボックスを使うか、コンテナ・VMを利用します。

有効化の方法

セッション内で /sandbox を実行すると、モード・例外・設定を選ぶ画面が開きます（選んだ内容は .claude/settings.local.json に保存）。設定ファイルで常時有効にする場合は次のように書きます。

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

サンドボックスには2つのモードがあります。

• auto-allow：サンドボックス内で動くコマンドは確認なしで実行。ただしdenyルール、重要パスの削除、Bash(git push *) のような内容指定のaskルールは引き続き有効
• regular permissions：サンドボックス内でも通常どおり確認

既定の範囲と注意点

既定で書き込めるのは作業ディレクトリ・ユーザー別の一時ディレクトリ・追加指定したディレクトリだけです。一方、読み取りは既定でマシン全体が対象で、公式ドキュメントも「~/.aws/credentials や ~/.ssh/ のような資格情報ファイルは読めてしまう」と明記しています。

資格情報を守るには、次のいずれかを設定します。

• sandbox.credentials：deny（ファイルの読み取りを禁止し環境変数も外す）か mask（コマンドにはダミー値を見せ、許可したホストへ送るときだけプロキシが本物に差し替える。v2.1.199以降。ファイルのmaskはLinux／WSL2のみ、macOSではブロック扱い）
• sandbox.filesystem.denyRead で ~/.ssh などを個別に読み取り禁止
• permissions.blockReadsOutsideWorkingDirectories（v2.1.257以降）で作業ディレクトリ外の読み取りを確認必須に

ネットワークはサンドボックス外のプロキシで制御され、既定で許可ドメインはゼロです。新しいドメインへの接続は初回に確認され、sandbox.network.allowedDomains で事前許可できます。

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "api.github.com"]
    },
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    }
  }
}

サンドボックスで守れないもの

サンドボックスは強力ですが、完全な隔離境界ではありません。公式ドキュメントで挙げられている制約は次のとおりです。

• MCPサーバーとコマンドHookはホスト上で制限なく動く。組み込みのRead／Editツールも権限システム側の管理
• プロキシは既定でTLSを検査しないため、github.com のような広いドメイン許可はドメインフロンティングなどで持ち出し経路になり得る
• allowUnixSockets で /var/run/docker.sock を許可すると、ホスト全体へのアクセスとほぼ同等になる
• Linuxの enableWeakerNestedSandbox やmacOSの allowAppleEvents は隔離を大きく弱める
• 依存パッケージがない場合、既定では警告を出してサンドボックスなしで実行してしまう（failIfUnavailable: true で起動失敗にできる）
• サンドボックスで失敗したコマンドを外で再実行する仕組み（dangerouslyDisableSandbox）があり、塞ぐには allowUnsandboxedCommands: false が必要
• docker や、gh terraform などGo製CLIは相性が悪く、excludedCommands で除外するとその分はサンドボックス外になる

また、どれだけ隔離してもプロンプトと読み込んだファイルはAnthropic API（または設定したプロバイダ）に送信される点は変わりません。機密データを扱うかどうかは、隔離とは別に判断が必要です。

隔離方式の比較

Claude Codeプロセス全体を囲いたい場合は、Bash sandbox以外の方式を選びます。

公式は「Bash sandbox単体では完全な無人実行には不十分」としており、無人実行ではdev container・コンテナ・VM・sandbox runtimeのいずれかを推奨しています。

--dangerously-skip-permissionsの危険性：消える保護・残る保護

--dangerously-skip-permissions は、権限プロンプトと安全チェックをまとめて外すフラグで、公式は「インターネットにつながっていないコンテナ・VM・dev containerなどの隔離環境でのみ使う」よう警告しています。 --permission-mode bypassPermissions と同じ動作です。

公式ドキュメントには次の警告があります。

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

bypassPermissions offers no protection against prompt injection or unintended actions.

消える保護・残る保護の一覧

このほか、次のような仕様になっています。

• 初回起動時に責任を受け入れる確認ダイアログが出る（受諾すると ~/.claude/settings.json に記録）
• プロジェクトの .claude/settings.json に defaultMode: "bypassPermissions" を書いても無効（Manualで起動）
• セッション途中からbypassに切り替えることはできない。--allow-dangerously-skip-permissions は切替候補に加えるだけで、開始はしない
• --restricted で起動したセッションではbypassは拒否される

セッション間メッセージの安全装置についてはClaude Codeのセッション間メッセージングで詳しく紹介しています。

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

「確認が面倒だから」という理由なら、多くの場合はbypassではなくautoモード＋サンドボックスで十分です。

組織・個人でbypassを封じる

次の設定で bypassPermissions を使えなくできます。managed settingsに置くのが一般的ですが、どのスコープでも機能するため、自分自身をロックアウトする目的でユーザー設定に書くこともできます。

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

Auto modeは--dangerously-skip-permissionsの安全な代替になるか

出典: Anthropic Engineering Blog

Auto modeは、確認の手間を大きく減らしつつ危険な操作だけを止める仕組みで、ホスト上で自動化したい場合は bypassPermissions よりはるかに安全な選択肢です。 ただし公式も「確認は減らすが安全を保証するものではない」と明記しており、本番インフラへの重要な変更は自分で確認するよう推奨しています。

仕組みと効果

別のモデル（分類器）が各アクションを実行前に審査し、「依頼内容を超えたエスカレーション」「把握していないインフラへの操作」「読み込んだ敵対的なコンテンツに由来すると思われる操作」をブロックします。現在はサーバー側の分類器が既定で、分類器の分のトークンは課金されません（自前の分類器にフォールバックした場合は課金され得るため、その際は通知が出ます）。

公式ブログ（2026年8月）で公表された数値は次のとおりです。

既定でブロックされる主な操作

• curl | bash などのダウンロード即実行
• 外部への機密データ送信、トンネル・リバースシェルの作成
• 本番デプロイ・マイグレーション、terraform destroy など
• クラウドストレージの大量削除、IAMやリポジトリ権限の付与
• force push、git reset --hard、git clean -fd、git stash drop
• セッション開始前から存在したファイルの不可逆な破壊
• シークレットマネージャ・DNS・TLS証明書の変更
• 人間が承認していないPRのマージ、CIの無効化、セキュリティテストの無効化
• --dangerously-skip-permissions や --no-sandbox を付けた自律ループの起動
• クラウドのメタデータエンドポイント（169.254.169.254）への資格情報要求
• 公開ペーストサービスへの投稿

既定で許可される主な操作

• 作業ディレクトリ内のローカル操作
• ロックファイルに記載された依存関係のインストール
• .env を読み、対応するAPIに認証情報を送ること
• 読み取り専用のHTTPリクエスト
• 作業中リポジトリのブランチへのpush（production や gh-pages などは除く）

会話で「pushしないで」と伝えた内容もブロックの判断材料になりますが、コンテキスト圧縮で消える可能性があります。確実に禁止したいことはdenyルールで書いておきましょう。

対応モデルと停止条件

現行の既定モデルである Claude Opus 5.5（claude-opus-5-5）は、この対応条件を満たしています。クラウドプロバイダ経由で使う場合は、そのプロバイダでOpus 5.5が提供されているかを各社の案内で確認してください。非対応モデルを選んでいる場合や、組織で無効化されている場合はManualで起動します。

分類器に3回連続、または合計20回ブロックされるとauto modeは一時停止し、通常の確認に戻ります（閾値は変更不可）。信頼できる社内インフラは autoMode.environment に登録でき、claude auto-mode defaults で既定ルールをJSONとして確認できます。

プロンプトインジェクションとの関係はClaude Code Auto modeとプロンプトインジェクションで掘り下げています。

用途別おすすめ構成と設定例

迷ったら「日常はauto＋サンドボックス」「機密作業はManual」「無人実行は隔離環境」の3パターンで考えるのが実務的です。 用途ごとの組み合わせを早見表にまとめます。

個人向け：auto＋サンドボックスの基本構成

~/.claude/settings.json に置く例です。Hookの形式は公式の hooks 設定に合わせています（deny-check.sh は自作のチェックスクリプトを想定）。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/gh/**)",
      "Bash(sudo *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "allow": [
      "Bash(npm run test)",
      "Bash(git status)",
      "Bash(git diff *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/.config/gh"]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "api.github.com"]
    }
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "~/.claude/scripts/deny-check.sh" }
        ]
      }
    ]
  }
}

それぞれの役割は次のとおりです。

CI向け：dontAskで許可したものだけ実行

CIでは既定モードの変化に左右されないよう、モードを明示します。

claude -p "テストを実行して失敗箇所を要約して" --permission-mode dontAsk

dontAsk では、allowルールに一致しない操作は確認されずに自動で拒否されます。GitHub Actionsでの運用例はClaude Code GitHub Actions連携ガイド、定期実行の組み方はClaude Code Routinesの使い方を参照してください。

--restricted：共有マシンでの評価用途

v2.1.248で追加された --restricted は、評価ハーネスが共有マシン上でClaude Codeを動かす用途を想定したオプションです。コマンド・コード実行系の組み込みツールとWebFetchを外し（--tools で個別指定した場合を除く）、ファイルツールを作業ディレクトリに限定し、managed settingsと --settings だけを読み込みます。bypassPermissionsやクラウドセッションの作成も拒否されます。

サブエージェント・MCPの注意点

• forkしたサブエージェントは親のplan・dontAskモードを引き継ぎます（v2.1.285以降）。設計はClaude Codeサブエージェントの使い方も参考にしてください
• Anthropicはディレクトリ掲載のコネクタを掲載基準でレビューしていますが、MCPサーバーのセキュリティ監査・管理はしていません（公式明記）。提供元を確認し、不要な権限を持つサーバーは入れないのが基本です。MCPの導入はClaude CodeのMCP連携ガイド、MCPそのものはMCPとはで解説しています

組織向け：managed settingsでポリシーを強制する

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

組織でClaude Codeを使うなら、managed settingsでサンドボックスとbypass禁止を強制するのが基本です。 managed settingsは最優先で適用され、どのレベルでdenyされたツールも、ほかのレベル（--allowedTools を含む）でallowし直すことはできません。

配布方法

クラウドセッションなど一部の実行環境は端末のMDMポリシーを読まないため、そうした環境も対象にするならserver-managed settingsが必要です。

推奨設定の例

公式が推奨するサンドボックス強制の構成に、bypass禁止などを加えた例です。auto modeを組織として使わない場合は disableAutoMode を追加します。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowManagedDomainsOnly": true
    }
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "forceRemoteSettingsRefresh": true
}

excludedCommands（サンドボックスから除外するコマンド）は開発者側で追記できるため、リストは狭く保ちましょう。v2.1.282以降は、allowUnsandboxedCommands: false のときプロジェクト・ローカル設定の excludedCommands は無視されます。

運用の監視には、OpenTelemetryのメトリクス、セッション中の設定変更を監査・ブロックできる ConfigChange Hook、claude doctor の「Organization policy」表示、/status が使えます。チーム導入の手順全体はClaude Codeのチーム導入ガイドにまとめています。

クラウドセッションという選択肢

Claude Code on the web（クラウドセッション）は、Anthropicが管理する隔離VMで動きます。GitHubの認証情報はVMに入らずプロキシ経由で扱われ、pushは作業ブランチのみ、操作は監査ログに残り、終了後は自動でクリーンアップされます。手元の端末や資格情報に触れさせたくない作業、信頼できないリポジトリの調査に向いています。なお、クラウドセッションでは設定ファイルの bypassPermissions / dontAsk 指定は無視されます。

過去の事故事例・脆弱性から学べること

公開されている事故や脆弱性の多くは、「境界を作っていなかった」か「古いバージョンを使っていた」ことが共通点です。 事実関係が確認できるものだけを整理します。

rm -rfによる削除事故

いずれも、現行の重要パスの仕組みで止められる類型です。ただし「最新版なら必ず防げる」とは言い切れないため、サンドボックスや隔離環境との併用が前提になります。

公開されている主な脆弱性

GitHubのSecurity Advisoriesでは、直近でも次のような報告と修正が公開されています。

こうした報告は修正版で対処されるため、Claude Codeは常に最新版に更新するのが最も手軽で効果の大きい対策です。組織では requiredMinimumVersion で古いバージョンを締め出せます。最新の一覧はGitHubのSecurity Advisoriesで確認できます。脆弱性を見つけた場合はHackerOneのプログラム経由で報告します。

ソースコード流出後に報告されたdenyルール回避の話題はClaude Codeソースコード流出の経緯、悪用事例はClaude Codeを悪用した恐喝キャンペーン、AIコーディング全般の論点はAIコーディングのセキュリティリスクでも取り上げています。

よくある誤解と実際の仕様

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

Claude Codeは、境界を先に設計できる人ほど安全かつ快適に使えるツールです。

安全に使いやすい人・使い方

• 個人開発でauto＋サンドボックスを使う人：確認疲れを減らしつつ、分類器とOSレベルの制限で二重に守れる
• 機密作業だけManualに切り替えられる人：Shift+Tab や --permission-mode で作業に応じてモードを変えられる
• 無人実行をコンテナ・VM・sandbox runtimeに閉じ込められる人：--dangerously-skip-permissions を使うなら必須の前提
• managed settingsを配布できる組織：サンドボックス強制・bypass禁止・MCP制限を一律に適用できる
• 常に最新版へ更新できる人・組織：脆弱性修正と安全装置の追加をすぐ取り込める

おすすめしない人・使い方

• 普段のPCで --dangerously-skip-permissions を常用する：保護パスもプロンプトインジェクション対策も外れる
• サンドボックスなしで ~/.ssh や ~/.aws がある業務PCを使う：資格情報を読まれる経路が残る
• 管理されていないMCPサーバーを次々に追加する：MCPはサンドボックスの外で動き、監査もされていない
• 本番インフラへの変更をauto modeに任せきりにする：公式も重要な変更は自分で確認するよう推奨している
• ネイティブWindowsで隔離なしに自動化する：サンドボックス非対応のため、WSL2・コンテナ・VMを使う
• ソースコードや業務データを外部に送れない環境：隔離してもモデルへの送信データは変わらないため、利用可否そのものを社内で判断する必要がある

他ツールとの違いも含めて検討したい場合は、CursorとClaude Codeの比較やClaude CodeとGitHub Copilotの比較、AIツール全体の選び方は生成AIツールおすすめ比較が参考になります。

料金とセキュリティ機能の関係

サンドボックス・権限ルール・ファイル配布によるmanaged settingsなどのセキュリティ機能は、プランによる追加料金なしで使えます。 違いが出るのは、claude.aiの管理コンソールから配布するserver-managed settings（Team／Enterpriseの組織機能）や、管理者によるauto modeの制御です。

料金は変更されることがあるため、最新情報は公式の料金ページで確認してください。プランの選び方はClaude Codeの料金プラン解説とClaudeの料金プランで詳しく比較しています。

FAQ

Q1. 今のClaude Codeは、起動するといきなりコマンドを実行しますか？

v2.1.283以降、対話型ターミナルとVS Codeでは権限モードを設定していなければautoで始まるため、多くの操作は確認なしで進みます。ただし分類器が危険な操作をブロックし、重要パスの削除などは確認が入ります。毎回確認したい場合は ~/.claude/settings.json で "defaultMode": "default" を指定すればManualで起動します。

Q2. --dangerously-skip-permissions とauto modeは何が違いますか？

auto modeは分類器が各操作を事前に審査し、force pushや本番デプロイ、外部への機密データ送信などを止めます。--dangerously-skip-permissions にはこの審査がなく、保護パスへの書き込みも許可され、プロンプトインジェクションへの防御もありません。ホスト上で自動化するならauto mode、完全な無人実行をするなら隔離環境内でのbypass、と使い分けるのが公式の考え方です。

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

組み込みのReadツールと、cat など認識できるコマンドによる読み取りは防げます。ただし、スクリプト内部で .env を開く処理やファイル名を指定しない検索までは止められません。サンドボックスを有効にし、sandbox.credentials や denyRead、ネットワークの許可リストを組み合わせると、読み取りと持ち出しの両方を抑えられます。

Q4. 誤って全削除されたとき、Claude Codeで元に戻せますか？

Claude Codeのチェックポイント機能はClaudeによるファイル編集の巻き戻しには使えますが、シェルコマンドで削除されたファイルまでは元に戻せないと考えておくべきです。実務的には、Gitへのこまめなコミット、OSのバックアップ（Time Machineなど）、そもそも重要なデータのない隔離環境で実行することが最も確実な備えになります。

Q5. Bedrockなどクラウド経由でもauto modeは使えますか？

現時点では使えます。v2.1.207以降は特別な環境変数なしでBedrock・Google Cloud Agent Platform・Foundryでもauto modeが利用でき、サーバー側分類器が使われる場合は分類器分のトークン課金もありません。ただし対応モデルはSonnet 5以降・Opus 4.7以降・Fableモデルに限られるため、古いモデルを指定している場合はManualで起動します。

Q6. 他人のリポジトリをcloneして開くだけで危険はありますか？

リスクはあります。過去にはリポジトリ内の設定ファイルやGit worktreeの偽装で信頼ダイアログを回避できる脆弱性が報告され、修正されています。信頼できないリポジトリは、最新版のClaude Codeを使ったうえで、専用VMやクラウドセッションで開くのが安全です。なお、プロジェクト設定に書かれたauto／bypassのモード指定は無視され、allowルールも信頼ダイアログの承認までは適用されません。

Q7. 社内でClaude Codeを禁止すべきか迷っています。判断の目安はありますか？

一般的には、「コードや業務データを外部のAPIに送ってよいか」と「端末にポリシーを強制できるか」の2点で判断します。前者がNGなら隔離しても解決しないため利用範囲を限定する必要があり、後者ができるならmanaged settingsでサンドボックス強制・bypass禁止・MCP制限を配布したうえで段階的に展開するのが現実的です。生成AI活用の全体方針は生成AIとはも参考にしてください。

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

Claude Codeの安全性は、「プロンプトでお願いする」のではなく「壊されても困らない境界を先に作る」ことで決まります。 今日から確認できる項目は次のとおりです。

• Claude Codeを最新版に更新している（組織なら requiredMinimumVersion を設定）
• 既定モードがautoになっていることを理解し、機密作業ではManualに切り替えている
• .env・~/.ssh・~/.aws・~/.config/gh をdenyルールで読み取り禁止にしている
• /sandbox を有効にし、failIfUnavailable と allowUnsandboxedCommands: false を設定している
• サンドボックスの既定読み取りがマシン全体である点を踏まえ、sandbox.credentials か denyRead で資格情報を守っている
• npx docker exec devbox run などのラッパーを丸ごとallowしていない
• 確実に止めたい操作はBashルールだけに頼らず、サンドボックスかPreToolUse Hookで制御している
• --dangerously-skip-permissions はコンテナ・VM・sandbox runtime内で非rootユーザーとしてのみ使っている
• CIでは --permission-mode を明示している
• MCPサーバーは提供元を確認したものだけに限定している
• 組織ではmanaged settingsでbypass禁止・サンドボックス強制を配布している

設定を一度整えておけば、確認の手間を減らしながら安心してClaude Codeに作業を任せられます。まずは /sandbox の有効化と機密ファイルのdenyから始めてみてください。

関連記事

• Claude Codeとは？できること・料金・使い方
• Claude Codeの使い方ガイド
• Claude Code Auto modeとは
• Claude Code Hooksの使い方
• Claude Codeのチーム導入ガイド
• Claude CodeのMCP連携ガイド
• AIエージェントのセキュリティ対策ガイド
• AIエージェントによるデータ削除事故まとめ
• AIエージェントとは
• 生成AIツールおすすめ比較