「消す操作だけを止めたかったのに、気づいたら何をするにも確認ダイアログが出るようになった」。Claude Codeを触り始めた人から、いちばんよく聞く相談です。
逆もあります。設定を空のまま使うと、どこまで自動で進むのかが読めません。危ないところで止まる根拠を自分で持てないから、任せきれない。相談はこの2つに分かれます。
この記事は、その両方を1つの設定で解きます。扱うのは.claude/settings.jsonのpermissionsです。deny・ask・allowという3つの列へ操作を仕分けるだけの仕組みですが、仕分けたつもりが効かない場面がいくつかあります。そこまで含めて見ていきます。
根拠は、Claude Codeの公式ドキュメント（code.claude.com/docs、2026-07-28時点の記載）と、運営元WEBMARKSが実際に使っている.claude/settings.jsonの抜粋です。
こんなふうに調べていませんか
- 消す操作だけを止めたいのに、どう書けばいいのか分からない
- 権限設定を書いたはずなのに、確認ダイアログの出方が変わらない
- AIエージェントにどこまで任せてよいのか、社内で説明できる基準がほしい
この記事を読み終えたときに手に入るもの
- 危険な操作だけを止めて、残りは確認なしで進む配分を書けるようになります
- 意図どおりに効くルールの書き方と、効かない書き方の見分けがつきます
- 書いた設定が本当に効いているかを、自分の手で確かめられるようになります
結論30秒でわかる、この記事の結論
- 権限設定は、ツール呼び出しをdeny・ask・allowの3列へ仕分けて、確認なしで進めてよい範囲を決める作業です。
- 判定はdeny→ask→allowの順で固定です。狭く書いたallowが、広いdenyの例外になることはありません。
- 書いた状態と、効いている状態は別ものです。最後に
/permissionsで突き合わせます。
進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長が自分の手で設定を書き、鈴木さん（本誌監修）が答えます。
01Claude Codeの権限設定は、AIエージェントに任せる範囲をどう分けるんですか？
若葉さん権限設定って、結局のところ何を決めている設定なんでしょうか。
鈴木さん空港の手荷物検査に似ています。持ち込ませない棚、係員が中身を見る棚、そのまま通す棚。荷物をこの3つに振り分けておくと、毎回考えなくて済みますよね。
若葉さんAIエージェントの操作を、その3つの棚に入れておくということですか。
鈴木さんそうです。棚の名前がdeny・ask・allowです。名前を覚えるより、棚が3つしかないことのほうが大事です。
書く場所は.claude/settings.jsonのpermissionsフィールドです。ここにdeny・ask・allowの3配列と、defaultModeを持たせます（出典: Claude Code公式ドキュメント）。
| 列 | 効果 | 一致したときの挙動 |
|---|---|---|
| deny | 拒否 | 確認すら出さずにブロックする |
| ask | 確認 | 毎回ユーザーの承認を求める |
| allow | 許可 | 確認なしでそのまま実行する |
押さえておきたいのは、判定の順番です。評価順序はdeny→ask→allowで固定されていて、最初に一致したルールがその場で結果を決めます。ルールの細かさ（特異度）は、順位に影響しません（出典: 同）。
たとえばBash(aws *)をdenyに置いたとします。あとから狭いBash(aws s3 ls)をallowに足しても、ブロックは解けません。denyの段で判定が終わっているからです。
3つの列のどれにも当たらなかった操作は、宙に浮きます。その受け皿がdefaultModeです。あとの章で扱います。
02組織でAI導入を進めるとき、権限設定はどのファイルに書くんですか？
書く場所は1か所ではありません。設定ファイルの置き場は5段階あり、上位が下位を上書きします（出典: Claude Code公式ドキュメント）。
| 順位 | 設定ファイル | 主な用途 |
|---|---|---|
| 1 | Managed settings | 組織の一括管理。他のどの段からも上書き不可 |
| 2 | コマンドライン引数 | セッション単位の一時的な上書き |
| 3 | .claude/settings.local.json（プロジェクト） | 個人用。Git管理対象外が前提 |
| 4 | .claude/settings.json（プロジェクト） | チーム共有。Git管理対象 |
| 5 | ~/.claude/settings.json（ユーザー） | 全プロジェクト共通の既定 |
段が分かれているのは、決める人が違うからです。会社として動かしたくない線は最上段に、チームで揃えたい線は共有ファイルに、手元の都合は個人用ファイルに置きます。
そして、denyだけは扱いが違います。deny側はどの段でも積み上がり、1段でも拒否すればブロックされます。ユーザー設定で許可済みでも、プロジェクト設定が拒否すれば、そのプロジェクトでは拒否のままです（出典: 同）。
この非対称は、AI導入を複数人で進めるときに効いてきます。許可は上書きで緩められますが、禁止は下から緩められません。会社として引きたい線を、いちばん下の個人設定に書かないでください。
03権限設定のルールに当てはまらない操作を、AIエージェントはどこまで進めるんですか？
高梨課長3列に書ききれない操作のほうが、実際には多いと思うんです。書いていない操作はどうなるんでしょう。
鈴木さんそこを決めるのがdefaultModeです。ルールに一致しなかった残りの既定値、という位置づけですね。
高梨課長既定値を広く取っておけば、書くルールは減らせますか。
鈴木さん減らせます。ただ、減らしたぶんは既定に任せたという意味になります。そこは引き換えです。
defaultModeは6種類あります（出典: Claude Code公式ドキュメント）。
| モード | 確認なしで進む範囲 |
|---|---|
| default（Manual） | 読み取りのみ |
| acceptEdits | 読み取り・ファイル編集・mkdir等の一般的なコマンド |
| plan | 読み取りと調査コマンドのみ。ソースは編集しない |
| auto | 分類器による安全確認つきで、ほぼ全操作 |
| dontAsk | allowルールに一致するものだけ |
| bypassPermissions | ほぼ全操作。コンテナ等の隔離環境専用 |
6つを横に並べると迷いますが、選ぶ軸はひとつです。手を戻せる範囲を、どこまで広げるか。それだけを見ます。
autoモードには、行き過ぎを引き戻す仕掛けがあります。3回連続、または合計20回ブロックされると、通常のプロンプトに戻ります。この閾値は変更できません（出典: 同）。広いモードを選んでも、ブロックが続けば手動に戻る、という設計です。
bypassPermissionsは、コンテナ等の隔離環境専用と明記されています。手元の作業マシンで選ぶモードではありません。
04AI社員に触らせたくない操作は、権限設定でどうやって選び分けるんですか？
高梨課長denyに何を入れるか、決め方が分かりません。思いついたものを並べるだけになりそうで。
鈴木さん思いつきで並べると、抜けたものが自分では分かりませんよね。うちは軸に載せてから選んでいます。
高梨課長軸というと、何を見るんでしょう。
鈴木さん元に戻せるかと、外まで届くか。この2つだけです。
権限設定の土台は、ルールを書く前の分類です。運営元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による書き換え自体を拒否している例です。正本の運用ルールを、権限設定でも二重に固定しています。
05denyに入れなかった操作は、AIエージェントの権限設定でどこまで許していいんですか？
残りの象限は、askとallowに分かれます。
取り返しはつくが外部に届く操作、たとえばgit pushや配信系ツールの送信はaskです。実行そのものは止めず、確定させる直前で人に戻します。両方ローカルで軽微な操作はallowに置きます。
判断に迷うのは、取り返しがつかずローカルだけ、という象限です。大量ファイルの一括削除などが当てはまります。ここはaskへ倒すのが安全側です。
倒す先をaskに固定しておくと、迷った操作がdenyにもallowにも溜まりません。denyに入れると自分の作業まで止まり、allowに入れると気づかないうちに実行されます。askは、判断を保留したまま作業を続けられる置き場です。
06Claude Codeで読み取りだけのコマンドまで毎回確認が出ると、生成AIを使う意味が薄れませんか？
先に答えると、そこは既に手当てされています。
読み取り専用コマンドの一部は、Claude Code側に組み込み済みです。モードを問わず、確認なしに実行されます（出典: Claude Code公式ドキュメント）。対象はls cat grep findなど14種と、読み取り専用のgitです。
つまり、調べるだけの操作をallowへ書き並べる必要はありません。allowに書く価値があるのは、その先にあります。
自社でよく使うコマンドのうち、失敗しても手元で戻せるものを選びます。テストの実行、ビルド、ローカルのコミットあたりが定番です。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git * main)"
],
"deny": [
"Bash(git push *)"
]
}
}この配分だと、手元での試行はほとんど止まらず、外へ出る操作だけが止まります。確認の回数を減らす近道は、allowを広げることではなく、止める場所を外へ出る一点へ寄せることです。
07Claude Codeの権限設定は、どう書けばAIエージェントに過不足なく効くんですか？
ルールの書式はToolまたはTool(指定子)です。ツール名だけなら、そのツールの全呼び出しに一致します。括弧内の指定子で絞り込みます（出典: Claude Code公式ドキュメント）。
| 記法 | 一致する対象 |
|---|---|
Bash | すべてのBashコマンド |
Bash(npm run build) | 完全一致する1コマンドだけ |
Bash(npm run test *) | npm run test で始まるコマンド |
Read(./.env) | カレントディレクトリの.env読み取り |
WebFetch(domain:example.com) | example.comへのfetch |
mcp__puppeteer__* | puppeteerサーバーの全ツール |
Agent(Explore) | Exploreサブエージェント |
粒度はツール名だけ、完全一致、前方一致の3段だと考えると迷いません。ここに、見落としやすいクセがあります。
ワイルドカードは、*の前の空白の有無で挙動が変わります。Bash(ls *)はls -laに一致しますが、lsofには一致しません。空白のないBash(ls*)は、どちらにも一致します（出典: 同）。
この差は、denyに書いたときにいちばん効いてきます。空白を入れたつもりが抜けていると、止めるつもりのなかったコマンドまで止まります。逆に、空白を入れたせいで狙ったコマンドが素通りすることもあります。
空白は飾りではなく、当たる相手を入れ替えます。頭の中で照合せず、あとの章で扱う一覧で確かめてください。
08&&でつないだコマンドは、AIエージェントの権限設定でどう判定されるんですか？
複合コマンドは、&& || ; | ごとに分解され、個別に判定されます（出典: Claude Code公式ドキュメント）。
つまりBash(safe-cmd *)を許可しても、&&の右側にあるother-cmdまでは許可されません。片方が許可されていなければ、その複合コマンド全体が確認に回ります。
この挙動は、意図せず許可が広がらないようにするための設計です。ただし、副作用もあります。複合コマンドを承認すると、サブコマンドごとに最大5個までルールが自動保存されます（出典: 同）。
承認を重ねるうちに、自分で書いた覚えのないallowが増えていく、という状態が起こります。定期的に一覧を出して、身に覚えのない行を消す作業が要ります。
09通信先の制限は、AIエージェントの権限設定だけで足りるんですか？
高梨課長書式のクセまで分かりました。これで書ききれますか。
鈴木さん書式だけでは届かない場所が残ります。たとえば、通信先の制限です。
高梨課長Bash(curl http://github.com/ *)のように書けばよいのでは。
鈴木さん公式ドキュメントが、その書き方は壊れやすいと明記しています。素通りする書き方が5通りある、と。
Bash向けのワイルドカードだけでURLを制限するのは、壊れやすい方法です（出典: Claude Code公式ドキュメント）。Bash(curl http://github.com/ *)のつもりでも、素通りする書き方が5通りあります。オプションを前に置く、httpsにする、といった変形です。
文字列の形で条件を書くかぎり、変形の余地は残ります。ここは書式の限界です。
URL制限が要るなら、別の場所で受けます。Bash経由のネットワークコマンドはdenyにしておき、WebFetch(domain:...)かPreToolUseフックで検証する形です。前者は書式のまま、後者はコードで判定します。
10権限設定に加えて、実行の直前で止めるフックはAIエージェントに何を返すんですか？
運営元WEBMARKSは、settings.jsonのルールに加えてPreToolUseフックで防御を重ねています。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "/usr/bin/python3 -I -B '<Vaultルート>/.claude/hooks/bash-guard.py'"
}
]
}
]
}
}このフックは、危険と判定したコマンドを終了コード2で止めます。標準エラーの内容がそのままモデルへ返り、ツール呼び出し自体は実行されません（出典: 同）。止めるだけでなく、止めた理由がモデルに伝わる点が、書式による拒否との違いです。
実際にgit pushを検出したときの応答が、これです。
⛔ bash-guard: `git push`はwrapper・間接実行・--no-verifyを含めて人間専権です。AIはローカルcommitまでで停止してください。文字列の一致だけでは拾えない変形、たとえばwrapper経由の呼び出しや--no-verifyつきの実行まで、フック側で判定しています。
11権限設定でつまずく3つの落とし穴は、AI社員の動きをどう変えてしまうんですか？
書いたのに効かない、あるいは効きすぎる。相談の中身は、だいたい3つに集まります。
落とし穴1：素のBashをdenyに書いて、全部止めてしまう。 rmだけを止めたいのに"deny": ["Bash"]と書くと、ツール名だけの記法として扱われます。Bashツールそのものが、モデルの視界から丸ごと消えます。狭めたいときはBash(rm *)のように指定子つきで書きます（出典: Claude Code公式ドキュメント）。
落とし穴2：狭いallowが、denyの例外になると思い込む。 ファイアウォールの例外設定に慣れていると、広いdenyの中へ狭いallowを混ぜれば通ると考えがちです。評価順序はdeny→ask→allowで固定です。denyが先に一致した時点で、後段のallowは評価されません（出典: 同）。
落とし穴3：プロジェクトのallowルールが、最初のセッションで効かない。 新しいプロジェクトの.claude/settings.jsonにallowルールを書いても、ワークスペース信頼ダイアログを承認するまで適用されません。ルールは読み込まれていても、権限は付与されていない状態です（出典: 同）。「書いたのに動かない」と感じたら、まずこのダイアログの承認を確認してください。
3つに共通するのは、書いた内容ではなく、それがどう解釈されるかのズレです。だから最後は、解釈された結果を見にいきます。
12書いた権限設定が、AIエージェントに本当に効いているかはどう確かめるんですか？
若葉さん書き終わったら、どうやって確かめればいいんでしょう。
鈴木さん動かして確かめます。読み返して納得するのは、確かめたことになりません。
若葉さん見るところは決まっていますか。
鈴木さん4項目です。一覧を出して、denyとaskとallowを1回ずつ踏んでみる。それだけです。
合否の基準は、次の4項目です。
/permissionsを実行する。入力は要りません。各ルールと、出所のsettings.jsonの一覧が出ます。期待：deny・ask・allowそれぞれに書いたルールが表示される（出典: Claude Code公式ドキュメント）- denyに置いた操作を、実際に呼び出させる。入力例：
rm -rfを含む操作。期待：実行されず、ブロックの理由が表示される - askに置いた操作を呼び出させる。入力例：
git push。期待：毎回、確認ダイアログが出る - allowに置いた操作を呼び出させる。入力例：許可した読み取り専用コマンド。期待：確認なしで完了する
4項目とも期待どおりなら合格です。ズレたときの見どころも決まっています。ワイルドカードの空白の有無と*の位置、そして評価順序です。askのはずが確認なしで進んだ場合は、広いallowルールが先に無いかを/permissionsの一覧で確認します。
この章のまとめ
書いた状態と、効いている状態は別ものです。4項目を踏めば、その差はその場で分かります。
13よくある質問
Claude Codeの権限設定は、defaultMode以外にどこへ書けますか
権限設定の主な項目は、permissions配下のallow ask deny additionalDirectoriesの4つです。additionalDirectoriesは、作業ディレクトリの外へのアクセスを追加する項目です。読ませたい資料が別のフォルダにあるとき、ここで足します。ただし追加した範囲は、Read側で塞がないかぎり読める状態になります。
権限設定はどのくらいの頻度で見直すべきですか
新しいMCPサーバーやツールを追加したとき、そしてClaude Codeのバージョンを更新したときに見直します。追加したツールはmcp__から始まる名前で入ってくるため、既存のルールでは拾えません。本記事は特定バージョンの公式仕様に依存するため、鮮度ラベルはwatch（四半期棚卸しの対象）です。
denyに書いた操作を、一時的に通したいときはどうしますか
denyのまま通す抜け道を探すより、その操作だけ人がやるほうが早い場面が多いです。評価順序が固定されている以上、狭いallowで穴を開けることはできません。自動で通したいなら、denyの記述そのものを狭めます。たとえばBash(git push *)をBash(git push --force*)へ絞る形です。狭めた記録がファイルに残ります。
権限設定とPreToolUseフックは、どちらを先に整えるべきですか
先は権限設定です。3列の仕分けは書式だけで済み、/permissionsで結果も見えます。フックはコードなので、書いた本人しか挙動を追えません。まず3列で大きく塞ぎ、書式では表せない条件が残ったときにフックを足す。この順番だと、フックが担う範囲が小さく収まります。
設定を書いたのに、ダイアログの出方が変わりません。どこから見ますか
まず/permissionsで一覧を出し、書いたルールが載っているかを見ます。載っていなければ、ファイルの置き場か、ワークスペース信頼ダイアログの承認を疑います。載っているのに挙動が違うなら、原因は評価順序か書式です。denyが先に当たっていないか、*の前の空白が意図どおりかを確かめてください。
14まとめ｜今日やる3つのこと
権限設定は、3列に仕分けて、書式で絞って、効いているかを確かめる。この順で進みます。
今日はこの順で手をつけます
元に戻せるかと、外まで届くかの2軸へ、自社の操作を載せる
思い出して並べる方式だと、抜けたものが分かりません
両方が悪い象限だけをdenyに書き、外へ出る操作をaskへ置く
止める場所を絞ると、確認の回数はむやみに増えません
/permissionsで一覧を出し、deny・ask・allowを1つずつ踏む書いた状態と効いている状態は、別々に確かめるしかありません
AI検索では、こう聞かれています
Claude Codeの権限設定は、どこに何を書けばいいんですか？
「組織でAI導入を進めるとき、権限設定はどのファイルに書くんですか？」の章で説明しています
AIエージェントに任せてよい操作は、どうやって選ぶんですか？
「AI社員に触らせたくない操作は…選び分けるんですか？」の章に2軸の仕分けがあります
権限設定を書いたのに効かないのは、なぜですか？
「権限設定でつまずく3つの落とし穴は…どう変えてしまうんですか？」の章で3つに整理しています
書いた設定が効いているか、どこで確かめますか？
「書いた権限設定が…本当に効いているかはどう確かめるんですか？」の章で4項目にしています
次に読むなら、この記事です
