Claude Codeの権限設定｜allow/deny/askとモードの設定手順

先に結論: Claude Codeの権限設定は、allow/deny/askの3種類のルールと、default(Manual)からauto・bypassPermissionsまで6種類のパーミッションモードで、確認プロンプトの範囲を調整する仕組みです。

Claude Codeを使っていると、ファイルの編集やコマンド実行のたびに「実行してよいですか?」と確認プロンプトが表示されます。事故を防ぐための権限設定の仕組みですが、頻発すると作業のテンポが落ちます。本記事では確認プロンプトの仕組みを理解したうえで、allow/deny/askの3種類のルールと、auto・dontAskを含む最新のパーミッションモードを使い分け、安全性を保ちながら確認を減らす権限設定の手順を解説します。設定ファイル全体の書き方は「Claude Code設定完全ガイド」もあわせてご覧ください。

この記事の要点

• Claude Codeは階層型の権限システムを採用しており、Bashコマンド実行やファイル編集は原則として確認が必要です。
• 権限ルールはallow/deny/askの3種類で、評価順序は「deny→ask→allow」です。
• パーミッションモードはdefault(Manual)/acceptEdits/plan/auto/dontAsk/bypassPermissionsの6種類で、Shift+Tabで切り替えられます。
• autoモードは分類器モデルによる安全性チェック付きでほぼすべての操作を自動承認し、2026年8月14日からPro/Max/Teamプランの新規セッションで既定モードになりました。
• bypassPermissionsでもrm -rf /やrm -rf ~などファイルシステムのルート・ホームディレクトリを狙った削除は、モデルの誤りに備えた保護機能(サーキットブレーカー)により確認を求められます。

前提・動作環境

この記事はターミナル版のClaude Code(2026年8月時点の最新版)を前提にしています。設定はsettings.jsonというJSONファイルに記述し、ユーザー全体・プロジェクト共有・個人ローカルの3つのスコープに分けて保存できます。あらかじめログインとインストールを済ませた状態から読み進めてください。

claude --version

権限設定の基本手順

Claude Codeの権限設定は、次の5ステップで進めると迷いません。

1. 現在のルールを確認する: セッション中に/permissionsを実行し、現在有効なallow/deny/askルールと、どのsettings.jsonに由来するかを確認します。
2. 保存先のスコープを決める: 全プロジェクト共通にしたいなら~/.claude/settings.json、プロジェクトメンバー全員に共有したいなら.claude/settings.json、自分だけのローカル設定(Git管理対象外が基本)なら.claude/settings.local.jsonを選びます。
3. allow/deny/askルールを書く: ToolまたはTool(specifier)形式で、自動許可・拒否・確認が必要なコマンドやツールを指定します(書き方は次章で解説します)。
4. パーミッションモードを選ぶ: default(Manual)・acceptEdits・plan・auto・dontAsk・bypassPermissionsから、作業の機密性や自律性のニーズに合ったモードを選びます。
5. 動作を確認する: 実際にコマンドを実行し、意図どおりに自動承認・確認・拒否されるか確かめます。想定外の挙動があれば、deny→ask→allowという評価順序を疑ってルールを見直しましょう。

権限確認プロンプトが出る仕組み

Claude Codeはツールの種類ごとに承認の厳しさを変える「階層型の権限システム」を採用しています。ファイル読み取りやGrepなどの読み取り系はワーキングディレクトリ内であれば確認不要ですが、Bashコマンドの実行やファイルの編集・書き込みは原則として確認が必要です。

確認時に「Yes, don’t ask again」を選ぶと、Bashコマンドの承認はリポジトリ単位で永続的に保存され、以降も自動的に許可されます。一方、ファイル編集の承認はセッション終了までしか有効ではありません。ルールはClaude Code自身が強制するもので、CLAUDE.mdに「勝手に実行してよい」と書いても変わりません。権限の変更は/permissionsコマンドやルール設定、パーミッションモード、PreToolUseフックで行います。フックの詳細は「hooks入門」で解説しています。

permission rulesの書き方: allow/deny/askと記述パターン

権限ルールはallow・deny・askの3つのリストで構成され、ToolまたはTool(specifier)という形式で書きます。評価順序は「deny→ask→allow」で、最初に一致したルールが優先されます。たとえばBash(git push *)という広いdenyルールがあれば、より狭いallowルールが存在してもブロックされます。

Bashコマンドは*によるワイルドカードパターンをサポートしており、コマンドの先頭・中間・末尾のどこにでも配置できます。次の例はnpm run系とgit commit系のコマンドを許可しつつ、git pushだけを拒否する設定です。

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)", "Bash(git status)"],
    "deny": ["Bash(git push *)"]
  }
}

