Claude Codeのpermissions設定レシピ集 — チーム配布用settings.jsonの実例（職種別・リスク段階別）

この記事の使い方 — 3つの前提だけ押さえる

レシピはすべて settings.json の permissions ブロックとして書いてあります。仕組みの解説は権限設定（permissions）の解説記事に譲り、ここではコピーして使う前に確認してほしい3点だけ押さえます。

1. 1評価順は deny → ask → allow で固定 — 最初に一致したルールが適用され、ルールの具体性は順序を変えません。「Bash(aws *) を禁止しつつ Bash(aws s3 ls) だけ許可」のような例外は作れないので、禁止は本当に禁止したいものだけに絞ります
2. 2置き場所で適用範囲が決まる — チーム全員に配るならリポジトリの .claude/settings.json、自分だけなら ~/.claude/settings.json、全社に強制するなら管理者配布のmanaged settingsです。個人が確認画面で「今後確認しない」を選んだ許可は .claude/settings.local.json に溜まります
3. 3手で書かなくてよい — レシピをClaude Codeに読ませて「うちの環境に合わせて調整して」と頼めば、設定ファイルを書いてくれます。人がやるのは中身の確認だけです

レシピ0: 全社共通の土台 — 職種を問わず最初に入れる

どの職種のレシピも、この土台の上に積みます。中身は「秘密情報を読ませない」「OSの管理者権限を渡さない」「消す・公開する操作は人が確認する」の3点だけです。

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

この土台だけでも、「AIが秘密情報を読んで外に出す」「勝手に消す・公開する」という導入時の不安の大半に設定レベルで答えられます。

何が起きうるかの整理はClaude Codeの危険性の記事、対策の全体像はセキュリティ対策の記事をご覧ください。

リスク段階の考え方 — 何を足すかは「業務」ではなく「環境」で決める

レシピを職種別に分ける前に、共通の物差しを1つ置きます。どこまで自動で動かしてよいかは、担当者の職種よりも「壊れたときの影響範囲」で決まるという考え方です。同じ開発者でも、本番データに触れる端末と使い捨ての検証環境では書くべき設定が違います。

レシピ1: 非エンジニアの業務チーム向け — 資料・データ業務を安心して任せる

資料作成やデータ整理にClaude Codeを使う非エンジニアのチーム向けです。土台に加えて、Bashからの外部通信を止め、Webアクセスは会社が決めたドメインだけWebFetchで許可します。

公式ドキュメントも、URLをコマンド引数で縛る書き方は書き方の揺れですり抜けるため、curl などをdenyしてWebFetchのドメイン許可で管理する構成を推奨しています。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(sudo *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(git push *)"
    ],
    "allow": [
      "WebFetch(domain:code.claude.com)",
      "WebFetch(domain:*.example.co.jp)"
    ]
  }
}

• WebFetch(domain:*.example.co.jp) は自社ドメインに書き換えて使います。*. はサブドメインだけに一致し、example.co.jp そのものには一致しないので、必要なら2行に分けて書きます
• allowに書いていない操作は、既定モードによって「確認が出る」か「安全チェック付きで自動承認される」かが変わります。導入初期は確認画面で内容を読み、問題なければ「今後確認しない」を選んで許可を育てるのが最も安全です
• 「削除は絶対にさせたくない」チームなら Bash(rm *) をaskからdenyへ移します。ただしdenyにすると不要ファイルの片付けも人がやることになるので、まずはaskで運用してから判断してください

レシピ2: 開発チーム向け — 定型作業を許可し、取り消せない操作だけ人が見る

テスト・lint・コミットのように毎日何十回も繰り返す操作を許可し、リモートへの公開・削除・履歴の改変だけを確認に残す構成です。確認回数が激減する一方、守るべき線は土台と同じです。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(sudo *)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(git push *)",
      "Bash(git reset *)",
      "Bash(git rebase *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(npx prettier *)",
      "Bash(npx eslint *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ]
  }
}

• git push はaskで一括して拾う — --force だけを別にdenyしたくなりますが、git push origin --force のようにオプションの位置が変わると一致しません。「pushは常に人が見る」に寄せる方が確実です
• 実行系ラッパーの広い許可は避ける — npx や docker exec のように「後ろに続くものを実行する」コマンドは、Bash(npx *) と書くと後ろが何であれ通ってしまいます。上の例のように Bash(npx prettier *) と中身まで含めて1行ずつ書きます
• コマンドを && でつないでも抜け道にはならない — 複合コマンドは部分ごとに判定されるので、npm test && rm -rf dist は rm の部分でaskに引っかかります
• パッケージのインストールもインストール時スクリプトが動くため、厳しめにしたいチームは Bash(npm install *) をaskに足します

レシピ3: MCP連携を使うチーム向け — 読み取り系だけ許可する

NotionやGitHubなど外部ツールとMCPで連携しているチームでは、サーバー単位・ツール名の前方一致で「読む操作だけ許可」する書き方が使えます。書き込み系（作成・更新・削除）はallowに入れず、確認に残します。

{
  "permissions": {
    "allow": [
      "mcp__github__get_*",
      "mcp__github__list_*",
      "mcp__github__search_*"
    ]
  }
}

