前回の記事は「CLAUDE.md には不変量だけを書く」と論じた。では memory は？このプロジェクトで実際に動いている 5 件の memory をすべて開いて、1 件ずつ点検した——残すもの、捨てるもの、CLAUDE.md と memory の境界線はどこにあるのか。
前回の記事では「CLAUDE.md に書くのは Claude がコードから読み取れないものだけだ」と論じた。ある読者がすぐに尋ねた——では memory は？memory も文脈なのに、CLAUDE.md と何が違うのか？
多くの人は使っているうちに memory を CLAUDE.md の「バックアップ拡張」のように扱い始める——思いついたことを次々と放り込んでいく。時間が経つと memory は肥大化し、Claude は毎セッションそれを読み込み、古くなった情報に基づいて判断を下すことになる。
この記事では抽象的な定義は扱わない。このプロジェクトで現在稼働している 5 件の memory をすべて開き、1 件ずつ点検する——残すべきもの、削除すべきもの、そもそも書くべきでなかったもの。過程のなかで、CLAUDE.md と memory の違いは自ずと見えてくる。
本当に役立つ問いは「どこに置くか」ではなく「この情報はどれだけ長く生きるか、誰が更新するか」だ。
feedback_commits — 私が「commit」と言うまで commit しない
feedback_article_authenticity — 実戦記事は捏造してはいけない
project_i18n_strategy — 全言語同時リリースという戦略判断
project_howdev_plan — how2claude.dev の未完了の実装計画
project_article_workflow — 記事公開のパイプライン
タイプ別に見ていく。
本文は短い："don't auto-commit, wait for user to confirm."
これは memory のなかでも最も ROI が高いタイプだ。一度の訂正 → 以降のセッションすべてで永続的に有効。
なぜ CLAUDE.md に入れないのか？ プロジェクトルールではなく、私個人の仕事習慣だから。別の貢献者がプロジェクトに加わっても、同じルールを守る必要があるとは限らない。CLAUDE.md はチームレベル、memory は「私と Claude のあいだ」のものだ。
なぜ会話のたびに言い直さないのか？ セッションをまたいで保持されるから。来週 Claude がコードを手伝うときにもまだ覚えている。
トリガーは明確だ：一度訂正した。その訂正を恒久的に残したい。
この memory の本文は異例に具体的だ：
2026-04-16、multi-agent シリーズ最終回を書いていたとき、「3 つの Agent で webhook 機能を作る」というストーリーを想像で作り上げた……全部でっち上げだった。ユーザーから「本物なのか作り話なのか」と問われた——これは先行する 2 本（方法論記事）とは別の水準の話だ……
ポイント：Why 欄は抽象的な原則ではない——具体的な出来事 + 日付 + そのとき何が起きたかだ。
なぜこう書くのか？6 か月後、「実戦記事は本物の素材が必要」という抽象ルールだけを見ると自分でも分からなくなる——いつ 決めたのか、なぜ 決めたのか？でも「4-16、agent のストーリーをでっち上げて見抜かれた」と書いてあれば即座に思い出せる。そしてそのルールがまだ有効かどうかも、その場で判断できる。
これは私の 5 件のなかで最も「重い」一件だ。単なるルールではなく、Claude と私の両方が参照できる事故記録でもある。
内容：このプロジェクトがなぜ全言語を一気にリリースしたか——翻訳コストが Claude 経由でほぼゼロ、公式ドキュメントが英語だけなのが中核の機会窓口、という判断。
コードからは読み取れない。コードには 19 個のロケールファイルがあるだけ。なぜ 19 個、なぜ同時、なぜ日本語と韓国語の優先度が高いか——すべて私の頭のなかにある。
memory はその「頭のなかの判断」を定着させ、Claude が後で機能を提案するとき「この提案は i18n 戦略と矛盾していないか」と判断できるようにする。
運用ルールではない（CLAUDE.md には入れない）、戦略背景である（memory に入れる）。
いちばん一時的なもの：how2claude.dev 開発者向けサイトのための 9 ファイルにわたる実装計画、末尾に「次のセッションで続ける」と書いてある。
最も危険なタイプ——容易に ゾンビ memory になる。実装が終わっても削除を忘れると、次回 Claude はまだ有効だと思い込み、古い計画に基づいて「step 3 がまだですね」と助言してくる。
このタイプの memory には明確な 退場メカニズム が必要だ：how2claude.dev がリリースされた瞬間、手動で削除しなければならない。
情報密度が最も高い一件で、当初は最も役立つと思っていた——注意深く読むまでは：
/write-article と /publish-article の存在 → .claude/commands/ を見れば分かるdocs/drafts/ を見れば一目瞭然.claude/publish-config.json に書いてあるClaude はコードを読めばすべて導出できる。
memory が実際に提供している唯一の情報は最終ブロックだ："Accounts (production): zh → @how2claude, en → @howtoclaude"——そしてこれは 既に古くなっている。前回のセッションで本番は実際には zh=@howtoclaude だと判明した。memory は数日前のスナップショットを記録しているだけで、もう現実からずれている。
結論：この memory は 90% 削除すべきだ。残す価値のある部分（「kamal でリアルタイムのアカウントを照会する」）は CLAUDE.md に入れるほうが適切だ——あるいはいっそ書かない。memory にハードコードされたアカウントはいずれまた古くなる。
1. memory の本当の役割は、Claude が入れない部屋を開けること。
2. Claude がコードから読み取れるものは memory に入れない。
前回の CLAUDE.md 記事と同じ原則。ファイルパス、API URL、ディレクトリ構造——すべてコードが答えられる問い。一度 grep するのが面倒だからと memory に放り込むのは、その情報が永遠に変わらないほうに賭けているのと同じだ。
3. memory は劣化する。
project_article_workflow がその証拠だ——数日前に書いたのに、アカウント情報はもう間違っている。古い memory ほど信頼できない。定期的に audit する > 無制限に増やす。
4. Why 欄があなたを救う。
私の 2 件の feedback を比べるとわかる：
feedback_article_authenticity の Why：「4-16、multi-agent 記事で話を作った」→ 6 か月後にも即座に有効かどうか判断できる。feedback_commits の Why：「user wants to review」のみ → 6 か月後、どの訂正から生まれたか私自身わからない。後者はずっと弱い。抽象的な原則は生き残らない——なぜ課されたか誰も覚えていない。
新しい情報が出てきたら、3 つの問いを立てる：
3 つ目が罠だ。書き留めたくなる「変わらない」情報の多くは実はコードから導出できる——ただ Claude にもう一度 grep させるのが面倒なだけだ。
一通り見ていくつか気づいた：
project_article_workflow の 90% はコードから導出できる。この一件が最も手を入れるべきだproject_howdev_plan は一時的な引き継ぎ——理論上、退場メカニズムが必要project_i18n_strategy は戦略判断——数か月後に見直す価値があるfeedback_commits の Why は弱い。具体的な出来事を付け足すほうが堅牢になるついでの観察：私の type 分布は feedback×2 + project×3、user や reference タイプはゼロだ。つまりまだ Claude に「私が誰か」「どの外部システムから状態を読むか」を伝えていない。おそらく次のバッチで書くべきもの。
memory の最大の罠は「書くべきなのに書かなかったもの」ではない。「書いたけれど古くなったもの」だ。5 件のうち 1 件がずれるだけで十分——Claude は静かに古い情報を使って判断を下し、そのずれを知らせてくれない。
私の 5 件のなかには、すでに手を入れたいところが見えている。あなたのほうはどうだろう？