CLAUDE.mdが無視される、反映されない、守らない——Claude Codeを使い込むほどぶつかるこの問題。原因は「肥大化」。この記事では、肥大化を防ぎ、遵守率を上げる実践的な方法を全て解説する。
CLAUDE.mdが無視される3つの原因
原因1: 200行を超えている
CLAUDE.mdは先頭約200行がセッション開始時にロードされる。200行を超えた部分は読み込まれにくく、ルールが無視される原因になる。
# 行数チェック
wc -l CLAUDE.md
# 200以下なら安全、60以下が理想原因2: ルールが多すぎて埋もれている
20個のルールを全て同じ重要度で書くと、Claudeは「どれを優先すべきか」が分からない。結果として「sedでPHP編集しない」（致命的）と「コミットメッセージは日本語で」（軽微）が同列に扱われ、致命的なルールが無視される。「5行ルール」で最重要ルールを冒頭に集約するのが解決策。
「コードから分かる情報を書くな」の具体例:
| 書いてしまいがち（NG） | なぜNGか |
|---|---|
| 「このプロジェクトはReact 18を使用」 | package.jsonを見れば分かる |
| 「srcディレクトリにソースコードがある」 | ディレクトリ構造を見れば分かる |
| 「TypeScriptを使用」 | tsconfig.jsonの存在から分かる |
| 「テストはjest」 | jest.config.jsの存在から分かる |
| 「ESLintでlintしている」 | .eslintrc.jsの存在から分かる |
これらをCLAUDE.mdに書くのは全てトークンの無駄。Claude Codeはこれらのファイルを自動で読んで技術スタックを把握する。書くべきは「コードからは分からない情報」のみ: プロジェクト固有の禁止事項、チームの慣習、過去のトラブル事例など。
原因3: セッション後半で古い指示が埋もれる
CLAUDE.mdはセッション開始時に1回だけ読み込まれる「ユーザーメッセージ」。会話が長くなると、新しいメッセージに押されて相対的に古くなり、遵守率が下がる。長いセッションでは/compactで圧縮すると改善する。
具体的には、セッション開始時にCLAUDE.mdの60行がコンテキストの先頭に注入される。その後の会話が100メッセージを超えると、CLAUDE.mdの内容はコンテキストの「遠い過去」になり、最近のメッセージに比べて影響力が低下する。これがセッション後半でのルール無視の根本原因。
対策は3つ: (1) /compactで中間メッセージを圧縮（CLAUDE.mdの相対的な影響力が回復）、(2) .claude/rules/でファイル操作時にルールを再注入、(3) Hooksで編集前に自動表示。
Hooksによるルール自動注入
セッション後半でルールが忘れられる問題の高度な解決策がHooks。ファイル編集前にルールを自動表示させる設定:
// .claude/settings.json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"command": "echo '⚠️ ルール確認: sedでPHP編集禁止。Pythonで行単位編集すること。'"
}
]
}
}この設定で、Claude Codeがファイルを編集するたびにルール確認メッセージが表示される。セッション後半でもルールが「再注入」されるため、忘却問題を根本解決できる。ただし設定が複雑なため、まずはrules/の条件付きロードから始めるのがおすすめ。
「腐ったCLAUDE.md」の危険性
腐ったCLAUDE.mdは、ないよりも有害。古いルールや矛盾するルールが残っていると、Claude Codeの判断を誤らせる。例えば:
- 「テストはjestで書く」と書いてあるが、プロジェクトはvitestに移行済み → Claude Codeがjestでテストを書く
- 「Node.js 16を使用」と書いてあるが、実際はNode.js 20 → 互換性のない書き方をする
- 「APIエンドポイントは/api/v1/」と書いてあるが、v2に移行済み → 古いAPIを呼ぶコードを生成する
これらは「CLAUDE.mdがない」状態より悪い。Claude Codeは「コードから分かること」より「CLAUDE.mdに書いてあること」を優先するため、古い情報が積極的に害を及ぼす。3ヶ月ごとの棚卸しが必須な理由はここにある。
腐敗を検知する方法: Claude Codeに「CLAUDE.mdに書いてあるルールの中で、現在のプロジェクトの実態と矛盾しているものはあるか？」と聞く。Claude Codeはコードベースとpackage.jsonを読んだ上で矛盾を指摘してくれる。例えば「CLAUDE.mdに『Node.js 16を使用』と書いてあるが、.nvmrcには20が指定されている」といった矛盾を発見できる。
もう1つの方法は、/initで新しいCLAUDE.mdを生成し、既存のCLAUDE.mdと比較すること。差分が大きければ大きいほど、既存のCLAUDE.mdが「腐っている」可能性が高い。バックアップを取ってから/initで再生成→必要なルールだけ手動で追加し直すのが最も確実な「リフレッシュ」方法。
肥大化した CLAUDE.md の移行例
実際に200行超のCLAUDE.mdを60行に削減した移行例：
| 内容 | 移行前 | 移行先 | 理由 |
|---|---|---|---|
| 最重要ルール5行 | CLAUDE.md | CLAUDE.md（そのまま） | 毎回必要 |
| PHP編集ルール | CLAUDE.md 20行 | .claude/rules/php.md | PHP操作時のみ必要 |
| テストルール | CLAUDE.md 15行 | .claude/rules/test.md | テストファイル操作時のみ |
| デプロイ手順 | CLAUDE.md 30行 | .claude/commands/deploy.md | デプロイ時のみ（Skill化） |
| コードレビュー手順 | CLAUDE.md 25行 | .claude/commands/review.md | レビュー時のみ（Skill化） |
| モデル仕様（回帰係数等） | CLAUDE.md 50行 | .claude/commands/predict.md | 予測時のみ（Skill化） |
| package.jsonの内容 | CLAUDE.md 10行 | 削除 | Claudeが直接読める |
結果：200行→60行（70%削減）。ルールの遵守率が体感で大幅に改善し、特に「sedでPHPを編集しない」ルールの違反が月2-3回→0件に。
移行の具体的な手順
# Step 1: バックアップ
cp CLAUDE.md CLAUDE.md.backup
# Step 2: 行数確認
wc -l CLAUDE.md # 200行超→移行必要
# Step 3: ディレクトリ作成
mkdir -p .claude/rules .claude/commands
# Step 4: ファイル種別ルールをrules/に移動
# CLAUDE.mdからPHP関連20行を切り出し→ .claude/rules/php-safety.md
# Step 5: ワークフローをSkills化
# CLAUDE.mdからレビュー手順25行を切り出し→ .claude/commands/review.md
# Step 6: コードから分かる情報を削除
# package.jsonの依存関係一覧→削除
# Step 7: 行数再確認
wc -l CLAUDE.md # 60行以内になっているか確認1回の移行で10-20行ずつ削減していくのが安全。全てを一度にやろうとしない。
.claude/rules/ の使い方
.claude/rules/はYAML frontmatter（ファイル冒頭の---で囲まれた設定エリア）で条件指定できるルールファイル。特定のファイルを操作する時だけ読み込まれるため、CLAUDE.mdの行数を減らせる。
# .claude/rules/php-safety.md
---
description: PHP editing safety rules
globs: "**/*.php"
---
- sedでPHPファイルを編集しない（Pythonで行単位編集すること）
- 編集後は php -l で構文チェック
- functions.phpの}を消さないことこのファイルはPHPファイルを操作する時だけ自動ロードされる。セッション開始時には読み込まれないため、トークンを節約できる。
セッション後半で忘れる問題の対策
| 方法 | 効果 | 手軽さ |
|---|---|---|
| .claude/rules/ の条件付きロード | ◎ ファイル操作時に再注入 | ◎ ファイル置くだけ |
| /compact で圧縮 | ○ コンテキスト整理で遵守率改善 | ◎ コマンド1つ |
| ソースコード先頭コメント | ○ ファイル読み込み時に目に入る | △ 全ファイルに追加必要 |
| Hooksで自動注入 | ◎ 編集前にルールを自動表示 | △ 設定が複雑 |
最も手軽で効果が高いのはrules/の条件付きロード。次点で/compact。
CLAUDE.mdの棚卸しチェックリスト
3ヶ月に1回、以下のチェックリストでCLAUDE.mdを見直す。
- □ 200行を超えていないか？（
wc -l CLAUDE.md） - □ コードから分かることを書いていないか？（package.jsonの情報等）
- □ Claude Codeのアップデートで不要になったルールはないか？
- □ 特定タスクでしか使わないルールがないか？（→ Skillsに移動）
- □ ファイル種別ごとのルールがないか？（→ rules/に移動）
- □ 最重要ルールが冒頭5行にあるか？
- □ 全ルールにWHY（理由）がついているか？
- □ 同じルールがCLAUDE.mdとrules/の両方に書かれていないか？（重複削除）
- □ 3ヶ月前に追加したルールで、今も有効なものはどれか？
このチェックリストを3ヶ月ごとに実行するだけで、CLAUDE.mdの品質を維持できる。チェックリスト自体をSkill化（/claudemd-audit）して自動化するのも有効:
# .claude/commands/claudemd-audit.md
CLAUDE.mdの品質を監査してください。
チェック項目:
1. 行数が60行以内か（wc -l CLAUDE.md）
2. コードから分かる情報が含まれていないか
3. 重複するルールがないか
4. .claude/rules/ に移動すべきルールがないか
5. Skillsに移動すべきワークフローがないか
6. 不要になったルールがないか
7. 全ルールにWHY（理由）がついているか
改善提案を箇条書きで出してください。このSkillで/claudemd-auditを実行するだけで、Claude Code自身がCLAUDE.mdの品質をチェックしてくれる。人間が1行ずつ確認するより効率的で、見落としも少ない。
よくある質問
Q: 何行が最適？
公式推奨は200行以内。実務最適は60行前後。最重要5行 + プロジェクト概要 + 自己改善プロトコル で構成するのがベスト。→「書き方ガイド」の5行ルール参照。
Q: /initで作り直してもいい？
はい。バックアップを取ってから/initで再生成し、必要なルールだけ追加し直すのが最も確実な棚卸し方法。
まとめ｜肥大化を防ぐ3つのルール
- 60行以内に収める（200行超は危険）
- 3層構造で分散（CLAUDE.md → rules/ → Skills）
- 3ヶ月ごとに棚卸し（チェックリストで見直し）
CLAUDE.mdの書き方は「書き方ガイド」、テンプレートは「テンプレート集」、3ファイルの違いは「agents.md比較」、Skillsは「Skills完全ガイド」、使い方は「使い方ガイド」、コマンドは「コマンド早見表」を参照。
肥大化の兆候チェック
以下のサインが出たらCLAUDE.mdが肥大化している可能性が高い:
- ⚠️
wc -l CLAUDE.mdで100行を超えている - ⚠️ セッション後半でClaude Codeがルールを無視するようになった
- ⚠️ CLAUDE.mdに「この手順でやって」系のワークフローが5つ以上ある
- ⚠️ package.jsonやtsconfig.jsonの内容をCLAUDE.mdに転記している
- ⚠️ PHPルール、テストルール、デプロイ手順が全て同じファイルに混在している
肥大化を防ぐ方法｜3層構造（Progressive Disclosure）
CLAUDE.mdの肥大化を防ぐ最も効果的な方法は、情報を3つのレイヤーに分散するProgressive Disclosure（段階的開示）設計。Anthropicのベストプラクティスでも推奨されている手法。
Layer 3のSkillsが肥大化解決の本命。Skillsはセッション開始時にロードされないため、いくら増やしてもトークン消費に影響しない。CLAUDE.mdに書いていたワークフロー（「コードレビューの手順」「デプロイ手順」等）をSkillsに移すだけで、CLAUDE.mdが劇的に軽くなる。
rules/ディレクトリの活用パターン
rules/ファイルの実用的なパターンを紹介。全てglobs指定で条件付きロードされるため、CLAUDE.mdの行数を増やさずにルールを追加できる。
# .claude/rules/testing.md
---
description: テストファイル操作時のルール
globs: "**/*.test.*,**/*.spec.*"
---
- テストフレームワークはvitest（jestは使わない）
- describe/it形式で書く
- テスト名は日本語で書く
- 正常系と異常系の両方を必ず書く
# .claude/rules/git-commit.md
---
description: Git操作時のルール
globs: null
---
- コミットメッセージはConventional Commits形式
- 日本語で書く
- 1コミット = 1論理単位globsをnullにすると、手動で@.claude/rules/git-commit.mdで参照した時だけ読み込まれる。公式ドキュメントにglobs指定の詳細がある。
肥大化のBefore/After実測データ
| 指標 | Before（200行超） | After（60行+rules/+Skills） |
|---|---|---|
| CLAUDE.md行数 | 200行以上 | 60行 |
| sedによるPHP破壊事故 | 月2〜3回 | 0回 |
| /clear回数（1日） | 5〜6回 | 3回 |
| ルール無視の発生 | 頻繁（特にセッション後半） | ほぼなし |
| セッション開始のトークン消費 | 大 | 小（1/3以下） |
| Proプランでの1日利用時間 | 1.5〜2時間 | 3〜4時間 |
最も効果が大きかったのは「Proプランでの利用時間が2倍になった」こと。CLAUDE.mdが軽くなったことでセッション開始時のトークン消費が減り、その分実作業に使えるトークンが増えた。月$20の投資効果が倍増した形。
よくある質問（追加）
Q: rules/ファイルはいくつまで作れる？
制限はない。ただし該当ファイルを操作するたびにロードされるため、1ファイルあたり20行以内に収めるのが推奨。10個以上のrules/ファイルを作る場合は、本当に条件分けが必要か見直すこと。
Q: 棚卸しを自動化できる？
/memoryコマンドでClaude CodeにCLAUDE.mdを分析させると、「不要なルール」「重複」「コードから分かる情報」を指摘してくれる。完全自動とはいかないが、人間が1行ずつ確認するよりはるかに効率的。3ヶ月ごとに/memoryを実行して提案に従う運用がおすすめ。
# 棚卸しのコマンド例
> CLAUDE.mdの内容を分析して。以下の観点でチェック:
> 1. コードから分かる情報が含まれていないか
> 2. 重複するルールがないか
> 3. 不要になったルールがないか
> 4. rules/やSkillsに移動すべきルールがないか
> 改善提案を出して。Q: CLAUDE.mdなしで始めて後から追加しても大丈夫？
問題ない。最初はCLAUDE.mdなしで使い始め、Claude Codeが間違いを犯した時に初めてルールを追加するのが最も効率的な始め方。「推測でルールを書く」のではなく「失敗からルールを学ぶ」アプローチが、肥大化を防ぐ最大のコツ。→「書き方ガイド」の5行ルール
肥大化の経時変化と対策タイムライン
| 時期 | CLAUDE.mdの状態 | やるべきこと |
|---|---|---|
| Day 1 | 0行（/initで10-20行を自動生成） | /initを実行。まだルールは追加しない |
| Week 1-2 | 10-30行 | Claude Codeが間違えた時だけルール追加 |
| Month 1 | 30-60行 | 最適サイズ。このまま維持 |
| Month 2-3 | 60-100行 | ⚠️ 肥大化開始。ワークフロー部分をSkillsに移動 |
| Month 3+ | 100行超 | 🔴 危険。rules/への分離と棚卸しが必須 |
Month 1の30-60行が最適ゾーン。これを超えたら移行のサイン。放置すると200行超まで膨らみ、ルール遵守率が目に見えて下がる。私の経験では、100行を超えた時点で「sedでPHP編集しない」ルールが無視される事故が発生し始めた。60行に戻したら即座に改善した。
CLAUDE.mdのサイズ vs 遵守率の関係
私の実体験に基づく、CLAUDE.mdのサイズとルール遵守率の関係:
| CLAUDE.md行数 | 遵守率（体感） | トークン消費への影響 | Proプランでの利用時間 |
|---|---|---|---|
| 20行以内 | ◎ ほぼ100% | 最小 | 4時間+ |
| 40-60行 | ◎ 95%+ | 小 | 3-4時間 |
| 80-100行 | ○ 80-90% | 中 | 2-3時間 |
| 150行 | △ 60-70% | 大 | 1.5-2時間 |
| 200行超 | ✗ 50%以下 | 最大 | 1-1.5時間 |
注目すべきは「Proプランでの利用時間」の列。CLAUDE.mdが重いと、毎セッションで大量のトークンを消費するため、実作業に使えるトークンが減る。200行のCLAUDE.mdを60行に削減するだけで、利用時間が1.5倍になる。これは月$20の投資効果を直接的に高める改善。
