*【ポエム】Claude Codeのmemoryは勝手に消えない 長期運用で付箋が腐る仕組みと対策メモ

Claude Codeのmemoryは勝手に消えない　長期運用で付箋が腐る仕組みと対策メモ

このメモ書きは、Claude Codeで長いスレッドを立て直す際に「引き継ぎをmemoryに書くべきか」を検討した過程で整理した、memoryの性質と運用上の注意点をまとめたものである。

発端：スレッドの立て直しと引き継ぎ

スレッドが長くなると、古いやり取りは自動で要約されていく。その過程で「なぜその値にしたか」「試してダメだったこと」といった細かい経緯が抜け落ちやすくなる。このため長くなったスレッドは立て直すのが望ましい。

問題は引き継ぎの方法である。

方法	内容
memoryに書く	新しいスレッドで自動的に読まれる
チャットに出力して貼る	新しいスレッドの最初に手で貼る。その1回だけ読まれる

memoryに書けば手間はかからない。ただし「memoryに引っ張られて意図しない動きにならないか」という懸念がある。この懸念は正しく、memoryの性質を理解しないまま書き続けると実際に事故が起きる。

memoryの正体

memoryはAIの脳内にある記憶ではなく、手元のディスクにあるただのテキストファイルである。

~/.claude/projects/<プロジェクトのパス>/memory/
  MEMORY.md      ← 目次
  xxx.md         ← 個別のメモ

性質は次のとおりである。

性質	内容
期限切れがない	書いた日付で古いと判断されることはない
終わった話を知らない	「切り分け中」と書いてあれば半年後でも切り分け中として読む
消えるのは誰かが消したときだけ	人が手で消すか、AIに消すよう頼むか

memoryは「毎回読まれる付箋」であり、剥がさない限りずっと貼られ続ける。

会話中にAIが「この記述は古い」と気付いて自発的に直すこともあるが、確実ではない。当てにする運用は危険である。

付箋が溜まっていく流れ

スレッドを立て直すたびにmemoryへ引き継ぎを足していくと、次のようになる。

問題は行数の増加より、新旧の矛盾が混ざることにある。

1回目：「方式Aでいく」
2回目：「やっぱり方式Bにする」
3回目：「方式Aは廃止」と書き忘れる

この状態では付箋に「方式Aでいく」と「方式Bにする」が並んでいる。AIはどちらが新しいか判別できないまま読むため、廃止済みの方式Aを持ち出すことがある。

症状	原因
終わった話を蒸し返す	古い付箋が残っている
方針がブレる	矛盾した付箋が混在している
肝心な指示が効きにくい	付箋が多すぎて埋もれている

目次ファイルは先頭から一定行数までしか自動で読み込まれない仕様になっている。付箋を溜め込むほど、重要な記述が読まれない位置へ押し出される可能性がある。

memoryに向くもの・向かないもの

向いている	向いていない
長く変わらない方針	版番号
「指示があるまでコードを書かない」	切り分け中の作業
「gitはユーザーが操作する」	やることリスト
設計方針・作風	すぐ変わる状態全般

すぐ変わる状態はmemoryに書かず、チャットに出力して新スレッドの最初に1回だけ貼る。1回読まれたら後に残らないため、古い前提に引っ張られない。

経緯や値の理由といった詳細は、リポジトリ内の開発メモやコードのコメントに残す。AIの記憶ではなくリポジトリに置くことで、スレッドを何度立て直しても情報が崩れない。

memoryが読まれるタイミング

memoryはプロジェクト単位で、スレッドを開くたびに無条件で読まれる。話題との関連性は判断していない。

プロジェクトの単位は、Claude Codeを起動した作業ディレクトリで決まる。パスのスラッシュをハイフンに置き換えた名前のフォルダに保存される。

作業ディレクトリ：/var/www/html/my_projects
memoryの場所  ：~/.claude/projects/-var-www-html-my-projects/memory/

読み込みは2段階になっている。

対象	読まれるタイミング
目次（MEMORY.md）	スレッド開始時に毎回自動で読む
個別のメモファイル	目次を見たAIが今の話に必要と判断したときに読む

関連性の判断が働くのは個別ファイルのほうだけであり、目次は問答無用で毎回入る。

モノレポでの問題

1つのLaravelアプリの中に、複数のプロジェクトを同居させている構成を想定する。

my_projects/        ← Laravelアプリのルート
  app/
    GameX/          ← 自作ゲーム
    ToolY/          ← ツール
    ResearchZ/      ← AI研究
  storage/
  config/
  routes/

