Claude が実際に従う CLAUDE.md はどう書くか？

CLAUDE.md は強制設定ではない——なぜ長いほど従われないのか

CLAUDE.md は、プロジェクトの指針（コーディング規則・構造・注意点）を書いておくと Claude Code が毎セッション一緒に読むファイルだ。しかし強制される設定ではない。コードで検査されて止められるのではなく、Claude が参照する指示文にすぎず、守ることも見落とすこともある。

だからルールを一つのファイルに積み続けると逆効果になる。長くなるほどルール同士が競合し、破られると困る核心の指示が大量の些細な指示に埋もれ、精度も落ちる。コツは「たくさん書く」ことではなく「引き締めておく」ことだ。以下の五つがその方法だ。

そもそも CLAUDE.md が適切か——強制ルールは hook へ

ターミナルで、hook が「never push to main」というメッセージとともに main への push を止める画面。権限設定に関わらず止めるプロジェクトレベルの hook——意図的なガードレールだという説明。 — hook は「never push to main」を実際に止める——依頼ではなく強制（Anthropic 公式動画）

ルールを書く前にまず問う。これは本当に CLAUDE.md に入れるべきか? 「絶対に main へ直接 push しない」のような必ず止めたいルールは、指示ではなく pre-tool-use hook に入れる。hook は Claude がその動作を実際に試みた瞬間に中断するよう設計されている。つまり「守ってほしいという依頼」ではなく「破ったら実際に止める遮断」だ。

区別はこうだ。CLAUDE.md の一行は Claude に従ってほしいもの、hook は破られたときに実際に止めるものだ。本番デプロイ、強制プッシュ、本番 DB の削除のように破られると大きく痛むルールは、CLAUDE.md の一行で「IMPORTANT」と叫ぶ代わりに hook へ移す。そうすれば CLAUDE.md はその分短くなり、強制すべきものは確実に強制される。

CLAUDE.md は四か所にある——managed・user・project・local

CLAUDE.md が存在する四か所をアイコンと説明で整理した図——Managed Policy（組織、除外不可）、User（個人、全プロジェクト）、Project（チーム共有）、Local（git 無視、このリポジトリの個人メモ）。 — CLAUDE.md の四か所: managed policy・user・project・local——すべて一緒に読み込まれる（Anthropic 公式動画）

CLAUDE.md はプロジェクトフォルダ内の一ファイルだけではない。四か所にある。managed policy は組織レベルのファイルでプラットフォームチームが管理し、個人は除外できない。user は自分のマシンの全プロジェクトに適用される個人設定だ。project はチームと共有するファイル。local は git に無視される、このリポジトリで自分だけの個人メモだ。

Claude はこれらのメモリファイルをすべて一緒に読み込む。何も捨てられず、組織ポリシーは常に効いている。だから「このスプリントでリファクタする間、これらの設計判断を覚えておいて」のような自分だけの一時的な文脈は、共有の project ファイルではなく local に入れる。みんなが見るべきルールと、自分だけの一時メモを混ぜないことが肝心だ。

@パス import で分ける——ただし何が得られるかを知る

エディタで開いた CLAUDE.md。「Split into topic files for readability — all still load at launch」というコメントと、@.claude/conventions/code-style.md などの @パス import 三行、その下に ## Rules セクション。 — @パス import は整理には役立つが、起動時にインライン展開され文脈は減らさない（Anthropic 公式動画）

CLAUDE.md が大きくなると、@パス import 構文で指示を複数ファイルに分割できる。たとえば `@.claude/conventions/code-style.md` のように書くと、そのファイルの内容がこの場所につながる。コードスタイル・テスト・ワークフローをトピック別ファイルに分ければ、大きな CLAUDE.md を保守しやすくなる。

