Claude Codeの権限設定（permissions）完全ガイド — deny・ask・allowの使い分けと全社統制

権限設定の基本 — deny・ask・allowの3層

Claude Codeのpermissions設定は、AIエージェントが実行しようとする操作（コマンド実行・ファイル読み書き・Web取得など）をdeny（禁止）・ask（毎回確認）・allow（許可）の3種類のルールで制御する仕組みです。

重要なのは評価の順序です。ルールはdeny → ask → allowの順で評価され、最初に一致したものが適用されます。つまりallowに何を書いてあっても、denyに一致すれば必ずブロックされます。「会社として絶対に禁止したい操作」をdenyに置いておけば、現場が利便性のためにallowを増やしても、その禁止が破られることはありません。

ルールの書き方 — ツール名と対象パターンで指定する

ルールは「ツール名（対象パターン）」の形式で書きます。ツール名だけ書けばそのツール全体、括弧内にパターンを書けば特定の操作だけに絞れます。代表的な書き方は次のとおりです。

*はワイルドカードで、コマンドの先頭・途中・末尾どこでも使えます。また、&&や;でつないだ複合コマンドは部分ごとに分解して判定されるため、「安全なコマンドの後ろに危険なコマンドを連結してすり抜ける」ことはできない設計になっています。

実務で落としがちなのがパスの表記ゆれによるマッチ漏れです。当社の社内リポジトリでは、顧客案件を置いたフォルダをAIに読ませないために、プロジェクト設定へ次の2行を並べて書いています（フォルダ名は例に置き換えています）。

{
  "permissions": {
    "deny": [
      "Read(./clients/**)",
      "Read(/clients/**)"
    ]
  }
}

同じフォルダを指す2通りの書き方をあえて重ねて書いているのは、AIがどちらの表記でパスを組み立ててもdenyに一致させるためです。1行で足りそうなルールでも、本当に禁止したい対象なら表記ゆれごと潰しておくほうが安全です。

法人導入の推奨セット — まずこの基本形から

ここからは説明用の例ではなく実物です。当社が社内標準のガードレールとして用意している設定ファイルの中身を、そのまま載せます。プロジェクトの .claude/settings.json に置けばチーム全員に、~/.claude/settings.json に置けば個人の全プロジェクトに適用されます。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/.env)",
      "Edit(**/.env.*)",
      "Write(.env)",
      "Write(.env.*)",
      "Write(**/.env)",
      "Write(**/.env.*)",
      "Bash(sudo *)",
      "Bash(shred *)",
      "Bash(truncate *)",
      "Bash(mkfs *)",
      "Bash(dd *)",
      "Bash(wipefs *)",
      "Bash(git push --force)",
      "Bash(git push --force*)",
      "Bash(git push -f)",
      "Bash(git push -f *)",
      "Bash(git push --force-with-lease*)",
      "Bash(git reset --hard*)",
      "Bash(git clean -f*)",
      "Bash(git filter-repo*)",
      "Bash(git filter-branch*)"
    ]
  }
}

27件の内訳は環境変数ファイルが12件・取り消せないコマンドが6件・git操作が9件です。数が多く見えますが、禁止したい対象そのものは3種類しかありません。1つずつ意図を説明します。

1つ目の .env は秘密情報の置き場所なので、同じファイルを4通りの書き方で塞いでいます。直下の .env と .env.*、さらにサブフォルダまで拾うglob付きの2つ。この4パターンを Read・Edit・Write の3ツールに掛けて12件です。読み取りだけ止めても、上書きや削除は別のルールになります。

2つ目は取り消しの効かないコマンドです。sudo に加えて shred・truncate・mkfs・dd・wipefs を並べています。いずれもファイルやディスクの中身を復元できない形で壊せるもので、AIエージェントに任せる理由がありません。

3つ目のgit操作が、実務では一番効きます。git push --force・git reset --hard・git clean -f・git filter-repo・git filter-branch の系統で9件。どれも「作業内容そのものが消える」種類の操作で、AIの取り違えが一番痛い形で出ます。

--force と -f と --force-with-lease を別の行に分けているのは、同じ操作でも書き方が違えばルールは一致しないからです。禁止したい操作が1つでも、実際に打たれうる表記を数えて並べる必要があります。

