Claudeに「いい夢見てね」を言う日がくるかもしれない

はじめに

Claude Codeで /memory を開くと、見慣れない項目がある。

Auto-dream: off · never

ONにはできない。何者なのか。 Twitter（X）での発見をきっかけにソースコードと関連論文を調べたところ、設計思想と実装の方向性が見えてきました。

この記事ではAuto-dreamの仕組みを技術的に読み解き、背景にあるSleep-time Compute論文との接点を整理します。

Auto-dreamとは何か

発見の経緯

Twitterでこんな投稿が流れてきました。

“just found out Claude Code has a new (unreleased?) feature called ‘Auto-dream’ under /memory — according to reddit, this basically runs a subagent periodically to consolidate Claude’s memory files for better long-term storage”

手元のClaude Codeで /memory を開くと、確かにある。

Memory

    Auto-memory: on
    Auto-dream: off · never

  > 1. User memory          Saved in ~/.claude/CLAUDE.md
    2. Project memory        Checked in at ./CLAUDE.md
    3. Open auto-memory folder

UIには表示されているものの、ユーザー側からONにはできません。

手元のClaude Codeで調べてみた

気になったので、Claude Codeに「これ何？」と聞いて一緒にソースを調べてもらいました。

Auto-dreamはサーバーサイドのフィーチャーフラグ（コードネーム: tengu_onyx_plover）で制御されています。settings.json で単純にONにできる設定ではなく、Anthropic側でロールアウトを管理している仕組みです。

デフォルト値は以下の通り。

enabled: false
minHours: 24（最低24時間間隔）
minSessions: 5（最低5セッション蓄積後）

UIに表示はされているが、まだ一般ユーザーには開放されていない段階。Anthropicが段階的にロールアウトしている最中と思われます。

デフォルト値から読み取れる設計思想

この3つのパラメータだけで、設計意図がかなり読み取れます。

パラメータ	値	意味
`enabled`	`false`	サーバー側フラグ。ユーザーが `settings.json` で変えても無効
`minHours`	`24`	前回の実行から最低24時間空ける。1日1回以下
`minSessions`	`5`	5セッション分の蓄積がないと実行しない

少量のメモリを頻繁に整理しても意味がない。ある程度溜まってから、1日1回まとめて整理する。人間の睡眠中の記憶定着に近いコンセプトですね。

なぜAuto-dreamが必要なのか

現状のAuto-memoryには構造的な問題があります。

書きっぱなし問題

Auto-memoryは会話中に学んだことをメモリファイルに書き込みます。ただし、整理する仕組みがない。

一時的な作業メモも本質的な学びも同列に保存される
似た内容が何度も重複して書かれる
解決済みの問題や、もう使わない技術スタックの記述が残り続ける
MEMORY.md は200行で切れるのに、整理されないまま枠が埋まっていく

セッションが増えるほどメモリの質が下がる。私のClaudeCodeの設定もこの問題でAuto-memoryをOFFにしています。それはメモらなくても良いんだよね、というのをメモリに記録してしまうのが散見されたので。

Auto-dreamはペア機能

Auto-memoryとAuto-dreamは、最初からペアで設計されていたと考えるのが自然です。

Auto-memory: 書き込みフェーズ。会話中にどんどんメモする
Auto-dream: 整理フェーズ。溜まったメモを統合・淘汰する

片方だけが先にリリースされたため、今は「メモは取るがノートは整理しない」という中途半端な状態になってるのかも？と思います。

Sleep-time Compute論文との接点

Auto-dreamの設計思想には、2025年4月に公開された論文が理論的な裏付けを与えています。

論文概要

Sleep-time Compute: Beyond Inference Scaling at Test-time Kevin Lin, Charlie Snell ら（Letta + UC Berkeley）

arxiv.org Sleep-time Compute: Beyond Inference Scaling at Test-time

コアアイデア

従来のLLMは「質問が来てから考える」（test-time compute）。この論文は**「質問が来る前に、コンテキストから予測して事前に考えておく」**（sleep-time compute）を提案しています。

Sleep-time: コンテキスト c だけを使い、ユーザーが聞きそうなことを予測して推論させる。再構成されたコンテキスト c' を生成する
Test-time: クエリ q が来たら、事前に生成した c' を使って高速に回答する

数式で表すと以下の通りです。

S(c) \rightarrow c'

