Claude Codeの仕組み講座（講師のためのエンジニア水準）

区分4 安全と設定★★

No.15 設定ファイルの階層と優先順位

設定ファイルは、Claude Code 本体の動きを決める「社内規程」です。置き場所が複数あり、同じ項目が重なった時にどれが勝つのかが、受講生の混乱の元です。この単元では、階層と優先順位と、見て確かめる方法を扱います。
目次
  1. 第0章 前提知識
  2. 第1章 4つの置き場所
  3. 第2章 見て、確かめて、直す
  4. 確認問題

第0章 前提知識

① settings.json　：本体の動きを決める設定ファイル

settings.json は、許可ルール（No.13）、フック（No.10）、使うモデル、環境変数（プログラムに渡す設定値）などを書く設定ファイルです。 書き方は JSON という形式（{ } の中に「項目名: 値」を並べる）です。

CLAUDE.md との違いを、先に押さえます。

読む主体 性質
CLAUDE.md AI（読んで考える） お願い
settings.json Claude Code 本体（そのまま実行する） 鍵・設定

たとえ話にします。 CLAUDE.md が口頭の指示書、settings.json がシステムの設定画面です。

② 「作業場」と「範囲」

この講座では、いま開いているフォルダを「作業場」と呼びます。公式の説明では「プロジェクト」です。 設定は、誰に効くかで置き場所を分けます。この「効く範囲」を、この講座では「範囲」と呼びます（公式の言葉はスコープです）。

第1章 4つの置き場所

① 階層の全体像 必ず覚える

階層 場所 誰に効くか
管理（組織） 管理者が配る設定（managed-settings.json、端末管理＝会社が社員のパソコンをまとめて管理する仕組み、claude.ai の管理画面） 組織の全員
ユーザー ~/.claude/settings.json 自分の、全部の作業場
作業場（共有） .claude/settings.json その作業場に関わる全員（git に入れて共有する）
ローカル .claude/settings.local.json 自分の、その作業場だけ

選び方の考え方は、「誰に効かせたいか」です。

git は、ファイルの変更履歴を管理する道具で、共有するフォルダは git で管理します（公式の言葉ではリポジトリ）。 ローカルの設定ファイルは、Claude Code が git の共有の対象外にしてくれます。手で作った場合は、.gitignore（git に共有させないファイルを書いておくファイル）に自分で書き足します。 「今後は聞かない」を選ぶと、Claude Code 自身がローカルの設定ファイルに allow ルールを書き足すので、自分で書いていないのに設定が増えていることがあります。

② 優先順位 必ず覚える

同じ項目が複数の階層にある時は、強い階層の値が使われます。 強い順は、次のとおりです。

  1. 管理（組織）
  2. 起動時に渡す設定（claude --settings で、その会話だけ）
  3. ローカル
  4. 作業場（共有）
  5. ユーザー

つまり、「近い物が勝つ」で、一番上は組織です。 管理設定は、ユーザーや作業場の設定、起動時の指定でも上書きできません。

③ 他の機能との比較 必ず覚える

同じ名前の物が複数の範囲にある時の強さの順番は、機能ごとに違います。 講師が混乱しやすいので、ここに1つの表にまとめます（強い順）。

機能 強い順 気をつける点
設定 管理 → 起動時の指定 → ローカル → 作業場 → ユーザー 作業場が自分より強い
スキル 管理（組織） → 自分（ユーザー） → 作業場 設定とは逆で、自分が作業場より強い
サブエージェント 管理 → 起動時の指定 → 作業場 → ユーザー → プラグイン 設定と同じく、作業場が自分より強い
MCP（道具を出すサーバーの接続） ローカル → 作業場 → ユーザー → プラグイン → claude.ai のコネクタ 管理者が決めた物は、これらより上
フック（決まった場面で自動で動く処理） 範囲の順ではなく、許可の判定の中で決まる。フックの deny は他より優先、allow は deny のルールを越えられない（No.10） 詳しくは No.10
プラグイン 名前に「プラグイン名:」が付くので、同名でも競合しない スキルとサブエージェントは、プラグインのものも両方使える

なぜこの順になっているかは、公式には書かれていません。「機能ごとに決まっている」と覚えてください。

特に紛らわしいのが「ローカル」です。 設定の「ローカル」は、作業場の中の .claude/settings.local.json です。MCP の「ローカル」は、自分のホームフォルダにある ~/.claude.json に、その作業場の分として保存されます。名前は同じでも、別の物です。

環境変数は、この階層の一員ではありません。項目ごとに、どちらが先かが決まっています。 たとえば、シェルで設定した ANTHROPIC_MODEL は、どの設定ファイルの model よりも先に使われます。一方、ANTHROPIC_DEFAULT_MODEL は、どのファイルにも model が無い時だけ使われます（どちらも使うモデルを決める環境変数です）。

④ リストは上書きでなく合体 必ず覚える

