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を増やしても、その禁止が破られることはありません。

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

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

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

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

当社が導入企業に最初に配布している基本形です。プロジェクトの .claude/settings.json に置けばチーム全員に、~/.claude/settings.json に置けば個人の全プロジェクトに適用されます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(sudo *)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(git push *)"
    ]
  }
}

設定ファイルを自分で書く必要はありません。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には通常の確認動作を変えるパーミッションモード（計画だけ立てて実行前に確認するplanモード、編集を自動承認するacceptEditsモードなど）があり、その中のbypassPermissionsは確認をスキップして実行し続けるモードです。開発効率は上がりますが、コンテナや仮想マシンなど壊れても影響がない隔離環境以外では使わないのが原則です。組織としては、設定にdisableBypassPermissionsModeを"disable"と指定することで、このモード自体を使えなくできます。

設定ファイルは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に書くのが定石です。ここに書けば現場では解除できません

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

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

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

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

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