エージェントメモリの構成要素 — dreamingでメモリを整える設計

Anthropicのエンジニアリングブログが、エージェントのメモリを「書く側」と「後から整える側」に分けて考える設計論を公開しました。後から整える側の仕組みが、dreaming(ドリーミング)です。書いたメモをあとで見直し、誤りを直し、構造を作り、次のセッションに先読みさせるものを選びます。

評価の中身は、データベース問答のCL-Bench 1.0、Pokémon Red、約35万ファイルの社内文書、合併案件の法務文書と幅広い構成です。この記事では、その結果を「メモリ設計で何を決めるか」という視点に組み替えて読みます。

背景 — メモリは時に、未来への予測である

扱うメモリの範囲は絞られています。対象は、Claudeがユーザーとのやり取りや割り当てられたタスクから得て、セッションをまたいで保持し、後から読める文脈として保存した知識です。モデルの重みの更新、1回の会話内の文脈学習、コンパクション(古いターンを要約で置き換える処理)は含みません。

そのうえで、メモリは時に予測になりうると述べます。ルールを書き残すのは、そのパターンがまた関係してくると見込むことです。検証済みの事実を書くのは、未来のセッションがその事実を再確認せずに頼りたがると見込むことです。

ここに難しさがあります。何が重要かは、先に何が起きるかを知らないと分かりません。この板挟みは、キルケゴールの「人生は後ろ向きにしか理解できないが、前向きに生きなければならない」という言葉で説明されています。

人間の脳との対応づけが、設計の軸になります。

• 海馬が経験をその場で素早く記録する → セッション中にメモを書く
• 睡眠や安静時に海馬が経験を再生し、新皮質に統合する → 夢を見る(dreaming)ように、ログを振り返ってメモを直す

dreamingは、LettaとUC Berkeleyの研究者が提案したsleep-time compute(対話の合間の遊び時間を使って文脈を整理させる考え方)を、メモリの整理に応用したものです。

モデルはメモの書き方を学んできたか

CL-Bench — 学習ループを閉じられるか

CL-Bench 1.0は、長い作業の中でメモリを使えるかを測るベンチマークです。ここでの課題は、データベースを引いて一連の質問に答えること。Claudeは回答後に正解を知らされ、次の質問のためにメモを書けます。Managed Agentsで実行し、各質問は新しいセッションから始まります。引き継げるのはメモリのディレクトリだけです。

ブログが示すモデルごとの違いを、メモリに何が残ったかで並べると次のとおりです。

Opus 5.5とSonnet 5.5もループを閉じ、メモリありの得点はOpus 5と同程度でした。メモリなしのベースラインは、この2つのほうがわずかに高かったとのことです。

Pokémon Red — 何を書かないかの判断

次の評価は、書く量の違いを際立たせます。約10,000ステップ時点で、Sonnet 3.7とFable 5のメモリフォルダを比べています。

Sonnet 3.7は、所持金や現在地のように毎ターン画面から読めることまで書いていました。ゲームの状態は刻々と変わるので、記録はすぐ古くなります。10,000ステップ付近では、4つ目の「マスター」フォルダを作り、17ステップでファイルを6つ作って9つ消し、ゲームの操作は1回もしませんでした。

Fable 5のメモは、画面からは得られない情報だけです。global.mdは現在の目標、ジム攻略の事前計画、メモリを使うための自分用ルールを持つダッシュボードとして働きました。Magikarpがボール7個連続で捕まらなかった経験からは、「3回以上連続で失敗したらタイミングを変える」という手順の知見が残っています。Opus 5.5も、現在の目標と次の手順だけの小さなフォルダを書き換えながらゲームをクリアしました。

メモは多いほど良いわけではありません。書く量が増えるほど、探して整える側の負荷が増えます。

指示は「何のためか」だけ伝える

ブログの結論は、メモリが何のためにあるかは伝えても、どう使うかまでは決めないほうがよい、というものです。CL-Benchでは「メモリフォルダがある」と伝えるだけで、Opus 4.7とOpus 5が有効に使い、成績も目に見えて上がりました。

逆に、書く内容を絞る個別ルールは、強いモデルでは逆効果でした。「失敗だけを記録する」というルールを与えると、Opus 5とOpus 4.7はメモリによる上積みの多くを失っています。ブログは、強いモデルには何が重要かを自分で判断させるほうが、事前のルールより効果的だったとまとめています。

