settings.jsonとsettings.local.jsonの違いは何ですか？

settings.json（.claude/settings.json）はチームでGit共有する設定、settings.local.json（.claude/settings.local.json）はGit管理外の個人用オーバーライドです。あなた個人の許可ルールはlocal側に、チーム共通の禁止ルールはproject側（settings.json）に書くのが基本です。「今後確認しない」を選んだ許可は自動でsettings.local.jsonに保存されます。

allow・deny・askの優先順位はどうなっていますか？

denyが最優先で、マッチした操作は即ブロックされます。次にallowが自動承認、どちらにも当てはまらない操作はaskで確認プロンプトが出ます（既定モードによる）。同じ操作にallowとdenyが両方マッチした場合はdenyが勝ちます。

許可ルールが増えすぎたときはどうすればいい？

定期的に棚卸しして、ワイルドカードで束ねられるものはまとめ、使っていない具体コマンドは消しましょう。あるエンジニアはこの棚卸しで許可ルールの約9割を削減できたと報告しています。ルールは少なく・広すぎず・denyで下線を引く、が管理しやすい形です。

Claude Code settings.json 権限設定ガイド2026

Claude Codeのsettings.jsonで許可（allow）・拒否（deny）・確認（ask）ルールを書く方法を、公式ドキュメントをもとに実例つきで解説します。Tool(specifier)の書き方、deny優先の評価順、user/project/localの使い分け、.envを守る安全な初期設定、そして「許可ルールを棚卸しして9割減らせた」実例まで、Synthが手を動かせる形でまとめました。

まず結論：Claude Codeの権限は「denyで下線、allowで時短」

Claude Codeを使っていて「毎回この確認、面倒だな」と思ったこと、ありませんか。逆に「これは絶対触ってほしくない」ファイルもありますよね。その両方を1つのファイルで管理するのが settings.json の権限ルールです。要点から。

参照元: Claude Code Settings（Anthropic公式ドキュメント）
権限は permissions の中に allow（許可）・deny（拒否）・ask（確認） の3つのリストで書く。
評価はdeny が最優先。禁止にマッチした操作は、他で許可していても即ブロックされる。
ルールは Tool(specifier) 形式。例：Bash(npm run test *) Read(./.env) Edit(src/**)。
チーム共有は settings.json、個人用は settings.local.json（Git管理外）に分ける。
最初にやるべきは、.env や secrets を deny に入れて”下線”を引くこと。

この記事は、権限モードの選び方（default／acceptEditsなど）ではなく、**「ルールそのものの書き方」**に絞って解説します。モードの違いはClaude Code権限モード完全ガイドで扱っているので、あわせて読むと全体像が掴めます。

settings.jsonはどこにある？4つの置き場所

結論から言うと、Claude Codeの設定は4つの階層に分かれていて、どこに書くかで「共有されるか」「上書きされるか」が変わります。

種類	場所	Git共有	用途
ユーザー	`~/.claude/settings.json`	されない	全プロジェクト共通の個人設定
プロジェクト	`.claude/settings.json`	される	チーム共通の設定
ローカル	`.claude/settings.local.json`	されない（gitignore）	プロジェクトごとの個人上書き
管理（Managed）	`managed-settings.json` 等	IT配布	組織全体で強制する設定

優先順位は 管理＞コマンドライン＞ローカル＞プロジェクト＞ユーザー の順で、上のものが下を上書きします。会社で managed-settings.json が配られている場合、それは個人設定で外せません。

覚え方はシンプルで、「チームに強制したい禁止はproject、自分だけの許可はlocal」。この住み分けができていないと、うっかり自分の許可ルールをGitに載せてしまい、チーム全員に効いてしまう事故が起きます。

allow・deny・askの書き方（Tool(specifier)形式）

3つのリストは、すべて Tool(specifier) という共通の書式で書きます。Tool はツール名（Bash・Read・Edit・WebFetchなど）、specifier は対象を絞る条件です。公式ドキュメントの例をもとに、実際の形を見てみましょう。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

specifier では次のパターンが使えます。

完全一致：Bash(npm run lint) … このコマンドだけ許可
ワイルドカード *：Bash(npm run test *) … npm run test で始まる系を許可
再帰グロブ **：Read(./secrets/**) … secrets配下すべてを対象

⚠️ ここは気をつけて Bash(*) のように全コマンドをまとめて許可するのは危険です。allowを広く取りすぎると、危険なコマンドまで無確認で通ってしまう。allowは「安全だと自分で確認できたものだけ」に絞り、危ないものはdenyで明示的に塞ぐ。これが基本の型です。

なぜdenyが最優先なのか？

ここがルール設計の肝です。Claude Codeは、操作を実行してよいか判断するとき、まずdenyリストを見ます。理由は、禁止を最優先にしないと「うっかり広い許可」が事故につながるからです。

順番はこうです。

deny にマッチ → 即ブロック（他で許可していても実行しない）
allow にマッチ → 確認なしで自動実行
どちらにもマッチしない → ask（確認プロンプト）

たとえば allow に Bash(git *) を入れていても、deny に Bash(git push *) を入れておけば、pushだけは必ず止まります。「広く許可して、危険な一部だけdenyで抜く」という設計ができるのは、この評価順のおかげです。

許可ルールが増えすぎたら「棚卸し」する

運用していると、確認のたびに「今後許可」を押して、allowリストがどんどん膨らみます。あるエンジニアは、溜まった settings.json を見直したところ、許可ルールの約9割を削れたと報告しています（Claude Code の settings.json を棚卸ししたら、許可ルールの9割が消せた（ZENN））。

なぜそんなに減るのか。理由は、個別コマンドを1つずつ許可していくと、Bash(npm run test:unit) Bash(npm run test:e2e) のような似たルールが量産されるからです。これらは Bash(npm run test *) の1行にまとめられます。

棚卸しのコツはこの3つです。

✅ ワイルドカードで束ねる：似た許可は * でまとめる
✅ 使っていない具体コマンドを消す：一度きりの許可は残さない
✅ denyで下線を引き直す：許可を広げた分、危険なものはdenyで塞ぐ

リストは「多くて具体的」より「少なくて、広すぎず、denyで守られている」方が、結局は安全で読みやすくなります。

あなたへの影響

Claude Codeを毎日使う人: まず deny に .env と secrets/** を入れてください。10分の作業で、機密ファイルがAIに読まれる事故の確率が下がります。
チーム開発の人: 共通の禁止は .claude/settings.json（Git共有）、自分の許可は settings.local.json に分けましょう。混ぜると事故ります。
これから始める人: いきなり全許可（bypass系）にせず、confirmを面倒がらずに数日使い、溜まった許可を後で棚卸しする。この順番がいちばん安全に速くなれます。

まとめ

Claude Codeの権限設定は、突き詰めると「denyで守り、allowで時短する」の一言に尽きます。deny最優先という評価順を理解すれば、「広く許可して危険な一部だけ抜く」という賢い設計ができるようになります。まずは .env と secrets をdenyに入れる——今日はそこだけでも十分です。慣れてきたら、膨らんだallowを棚卸しして、少なく強いルールに育てていきましょう。