AIは「忘れる」べきか：記憶を増やすほど、エージェントは壊れやすくなる

AIエージェントには、過去の会話、実行履歴、利用者の好み、成功した手順を覚えさせた方がよい。そう考えるのは自然です。

前回と同じ失敗を避け、利用者が説明を繰り返さなくて済み、業務固有の手順も身につけられる。記憶は、汎用的なLLMを継続的に改善するための重要な仕組みに見えます。

しかし、記憶は多いほどよいのでしょうか。

最近の研究では、記憶を増やし、更新を繰り返すことで、AIエージェントの性能がかえって低下する現象が報告されています。問題は単にコンテキストが長くなることではありません。誤った経験を再利用する、古い情報を現在の事実として扱う、複数の経験を不適切に一般化するといった、記憶そのものの品質にあります。

本記事では、近年の研究を手がかりに、AIエージェントにとって「忘れる」とは何か、業務システムでは記憶をどう設計すべきかを考えます。

ここでいう記憶は、モデルの重みではない

最初に対象を明確にしておきます。本記事で扱う記憶は、LLMが事前学習で獲得した知識ではなく、エージェントが利用中に外部へ保存する情報です。

たとえば、次のようなものがあります。

• 過去の会話と利用者の設定
• タスクの実行履歴と結果
• 成功・失敗から抽出した注意点
• 再利用するために文書化した手順やスキル
• RAGで検索する業務文書
• 人が行った修正やフィードバック

保存方法も一つではありません。会話をそのまま残す方法、検索用のデータベースへ入れる方法、複数の経験を短い教訓へ要約する方法、手順書としてファイルに保存する方法があります。

ここでいう「忘れる」とは、保存データを無条件に消去することではありません。現在の判断に使わない、検索対象から外す、古い版として無効化する、詳細な履歴と要約を分けて管理するといった操作を含みます。

記憶がエージェントを改善する仕組み

典型的なエージェントは、新しいタスクを受け取ると、似た過去のタスクを検索します。見つかった入力と実行結果をプロンプトへ加え、過去の経験を例として次の行動を生成します。

新しいタスク
  → 類似する過去の経験を検索
  → 経験をプロンプトへ追加
  → 計画・実行
  → 今回の結果を記憶へ追加

この循環は、正しい経験を適切に取り出せる限り有効です。一方で、過去の経験が誤っていた場合や、表面的には似ていても条件が異なる場合には、その誤りまで再現します。さらに今回の結果を再び保存すると、誤りが将来のタスクへ引き継がれます。

How Memory Management Impacts LLM Agents は、これを「experience-following」と呼んでいます。現在の入力と検索された記憶が似ているほど、エージェントの出力も過去の出力に似やすくなる性質です。

成功例を再利用するには望ましい性質ですが、記憶の内容が悪ければ、誤りの伝播や、現在のタスクに合わない経験の再生につながります。同研究では、記憶を無条件に増やす方式に比べ、保存する経験を選別し、低品質・古い・重複した記憶を削除する方式が、3種類のエージェントで平均10ポイントの絶対性能改善を示しました。

重要なのは、記憶容量ではなく、書き込みと削除の判断だったという点です。

正しい経験から作った記憶でも、壊れる

では、失敗した実行結果を保存しなければ解決するのでしょうか。2026年5月に公開された Useful Memories Become Faulty When Continuously Updated by LLMs は、より難しい問題を示しています。

この研究は、エージェントが過去の実行履歴を繰り返し要約し、再利用可能な教訓へ統合する過程を調べました。対象にはALFWorld、ScienceWorld、WebShop、AppWorld、ARC-AGIを使った制御実験などが含まれます。

結果は、記憶の効用が単調には増えないというものでした。更新の初期には改善しても、統合を繰り返すうちに性能が下がり、記憶を使わない条件を下回る場合もありました。

特に興味深いのは、ノイズのある失敗履歴ではなく、正解が与えられた経験から記憶を作っても性能が崩れたことです。ARC-AGIを用いた実験では、GPT-5.4が記憶なしで解けていた問題群に正解例を順次統合した後、正答率が52.6%まで低下しました。

