Auto Dream

Anthropic は公式発表なしに Claude Code へある機能を追加しました。Auto Dream と呼ばれるこの機能は、オートメモリの核心的な弱点、つまりノートが蓄積するにつれて古くなっていく問題に取り組みます。

問題: オートメモリは大きな前進でした。Claude は自身のプロジェクトノートを保持するようになりました。しかし20回以上のセッションを経ると、ノートブックが乱雑になります。エントリが互いに矛盾し始めます。「昨日」のような相対的な日付はもう意味をなしません。古いデバッグのヒントはリファクタリングで削除されたファイルを指したままです。役立つはずのメモリが、Claude を惑わすバックグラウンドノイズになってしまいます。

すぐできること: お使いのインストールで Auto Dream が有効かどうか確認しましょう。Claude Code のセッションを開いて /memory を実行します。セレクターで「Auto-dream: on」を探してください。そのフラグがあれば、Claude はすでにバックグラウンドでセッション間にメモリファイルを整理しています。

# Check your current memory state
/memory
 
# Look for:
# Auto-dream: on

トグルが表示されてオンになっていれば問題ありません。定期的に、Claude はプロジェクトのメモリファイルを走査し、古くなったものを捨て、矛盾を修正し、残りを再整理します。まだトグルがない場合はお読みください。手動でのトリガーも機能します。

なぜ「夢を見る」と呼ぶのか: REM 睡眠との類比

この名前は偶然ではありません。この類比は実際に当てはまります。

脳は一日中生の入力を吸収し、短期記憶として保存します。REM 睡眠はその日の出来事を振り返り、重要なつながりを保持し、不要なものを捨て、残りを長期記憶に整理します。REM が不足すると、永続的な記憶の形成が難しくなります。情報は届いても、統合されることがありません。

オートメモリは Claude の覚醒時の脳の役割を果たします。作業中にメモを取ります: デバッグのパターン、ビルドコマンド、アーキテクチャの決定、あなたの癖。セッションごとにエントリが積み重なります。しかし、クリーンアップパスがなければ、統合されない短期記憶と同じように、それらのノートは乱雑になっていきます。古い矛盾が残ります。古くなったエントリが消えません。シグナルはセッションを経るごとにノイズに溺れていきます。

Auto Dream は REM の役割を果たします。オートメモリが収集したものを確認し、まだ価値のある部分を保持し、期限切れになったものを削除し、残りをきれいなインデックスを持つ整然としたトピックファイルに再形成します。これがなければ、Claude Code は基本的に睡眠なしで動いていることになります。ノートは積み重なり続け、クリーンアップは来ませんでした。

ドリームサイクルの4つのフェーズ

Auto Dream は実行されるたびに4フェーズのルーティンを実行します。各フェーズには固有の役割があり、合わさることで散らかったセッションノートの山を整理されたプロジェクト知識に変換します。

フェーズ1: オリエンテーション

Claude はメモリディレクトリを開き、すでに存在するものをカタログ化します。MEMORY.md（インデックス）を読み、トピックファイルのリストを確認し、現在の状況を把握します。

このフェーズが答える質問: 「私はすでに何を知っていて、どのように整理されているか?」

フェーズ2: シグナルの収集

次に、Auto Dream はセッションの書き起こし（Claude がすべてのセッションについてローカルに保持している JSONL ファイル）を掘り下げます。各ファイルを最初から最後まで読むことは選択肢にありません。数百のセッションがあるプロジェクトでは、トークンと時間の観点から非現実的です。このパスは狭く絞られています。特定のパターンのみを検索します:

• ユーザーの訂正: あなたが Claude の間違いを指摘したり、新しい方向に導いた箇所
• 明示的な保存: 「これを覚えて」や「メモリに保存して」と言った箇所
• 繰り返しのテーマ: 多くのセッションにわたって現れたパターン
• 重要な決定: アーキテクチャの選択、ツールの選択、ワークフローの変更

