denyルールを、
実運用で育てる。

01 / LAYERS

allow・ask・denyは、信頼度ではなく「戻せるか」で分ける

3つの分類は、AIをどれだけ信用しているかで決めるものではありません。その操作が失敗したときに元へ戻せるかどうかで決めます。

• allow＝読むだけ・調べるだけ。実行しても状態が変わらない操作。
• ask＝実行してよいが、意図が変わる操作。公開、送信、push、お金が動くコードの編集。
• deny＝一度通ると戻せない操作。破壊的なgit操作、一括削除、秘密ファイルの読み取り。

迷ったらaskに置きます。allowへ入れる基準を「読み取り専用かどうか」だけに固定しておくと、後から判断が揺れません。

02 / ORDER

評価順はdeny→ask→allow。denyに例外は書けない

Claude Codeの公式ドキュメントには、次のように書かれています。

Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order.

Claude Code Docs / Configure permissions

重要なのは後半です。ルールの細かさは順序を変えません。つまり広いdenyを1件書くと、それより細かいallowを何件足しても通りません。公式も、denyルールは許可の例外を持てないと明記しています。

A broad deny rule like `Bash(aws *)` blocks every matching call, including calls that also match a narrower allow rule like `Bash(aws s3 ls)`, so a deny rule can't carry allowlist exceptions.

Claude Code Docs / Configure permissions

実務上の意味は単純です。denyは「例外を作らないと決めた対象」にだけ使います。基本は禁止だがこの場合だけ許したい、と思ったなら、それはdenyではなくaskの仕事です。

設定ファイルが複数の階層にあっても順序は変わりません。ユーザー設定のdenyは、プロジェクト設定のallowより先に評価されると公式は説明しています。厳しい側が常に勝つ、と覚えておけば十分です。

03 / PROSE VS CONFIG

CLAUDE.mdに書いた禁止と、設定のdenyは別のもの

CLAUDE.mdやAGENTS.mdに「これはやらないで」と書くのは、モデルへの指示です。読んだうえで従う可能性は高いですが、実行を止める仕組みではありません。

一方、permissionsのdenyは、ツールが呼ばれる前に評価される仕組み側の制御です。公式ドキュメントは、フックの判断ですらこれを迂回できないと書いています。

Hook decisions don't bypass permission rules. Claude Code evaluates deny and ask rules regardless of what a PreToolUse hook returns

Claude Code Docs / Configure permissions

なので、順序はこうなります。まず文章のルールで意図と理由を書く。破られたとき、あるいは破られたら困ると気づいた時点で、同じ内容を設定へ落とす。文章と設定は二者択一ではなく、意図の層と強制の層です。

絶対にやらせないと決めた対象は、両方に書く価値があります。設定だけだと、なぜその行があるのかが半年後に読めません。文章だけだと、止まりません。

04 / GROWTH

ルールを1件足す判断基準

最初から完成した権限設定は書けません。増えるきっかけは、だいたい次の3つです。

• 同じ確認を2回した → askに固定する。毎回聞かれて面倒だからallowにするのではなく、聞かれる回数が多い操作ほど重要だと解釈します。
• 1回でも通ると戻せないと気づいた → denyに入れる。まだ事故が起きていなくても入れます。
• 止まるたびに作業が切れる読み取り操作 → allowに入れる。ただし読み取り専用に限ります。

2026年7月時点で、私の設定はdenyが56件、askが37件、allowが61件です。最初から56件書いたわけではなく、迷った操作を1件ずつ足した結果です。件数そのものに意味はありませんが、たまったルールの偏りには意味がありました。

denyに入っているものの大半は、秘密ファイルの読み取りと、取り返しのつかない破壊的な操作（強制push、履歴やリモート設定の書き換え、一括削除）です。askに入っているものの大半は、外部への送信と、お金や公開が動くコードの編集です。同じ「危ない」でも、戻せないものはdenyへ、戻せるが確認したいものはaskへ、と自然に分かれていました。最初に決めた分類の基準が、そのまま形になっています。

逆に、長く増えも減りもしていないルールは、見直す候補です。必要がなかったか、書き方が間違っていて一度も一致していないかのどちらかです。

05 / EXAMPLE

設定例と、効かない書き方

最低ラインはこの形になります。パスや対象は自分の環境に合わせて置き換えてください。

{
  "permissions": {
    "deny": [
      "Bash(git reset --hard:*)",
      "Bash(git push --force:*)",
      "Bash(git clean:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Edit(./billing/**)",
      "Bash(npm test)",
      "WebFetch"
    ],
    "allow": [
      "Read(./src/**)",
      "Bash(git status)",
      "Bash(git diff)"
    ]
  }
}

allowに入れているのは、状態を変えず外部にも送らないと判断できる操作だけです。テストの実行はここに入れていません。npm testはpackage.jsonのscriptsに書かれたコマンドをそのままシェルへ渡して実行するもので、中身は各プロジェクトが自由に決められます。名前が同じでも、やることが読み取り専用とは限らないため、askに置いています。

ここで踏みやすい罠が2つあります。

1つ目はWrite()です。ファイルの書き換えを止めたつもりでWrite(パス)と書いても、ファイル権限のチェックには一致しません。Claude Codeは起動時に次の警告を出します。

Permission deny rule (.claude/settings.json): Write(docs/**) is not matched by file permission checks — only Edit(path) rules are. Use Edit(docs/**) instead (Edit rules cover all file-editing tools).

Claude Code 起動時の警告 / Configure permissions

編集を止めたいならEdit(パス)です。Editのルールがファイル編集系のツールをまとめて覆います。

2つ目はURL単位のdenyです。コマンド文字列でURLを弾こうとしても、プロトコル違い、リダイレクト、変数展開、余分な空白で簡単に外れると公式ドキュメントは説明しています。URLで絞りたいなら、curlやwget自体をdenyしたうえで、許可するドメインだけをWebFetchのドメイン指定で通すほうが確実です。

06 / LIMITS

この設定でも保証できないこと

いちばん重要な制約です。Read()やEdit()のルールが直接制御しているのは、Claude Codeの組み込みファイルツールです。ファイルを読む手段はそれだけではないので、Read(./.env)をdenyしても、あらゆる読み取り経路が塞がるわけではありません。公式ドキュメントの警告はこう書かれています。

Read and Edit deny rules apply to Claude's built-in file tools and to file commands Claude Code recognizes in Bash, such as `cat`, `head`, `tail`, and `sed`. They don't apply to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself. For OS-level enforcement that blocks all processes from accessing a path, enable the sandbox.

Claude Code Docs / Configure permissions

Bashについては「Claude Codeが認識できるファイルコマンド」に限って効く、という書き方になっています。つまり、cat .envのような分かりやすい形は拾われても、ファイルを自分で開くPythonやNodeのスクリプトを書いて実行すれば、その経路は権限ルールの外側です。「denyを書いたからBash経由でも読まれない」とは考えないでください。

ファイルアクセスそのものを本当に制限したいなら、レイヤーが違います。公式は、すべてのプロセスからのアクセスを止めるOSレベルの強制としてサンドボックスの有効化を案内しています。サンドボックスはBashコマンドとその子プロセスにOSレベルの境界をかけるもので、権限ルールとは別の層です。さらに確実にするなら、コンテナやVMで環境ごと分ける、あるいはそもそも秘密ファイルをその環境に置かない、という分離が要ります。権限設定は最初の一枚であって、最後の一枚ではありません。

もう1つ、確認プロンプトを省略するモード（bypassPermissions）についてです。公式はこのモードを、権限プロンプトと安全チェックを止めてツール呼び出しを即座に実行するもの、と説明しています。通常なら確認が入る操作も、そのまま実行されます。

ただし、権限ルールがすべて無効になるわけではありません。明示的なdenyルールとaskルールは、bypassPermissionsを含むどのモードでも適用されます。askに一致した操作では、このモードでも確認が表示されます。一方でallowルールは、それ以外の操作がすでに承認された状態になるため、このモードでは効果を持ちません。

These controls apply in every mode, including `bypassPermissions`: deny rules and explicit ask rules, which apply to every tool but can't block `EndConversation` while any other tool remains

Claude Code Docs / Choose a permission mode

Allow rules have no effect in `bypassPermissions` because everything else is already approved.

Claude Code Docs / Choose a permission mode

問題は、deny・askで守れるのが「事前に想定して明示的に書いた操作」だけだという点です。書いていない操作は素通りします。askだけを安全対策のすべてにしないでください。公式は、このモードにプロンプトインジェクションや意図しない操作への保護がないと明記しています。

`bypassPermissions` offers no protection against prompt injection or unintended actions.

Claude Code Docs / Choose a permission mode

なので、使うなら壊れても影響が閉じる隔離環境が前提です。コンテナ、VM、dev containerなどで区切ったうえで動かすもので、母艦のホスト環境で常用するものではありません。

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

Claude Code Docs / Choose a permission mode

そして、ルールの件数は安全の指標ではありません。何を通さないと決めたかと、その判断が今の作業内容と合っているかだけが意味を持ちます。