入力となる経験が正しくても、それを抽象化して記憶を書き換える段階で、次のような問題が発生します。

• 本来は異なる問題を、同じ種類の経験としてまとめる
• 手順が成立する条件を要約時に落とす
• 一部の事例に過剰適合した規則を作る
• 新しい教訓で、以前の有効な教訓を上書きする
• 更新する順序や単位によって、異なる記憶ができる

つまり、正しい記録を保存することと、正しい一般則を作ることは別の問題です。

生の履歴と、要約された教訓は役割が違う

エージェントの記憶は、大きく二つに分けて考えられます。

一つは、何が起きたかを残すエピソード記憶です。入力、実行した操作、結果、評価などの生の履歴が該当します。

もう一つは、複数の経験から抽出した意味記憶・手続き記憶です。「この形式のファイルは先に文字コードを確認する」「この申請では承認者を取得してから登録する」といった、再利用可能な知識や手順です。

生の履歴は具体的な証拠を残せますが、増え続けるため、検索と利用にコストがかかります。要約された教訓は短く再利用しやすい一方、適用条件や例外を失う危険があります。

前述の研究では、生の履歴をそのまま保持する方式が、LLMに教訓へ統合させる方式と競争力を持つ場合がありました。これは「一切要約するな」という結論ではありません。長期運用では、すべての履歴を毎回読むことはできず、圧縮と抽象化が必要です。

ただし、抽象化した記憶だけを残し、根拠となった履歴を上書きしてしまう設計は危険です。要約に誤りが見つかっても、何を根拠に作られたのか検証できないためです。

古くなった記憶は、取得できるだけでも問題になる

記憶のもう一つの問題は、時間とともに事実が変わることです。

利用者の好み、担当者、予算、契約、社内規程、商品の価格は更新されます。「以前は正しかった」という記憶が、現在も有効とは限りません。

ACL Findings 2026で発表された From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents は、週・月・四半期にわたる会話を想定したMemoraというベンチマークを提案しています。

従来の記憶評価は、過去に登場した情報を思い出せるかに重点を置いていました。しかし、古い情報をうまく検索できることが、現在の正しい回答につながるとは限りません。Memoraでは、無効化された記憶を回答に使った場合に減点する指標を導入しています。

4種類のLLMと6種類のメモリエージェントを評価した結果、無効になった記憶の再利用や、時間とともに変化した情報を整合させられない問題が頻繁に確認されました。外部メモリの追加による改善も限定的でした。

業務システムに置き換えると、最新版の規程を検索できるだけでは足りません。旧版を検索結果から外し、いつから無効かを表現し、必要なら監査用に履歴を残す必要があります。

具体的に、どうやって「忘れる」のか

紹介した研究は、すべての業務に使える一つの実装を提示しているわけではありません。ただし、実験で使われた削除方法と、そこから導ける設計を組み合わせると、忘却は次の五つの処理に分解できます。

1. 書き込み前に落とす：Selective Addition

最初の方法は、不要な記憶を後から消すのではなく、そもそも利用可能な記憶へ昇格させないことです。

タスクが完了しただけでは、正しい経験とは限りません。外部ツールが偶然成功した、出力形式だけ合っていた、人が後から内容を修正した、といった場合があります。そこで実行結果を、まず「候補」として保存します。

実行結果
  → 候補として一時保存
  → 自動テスト・評価器・人の承認
  → 合格したものだけ検索対象へ追加

コード生成ならテストが通ったか、問い合わせ対応なら担当者が採用したか、データ更新なら更新後の状態が期待どおりかを確認します。失敗例を残す場合は、成功手順と同じ検索対象へ入れず、「避けるべき事例」として別の用途に限定します。

これは How Memory Management Impacts LLM Agents で検証されたSelective Additionに対応します。同研究では、各タスクの出力品質を確認してから記憶へ追加することで、誤りが次のタスクへ伝播するのを抑えています。

2. 使われない・役に立たない記憶を定期的に外す

