Claudeは「夢」を見て記憶を直す。Anthropicがエージェント記憶の部品を公開、35万ファイルのwiki化で正答材料は13％から48％へ

まず初めに

AIの記憶の話になると、だいたい「どれだけ大量に覚えられるか」の競争になる。今回Anthropicが出してきたのは、その逆の話だ。覚えすぎたモデルは、自分のメモの山に埋もれてゲームすら進めなくなった。勝ったのは、10ファイル足らずに絞って「今の目的と、試して分かったルール」だけを持ち歩いた方である。人間の整理整頓の失敗談と、驚くほど同じ形をしている。容量の競争から、捨て方の競争へ。記憶の勝負はそちらへ移った。

※個人の感想です

「エージェント記憶」とは何か

Anthropicは「エージェント記憶」を、Claudeが利用者とのやり取りや任された作業から得た知識で、セッションをまたいで残り、後から読み返せる文脈として保存されるもの、と定義しています。学習でモデルの重み自体を変えること、その場の会話の中で学ぶこと（in-context learning）、古い発言を要約に置き換えて作業を続ける「compaction」は、記憶には含めないと線を引いています。

課題は単純です。何を覚えるべきかは、その時点では分かりません。覚えた内容が間違っていたり、環境が変わって古くなったりもします。だから同社は、作業中に重要な出来事に印を付けてメモに書く「その場の記録」と、空き時間に記録全体を見直す「dreaming」を組み合わせる設計を説明しています。dreamingという考え方は、LettaとUC Berkeleyの研究者が提案した「sleep-time compute（睡眠時間の計算）」に由来するとしています。

何を覚えるか――ポケモンで見えた世代差

判断力の評価には『ポケットモンスター 赤』のプレイが使われました。各モデルにメモリ用フォルダを与え、約10,000ステップ時点のフォルダを比べています。

• Claude Sonnet 3.7は「全部要るかもしれない」と、戦闘ごと・アイテムごと・キャラクターごとにファイルを作り、413ファイル・225フォルダに膨らみました。獲得したバッジは1つです。しかもゲームの状態は刻々と変わるため、詳細な記録ほどすぐ古くなり、メモの整理自体に手数を使ってゲームが進まなくなる場面もありました。
• Claude Fable 5は、ファイル9件とフォルダ2つ、それに全体の目的と計画を書いた global.md 1件だけに絞り、バッジを4つ獲得しました。画面を見れば分かる情報（所持金や現在地）は覚えず、自分で考え出さないと消えてしまう戦略や検証済みのルールだけを残す、という使い分けです。
• Claude Opus 5.5も小さいフォルダを保ち、目的と次の手を書き換えながら進めて、ゲームを最後までクリアしました。

データベースを引いて質問に答える課題（Continual Learning Bench 1.0）でも似た差が出ています。Sonnet 4.6は未検証の推測を散らかす段階まで、Opus 4.7は1つの参照文書に統合する段階まで、Sonnet 5は正誤の確認印と訂正を書く段階まで進み、Opus 5が初めて「ルールと、そのルールが正しいと分かった根拠と、発見した落とし穴の警告」まで揃える学習の輪を閉じた、と同社は報告しています。

細かい使い方を指示するより、「記憶は何のためにあるか」だけを伝える方が効いた、という結果も示されています。「失敗だけを記録せよ」という規則を与えると、Opus 5とOpus 4.7では記憶の効果が大きく落ちました。一方、古いモデルには具体的な指示が効き、Sonnet 4.6に「答える前にメモを読み、推測を検証せよ」と促すとスコアがほぼ2倍になったとしています。Sonnet 5は促されなくても10回中9回は先にメモを読むようになっていた、とのことです。

dreamingは誤りを直し、wikiを育てる

誤った記憶の修正例として、ポケモンの「おつきみやま」の事例が紹介されています。Claudeは回復施設（ポケモンセンター）の位置を東西逆にメモし、その誤りのせいで同じ崖から3回落ちて、到達を諦めかけました。そこでメモフォルダにdreamingをかけると、Claudeは元のセッション記録と照合して誤りに気づき、メモを書き直しました。訂正後はまっすぐ洞窟を抜けて、次の街に到達したとしています。

もう一つの実験が、文書の山をwiki（相互にリンクした知識ページ集）に変える試みです。ソフトウェア企業Stainlessの内部文書、約35万ファイル・約4億2,000万トークンから、25問の評価セットを用意し、Opus 5のエージェントが128セッションかけてwikiを育てました。dreamingのセッションを2回から128回へ増やすと、wikiだけで答えた場合の材料充足度は13％から48％へ伸びました。検索ツールと併用した場合は54％から61％で、検索だけの53％を上回り、質問あたり約20,000トークン節約できたとしています。

ただし、万能ではありません。合併関連の質問ではwiki参照が87％対73％で検索単独を上回った一方、文書1件から検索で足りる課題ではwikiの利得が見られず、別の課題ではwikiが元の文書より大きくなる本末転倒も起きました。契約条件が要の課題では、共有表への書き込みの競合で重要事実が欠け、当初は57件中41件（72％）の充足にとどまりましたが、指示自体を振り返って直すループを回すと100％に届いた、としています。

実務との接点もあります。Claude Codeの自動メモリは、毎セッション読み込む層を MEMORY.md の先頭200行または25KBまでに絞り、それを索引として使う設計だと同社は説明しています。全部を毎回読むのではなく、目次だけを常備し、本文は必要時に取りに行く形です。

これらの数値はすべてAnthropic自身の評価であり、第三者による再現ではありません。また同社は、記憶の作成に計算資源が要ること、誤ったメモが全セッションに注入され得ること、dreamingの頻度の調整が未解決であることも、課題として挙げています。

IT Postの見方

IT Postでは、今回の記事の価値は「dreaming」という派手な名前ではなく、「覚える量ではなく、捨て方と直し方が性能を決める」と同社が実測で示した点にあると考えます。413ファイルで身動きが取れなくなった旧モデルと、10ファイルでクリアした新モデルの対比は、エージェントの記憶が「保存容量」の問題ではなく「編集」の問題だということを、これ以上ない形で示しています。記録を貯めるだけの仕組みは、貯めた分だけ遅く、古く、間違いやすくなる。見直す工程に計算を払うかどうかが、次の差になるでしょう。

同じ週には、未公開のAnthropicモデルを使った研究システムが量子計算の未解決予想を証明したという発表もありました。「賢いモデル」競争の裏側で、「経験をどう残し、どう直すか」という地味な基盤の競争が、表に出てきた週だと言えます。

今後どうなりそうか

今後の確認点は、dreamingの仕組みが開発者向けの機能としてどこまで一般提供されるか（同社はdreaming入門のクックブックへの案内を記事末尾に置いています）、記憶の誤りの注入や古さへの対策がどう実装されるか、そして第三者が同じ評価を再現できるかです。

IT Postでは、新しい公式情報が確認できれば続報として整理します。