CLAUDE.md を書いたのに無視される ─ 原因は「配置」と「行数」しかない

CLAUDE.md に「コミットメッセージは日本語で」と書いた。次の朝、Claude が出してきたコミットメッセージは普通に英語だった。3 回書き直しても直らない。「prettier ではなく biome を使え (コードフォーマッター)」と書いても、相変わらず prettier を提案してくる。

私もこれを 1 ヶ月続けて、最終的に「Claude Code は CLAUDE.md を読まない」と勝手に結論付けていた時期があります。実際は読んでいました。読んでいた上で、私が書いた指示が「届いていない場所」に置かれていたか、「埋もれて見えなくなる行数」になっていただけでした。

CLAUDE.md は無視されているのではありません。原因はほぼ 2 つに絞れます。配置と行数です。仕組みを 3 点だけ押さえて、処方箋を 4 ステップで運用に落とす、というのが本記事です。

「無視されている」と感じる前に思い出す 1 行

Anthropic 公式 docs は CLAUDE.md の挙動についてこう書いています。

CLAUDE.md content is delivered as a user message after the system prompt.

CLAUDE.md のコンテンツは、システム プロンプトの後にユーザー メッセージとして配信されます。

つまり、CLAUDE.md は 読まれたうえで Claude に渡されている。「無視されている」のではなく「届いていないか、量が多すぎて埋もれている」だけです。問題が起きうるのは次の 2 軸しかありません。

• そもそも起動時に ロードされる場所 に置かれているか
• ロードされたとしても、Claude が 読み切れる行数 に収まっているか

そして、この 2 軸はどちらも仕様で決まっています。AI の気まぐれではありません。

押さえる仕組みは 3 つだけ

仕組み 1: ローディングは「祖先=自動 / 子孫=遅延」の 2 機構

Claude Code は起動した瞬間、カレントディレクトリから ファイルシステムのルートに向かって上方向に 歩き、見つけた CLAUDE.md と CLAUDE.local.md をすべて読み込みます。これが祖先ロードです。

一方、カレントディレクトリの 下 にある CLAUDE.md は、起動時には読み込まれません。そのディレクトリ配下のファイルを Claude が実際に触った瞬間に初めて読み込まれます。これが遅延ロード（lazy loading）です。

flowchart LR Start["起動時 cwd = monorepo/frontend/"] Root["/monorepo/CLAUDE.md"] Front["/monorepo/frontend/CLAUDE.md"] Back["/monorepo/backend/CLAUDE.md"] Sub["/monorepo/frontend/components/CLAUDE.md"] Start -- "祖先・自動" --> Root Start -- "祖先・自動" --> Front Start -. "兄弟・読まれない" .-> Back Start -. "子孫・触ったら読む" .-> Sub

ここから 3 つの帰結が出ます。

• モノレポのルートで起動すると、子の frontend/CLAUDE.md も backend/CLAUDE.md も起動時には読まれない。Claude がそのフォルダのファイルを開いて初めて該当の CLAUDE.md がコンテキストに入る
• frontend/ で起動すると、上の monorepo/CLAUDE.md は自動で入るが、隣の backend/CLAUDE.md は永久に読まれない。(兄弟は読まれないのが原則)
• ~/.claude/CLAUDE.md（ホーム配下）は祖先扱いで自動ロードされる。全プロジェクトに効く個人設定の置き場所

「子の CLAUDE.md に書いたのに効かない」と感じたら、それは Claude がまだそのディレクトリのファイルを触っていない可能性が高いです。逆に「他チームのルールが勝手に混ざってくる」のは、祖先方向に余計な CLAUDE.md があるサインです。

仕組み 2: 配置場所は実質 4 つ

CLAUDE.md は置く場所で「誰に効くか」が変わります。整理するとこうなります。

(配置場所の詳細は 公式 docs – Choose where to put CLAUDE.md files を参照)

