Claude Codeの権限設定入門｜allow・ask・denyの書き方

公開 2026-10-22更新 2026-10-22著者永上裕之導入とルール

#Claude Code #権限設定 #permissions #settings.json #安全対策

この記事の要点

権限設定は、AIの操作を allow（許可）・ask（確認）・deny（禁止）の3つに振り分ける仕組み
評価は deny → ask → allow の順で、どこか1か所でも禁止されていれば、ほかの場所の許可では解除できない
必ず守りたい決まりは CLAUDE.md の文章ではなく、deny のルールとして settings.json に書く

AIに仕事を任せるとき、いちばん気になるのは「勝手に何をされるか分からない」という不安です。毎回の確認を全部はいで答えると手間がかかり、確認を減らしすぎると、思わぬ操作まで通ってしまいます。

Claude Code には、この線引きを決めるための 権限設定（permissions） があります。この記事では、公式ドキュメント（2026年10月22日確認）にもとづいて、allow・ask・deny の意味、評価の順番、ルールの書き方、権限モードの種類、設定ファイルの置き場所までを順に整理します。

結論：操作を「許可・確認・禁止」の3つに振り分ける

権限設定でやることは、AIの操作を3つの箱に振り分けること です。公式ドキュメントでは、次の3種類のルールとして説明されています。

ルール	意味	向いている操作
allow（許可）	確認なしで実行してよい	テストの実行・ビルドなど、毎日くり返す安全な操作
ask（確認）	実行のたびに人に確認する	外へ送る・大きく書き換えるなど、場面で判断したい操作
deny（禁止）	実行させない	秘密のファイルを読む・取り消せない操作

大切なのは、このルールを守らせるのはAIではなく Claude Code の仕組みそのもの だという点です。依頼文や CLAUDE.md に書いた注意は「AIが何をしようとするか」に影響するだけで、実際に何を許すかは変わりません。必ず守りたい決まりは、権限のルールとして書きます。

評価の順番：deny → ask → allow

いちばん先に覚えておきたいのは 評価の順番が deny → ask → allow で固定されている ことです。この順に調べて、最初に当てはまったルールで結果が決まります。ルールがどれだけ細かいかで順番は変わりません。

たとえば deny に「aws から始まる命令すべて」を入れておくと、allow に「aws の一覧表示だけ」を入れても、その操作は止まります。allow で deny の例外を作ることはできない のです。ask と allow の関係も同じで、ask に当てはまれば、allow にも当てはまっていても確認が出ます。

この仕組みのおかげで、「禁止のつもりが、別の許可ルールで上書きされていた」という事故が起きにくくなっています。迷ったら、まず deny に入れておくのが安全側の考え方です。

ルールの書き方の基本形

ルールは 道具の名前 か 道具の名前(条件) の形で書きます。条件を付けないと、その道具のすべての使い方が対象になります。