この構成でルートからClaude Codeを起動すると、すべてのプロジェクトの付箋が1枚のボードに貼られることになる。

• 「アルゴリズムAはv15」とあっても、どのプロジェクトの話か判別できない
• 似た名前の設定や機能があると取り違える
• 関係ないプロジェクトの作業中にも、別プロジェクトの付箋が効いてくる

サブフォルダ起動が使えない理由

サブフォルダで起動すればmemoryは分かれる。しかしLaravelでは storage/、config/、routes/ などが全プロジェクト共通であり、サブフォルダ起動ではこれらに手が届きにくくなる。共通基盤を持つモノレポでは、起動場所をルートに固定したまま分ける工夫が必要になる。

ルート起動のまま分ける方法

1. memoryを目次とプロジェクト別ファイルに分ける

memory/
  MEMORY.md      ← 共通ルールと索引のみ
  game_x.md
  tool_y.md
  research_z.md

# MEMORY.md
- 共通：指示があるまでコードを書かない、gitはユーザーが操作する
- ゲームXの話 → game_x.md
- ツールYの話 → tool_y.md
- 研究Zの話 → research_z.md

目次は毎回読まれるが、個別ファイルは関連するときだけ読まれる。この2段階の仕組みを利用して混線を防ぐ。

2. CLAUDE.mdをモジュールのフォルダに置く

my_projects/
  CLAUDE.md               ← 全体共通の規約
  app/GameX/CLAUDE.md     ← ゲームX固有の規約
  app/ResearchZ/CLAUDE.md ← 研究Z固有の規約

サブフォルダのCLAUDE.mdは、そのフォルダ内のファイルを触ったときに追加で読み込まれる。ルート起動のまま個別ルールを効かせられる。

3. スレッドの1行目で対象を宣言する

「今回は研究Zの話である」と最初に書く。AIが参照すべき付箋とファイルを絞り込める。地味だが最も確実な手段である。

memoryとCLAUDE.mdの所在地

種類	パス	範囲
自動memory	~/.claude/projects/<プロジェクトのパス>/memory/MEMORY.md	プロジェクトごと・手元のみ
ユーザー共通	~/.claude/CLAUDE.md	全プロジェクト共通・手元のみ
プロジェクト	<プロジェクト>/CLAUDE.md または <プロジェクト>/.claude/CLAUDE.md	リポジトリに含めてチーム共有
サブフォルダ	<プロジェクト>/<フォルダ>/CLAUDE.md	そのフォルダを触ったとき
組織管理者用	Linuxでは /etc/claude-code/CLAUDE.md	組織全体に強制

置きたいもの	置き場所
全プロジェクトで効かせたい自分の癖	~/.claude/CLAUDE.md
リポジトリの規約	プロジェクトの CLAUDE.md
モジュール固有の規約	サブフォルダの CLAUDE.md
AIが自分で書き留める付箋	自動memory

CLAUDE.mdはリポジトリに入れて共有する「規約」、memoryは手元だけの「付箋」という役割分担になる。仕様はバージョンアップで変わることがあるため、Claude Code上で /memory を実行し、実際に読み込まれているファイルの場所を確認するのが確実である。

まとめ

論点	結論
memoryの正体	手元のテキストファイル。毎回読まれる付箋
自動で消えるか	消えない。期限切れも「終わった話」の判断もない
溜まると起きること	新旧の矛盾が混在し、廃止した話を持ち出す
運用の基本	足さずに書き換える。立て直し時に棚卸しする
memoryに書くもの	長く変わらない方針のみ
すぐ変わる状態	チャットに出力し新スレッドで1回だけ貼る
経緯・値の理由	リポジトリの開発メモやコメントに残す
読まれる単位	起動した作業ディレクトリ単位。目次は無条件で毎回
モノレポでの分け方	ルート起動のまま、memoryをプロジェクト別ファイルに分割
個別ルール	サブフォルダにCLAUDE.mdを置く
最も確実な手段	スレッドの1行目で対象プロジェクトを宣言する

あとがき

AIの記憶と聞くと、賢く整理してくれる仕組みを想像しがちである。実態は毎回読まれるテキストファイルであり、整理するのは人間の仕事になる。付箋は増やすより剥がすほうが重要であり、揮発する情報は最初から貼らない運用が最も事故を減らす。複数プロジェクトを1つのリポジトリで抱える構成では、起動場所を変えられない前提で、ファイルの分け方と最初の宣言で混線を防ぐことになる。