この狭いパスは意図的なものです。500の書き起こしをすべて読むことは、ほとんど新しいものを得られないのにトークンを浪費します。狭い grep スタイルのクエリが、無駄なく高シグナルな部分を取り出します。

フェーズ3: 統合

これがメインイベントです。Claude は新しい情報を既存のトピックファイルに組み込み、重要なメンテナンスを処理します:

• 相対的な日付が絶対日付に書き換えられます。 「昨日 Redis を使うことにした」は「2026-03-15 に Redis を使うことにした」になります。これにより、記憶が古くなっても時期が混乱しません。
• 矛盾した事実は削除されます。 3週間前に Express から Fastify に切り替えた? 古い「API は Express を使用」エントリは消えます。
• 古い記憶は削除されます。 リファクタリングで削除されたファイルを指しているデバッグノートは無用です。削除されます。
• 重複するエントリは統合されます。 同じビルドコマンドの癖を記録した3つのセッションが、一つのきれいなノートに圧縮されます。

フェーズ4: 整理とインデックス更新

最後のフェーズは MEMORY.md に焦点を当てます。このファイルは200行以内に保たれます。200行が起動時に読み込まれる上限だからです。フェーズ4は MEMORY.md を更新して、トピックファイルの現在の状態を反映させます:

• もはや存在しないトピックファイルへのリンクを削除
• 統合中に作成された新しいトピックファイルへのポインタを追加
• インデックスと実際のファイルの内容の間のギャップをなくす
• 関連性と新しさでエントリを並び替える

統合中に編集が不要だったトピックファイルはそのままにされます。Auto Dream はすべての実行でゼロから書き直すわけではありません。変更は外科的です。

完全なシステムプロンプト

Auto Dream を動かす実際のシステムプロンプトがこちらです。ドリームサイクルが始まるとき、Claude が受け取るものです:

# Dream: Memory Consolidation
 
You are performing a dream - a reflective pass over your memory files.
Synthesize what you've learned recently into durable, well-organized
memories so that future sessions can orient quickly.
 
Memory directory: `~/.claude/projects/<project>/memory/`
This directory already exists - write to it directly with the Write tool
(do not run mkdir or check for its existence).
 
