CLAUDE.mdの書き方｜肥大させずrulesに分散するLean構成の実例
CLAUDE.md にプロジェクトの決まりを書き足していくと、いつの間にか長大になり、肝心の指示が守られなくなる。原因は情報の不足ではなく、一枚に詰め込みすぎたことにある。結論から言えば、CLAUDE.md は目次に徹し、領域ごとの判断基準は .claude/rules/ に ID を付けて分散させるのがよい。本稿は、筆者が実運用している4プロジェクトの CLAUDE.md 実物を比べながら、その Lean 構成の設計を整理する。
CLAUDE.md が肥大して効かなくなる理由
CLAUDE.md は毎ターン、プロンプトの先頭に丸ごと載る。ここに数百行の規約を積むと、一つひとつの指示が相対的に薄まる。「エスケープは必ず通す」のような一行の禁止事項が、周囲の説明文に埋もれて効きにくくなる。これがコンテキスト希釈である。長く書くほど徹底されるわけではなく、むしろ逆に働く場面がある。
もう一つの問題は、載っている情報の大半が、その作業では使われないことである。CSS を直しているときにデプロイ手順や DB スキーマの契約まで毎回読ませても、判断の役には立たない。無関係な規約が常時トークンを占有し、いま効かせたい規約の存在感を下げる。効かなくなったと感じるとき、足りないのは指示ではなく、指示を整理する構造であることが多い。
Lean 本体＋rules 分散の設計原則
方針は単純である。CLAUDE.md 本体には、毎回必ず要るものだけを残す。 具体的には、技術スタック、日常の操作（ゴールデンパス）、やってはいけないこと（ガードレール）、そして詳細規約への目次。この4つがあれば、モデルは全体像を把握し、どこを深掘りすべきかを判断できる。
一方、領域ごとの判断基準は .claude/rules/ に出す。 アーキテクチャの原則、スキーマ契約、コーディング規約、デザイン、SEO、デプロイ——これらは該当作業のときだけ参照すれば足りる詳細である。本体に置くと希釈を招くが、rules に分ければ、必要な場面で必要な密度で効かせられる。
分散を機能させる鍵が、規約への ID 付与である。本リポジトリの CLAUDE.md は、rules への目次をこう書いている。
## ルール（必読・契約）
詳細は `.claude/rules/` に分割。会話では ID（例: ARCH-1）で参照する。
- `00-architecture` (ARCH-\*) … 単一の真実源・描画方針・レイヤリング
- `10-data-schema` (DATA-\*) … `sites.json` のスキーマ契約
# … 全6項目のうち2項目を抜粋ID を振っておくと、会話の解像度が上がる。「ここは ARCH-1 に反する」と一言で指摘でき、モデルも「DATA-6 に従って例外を投げる」と根拠を添えて応答できる。抽象的な「規約に従って」が、番号を介した具体的な照合に変わる。本体を薄く保つことと規約を ID で呼べるようにすることは、同じ設計の表と裏である。
実例 — 4プロジェクトの分散構成
分散といっても実装には幅がある。筆者が運用中の4プロジェクトは、いずれも本体＋rules 構成だが、ロードのさせ方が異なる。
目次＋ID 参照型（本ハブ）。 rules は .claude/rules/ に10本（先の目次抜粋が列挙するのは中核6本で、残る記事制作系4本は本体の別節から参照している）。本体40行あまりはスタック・ゴールデンパス・ガードレール・目次に徹し、判断基準は 00-architecture.md（ARCH-\*）や 10-data-schema.md（DATA-\*）に分散する。会話では ID で参照する運用と対になっている。
条件付きロード型（人口カルテ47）。 rules 7本を、常時読むものと編集ファイル連動のものに分ける。CLAUDE.md 側に「ロード条件」列を持つ表を置くのが特徴である。
| ファイル | ロード条件 | 内容 |
| `.claude/rules/architecture.md` | 常時 | ディレクトリ構成・データフロー・URL設計 |
| `.claude/rules/api-layer.md` | `lib/api_client.php`, `lib/models.php`, `api/*.php` 編集時 | HTTP・キャッシュ・fixture |
# … 全7本のうち2本を抜粋このプロジェクトは「設計書 > rules > CLAUDE.md」という優先順まで明記し、矛盾時の裁定を先に決めている。
参照テーブル型（国会議事録 AI要約）。 rules 8本へのポインタ表を持ち、加えてサブエージェントごとに「担当 rules のみ読めば完結する」割当を書く。本体には実装上の重要ルールを残しており、4例のなかでは本体が厚めで、分散の途上にある例としても読める。
## 詳細仕様の参照先 (.claude/rules/)
| ファイル | 内容 |
| `01-database.md` | スキーマ定義(CREATE TABLE)、全CRUDメソッド仕様、ローテーション |
| `03-processor.md` | LLMパイプライン、モデル使い分け、チャンキング、バリデーション |
# … 全8本のうち2本を抜粋@import 最小型（未公開の個人プロジェクト。日本語の小型言語モデルをスクラッチで自作している）。 本体20行あまりが最小構成の例である。目的とルール運用の宣言だけを置き、rules 7本を @import で明示的にロードする。
## ルール運用
全実装は ID 付きルール（`PREFIX-N`）に従う。ルールは `.claude/rules/` に分割。
コード生成・編集・レビュー時は、根拠となったルール ID を出力に必ず併記する（FLOW-4）。
@.claude/rules/00-flow.md
@.claude/rules/10-env.md
# … 全7本のうち2本を抜粋同じ原則でも、常時ロード・条件付き・ポインタ参照・明示 import と実装は分かれる。プロジェクトの規模と、規約をどれだけ確実に読ませたいかで選べばよい。
分散の判断基準と失敗例
分散にも失敗の型がある。第一に、参照されない rules。ファイルに書いただけで、本体の目次からも会話からも呼ばれない規約は、事実上存在しないのと同じである。書くこと自体が目的化すると起きる。rules は運用に接続して初めて効く。
第二に、過剰分割。一つの判断のために三つのファイルを開かないと結論が出ない状態は、希釈とは別の摩擦を生む。判断が一箇所で完結する粒度に束ねるべきで、細かく割ればよいわけではない。
第三に、本体が再び太る問題。放置すると CLAUDE.md はまた膨らむ。人口カルテ47 のプロジェクトは、これを自己保守規約で抑えている。
## このファイルの保守
- 150行以内を維持。追加情報は `.claude/rules/` 配下へ
# … 全3項目のうち1項目を抜粋上限を先に決め、超えたら rules へ出すと明文化しておくと、肥大に歯止めがかかる。逆に、rules へ出した内容が毎回必要だと分かれば、本体へ戻す判断もあってよい。分散は一度きりの作業ではなく、どちらへ動かすかを見直し続ける運用である。
なお、本体のガードレール（やってはいけないこと）は、フェーズを刻んで作業を止める運用と組み合わせると効く。工程分割そのものについては別記事で扱っている。
よくある質問
.claude/rules/ は自動で読まれるのか。 挙動は断定しない。確実に読ませたいなら、本稿の実例のように @import で本体から明示ロードするか、本体の目次から参照するのがよい。筆者の環境（Claude Code v2.1.211、2026-07-16 確認）では、@import で並べた rules が本体と一緒にロードされることを確認している。暗黙のロードに頼らず、読ませたい規約は明示的に接続しておくのが安全だと考えている。
プロジェクト間で規約を共有するには。 同じ規約を複数リポジトリで使い回したい場合は、rules ではなくスキルとして切り出す方法がある。詳細は別記事に譲るが、共有の単位を rules と分けて考えると整理しやすい。
まとめ
CLAUDE.md が効かなくなるのは、情報が足りないからではなく、一枚に詰め込みすぎて希釈されるからである。本体は技術スタック・ゴールデンパス・ガードレール・目次に絞り、領域ごとの判断基準は ID を付けて .claude/rules/ に分散する。ロードのさせ方は選べるが、共通するのは「本体は薄く、規約は番号で呼べる」ことである。上限を決めた自己保守規約を仕込み、本体と rules の間で内容を動かし続けることが、Lean な状態を保つ要点だと考えている。