Claude Codeのメモリ階層を完全理解する：何がいつ自動で読まれるのか

Claude Codeを使い込んでいくと、必ずこの疑問にぶつかります。

「CLAUDE.md に書いたルールは毎回読まれるの？ メモリに保存した内容は、次のセッションでも勝手に反映される？」

「メモリに保存しました、次回も自動で反映されます」と説明されても、実際に何がいつ読み込まれているのかが曖昧なまま使っている人は多いはずです。

この記事では、Claude Codeのメモリ・設定ファイルの2層構造を整理します。「自動で読まれる層」と「必要なときだけ読まれる層」の違い、そしてコンテキスト（＝Claudeが一度に把握できる作業メモリの上限）を節約しながら確実に挙動を制御する方法をまとめました。

なお、複数クライアントをClaude Codeで管理する際の情報設計はClaude Codeで複数クライアントをスキル管理する設計で全体像を扱っています。本記事はその中の「記憶を3階層に分ける」という発想を、メモリ階層の仕組みそのものに踏み込んで深掘りする位置づけです。

結論：Claude Codeのメモリは「インデックス層」と「本体層」の2階建て

要点を先に並べます。

• 設定・メモリには毎回自動で読まれる層と、必要なときだけ読まれる層がある
• CLAUDE.md・rules/・メモリのインデックスは、セッション開始時に自動でコンテキストに入る
• インデックスからリンクされた個別ファイルの中身は、自動では読まれない（必要なときにツールで開く）
• だから「メモリに保存したから次回も完璧に反映される」は半分正しく、半分間違い

この構造がわかると、「なぜルールが効いたり効かなかったりするのか」「どこに書けば確実に反映されるのか」が見えてきます。

一目で掴む早見表

最初にこの記事の結論を表で。

この4行が頭に入っていれば、以降はその裏付けと使い分けの話です。

自動で読まれる層（毎セッション）

Claude Codeはセッション開始時に、いくつかのファイルを自動的にコンテキストへ注入します。代表的なものは次の通り。

ここに書いた内容は、セッションが始まった瞬間からClaudeの目に入っています。だから次のような常時守ってほしい指示は、CLAUDE.md や rules/ に置くのが正解です。

• 「日本語で応答する」
• 「コミットメッセージはConventional Commits形式」
• 「このプロジェクトのDBはPostgreSQL」

逆に言うと、ここに置かない指示は「毎回確実に効く」とは限りません。

自動では読まれない層（必要なときだけ）

一方、メモリのインデックスからリンクされた個別ファイルの本体は、自動では読み込まれません。

たとえばインデックスにこう書いてあるとします。

## Feedback
- [n8n-diagnosis](feedback-n8n-diagnosis.md)：n8n障害は生エラーログから読む

この1行の要約は自動で読まれます。しかしリンク先 feedback-n8n-diagnosis.md の中身、つまり詳細な手順・トリガー条件表・アンチパターンは、Claudeが「今このファイルが関連しそうだ」と判断して開かない限り読まれません。

ここに非対称があります。

• インデックスの1行は毎回読まれる
• リンク先ファイルの詳細は、関連すると判断されたときだけ読まれる

これが意味すること：「保存したから安心」ではない

ここを取り違えると設計を間違えます。

メモリに詳細なルールを保存しても、インデックスの要約に書かれていない情報は、次回セッションで自動的には反映されません。

具体例で考えます。あるルールをメモリに保存したとして、反映の確実性はシナリオごとに変わります。

だから絶対に守ってほしい挙動は、インデックスの1行に要旨を凝縮するか、CLAUDE.md / rules/ に直接書く。リンク先の奥に埋めると、参照されないリスクが残ります。

コンテキストを節約しながら確実性を上げる方法

「じゃあ全部 CLAUDE.md に書けばいいのか」というと、それは間違いです。CLAUDE.md が肥大化すると毎回のコンテキスト消費が増え、肝心の作業スペースが圧迫されます。