T_b(q, c') \rightarrow a \quad (b \ll B)

事前処理を済ませておけば、テスト時の計算バジェット $b$ を従来の $B$ に比べて大幅に小さくできます。

実験結果

指標	効果
テスト時の計算量	同精度で約5倍削減
精度向上	最大+13%（GSM-Symbolic）、+18%（AIME）
複数クエリ時のコスト	2.5倍削減（償却効果）

クエリの予測可能性

論文で特に示唆的なのは、クエリの予測可能性が高いほどsleep-time computeの効果が大きいという発見です。

Auto-dreamに当てはめると、ユーザーの作業パターンが蓄積されるほどメモリ整理の精度が上がる。minSessions: 5 という閾値は、予測に必要な最低限のデータ量を確保するための設計と解釈できます。

論文著者の背景

この論文の著者陣は、2つの文脈が交差しています。

Letta（旧MemGPT）: 2023年にLLMにOS的なメモリ管理を持たせるMemGPT論文を発表したチーム
Charlie Snell: UC Berkeleyでtest-time compute scalingの先駆的研究を行った研究者

メモリ管理のプロと計算スケーリングのプロが合流して、寝てる間にメモリを整理するという研究が生まれました。GPT系モデルの研究に携わっていたメンバーもおり、OpenAIのo1/o3路線とは異なるアプローチを小さいチームで追求した形とも読めます。本当にAnthropicのメンバーがOpenAIから離脱したメンバーがやっている、という関係性を知っている故にちょっと苦笑いが出た。

Auto-dreamとSleep-time Computeの対応関係

論文の理論とAuto-dreamの実装を並べると、対応がきれいに見えます。

Sleep-time Compute（論文）	Auto-dream（Claude Code）
ユーザーのクエリを予測して事前計算	過去のメモリを統合・整理
テスト時の計算を5倍削減	セッション開始時のコンテキスト読み込みを効率化
オフライン（sleep-time）に処理	`minHours: 24` で1日1回、非同期で実行
複数クエリで償却	`minSessions: 5` で5セッション分を一括整理

ただし論文はあらゆるコンテキストに対する事前推論を扱っているのに対し、Auto-dreamはスコープをメモリファイルの整理に限定しています。理論のフル適用ではなく、最も実用性が高い部分だけを切り出した実装です。これ本当に上手いと思う。スコープ整理が良い、これ以上手を広げると大変な苦労がもう見えている、だから切り分けて、限定している。

「寝る」をどう実装するか

論文の前提

論文ではsleep-timeを「ユーザーがクエリを投げていないアイドル時間」と定義しています。LLMが寝ているのではなく、ユーザーが使っていない間にLLMが裏で働く。逆ですね。

Claude Codeの場合

Claude CodeはCLIツールです。常駐プロセスではないため、ユーザーが寝てる間にバックグラウンドで動かすのは一見難しい。

しかしAnthropicはすでにこの問題を解決するインフラを持っています。実は定期実行の仕組みが3層構造で揃っている。

方式	動作場所	再起動後	マシンOFF
`/loop`（CLI内）	ローカル	消える	動かない
Desktop scheduled tasks	ローカル	残る	動かない
Cloud scheduled tasks	Anthropicクラウド	残る	動く

code.claude.com Run prompts on a schedule - Claude Code Docs

CLI内の /loop はセッション中だけの簡易スケジューラ。Desktopはローカルで永続化。Cloudに至ってはAnthropicのインフラ上で動くため、ユーザーのマシンが落ちていても実行されます。

Auto-dreamがどの層を使うかは不明ですが、3層ともすでにプロダクション環境で稼働済みです。技術的な障壁はほぼありません。

リリースはいつごろになるのかな

揃っている条件

理論的裏付け（Sleep-time Compute論文、2025年4月）
定期実行インフラ（デスクトップ版スケジュール機能、CLI版Cronコマンド）
UIの準備（/memory に表示済み）
フィーチャーフラグの仕組み（サーバーサイドでフラグを true にするだけ）

残っている論点

技術的にはいつでもリリースできる状態に見えます。残っているのはビジネス判断でしょう。

ユーザーが明示的に要求していないサブエージェント実行のコストを誰が持つか
メモリの整理過程でコンテキストがAPI経由で処理される点の説明
デフォルトONにするのか、ユーザーが明示的に有効化する方式にするのか

多分やるとしても昨今の機能リリースやTeamを見るにsettingなどで切り替えでになりそうかな、と思ってます。知りませんけど。

エンタープライズからの需要

長期記憶を持つ長期稼働エージェントは、エンタープライズ領域で強く求められています。

新セッションでも文脈が引き継がれ、オンボーディングコストが下がる
インフラ運用のナレッジが蓄積される（障害対応履歴、運用ノウハウ）
個人のメモリからプロジェクト単位のメモリへ、チーム間でナレッジを共有したい需要がある

Anthropicは2026年3月にClaude Partner Networkへ1億ドルの投資を発表し、エンタープライズ領域への拡大を加速させています。Auto-dreamのリリースはこのビジネス戦略とも合致します。

www.anthropic.com Anthropic invests $100 million into the Claude Partner Network

この記事の仮説に対する反証

ここまでの議論はあくまで状況証拠の積み重ねです。反証になりうるポイントも整理しておきます。

Auto-dreamはSleep-time Computeと無関係かもしれない

この記事ではAuto-dreamの設計とSleep-time Compute論文の対応関係を示しましたが、Anthropicが論文を参照して設計したという直接的な証拠はありません。もちろん大々的に開示をする、という事もするはあまりないと思います。いつものAnthropic自体がそういう事をしないので。

メモリを定期的に整理するという発想は、論文がなくても自然に出てくるアイデアです。 cronでゴミ掃除、デフラグ、ログローテーション。インフラ運用では当たり前のパターンであり、LLMのメモリ管理に応用するのに論文は必要ないかもしれない。

また、論文のsleep-time computeは「コンテキストから将来のクエリを予測して事前推論する」話であり、Auto-dreamの「過去のメモリを整理する」とは方向が逆です。論文は未来を予測する計算、Auto-dreamは過去を整理する計算。似ているように見えて、解いている問題が違う可能性があります。

ただし、両者に共通するのは**「ユーザーがいない時間に計算リソースを使って、次のセッションの効率を上げる」**という構造です。実装の詳細は違っても、設計思想のレイヤーでは接点があると考えています。

エンタープライズとAuto-dreamは結びつかないかもしれない

記事ではエンプラ需要との合致を述べましたが、現状のAuto-memoryには制約があります。

公式ドキュメントには明確にこう書かれています。

Auto memory is machine-local.

Auto-memoryはマシンローカルです。チームメンバー間での共有はできません。エンプラが求めるチーム共有ナレッジベースとは設計が異なります。

一方で、CLAUDE.mdにはProject scope（ソース管理経由でチーム共有）やManaged policy（組織全体に適用）のスコープがあり、autoMemoryDirectory で保存先を変更する設定も存在します。共有ストレージに向ければ擬似的なチーム共有は技術的に可能です。

ただし、チーム共有メモリは 「欲しい」と「実装できる」のギャップが大きい領域です。

複数人が同時にメモリを書き込んだらどうマージするか。CLAUDE.mdはgitで管理できるが、Auto-memoryのような非構造的なメモリのマージは厄介
個人のメモリですら書きっぱなしで散らかるのに、チーム全員分が混ざったらカオスになる。Auto-dreamで個人メモリの整理すらまだ実装できていない段階では時期尚早
誰のメモリをどの範囲で共有するか。プロジェクト固有の知見は共有したいが、個人のワークフロー癖まで混ざると邪魔になる

順番としてはAuto-dream（個人メモリの整理）が先で、チーム共有はその次のステップでしょう。今の設計はあくまで個人のメモリ整理であり、チーム共有メモリは別の機能として設計される可能性が高いと思います。ただdreamだけに夢がある、といったところでしょう。

そもそもリリースされない可能性

フィーチャーフラグがUIに出ていても、実験だけして撤退したプロダクト機能は山ほどあります。 Auto-dreamも同じ運命をたどる可能性はゼロではありません。

夢を見る機能が、夢のまま終わる。それもまた「おやすみ」の一つの形かもしれません。

ここから先は推測が推測を呼ぶ領域です。楽しいですが、この記事もここで「おやすみ」にしておきます。

まとめ

Auto-dreamはLLMに睡眠を与えるという詩的なコンセプトですが、実態は計算理論に裏付けられた機能です。

メモリファイルの統合・整理をサブエージェントが自動実行する
Auto-memoryの書きっぱなし問題を解決し、使うほど賢くなるサイクルを作る
Sleep-time Compute論文が示した「事前計算のコストはテスト時の削減で回収できる」が理論的背景
UIもインフラも揃っている。フラグ1つでリリースできる状態

Auto-memoryとAuto-dreamがペアで動き始めたとき、Claude Codeのメモリ管理は「書いて忘れる」から「書いて、寝て、整理して、思い出す」に変わります。

ClaudeCode、Claudeに「良い夢みてね」を言う日は割とすぐだと思います。機能リリースされれば、ですが。

参考

Sleep-time Compute: Beyond Inference Scaling at Test-time（arXiv:2504.13171）

arxiv.org Sleep-time Compute: Beyond Inference Scaling at Test-time

MemGPT: Towards LLMs as Operating Systems（arXiv:2310.08560）

arxiv.org MemGPT: Towards LLMs as Operating Systems

Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters（arXiv:2408.03314）

arxiv.org Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters