長く動かしているエージェントの memory ファイルを開いて、うんざりしたことはないだろうか。同じ知見が言い回しを変えて三回書いてある。先週の前提と今週の前提が矛盾したまま並んでいる。とっくに消えたAPIの注意書きが残っている。エージェントは「気づいたことをメモする」のは得意でも、「ためたメモを整理し直す」のは誰もやってくれない。
Anthropicが5月6日のCode with Claudeで発表し、その後APIドキュメントが公開された Dreams(dreaming)は、まさにこの「メモの腐り」を相手にした機能だ。日本語ではまだほとんど解説されていないが、エージェントの長期記憶をどう扱うかという、地味だが本質的な問題に対するひとつの設計解になっている。
memory storeは追記で汚れていく
前提を一つだけ補っておく。ClaudeのManaged Agentsでは、エージェントが作業中に学んだことを memory store という永続ストアに書き込む。セッションをまたいで「このリポジトリのテストは pytest で動かす」「このユーザーはタブよりスペースを好む」といった知識を持ち越すための仕組みだ。
問題は、この書き込みがローカルかつ追記的(incremental)だという点にある。エージェントは作業の流れの中で都度メモを足していくだけなので、セッションを重ねるほどストアには重複・矛盾・陳腐化したエントリがたまる。公式ドキュメントもこの劣化をはっきり認めている。
over many sessions a memory store accumulates duplicates, contradictions, and stale entries.
（多くのセッションを経るうちに、memory storeには重複・矛盾・古くなったエントリが蓄積する)
ログを延々と追記し続けたファイルがいずれ読めなくなるのと同じで、追記オンリーの記憶は放っておくと信号がノイズに埋もれる。
Dreamsがやっていること
Dreamsは、この溜まったストアを非同期のバッチジョブで作り直す。入力は二種類だ。整理対象となる既存の memory store が一つと、そこから新しい知見を掘り起こすための過去の session(対話の記録)が1〜100件。これらを読み込んで、重複をマージし、矛盾・陳腐化したエントリを最新の値に置き換え、セッションから見つけた新しいパターンを反映した新しいmemory storeを出力する。
設計でいちばん効いているのは、入力ストアを一切書き換えない点だ。Dreamsは別の出力ストアを生成するだけで、元のストアには触れない。気に入らなければ出力を捨てればいい。記憶の再構成という、失敗すると黙ってエージェントの土台を壊しかねない操作を、レビュー可能な提案として扱っている。
呼び出しはMessages APIとは別の /v1/dreams エンドポイントで、Python SDKならこうなる(SDKがベータヘッダを自動付与する)。
dream = client.beta.dreams.create(
inputs=[
{"type": "memory_store", "memory_store_id": store_id},
{"type": "sessions", "session_ids": [session_a, session_b]},
],
model="claude-opus-4-8",
instructions="Focus on coding-style preferences; ignore one-off debugging notes.",
)
print(dream.id) # drm_01...
curlで直接叩くなら、managed-agents-2026-04-01 に加えて dreaming-2026-04-21 のベータヘッダが要る。
-H "anthropic-beta: managed-agents-2026-04-01,dreaming-2026-04-21"
ジョブは数分から数十分かかる非同期処理で、pending → running → completed と状態が遷移する。completed になると outputs[] に再構築済みストアのIDが入るので、それを次のセッションに memory_store リソースとして渡せば、整理後の記憶でエージェントが動き出す。
注目したいのが instructions フィールド(最大4,096文字)だ。「コーディングスタイルの好みに集中し、その場限りのデバッグメモは無視せよ」のように、何を読み込み・何を残し・どう構造化するかを高レベルで指示できる。ただしドキュメントは釘を刺している。これはストア全体に対する*合成(synthesis)*のパスであって、テキストエディタではない。「3行目をこう直せ」式の行単位の命令はほぼ無視される。個別エントリのピンポイント修正がしたければ、出力ストアに対してMemory Stores APIを使え、という整理だ。
何が新しいのか
「エージェントに記憶を持たせる」話なら、memory.md に追記する、RAGでベクタDBから引く、といった既存手法がいくらでもある。Dreamsがそれらと違うのは、記憶の蓄積と記憶の整理を別の処理として明示的に分離した点にある。
| ふつうの追記型メモリ | Dreams | |
|---|---|---|
| いつ書くか | 作業中、逐次 | 後からまとめて、非同期で |
| 何をするか | 足すだけ | 重複統合・矛盾解消・陳腐化の置換 |
| 既存の記憶 | そのまま汚れていく | 入力は不変、別ストアに作り直す |
| 失敗時 | 気づかず劣化が進む | 出力を捨てれば元に戻る |
人間が寝ている間に記憶を整理する、という連想からの命名だろうが、エンジニアの感覚に引きつけるなら、これは追記ログに対するコンパクションに近い。書き込みは速い追記で済ませ、整然とした状態への作り直しはオフラインのバッチに逃がす。LSMツリーやイベントソーシングで使い古された分割を、エージェントの記憶に持ち込んだ格好だ。
Dreamsは単体ではなく、同時に公開された「outcomes」(別のグレーダーが成果物を独立した文脈で採点し、基準を満たすまで作業をやり直させる)やマルチエージェント・オーケストレーションと並ぶ三点セットの一つだ。いずれも「一発の応答を良くする」より「長く走らせる中で勝手に良くなっていく」方向にエージェントを寄せる狙いが共通している。
使う前に踏まえておきたいこと
冷静に見ておくべき点もある。まずDreamsは執筆時点でresearch previewで、利用には申請が要る。プロダクションの記憶管理を丸ごと預ける段階ではない。
コストも軽くない。課金は選んだモデルの通常トークンレートで、ドキュメント曰く費用は入力セッションの数と長さにほぼ比例して伸びる。つまり過去の対話を丸ごと読み直させる行為であり、セッションが長大なエージェントほど整理のたびに相応の請求が立つ。まず少数のセッションで試し、品質に納得してからスケールせよ、という公式の助言は素直に従うのが良い。
そしてこれはAnthropicのManaged Agentsという実行基盤に乗った機能だという点。記憶・採点・オーケストレーションをプラットフォーム側が抱える設計は、運用が楽になる一方で、エージェントの中核資産であるメモリの管理をベンダーに寄せることにもなる。VentureBeatがこの一連の発表を「Anthropicはあなたのエージェントの記憶を所有したがっている」と評したのは、煽りというより的を射た懸念だ。
それでも、追記オンリーの記憶がいずれ破綻することは長く走らせれば誰でも気づく。Dreamsの面白さは「記憶を整理する」という当たり前の運用を、入力不変・レビュー可能・instructions で操舵可能という形で一級のAPIに昇格させたことにある。自前でエージェントの記憶基盤を組んでいる人にとっても、この「蓄積と整理を分け、整理は捨てられる提案として返す」という設計思想は、そのまま借りる価値がある。
公式ドキュメントはこちら。