• mcp__ の後ろはClaude Codeに登録したサーバー名、その後ろがツール名です。登録済みのサーバーとツール名は /mcp コマンドで確認できます
• allowのワイルドカードは mcp__<サーバー名>__ を書いた後ろでだけ使えます。mcp__* のような書き方はallowでは無視されます（denyなら「MCPを全部止める」の意味で使えます）
• 「サーバー全体をask、読み取りだけallow」は成立しません — askはallowより先に評価されるため、mcp__github__* をaskに書くと読み取り系も毎回確認になります。allowに読み取り系だけを書き、残りは既定の動作（確認）に任せるのが正解です

レシピ4: 情報システム部門の全社配布向け — 外せない禁止だけをmanaged settingsに

従業員が増えると「各自で設定してください」では統制が効きません。管理者がOSの管理領域に置くmanaged settingsは、ユーザー設定・プロジェクト設定のどちらでも上書きできない全社ポリシーとして機能します。ここに書くのは現場が上書きできては困るものだけに絞るのがコツです。

{
  "permissions": {
    "deny": [
      "Read(//**/.env)",
      "Read(//**/.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(sudo *)"
    ],
    "disableBypassPermissionsMode": "disable"
  }
}

• パスはスラッシュ2本の絶対指定にする — スラッシュ1本で始まるパスは「設定ファイルの置き場所」が基準になり、たとえばユーザー設定に Read(/secrets/**) と書くとプロジェクトではなく ~/.claude/secrets/ を指します。PC上のどこにあっても効かせたい禁止は、上のレシピのようにファイルシステムのルート（スラッシュ2本）から書くか、~/ 始まりのホーム基準で書きます
• disableBypassPermissionsMode で確認スキップを封印 — 確認を一切出さないbypassPermissionsモードを、現場では有効にできなくします。同様に disableAutoMode を "disable" にすればautoモードも封じられます（2026年8月時点）
• 現場のallowを許すかどうかは方針で決める — 「管理者が配ったルール以外は一切適用しない」に振り切るなら、managed settingsに allowManagedPermissionRulesOnly を有効化して置きます。ただしレシピ1〜3のようなチーム設定も無効になるので、統制と現場効率のどちらを優先するかを先に決めてください
• 配布はJamf・Intuneなどの端末管理ツールから、OSのポリシー機能として行えます。配置パスと配布方法はpermissions記事のmanaged settingsの節にまとめています

配って初めて分かるはまりどころ5つ

レシピをそのまま配ったあとに「効いていない」「思ったより厳しい」と相談を受けるポイントを、公式仕様にもとづいて先回りしておきます。

1. 1プロジェクトのallowは「フォルダを信頼」してから効く — リポジトリの .claude/settings.json に書いたallowは、そのフォルダを初めて開いたときの信頼確認ダイアログを受け入れて初めて適用されます。deny・askは信頼前でも効きます。「配ったのに確認が減らない」の原因の多くはこれです
2. 2.claude/ フォルダや .git への書き込みはallowでは事前承認できない — Claude Code自身の設定やリポジトリ状態を守る保護パスは、allowルールに書いても自動承認されません。「設定ファイルの編集まで自動化したい」は現状の仕様では通らないと知っておくと迷いません
3. 3Read・Editのdenyは間接アクセスには効かない — AIが書いたPythonスクリプトがファイルを開く動きまでは止められません。OSレベルで確実に止めたい場合はサンドボックス機能を併用します。permissionsとサンドボックスは重ねて使う前提の設計です
4. 4「今後確認しない」は個人ファイルに溜まる — 確認画面で選んだ許可は .claude/settings.local.json（リポジトリのルート）に個人ごとに保存されます。2週間ほど運用したら各自のこのファイルを持ち寄り、共通して増えた許可をチームの .claude/settings.json に昇格させると、レシピが現場の実態に追いつきます
5. 5autoモードを既定にする指定はプロジェクト設定では効かない — defaultMode に "auto" を書いて効くのはユーザー設定（~/.claude/settings.json）かmanaged settingsだけです。逆に「planモードを既定にする」などはプロジェクト設定でも効きます（プランモードの記事参照）

配布と運用の流れ — 土台を配り、育て、昇格させる

レシピは配って終わりではなく、運用しながら育てるものです。当社が導入支援で使っている流れは次の3ステップです。

1. 1土台（レシピ0）をチームの設定ファイルに入れて配る — 置き場所はリポジトリの .claude/settings.json。最初はallowを欲張らない。denyとaskだけで「これは絶対に起きない」を先に作る
2. 22週間、各自の「今後確認しない」を溜める — 職種ごとに実際に増えた許可を持ち寄り、レシピ1〜3を自チームの実態に合わせて調整する。ここで初めてallowを厚くする
3. 3上書きされては困る禁止だけをmanaged settings（レシピ4）へ昇格する — 全社に強制するのは秘密情報の読み取り禁止・sudo禁止・bypassの封印程度に留め、現場効率を殺さない

permissionsだけで統制が完成するわけではありません。「入力してよい情報の区分」「インシデント時の報告先」といった運用ルールは設定ファイルでは伝わらず、導入前チェックリストのような形で明文化し、研修で定着させる必要があります。

また、より細かい条件で止めたい場合（特定URLへのcurlだけ止める等）はhooksでルールを拡張できます。

当社のClaude Code法人研修では、本記事のレシピを受講企業の環境に合わせて調整し、権限設計・利用ガイドライン・研修を1セットで整えるところまで伴走しています。