Claude Code の権限（permissions）解説：allow・deny・ask ルールの仕組み
Claude Code がどう権限を確認するかをコマ送りで解説：確認プロンプトの 3 つの選択肢、settings.local.json に保存される allow ルール、deny 優先の評価順序、権限モード、そして日常のコーディングと CI で確認回数を減らすレシピ——動画で足りない部分はすべて公式ドキュメントで補いました。
60 秒でわかる Claude Code の権限
- Claude Code は Bash、Edit、WebFetch、Write の前に確認を求めます。Read、Glob、Grep、LS は尋ねずに実行します。
- 「Yes, and don't ask again」を選ぶと Bash(git add:*) のようなルールが .claude/settings.local.json に保存されます——そのリポジトリ限定の、git から除外された個人用ルールブックです。
- ルールは deny → ask → allow の順で評価されます：どの設定ファイルの deny も優先され、allow ルールはそこに例外を作れません。
- モードで信頼の度合いを調整します：編集の多い作業には acceptEdits（alt+m）、読み取り専用の偵察には plan、CI では --permission-mode で bypassPermissions——なお defaultMode の auto と bypassPermissions はユーザー設定か管理設定に書いて初めて効きます。
Claude Code Tutorial #4 - Tools & Permissions
チャンネル:The Net Ninja4:55
Permission Modes Head to Head
チャンネル:ttywood6:20
Permissions — Claude Code documentation
公式ドキュメント:code.claude.com
Settings files — Claude Code documentation
公式ドキュメント:code.claude.com
静止画はすべて Net Ninja の収録から——カメラもオーバーレイもないクリーンな画面キャプチャです。権限モードを正面から比べた ttywood の回は、モードとレシピの節のクロスチェックに使いましたが、フレームは 1 枚も採っていません（焼き込み字幕があるため）。ルール構文、評価順序、モードの挙動、設定ファイルの優先順位は 2 つの公式ドキュメントページで検証済みです。
動画 © The Net Ninja・ttywood（リンクのみ）。ドキュメント © Anthropic。スクリーンショットは本ガイドの解説のために引用しています。
Claude Code の権限をステップごとに設定する
Claude Code が動く前に尋ねること
- 1
どのツールが権限プロンプトを出すか知る
Claude Code はツールを自分で選びます——ファイルを開くのは Read、変更するのは Edit、シェルコマンドは Bash。Anthropic の設定ドキュメントは各ツールに Permission Required の列を与えています：Bash、Edit、WebFetch、Write は止まって尋ね、Read、Glob、Grep、LS はそのまま走ります。ツール名を自分で打つことはなく、大事なのはどの動作が自分を待って停止するかを先に知ることです。
Claude Code の設定ドキュメントは、内蔵ツール全員に Permission Required の判定を付けて一覧にしています。1:05 から視聴 - 2
編集を頼んで、まず読む様子を見る
動画でのリクエストは意図的に小さくしています：src/app/globals.css に淡い黄色の --highlight 変数を足す、というもの。Claude Code はまずファイルを読み——Read には権限が不要です——変更しようとする瞬間に初めて止まります。この分離が権限モデル全体の縮図です：見るのは無料、触れるのは確認。
VS Code の Claude Code 入力欄に打ち込まれたハイライト変数のリクエスト。1:45 から視聴 - 3
答える前に 3 つの選択肢を読む
編集の確認プロンプトには毎回 3 つの答えがあります。1. Yes はこの 1 回の編集だけを承認。2. Yes, and don't ask again this session はこのセッションの残りの変更を承認（収録ビルドでは alt+m）。3. No, and tell Claude what to do differently（esc）は変更を拒み、指示で舵を取ります。3 番目は失敗ではありません——コードが着地する前に軌道修正する正しいやり方です。
globals.css の編集確認プロンプト。3 つの権限オプションがすべて見えています。2:17 から視聴
一度だけ yes を言う：allow ルールを保存する
- 4
タスクごとではなく、編集ごとにプロンプトが出る
承認は次の変更に引き継がれません。デモでは同じファイルへの 3 つの別々の編集に 3 回の Yes が要り、次の変更でもまた尋ねられました。都度承認でも動きますが、2 行のタスクを超えた途端に破綻します——allow ルールとモードが存在するのはまさにそのためです。
1 か所目の承認の直後、globals.css の 2 か所目の編集が再び確認を表示。2:32 から視聴 - 5
Bash コマンドには専用の確認ゲートがある
シェルコマンドには別の関門があります。デモで Claude にコミットを頼むと、Bash(git add src/app/globals.css) が Waiting 状態で答えを待ちます。あるコマンドの yes は次のコマンドの yes ではありません——続く git commit は自分の名前でもう一度尋ねてきます。
承認待ちの git add コマンド。上には先ほどの git の出力が流れています。3:16 から視聴 - 6
「don't ask again」にルールを書かせる
git add コマンドに Yes, and don't ask again を選ぶと、2 つのことが一度に起きます：現在のコマンドが解放され、ルールが 1 本保存される。作られるのはリポジトリのルートにある .claude/settings.local.json で、permissions オブジェクトの allow 配列——ここでは "Bash(git add:*)"——に加え、空の deny と ask の配列が入ります。以後このプロジェクトの git add はすべて確認なしで走ります。
.claude の下に作られた settings.local.json。Bash(git add:*) の allow ルールが保存済み。3:40 から視聴 - 7
ダイアログで足りないルールは手で編集する
allow 配列はただの JSON なので、自分でルールを足せます。単一のコマンドには正確な文字列——Bash(npm run test)——を、同じ始まりのコマンド全体には末尾の :* ——Bash(npm run test:*)——を使います。公式ドキュメントも :* が末尾ワイルドカードの省略記法だと確認しています。このファイルは個人用と心得て：Claude Code は settings.local.json を自動で git 除外に入れ、動画も同じ助言をします——これはリポジトリではなく、あなたのワークフローのためのものです。
手編集の最中、permissions.allow 内で選択された保存済みルール。4:22 から視聴
モードで委譲の幅を調整する
- 8
編集の集中期間は accept edits に切り替える
alt+m（現行ビルドでは shift+tab でモードを巡回）でセッションのバッジが accept edits on に変わります。ファイル編集は確認なしで着地し、ドキュメントはさらに、mkdir、touch、mv、cp といった一般的なファイルシステムコマンドも自動承認されると述べています。この恩赦はセッション限定：新しいセッションを始めれば、自分で再び有効にするまで編集ごとの確認に戻ります。
許可済みの git コマンドがコミットを仕上げる間、accept edits on のバッジが表示。4:35 から視聴 - 9
登る前にモードの階段全体を知っておく
モードはセッションの既定の姿勢を決めます。default は各ツールの初回使用時に確認。plan は何も編集しない読み取り専用の探索。acceptEdits はファイル編集を自動承認。dontAsk は尋ねるはずの呼び出しをすべて自動拒否。auto はバックグラウンドの安全確認つきでツール呼び出しを承認。bypassPermissions は、どのモードも自動承認できない小さな集合を除いて確認を省きます。セッションごとには --permission-mode で、恒久には permissions.defaultMode で選びます。
- 10
defaultMode を正しいファイルに置く
設定ドキュメントは明快です：defaultMode の auto と bypassPermissions はプロジェクトやローカルの設定からは効きません——ユーザー（~/.claude/settings.json）か管理設定に置くか、1 セッションだけなら --permission-mode を渡します。優先順位は管理設定 → CLI --settings → .claude/settings.local.json → .claude/settings.json → ユーザー設定の順に走り、どの階層の deny もその下のすべての allow に勝ちます。
実プロジェクト向けのコピペレシピ
- 11
レシピ：テストは許可し、破壊は拒否する
チーム共有の .claude/settings.json で、テストループを "Bash(npm run test:*)" で許可し、危険な部分を "Bash(rm -rf *)" と "Read(./.env)" で囲えば、シークレットは決して読めません。Web リサーチも同じ要領：単一ドメインは "WebFetch(domain:example.com)"、サブドメイン全体は "WebFetch(domain:*.example.com)"。deny が先に評価されるため、どの allow ルールもそこに例外を掘れません。
- 12
レシピ：CI で安全に確認を省く
非対話の実行に必要なのは、偶然ではなく意図的な姿勢です：CI ジョブに --permission-mode bypassPermissions を渡すか、ユーザーか管理設定で defaultMode を設定——プロジェクトファイルには許諾できません。ガードレールを恒久にするには、管理設定で permissions.disableBypassPermissionsMode を "disable" にし、/permissions で各マシンを監査すれば、有効な全ルールとその出所ファイルが一覧されます。
deny → ask → allow：ルールは実際どう評価されるか
権限ドキュメントは率直に述べています：ルールは deny、次いで ask、次いで allow の順に評価され、最初に一致したものが結果を決める。ルールの具体性はこの順序を決して変えません。allow ルールは、どんなに精密でも deny ルールに例外を掘れません。
deny はファイルをまたいでグローバルでもあります。ユーザー設定がコマンドを許可し、プロジェクト設定が拒否すれば、deny が勝ちます——あらゆるスコープの deny ルールは allow ルールより先に評価され、管理設定の deny はコマンドラインフラグでも覆せません。"Bash" のような裸のツール名を deny するとさらに先まで行きます：ドキュメントいわく、そのツールを Claude のコンテキストから完全に取り除くとのことです。
実務上の帰結：安全ルール——rm の拒否、.env 読み取りの拒否、force-push の拒否——は、リポジトリとともに配られるプロジェクトの .claude/settings.json に載せ、allow リストはその上に積む便利装置と扱います。allow リストはスコープをまたぐと上書きではなくマージされるため、個人の settings.local.json は誰の deny も弱めずに特例を足せます。
盗む価値のある 3 つのレシピ
各レシピは書き込むべきファイルを明示しています。すべてに共通する鉄則：deny はどこでも、常に勝ちます。
テストは自由に、rm と .env は固く閉ざす
.claude/settings.json に："permissions.allow": ["Bash(npm run test:*)"]（スタックに合わせて "Bash(npx vitest:*)" や "Bash(uv run pytest:*)" に差し替え）、"permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]。テストとそのコールバックは手放しで走り、破壊的な削除とシークレット読み取りは評価が allow リストに届く前に遮られます。
リサーチは信頼するドメインに釘付けする
ドキュメント漬けの作業には：allow に "WebFetch(domain:developer.mozilla.org)" と "WebFetch(domain:claude.com)"、またはサブドメイン全体なら "WebFetch(domain:*.example.com)"。裸の "WebFetch" ツールを deny すれば Web 読み取りを丸ごと切れます——ローカルコンテキストだけで完結する再現性重視の実行に有用です。
CI を無人化する、ただし暴走させずに
CI ジョブに --permission-mode bypassPermissions を渡すか、ユーザーか管理設定で "permissions.defaultMode": "bypassPermissions" を設定——プロジェクトとローカルの設定には許諾できません。モード自体を禁じたいなら、管理設定の "permissions.disableBypassPermissionsMode": "disable" が全リポジトリ・全フラグを締め出します。それでも bypassPermissions は、どのモードも自動承認できない短いリストのアクションはブロックし続けます。
ルールが効かない？確認すべきはこの 4 つ
「allow ルールが無視される」という報告のほとんどは、ルールがどのファイルに落ちたか、どのファイルが勝つかに行き着きます。
- 1ルールは正しい、ファイルが違う。セッションの承認は .claude/settings.local.json に落ちます。チームのルールは .claude/settings.json へ、マシン全体のルールは ~/.claude/settings.json へ。/permissions を実行すれば——有効な全ルールと、それぞれの出所の設定ファイルが一覧されます。
- 2上位のファイルが deny している。値は下位を上書きしますが、どの階層の deny も allow より先に評価されるため、ユーザーレベルの allow はプロジェクトレベルの deny を救えません——管理設定はコマンドラインフラグも含めてすべてに勝ちます。
- 3allow ルールが信頼を待っている。deny と ask は即時有効ですが、コミット済みプロジェクトファイルからの allow ルールは、ワークスペースフォルダを信頼するまで効きません——clone してきたリポジトリのための意図的なゲートです。
- 4モードが間違ったファイルに置かれている。defaultMode の auto と bypassPermissions はプロジェクト・ローカル設定からは無視されます（ドキュメントはこの変更が v2.1.257 からと注記——それ以前は bypassPermissions がどのファイルからでも効きました）。ユーザーか管理設定へ移すか、単一セッションなら --permission-mode を使います。