「全プロジェクト共通の私のクセ」と「このプロジェクトの規約」と「チームに見せたくない個人メモ」は、置き場所で分離します。1 ファイルに全部書こうとすると次の 200 行ルールに引っかかります。

仕組み 3: 1 ファイル 200 行ルール

公式 docs はサイズについてはっきり書いています。

Size: target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.

サイズ: CLAUDE.md ファイルあたり 200 行未満をターゲットとします。ファイルが長いと、より多くのコンテキストが消費され、準拠性が低下します。

200 行を超えると、コンテキストを食ううえに 指示への準拠性が下がる、と公式が言っている。「書いた指示の効きが悪くなる」のは、Claude のサボりではなく仕様です。

ここで注意がひとつ。CLAUDE.md は @path/to/file.md という構文で他のファイルを取り込めます（公式 docs – Import additional files）。便利な仕組みですが、import 先の中身もコンテキストに合算されるので、「import で逃げれば 200 行制約を回避できる」という誤解は通用しません。

なお Skills の章（#04 Skills 入門）で書いた「全部コンテキストに入れると壊れる」話と、根っこは同じです。CLAUDE.md も Skills も、起動時に一括で読み込まれる側の仕組みなので、量が増えれば指示への準拠性が落ちます。

踏みやすい罠 4 つ

罠 1: ベタ書きで 200 行突破

最も多いのがこれです。「プロジェクトの規約 + 自分の癖 + 過去のハマりメモ + 注意事項」を 1 ファイルに詰めて 400 行になり、Claude がだんだん指示を見落とすようになる。

対処: 200 行を超えたら「分量を減らす」が先で「import で分ける」は後。本当に必要な指示だけ主 CLAUDE.md に残して、頻繁に参照されない詳細は .claude/rules/<topic>.md に逃がします（次の処方箋で詳述）。

罠 2: 子孫 CLAUDE.md に頼って効かないと嘆く

「frontend/CLAUDE.md に書いたのに React のルールが効いていない」と感じる。原因は単純で、そのセッションで frontend/ 配下のファイルにまだ触っていないだけです。子孫は遅延ロードなので、Claude がそのフォルダを開いた瞬間に初めて読まれます。

対処: 起動時から効かせたい指示は祖先方向（プロジェクトルートか ~/.claude/）に置きます。子の CLAUDE.md は「そのディレクトリ配下を触ったときだけ追加で効かせたい狭い指示」に限定します。

罠 3: モノレポで祖先に他チームのルールが混入

会社の巨大モノレポを git clone した直後、ルート直下に巨大な monorepo/CLAUDE.md があって、その中身が他チーム向けの命名規約や禁止事項で埋め尽くされていることがあります。frontend/ で作業しているだけなのに、Claude が backend チームのルールに従って動こうとして混乱する。

対処: .claude/settings.json の ignorePatterns 設定で該当ファイルを除外します（公式 docs – Exclude specific CLAUDE.md files）。例えばこうです。

{ "ignorePatterns": [ "**/monorepo/CLAUDE.md", "/home/user/monorepo/other-team/.claude/rules/**" ]
}

これで指定ファイルは祖先ロードから外れます。

罠 4: auto memory と CLAUDE.md の混同

Claude Code には CLAUDE.md と別に auto memory という仕組みがあります（~/.claude/projects/<project>/memory/MEMORY.md）。これは Claude が会話の中で「これは覚えておくべき」と判断したことを自動で書き出す側 です。人間が手で書く CLAUDE.md とは別物です。

両者の違いを整理するとこうです（公式 docs – CLAUDE.md vs auto memory より）。

「Claude にこう動いてほしい」は CLAUDE.md、「Claude に勝手に書き溜めさせる」は auto memory、と切り分けます。auto memory に追記したいことを CLAUDE.md に書いても、設計の方向がずれます。

処方箋 ─ 4 ステップで運用する

