29｜ルールの階層と優先度：影響範囲が広いほど、優先度は低い

29-1 ルールが増えると、必ず矛盾する

07番で作った CLAUDE.md にルールを書き足していくと、あるとき必ずぶつかります。全プロジェクト共通のルールと、この案件だけのルールが、正反対のことを言っている状態です。

たとえば、~/.claude/CLAUDE.md（あなたの全プロジェクトに効く）に「ブランドの声は落ち着いたトーンで」と書いてある。一方、ある案件のクライアントは「明るく親しみやすく」を求めている。どちらも正しい指示です。

~/.claude/CLAUDE.md      → 「ブランドの声は落ち着いたトーンで」
./client-a/CLAUDE.md     → 「明るく親しみやすいトーンで」

この状態でClaudeCodeを動かすと、どちらが採用されるかは安定しません。公式ドキュメントも「2つのルールが矛盾する場合、Claudeはどちらか一方を任意に選ぶことがある（Claude may pick one arbitrarily）」と明記しています。その場で「今回は明るくして」と口頭で直すことはできますが、次に同じ状況が来たとき、同じ結果になる保証はありません。

29-2 抽象度が高いほど影響範囲が広く、優先度は低い

ここが直感に反するところです。「全体の共通ルール」は、いちばん偉そうに見えて、いちばん弱い。

理由は単純です。全体ルールはすべての成果物に適用されます。だからこそ、すべての成果物が満たせるものしか書けません。一つでも例外があるなら、そもそもそこに書いてはいけない。

逆に「このLPの、この一箇所だけ」というルールは、影響範囲が針の先ほどしかありません。だからこそ、そこでは確実に守られます。CSSを書いたことがあれば、詳細度と同じだと分かるはずです。body { color: black } より #header .title { color: red } が勝つ。範囲が狭いほど強い。

ClaudeCodeでは、どのファイルがどの層か

ClaudeCodeは、作業ディレクトリから上へディレクトリをたどりながら CLAUDE.md を探して読み込みます。つまり、フォルダの深さがそのまま層になります。

