Claude Codeの権限設定｜allow・ask・denyの配分と設定例

Claude Codeの権限設定を曖昧にすると、危険な操作が自動で進むか、安全な操作にまで毎回確認を求められます。公式ドキュメントと自社のsettings.json実例で、危険操作だけを止める配分を示します。

01結論：Claude Codeの権限設定は、allow・ask・denyの3列に操作を仕分けて配分する

設定は .claude/settings.json の permissions フィールドに書きます。deny・ask・allowの3配列と defaultMode を持ちます（出典: Claude Code公式ドキュメント）。

評価順序はdeny→ask→allowで固定で、最初に一致したルールが結果を決めます。ルールの細かさ（特異度）は順位に影響しません（出典: Claude Code公式ドキュメント）。例えば Bash(aws *) がdenyなら、狭い Bash(aws s3 ls) のallowがあってもブロックされます。

02権限設定を始める前に要る前提（バージョンと設定ファイルの場所）

検証環境はClaude Code公式ドキュメント（code.claude.com/docs、2026-07-28時点の記載）です。設定ファイルの場所は5段階あり、上位が下位を上書きします（出典: 同）。

deny側はどの段でも積み上がり、1段でも拒否すればブロックされます。ユーザー設定で許可済みでも、プロジェクト設定が拒否すればそのプロジェクトは拒否のままです（出典: 同）。

ルールに一致しなかったときの挙動を決めるのが defaultMode で、6種類あります。

autoモードは3回連続、または合計20回ブロックされると通常のプロンプトに戻り、この閾値は変更できません（出典: Claude Code公式ドキュメント）。defaultModeはルールに一致しなかった残りの既定値です。

03denyへ先に置く危険操作の決め方｜権限設定の土台になる4分類

権限設定の土台はルールを書く前の分類で、WEBMARKSは可逆性（元に戻せるか）と影響範囲（外部やシステムに届くか）の2軸で仕分けています。

取り返しがつかず外部やシステムにも届く操作はdenyに置きます。実際の.claude/settings.jsonの抜粋です（2026-07-28時点）。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf*)",
      "Bash(sudo rm*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Read(**/.env)",
      "Read(**/id_rsa*)",
      "Edit(02-company_knowledge/.../03_定量実績.md)",
      "Write(02-company_knowledge/.../03_定量実績.md)"
    ]
  }
}

最後の2行は事業の公式数値を1ファイルに集約し、AIによる書き換え自体を拒否する例で、正本運用を権限設定でも二重に固定しています。

取り返しはつくが外部に届く操作（git push・配信系ツールの送信）はaskに、両方ローカルで軽微な操作はallowです。

読み取り専用コマンドの一部はClaude Code側に組み込み済みで、モードを問わず確認なしに実行されます（出典: Claude Code公式ドキュメント）。対象はls cat grep findなど14種と、読み取り専用のgitです。

取り返しがつかずローカルだけの象限は判断に迷いますが、大量ファイルの一括削除などはaskへ倒すのが安全側です。

04settings.jsonへallow・ask・denyを書く権限設定の実装手順

ルールの書式は Tool または Tool(指定子) です。ツール名だけなら全呼び出しに一致し、括弧内の指定子で絞り込めます（出典: Claude Code公式ドキュメント）。

ワイルドカードは * の前の空白の有無で挙動が変わります。Bash(ls *) は ls -la に一致しますが lsof には一致しません。空白のない Bash(ls*) はどちらにも一致します（出典: Claude Code公式ドキュメント）。

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

複合コマンドは && || ; | ごとに分解され、個別に判定されます。Bash(safe-cmd *) を許可しても other-cmd 側までは許可されません。複合コマンドを承認すると、サブコマンドごとに最大5個までルールが自動保存されます（出典: Claude Code公式ドキュメント）。

ワイルドカードだけでは防ぎきれないパターンもあり、WEBMARKSはsettings.jsonのルールに加えPreToolUseフックで防御を重ねています。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/python3 -I -B '<Vaultルート>/.claude/hooks/bash-guard.py'"
          }
        ]
      }
    ]
  }
}

このフックは危険と判定したコマンドを終了コード2で止めます。標準エラーの内容がそのままモデルへ返り、ツール呼び出し自体は実行されません（出典: Claude Code公式ドキュメント）。実際にgit pushを検出したときの応答は次のとおりです。

⛔ bash-guard: `git push`はwrapper・間接実行・--no-verifyを含めて人間専権です。AIはローカルcommitまでで停止してください。

公式ドキュメントも、Bash向けワイルドカードだけのURL制限は壊れやすいと明記しています。Bash(curl http://github.com/ *) のつもりでも素通りする書き方が5通りあります。オプションを前に置く・httpsにするなどです（出典: Claude Code公式ドキュメント）。URL制限が要るなら、Bash経由のネットワークコマンドはdenyし、WebFetch(domain:...)かPreToolUseフックで検証します。

05権限ルールでつまずきやすい3つの落とし穴

落とし穴1：素のBashをdenyに書いて全部止めてしまう。rm だけを止めたいのに "deny": ["Bash"] と書くと、ツール名だけの記法としてBashツールそのものがモデルの視界から丸ごと消えます。狭めたいときは Bash(rm *) のように指定子つきで書きます（出典: Claude Code公式ドキュメント）。

落とし穴2：狭いallowがdenyの例外になると思い込む。ファイアウォールの例外設定のように、広いdenyの中に狭いallowを混ぜれば通ると考えがちです。評価順序はdeny→ask→allowで固定で、denyが先に一致した時点で後段のallowは評価されません（出典: Claude Code公式ドキュメント）。

落とし穴3：プロジェクトのallowルールが最初のセッションで効かない。新しいプロジェクトの.claude/settings.jsonにallowルールを書いても、ワークスペース信頼ダイアログを承認するまで適用されません。ルールは読み込まれても権限は付与されない状態です（出典: Claude Code公式ドキュメント）。「書いたのに動かない」と感じたら、まずこのダイアログの承認を確認します。

06/permissionsでClaude Codeの権限設定を動作確認する

設定を書いたら、動かして確かめます。合否の基準は次の4項目です。

1. /permissions を実行する。入力不要で、各ルールと出所のsettings.jsonの一覧が出ます。期待：deny・ask・allowそれぞれに書いたルールが表示される（出典: Claude Code公式ドキュメント）。
2. denyに置いた操作を実際に呼び出させる。入力例：rm -rfを含む操作。期待：実行されず、ブロックの理由が表示される。
3. askに置いた操作を呼び出させる。入力例：git push。期待：毎回、確認ダイアログが出る。
4. allowに置いた操作を呼び出させる。入力例：許可した読み取り専用コマンド。期待：確認なしで完了する。

4項目とも期待どおりなら合格です。ズレたらワイルドカード（空白の有無、*の位置）と評価順序を見直します。askのはずが確認なしで進んだ場合は、広いallowルールが先に無いか/permissionsの一覧で確認します。

07FAQ