気づかれたと思いますが、この設定には allow（許可）も ask（確認）も1件もありません。禁止だけを全社で揃え、許可は現場に委ねるという設計です。理由は「managed settingsで外せない禁止を全社配布する」で説明します。

なお設定ファイルを自分で書く必要はありません。Claude Codeに日本語で「.envの読み取りとsudoを禁止して、rmは毎回確認にして」と依頼すれば、設定ファイルを書いてくれます。内容を確認して保存するだけです。

「管理者権限」の2つの論点 — sudoとbypassPermissions

Claude Codeと管理者権限の話には2つの別の論点があります。1つ目はOSの管理者権限（sudo）をAIに渡すかです。sudoはシステム全体を変更できる権限で、AIエージェントに渡す必要はほぼありません。上の推奨セットのとおりBash(sudo *)をdenyにしておき、OSレベルの作業が必要な場面は人が実行する運用にします。

2つ目は確認プロンプトを省略するbypassPermissionsモードです。Claude Codeには「確認の既定動作」を変えるパーミッションモードが6種類あり、そのうちbypassPermissionsだけが確認を全面的にスキップして実行し続けるモードです。

現行のモード一覧は次のとおりです（2026年8月時点の公式ドキュメントで確認）。設定ファイルの defaultMode や起動時の --permission-mode にはこの値を書きます。default は、画面上では「Manual」と表示される点に注意してください。

見落とされがちなのが dontAsk です。名前から「何でも通す」と誤解されますが、実際は逆で、許可リストに無い操作を待たずに拒否するモードです。人が承認できない自動実行の場面では、確認待ちで止まらせないための選択肢になります。

開発効率は上がりますが、コンテナや仮想マシンなど壊れても影響がない隔離環境以外では使わないのが原則です。組織としては、設定にdisableBypassPermissionsModeを"disable"と指定することで、このモード自体を使えなくできます。

「すべて許可」にしたい — 確認プロンプトを安全に減らす4つの方法

「毎回の確認が煩わしいので、すべて許可で動かしたい」という相談もよく受けます。人が画面の前にいる通常の作業で確認プロンプトを減らす方法は、リスクの低い順に並べると次の4つです（2026年8月時点の公式ドキュメントで確認）。

完全な「すべて許可」にあたるbypassPermissionsモードは、起動時にclaude --permission-mode bypassPermissions（同じ意味の--dangerously-skip-permissionsでも可）と指定した場合だけ使えます。

フラグ名に「dangerously（危険を承知で）」と入っているとおり自己責任のモードで、初回は責任を受け入れる確認ダイアログが表示され、root・sudoでの起動は拒否されます。ルートディレクトリやホームディレクトリ全体の削除（rm -rf /など）だけは、このモードでも安全装置として確認が残ります。

実務での推奨は明確です。日常の開発では「今後確認しない」で許可リストを育てるかautoモードを使い、bypassPermissionsは隔離環境に限定する——公式ドキュメントも、確認を減らしたい場合は安全チェック付きのautoモードを代替として推奨しています。

そもそも何が起きうるから確認があるのか、というリスクの全体像はClaude Codeの危険性の記事で整理しています。

組織として「すべて許可」を封じたい場合は、前述のとおり設定のdisableBypassPermissionsModeで無効化してください。

設定ファイルは4層 — 誰がどこまで統制できるか

permissionsを書く場所は1つではありません。Claude Codeの設定ファイルは4つの層があり、法人導入では「どの層に何を書くか」の設計がそのまま統制設計になります。

優先順位はmanagedが最上位で、以下コマンドライン指定 → local → project → userの順です。ただしpermissionsのルールに限っては、denyルールはどの層に書かれていても常に有効です。ユーザー設定のdenyをプロジェクト設定のallowで上書きする、といったことはできません。

managed settingsで「外せない禁止」を全社配布する

従業員数が増えてくると「各自が設定してください」では統制が効きません。そこで使うのがmanaged settings（管理者配布の設定）です。管理者がOSの管理領域に設定ファイルを配置すると、ユーザー側・プロジェクト側の設定では一切上書きできない全社ポリシーとして機能します。

