Claude Code の settings.json と権限設計 — 「確認地獄」と「やりすぎ許可」の間を取る

Posted at 2026-06-13

Claude Codeの権限まわりで、こんな状態になっていませんか。

コマンドのたびに「実行していいですか?」と聞かれて、毎回 y を押すのが地味につらい
かといって全部許可するのは怖い（rm -rf を勝手に流されたくない）
settings.json に何をどう書けば安全なのか、線引きが分からない
チームで使うとき、どこまで共有していいのか迷う

権限は「全部確認」か「全部許可」の二択ではありません。settings.json の permissions で、安全なものは許可・危険なものは拒否・迷うものは確認、と細かく線引きできます。この記事では、その設計の考え方と具体的な書き方をまとめます。

注意: settings.json のキーや権限ルールの記法は変わることがあります。本記事は執筆時点（2026年6月）の公式ドキュメントを参照していますが、実際の設定時は手元の最新ドキュメントで確認してください。

大前提: 権限は `allow / deny` で書ける

settings.json の permissions には、許可リスト（allow）と拒否リスト（deny）を書けます。公式ドキュメントの例はこうです。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

読み方はこうです。

allow: ここに書いたものは、確認なしで実行される
deny: ここに書いたものは、実行されない（最優先）

Bash(...) はコマンド、Read(...) はファイル読み取り、という形でツールごとに対象を指定します。

評価順序を理解する — 「deny が最優先」

権限ルールには評価順序があります。公式ドキュメントによると、deny → ask → allow の順で評価され、最初にマッチしたルールが勝ちます。

評価の順番（先にマッチした方が勝つ）
 ├─ ① deny  … 拒否（最優先）
 ├─ ② ask   … 確認する
 └─ ③ allow … 許可

これは安全側に倒れる設計です。deny が最初に評価されるので、拒否したいものは確実に拒否される。「うっかり allow に書いてしまったが deny にもある」場合でも、deny が勝ちます。

ワイルドカードで「コマンドの形」を許可する

毎回コマンドが少しずつ変わる（引数が違う）場合は、ワイルドカード * で「形」を許可できます。公式ドキュメントの例です。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

ここでの設計意図が分かりやすいです。

npm run *: npmスクリプト全般は許可（ビルド・テストなど）
git commit *: コミットは許可
* --version / * --help *: バージョン確認・ヘルプ表示は無害なので許可
git push *: push は拒否（リモートを勝手に書き換えさせない）

「コミットはOKだがpushはダメ」のように、読み取り・ローカル作業は許可、外部へ影響する操作は止めるという線引きがそのまま表現できます。

推奨する線引きの考え方

何を allow にして何を deny にするか。迷ったら次の基準が目安になります。

分類	例	推奨
読み取り・状態確認	`git status` / `git diff` / `ls` / テスト実行	`allow`（快適）
ローカルで完結する作業	`npm run build` / `git commit`	`allow` 寄り
破壊的・不可逆	`rm -rf *` / `git push --force`	`deny`（止める）
外部への送信・取得	`curl *`	必要時のみ確認、原則 `deny`
秘密情報の読み取り	`.env` / `secrets/**`	`deny`（読ませない）

特に重要なのが秘密情報の deny です。公式の例でも .env や secrets/** を deny に入れています。APIキーなどをうっかり読み込ませて会話に乗せてしまう事故を防げます。

OSによる書き分け（Windowsの場合）

コマンド系の権限は、使っているシェルに合わせて書きます。Windowsでは PowerShell(...) の形になります。公式ドキュメントの例です。

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

考え方は同じで、「状態確認・コミットは許可、削除系は拒否」です。自分の環境のシェルに合わせて書き分けてください。

チームで共有するときの注意

settings.json をリポジトリに含めれば、権限設定をチームで共有できます。ただし、全員が「安全だ」と納得できる範囲に絞るのが原則です。

共有する allow は、誰が見ても無害なもの（読み取り・テスト・ビルド）に限る
個人の好みで広げたい許可は、個人設定側に置く（共有リポジトリに混ぜない）
deny（秘密情報・破壊系）はチーム共通で固めておくと安全

権限は「速さ」と「安全」のトレードオフです。共有設定は安全側に寄せ、便利さは個人側で足す、という分担にすると揉めにくくなります。

まとめ

権限は settings.json の permissions（allow / deny）で細かく設計できる
評価順序は deny → ask → allow。拒否が最優先で安全側に倒れる
ワイルドカード * で「コマンドの形」を許可でき、「commitはOK・pushはダメ」が表現できる
秘密情報（.env / secrets/**）と破壊系は deny に固定するのがおすすめ

まずは**「毎回確認されてうんざりするコマンド」を allow に**、「絶対に止めたいコマンドと秘密ファイルを deny に入れるところから始めると、確認地獄とやりすぎ許可の両方を避けられます。

補足: 安全運用の土台になる無料リポジトリ

権限設計は「Claude Codeに何をどこまで任せるか」を決める作業です。CLAUDE.md でルールを明文化し、開発の型を整えておくと、権限の線引きも判断しやすくなります。私が使っているスキルを無料で公開しています。

無料スターター（GitHub・CC BY 4.0）:
https://github.com/noguso245-jpg/claude-code-skills-starter

CLAUDE.md設計・計画ファースト開発（PIV）・AIコミット戦略・アジャイルなプロンプト設計の4本のスキルが日本語・英語で入っています。ルールと進め方の土台を整えてから、権限を自分の運用に合わせて削り込むとスムーズです。まずは無料リポジトリから試してみてください。

最新のTipsはXでも発信しています: @k___n___t_1125

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up