結論: Claude Code には ~/.claude/projects/<dir>/memory/ 配下に Markdown でユーザー情報・プロジェクト情報を蓄積する仕組みがある。意図的に育てると毎回の前置き説明が要らなくなる。CLAUDE.md（宣言的ルール）と役割が逆で「観測的に貯まる方」を担当する。

この記事で書くこと

• Claude Code 自動メモリの仕組み（保存場所、MEMORY.md インデックス + 個別 Markdown）
• 4 タイプ（user / feedback / project / reference）の使い分け
• 育て方 — 何を書くべきで、何を書かないべきか
• CLAUDE.md との役割分担（宣言的 vs 観測的）
• 1 ヶ月運用してわかったハマりどころ

自動メモリ機能の概要

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 など）。

4 タイプの使い分け

user — 「誰が話しているか」

役割、専門領域、好み、コミュニケーションスタイル。Claude が回答を「あなた向けに」調整するための情報。例:

• 「個人ブログ運営者で、Next.js / Go が主戦場」
• 「説明は要点先出し、長い前置きは嫌う」
• 「未経験領域のときは比喩より具体例で説明されると入りやすい」

これがあるだけで、同じ質問に対する回答の解像度が変わる。

feedback — 「過去にどう指示されたか」

会話の中で出した修正・好み・ルールの蓄積。同じ訂正を 2 回しなくて良くするのが目的。例:

• 「テストは無効化・スキップしない」
• 「コード探索は rg を優先、grep は使わない」
• 「PR は要約 1〜3 行だけ、長文サマリは不要」

大事なのは なぜそうしたいのか（Why）とどこに適用されるのか（How to apply）を一緒に書くこと。理由なしで「禁止」だけ書くと、エッジケースで判断できなくなる。

project — 「いま何が動いているか」

進行中の案件の経緯、決定事項、宿題、関係者。コードや git log から再現できないコンテキストを残す枠。例:

• 「2026-04-26 にユーザー判断で Qiita 移管記事の大半をロールバックした。理由は AdSense 審査・商標・コンテンツ品質」
• 「リリースは 2026-05-12 凍結予定、緊急修正以外マージ禁止」

状態が変わりやすいので絶対日付で書くのがコツ（「来週」「先日」と書くとあとで意味不明になる）。

reference — 「どこに情報があるか」

外部システムのポインタ。Slack のどのチャンネル、Linear のどのプロジェクト、Grafana のどのダッシュボード、といった情報源の地図。中身は書かない、場所だけ書く。例:

• 「パイプライン系のバグは Linear の INGEST プロジェクトで管理」
• 「リクエスト経路を触るときは grafana.internal/d/api-latency を確認」

育て方: 何を書くか、何を書かないか

書くべきこと

• 非自明な合意・判断履歴: コードを読んでも意図がわからない決定（「敢えてこの方式を選んだ理由」）
• 繰り返される指示・好み: 同じ訂正を何度もしている自覚があるもの
• 現状を理解するためのコンテキスト: いま何が進行中で、何が止まっていて、なぜ止まっているか
• 外部リソースの地図: 「これを触るときはあのダッシュボードを確認する」

書かないべきこと

• コードから読めること: アーキテクチャ、ファイルパス、関数名（grep で取れる）
• git log / git blame で取れること: 「いつ誰が何を変えた」
• デバッグの解決策: 修正は既にコードに入っているはず。残すならコミットメッセージか PR 説明
• CLAUDE.md に書いてあること: 重複は陳腐化の温床になる
• その場限りのタスク状態: 進行中の TODO や会話のフロー
• 機密情報: API キー、個人情報、未公開の人事情報

「書くな」と言っているのは、コードに対する 真実の単一情報源（Single Source of Truth）を守るため。同じ事実を 2 箇所に書くと、必ずどちらかがズレる。

CLAUDE.md との役割分担

Claude に渡せるテキスト情報は他にも CLAUDE.md がある。両者は守備範囲が違う、というより性質が逆になっている。

切り分けの軸はだいたいこれ:

• 誰が書くか: CLAUDE.md は人間、memory は Claude
• 何を書くか: CLAUDE.md は「こうしてほしい」、memory は「こう観測した」
• どこに置くか: CLAUDE.md はリポジトリにコミット（チーム共有）、memory はローカル個別（git 管理外）
• いつ書くか: CLAUDE.md はプロジェクト立ち上げ時に整備、memory は会話のたびに育つ

例えば「テストは 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 はその会話の間メモリの内容を引かなくなる。第三者にデモする時、メモリ依存の挙動を切りたい時に使える。

1 ヶ月運用して感じた効果

新規セッション開始時の「前置き説明」がほぼ消えた。Claude が「このプロジェクトはこういう構造で、自分はこういう人で、過去にこう指示してある」を最初から踏まえてくる。1 セッション内で説明していた前提が、次回以降は自動で適用される、という体験ができる。

特に効くのが feedback 系。「同じ修正をする頻度」を体感で減らせる。例えば「PR の summary は短く」と一度伝えれば、以降は短く出してくる。これが積み上がる。

もう一つは メモリ自体を読み返す価値がある。1 ヶ月分の project_*.md や feedback_*.md を眺めると、自分が無意識に繰り返している判断パターンが見える。Claude のためというより自分用のリフレクションツールとしても機能している、というのが思っていなかった発見だった。

まとめ

• Claude Code の自動メモリは ~/.claude/projects/<dir>/memory/ に Markdown で蓄積され、編集・削除・バックアップが効く
• 4 タイプ（user / feedback / project / reference）を使い分け、MEMORY.md をインデックスにして簡潔に保つ
• 「コードや git log で取れることは書かない」を守ると陳腐化しにくい
• CLAUDE.md（宣言的・能動的）と memory（観測的・受動的）は性質が逆で、両方使うと役割が補完される
• 古いメモリが現状からズレるリスクには、「使う前に現状確認」を挟むことで対応する

使い始めると「LLM に自分のことを覚えていてほしい、でもブラックボックスは怖い」というジレンマが、可視化された Markdown のおかげで解消される。意図的に育てる価値のある仕組み。