• MDM経由で配布できる — Jamf・Intuneなどの端末管理ツールから、OSのポリシー機能（macOSの構成プロファイル、Windowsのグループポリシー）としても配布できます
• 現場ルールの全面禁止も可能 — allowManagedPermissionRulesOnlyを有効にすると、ユーザー・プロジェクト設定に書かれた許可ルール自体を無効化し、管理者が配布したルールだけを適用できます
• bypassPermissionsの封印 — 前章のdisableBypassPermissionsModeもmanaged settingsに書くのが定石です。ここに書けば現場では解除できません

先ほど載せた実物に allow も ask も無かったのは、この層に置くものを絞ったからです。managedへ書くのは禁止だけにする——許可まで管理者が抱えると、現場が新しいツールを使うたびに配布ファイルの更新依頼が届き、情報システム部門が業務のボトルネックになります。

もう1つ、managedを使う本質的な理由はAIエージェント自身に書き換えられないことです。~/.claude/settings.json や .claude/settings.json は作業対象のファイルと同じ場所にあり、AIに編集を頼めば書き換えられます。そこにだけ禁止を置くのは、ガードレールをAIが動かせる場所に置いている状態です。

そして managed settings の配置先へ書き込むには管理者権限が必要で、その sudo 自体を上の設定で禁止しています。禁止のルールが、そのルールを書き換える手段まで塞いでいる——この二重構造があって初めて、managed層は「最後の床」として機能します。

なお、Claude for Enterpriseプランでは、こうした組織全体のポリシー設定（managed policy settings）やSSO・ロール管理を管理画面から一元的に扱えます。契約プランの選定とあわせて検討してください。

permissionsの限界 — 併用すべき仕組み

permissionsは強力ですが、万能ではありません。限界を知って他の仕組みと組み合わせるのが実務です。

• 間接的なファイルアクセスには効かない — ReadやEditのdenyルールは、AIが自作したスクリプト（Python等）がファイルを開く動きまでは止められません。OSレベルで強制したい場合はClaude Codeのサンドボックス機能を併用します
• コマンドの引数を縛るパターンは破られやすい — 「curlはこのURLだけ許可」のような引数ベースの制限は、書き方の揺れですり抜けが起きます。Bash側のネットワークコマンドをdenyし、WebアクセスはWebFetch(domain:...)のドメイン許可で管理する構成が堅実です
• 組織のルールは設定だけでは伝わらない — 「入力してよい情報の区分」「インシデント時の報告先」といった運用ルールは利用ガイドラインとして明文化し、研修で定着させます

1つ目の限界は、言葉で説明するより実例のほうが早いので当社の話をします。Read(./.env) を deny に書いても、cat .env は Bash ツールの操作なので Read のルールには一致しません。禁止したのはファイルではなく、あるツールでの操作だからです。

そこで当社は、Bashコマンドの中身を実行前に見るhookを1本足しています。.env を触ろうとする表示・持ち出し系のコマンドを、その場でブロックするという判定です。

ここで効いているのは、ブロックそのものより拒否したときに返すメッセージです。理由だけ告げて止めると、AIは別の抜け道を探し始めます。当社のhookは拒否と同時に、代わりに使ってよい正規ルートを3つ返すようにしています。

• スクリプトの中から読み込む — プログラム内部で設定値として読ませ、コマンドラインに .env の値そのものを出さない使い方は通す
• 環境変数としてロードするだけなら認める — スクリプト内部で環境変数として読み込む使い方は、値がAIの読む画面に出ないため公認する（実行前に用途を1行宣言させる）
• 存在確認は値を出さずに行う — キーが入っているかどうかの真偽だけを表示し、中身は表示しない

この線引きを一言でいうと「表示はブロック、ロードは公認」です。.env に一切触らせない運用は現実には回りません。危ないのは値がAIの読む画面に出ることだと定義し直し、そこだけを塞ぐ。禁止は面積を絞るほど守られます。

permissionsとモードとhookは、役割で分けると設計が迷わなくなります。参考までに、当社の個人設定の permissions には defaultMode の1行しか書いていません。禁止はmanaged層、文脈を見ないと判断できない禁止はhook層に寄せているからです。

まとめると、CLAUDE.mdは行動方針（お願い）、permissionsは機械的な強制、サンドボックスはOSレベルの隔離、ガイドラインは組織のルールという役割分担です。この4点セットを最初に整えることが、「不安だから禁止」で止まらずにClaude Codeを全社活用へ進める最短ルートです。