このJSONは~/.claude/settings.json(ユーザー全体)や.claude/settings.json(プロジェクト共有)、.claude/settings.local.json(個人ローカル、Git管理対象外が基本)に記述します。ファイル全体の構造は「settings.json解説」で説明しています。Bash(ls *)のようにスペース付きの*は単語境界を意識した一致になり、ls -laにはマッチしますがlsofにはマッチしません。

パーミッションモード一覧: default/acceptEdits/plan/auto/dontAsk/bypassPermissionsの違い

2026年8月時点でClaude Codeには6種類のパーミッションモードがあり、確認なしで実行される範囲がそれぞれ異なります。

defaultはCLIやヘルプ上では「Manual」と表示されますが、設定ファイル上の値は引き続きdefaultです。モードはセッション中にShift+Tabキーでdefault → acceptEdits → planの順に切り替えられ、autoやbypassPermissionsを有効化している場合はそのサイクルの末尾に追加されます。起動時に指定する場合は--permission-modeフラグを使います。

claude --permission-mode plan

autoモードは、ユーザーのリクエストから逸脱する操作や見覚えのないインフラを対象にした操作を分類器がブロックする仕組みで、2026年8月14日からPro・Max・Teamプランの新規セッションで既定モードになっています(独自の既定値を設定済みならそちらが優先され、一回限りの切り替え確認プロンプトを承認した場合のみ変わります)。dontAskとbypassPermissionsはShift+Tabの通常サイクルには含まれず、--permission-mode dontAskや--permission-mode bypassPermissions(--dangerously-skip-permissionsと同義)で明示的に起動したときだけ使えます。bypassPermissionsは危険性が高いため、後述の注意点を必ず確認してから使ってください。デフォルトのモードはsettings.jsonのpermissions.defaultModeでも指定でき、Plan Modeの詳しい使い方は「Plan Mode」で解説しています。

分類器は既定で/modelの選択とは独立してClaude Sonnet 5モデル上で動作します(セッションのモデルがSonnet 4.6の場合はそのモデルを、Fable 5の場合はOpus系モデルを使用)。Anthropic公式ブログによると、1,053名の有償テスターを対象にした検証で、危険なコマンドを人間によるレビューでは13.6%しか検知できなかったのに対し、分類器は89%を検知してブロックしたと報告されています。また公式ドキュメントでは、Pro・Max・Teamプランでの分類器の呼び出しはユーザーのトークン消費としてカウントされない一方、Enterprise・API経由のアカウントでは分類器の呼び出しも通常のトークン利用としてカウントされると説明されています。

2026年8月7日付のAnthropic公式ブログ「Auto mode is now the default in Claude Code for Pro, Max, and Team plans」で、この既定化が正式に発表されました(2026年8月時点)。対象はPro・Max・Teamプランの新規セッションで、予定どおり2026年8月14日に適用が開始されました(公式ドキュメントの記載も確認済み・2026年8月14日時点)。組織でautoモード自体を使わせたくない場合は、管理者が管理対象設定でpermissions.disableAutoModeを"disable"にするとShift+Tabのサイクルからも除外できます。一方でEnterprise・Claude API・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由のアカウントでは、auto modeは当面オプトイン(手動選択)のままとされ、同ブログは「1か月以内をめどに既定化する予定」と案内しています。あわせて、ユーザーの依頼から外れた範囲の操作やコード・シークレットの外部送信のような操作を常にブロックする「hard deny」ルール(管理者によるカスタマイズも可能)と、外部コンテンツ取得時にプロンプトインジェクションの兆候をAPI側で検知しClaudeの文脈に警告を挿入する仕組みも、同時に導入されたと発表されています。

bypassPermissionsのサーキットブレーカー

bypassPermissionsはほぼすべての確認をスキップしますが、rm -rf /やrm -rf ~のようにファイルシステムのルートやホームディレクトリ全体を狙う削除コマンドだけは、モデルの誤りに備えた保護機能(サーキットブレーカー)により実行前に確認を求められます。$(rm -rf ~)のようなコマンド置換・プロセス置換に埋め込まれた場合も働く保護です。ただしプロンプトインジェクションや意図しない操作全般を防ぐものではないため、公式ドキュメントも隔離されたコンテナ・VM専用の利用を強く推奨しています。Linux・macOSではroot権限・sudo実行時にこのモードでの起動自体が拒否されます。

/permissionsコマンドで確認・追加する

