プロジェクトでClaude Codeを使っていると、2つの要望が生まれます。「このルールは毎回守って」と「前回わかったことを覚えておいて」です。
前者を担うのがルールファイルのCLAUDE.mdで、後者を担うのがメモリ機能です。どちらも「セッション終了後も残る指示」なので混同しやすいものの、管理主体と性質は異なります。
この記事では、CLAUDE.mdの階層構造、メモリ機能の動作、そしてどの内容をどこに置くべきかの基準を整理します。
まずは要点を確認しましょう。
- CLAUDE.mdは毎セッション自動で読み込まれるルールファイルで、グローバルとプロジェクト単位に分かれます。
- メモリは、Claudeが作業中に知った事実をプロジェクト別のフォルダーへ自分で記録・取得する機能です。
- 人が決めたルールはCLAUDE.md、エージェントが蓄積した経験はメモリに分けます。
- どちらもコンテキストを消費するため、「常に必要か」を基準にスリムに保つ必要があります。
CLAUDE.mdは場所が適用範囲を決める
CLAUDE.mdは、セッション開始時にプロンプトへ全文が読み込まれるMarkdownファイルです。コーディング規約、禁止事項、プロジェクトの背景など、「常に正しい状態であるべきルール」を記述します。
同じ名前のファイルでも、場所によって適用範囲が異なります。
| 場所 | 範囲 | 共有 |
|---|---|---|
| ~/.claude/CLAUDE.md | すべてのプロジェクト | 個人専用 |
| project/CLAUDE.md | 該当プロジェクト | Gitでチーム共有 |
| subfolder/CLAUDE.md | そのフォルダーで作業するとき | Gitでチーム共有 |
グローバルファイルには、コミットスタイルや応答言語などプロジェクトに関係しない個人の好みを、プロジェクトファイルにはリポジトリ固有のルールを置きます。2つの階層が衝突する場合は、より具体的なプロジェクトルールを優先すると明記しておくのが安全です。
ファイルが長くなったら、@경로/파일.md形式で別の文書をインポートして分割できます。ただしインポートした文書もコンテキストに入るため、容量節約ではなく管理のしやすさのための機能と考えるべきです。
メモリはエージェントが自分で書くノート
CLAUDE.mdが人の書くトップダウンのルールなら、メモリは逆方向に働きます。Claudeが作業中に知った事実をプロジェクト別のメモリフォルダーへファイルとして記録し、次のセッションで再び取り出して使います。
仕組みは単純です。1つのメモリが1つのファイルに対応し、インデックスファイルのMEMORY.mdに1行の要約が蓄積されます。セッション開始時にはインデックスだけがコンテキストに入り、個々のメモリ本文は関連する作業のときに読み込みます。
記録される内容の性質もルールとは異なります。「このDBはバッチ処理後に型検査が必要だった」「変更を反映するにはこのワークツリーでdevサーバーを起動する必要があった」といった、文書にはなく経験して初めてわかる事実です。人がルールとして明文化する前の経験知が蓄積されます。
会話中に#で始まるメッセージを送り、「これを覚えておいて」と直接指示することもできます。その場合、Claudeが保存先のファイルを尋ねるか、自動で分類します。
どこに置くかを決める基準
役割が重なって見えるときは、3つの質問で判断します。
1つ目は、誰が決めた内容か。チームや自分が決めたルールならCLAUDE.md、作業中に発見した事実ならメモリです。
2つ目は、破ったときに問題になるか。秘密鍵のコミット禁止やデプロイ手順など、違反がそのまま事故につながるルールは必ずCLAUDE.mdに置きます。メモリは取得が保証された強制装置ではなく、参考ノートに近いからです。
3つ目は、コードやドキュメントからすでにわかるか。リポジトリを読むだけでわかる内容は、どちらにも入れないのが原則です。コンテキストを浪費するだけで、コードが変われば誤情報になります。
運用で守るべき2つのこと
1つ目は、定期的に整理すること。CLAUDE.mdはルールが増えるだけで削除されない傾向があります。無効になったルールや一度きりの指示は見つけ次第削除し、毎セッションのコンテキスト浪費を防ぎます。メモリも同様に、コードの変更で事実でなくなった項目は残すより削除したほうがよいでしょう。
2つ目は、ルールを短く断定的にすること。「できれば～するのがよいです」よりも、「～する」「～禁止」のような短文のほうが守られます。1行の例を添えると遵守率が目に見えて上がります。
まとめ
CLAUDE.mdは憲法で、メモリは業務日誌です。人が決めた不変のルールは上から伝え、現場で得た経験は下から積み上げる構造です。
この2つを分けて管理し始めると、毎セッション同じ説明を繰り返すことも、前のセッションの試行錯誤を再び経験することも減ります。