Session transcripts: `~/.claude/projects/<project>/`
(large JSONL files - grep narrowly, don't read whole files)
 
## Phase 1 - Orient
 
- `ls` the memory directory to see what already exists
- Read `MEMORY.md` to understand the current index
- Skim existing topic files so you improve them rather than creating
  duplicates
- If `logs/` or `sessions/` subdirectories exist (assistant-mode layout),
  review recent entries there
 
## Phase 2 - Gather recent signal
 
Look for new information worth persisting. Sources in rough priority order:
 
1. **Daily logs** (`logs/YYYY/MM/YYYY-MM-DD.md`) if present - these are
   the append-only stream
2. **Existing memories that drifted** - facts that contradict something
   you see in the codebase now
3. **Transcript search** - if you need specific context (e.g., "what was
   the error message from yesterday's build failure?"), grep the JSONL
   transcripts for narrow terms:
   `grep -rn "<narrow term>" <project-transcripts>/ --include="*.jsonl"
| tail -50`
 
Don't exhaustively read transcripts. Look only for things you already
suspect matter.
 
## Phase 3 - Consolidate
 
For each thing worth remembering, write or update a memory file at the
top level of the memory directory. Use the memory file format and type
conventions from your system prompt's auto-memory section - it's the
source of truth for what to save, how to structure it, and what NOT
to save.
 
Focus on:
 
- Merging new signal into existing topic files rather than creating
  near-duplicates
- Converting relative dates ("yesterday", "last week") to absolute dates
  so they remain interpretable after time passes
- Deleting contradicted facts - if today's investigation disproves an old
  memory, fix it at the source
 
## Phase 4 - Prune and index
 
Update `MEMORY.md` so it stays under 200 lines. It's an **index**, not a
dump - link to memory files with one-line descriptions. Never write memory
content directly into it.
 
- Remove pointers to memories that are now stale, wrong, or superseded
- Demote verbose entries: keep the gist in the index, move the detail into
  the topic file
- Add pointers to newly important memories
- Resolve contradictions - if two files disagree, fix the wrong one
 
---
 
Return a brief summary of what you consolidated, updated, or pruned. If
nothing changed (memories are already tight), say so.

このプロンプトからいくつかの詳細を指摘する価値があります。Claude に対して、狭く grep し、書き起こしの全文読み取りを避けるよう明示的に指示しています。MEMORY.md を200行の上限に保ちます。そして、矛盾を単に指摘するのではなく、ソースファイルで修正するよう Claude に指示します。このプロンプトはメモリがどのように見えるべきかについて強い意見を持っており、出力が一貫して整然としている理由がここにあります。

ドリームサイクルが開始するタイミング

統合が実行されるには、同時に2つの条件を満たす必要があります:

1. 前回の統合から 24時間以上が経過している
2. 前回の統合から 5セッション以上が経過している

両方のゲートが必要です。2日間にわたる一つのマラソンセッションでは Auto Dream は起動しません（セッション数が少なすぎます）。2時間以内の10の高速セッションでも起動しません（十分な時間が経過していません）。ダブルゲートにより、静かなプロジェクトでは無用なクリーンアップの実行を防ぎ、アクティブなプロジェクトは整然と保たれます。

規模感として: ある観察された実行では、Auto Dream は913セッション分のメモリを約8〜9分で処理しました。無料ではありませんが、バックグラウンドで動作するため、そのコストを感じることはありません。

安全性の保証

Auto Dream は本物のガードレールの中で動作します。事故は起こりにくい構造です。

プロジェクトのコードは読み取り専用です。 ドリームサイクル中、Claude はメモリファイルにのみ書き込めます。ソースコード、設定、テスト、その他のプロジェクトファイルは制限されています。ドリームプロセスはメモリディレクトリ内に封じ込められています。

ロックファイルが重複を防ぎます。 同じプロジェクトで2つの Claude Code インスタンスを開いている場合でも、Auto Dream を実行できるのは一度に一つだけです。ロックファイルにより、2つの統合実行が競合することを防ぎます。これがなければメモリファイルにマージコンフリクトが発生します。

バックグラウンドで実行されます。 Auto Dream はセッションをブロックしたり、待機させたりしません。Claude Code で作業を続けながら、バックグラウンドで統合が行われます。

手動でのドリームのトリガー

自動トリガーを待つことは必須ではありません。メモリのクリーンアップが必要だとわかっている場合（大きなリファクタリングの直後など）、統合を自分で強制できます。

/dream コマンドは存在しますが、まだすべてのアカウントには届いていません。それを待つ間は、Claude に望むことを伝えるだけです:

"dream"
"auto dream"
"consolidate my memory files"

Claude は意図を理解し、同じ4フェーズのフローを実行します。プロジェクトに大きな変更があった後、新鮮なメモリが重要で次の自動サイクルを待つのが遅すぎる場合に役立ちます。

実際の統合: 前後の比較

ドリームサイクルの前後で、典型的なメモリディレクトリがどのように見えるかを示します。

統合前（30以上のセッションの蓄積、散漫な状態）

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 280 lines, over the 200-line limit
├── debugging.md           # Contains 3 contradictory entries about API errors
├── api-conventions.md     # References Express (switched to Fastify 2 weeks ago)
├── random-notes.md        # Mix of stale and current info
├── build-commands.md      # "Yesterday" used 6 times with no dates
└── user-preferences.md    # Duplicates entries from MEMORY.md

統合後（整理された状態）

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 142 lines, clean index with links to topic files
├── debugging.md           # Deduplicated, only current solutions
├── api-conventions.md     # Updated to reflect Fastify migration
├── build-commands.md      # All dates absolute, no duplicates
└── user-preferences.md    # Merged with relevant MEMORY.md entries

random-notes.md ファイルは消えています。その内容は関連するトピックファイルに組み込まれるか、古くなったとして削除されました。MEMORY.md は280行から142行に縮小し、起動時の読み込み閾値である200行を下回りました。矛盾は解消されました。日付は絶対的なものになりました。

オートメモリ vs Auto Dream: 一つのシステムの2つのレイヤー

これら2つの機能は互いに対立するのではなく、連携して動作します。一つのメモリセットアップの収集レイヤーとメンテナンスレイヤーとして捉えてください。

後からクリーンアップするものが何もないオートメモリは、ノートブックを振り返らないメモ取り担当者のようなものです。逆もしかりです: 新しいノートを書くものがなければ、ドリームサイクルには処理するものがありません。両方が動作することが望ましいです。

4つのメモリシステム: 全体像

この新しいレイヤーにより、Claude Code には4つの異なるメモリメカニズムがあります。オートメモリの詳細で紹介したテーブルをベースに、完全なセットがどのように組み合わさるかを示します:

最強のセットアップは4つすべてを実行します。CLAUDE.md があなたが所有・管理するルールを保持します。オートメモリは Claude が仕事中に拾い上げたものを記録します。セッションメモリは再起動をまたいで会話スレッドを引き継ぎます。そしてドリームサイクルにより、蓄積された知識が常に最新で、正確で、整理された状態に保たれます。

実践的なヒント

ほとんどのプロジェクトは自動化に任せる。 デフォルトのゲート（24時間 + 5セッション）はアクティブな開発に適しています。監視は不要です。

大きなリファクタリングの直後にドリームを強制する。 コードベースの半分の名前を変更しましたか? フレームワークを交換しましたか? API を再構築しましたか? 手動サイクルをトリガーしましょう。古いエントリは、次の自動サイクルで調整されるまで、役立つよりも混乱を招きます。

時々出力を確認する。 ドリームサイクルが完了したら、MEMORY.md をざっと見てください。Auto Dream は優秀ですが、完璧ではありません。統合の選択があなたの意図に合わない場合もあります。ファイルはプレーンなマークダウンです。好きなように編集してください。

良いコンテキスト衛生と組み合わせる。 ドリームサイクルはメモリファイルをクリーンに保ちますが、アクティブなセッションコンテキストは依然としてあなたが管理するものです。ファイルがきれいであれば、Claude は起動時に読み込むガベージが少なくなり、コンテキストウィンドウに実際の作業のための余地が増えます。

次のステップ

• まだ CLAUDE.md を設定していない場合は先に設定しましょう。ドリームサイクルはオートメモリを統合しますが、CLAUDE.md は依然として最高優先度の信頼できる情報源です。
• オートメモリを読んで、セッション中に Claude が何を記録しているかを正確に理解しましょう。それが Auto Dream が処理する生の素材です。
• セッションメモリでワークセッション間の会話レベルの継続性を確認しましょう。
• コンテキストエンジニアリングで、これらすべてのメモリシステムが意図的なコンテキスト戦略にどのように積み上がるかを確認しましょう。
• Auto Dream があなたのプランティアに展開される時期など、メモリシステムのアップデートについては Claude Code のチェンジログを確認しましょう。
• Claude Code が初めての方は、メモリ設定に触れる前に、macOS、Windows、または Linux でのセットアップのためのインストールガイドに従ってください。

Auto Dream は、Claude のメモリを増え続けるノートの山から、生きた維持管理されたナレッジベースに変えるピースです。オートメモリが生の素材を収集します。Auto Dream はそれを Claude が実際に使えるものに形成します。最終的な効果は、時間とともにより多くを覚えるだけでなく、より良く覚える Claude です。