Anthropicの新機能「Dreaming」はセッションログをオフラインで読み取り、反復パターンを見つけ、重複する記憶をより緊密なファイルに統合します
元のセッションデータはそのまま変更されず、書き換えられるのは統合後のメモリアーティファクトだけです
これはベクトル検索でもファインチューニングでもありません。既存のメモリエントリに対する別個のオフライン処理です
長時間稼働するエージェントや反復ワークフローでは効果が出ますが、ワンショットのエージェントでは得られるものがほぼありません
現在、Result Loops、Multi-Agent Orchestration、Webhooksと並行してテスト中で、パブリックベータです
Anthropicは2026年5月6日、SF開発者カンファレンスでDreamingを発表しました。この機能はテスト段階でありGA（一般提供）ではありません。昨日の報道の大半は「エージェントの記憶統合」とラベリングして話題を切り上げました。仕組みは見出しが示す以上に面白く、実際の影響という“誰も語らなかった部分”こそがポイントです。
Dreamingが実際に行うこと
Dreamingはオフラインで動作します。ライブのリクエストも、ユーザーのプロンプトも、ツール呼び出しもありません。処理が行われている間、エージェントは起きていません。これは別枠の処理で、最近のセッションでエージェントが書き留めた内容を読み取り、パターンを探し、メモリーファイルをよりコンパクトなものへ書き換えます。
仕事（処理）にはいくつかの要素があります。
まずセッションログをスキャンします。Managed Agentはすでに、実行したこと、試したこと、うまくいったこと、失敗したことの記録（トランスクリプト）を保持しています。Dreamingはそれらのログを、日曜の朝に自分のメモをゆっくり読み返すのと同じように読み込み、何度も繰り返し登場する断片を探します。
次にパターンを検出します。同じ種類の質問をエージェントが1週間のうち14回行っていた場合、それはフラグが立ちます。同じワークフローを、表現が少し違う5つの記憶が説明している場合、それらは1つの標準エントリにまとまります。一度書かれたものの、その後参照されない記憶は削除されます。
その後、メモリーファイルを書き換えます。ログの要約ではありません。エージェントが毎回の実行で読み込む、新しいバージョンのファイルです。より小さく、重複が取り除かれ、実際にエージェントが使用したものに基づいて優先順位付けされています。
元のセッションデータは決して変更されません。この点が重要です。ログはそのままの文言で残ります。触るのは導出されたメモリアーティファクトだけです。もし何かがうまくいかない場合でも、参照元（ソース・オブ・トゥルース）は残っているため回復できます。
「重複が統合される」とは実際どういう意味か
この部分をほとんどの投稿は飛ばしていました。実際に“記憶がどう蓄積されるか”を見るまで、当たり前のように聞こえてしまうからです。
稼働中のエージェントは、機会があれば（opportunistically）記憶エントリを書き込みます。月曜に「ユーザーはTypeScriptを好む」を保存し、水曜に「このプロジェクトではユーザーがTypeScriptを使っている」を保存し、金曜に「関連する場合は例をTypeScriptに切り替える」と保存するかもしれません。同じ事実が、3つの異なる言い回しで残るのです。2か月目には、エージェントの記憶は9層の“重なり”をまとっています。
Dreamingは重なりを見つけ、1つのエントリとして書き込みます。新しいエントリには、統合の際の追加メタデータが少し含まれることが多いです。たとえば確信度（confidence weight）や頻度カウントなどです。これにより、エージェントはそれが単発の一言ではなく、安定した嗜好だと理解できます。
逆のケースも検出します。たとえば、月曜に「常に4スペースのインデントを使う」と保存し、水曜に「ユーザーは2スペースのインデントを望んでいる」と保存した場合、後者が勝ちます。より新しく、かつユーザーが明確に修正した内容だからです。統合されたエントリには修正後のバージョンが保持されます。古い方は“下に埋もれる”のではなく、削除されます。
結果として、メモリーファイルは直線的に増えなくなります。統合がない場合、Managed Agentの記憶は数百セッションも経つと、付箋の山のようになります。Dreamingはファイルの形を保つことで、エージェントが目を覚ますたびにファイル読み込みがコンテキストウィンドウを食い尽くすことを防ぎます。
ベクトル検索、要約、ファインチューニングとの違い
「エージェントに記憶を持たせる」ためのアプローチはいくつかすでに存在します。Dreamingはそれらのどれでもありません。
ベクトル検索では、すべてを保持し、実行時に関連するチャンクを取り出します。記憶は永遠に増え続けます。しかも、そのコストを毎回のクエリで支払います。想起の質は埋め込み（embedding）の品質に依存します。Dreamingは検索の“前”に位置し、参照（retrieval）のための母集団そのものを書き換えることで、そもそも検索が扱う量を減らします。
要約（Summarization）は、古い会話をモデルがウォームアップとして読む1つの段落に圧縮します。損失（lossy）です。設計上、細部は“なだらかに”されて味気ない文章に吸収されます。Dreamingは要約というより、再インデックス作成（re-indexing）に近いです。出力は、エージェントが事実として扱う構造化されたメモリーファクト・エントリであり、再解析しなければならない段落ではありません。
ファインチューニングは、パターンをモデルの重み（weights）に焼き付けます。恒久的で、コストが高く、巻き戻しには苦労します。エージェントが間違ったことを学習してしまったら、再学習（再トレーニング）します。Dreamingは重みではなくファイルを触ります。統合された記憶が間違っているなら、ログから再生成します。可逆で安価で、エージェントごとです。
人間にたとえるなら、静かな日曜にメモアプリを整理するのが一番近いと思います。同じメモ、より少ないメモにして、月曜に本当に必要なものを見つけやすく整理する。エージェントはあなたが眠っている間に、自分のスケジュールでそれを行います。
エージェントの記憶アーキテクチャに関する深い文脈は、Claude Managed Agents Now Have Filesystem Memoryをご覧ください。Dreamingがその上で動作する記憶のプリミティブは、この発表の2週間前に導入されていました。
それが重要になるとき／重要でないとき
Dreamingの効果は、エージェントが自分自身をどれだけ再利用するかに比例して出ます。1回実行しても効果が見えません。1,000回実行すれば、ファイルが小さく保たれます。
分かりやすい例は長時間稼働するエージェントです。調査エージェントが6か月間、毎日稼働すると、セッションエントリが数千件たまります。統合がない場合、コールドスタートのたびに、さらに多くのコンテキストが一緒に引きずられます。Dreamingがあると、いくつかのサイクルの後にメモリーファイルが安定し、エージェントはほぼ一定時間で読み込めます。
次は反復ワークフローです。エージェントが同じ種類のチケットを200回処理すれば、ワークフローの“型”を掴みます。Dreamingはその型を200回ではなく1回だけ取り込みます。これにより、毎回の実行で「明らかなこと」を作り直す必要がなくなります。これは、2か月経ってもファイルサイズが倍増していないことに後から気づいて初めて理解できる種類のものです。
マルチエージェント構成でも効果があります。新しいMulti-Agent Orchestrationのベータでは、コーディネーターが最大20人の専門家にタスクを割り振れます。それぞれの専門家が自分自身のメモリを書き込みます。Dreamingはエージェントごとに動作するため、専門家ごとのファイルはスリムに保たれ、下からのコンテキスト漏れでコーディネーターが押し潰されることがありません。
ワンショットのエージェントでは、ほとんど何も起きません。エージェントが一度動いて、関連するタスクに二度と遭遇しないなら、検出すべきパターンも統合すべき重複もありません。そのような場合にDreamingを回すのは無駄な計算です。Anthropicのプレビュー資料でも、まさにこの理由から機能はオプトインだと述べられています。
また、メモリの衛生（hygiene）が悪い問題も解決しません。エージェントがゴミを保存しているなら、そのゴミを統合しても、より整ったゴミが生まれるだけです。Dreamingは、そもそもエージェントが何を“覚えると決めたか”の下流にあります。ゴミが入れば、少しだけ整理されたゴミが出る。
私の大まかな感覚的な閾値は、約50セッションまたは1,000メモリエントリ（先に来た方）です。それ以下ならファイルは人間が目視できる程度に小さいです。以上になると、統合が自己負担し始めます。
CoworkおよびClaude Codeのログで何を期待するか
DreamingがGAとして提供されると、CoworkやClaude Codeにおける露出（表面化する範囲）は小さくなるはずです。そこが狙いです。
Coworkでは、エージェントのタイムラインに「memory consolidation」や「dream cycle」のようなタグが付いた新しいエントリが表示されることを期待してください。これはセッション間で実行され、1回のセッション中には実行されません。そのエントリには、何件のメモリが統合されたか、何件が削除（pruned）されたか、新しい合計件数が表示されます。そこをクリックすると、古いメモリーファイルと新しいメモリーファイルの差分（diff）が見られます。このdiffが監査ログ（audit trail）になります。
ローカルで Managed Agents を実行している Claude Code ユーザーは、エージェントのログでも同じものを見ることになります。tool: や compact: がすでに表示されているのと同様に、dream: というプレフィックスが付いた行が出てくるはずです。頻度はおそらく N 回のセッションごとに 1 回にデフォルト設定されており、エージェントの仕様（spec）から構成できます。
実際に着地したら、まず見るべき点は 2 つあります。
指標よりも重要なのは diff です。「37 memories merged」という行は、正しいものがマージされたかどうかを教えてくれません。変更前/変更後の diff は、有用な優先設定が統合されて解消されたかどうかを示します。信頼できるまでの間、junior dev のコミット diff を読むのと同じように、最初の数サイクルは読んでください。
頻度の調整は、ここから面白くなります。やりすぎると、エージェントが有用な詳細を忘れてしまいます。緩すぎると、ファイルが肥大化します。Anthropic はおそらく妥当なデフォルトを出した上で、パワーユーザー向けの調整用ノブを 1〜2 リリース後に公開するでしょう。そのノブが出てくることを前提に計画し、不足していることを回避する形で設計しないでください。
Claude Managed Agents at scale を実行している場合、これは「今から6か月後も、あなたのエージェントがサブ秒で読み込み続けているかどうか」を決める機能です。API がそれを公開し次第、評価スイートで早めにフラグを立てておく価値があります。
Bottom line
ドリーミングは魔法でもなく、記憶システムでもありません。これは Anthropic が 2 週間前に出荷した記憶プリミティブの上に実行されるメンテナンス・パスです。仕事の範囲は狭いです。ログを読み、パターンを見つけ、重複をマージし、メモリファイルを書き換え、ソースデータはそのままにします。
長く動き続けるエージェントや、繰り返し行うワークフローにとって、このメンテナンス・パスは、「メモリファイルが有用なまま保たれるか」それとも「60日後にガラクタ置き場になってしまうか」の違いです。一発限りのエージェントでは、何もしない（ノーオペ）です。
これがベータに到達したときに私が注視するのは、指標ではなく diff です。指標は「何かが起きた」ことを教えてくれます。diff は「正しいことが起きたかどうか」を教えてくれます。
これは Result Loops、20-way Multi-Agent Orchestration のベータ、そして Webhooks とともに出荷されます。完全な導入は Claude Managed Agents Just Got Dreams, 20-Way Parallelism, and Self-Checking Loops にあります。私がこれまでに書いてきた残りのエージェント向けツールについては、RAXXO Lab に Claude Managed Agents のクラスタがあります。