同研究が試した削除方法は、二つの指標を組み合わせています。

一つは、一定期間に検索された回数です。論文の実験では、直近の期間に所定回数以上使われなかった記憶を、重複または低需要な候補として削除します。

もう一つは、過去にその記憶が検索された後の成績です。何度も検索されているのに、タスクの評価を改善していない記憶は、入力が似ているだけで役に立たない事例かもしれません。一定回数以上利用した記録について、平均的な効用が基準を下回れば削除します。

業務システムでは、たとえば次の値を記録できます。

last_retrieved_at   最後に検索された日時
retrieval_count     一定期間の検索回数
accepted_count      利用後に人が結果を採用した回数
failure_count       利用後に処理が失敗した回数
correction_count    人による修正が発生した回数

そして、次のようなルールを定期実行します。

90日間一度も使われていない
  → 検索対象から外して保管

10回以上使われ、採用率が20%未満
  → 無効化してレビュー対象へ

内容がほぼ同じ記憶が複数ある
  → 根拠を残して統合候補へ

日数や閾値は一律に決められません。年に一度だけ使う決算手順と、毎日使う問い合わせ手順では、利用頻度の意味が異なるためです。記憶の種類ごとに基準を持たせます。

物理削除を急ぐ必要もありません。まず検索対象から外し、問題がないことを確認した後で、保存期間や法的要件に従って削除します。

3. 新しい事実で古い事実を失効させる：版管理と無効化

担当者、予算、契約、社内規程のように変化する事実は、類似度だけで検索すると旧情報と新情報が同時に返ります。新しい情報を追加するとき、同じ対象・属性を表す古い記憶を探し、失効させます。

そのためには、本文と埋め込みベクトルだけでなく、次のようなメタデータを持たせます。

subject_key       何についての記憶か
property_key      どの属性・手順か
status            candidate / active / revoked / archived
valid_from        いつから有効か
valid_until       いつまで有効か
superseded_by     どの記憶に置き換えられたか
source_ids        根拠となった文書・実行履歴

たとえば「A社の請求書送付先」が変更されたら、新しい値を追加するだけでなく、以前の値を revoked にして、新しい記憶のIDを superseded_by に記録します。検索時には、ベクトル類似度を計算する前に、次の条件で対象を絞ります。

WHERE status = 'active'
  AND valid_from <= :now
  AND (valid_until IS NULL OR :now < valid_until)
  AND tenant_id = :tenant_id

古い記憶は監査用に残っていても、この条件を通らないため、現在の回答には使われません。これが「保存しているが、忘れている」状態です。

更新が明示的な訂正ではない場合は難しくなります。「最近は海外出張を控えている」という会話が、以前の「海外旅行が好き」という推薦用の記憶をどこまで無効にするかは、単純なキー一致では決められません。この種の暗黙的な矛盾は現在のメモリエージェントが苦手とする領域であり、重要な用途では人の確認へ回す必要があります。

4. 生の履歴と教訓を分け、統合を毎回行わない

Useful Memories Become Faulty When Continuously Updated by LLMs の実験では、エージェントに三つの操作を与えています。

• Retain：生の経験をエピソード記憶として残す
• Delete：不要な経験または記憶を外す
• Consolidate：複数の経験を抽象的な教訓へまとめる

毎回強制的にConsolidateさせる条件より、エージェントが操作を選べる条件や、エピソード記憶だけを管理する条件の方が良い結果を示しました。実際の設計でも、生の履歴と要約された教訓を別のストアにします。

エピソード記憶
  入力、操作、結果、評価を改変せず保存
          ↓ 複数の検証済み事例が集まったときだけ統合
抽象記憶
  共通手順、適用条件、例外、根拠のIDを保存

一件処理するたびに既存の手順書をLLMで書き換えるのではなく、次の条件がそろったときに統合します。

• 同じ種類の検証済み事例が複数ある
• 成功条件と失敗条件の両方を比較できる
• 作成した教訓を過去の事例で再テストできる
• 更新前の教訓を版として残し、切り戻せる

