はじめに
「また同じこと説明した」と思ったことはないだろうか。
プロジェクトのコーディング規約、先週のコードレビューで決めた命名ルール、「このパターンは以前やって失敗した」という経緯——Claude Codeは毎回のセッション開始時にそれを全部忘れる。CLAUDE.mdを丁寧に書いても、それは静的なルールを渡しているだけで、Claudeが「今日の自分たち」を覚えているわけではない。
この記事では、Claude CodeのAuto Memory・MEMORY.md・そして次期機能のautoDreamという3層のメモリ設計について、実践事例とともに整理する。1人で使っている人にも、チームで運用している人にも、同じ問題の解決策になるはずだ。
毎朝10人のAIに同じ説明をしていた
作曲家・1人経営者のkimny氏は、Claude Codeで10のAIエージェント（conductor、writer、researcher等）を同時に運用していた。ところがセッションが終わるたびに全員がリセットされる。翌朝の最初の仕事は「昨日の進捗」「このプロジェクトのルール」「前回の指摘事項」を10人のAIに一から説明することだった。
解決策はAuto Memoryの体系的な設計だった。4タイプ274個のメモリファイルを整理した結果、翌朝の状況説明が不要になった。特に効果が高かったのがfeedbackタイプで、修正履歴を記録した後は同じミスが一度も再発しなくなったという（出典: Zenn "Claude Codeに記憶を持たせたら〜 auto memory設計パターン" by kimny氏）。
月間コストはClaude Max $200（¥37,800）+ Gemini ¥2,610 = ¥40,410。「アシスタント1人雇用の約1/5」という試算に、この体制の現実味がある。
なぜClaude Codeは「記憶できない」のか
Claude Codeのメモリには現在2層ある。
CLAUDE.mdは「静的な指示層」だ。テストコマンド、命名規則、セキュリティ境界などチーム全員が守るルールを書く場所で、gitで管理される。一方、Auto Memory / MEMORY.mdは「動的な学習層」で、Claudeが自律的に好み・進捗・フィードバックを記録し、次のセッション以降に引き継ぐ。そして将来的にはautoDreamという「整理層」が加わる予定だ。
問題は多くのユーザーがCLAUDE.mdだけを使い、Auto Memoryの存在に気づいていないことにある。CLAUDE.mdに「現在の進捗」「個人の作業スタイルの好み」を書き込もうとして、なぜかうまく機能しないと感じた経験があれば、それは書く場所が違ったということだ。
Auto Memory──Claudeが自ら書く「学習ノート」
Auto MemoryはClaude Codeの現行バージョンに標準搭載されている（コミュニティ報告ではv2.1.59以降とされているが、公式ドキュメントに明記はない。`claude --version`で手元のバージョンを確認しよう）。Claudeが自律的にメモリを記録し、セッション開始時に自動でロードする。
4つのメモリタイプと優先順位
kimny氏の274ファイルを分析すると、4タイプに分類される。
#### feedbackタイプ（94個・34%）
修正履歴から学習する。「Zenn記事はですます調」と記録した後、再発ゼロになった例が典型的だ。
#### projectタイプ（152個・55%）
現在の進捗・設計決定を記録する。「今週どこまで実装したか」がここに入る。
#### referenceタイプ（21個・8%）
GrafanaダッシュボードURLなど外部リソースの参照先。
#### userタイプ（4個・1%）
応答スタイルのパーソナライズ用。
最初に整備すべきはfeedbackタイプだ。「何度も同じ指摘をしている」という繰り返しを一番速く止められる。
MEMORY.mdは「インデックスファイル」として設計する
MEMORY.mdにはセッション開始時に先頭200行または25KBまでしかロードされない（公式確認済み）。ここに詳細を書き込もうとすると、すぐに溢れる。
正しい設計は「インデックスとして使い、詳細は個別ファイルに分離する」ことだ。
# MEMORY.md（インデックス設計の例）
- [命名規則フィードバック](feedback_naming.md) — camelCase強制、prefix不要
- [認証実装パターン](project_auth.md) — JWT + refresh token設計決定
- [Grafanaダッシュボード](reference_dashboards.md) — APIレイテンシ監視URL
各メモリファイルには「なぜ」を書くと効果が上がる。「インラインコメントは理由を書く」という指示だけより、「なぜなら：コードを読めば何をやっているかは分かる。なぜやるかだけが伝わらない」と書いた方が、エッジケースでの判断精度が格段に違う。
保存してはいけない情報
コードから復元できる情報、gitログで追跡できる変更履歴、APIキーや機密情報はメモリに入れない。CLAUDE.mdと内容が重複すると「どちらが正しいか」という競合が起きる。役割の線引きは最初から決めておきたい。
autoDream──「AIの睡眠」で自動整理する（次期機能）
autoDreamはAnthropicのソースコードリーク（Deep Learning AI / The Batch 2026年報告）で発覚した機能だ。公式ドキュメントには未記載で、現在はserver-sideのfeature flag（`tengu_onyx_plover`）で制御されており、公開ビルドではデフォルト無効になっている。一部ユーザーが段階的ロールアウト中の`/dream`コマンドを使えると報告しているが、信頼度は「個人報告」レベルで、一般公開時期は未定だ。
仕組みは人間の睡眠中の記憶整理（memory consolidation）に着想を得ている。古い・重複・不要な情報のプルーニング、同トピックの情報マージ、「先週」「昨日」などの相対日付の絶対日付への変換、そしてMEMORY.mdの200行以内への圧縮を自動で行う。340行のMEMORY.mdが152行に圧縮されたという個人報告も出ている（公式データではない）。
現時点でできる手動代替手段として、`autoMemoryEnabled`設定でメモリのオン/オフを切り替えることと、`/memory`コマンドでメモリファイルを直接閲覧・編集・削除することがある。肥大化が気になりはじめたら、定期的に手動で整理するのが今できる最善策だ。
今日からの設定ガイド
`claude --version`で最新バージョンであることを確認するのがスタート地点だ。古いバージョンではAuto Memory自体が使えない場合がある。
確認できたら、`/memory`コマンドで現状を覗いてみてほしい。何も記録されていないか、逆にファイルが溜まりすぎているか。どちらにせよ、想像と違う状態で驚くと思う。
記録を始めるなら、これまで繰り返し伝えてきた指摘からだ。「コメントは日本語で書いてほしい」「このプロジェクトではESLintをpre-commitで走らせる」、そういった内容を「feedback」タイプとしてClaudeに伝えて記録させる。「次から覚えておいてほしいんだけど、これをfeedbackメモリとして保存して」という一文で十分だ。
チームで使う場合は`.gitignore`に`~/.claude/`以下のメモリディレクトリを追加するのを忘れない。Auto Memoryはマシンローカルで動作するため、チームメンバーの個人的な好みがリポジトリに混入しないようにする必要がある。
まとめ
CLAUDE.mdは「チームの規約書」で、Auto Memoryは「自分とClaudeの間で育てていく学習ノート」だ。この2つを別物として使い分けることが、セッション間で学習し続けるClaude Codeを作る出発点になる。
毎朝同じ説明をしている人は、今日のセッションで一度試してみてほしい。繰り返し伝えてきた指摘を一つfeedbackメモリに記録させるだけで、翌日のセッションが変わり始める。
コメント