[Claude Code #3] 権限管理まとめ：/permissionsとモード切り替え

Claude Codeの権限はallow・ask・denyルールと、denyを優先する評価順で動作します。/permissionsの使い方、Bashのワイルドカード構文、Shift+Tabによるモード切り替え、設定ファイルの優先順位まで整理します。

SeokWoo LeeシニアiOSソフトウェアエンジニア公開 2026年8月20日読了 7 分

[Claude Code #3] 権限管理まとめ：/permissionsとモード切り替えのカバー画像

AIコーディングツールを使っていると、あるジレンマが生じます。毎回許可を求めるのは面倒ですが、すべて許可するのもgit pushやrm -rfが怖いものです。

Claude Codeは、このバランスを権限ルールで解決します。黙って通すコマンド、必ず確認するコマンド、完全にブロックするコマンドを分けて扱います。

前回のClaude Code 第2回で扱ったプランモードも、この権限システム上で動作します。今回は全体像を整理します。

基本動作：何を確認するのか

公式権限ドキュメントによると、ツールの種類ごとにデフォルトルールが異なります。

ファイルの読み取りや検索などの読み取り専用ツールは、作業ディレクトリ内で承認なしに実行されます。

シェルコマンドは原則として承認が必要です。ただし、組み込みの読み取り専用コマンド群は例外です。

ファイルの変更は必ず確認されます。「再度確認しない」を選んでも、セッション終了時にリセットされます。一方、シェルコマンドの「再度確認しない」はリポジトリごとのルールとして保存され、次のセッションにも引き継がれます。

/permissionsでルールを確認する

セッションで/permissionsを入力すると、現在適用されているルール一覧が開きます。各ルールの出典となったsettings.jsonも表示されます。

ルールは3種類あります。

allow：確認なしで実行を許可
ask：実行を試みるたびに確認を要求
deny：実行そのものをブロック

評価順序がすべてを決める

ルールが重なった場合はどうなるでしょうか。順序はdeny → ask → allowで、最初に一致したルールが適用されます。

重要なのは、具体性によって順序は変わらないことです。Bash(aws *)をdenyに入れると、allowにBash(aws s3 ls)をどれだけ具体的に書いてもブロックされます。

denyルールに例外はありません。「awsはすべてブロックするが、s3の照会だけ許可する」といった構成はできないため、ルールを狭く分割する必要があります。

Claude Codeの権限ルールにおけるdeny・ask・allowの評価順序を示すフローチャート図 — ルールの評価順序です。denyから確認し、最初に一致した側が勝ちます。

もう1つ、denyに括弧なしでツール名だけを書くと（例：Bash）、そのツールはClaudeのコンテキストから完全に消えます。Bash(rm *)のように範囲を絞ったルールなら、ツールを残したまま該当する呼び出しだけをブロックできます。

ルール構文をざっと確認する

ルールは도구または도구(지정자)の形式です。Bashルールは*ワイルドカードに対応しており、位置も自由です。

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

コマンド末尾のアスタリスクの前に空白があると（Bash(ls *)）、単語境界が保たれます。ls -laには一致しますが、lsofには一致しません。空白のないBash(ls*)はlsofまで一致します。

git status && npm testのような複合コマンドは、各サブコマンドがルールに一致しなければ通りません。Bash(safe-cmd *)を許可しても、safe-cmd && other-cmdは通過できません。

ファイルパスのルールでは、Read(경로)とEdit(경로)だけが検査対象です。gitignoreのパターン構文を使います。Write(docs/**)のように書くと無視されるため、Edit(docs/**)と書く必要があります。

さらに、Read denyは同じパスの編集・書き込みも同時にブロックします。例にあるRead(./.env)だけで、読み取りと変更の両方が遮断されます。

権限モード：Shift+Tabで切り替える

ルールが精密な照準だとすれば、権限モードはセッション全体の方針です。

Shift+Tabを押すたびに、default（手動承認）→ acceptEdits（編集を自動承認）→ plan（プランモード）の順に切り替わります。プランモードは前回扱いました。

公式権限モードドキュメントによると、アカウントと料金プランの条件を満たすとautoモードも切り替え対象になります。分類器モデルが危険な操作だけを検出し、それ以外は確認なしで進めるモードです。この場合も、明示的なaskルールはプロンプトを強制します。

なお、公式発表に基づく情報によると、2026年8月14日からPro・Max・Teamプランの新規セッションではautoモードがデフォルトになります。

設定ファイル間の優先順位

ルールは複数階層のsettings.jsonに分けて保存できます。個人のグローバル設定（~/.claude/）、プロジェクト設定（.claude/settings.json）、ローカル専用設定、組織管理設定などです。

公式設定優先順位ドキュメントが示す原則は単純です。どの階層でもdenyに一致すれば、別の階層のallowで覆すことはできません。

プロジェクトのallowを個人設定のdenyでブロックすることも、その逆も可能です。組織管理設定のdenyはコマンドラインフラグでも解除できません。

ルールを守るのはモデルではなくツール

最後に、誤解しやすい点を1つ紹介します。

CLAUDE.mdに「git pushしないで」と書くのは依頼であって強制ではありません。モデルが指示を忘れたり誤判断したりすれば、突破される可能性があります。

権限ルールは異なります。Claude Codeクライアントがモデルの判断に関係なく機械的に適用します。必ずブロックしたいものはCLAUDE.mdではなくdenyルールに入れてください。

RULES NOT REQUESTSの文言と、付箋の依頼、鍵のかかった鉄門を対比したイラスト — 依頼はCLAUDE.mdに、強制はdenyルールに置きます。

まとめ

権限システムの骨格は3つです。allow・ask・denyルール、deny → ask → allowの評価順序、そしてセッション全体の方針を決める権限モードです。

よく使う安全なコマンドはallowで開いてプロンプト疲れを減らし、危険なコマンドはdenyで確実にブロックするのが基本戦略です。

次回は、会話を続けたり分岐させたりする/resume・/branch・/forkの3点セットを扱います。

出典と確認基準

Claude Code公式ドキュメント — Configure permissions（Anthropic、2026-08-13確認）
Claude Code公式ドキュメント — Choose a permission mode（Anthropic、2026-08-13確認）