新しい教訓はすぐ本番で使わず、既存の評価セットで旧版と比較します。成績を悪化させた場合は昇格させません。LLMは教訓の候補を作れますが、自分で作った教訓の正しさを同じLLMの判断だけで確定しないことが重要です。

5. 取り出す段階で忘れる：検索時フィルタリング

記憶を保存してあることと、今回のプロンプトへ入れることは別です。検索では、ベクトル類似度の前後に制約を置きます。

権限・顧客・案件・有効期間で絞る
  → 類似する記憶を検索する
  → 最低類似度を下回るものを捨てる
  → 相互に矛盾する候補を検出する
  → 上位の少数だけをプロンプトへ入れる

該当する記憶がない場合は、無理に最も近い一件を返さず、「利用できる記憶なし」とします。似ているが条件の違う経験を使うより、記憶なしで処理する方が安全な場合があるためです。

権限による絞り込みも忘却の一種です。別の顧客や権限外の案件で得た経験は、データベースに存在していても、その利用者にとっては思い出せない状態にします。

忘却は、物理削除より前に始まる

以上を一つのライフサイクルにすると、次のようになります。

候補として保存
  → 品質を検証
  → 検索対象へ昇格
  → 利用実績を記録
  → 更新・低効用・期限切れを検知
  → 検索対象から無効化
  → 保管期限後に物理削除

個人情報の削除要求や保存期限の到来では、原文、要約、埋め込みベクトル、キャッシュ、バックアップなど、派生データも含めた物理削除が必要です。それ以外では、監査や原因調査のために履歴を保管しつつ、検索から除外する方が扱いやすい場合があります。

各記憶には、根拠、適用条件、版、状態、利用履歴を残します。そうすれば、記憶を使ったことで品質が上がったかを評価でき、問題があったときには利用を停止できます。

記憶の件数や検索回数だけをKPIにしても、エージェントが賢くなったかは分かりません。見るべきなのは、記憶を使ったタスクの成功率、修正率、再作業、誤った記憶の利用率、無効化までの時間です。

「全部覚えるAI」より、「根拠を残して忘れられるAI」

AIエージェントの記憶には価値があります。過去の成功を再利用し、利用者の繰り返しを減らし、業務固有の手順へ適応できます。

一方で、無条件に記憶を増やすと、誤りを増幅し、古い事実を現在へ持ち込み、不完全な一般則で判断を歪める可能性があります。正しい経験でさえ、要約と統合の過程で壊れることがあります。

必要なのは、記憶する機能だけではありません。

何を記録するか
何を検証してから使うか
どの条件で取り出すか
いつ無効化するか
何を根拠として残すか

これらを決めることが、エージェントの記憶設計です。

AIにとっての忘却は、能力の欠如ではありません。変化する業務の中で、現在も有効な情報だけを安全に使うための機能です。「すべてを覚えているAI」よりも、「根拠を残しながら、使うべきでない記憶を忘れられるAI」の方が、本番環境では信頼できるかもしれません。

研究結果を読む際の注意

紹介した研究のうち、ACL Findings 2026の論文を除く2本はプレプリントです。また、評価対象、記憶方式、モデル、タスクは研究ごとに異なります。

したがって、あらゆるエージェントで「記憶を増やすほど必ず性能が下がる」と結論づけることはできません。本記事の題名は、無制御な記憶の蓄積に対する問題提起です。

研究から一貫して読み取れるのは、記憶の追加が常に無害ではないこと、保存・統合・検索・無効化を分けて評価する必要があることです。実際の導入では、自社の業務履歴と失敗条件を使って検証する必要があります。

関連記事

• AIエージェントは経験から本当に成長するのか：ContinualSkillBenchを読む
• AIエージェントを業務システムにつなぐ前に決める、権限と自動実行の境界
• 生成AIの評価セットをどう作るか：業務で使えるLLM評価の設計

参考資料

• Useful Memories Become Faulty When Continuously Updated by LLMs
• How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior
• From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents
• ContinualSkillBench: Can LLM Agents Truly Evolve Their Capabilities?