セッション中に現在の権限ルールを確認したり、新しいルールを追加したりするには/permissionsコマンドを使います。

/permissions

実行すると、現在有効なallow/deny/askルールと、それぞれがどのsettings.jsonに由来するかが一覧表示されます。この画面からルールを直接追加・削除できるので、設定ファイルの手動編集が面倒なときはこちらが手軽です。

安全に確認を減らすおすすめ設定

確認プロンプトをむやみに減らすと事故のリスクが上がりますが、読み取り系の安全なコマンドまで毎回確認するのは非効率です。おすすめは次のような段階的な設定です。

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(git diff *)", "Read"],
    "ask": ["Bash(git push *)"],
    "deny": ["Bash(rm -rf *)"]
  }
}

テストやビルド、差分確認など「実行しても取り返しがつく」コマンドはallowに、git pushのようにリモートへ影響する操作はaskで一呼吸置く、削除系の破壊的コマンドはdenyで明示的にブロックする、という考え方です。bypassPermissionsは隔離環境専用のモードで、通常の開発マシンで常用すると誤削除や意図しない変更のリスクが大きくなります。確認そのものを減らしたい場合は、bypassPermissionsではなく分類器による安全性チェックが働くautoモードを検討してください。すべてのプロンプトを毎回「はい」で許可し続ける運用も、破壊的なコマンドを見落とすリスクがあるため避けてください。

つまずきポイント/よくあるエラー

• allowルールを書いたのに毎回確認される: denyやaskルールが同じコマンドに一致していないか確認してください。評価順序はdeny→ask→allowなので、広いdenyルールがあると狭いallowルールは効きません。
• Bash(ls *)が特定のコマンドにマッチしない: *前のスペース有無で挙動が変わります。単語境界を意識してパターンを書いてください。
• 複合コマンドが想定通り許可されない: git status && npm testのように&&や|でつないだコマンドは、サブコマンドごとに個別のルールが必要です。
• .claudeディレクトリへの書き込みが常に確認される: 「保護パス」と呼ばれる仕組みで、bypassPermissions以外ではallowルールを書いても自動承認されません。設定を誤って壊さないための安全策です。

よくある質問

allowリストに入れたコマンドは他のプロジェクトでも有効ですか?

保存先のファイルによります。~/.claude/settings.jsonなら全プロジェクト共通、.claude/settings.jsonはそのプロジェクトの全員に共有、.claude/settings.local.jsonは自分だけのローカル設定です。

bypassPermissionsモードはどんなときに使えばよいですか?

誤動作しても実害が出ない、インターネットに接続していないコンテナやVMなどの隔離環境に限定して使うのが安全です。通常の開発マシンでは使わないことをおすすめします。rm -rf /のようなルート・ホームディレクトリを狙う削除だけは、このモードでもサーキットブレーカーにより確認が挟まります。

autoモードとdontAskモードはどう違いますか?

autoは分類器が逐一チェックしながらほぼすべての操作を自動承認する、確認疲れを減らすためのモードです。一方dontAskはallowルールで許可した操作と読み取り専用コマンドしか実行せず、それ以外は自動拒否するため、CIのような無人環境向けのより厳格なモードです。

denyルールとaskルールはどう使い分けますか?

絶対に実行させたくない破壊的な操作(強制削除など)にはdenyを、実行してもよいが人間の確認を挟みたい操作(pushやデプロイなど)にはaskを使うのが基本の使い分けです。

ハブネコのひとこと

bypassPermissionsでもrm -rf /のようなコマンドはサーキットブレーカーで止まると知って少し安心しましたが、それでも隔離環境専用という原則までは変わりません。

まとめ

Claude Codeの権限設定は、ツールごとに確認の厳しさが変わる階層型の仕組みと、allow/deny/askの3種類のルール、default(Manual)からauto・dontAsk・bypassPermissionsまでの6種類のパーミッションモードで構成されています。取り返しのつくコマンドはallowに、リモートへ影響する操作はaskで一呼吸置き、破壊的なコマンドはdenyでブロックする段階的な設定が、確認疲れと事故防止を両立させるコツです。bypassPermissionsでもrm -rf /のような破壊的削除はサーキットブレーカーで確認が挟まりますが、それでも隔離環境専用の利用が原則である点は変わりません。設定ファイル全体は「Claude Code設定完全ガイド」と「settings.json解説」を、高度な自動化には「hooks入門」をあわせて参考にしてください。Sandboxやgit、rewindと組み合わせた事故防止の全体像は「誤削除を防ぐ安全運用ガイド」で整理しています。