Anthropic、エージェントの記憶を「dreaming」で直す手法　正答13%→48%

米Anthropicのエンジニアリング記事は11月6日、エージェントの記憶をどう設計するかを整理し、会話の合間にログを読み直して記憶を直す手法「dreaming」を示した。セッションをまたいで残す記憶ノートと、オフラインでそれを直すdreamingを分けて評価し、知識wikiを128回のdreamingで育てると、25問の採点基準の正答が13%から48%に上がったと書く。長く回すBotやコーディングエージェントで、誤ったメモが次の会話に持ち越される問題への処方箋になる。

記憶はノートとdreamingに分ける

記事は、エージェント記憶を「経験から得た知識を、セッションをまたいで読める形で残すもの」と定義する。重みの更新や、1会話の中だけの学習、古い会話を要約で置き換えるcompactionは対象外だ。

人間の脳では、海馬が体験をすぐ捉え、睡眠や休息のあいだに長期の知識へ統合する、という対比を置く。エージェントでも、作業中のログや文字起こしを残しつつ、対話の合間の空き時間に文脈を組み直す「sleep-time compute」の考え方が使える、と記事は述べる。この再整理をdreamingと呼ぶ。

セッション中にClaudeが書くのは、あとで使えそうだと判断した出来事のタグや、記憶フォルダへのメモだ。dreamingは、そのメモを元のログと突き合わせて誤りを直し、索引やwikiのような新しい表現を作り、次のセッションで先に読み込む内容を整える。

誤りを直すと先へ進む

記事は、Managed Agentsでポケモンを遊ぶ例で、dreamingの効果を示す。洞窟を抜ける途中で、Claudeがポケモンセンターの位置を東西逆にメモしていた。dreamingがそのメモをセッション記録と照合して直し、次の走査では洞窟へ戻り次の街へ到達した。直さないメモのままでは同じ場所を回り、街に着けなかったという。

記憶をどう書くかも評価した。Continual Learning Bench（CL-Bench）1.0のデータベース質問では、各問を新しいセッションで始め、記憶フォルダだけを引き継ぐ。強いモデルほど、失敗と検証済みの規則を自分で回せるようになり、何を残すかを細かく指定しすぎるとかえって伸びが落ちた、と記事は書く。古いモデルには「答える前に記憶を読め」「仮説を試せ」といった誘導が効いたが、新しいモデルには記憶フォルダがある、という程度の案内で足りたという。

wikiを128回育てると正答が上がる

もう一つの実験は、文書群からwikiを育て、25問に答えるものだ。Opus系のエージェントに、128セッションまでdreamingでwikiを追記・統合・剪定させると、採点基準の充足率が2セッション時点の13%から48%まで上がった。検索ツールだけを使う場合は53%で、wikiだけでも48%に達し、検索とwikiを併用すると1問あたり約2万トークンを節約できた、と記事は記す。

dreamingは、セッション中に書けなかった抜けも埋める。2回目のdreamingでは、欠けたページへのリンク9本を同じ文書の既存のページへ付け替え、あわせて索引を含む新しいページ3つを足した例も示す。一方で、毎セッションに注入する最上位の記憶はトークンを食い、誤ったメモが全会話に乗るリスクもある。dreamingの仕事の多くは、詳細を下層へ下げてリンクだけ残し、最上位を小さく保つことだ、と記事は注意する。

長く回すエージェントでは、対話のあいだに誤ったメモが残りやすい。dreamingは、そのメモをログと突き合わせて直し、索引やwikiへ育てるオフラインの一手だ。手元では、記憶フォルダの用途だけを伝え、書き方の細則を先に固めすぎない方が、新しいモデルでは伸びやすい、というのが記事の実務寄りの結論になる。

編集部の見方

コーディングエージェントや定期で回すBotを運用している人は、失敗のメモが次の起動にそのまま載っていないかを一度確かめるとよい。Anthropicが示したのは、対話中に全部直すのではなく、合間にログと照合して直す、という分担だ。wikiや索引をdreamingで育てる実験は、長く続くプロジェクトのメモが肥大化したときの剪定の型としても読める。ただし記事は研究と評価のまとめであり、製品の既定機能としていつ入るかは書いていない。