レイヤーが優先順位付けされず、連結される理由
まず、指示を記述する場所（サーフェス）がいくつあるかから始めましょう。ほとんどの人は、自分が思っている以上に多くの場所で実行しています。
ドキュメントには、CLAUDE.mdの場所が「最も広いスコープから最も具体的なスコープへの読み込み順」でリストされています。IT/DevOpsによって管理される「組織全体の指示」を保持すると説明されている管理ポリシー（managed policy）ファイルは、システムパス（macOSでは /Library/Application Support/ClaudeCode/CLAUDE.md、LinuxおよびWSLでは /etc/claude-code/CLAUDE.md、Windowsでは Program Files のパス）に配置されます。ユーザー指示（User instructions）は ~/.claude/CLAUDE.md に、プロジェクト指示（Project instructions）は ./CLAUDE.md または ./.claude/CLAUDE.md に配置されます。
そして、忘れがちなものもあります。ワーキングディレクトリより上のディレクトリ階層にあるすべての CLAUDE.md は、起動時に読み込まれます。それらと並行して存在するすべての CLAUDE.local.md も読み込まれます。さらに、配下のサブディレクトリにあるファイルも検出されます。「起動時に読み込むのではなく、Claudeがそれらのサブディレクトリ内のファイルを読み込むときに含まれます。」また、.claude/rules/ には、好きなだけMarkdownファイルを配置できます。
6つのサーフェスに加えて、ディレクトリレベルごとに1つ、さらにルールフォルダがあります。では、その仕組みを見てみましょう。
「検出されたすべてのファイルは、互いに上書きするのではなく、コンテキストに連結されます。」
連結（Concatenated）です。勝者がマージされるわけでも、上書きされるわけでもなく、追加（appended）されます。順序はドキュメント化されています。「コンテンツはファイルシステムのルートからワーキングディレクトリに向かって順序付けされる」ため、「Claudeを起動した場所に近い指示が最後に読み込まれる」ことになり、ディレクトリ内では CLAUDE.local.md が CLAUDE.md の後に来るため、「あなたの個人メモは、そのレベルでClaudeが最後に読み込むものになる」とされています。しかし、順序は優先順位ではありません。最後に読み込まれるからといって、それが優先されるわけではありません。
ルールフォルダは、これを暗黙的ではなく明示的にしています：
「pathsフロントマターのないルールは、起動時に.claude/CLAUDE.mdと同じ優先度で読み込まれます。」
同じ優先度。はっきりとそう述べられています。ドキュメントにはこれらのレイヤー間のタイブレーカー（優先順位の決定方法）についての記載はありません。その理由は、ドキュメント全体の中で最も重要な一文にあります：
「Claudeはこれらを強制的な設定ではなく、コンテキストとして扱います。」
これが根本の原因です。これらのファイルは、優先順位エンジンによって解決される設定ではなく、プロンプトに配置されるテキストです。ドキュメントはその結果について率直に述べています。「これらは強制的な設定ではなくコンテキストであるため、指示の書き方が、Claudeがどれだけ確実にそれに従うかに影響します。具体的で簡潔、かつ適切に構造化された指示が最も効果的です。」また、エスケープハッチについても言及しています。「Claudeがどう判断するかにかかわらずアクションをブロックするには、代わりに PreToolUse フックを使用してください。」
これは不満を言うよりも、評価すべき点です。他のツールは優先順位を公開しています。GitHub Copilotは個人指示を最優先、組織指示を最下位として文書化しています。Tabnineは管理コンソールがローカルのガイドラインファイルよりも優先されると文書化しています。Cursorはチームルールがプロジェクトルールやユーザールールよりも優先されると文書化しています。これらはそれぞれ決定論（確実性）を得る代わりに、1つのファイルからモデルが何を見るかを知る能力を失っています。Claude Codeの答えは、すべてがコンテキストであり、何かが暗黙的に勝つことはないというものであり、調整作業をあなたに委ねています。
今年これがさらに重要になる理由は、管理ポリシーレイヤーにあります。組織はすべてのマシンに CLAUDE.md をデプロイできるようになり、最近の Claude Code のリリースでは、管理された claudeMd がトリガーしていたセキュリティ承認ダイアログが削除されたため、静かに適用されるようになりました。そのファイルはあなたのプロジェクトを知らない人々によって書かれ、あなたのファイルと連結され、矛盾が生じたときには何も仲裁しません。これが、Claude forgetting house conventions（Claudeがハウスルールを忘れる）といった多くの報告の背後にあるメカニズムです。ルールはコンテキスト内にあり、それに反対するものも同様にコンテキスト内にあるのです。
代わりに試されがちなこと
プロジェクトファイルでルールをより強く繰り返す。 ドキュメントには具体的で適切に構造化された指示の方が確実に従うと書かれているため、効果がある場合もあります。しかし、ファイルが肥大化し、2つの強調された矛盾する指示は、依然として2つの矛盾する指示のままです。
最後に読み込まれるため、ルールを CLAUDE.local.md に記述する。 「最後＝勝者」という前提に基づいています。ドキュメントは順序について説明しており、優先順位については説明していません。また、ファイルは上書きされるのではなく連結されると明記されています。
ユーザーレベルのファイルを削除する。 効果的ですが、代償が大きいです。あなたの個人的な好みが問題だったのではなく、それとプロジェクト標準との間の真の競合が問題だったのです。
すべてを1つの巨大なプロジェクト CLAUDE.md に移動する。 これによりファイル間の競合は解消されますが、サイズに関するガイダンスに違反します。ドキュメントでは1ファイルあたり200行未満に抑えることを推奨しており、長いファイルは「より多くのコンテキストを消費し、遵守率を低下させる」と指摘しています。競合の問題を遵守率の問題とトレードオフしたことになります。
どのルールに従っているかをClaudeに尋ねる。 合理的な診断方法であり、/context は読み込まれたメモリファイルを実際にリストし、/status は適用されている管理ソースの名前を表示します。しかし、モデルに任意の選択について内省を求めても、その選択が任意であることに変わりはありません。
フックを使用する。 ハードな制約に対するドキュメント自身の推奨事項であり、アクションをブロックするためには正しい方法です。しかし、フックはチームが決定した2つのスタイル規約のどちらをClaudeが採用すべきかを伝えることはできません。
パターンとして、これら6つのアプローチはすべて競合に「勝とう」としています。競合そのものを排除するものは一つもありません。そして、2つの命令間の競合は、それらに優先順位を付けることでは排除できません。なぜなら、優先順位を付けるために必要な情報はどちらのファイルにも含まれていないからです。
解決策：矛盾を解決可能にするのではなく、不可能にする
3つのステップ：実際に何が読み込まれているかを確認し、各レイヤーに1つの役割を与え、矛盾が蓄積する原因を排除します。
ステップ 1：実際にコンテキストにあるものを列挙する
セッションで /context を実行し、「Memory files」の下にあるリストを確認します。これが信頼できる唯一の情報源であり、日常的に驚きをもたらします。誰かが昨年追加した3つ上のディレクトリの CLAUDE.md、忘れていた CLAUDE.local.md、すべて無条件で読み込まれる .claude/rules/ 内の4つのファイルなどです。/status も実行し、適用されている管理ソースの名前を示す Setting sources 行を確認して、組織ファイルが有効になっているかどうかを把握してください。
監査中に注意すべき、文書化されている2つの癖があります。インポートは実際のコンテンツです。CLAUDE.md は @path/to/import 構文を使用して他のファイルを取り込むことができ、それらは「起動時に展開されてコンテキストに読み込まれる」ため、1行のファイルでも大きくなる可能性があります。また、インポートのパースは「Markdownのコードスパンやフェンス付きコードブロックをスキップ」します。バックティックス内のパスはリテラルのままですが、バックティックスの外にある同じパスはファイルをインポートします。バックティックスなしでパスを記述している場合、言及するつもりだったものをインポートしてしまっている可能性があります。
また、ブロックレベルのHTMLコメントは「コンテンツがClaudeのコンテキストに注入される前に削除される」ため、トークンを消費せずに人間のメンテナー向けのメモを残すのに最適な場所です。
他のチームのファイルが検出されてしまうモノレポでは、claudeMdExcludes がそれらをスキップします。これは実際の競合原因に対する本質的な解決策であり、このリストの中でファイルを並べ替えるのではなく、コンテキストから削除する唯一の方法です。
ステップ 2：各レイヤーに正確に1つの役割を与える
各レイヤーが異なることについて話すようにスコープを割り当て、2つのレイヤーが矛盾しないようにします。
管理ポリシー（Managed policy）は、セキュリティ要件、コンプライアンスルール、ライセンスなど、真に組織的な制約を保持します。チームの誰も異論を唱えないような内容です。もしここにフレームワークに関する意見が含まれているなら、それが競合の原因であり、話し合うべき相手はプロジェクトファイルではなく、それをデプロイした担当者です。
ユーザー指示（User instructions）は、回答スタイル、ターミナルの好み、ショートカットなど、あなた個人の好みの働き方を保持します。プロジェクトに関するものはここには含めません。これは、チームメイトのルールと暗黙的に矛盾するルールの最も一般的な原因であり、making Claude stick to your coding style（Claudeにコーディングスタイルを守らせる）を必要以上に難しくしている原因でもあります。
プロジェクト指示（Project instructions）は、コマンド、規約、アーキテクチャの事実など、このリポジトリについて真実である事柄を保持します。これは共有され、レビューされるべきファイルです。
paths フロントマターを持つ .claude/rules/ は、条件付きのものを保持します。これは重要なポイントです。パススコープのルールは、異なるパスのルールと競合することはありません（両方が同時に適用されることはないため）。無条件のファイルから paths スコープのルールに移行することで、潜在的な矛盾を2つの重複しない記述に変換できます。paths のないルールは、プロジェクトファイルと同じ優先度で無条件に読み込まれるため、ルールが特定のファイルに限定される場合は常にフロントマターを使用してください。
スキル（Skills）は、タスク固有の手順を保持します。ドキュメントではこの切り分けが明確にされています。ルールは「セッションごと、または一致するファイルが開かれたときにコンテキストに読み込まれる」のに対し、「常にコンテキストにある必要がないタスク固有の指示には、代わりにスキルを使用します。」
作業時間を大幅に節約できる事実を1つ紹介します。「Claude Codeは CLAUDE.md を読み込み、AGENTS.md は読み込みません。」他のツール用にリポジトリにすでに AGENTS.md が存在する場合、文書化されているアプローチは、それをインポートする CLAUDE.md を作成することです。これにより、2つのファイルが乖離するのを防ぎ、両方が同じコンテンツを読み込むようになります。2つのファイルが乖離することは、最も純粋な形での競合問題です。
ステップ 3：ルールだけでなく、決定事項を記録する
ステップ2の後に、少数の真の矛盾が残るでしょう。これは、2つのレイヤーが同じことについて本当に意見が異なり、双方の作成者に理由があるケースです。
これらはレイヤーに優先順位を付けることでは解決できません。「内部HTTPクライアントを使用する」と「標準ライブラリクライアントを使用する」という2つの命令は、命令としては解決不可能です。しかし、一方が「内部クライアントだけが必要なプロキシサポートを持っていた時期」に書かれ、その後「標準ライブラリが後のバージョンでそれをサポートした」という経緯を知っていれば、即座に解決します。
その情報はどちらのファイルにも含まれていませんでした。なぜなら、CLAUDE.md は命令を記述する場所だからです。つまり、今日解決したすべての競合は、次回誰かがその理由なしに命令を書いたときに再び発生します。自動メモリ（Auto memory）はこれに少し役立ちます。Claudeはリポジトリごとに学習と修正の独自のストアを維持し、各セッションで文書化された制限（最初の200行または25KB）まで注入されます。しかし、そのストアはあなたの修正からClaudeによって書き込まれるものであり、チームが下した決定とその理由の記録ではありません。
MemoryLakeでの設定方法
MemoryLake は、すべての指示ファイルの外側に決定とその理由を保持し、MCPまたはAPIを介してそれらに関する質問に答えます。CLAUDE.md ファイルは短く命令的な状態を維持し、ドキュメント通りに正確に読み込まれます。2つのファイルが矛盾した場合、どちらのレイヤーが勝つべきかを推測する代わりに、それぞれの存在理由を検索して確認できます。
ステップ 1：APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。レイヤーを整理しながら各競合を記録する場所を確保するために、上記のステップ2の前にこれを行ってください。
ステップ 2：最初のメモリをアップロードする
ステップ2の競合と、引き継いだルールを整理します。それぞれについて、何が決定され、何が却下され、その理由は何だったのかを書き留めます。理由を誰も思い出せないルールは、最も価値のあるエントリーです。なぜなら、それらは再び議論の的になるものだからです。裏付けとなるドキュメントやファイルも同じ場所に保管します。
ステップ 3：AIとエージェントを接続する
Claude Code、Codex、Devin、およびその他のエージェントに、MCPまたはAPIを介してアクセスを許可します。ルールが間違っているように見える場合、「なぜこれがここにあるのか」という問いに対する答えは、より大きな声での再主張ではなく、その理由とともに返されます。
実際に何が変わるか
最初の変化は、ファイルが短くなることです。理由が別の場所に存在すれば、CLAUDE.md は命令のリストになります。これは200行未満のガイダンスが求めているものであり、ドキュメントが遵守率を向上させると述べている状態です。
2つ目は、ほとんどの競合が解決されるのではなく、存在しなくなることです。paths でスコープされたルールと、別のパスにスコープされたルールが同時にコンテキストに入ることはありません。これは優先順位付けではなく、構造的な修正です。
3つ目は、管理ポリシーレイヤーが怖くなくなることです。組織ファイルが真の組織的制約のみを保持し、プロジェクトファイルがプロジェクトの事実を保持している場合、連結はまさに望ましい動作となります。重複しない2つの記述のセットになるからです。
4つ目は、任意の選択に関する一文が、あなたが気にするような事柄に適用されなくなることです。Claudeは依然として2つの矛盾するルールの間で任意に選択するかもしれませんが、あなたは単に矛盾するルールを提供することをやめただけです。これが、Claude Code forgetting project context（Claude Codeがプロジェクトのコンテキストを忘れる）や、agents ignoring your instruction files（エージェントが指示ファイルを無視する）といった不満に対する実際の解決策です。指示が無視されたのではなく、隣り合う別の指示によって多数決で負けたのです。
複数レイヤーのCLAUDE.mdセットアップにおけるベストプラクティス
デバッグする前に必ず /context を実行する。 読み込まれたメモリファイルのリストが信頼できる唯一の情報源であり、通常は予想以上に長くなります。
1つのレイヤーに1つの役割。 組織の制約、個人の好み、プロジェクトの事実、条件付きルール、タスクの手順。2つのレイヤーが同じテーマについて話すことができる状態であれば、最終的には矛盾が生じます。
paths フロントマターを積極的に使用する。 スコープされたルールは、他のファイルのルールと矛盾することはありません。これは、最も低コストで利用できる競合排除方法です。
プロジェクトファイルを推奨サイズ以下に保つ。 ドキュメントでは200行未満を目標としており、長いファイルは遵守率を低下させると指摘しています。1つのファイルを肥大化させるのではなく、トピックごとに .claude/rules/ に分割してください。
ユーザーファイルにプロジェクトの事実を絶対に記述しない。 これは、チームメイトのルールと矛盾し、レビューもできないルールが生まれる最も一般的な原因です。
インポートする意図がない限り、パスはバックティックスで囲む。 インポートのパースはコードスパンをスキップするため、バックティックスの有無が、ファイルへの言及とファイルの読み込みの違いになります。
AGENTS.md を複製するのではなくインポートする。 Claude Codeは CLAUDE.md を読み込み、AGENTS.md は読み込みません。手動で管理された同じ規約の2つのコピーは、いずれ乖離してしまいます。
ハードな制約にはフックを使用する。 ドキュメントでは、これらのファイルは強制的な設定ではなくコンテキストであり、Claudeの判断に関係なくアクションをブロックするには PreToolUse フックを使用すると明記されています。
結論
Claude Codeは、その指示ファイルについて正直に文書化しています。検出されたすべてのファイルは、互いに上書きするのではなくコンテキストに連結され、paths フロントマターのないルールはプロジェクトファイルと同じ優先度で読み込まれ、セット全体が強制的な設定ではなくコンテキストとして扱われ、2つのルールが矛盾している場合、Claudeは任意に1つを選択することがあります。学習すべき隠された優先順位エンジンは存在しません。これは、2つのファイルが矛盾したときに訴えかける手段がないことも意味します。
ですから、それらの競合に勝とうとするのをやめ、代わりに競合を提供することをやめましょう。実際に何が読み込まれているかを列挙し、レイヤーが重複しないように各レイヤーに1つのテーマを与え、条件付きのものはすべて paths でスコープし、ファイルが従いやすいように十分に短く保ちます。そして、各ルールが存在する理由をそれらすべての外側に記録してください。なぜなら、競合を決定するレイヤーは、ファイルパスや読み込み順ではないからです。それは、そのルールが何のためにあったのかを誰かがまだ覚えているかどうかです。