確実性とコンテキスト消費はトレードオフ（＝あちらを立てればこちらが立たない関係）にある。3つの選択肢で使い分けます。

選択肢A: メモリのインデックスに要旨を書く（軽量・推奨）

詳細はリンク先に置きつつ、インデックスの1行に「何をすべきか」の核心を凝縮します。これだけで、要旨レベルの反映は毎回保証される。

- [rule-name](rule-name.md)：〇〇のときは△△する（理由は1行で）

選択肢B: rules/ に独立ファイルとして置く（中量・確実）

rules/ 配下は毎回自動で読まれるので、トリガー条件やフォーマットも常時参照されます。絶対に守らせたいルールはここへ。ただしファイル数が増えるとコンテキスト消費も増えるので、本当に重要なものに絞ります。

選択肢C: CLAUDE.md に直接書く（重量・最確実）

最も確実な代わりに、CLAUDE.md が肥大化します。1行で済む最重要事項だけにとどめます。

スキルの「Progressive Disclosure」も同じ構造

「インデックスは読む、本体は必要時だけ」という設計は、Claude Codeのスキル機能にも共通しています。

• スキルの名前と説明（description）は毎回読まれる（どのスキルがあるか把握するため）
• スキルの本体（手順・スクリプト）は、そのスキルが呼び出されたときだけ読まれる

これを Progressive Disclosure（＝段階的開示。必要になった分だけ中身を開く仕組み）と呼びます。全スキルの中身を毎回読み込んでいたら、コンテキストが一瞬で枯渇するでしょう。だから「目次は常に見える、中身は必要なときに開く」設計になっています。

メモリもスキルも同じ思想で動いていると理解すると腑に落ちます。

アンチパターン3つ

アンチパターン1: 重要ルールをリンク先の奥に埋める

「メモリに詳しく書いたから大丈夫」と、絶対守らせたいルールをリンク先ファイルの奥に置いてしまう。インデックスに要旨がないと参照されないリスクが残ります。重要なものほどインデックスか rules/ に出すのが鉄則です。

アンチパターン2: 何でも CLAUDE.md に書いて肥大化させる

確実性を求めるあまり CLAUDE.md に全部書く。結果、コンテキストが圧迫され、肝心の作業効率が落ちました、というパターン。1行で済む最重要事項だけに絞ります。

アンチパターン3: 「メモリに保存=完璧に反映」と過信する

保存したルールが次回も100%完璧に適用されると思い込む。実際は「インデックスの要約レベル」での反映が中心になる。何がどこまで反映されるかを理解した上で書き分けましょう。

まとめ：メモリは「目次は常に読む、中身は必要なときだけ」

Claude Codeのメモリ・設定の本質は次の3点です。

1. 自動で読まれる層（CLAUDE.md / rules/ / インデックス）と、必要なときだけ読まれる層（リンク先ファイル）の2階建て
2. インデックスの1行は毎回読まれるが、リンク先の詳細は自動では読まれない
3. 確実性とコンテキスト消費はトレードオフ。重要度に応じてA/B/Cを使い分ける

「メモリに保存したから次回も安心」ではありません。次回も確実に反映させたいなら、インデックスか rules/ に要旨を出す。この一手間が、Claude Codeを長期運用するうえでのコンテキスト設計の肝になります。

AIエージェントの運用設計でお困りなら

Claude Codeを使い始めたものの設定ファイルが膨らんできた、ルールを書いたのに効いたり効かなかったりする、社内に挙動を制御できる人がいない。こうした状態の方は、メモリ・設定の置き場所設計が原因になっているケースが多いです。設定を増やすほど精度が下がる、という逆転も珍しくありません。

f2t.jpでは、AIエージェントの設計から、メモリ・ルールの構造設計まで一貫してお手伝いしています。お問い合わせフォームからお気軽にどうぞ。