AI Hub

Claude Code権限管理入門｜allow/deny設定と確認を減らす方法

公開:

#権限 #設定

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

前提・動作環境

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

claude --version

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

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/bypassPermissionsの違い

Claude Codeには確認の頻度が異なる複数のパーミッションモードがあります。

モードはセッション中にShift+Tabキーでdefault → acceptEdits → planの順に切り替えられます。起動時に指定する場合は--permission-modeフラグを使います。

claude --permission-mode plan

bypassPermissionsはShift+Tabの通常サイクルには含まれず、--permission-mode bypassPermissionsまたは--dangerously-skip-permissionsフラグ付きで起動したときだけサイクルに現れます。デフォルトのモードはsettings.jsonのpermissions.defaultMode(例: "acceptEdits")でも指定できます。

/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は隔離環境専用のモードで、通常の開発マシンで常用すると誤削除や意図しない変更のリスクが大きくなります。すべてのプロンプトを毎回「はい」で許可し続ける運用も、破壊的なコマンドを見落とすリスクがあるため避けてください。

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

よくある質問

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

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

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

インターネットに接続していないコンテナやVMなど、誤動作しても実害が出ない隔離環境に限定して使うのが安全です。通常の開発マシンでは使わないことをおすすめします。

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

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

まとめ

Claude Codeの権限管理は、ツールごとに確認の厳しさが変わる階層型の仕組みと、allow/deny/askの3種類のルール、defaultからbypassPermissionsまでのパーミッションモードで構成されています。取り返しのつくコマンドはallowに、リモートへ影響する操作はaskで一呼吸置き、破壊的なコマンドはdenyでブロックする段階的な設定が、確認疲れと事故防止を両立させるコツです。設定ファイル全体は「Claude Code設定完全ガイド」と「settings.json解説」を、高度な自動化には「hooks入門」をあわせて参考にしてください。