一方、指示が効くのは古いモデルです。Sonnet 4.6は、答える前にメモリを読まないことが多く、立てた仮説も検証しませんでした。「答える前に読む」「仮説を明示的に検証する」と促すと、ベンチマークの得点は約2倍になっています。Sonnet 5は促さなくても、10回中9回は答える前にメモリを読みました。Sonnet 4.6では半分未満です。

dreamingはエージェントメモリの何を直すのか

dreamingが扱うのは、セッション中に書かれたメモの欠陥です。書いた時点の判断が間違っていたり、環境の変化でメモが古くなったりしても、次のセッションのClaudeはそのメモを信じて読んでしまいます。dreamingの役割は5つの場面に分かれます。

誤ったメモを直す — Mt. Moonの例

Pokémonでは、Claudeが「ポケモンセンターは山の東側」と誤って書きました。センターを出て「Mt Moonは後ろにある」と宣言し、メモに「Mt Moon DONE」と書き込みます。ところが山は後ろにありませんでした。直後に一方通行の崖から落ち、元の道へ戻ります。ナビゲーションツールは落下を表示しないため、Claudeは「西へ行き過ぎた」と解釈し、自分は正しい側にいたと結論づけました。

誤ったメモのまま走らせた実行では、崖から3回落ちています。3回目の後でClaudeは「ループするのをやめます」と書きましたが、検証環境の自動応答が続行を指示したため、ふもとの町まで戻って終わりました。次の町には着いていません。

同じメモリフォルダにdreamingをかけると、Claudeはメモをセッションの記録と照合して誤りに気づき、書き直しました。修正後は洞窟に再び入り、Cerulean Cityに着いています。決め手は、トランスクリプトという答え合わせの材料があったことです。

wikiを作る — 効く課題と効かない課題

wikiは、1つの主題についてClaudeが知っていることを集め、他のノートにリンクするページ群です。リンクが地図になり、増え続ける記憶の中から必要なものを探せます。

検証に使ったのは、Anthropicが5月に買収したStainlessの社内文書です。約35万ファイル、約4.2億トークンに及びます。25問の評価セットを作り、検索ツールを渡したうえで、dreamingでwikiを作らせました。Opus 5のエージェントが128セッションかけて、ページの作成と修正、重複の統合、出典との照合を進めています。

• 2セッションから128セッションに増やすと、採点基準の達成率は13%から48%に上がった
• wikiだけで答えたときの最高は48%
• 検索とwikiを併用すると、wikiの成長に応じて54%から61%まで上がった(検索だけは53%)
• 併用は1問あたり約2万トークンの節約にもなった

wikiは検索の代わりではなく、検索の効率を上げる地図として効いたことになります。

では、どの課題でwikiが効くのか。Harvey LABベンチマークと、合併に関する文書群で確かめています。複数の文書にまたがる情報を要する項目では、wiki経由の正答率が87%、検索のみが73%でした。反対に、採点基準の大半が1つの文書の検索で満たせるLAB課題では、wikiの効果は明確に出ていません。別の課題では、wikiが元の文書より大きくなりました。ブログはこれを、帝国と同じ大きさの地図を作ってしまったボルヘスの短編にたとえ、何も抽象化できていないと述べています。

wikiを作る価値は、答えが複数の文書に散らばっているかどうかで決まります。単一の文書で足りる課題には不要です。

昇格と目的への調整

dreamingは、メモを記憶の階層の最上位に昇格させることもできます。ハーネスが毎セッションの冒頭にその層を先読みさせれば、Claudeは検索する必要も、検索すべきものがあることを知る必要もありません。

ただし、先読みにはコストがあります。トークンを消費しますし、誤ったメモが毎回のセッションに持ち込まれます。読み込んでも、Claudeがその通りに動くとは限りません。そのため、最上位の層は小さく保つ必要があり、詳細を下の層に移してリンクを残す作業が、dreamingの仕事の多くを占めます。

Claude Codeの自動メモリは、同じ形で小さく保たれています。MEMORY.mdの先頭200行または25KBの早いほうまでを会話の開始時に読み込み、それを超える部分は読み込みません。詳細はトピックごとのファイルに移し、MEMORY.mdは索引として働きます(設定の詳細は自動メモリの保存先変更とオフ設定にあります)。

例えば、階層を意識したメモリは次のような形になります。これはブログの説明に沿って組んだ例示です。

