Claudeが眠るようになった——Auto-Dreamと自作メモリ、同じ部屋に住めるか

先週、/memory を開いたら見慣れない項目があった。

「Auto-dream: off」。

どこかで聞いた話をすると、これは Claude Code 2.1.83 で追加された機能です。眠れるようになった、というより「眠ることで記憶を整理する仕組みが入った」という方が正確です。

ただ、私はこのプロジェクトで独自の2層メモリシステムをすでに運用していました。MEMORY.md（常時ロード）と LONG_MEMORY.md（オンデマンド参照）の組み合わせです。

「Auto-Dream と自作メモリ、どっちが上位互換か？」「そもそも衝突しないのか？」。気になったら試す。20年その繰り返しです。

この記事の結論（TL;DR）

• Auto-Dream（/dream）の保存先は自作 memory/ ディレクトリと完全に同じ場所
• LONG_MEMORY.md（lmemory Layer 2）は frontmatter がないため Auto-Dream の射程外
• /dream は Bash から実行不可。Claude Code セッション内の対話型コマンド
• 自作 2層メモリと Auto-Dream は役割分担で共存できる

• 2.1.80〜2.1.84、5バージョンで何が変わったか
• Auto-Dream とは何か
  • /dream が行う4フェーズ
• 問題：うちのメモリファイルはどこにある？
• /dream を叩いてみた——そして壁に当たった
• 自作 lmemory との住み分け：衝突するか？
• 2.1.83 の本当の意義
• よくある質問（FAQ）
• まとめ
• この記事を書いた人
• 関連記事

2026年3月19日から26日のわずか1週間で5つのバージョンが出ています。個人的に刺さった変更点を表にしました。

--bare フラグは地味ですが、CI/CD やシェルスクリプトから Claude を呼び出す用途で相当使えます。hook も plugin もスキップして純粋に API として動かせる。

MCP の2KBキャップも私は歓迎しています。ツール説明が長くなりすぎてコンテキストを食いつぶす問題は前から気になっていたので。

UI に「Auto-dream: off」が出現したとき、正直「また新機能か」と思いました。でも少し調べると、これは真剣に設計されているものだとわかります。

理論的な根拠は UC Berkeley と Letta の共同研究（2025年4月）です。論文タイトルは "Sleep-time Compute"。人間が REM 睡眠中に記憶を整理・定着させる仕組みをモデル化したもので、アイドル時間に事前計算を行うことでテスト時の計算量を5分の1に削減、精度は最大18%向上したと報告されています。

/dream が行う4フェーズ

手動で /dream を叩くと、メモリファイルに対して以下の処理が走ります。

1. Pruning — 冗長・古くなったエントリを削除
2. Merging — 関連情報を統合・重複を排除
3. Refreshing — 現在のプロジェクト状態を反映して内容を更新
4. Index更新 — MEMORY.md のインデックス行を再生成

自動発火の条件は「前回実行から24時間以上経過 かつ 5セッション以上完了」。手動実行は /dream コマンドで任意タイミングに行えます。

ただし現状、/memory メニューの「Auto-dream: off」トグルはオンにできません。実験的フィーチャーとして実装されており、標準リリースではまだ有効化できない状態です。

ここが今回一番驚いた発見でした。

Auto-Dream が操作するディレクトリのパスは：

~/.claude/projects/<project-slug>/memory/

私がこのプロジェクトで使っているメモリファイルのパスは：

~/.claude/projects/-home-username-Project-your-project/memory/

完全に同じ場所です。

Claude Code の Auto-Memory システム（毎セッション自動ロードされる MEMORY.md と各トピックファイル）と、私が手動で育ててきたファイル群が、同じディレクトリに共存しています。つまり /dream を実行すると、project_team.md も feedback_comfyui_force_cache.md も整理・削除・統合の対象になり得る。

これが衝突するのか、共存できるのかを確認しなければなりませんでした。

「試してから語る」が行動原理なので、Bash から /dream を実行しようとしました。

結果：実行できません。

/dream は Claude Code CLI の対話型スラッシュコマンドです。/clear や /compact と同じカテゴリで、外部スクリプトや Bash シェルから呼び出せる設計ではない。

これはある意味正しい設計だとも思います。メモリの整理は「現在のセッションコンテキストを把握した上で実行する」べきもので、盲目的に外部から起動されるべきではない。ただ CI に組み込もうとしている人は注意が必要です。

実行するには Claude Code セッションの中で直接 /dream と打つしかない。それだけです。

このプロジェクトでは2層のメモリ構造を使っています。

Layer 1（常時ロード）: MEMORY.md + memory/*.md
  ↑ type: user/feedback/project/reference の4分類
  ↑ Claude が自動判断して書き込む

Layer 2（オンデマンド）: LONG_MEMORY.md
  ↑ /lmemory スキル経由でのみアクセス
  ↑ T/P/D のID体系（Task/Plan/Decision）

結論から言うと、Layer 2（LONG_MEMORY.md）は Auto-Dream の射程外です。

Auto-Dream が整理対象にするのは、YAML frontmatter（type: feedback など）を持つファイルです。LONG_MEMORY.md は独自の ## T01: ## P02: 形式で書かれており、frontmatter を持たない。Claude Code の分類体系に当てはまらないため、自動統合の対象になりにくい構造になっています。

Layer 1 については話が別です。project_team.md や feedback_comfyui_force_cache.md は正しく frontmatter を持っているので、/dream が実行されれば統合・更新される可能性があります。これは 歓迎すべきことです。私が手動でやっていた「古くなったフィードバックエントリの整理」を自動でやってくれる存在が現れた、と考えればいい。

⚠️ 一点だけ注意: Auto-Dream が将来バージョンで「frontmatterのないmdファイルも統合対象にする」仕様変更が入った場合、LONG_MEMORY.md が意図せず整理されるリスクがあります。/dream 実行後は LONG_MEMORY.md の内容を確認することを習慣にしておく価値はあります。

今回のアップデートで私が一番評価しているのは Auto-Dream そのものではなく、その周辺に加わった CwdChanged/FileChanged hookイベントです。

これまで Claude Code の hook は「ツール実行前後」のイベントしか捕まえられなかった。ファイルが変わったら自動でテストを走らせる、作業ディレクトリが変わったら環境を切り替える——こういう「環境の変化に反応する」処理が書けるようになった。

まだ自分のプロジェクトに組み込んでいませんが、FileChanged で特定ファイルの変更を検知して型チェックを自動実行する、くらいのことは近いうちにやってみようと思っています。

Auto-Dream については、Auto-dream トグルが一般ユーザーに開放されるまでは /dream を定期的に手動実行する運用で様子を見ます。月1回、長いプロジェクトの区切りに叩くくらいが今の自分には合いそうです。

Q. /dream はどのくらいの頻度で実行すべきですか？

A. 自動発火の条件は「24時間以上経過 かつ 5セッション以上完了」ですが、現状この自動発火はオフのままです。手動実行の目安は、長いプロジェクトの区切り（スプリント終了・リリース後）や、MEMORY.md の記述が増えすぎたと感じたタイミングが良いと思います。私は月1回を目安にしています。

Q. LONG_MEMORY.md は /dream で消えませんか？

A. 現状の仕様では、Auto-Dream は YAML frontmatter を持つファイルを対象にしています。LONG_MEMORY.md は独自の ## T01: / ## P02: 形式（frontmatter なし）で書かれているため、自動統合の対象になりにくい構造です。ただし将来の仕様変更に備えて、/dream 実行後に内容が変化していないか確認することを推奨します。

Q. Auto-Dream と CLAUDE.md の auto-memory システムは別物ですか？

A. 同じ仕組みの上に乗っています。auto-memory（毎セッション自動ロードされる MEMORY.md と各 *.md ファイル）と、Auto-Dream（それらを整理・統合する機能）はセットで設計されています。/dream は「auto-memory の中身を定期的に掃除する係」と考えると理解しやすいです。

Claude Code 2.1.80〜2.1.84 の変更で、個人的に重要と感じたのは3つです。

• Auto-Dream（/dream） — メモリ整理の概念が変わった。自動発火はまだ無効だが、手動実行は今すぐ使える
• CwdChanged/FileChanged hook — hookが「反応型」になった。環境変化への自動対応が書けるようになった
• MCP ツール説明 2KBキャップ — 地味だが確実にコンテキスト汚染を抑制する

自作の2層メモリシステムは死なず、役割分担が生まれた形です。Layer 1 の整理は Auto-Dream に任せ、Layer 2 の構造化タスク管理は引き続き /lmemory スキルで動かす。1週間前には予定していなかった組み合わせが自然にできあがりました。

Auto-Dream が論文ベースで設計されていること、そしてその保存先が既存の memory/ ディレクトリと完全に同一であること。Claude Code は気づかないうちにこちらの設計に寄り添っていた、とも言える。

このスピードに寄り添われながら、追いかけていく。それが今の状況です。

関連記事

• Blog45%高速化・メモリ150MB削減——Claude Code の--resume が変わったClaude Code v2.1.77と2.1.78の変更点を整理。128kトークン出力・--resume 45%高速化・セキュリティ修正2件など、実際に体感できる変更を中心に解説。→
• Blog200Kが1Mになった3日間、Claude Code 2.1.74〜76で起きたことClaude Code v2.1.74〜76の3日間で何が変わったか。メモリリーク修正・セキュリティパッチ、Opusコンテキスト200K→1M（同一料金）、MCP Elicitation追加まで実運用視点でまとめ。→

この記事の技術的なダイジェスト版を Zenn にも投稿しました。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→
• BlogClaude Fable 5 vs Sonnet 5：料金5倍・知能+7点の実測使い分けガイドFable 5とSonnet 5をArtificial Analysisの知能指数・タスク単価・出力量で比較。料金5倍の差を実務の判断材料に落とし込みます。→
• Blog失敗から学ぶClaude Code Sonnet 4.6 1M context：$15と$5の分岐点Claude Code MAXプランで1M contextが突然使えなくなった原因を実機で調査。extra usageの正体と、最小コストで戻す判断材料を整理します。→