~/.claude/CLAUDE.md            ← 全体：全案件に効く
~/.claude/rules/*.md           ← 全体：個人の好み

client-a/                      ← ここでClaudeCodeを起動
├── CLAUDE.md                  ← 案件：この案件すべてに効く
├── .claude/
│   ├── settings.json          ← 案件：権限・環境変数（チームで共有）
│   ├── settings.local.json    ← 例外：自分のマシンだけ（gitignore）
│   └── rules/
│       └── tone.md            ← 相手：paths指定で対象を絞れる
├── CLAUDE.local.md            ← 例外：自分だけ（gitignore）
├── design.md                  ← 08番のデザイン仕様
└── lp/
    └── CLAUDE.md              ← 成果物：lp/ の中を触るときだけ読まれる

設定ファイル（settings.json）も同じ向き

文章のルールだけでなく、権限や環境変数を決める settings.json も、まったく同じ「狭いほど強い」で並んでいます。

ただし 権限（permissions）だけは例外で、各層が上書きではなくマージされます。どこか一つの層で deny されていれば、他の層で allow していても拒否されます。禁止は強いほうに倒れる、という設計です（06番）。

29-3 読む順と、勝つ順は逆

混乱しやすいので、分けて覚えます。

• 読む順　広いほうから狭いほうへ降りる。全体 → 案件 → 相手 → 成果物 → 例外
• 勝つ順　その逆。狭いほうが強い

ここで重要なのは、ClaudeCodeが各層を上書きしているのではなく、すべて連結して読んでいることです。公式ドキュメントにも「発見されたすべてのファイルは、互いを上書きするのではなく連結される」とあります。つまり各層はフィルタであって、置き換えではありません。

上から降りながら、選択肢がだんだん絞られていくイメージです。

29-4 「ルールがない」と「まだ確認していない」は別物

相手のルールが何も書かれていなければ、その層は飛ばして次へ進みます。上の層のルールがそのまま生きる。これは正常な動作です。

ただし、それは相手のドキュメントを開いて「特に指定なし」と確認した場合の話です。開いてすらいないのなら、それは通過ではなく手抜きです。

AIに任せるとき、ここが最も事故る場所です。ClaudeCodeには、確認できる手段が用意されています。

1. /memory を実行するそのセッションで実際に読み込まれている CLAUDE.md・CLAUDE.local.md・rules ファイルの一覧が表示されます。ここに出てこないファイルは、ClaudeCodeから見えていません。
2. サブディレクトリの読み込みタイミングを理解するサブフォルダの CLAUDE.md は起動時ではなく、そのフォルダのファイルを実際に読むときに読み込まれます。「まだ読まれていないだけ」を「ルールがない」と誤解しないこと。
3. 参照した証拠を残させるNotion（14番）やドキュメントを参照させるときは、「参照したページのURLを必ず出力に記録する」と指示しておく。確認したという証拠が残ります。

27番で作ったレビューAIに、この記録の有無をチェックさせるのが実用的です。「参照URLが書かれていなければ差し戻す」という基準を1行足すだけで、確認漏れが検出できます。

29-5 矛盾は、上の層が書きすぎているサイン

階層がきれいに入れ子になっていれば、矛盾は原理的に起きません。起きたということは、上位の層に「配下の一部しか満たせないこと」が書いてあるということです。

29-1の例に戻ります。「相手ルールのほうが具体的だから採用」と処理すると、その場は動きます。ですが間違いは修正されません。次の案件でも、その次でも、同じ衝突が起き続けます。

正しい対処は、全体ルールから「ブランドの声」を降ろすことです。あれは自社の発信に適用されるルールであって、顧客の代わりに書く仕事には適用されない。一つ下の層に置くべきものでした。

矛盾は、バグではなくルール設計の欠陥を知らせるアラートです。

ルールを書くときの唯一の原則。上位層には、配下のすべてが満たすものだけを書く。

29-6 例外は、安全と法務だけ

誇大表現をしない。他人の著作物を勝手に使わない。個人情報を書かない。

これらは最も広く適用され、かつ最も強い。下位のどの層からも上書きできません。だから29-2の図では、ピラミッドの一部ではなく、ピラミッドが立っている地面として描いています。

そしてもう一つ、重要なことがあります。地盤は、文章では守られません。

CLAUDE.md に「勝手に投稿しないこと」と書いても、それはお願いです。公式ドキュメントの表現を借りれば、CLAUDE.md は「コンテキストであって、強制される設定ではない」。長い作業の途中や曖昧な状況では、従わないことがあります。本当に守りたいなら、権限設定やフック（実行前に走るチェック処理）で機械的に止める必要があります。

ClaudeCodeで地盤を作る手段は3つです。

• permissions.deny：特定のコマンドやファイルパスへの操作を禁止する。どこか一つの層でdenyされていれば、他の層のallowでは覆せません。
• フック（PreToolUse）：ツールが実行される直前に、こちらのスクリプトを走らせて可否を判定する。AIの判断に関係なく必ず動きます。
• 承認モード：実行のたびに人間に確認を求める。06番で扱った考え方が、そのままここに効いてきます。

29-7 どこで使えるか

この構造はClaudeCodeへの指示に限りません。影響範囲と優先度を逆向きに並べる、というだけの話なので、ルールが増える場所すべてに使えます。

「なんとなくルールが増えて、誰も守らなくなった」という状態は、たいてい全部を同じ平面に並べていることが原因です。階層に置き直すだけで、どれが強いかが自明になります。

点検のしかた

1. ~/.claude/CLAUDE.md を開く一行ずつ「これは本当に全部の案件で守れるか」を確かめる。
2. 守れない行を見つける一つでも例外がある行が、降ろすべきルールです。
3. 一つ下の層へ移すその案件の CLAUDE.md、あるいは .claude/rules/ に paths 付きで移す。
4. 安全・法務の行を分ける「絶対に守らせたい」ものが文章として書かれていたら、permissions.deny やフックに移す。文章のままにしない。
5. /memory で確認する移したあと、意図したファイルが読み込まれているかを確認する。