memory/
├── MEMORY.md        # 索引。常に読み込まれる。短く保つ
├── goals.md         # 現在の目標と次の手順
├── rules/
│   └── retry.md     # 検証済みのルールと、その根拠
└── places/
    └── route-a.md   # 場所ごとの攻略メモ

目的への調整は、LAB課題の例が具体的です。企業買収を想定し、契約書から条件を拾って報告書を書く課題で、wikiの作成指示は「wikiの使い方」を含まない基本形でした。複数のエージェントが同じ契約条件の表に同時に書き込み、互いの書き込みを上書きしています。採点対象の事実57件のうち、報告書に入ったのは41件(72%)でした。

ここでClaudeに、失敗を振り返り、指示の変更案を出し、wikiを作り直すループを回させます。Claudeは契約条件の重要性に気づき、指示を書き換えました。契約ごとに1ページ、1エージェントが担当し、条件は要約せず原文のまま引用する形です。採点基準は100%満たせるようになり、事実は57件すべてが残りました。

メモリの育て方の指示は、課題が決めるものです。何が重要かをdreamingに伝えないと、重要な部分ほど薄くなることがあります。

最後は、抜けを埋める役割です。メモを書く時点のClaudeは、そのセッションの文脈しか見ていません。LABのwiki作成では、まだ存在しないページにリンクを張ることがあり、2回目のdreamingで多くが解消されました。ある課題では、存在しないページへの9本のリンクを、同じ文書の既存ページに付け替えています。索引を含む3ページも追加しました。

実装に引き寄せて読む — 3つの設計判断

メモリ機構を作る側から見ると、ブログの結果は3つの選択に分かれます。ここから先はブログの事実ではなく、その結果をもとにした解釈です。

もう1つ、見落としやすい点があります。dreamingが直せたのは、答え合わせに使えるトランスクリプトがあったからです。ログを残さない構成では、メモの誤りを後から検証する足場がありません。メモリを設計するときは、書いたノートと並べて、元の記録を残す方針も一緒に決めることになります。

Managed Agentsには、これに近い機能としてDreamsがあります。既存のメモリストアと過去のセッションを読み込み、重複の統合や古い値の置き換えをして、別のメモリストアを出力する非同期ジョブです。入力元のストアは変更されません。リサーチプレビュー扱いで、利用にはアクセス申請が必要です。使い方はManaged AgentsのDreams機能の解説にまとめています。ブログはdreamingという語からManaged AgentsのDreamsページへリンクしており、始め方としてManaged Agentsのdreaming cookbookを案内しています。ただし、各評価がDreams APIそのもので実行されたかは本文に書かれていません。

メモリツールを自前で実装する場合は、Memoryツールの6コマンド実装や、Managed Agentsのメモリ管理のベストプラクティスが入口になります。コンテキストの編集と組み合わせる設計は、Context editingとmemory toolの併用で扱いました。

未解決の問い

結論は急がれず、3つの問いが開いたまま残っています。

1つ目は、メモをいつ作るかです。作業中に書けば、重要な細部を発生源で押さえられます。ただしメモを取ること自体が、本来の作業から注意を奪います。dreamingは作成を裏に回せますが、出力はすぐには使えません。

2つ目は、メモリを最新に保つ方法です。dreamingで誤りは直せますが、計算資源が要ります。全メモリを常に点検させるのは現実的ではないかもしれません。変わりやすい情報に絞るか、メモリへのアクセス頻度に応じて夢を見る間隔を調整する案が挙がっています。

3つ目は、トランスクリプト検索を土台にする道です。wikiなどの表現と検索を併用すると効くことがあるものの、表現を保守し、誤りや幻覚の蓄積を防ぐ計算資源が必要になります。

まとめ

評価全体から浮かぶのは、メモリの質は「どれだけ書いたか」ではなく「何を書かなかったか」と「書いた後にどう直したか」で決まる、という点です。global.mdを含めて10ファイルのFable 5が413ファイルのSonnet 3.7より先へ進んだことと、128セッションのdreamingでwikiの得点が13%から48%に伸びたことは、同じ話の表と裏にあたります。

自前でメモリを設計する人にとっての実務的な論点は、先読み層を小さく保つこと、元の記録を検証用に残すこと、wikiは複数文書にまたがる課題で使うことの3点です。ブログが示したのは、強いモデルほど書く判断を任せたほうが成績が上がる、という傾向までで、どのルールが最適かは課題ごとに試すことになります。