許可の一覧（permissions.allow など）のようなリストの項目は、上書きでなく合体します。 各ファイルが、他のファイルの項目を消さずに足せます。

ここで、No.13 の知識がつながります。 deny は、どの階層にあっても、allow より先に調べられます。 ユーザーが allow した物を、作業場が deny すれば止まります。 その逆（ユーザーの deny を、作業場の allow で解除する）はできません。

つまり、「単純な値は強い階層が勝つ」「リストは合体し、deny は最強」と分けて覚えます。

⑤ 組織の締め付けには例外がある さらっと

管理設定が最上位ですが、「より厳しい値なら、下の階層の指定も採用する」項目が少しだけあります。 たとえば、作業場の外のファイルを読めなくする設定（permissions.blockReadsOutsideWorkingDirectories）は、どの階層で true にしても有効になります。 これは安全側に倒すための例外で、細かい一覧は公式を引けば足ります。

○ 数字・項目名は2026年10月時点の公式。設定の項目は版で増えます
○ よくある勘違い：「作業場の設定が、自分のユーザー設定を消す」→ ×。リストは合体します。単純な値だけが、強い階層で上書きされます
○ 関係する単元：No.13 許可ルール、No.10 フック

第2章 見て、確かめて、直す

① 何が読み込まれたかを見る 必ず覚える

/status は「どのファイルを読んだか」までで、設定の項目ごとの出所までは示しません（許可ルールの出所は /permissions で見えます）。

② 直し方と、よくある落とし穴 必ず覚える

設定ファイルは厳密な JSON です。 // のコメントや、最後の項目の後ろのカンマは、書き間違いとして扱われます。起動時に「Settings Error」が出ます。

つまずきやすい点が3つあります。

  1. 共有の設定ファイルの allow は、フォルダを信頼するまで効かない。作業場の .claude/settings.json の許可ルールは、初めて開いた時の「信頼しますか」の確認を済ませてから有効になります。deny は、制限するだけなので確認を待たずに効きます
  2. 自動モード（defaultMode: "auto"）は、作業場の設定ファイル（共有もローカルも）に書いても効かない。公式にそう決められていて、理由は書かれていません。ユーザー設定に書きます
  3. 管理設定で決まっている項目は、自分では変えられない

やり方は、AIに頼めば足ります。 頼み方の例：「この作業場の .claude/settings.json に、npm test（テストを動かすコマンド）を許可するルールを足して」。 書き換える前に、どの階層（誰に効かせたいか）かを一緒に決めるのがコツです。

③ 手元の実物を読む さらっと

講師としては、自分の ~/.claude/settings.json を1回開いて読んでおくと、説得力が出ます。 鍵（APIキーなど、外のサービスを使うための合言葉）のような秘密は、共有される作業場のファイルには書きません。

○ 受講生によく聞かれる質問：「チームと自分の設定が食い違った。どっちが勝つ？」
→ 値なら、作業場（共有）よりローカルが強いので、自分だけの上書きはローカルに書けます。許可の一覧なら合体します。ただし deny は最強です
○ 受講生によく聞かれる質問：「設定を変えたのに、効いていない」
→ /status で読み込み元を確認し、claude doctor で書き間違いを探します。より強い階層（特に管理）で決まっていることもあります
○ 受講生によく聞かれる質問：「許可を聞かなくなったのは、いつから？」
→ 「今後は聞かない」を選ぶと、ローカルの設定ファイルに allow が増えます。/permissions で出所が見えます
○ 講義で使えるたとえ：会社の規程集。就業規則（管理）、部署の決まり（作業場）、自分のメモ（ローカル）、本人の標準（ユーザー）。会社の規程が一番上
○ 関係する単元：No.13 許可の判定順

誰に効かせたいかで置き場所を選ぶ。強さは、管理 → 起動時 → ローカル → 作業場 → ユーザー。リストは合体し、deny は最強。見るのは /status と /permissions。

確認問題

問1　「自分の全部の作業場で、毎日使うフックを入れたい」。どこに書きますか？

問2　ユーザー設定と作業場（共有）の設定で、モデルの指定が違っています。どちらが使われますか？

問3　ユーザー設定で Bash(npm *) を allow にし、作業場の設定で Bash(npm publish *) を deny にしました。npm publish は？

問4　「なぜこの操作は聞かれずに通ったのか」を調べたいです。最初に見るのは？

出典：Claude Code 公式ドキュメント「Settings files and precedence」（https://code.claude.com/docs/en/settings）「Configure permissions」（https://code.claude.com/docs/en/permissions）「Choose a permission mode」（https://code.claude.com/docs/en/permission-modes）。強さの比較表は「Skills」（https://code.claude.com/docs/en/skills）「Subagents」（https://code.claude.com/docs/en/sub-agents）「MCP」（https://code.claude.com/docs/en/mcp）。2026年10月13日に確認

← 前へ次へ →