ただし import が何をしてくれるのかを正確に知る必要がある。Claude は起動時に、import されたファイルを参照した位置のすぐ隣にインラインで展開する。つまり import は大きなファイルを整理するのには役立つが、結局すべて最初に一緒に読み込まれるので、文脈（トークン）の使用量は減らさない。「分けたから軽くなった」と勘違いしないこと——整理と文脈削減は別の話だ。

言い回しが遵守を分ける——具体的に、代替を名指しで

すべて「Don't」の形で書かれた CLAUDE.md の規約リスト——「Don't use default exports」「Don't use any」「Don't put business logic in components」など。 — 「Don't use default exports」は代替がなく曖昧——「Use named exports」の方がよい（Anthropic 公式動画）

同じルールでも、どう書くかで Claude の従う度合いは変わる。多くのルールが失敗するのは曖昧だからだ。第一に、具体的で検証可能に書く。「ベストプラクティスに従え」——それが何を指すのか人でも正確には言えない。Claude が自発的に守るはずもない。代わりに「新しい API ルートは src/api/handlers に一ファイル一つ」のように、確認できる形で明示する。

第二に、禁止するだけでなく代替を名指しする。「デフォルトエクスポートを使うな」では何を使うべきかが開いたままで、解釈の余地が残る。「名前付きエクスポートを使え、デフォルトエクスポートではなく」と書けば隙間を塞げる。何をするなとだけ言うと Claude が誤った代替を選びかねないので、代わりに何をすべきかを指す。

強調は予算だ——IMPORTANT は惜しんで使う

CLAUDE.md の「HARD RULES — DO NOT BREAK THESE」リスト。すべての行が YOU MUST NEVER、IMPORTANT、CRITICAL などの大文字強調で埋め尽くされている。 — すべてのルールに YOU MUST・IMPORTANT を付ければ何も際立たない——強調は二つ三つだけに（Anthropic 公式動画）

強調にも予算がある。IMPORTANT や YOU MUST はルールの優先度を上げるが、あくまで周りのより静かなルールに対して相対的にだ。すべての行に IMPORTANT・YOU MUST を付ければ、結局何も強調していないのと同じになる。全部叫べば、本当に大事なものは消える。

だから強調は、破られると本当に痛む二つ三つのルールにだけ使う。残りは淡々とした平叙文で置き、必ず強制すべきものは（前述のとおり）hook へ移す。強調を惜しむほど、残した強調が実際に力を持つ。

CLAUDE.md も改訂し続ける——誤ったらバグ報告のように

ターミナルでユーザーが「Ok, put in the CLAUDE.md file」と入力し、たった今決めたルールを CLAUDE.md に追加させる画面。 — 誤りを見たあと「CLAUDE.md に追加して」と言えば Claude がルールを書く（Anthropic 公式動画）

CLAUDE.md は一度書いて終わりではなく、改訂し続ける文書だ。Claude が誤った動作をしたら、それを CLAUDE.md へのバグ報告として扱う。何がなぜ誤ったかを見たうえで、Claude に「それをルールとして CLAUDE.md に追加して」と言えば、Claude がそのルールを文章にして書いてくれる。

こうすれば CLAUDE.md は実際に遭遇した問題をもとに少しずつ精緻になる。想像で先に詰め込むルールより、実際の失敗から抽出したルールの方がはるかによく守られ、無駄も少ない。

結論——CLAUDE.md をプロダクションコードのように

CLAUDE.md をプロダクションコードのように扱う。一行一行がなぜあるのかを正当化できるべきで、正当化できない行は消す。強制すべきものは hook へ移し、大きくなったファイルは @パス import で整理する。

そして特定の領域だけに当てはまるルールは、その領域でだけ読み込まれるように範囲を狭める（たとえば該当する下位ディレクトリの CLAUDE.md に置けば、そのフォルダで作業するときだけ一緒に読まれる）。ファイルが痩せているほど、Claude はその多くを守る。結局、Claude に CLAUDE.md を守らせるのは、どれだけ書いたかではなく、どれだけ抑えたかだ。