Claude Code には ~/.claude/projects/<dir>/memory/ に Markdown で会話履歴を蓄積する仕組みがある。4 タイプの使い分け、CLAUDE.md との役割分担、運用してわかったハマりどころまで、実例ベースでまとめた。
28 April, 2026
PR本記事には広告・アフィリエイトリンクが含まれることがあります（開示）
結論: Claude Code には
~/.claude/projects/<dir>/memory/配下に Markdown でユーザー情報・プロジェクト情報を蓄積する仕組みがある。意図的に育てると毎回の前置き説明が要らなくなる。CLAUDE.md（宣言的ルール）と役割が逆で「観測的に貯まる方」を担当する。
MEMORY.md インデックス + 個別 Markdown）user / feedback / project / reference）の使い分けClaude Code は ~/.claude/projects/<プロジェクトパスをエンコードしたディレクトリ>/memory/ 配下に、会話を通じて学んだ情報を Markdown ファイルとして自動的に書き残していく。ChatGPT のメモリと違って 全部 Markdown で見える、編集できる、削除できる、バックアップできるのがいちばんの違いになる。
構造はシンプルで、MEMORY.md がインデックスとして毎セッションの最初に読み込まれ、そこに並んだ各 *.md が必要に応じて参照される、という二段構成になっている。
個別ファイルは frontmatter として name / description / type を持ち、type で 4 つに分類される。
---
name: ロールと専門領域
description: 個人ブログ運営者、Web/インフラを横断する個人開発者
type: user
---
個人ブログ s1mlog を運営。
普段は Next.js/Go を書く。
説明は要点先出しを好む。ファイル名は型から始める運用が読みやすい（user_role.md、feedback_testing.md、project_release.md など）。
user — 「誰が話しているか」役割、専門領域、好み、コミュニケーションスタイル。Claude が回答を「あなた向けに」調整するための情報。例:
これがあるだけで、同じ質問に対する回答の解像度が変わる。
feedback — 「過去にどう指示されたか」会話の中で出した修正・好み・ルールの蓄積。同じ訂正を 2 回しなくて良くするのが目的。例:
rg を優先、grep は使わない」大事なのは なぜそうしたいのか（Why）とどこに適用されるのか（How to apply）を一緒に書くこと。理由なしで「禁止」だけ書くと、エッジケースで判断できなくなる。
project — 「いま何が動いているか」進行中の案件の経緯、決定事項、宿題、関係者。コードや git log から再現できないコンテキストを残す枠。例:
状態が変わりやすいので絶対日付で書くのがコツ（「来週」「先日」と書くとあとで意味不明になる）。
reference — 「どこに情報があるか」外部システムのポインタ。Slack のどのチャンネル、Linear のどのプロジェクト、Grafana のどのダッシュボード、といった情報源の地図。中身は書かない、場所だけ書く。例:
grafana.internal/d/api-latency を確認」「書くな」と言っているのは、コードに対する 真実の単一情報源（Single Source of Truth）を守るため。同じ事実を 2 箇所に書くと、必ずどちらかがズレる。
Claude に渡せるテキスト情報は他にも CLAUDE.md がある。両者は守備範囲が違う、というより性質が逆になっている。
切り分けの軸はだいたいこれ:
例えば「テストは npm test で動く」は CLAUDE.md に書く事実。「このユーザーはテスト前にビルドの型エラーを潰す派」は memory に書く観察。
メモリは 書いた時点のスナップショットであって、ライブステートではない。「半年前にあった機能 X」が削除されているのに、メモリにだけ残っていると Claude は存在前提で動こうとして失敗する。
対策はシンプルで、ファイルパス・関数名・フラグ名のような具体的な参照を含むメモリは、使う前に grep で実在確認するのを習慣にする。Claude 自身も賢く、最近の運用ガイドライン上「メモリの参照を実際の作業に反映する前に、現状の確認を一段挟む」というルールが入っている。書き手としては、メモリの内容が古くなっていたら気づいたタイミングで更新・削除する。
MEMORY.md の 200 行制限MEMORY.md は毎セッション全部読み込まれる前提なので、200 行を超える分は切られる仕様になっている。これは「インデックスは簡潔にしろ」というデザイン上の制約で、メモリ本文は個別ファイルに置くべし、という設計が暗に求められている。
実運用では MEMORY.md の各行を - [Title](file.md) — one-line hook 形式で、150 文字以内にまとめると安定する。詳細は個別ファイル側に書く。
メモリが便利だからといって何でも書くと、インデックスが膨らんで関連性の判定が雑になる、内容がコードと二重管理になって陳腐化する、機密が混ざる、と全部のデメリットが出る。「再現できない情報だけを書く」原則を守れば、ファイル数が増えてもノイズにはならない。
セッション中に「メモリを使うな」「メモリを無視しろ」と指示すると、Claude はその会話の間メモリの内容を引かなくなる。第三者にデモする時、メモリ依存の挙動を切りたい時に使える。
新規セッション開始時の「前置き説明」がほぼ消えた。Claude が「このプロジェクトはこういう構造で、自分はこういう人で、過去にこう指示してある」を最初から踏まえてくる。1 セッション内で説明していた前提が、次回以降は自動で適用される、という体験ができる。
特に効くのが feedback 系。「同じ修正をする頻度」を体感で減らせる。例えば「PR の summary は短く」と一度伝えれば、以降は短く出してくる。これが積み上がる。
もう一つは メモリ自体を読み返す価値がある。1 ヶ月分の project_*.md や feedback_*.md を眺めると、自分が無意識に繰り返している判断パターンが見える。Claude のためというより自分用のリフレクションツールとしても機能している、というのが思っていなかった発見だった。
~/.claude/projects/<dir>/memory/ に Markdown で蓄積され、編集・削除・バックアップが効くuser / feedback / project / reference）を使い分け、MEMORY.md をインデックスにして簡潔に保つ使い始めると「LLM に自分のことを覚えていてほしい、でもブラックボックスは怖い」というジレンマが、可視化された Markdown のおかげで解消される。意図的に育てる価値のある仕組み。