ここまでの仕組みと罠を踏まえて、私が運用している 4 ステップを置いておきます。

Step 1: 置き場所を 3 階層で固定する

「全プロジェクトで効かせたい個人の癖」「このプロジェクト固有でチーム共有したい規約」「個人メモ」を、最初に 3 ファイルに分けます。

~/.claude/CLAUDE.md # 全プロジェクト共通の個人クセ
<project>/CLAUDE.md # チーム共有のプロジェクト規約（git に commit）
<project>/CLAUDE.local.md # 個人メモ・実験中の指示（.gitignore に追加）

ここに書く前に、「これは誰に効かせたいか」を 1 行で言える状態にしておきます。言えなければ書かない。書いていい場所が決まらなければ書かない、というのを徹底するだけで主 CLAUDE.md の肥大化が止まります。

Step 2: 主 CLAUDE.md は 100 〜 150 行で固定する

主 CLAUDE.md に書くのは「概要 + コア規約 + 全体に効かせたい少数の規約」だけにします。それ以外の細かい規約（API 規約・テスト規約・ドキュメント規約など）は .claude/rules/<topic>.md に切り出し、paths: frontmatter で「マッチしたファイルを触ったときだけ読み込め」と指定します。これは Anthropic 公式の Claude Code が提供している正式機能です（公式 docs – Path-specific rules）。

まず構造を概念図で押さえます。

flowchart LR Session(("Claude<br/>セッション")) Main["CLAUDE.md<br/>(常時ロード・100 行台)"] Rule1[".claude/rules/api.md<br/>paths: src/api/**/*.ts"] Rule2[".claude/rules/testing.md<br/>paths: tests/**"] Rule3[".claude/rules/docs.md<br/>paths: **/*.md"] Session == "毎セッション必ず" ==> Main Session -. "src/api を触ったときだけ" .-> Rule1 Session -. "tests を触ったときだけ" .-> Rule2 Session -. "Markdown を触ったときだけ" .-> Rule3

主 CLAUDE.md は常時コンテキストに入る。.claude/rules/*.md は paths: のグロブにマッチするファイルを Claude が読んだときだけコンテキストに入る、という関係です。普段触らない領域のルールがセッション開始時に枠を食わなくなる、というのがこの仕組みのキモです。

ここで言う「グロブパターン」とは、ファイルパスを *（任意の文字列）や **（任意の階層）といったワイルドカードでまとめて指定する記法のことです。シェルの ls src/**/*.ts などで日常的に使うあれで、Claude Code もこれと同じ書き方で「どのファイルを触ったときにルールを読み込むか」を指定します。

公式に載っている最小例

公式 docs に載っている例をそのまま日本語化したものがこれです。

---
paths: - "src/api/**/*.ts"
---
# API 開発ルール
- すべての API エンドポイントで入力バリデーションを必須にする
- 標準のエラーレスポンス形式を使う
- OpenAPI のドキュメントコメントを含める

このファイルを .claude/rules/api.md として置くと、Claude が src/api/ 配下の .ts を読んだ瞬間にだけ、この 3 行のルールがコンテキストに入ります。フロントエンドだけ触っているセッションや、Markdown だけ書いているセッションでは一切ロードされず、その分の枠が空きます。

複数パターンを指定したいときは配列で並べ、ブレース展開で拡張子をまとめられます（こちらも公式 docs より）。

---
paths: - "src/**/*.{ts,tsx}" - "lib/**/*.ts" - "tests/**/*.test.ts"
---

公式が出しているグロブパターンの早見表は次のとおりです（公式 docs – Path-specific rules）。

paths: を付けないとどうなるか

paths: frontmatter を 付けない ファイルを .claude/rules/ に置くと、それは主 CLAUDE.md と同じ扱いで毎セッション常時ロードされます（公式 docs – Set up rules）。つまり .claude/rules/ の使い分けは 2 段階あって、