道具ごと指定する：Bash はすべてのシェル命令、WebFetch はすべてのページ取得が対象
命令を指定する：Bash(npm run build) はその命令ちょうどだけ。Bash(npm run *) は npm run から始まる命令すべて
ファイルを指定する：Read(./.env) は今のフォルダの .env を読む操作。Edit(/src/**) は src 以下の編集
取得先を指定する：WebFetch(domain:example.com) は example.com へのページ取得

* の位置にも意味があります。公式ドキュメントは *** はサブコマンド（git log の log の部分）の後ろに置く** よう勧めています。Bash(git log *) なら git log だけが対象ですが、Bash(git *) にすると git のすべての命令が対象になります。許可のルールほど、範囲を狭く書くのが基本です。

実際の settings.json は、次のような形になります。

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

この例では、テストやビルドとコミットは確認なしで進み、外への送信（push）は毎回確認が出て、秘密のファイルは読めません。&& などで命令をつないだ場合も、つながれた命令の1つずつにルールが当てはめられる ので、許可した命令の後ろに別の命令を足しても、まとめて通ることはありません。

権限モードの種類と選び方

ルールとは別に、会話全体の「確認の出し方」を決める権限モード があります。公式ドキュメントにある6つを表にまとめます。

モード	動き方	向いている場面
default（Manual）	道具を初めて使うときに確認する	はじめて使うとき・慣れないフォルダ
acceptEdits	ファイルの編集と、よく使うファイル操作を自動で通す	編集を任せて、命令の実行だけ見たいとき
plan	読むだけで、元のファイルは編集しない	作業の前に計画だけ立てさせたいとき
auto	確認を減らし、別のAI（分類器）が操作を見張る	長い作業を任せたいとき
dontAsk	確認が要る操作はすべて自動で断る	許可した操作だけで動かしたいとき
bypassPermissions	確認を飛ばす（一部の操作を除く）	コンテナや仮想マシンなど、切り離した環境だけ

bypassPermissions は、公式ドキュメントでも「隔離された環境でだけ使う」と注意されているモード です。ふだんの仕事のパソコンでは使わないのが基本です。組織として使わせたくない場合は、permissions.disableBypassPermissionsMode や permissions.disableAutoMode を "disable" にすると、そのモードを選べなくなります。

確認を減らしたいときの考え方は Claude Codeのオートモードで詳しく解説しています。どのモードでも、deny のルールは効き続ける 点が安心材料です。

settings.json の置き場所と優先順位

ルールは settings.json に書きます。置く場所によって、だれに効くかが変わります。

置き場所	効く範囲
プロジェクトの `.claude/settings.json`	そのプロジェクトを使う全員（共有できる）
プロジェクトの `.claude/settings.local.json`	そのプロジェクトでの自分だけ
自分のホームの `.claude/settings.json`	自分の全プロジェクト
管理者が配る設定（managed settings）	組織の全員。ほかのどこからも上書きできない

優先順位でまず押さえたいのは2つです。1つ目は、管理者が配る設定がいちばん強く、起動時の指定を含めて、ほかのどこからも上書きできない こと。2つ目は、どこか1か所で deny されていれば、ほかの場所の allow では許可できない ことです。自分の設定で許可していても、プロジェクトの設定で禁止されていれば止まりますし、その逆も同じです。

確認の画面で「今後は聞かない」を選ぶと、そのルールはプロジェクトの .claude/settings.local.json に保存されます。また、プロジェクトの .claude/settings.json に書いた allow は、そのフォルダを信頼する確認に同意するまで効きません。他人が作ったプロジェクトを開いたとき、勝手に許可が広がらないための仕組みです。

/permissions で今のルールを確かめる

設定を書いたら、Claude Code の中で /permissions を開いて確かめます。この画面には、今効いているすべてのルールと、それぞれがどの settings.json から来ているか が一覧で出ます。

/permissions を開き、allow・ask・deny のルールが意図どおりに並んでいるか見る
思わぬ allow があれば、どのファイルから来たかを見て、元のファイルを直す
その場でルールを足したり消したりもできる。変更は次の操作から反映される

ルールの名前を打ち間違えて、どの道具にも当てはまらない deny や ask があると、起動時に警告が出ます。起動時の警告は読み飛ばさない のが、設定ミスを早く見つけるこつです。

任せる前のチェックリスト

秘密のファイルは deny に入れる：.env や鍵の入ったフォルダは Read(...) の deny で読めなくする。Read の deny は、同じ場所への編集や書き込みも止めます
取り消せない操作は ask か deny に：外への送信・削除・本番への反映は、少なくとも毎回確認にする
allow は狭く書く：* はサブコマンドの後ろに置き、道具ごとの丸ごと許可は避ける
ルールだけに頼らない：命令の書き方によっては、ルールに当てはまらない形で同じ操作ができることがあります。公式ドキュメントも、守りたい境界にはサンドボックス（OSのレベルで制限する仕組み）やフックを組み合わせるよう勧めています。フックの使い方は Claude Codeのフックで解説しています
最後の判断は人が持つ：変更の取り込みには Claude CodeのCode Review も組み合わせられます

よくある質問

CLAUDE.md に「〇〇はしないで」と書くだけではだめですか？

それだけでは足りません。CLAUDE.md の内容はAIが何をしようとするかに影響しますが、Claude Code が何を許すかは変えません。必ず守りたい決まりは deny のルールにする のが確実です。CLAUDE.md には理由や背景を書き、ルールと両方で伝えると分かりやすくなります。

allow に入れたのに確認が出るのはなぜですか？

同じ操作に当てはまる ask か deny が、どこかの設定にある可能性が高いです。評価は deny → ask → allow の順なので、ask に当てはまれば allow より先に確認が出ます。/permissions で、どのファイルのルールが当たっているかを確かめてください。

チームで同じ設定を使うにはどうしますか？

プロジェクトの .claude/settings.json に書いて、ほかのファイルと一緒に共有します。自分だけの好みは .claude/settings.local.json に分けておくと、チームの設定を汚しません。組織として必ず守らせたいものは、管理者が配る設定（managed settings）に入れます。

確認の画面で「今後は聞かない」を選ぶとどうなりますか？

シェル命令やページ取得の場合、そのルールがプロジェクトの .claude/settings.local.json に保存され、次の会話からも効きます。ファイルの編集の許可は保存されず、その会話が終わるまでです。保存されたルールも /permissions から消せます。

出典

永上裕之

ユニコスクール株式会社代表取締役。AIエージェント専門のスクール＆コミュニティを運営しています。

この記事はAIを使って下書きし、著者が事実確認・加筆しています。ツールの機能や料金は変わることがあるため、最新の情報は各社の公式ページでご確認ください。