Claude Codeでプロジェクト固有のルールを指定するためにCLAUDE.mdを作成したものの、実際に作業を依頼すると指示を無視されることがあります。
たとえば、
npmではなくpnpmを使う 編集後は必ずテストを実行する src/api以下では既存のRepositoryパターンを使う
と書いているのに、Claude Codeがnpm installを実行したり、テストを実行せず作業を終了したりするケースです。
このとき、「Claude CodeはCLAUDE.mdを読んでいない」と考えたくなりますが、原因は大きく分けると異なります。
本当にファイルが読み込まれていない場合もあれば、読み込まれているものの別のCLAUDE.mdと競合している場合、ファイルが長すぎて個別の指示への追従率が落ちている場合もあります。
Claude Codeの現在の公式ドキュメントでは、CLAUDE.mdは強制設定ではなく、モデルのコンテキストへ与えられる指示として扱われます。Anthropicも、具体的で短い指示ほど安定して従いやすく、曖昧な指示や競合する指示では遵守が保証されないと説明しています。
この記事では、Claude CodeがCLAUDE.mdを読まない、または読んでいるように見えないときに確認したい配置場所、読み込み範囲、読み込み順序、CLAUDE.local.md、サブディレクトリ、@インポートなどを解説します。CLAUDE.md自体の書き方・ベストプラクティスはClaude Code CLAUDE.md完全設計ガイドで、CLAUDE.mdとAuto Memory・MCPメモリサーバーの使い分けはClaude Code 記憶戦略完全ガイドで扱っているため、この記事では「なぜ読まれないのか」という切り分けにしぼります。
- 最初に/contextでCLAUDE.mdが読み込まれているか確認する
- プロジェクトのCLAUDE.mdはどこに置けばよい?
- ~/.claude/CLAUDE.mdはすべてのプロジェクトに適用される
- CLAUDE.local.mdは自分だけのプロジェクト設定に使える
- CLAUDE.mdの「優先順位」は単純な上書きではない
- Claude Codeは起動したディレクトリから上方向を調べる
- サブディレクトリのCLAUDE.mdは起動時には読み込まれない
- サブディレクトリ用ルールは.claude/rulesも使える
- –add-dirしたディレクトリのCLAUDE.mdはデフォルトでは読まれない
- AGENTS.mdはそのままではCLAUDE.mdの代わりにならない
- @で別ファイルを読み込める
- @importした外部ファイルが読み込まれない場合は承認を確認する
- バッククォート内の@pathはImportされない
- claudeMdExcludesで除外されていないか確認する
- –setting-sourcesによってProject設定を除外している場合もある
- ファイルが読み込まれていてもClaudeが必ず従うわけではない
- 曖昧な指示は「読んでいない」ように見えやすい
- CLAUDE.mdが長すぎると個別ルールへの追従率が落ちる
- @importでファイルを分割してもContext量は減らない
- 親ディレクトリの古いCLAUDE.mdと競合していないか確認する
- CLAUDE.local.mdとの競合も確認する
- /compact後にサブディレクトリの指示が消えたように見える場合がある
- CLAUDE.mdを編集したのに現在のセッションへ反映されない場合は/contextを確認する
- InstructionsLoaded Hookなら何がいつ読み込まれたか追跡できる
- /doctorでも設定上の問題を確認できる
- 「必ず実行する」はCLAUDE.mdよりHookが向いている
- 効いているか確認するために曖昧な質問をしない
- 読み込まれない場合と従わない場合を分けて考える
- CLAUDE.mdが読まれない原因に関するよくある質問
- CLAUDE.mdが読まれないときは配置場所より先に/contextを見る
最初に/contextでCLAUDE.mdが読み込まれているか確認する
原因を調べるときに、最初からファイル配置を推測する必要はありません。
Claude Codeでは、
/context
を実行すると、現在のセッションでコンテキストへ読み込まれている情報を確認できます。
Memory filesの部分に対象のCLAUDE.mdが表示されているか確認してください。
設定が効かない場合は最初に/contextを実行し、CLAUDE.mdやRulesが実際に読み込まれているか確認する方法が案内されています。/memoryではUser ScopeやProject Scopeにあるメモリファイルの場所も確認できます。
たとえば次のような状態なら、
Memory files User ~/.claude/CLAUDE.md Project /home/user/my-project/CLAUDE.md
少なくともProject側のCLAUDE.mdは現在のClaude Codeから見えています。
一方、作成したはずのファイルが/contextへ出ていなければ、Claudeが指示を無視しているのではなく、そもそもコンテキストに入っていません。
この場合は文章の書き方を修正する前に、配置場所と起動位置を確認する必要があります。
プロジェクトのCLAUDE.mdはどこに置けばよい?
一般的なプロジェクト用CLAUDE.mdは、プロジェクトディレクトリへ次のように配置できます。
my-project/ ├── CLAUDE.md ├── package.json └── src/
現在のClaude Codeでは、プロジェクト指示を、
./CLAUDE.md または ./.claude/CLAUDE.md
へ配置できます。
Anthropicは、プロジェクト共通のアーキテクチャ、Coding Rule、Build Command、Test Commandなどをここへ記載し、Gitでチーム共有する用途を想定しています。
たとえば、
# Package Manager このプロジェクトではpnpmを使用する。 npmとyarnは使用しない。 # Test TypeScriptを変更した場合は、完了前に次を実行する。 pnpm test pnpm lint
のように書けます。
ファイルを作成しただけでは不安な場合は、Claude Codeで/contextを実行し、Project Memoryとして認識されていることを確認します。
~/.claude/CLAUDE.mdはすべてのプロジェクトに適用される
プロジェクト専用ではなく、自分が使うClaude Code全体にルールを適用したい場合は、
~/.claude/CLAUDE.md
を利用できます。
Windowsでは通常、
%USERPROFILE%\.claude\CLAUDE.md
に相当します。
ここはUser Instructionsとして扱われ、すべてのプロジェクトへ適用されます。
たとえば、
# My Defaults JavaScriptプロジェクトではTypeScriptを優先する。 コード変更後は可能な範囲でテストを実行する。 Git commitはユーザーから依頼された場合だけ実行する。
のような個人的な作業方針に向いています。
一方、
このプロジェクトのAPIはsrc/api/v2に作る
といった特定RepositoryだけのルールをUser Scopeへ書くと、別プロジェクトでも読み込まれてしまいます。
プロジェクト固有の内容はProject側へ分けるほうが管理しやすくなります。Claude CodeはUser側とProject側の両方のCLAUDE.mdを読み込みます。
CLAUDE.local.mdは自分だけのプロジェクト設定に使える
チームへ共有したくないプロジェクト固有の指示には、
CLAUDE.local.md
を利用できます。
たとえば、
my-project/ ├── CLAUDE.md ├── CLAUDE.local.md └── src/
という構成です。
CLAUDE.mdにはチーム共通ルールを書き、
テストにはpnpm testを使用する。
CLAUDE.local.mdには個人的な環境だけで必要な情報を書けます。
ローカル確認にはhttp://localhost:3001を使用する。
AnthropicはCLAUDE.local.mdを個人用のプロジェクト設定として案内しており、Gitへcommitしないよう.gitignoreへ入れることを推奨しています。
CLAUDE.mdの「優先順位」は単純な上書きではない
Claude Codeの設定を調べていると、
User Project Local
の「優先順位」という説明を見かけることがあります。
ここで注意したいのは、settings.jsonの設定値のように、後のファイルが前のファイルを機械的に上書きするわけではないことです。
Claude Codeは発見したCLAUDE.mdをコンテキストへ連結します。
現在の公式仕様では、広いScopeから具体的なScopeの順で読み込まれ、Project InstructionsはUser Instructionsより後にコンテキストへ入ります。また、同じディレクトリではCLAUDE.local.mdがCLAUDE.mdの後に配置されます。
たとえばUser側に、
Package Managerはnpmを使う。
とあり、Project側に、
このプロジェクトではpnpmを使う。
と書かれていれば、Project側のほうが後から読まれます。
ただし「後の指示が必ず100%勝つ」というHard Overrideではありません。
Anthropic自身も、複数のCLAUDE.mdで指示が競合するとClaudeがどちらかを任意に選ぶ場合があるため、矛盾するルールを作らないよう推奨しています。
したがって、npmを使うという指示とpnpmを使うという指示を別のCLAUDE.mdに同時に残すより、古い指示自体を削除したほうが安定します。User/Project/Local(・MCPメモリサーバー)のどこに何を置くべきかという設計判断はClaude Code 記憶戦略完全ガイドにまとめています。
Claude Codeは起動したディレクトリから上方向を調べる
CLAUDE.mdの読み込みで特に重要なのがCurrent Working Directoryです。
Claude Codeは起動したディレクトリから上方向へディレクトリをたどり、CLAUDE.mdとCLAUDE.local.mdを探します。
たとえば次の構成があるとします。
workspace/
├── CLAUDE.md
└── shop/
├── CLAUDE.md
└── frontend/
frontendでClaude Codeを起動した場合、
cd workspace/shop/frontend claude
上位にあるworkspace/CLAUDE.mdとworkspace/shop/CLAUDE.mdを読み込み対象にできます。
Anthropicの説明では、foo/bar/で起動した場合、foo/bar/CLAUDE.mdとfoo/CLAUDE.mdなど上位のファイルが発見され、Filesystem Root側からCurrent Working Directory側の順番でコンテキストへ追加されます。
サブディレクトリのCLAUDE.mdは起動時には読み込まれない
ここは「CLAUDE.mdを読まない」と感じやすいポイントです。
Claude CodeはCurrent Working Directoryより下にあるCLAUDE.mdも認識しますが、すべてを起動時に読み込むわけではありません。
たとえばmy-project/frontend/CLAUDE.mdやmy-project/backend/CLAUDE.mdがあっても、Rootのmy-project/CLAUDE.mdだけが起動時に読み込まれ、サブディレクトリ側はClaudeがそのディレクトリ内のファイルを実際に読むときに、On-demandで読み込まれます。
そのため、frontendのCLAUDE.mdが/contextに最初から表示されないからといって、必ずしも不具合ではありません。この遅延ロードの仕組みを利用した、モノレポでのCLAUDE.md階層設計・容量削減パターンはClaude Code 大規模コードベース・モノレポ完全ガイドで詳しく解説しています。
サブディレクトリ用ルールは.claude/rulesも使える
大規模なプロジェクトで、frontend用・backend用・tests用・API用と大量のCLAUDE.mdを置くより、.claude/rules/を利用したほうが整理しやすいケースもあります。
たとえば、
.claude/
├── CLAUDE.md
└── rules/
├── api.md
├── frontend.md
└── testing.md
という構成です。
さらにpathsを指定すると、対象ファイルを扱う場合だけRulesを読み込ませられます。
--- paths: - "src/api/**/*.ts" --- # API Rules APIでは必ず入力値を検証する。 エラーは共通Response形式で返す。
このRuleはsrc/api以下の対象ファイルをClaudeが扱うときに適用されます。
Anthropicは、長いCLAUDE.mdを小さく保つ方法としてPath-scoped Rulesの利用を案内しています。
–add-dirしたディレクトリのCLAUDE.mdはデフォルトでは読まれない
Claude Codeには、Current Working Directory以外を参照できるようにする--add-dirがあります。
たとえば、
claude --add-dir ../shared
として別Directoryへアクセスさせることができます。
ここで注意したいのは、追加Directoryへアクセスできることと、そのDirectory内のCLAUDE.mdを自動ロードすることは別という点です。
Anthropicの現在の仕様では、--add-dirで追加したDirectoryのCLAUDE.mdはデフォルトでは読み込まれません。
追加Directoryの指示も読み込みたい場合は、
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../shared
のように環境変数を有効にします。
これによって追加Directory内のCLAUDE.md、.claude/CLAUDE.md、.claude/rules/*.md、CLAUDE.local.mdも読み込み対象になります。
「--add-dirしたのだからCLAUDE.mdも読まれているはず」と考えている場合は確認してみてください。
AGENTS.mdはそのままではCLAUDE.mdの代わりにならない
複数のAI Coding Agentを利用しているRepositoryでは、AGENTS.mdを置いている場合があります。
しかしClaude Codeの現在の公式仕様では、AGENTS.mdをCLAUDE.mdとして自動的に読み込むわけではありません。
Anthropicは、既存のAGENTS.mdをClaude Codeでも共用したい場合、CLAUDE.mdからImportする方法を案内しています。
たとえば、
@AGENTS.md # Claude Code このプロジェクトでは変更後にpnpm testを実行する。
とします。
これなら共通ルールはAGENTS.mdに集約しつつ、Claude固有の設定だけCLAUDE.mdへ追加できます。
「AGENTS.mdを置いているのにClaude Codeがルールを無視する」という場合は、CLAUDE.mdからImportされているか確認してください。
@で別ファイルを読み込める
CLAUDE.md自体を巨大にしたくない場合は、別ファイルをImportできます。
たとえば、
# Project Rules @docs/coding-rules.md @docs/testing.md
と書けます。
Anthropicの現在の仕様では、@path構文を使って別ファイルを読み込めます。
Relative PathはCurrent Working Directoryではなく、Importを書いたCLAUDE.md自身の場所を基準に解決されます。Imported Fileからさらに別ファイルをImportすることもでき、現在は公式ドキュメント上で最大5段階(5 hops)まで再帰できるとされています。
1つのファイルへ何でも詰め込むのではなく、テーマごとに分割しておくと、後から特定のルールだけを見直しやすくなります。
@importした外部ファイルが読み込まれない場合は承認を確認する
Projectの外にあるファイルを@で読み込む場合は、さらに注意が必要です。
たとえば、
@~/.claude/my-company-rules.md
のようにWorking Directory外のファイルをProject側のCLAUDE.mdからImportした場合、Claude Codeは初回に承認ダイアログを表示します。
Anthropicの仕様では、そこで拒否するとExternal Importは無効になり、その後同じ確認ダイアログは表示されません。
つまり、CLAUDE.md本体は読み込まれているのに、@で指定したファイルのルールだけ効かないという状態があり得ます。
この場合は/contextでImport先がコンテキストに入っているか確認してください。
バッククォート内の@pathはImportされない
Markdown内でファイル名を説明するために、
`@README.md`
と書いた場合、これはImportではなくLiteral Textとして扱われます。
実際に読み込みたいなら、
@README.md
と書きます。
Anthropicの公式ドキュメントでも、Code SpanやFenced Code Block内の@pathはImport Parserが無視すると説明されています。
claudeMdExcludesで除外されていないか確認する
大規模Monorepoでは、関係のないチームのCLAUDE.mdまで読み込まれてしまうことがあります。
その対策としてClaude Codeには、
claudeMdExcludes
という設定があります。
たとえば、
{
"claudeMdExcludes": [
"**/legacy/CLAUDE.md"
]
}
としていれば、対象ファイルは読み込みから除外されます。
Anthropicによると、claudeMdExcludesはUser、Project、Local、Managed Policyなど複数のSettings Layerから設定でき、配列はLayer間でMergeされます。Managed PolicyのCLAUDE.mdだけは除外できません。
自分では除外設定を追加した覚えがなくても、Repositoryの.claude/settings.jsonや個人用settings.local.jsonに以前の設定が残っている可能性があります。
/contextに特定ファイルだけ出てこない場合は確認してみる価値があります。
–setting-sourcesによってProject設定を除外している場合もある
Claude Codeを通常のCLIではなくAgent SDKや特殊な起動方法から利用している場合、読み込むSetting Sourceを制限していることがあります。
たとえばProject Sourceが読み込み対象から外れていれば、Project側のCLAUDE.mdや.claude/rules/も期待どおりに使えません。
Claude Code Agent SDKの公式仕様では、Project、Local、Userがそれぞれ別のSetting Sourceとして扱われます。Project Sourceに含まれる親DirectoryのCLAUDE.mdはSession Start時に読み込まれ、子Directory側は必要になった際にOn-demandで読み込まれます。
通常の対話型Claude Codeを使っているだけなら深く意識する必要はありませんが、自作ツールからClaude Code SDKを呼び出している場合は確認ポイントになります。
ファイルが読み込まれていてもClaudeが必ず従うわけではない
/contextにCLAUDE.mdが表示されているのに、指示どおりに動かない場合があります。
ここで重要なのは、CLAUDE.mdがPermission SystemやProgram Codeではないということです。
Claude Codeの現在の公式ドキュメントでは、CLAUDE.mdはSystem Promptそのものではなく、System Promptの後にUser Messageとして与えられるContextとして扱われています。
そのため、
危険なコマンドは絶対に実行禁止
と書いたとしても、技術的にCommand実行をブロックするSecurity Boundaryにはなりません。
絶対に禁止したい処理ならPermissionsやHookなどの強制機構を使う必要があります。
CLAUDE.mdは、「このプロジェクトではこう作業する」という行動指針には向いていますが、「何があってもこの操作を技術的に禁止する」という用途には適していません。
曖昧な指示は「読んでいない」ように見えやすい
たとえば、
きれいなコードを書いてください。
と書いても、人によって「きれい」の意味は異なります。Claudeにも判断の余地が大きく残ります。
代わりに、
TypeScriptではanyを使用しない。 関数は原則として50行以内にする。
のように具体化します。
Anthropicも、Format code properlyよりUse 2-space indentationのように検証可能な具体的指示を推奨しています。
Claudeがルールを無視したように見えたら、「読んだかどうか」と同時に「そのルールから一意に行動を決められるか」を確認してください。
CLAUDE.mdが長すぎると個別ルールへの追従率が落ちる
プロジェクトを長く運営していると、問題が起きるたびにCLAUDE.mdへルールを追加したくなります。最初は50行だったものが、300行、500行、1000行と増えていくことがあります。
Anthropicは現在、CLAUDE.mdを目安として200行未満に保つことを推奨しています。長いファイルはContextをより多く消費し、個々のルールへのAdherenceを低下させる可能性があります(具体的な削り方・分割の目安はClaude Code CLAUDE.md完全設計ガイドで解説しています)。
さらに現在のClaude Codeは、CLAUDE.mdを最大4MiBまでFull Loadしますが、それを超えるファイルはスキップします。
つまり、ルールを書けば書くほどClaudeが正確になるとは限りません。常に必要なルールだけをRootのCLAUDE.mdへ残し、特定Directoryでしか必要のないルールは.claude/rules/へ分けたほうが効率的です。
@importでファイルを分割してもContext量は減らない
長いCLAUDE.mdを複数ファイルへ分割し、@でImportすれば見た目は整理できますが、Context削減にはなりません。
Anthropicの公式ドキュメントでは、@pathでImportしたファイルも起動時にContextへ読み込まれるため、単に分割しただけではToken消費は減らないと説明されています。
コンテキストを減らすことが目的なら、Importより前述のPath-scoped RulesやSkillsへ移すほうが適しています。モノレポでの階層化による具体的な削減事例はClaude Code 大規模コードベース・モノレポ完全ガイドで紹介しています。
親ディレクトリの古いCLAUDE.mdと競合していないか確認する
Claude Codeは起動Directoryだけでなく、その親Directoryも調べます。そのため自分が忘れていた上位DirectoryのCLAUDE.mdが読み込まれていることがあります。
たとえば、
~/projects/
├── CLAUDE.md
└── new-app/
└── CLAUDE.md
となっていて、
cd ~/projects/new-app claude
と起動すると、両方が読み込まれます。
上位のCLAUDE.mdに「テストにはnpm testを使う」、Project側に「テストにはpnpm testを使う」とあれば競合します。
Claude Codeは両方の内容をContextへ入れるため、古い親Directory設定が意図せず影響する可能性があります。
/contextを使うメリットは、このような「存在を忘れていたCLAUDE.md」も確認できる点です。
CLAUDE.local.mdとの競合も確認する
同じDirectoryでは、CLAUDE.mdの後にCLAUDE.local.mdが読み込まれます。
以前、自分だけの設定として、
テストは実行せず高速に作業する。
と書き、その存在を忘れているケースも考えられます。
Team共有のCLAUDE.mdには「変更後は必ずテストを実行する」と書かれているため、「Claude CodeがProject Ruleを無視した」と見えるわけです。
/memoryや/contextを使い、Local Fileまで含めて確認してください。
/compact後にサブディレクトリの指示が消えたように見える場合がある
長時間Claude Codeを利用すると、Context Compressionのため/compactを使うことがあります。
現在のClaude Codeでは、Project RootのCLAUDE.mdはCompaction後にDiskから再度読み込まれ、Sessionへ再注入されます。
一方、Nested DirectoryのCLAUDE.mdやpaths:を持つRuleは、その対象ファイルを再びClaudeが読む際に再ロードされます。
そのためCompaction直後に「frontend/CLAUDE.mdのルールを忘れた」ように見えても、まだfrontend内の対象ファイルを読み直していないだけの場合があります。
長時間Sessionでだけルールが効かない場合は、この読み込みタイミングも確認してください。
CLAUDE.mdを編集したのに現在のセッションへ反映されない場合は/contextを確認する
CLAUDE.mdを外部Editorで修正したあと、現在開いているSessionがどの内容を使っているか分からなくなることがあります。
この場合も推測せず、/contextと/memoryを使って確認するのが安全です。
/memoryはUserとProject ScopeにあるMemory Fileを表示し、Editorで開くこともできます。一方、現在のSessionへ実際に読み込まれたファイルを確認する目的では/contextが推奨されています。
外部からファイルを更新した直後に挙動がおかしい場合は、新しいSessionでも再現するか確認すると切り分けやすくなります。
InstructionsLoaded Hookなら何がいつ読み込まれたか追跡できる
複雑なMonorepoやNested CLAUDE.mdを大量に利用している場合は、どの指示ファイルがいつ、なぜ読み込まれたのかまで確認したいことがあります。
現在のClaude CodeにはInstructionsLoaded Hookがあり、指示ファイルのロードを追跡できます。
Anthropicも、Path-specific RuleやLazy LoadされるSubdirectory Fileをデバッグする用途としてInstructionsLoaded Hookを案内しています。
単純なプロジェクトなら/contextだけで十分ですが、大規模Repositoryで「あるDirectoryだけルールが効かない」といった問題を追跡するときには便利です。
/doctorでも設定上の問題を確認できる
Claude Codeには、/doctorもあります。
現在の公式ドキュメントでは、Installation Healthだけでなく、無効なSettings Fileや未使用のExtension、重複したSubagent名などのConfiguration診断に利用できます。さらに、RepositoryへCommitされたCLAUDE.mdについて、CodebaseからClaude自身が取得できる冗長な内容を検出し、Trim案を提示する機能もあります。
CLAUDE.mdを長年継ぎ足して大きくなっている場合は、一度確認してみる価値があります。
「必ず実行する」はCLAUDE.mdよりHookが向いている
たとえば、
ファイルを編集するたびにPrettierを実行する。
と書いたとします。Claudeはこの指示に従おうとしますが、CLAUDE.mdはHard Enforcementではありません。
絶対に毎回実行させる必要があるならHookのほうが適しています。
同様に、rm -rfを絶対に実行させないといったSecurity RuleはPermissionsで禁止するほうが安全です。
Anthropicも、特定Lifecycleで必ず実行したい処理はHook、技術的に禁止したい操作はPermissionsなどの強制機構を利用し、CLAUDE.mdはBehavior Guidanceとして使い分けることを推奨しています。
「CLAUDE.mdを読んでいるのに時々守られない」という問題を、文章をさらに強くするだけで解決しようとしないことも重要です。
効いているか確認するために曖昧な質問をしない
CLAUDE.mdの動作確認として、
ルールを読んでいますか?
と質問するだけでは、十分なテストにならない場合があります。
実際にルールへ関係する作業を依頼したほうが確実です。
たとえばCLAUDE.mdに「このプロジェクトではpnpmのみを使用する」と書いているなら、「依存パッケージを追加してください」と依頼し、実際にどのCommandを選ぶか確認します。
それでもnpm installを選ぶなら、/contextでファイルがロードされているかを確認します。
ロード済みなら、競合ルールがないか、指示が具体的か、CLAUDE.mdが長すぎないかへ調査対象を移します。
この順番なら「読み込まれていない問題」と「従っていない問題」を混同せずに済みます。
読み込まれない場合と従わない場合を分けて考える
Claude CodeのCLAUDE.mdトラブルで最も重要なのは、この2つを分離することです。
/contextにファイルが表示されていないなら読み込みの問題です。
この場合は配置場所、Current Working Directory、--add-dir、claudeMdExcludes、Setting Sources、External Importなどを確認します。
一方、/contextには表示されているのにルールに従わないなら、指示内容の問題である可能性が高くなります。
この場合は競合するUser・Project・Local Instructions、曖昧な表現、ファイルサイズなどを確認します。
公式のデバッグガイドでも、/contextでMemory Fileが確認できるのにClaudeが従わない場合は、LoadingではなくInstructionの書き方を疑うよう案内されています。
CLAUDE.mdが読まれない原因に関するよくある質問
QCLAUDE.mdが読まれているか確認する一番確実な方法は何ですか
A/contextコマンドを実行し、Memory filesに対象のCLAUDE.mdが表示されているか確認する方法が最も確実です。表示されていなければ、指示を無視されているのではなくそもそもコンテキストに入っていないという、読み込みそのものの問題として調査します。
Qサブディレクトリに置いたCLAUDE.mdが/contextに出てこないのはなぜですか
AClaude Codeはサブディレクトリ内のCLAUDE.mdをセッション開始時には読み込まず、そのディレクトリ内のファイルを実際に読むときにOn-demandで読み込む仕様のためです。最初からセッション開始時の/contextに出てこなくても不具合とは限りません。
Q–add-dirで追加したディレクトリのCLAUDE.mdはなぜ読まれませんか
A–add-dirはディレクトリへのアクセス権限を追加するだけで、そのディレクトリのCLAUDE.mdを自動的に読み込む機能ではないためです。追加ディレクトリの指示も読み込みたい場合は、CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1という環境変数を有効にする必要があります。
QAGENTS.mdを置いているのにClaude Codeがルールを無視するのはなぜですか
AClaude CodeはAGENTS.mdを自動的には読み込まないためです。CLAUDE.mdの中に@AGENTS.mdとImport文を書くことで、共通ルールをAGENTS.mdに集約しつつClaude Codeでも読み込ませることができます。
Q@でファイルをImportしているのに反映されない場合はどうすればよいですか
AWorking Directory外のファイルをImportした場合、初回に表示される承認ダイアログで拒否すると、それ以降そのExternal Importは無効なままになります。/contextでImport先のファイルがコンテキストに含まれているか確認してください。またバッククォートで囲んだ`@path`はImportとして扱われない点にも注意が必要です。
QCLAUDE.mdは読み込まれているのに指示に従ってくれません。なぜですか
ACLAUDE.mdはPermission SystemやProgram Codeではなく、System Promptの後に与えられるContextとして扱われるためです。指示が曖昧だったり、User側・Project側・Local側の指示が競合していたり、ファイルが長すぎて個々のルールへの追従率が落ちていたりする可能性があります。絶対に強制したい処理はHookやPermissionsを使ってください。
QCLAUDE.mdが長すぎるとどんな問題がありますか
AContextの消費が増えるだけでなく、個々のルールへの追従率(Adherence)が低下する可能性があります。Anthropicは目安として200行未満を推奨しており、4MiBを超えるCLAUDE.mdは現在のClaude Codeでは読み込み自体がスキップされます。頻繁に使わないルールはPath-scoped Rulesなど別の仕組みへ分けたほうが効率的です。
CLAUDE.mdが読まれないときは配置場所より先に/contextを見る
Claude CodeがCLAUDE.mdを無視しているように見えた場合、最初からファイルを移動したり再作成したりする必要はありません。
まず/contextを実行し、現在のSessionへ対象ファイルが読み込まれているか確認してください。
Project Instructionsは./CLAUDE.mdまたは./.claude/CLAUDE.mdへ配置できます。全Project共通の個人設定なら~/.claude/CLAUDE.md、自分だけのProject設定にはCLAUDE.local.mdを利用できます。
Claude CodeはCurrent Working Directoryから上方向にあるCLAUDE.mdを読み込み、下位Directoryにあるファイルについては、そのDirectory内のファイルを操作するときにOn-demandで読み込みます。
さらに複数のCLAUDE.mdは単純に上書きされるのではなく、コンテキストへ連結されます。そのため古い親Directoryの指示、User側の設定、CLAUDE.local.mdなどが競合している可能性もあります。
ファイルが確実にロードされているのに守られないなら、ルールをより具体的にし、不要な競合を削除し、CLAUDE.mdを短くしてください。Anthropicは目安として200行未満を推奨しており、4MiBを超えるCLAUDE.mdは現在のClaude Codeでは読み込み自体がスキップされます。
そして「絶対に禁止する」「必ず特定タイミングで実行する」といった保証が必要なルールは、CLAUDE.mdだけに任せずPermissionsやHooksへ移します。
Claude CodeのCLAUDE.mdトラブルは、「Claudeがルールを無視した」と考える前に、まず/contextで何が実際に読み込まれたのかを見ることが最も効率的な切り分け方法です。CLAUDE.md自体の設計はClaude Code CLAUDE.md完全設計ガイド、Auto Memory・MCPメモリサーバーとの使い分けはClaude Code 記憶戦略完全ガイド、モノレポでの階層設計はClaude Code 大規模コードベース・モノレポ完全ガイドもあわせて参考にしてください。