• paths: なし：常時効かせたいが、主 CLAUDE.md を肥大化させたくないので別ファイルに分けたいもの（例：会社共通のコミット規約）
• paths: あり：特定領域でだけ効かせたいもの（例：API・テスト・Markdown）

この 2 段階に主 CLAUDE.md を合わせると、「主 CLAUDE.md（概要 + コア規約）」「常時 rules（分割した共通規約）」「条件 rules（領域別の詳細）」の 3 階層で運用できる、というのが公式が想定している構造です。

実運用例：109 行で回しているコミュニティリポジトリ

実際にこの形で運用されているリポジトリが shanraisshan/claude-code-best-practice です。主 CLAUDE.md は 109 行に収まっており、.claude/rules/ には次の 2 ファイルがいずれも paths: 付きで置かれています。

• .claude/rules/markdown-docs.md：paths: ["**/*.md"]。Markdown を触ったときだけ読み込まれる文書化標準（1 トピック 1 ファイル、相対リンク必須、見出し階層を飛ばさない、など）
• .claude/rules/presentation.md：paths: ["presentation/**"]。プレゼンディレクトリを触ったときだけ読み込まれる委譲ルール（HTML 直編集禁止、対応エージェントへの委譲）

「常時ロードは主 CLAUDE.md 109 行だけ、細則は領域別に paths: 付きで条件ロード」という割り切り方で、200 行制約を自然に守っています。自分のプロジェクトに移植するときの雛形として参考になります。

Step 3: 子孫 CLAUDE.md は「狭い世界の追加指示」に絞る

frontend/CLAUDE.md のような子孫ファイルは、親と重複する内容を書きません。書くのはそのディレクトリ配下でしか使わない縛り（特定のフレームワーク版、独自コマンド、API のドメイン規約など）に限定します。

子孫はあくまで遅延ロードなので、「絶対に最初から効かせたい」指示はここに置いてはいけません。最初から効かせたいなら親に上げます。

Step 4: /memory と /init で点検する

「書いたのに効いていない気がする」と感じたら、まず /memory コマンドを開きます。これで 今のセッションで実際に読み込まれている CLAUDE.md / CLAUDE.local.md / rules ファイルがすべて一覧表示 されます。

ここで思っているファイルが出ていなければ、それは「届いていない」サインです。配置を見直します。

新規プロジェクトでは /init で雛形を自動生成できます（公式 docs – Set up a project CLAUDE.md）。Claude がプロジェクトを覗いて、技術スタックと既存規約を拾った CLAUDE.md を作ってくれるので、ゼロから書き始めるよりは早い、というだけのものです。生成後に「不要な行を削る」作業は必ず発生します。

まとめ

CLAUDE.md は素直な仕組みです。

• 起動時に祖先方向は 自動で全部ロードされる
• 子孫は 触られた瞬間に遅延でロードされる
• 1 ファイルは 200 行以内 が公式推奨
• 配置を 3 階層（user / project / local）で分けると役割が交わらない

この 4 点を押さえれば、「書いたのに効かない」は配置と行数の問題に必ず収束します。AI のサボりに見えていたものは、ほとんどが運用設計の問題です。

次に Claude が指示を聞いてくれないと感じたら、まず /memory を開いて、自分が書いたファイルが本当にそこに並んでいるか確認してください。並んでいなければ配置の問題、並んでいるのに長すぎれば行数の問題。原因はそれ以外にはありません。

TL;DR

• CLAUDE.md が効かない原因の大半は「配置」か「行数」のどちらか
• 起動時は祖先方向の CLAUDE.md だけが自動で読まれる。子孫はそのフォルダのファイルを触って初めて読まれる
• 1 ファイル 200 行以内が公式推奨。超えたら @import で逃げず、内容を削るか .claude/rules/<topic>.md に分けて遅延ロード化する
• 効かないと感じたら、まず /memory で「実際にロードされているもの」を確認する