Michael JohnsonAIエージェントが誤った事実を記憶すると、次のセッションでも同じ誤りを自信を持って繰り返すことがある。Anthropicが2026年11月6日に発表した研究では、タスク間に記録を見直す方法が紹介されている。エージェントは過去の作業ログと記録を照合し、不正確な点を修正して、役立つ情報をまとめる。同社はこのバックグラウンド処理を「夢」と呼んでいる。
長期間稼働するエージェントを設計する人にとって、実践的な示唆は明確だ。記憶は保存したメモの数ではなく、情報の出所を確認し、変化した情報を更新し、大量のアーカイブから必要な情報を見つけられるかどうかで評価すべきだ。Anthropicの実験は、このアプローチの有用性と、記憶がかえって妨げになる条件の両方を示している。
研究者が「エージェントの記憶」と呼ぶもの
Anthropicは記憶の構成要素についての説明で、記憶を、過去のやり取りやタスクから得られた知識のうち、セッションをまたいで保持され、エージェントが利用できるコンテキストとして定義している。これはシステムの独立した層であり、メモ、ファイル、インデックスなどの外部表現を指す。モデルのパラメーターを書き換えることや、現在の会話を通常の方法で短く要約することとは異なる。
この仕組みはいくつかの層で構成される。ログや記録が出来事を残し、メモが個々の観察事項を抜き出し、wikiのような関連づけられた表現がテーマごとに情報をまとめる。さらに、小さな上位層を新しいセッションにあらかじめ読み込ませることもできる。エージェントは、何を残し、何を後で確認し、次の実行に何をすぐ提示するかを判断しなければならない。
最後の判断はとりわけ難しい。出来事の重要性は、エージェントがその後の展開を見て初めて分かることが多いからだ。そこでAnthropicは、セッション中の作業とバックグラウンド処理を分ける方法を研究した。実行中にエージェントはログやメモを残し、後から別の処理がそれらを見直し、情報源を照合して、記憶の構成を更新する。
仕組みをどう検証したか
同社は単一の総合テストではなく、知識ベースへの質問、Pokémon Redのプレイ、社内文書を使ったwikiの作成、取引条件に関する法務ブリーフの作成など、複数のタスクを紹介した。こうした課題の組み合わせは、セッションをまたいでルールを保持すること、有用な詳細を選ぶこと、誤りを修正すること、複数の文書から情報を統合することなど、記憶のさまざまな機能を検証する。
知識ベースを使う課題では、質問ごとに新しいセッションを開始した。セッション間で保持されるのは、モデルが参照できる記憶フォルダーだけだった。研究者たちは、記憶あり・なしの成績を比較し、モデルがどのように記録を作るかも観察した。Anthropicが指摘する重要な違いは、検証済みのルールとその根拠を記したメモは次の質問に役立つ一方、未検証の推測を集めても信頼できる学習サイクルにはならないという点だ。
別の実験では、約35万件の社内文書、約4億2,000万トークンを使ってエージェントがwikiを構築した。その後、128回の連続セッションでページを補足・確認し、リンクを修正して重複を統合した。検証には、コーパスに関する25問を用いた。これは指定された文書群を使った限定的な実験であり、あらゆるエージェントの記憶を評価する汎用的なテストではない。
実験で分かったこと
知識ベースのタスクでは、複数のモデルで記憶による平均成績の向上が見られた。たとえばOpus 5.5では、満たした評価基準の平均割合が、記憶なしの0.655から、記憶ありの0.838に上昇した。Sonnet 5.5では0.644から0.833に上昇した。ただし、成績はモデルが記録をどう使うかによって異なった。Claude Sonnet 4.6は回答前に記憶ファイルを読まないことが多かった一方、Opus 5.5とSonnet 5.5は、検証済みのルールをよりうまく記述し、後のセッションで活用した。
Pokémonの実験は、過剰に記録することの代償を示した。ある実行ではSonnet 3.7が、遭遇した相手やアイテム、キャラクターなどを大量に記録し、225個のフォルダーに413個のファイルを作成した。記録の多くはすぐに古くなった。ゲーム内の位置や状態が変わる一方で、エージェントは記録の整理や再構築に行動を費やした。約1万ステップ時点の別の記憶比較では、Fable 5は2つのフォルダーに9個のファイルと、別途1つの共通ファイルを使用した。Anthropicによれば、Fable 5は4つのバッジを獲得したのに対し、Sonnet 3.7は1つだった。
誤ったメモがもたらす影響をよく示す例が、Mt. Moonの洞窟近くにあるポケモンセンターの位置に関するものだ。エージェントは洞窟をすでに通り抜けたと思い込み、以前のルートに何度も戻ってしまった。バックグラウンド処理がメモを行動ログと照合して誤りを見つけ、内容を書き換えた。その後、エージェントは入口に戻り、Cerulean Cityまで進んだ。記録を修正しない場合は同じ地点で足止めされた。ここでの「夢」は、新しい事実を自由に付け加えることではなく、履歴を検証する仕組みとして機能した。
大規模wikiの実験では、25問に対する評価基準の達成率が、構築を進めるにつれて13%から48%に上昇した。別の比較では、検索なしのwikiが48%だった。wikiと検索を併用した場合は54%から61%に変化し、wikiなしの検索は53%だった。この実験では、wikiは元文書の代わりというより、検索の上に重ねる関係性の地図、あるいはテーマ別の層として機能していた。
記憶は多ければよいとは限らない
記録を残すことは、将来への予測でもある。エージェントは、保存した情報が再び必要になると見込んでいる。その予測は古くなったり、誤っていたり、環境の現在の状態から直接得られる情報と重複したりする可能性がある。ゲームではキャラクターの位置を画面で確認できるが、導き出した戦略や検証済みのルールは、同じ方法で改めて推論せずに得ることはできない。
文書を使った実験では、構造上の別のリスクも明らかになった。複数のエージェントが契約条件を共通のページにまとめようとし、表の一部を互いに上書きした。その結果、wikiに含まれた確認対象の事実は57件中41件で、最初のブリーフは評価基準の72%を満たした。各契約に個別のページを割り当て、重要な条件を原文どおりに転記するようにした後、ブリーフは評価基準の100%を満たした。法的に重要な文言では、一般化した要約より、引用と元文書へのリンクを残す方が有用だった。
さらに、wikiの構築には、常にそのコストに見合う効果があるとは限らない。答えが1つの文書に含まれている課題では、Anthropicは通常のテキスト検索に対する明確な優位性を確認できなかった。別のテストでは、作成したwikiが元ファイルより大きくなった。こうした結果から、適用の目安が見えてくる。異なる情報源をまたいで情報を結びつける質問が繰り返し発生するなら複雑な構造が役立つが、単純な検索では、目立った利点がないまま管理負担だけが増える可能性がある。
エージェント設計に応用できること
この結果は、3つの要素から成る実践的なアーキテクチャを支持している。まず、メモの根拠を検証できるよう、一次ログを保存する。次に、結論やルール、計画について、出所と検証済みかどうかを添えた簡潔な記録を作る。最後に、別の処理を定期的に実行し、記録の矛盾を探し、関連づけを修正し、インデックスを再構成する。ただし、元資料をエージェント自身の要約で置き換えてはならない。
変化しやすい情報には、日付や有効な状況を記録し、再利用時に内容を確認するのが有用だ。長期的に有効な知識については、出所と裏付けを残すとよい。また、各セッションの共通コンテキストに読み込むのは、簡潔なインデックスだけにとどめるべきだ。Anthropicは、読み込んだ指示がコンテキストウィンドウを消費すること、そして誤ったメモがすべての実行に自動で追加されると、誤りが繰り返し広がりうることも指摘している。
この研究の最大の教訓は、エージェントの記憶は蓄積ではなく、選別とメンテナンスによって役立つようになるということだ。アーカイブは履歴を提供し、検索は必要な断片を見つけ、構造化されたメモは繰り返し現れるルールを結びつけ、バックグラウンドでの検証は結論を一次証拠に結び直す。この検証可能なつながりこそが、過去の経験を次のセッションに活用できる資源へと変える。
