AI の長期記憶は、履歴から現在状態を再構成する

by

長期的に利用する AI には、過去の会話や出来事から得た情報を保持し、後の判断に利用する能力が求められる。ところが、記録として正しいことと、現在の判断材料として正しいことは一致するとは限らない。勤務先、予定、役割、利用中の機器、進行中の作業などは時間とともに変化し、そのたびに新しい状態が履歴へ追加される。過去の情報を保持するほど、現在も有効な事実と、過去のある時点でだけ有効だった事実が同じ記憶領域へ蓄積していく。

このとき必要になるのは、記憶量を増やすことに加えて、保存された情報がどの時点で成立し、現在の問いに対してどの情報を利用するかを判定する仕組みである。検索によって関連する記憶を取得できても、その情報が現在も有効とは限らない。長期記憶では、情報の存在、時間的な有効性、問い合わせとの関係を分けて管理する必要がある。

たとえば、ある人物が以前は A 社に勤務し、現在は B 社に勤務しているとする。「以前の勤務先はどこか」という質問には A 社という記録が必要であり、「現在の勤務先はどこか」という質問には B 社という記録が必要になる。A 社という記録は古くなったから誤りになったわけではない。A 社に勤務していた時点を尋ねる質問では、現在も正しい証拠として利用できる。一方、現在の勤務先を尋ねる場面で A 社を B 社と同じ候補として扱えば、過去の正しい記録が現在の誤答を生む原因になる。

ここには二つの処理がある。一つは、観測した事実を履歴として保存する処理である。もう一つは、その履歴から質問された時点に対応する状態を選び、回答に使う処理である。A 社の記録を削除すれば現在状態は単純になるが、過去の経歴を尋ねる質問へ答えるための証拠を失う。反対に、A 社と B 社を区別せず保持して回答へ投入すれば、履歴は保全できても現在状態の判定が不安定になる。履歴の保存と回答時の利用を別の処理として扱うことで、過去を失わずに現在状態を確定できる。

2026 年 9 月に公開された Fortunate Recall と RD-Forget は、この問題を異なる方向から具体化した。Fortunate Recall は、記憶ごとに時間減衰、有効期間、同じ対象について後から得られた値との置換関係などを持たせ、記憶そのもののライフサイクルを管理する。RD-Forget は、保存された履歴と回答時に利用する記憶集合を分け、質問ごとに必要な情報を選び直す。前者は記憶側から有効性を管理し、後者は問い合わせ側から利用範囲を構成するという違いがある。

両者を合わせて見ると、AI の長期記憶で管理する対象が明確になる。保存されている事実の数だけでなく、その事実がいつ成立し、何によって更新され、どの質問に対して利用されるかという関係まで管理対象になる。長期記憶は「保存」から「有効性管理」へ設計範囲を広げつつある。

1. AI が覚えている事実は、現在も正しいとは限らない

長期記憶を考えるとき、最初に分けるべきなのは「その情報が保存されているか」と「その情報が現在の問いに使えるか」である。保存は、過去に観測した事実を後から参照できる状態に保つ処理である。有効性は、その記録を特定の時点と質問に対する判断材料として採用できるかを表す。保存された事実が増えるほど、この二つを区別する必要性も大きくなる。

勤務先の変更を例にすると、A 社勤務という記録と B 社勤務という記録は、どちらも履歴上の事実として保存できる。しかし、二つの記録が表している状態は同時には成立していない。A 社勤務という記録には A 社に在籍していた期間があり、その後 B 社への転職によって現在状態が更新されている。記憶領域に両方が存在すること自体に矛盾はなく、どの時点の状態として読むかによって利用すべき記録が変わる。

「2024 年時点の勤務先」を尋ねるなら、質問に含まれる時点を基準として A 社の記録を選べる。「現在の勤務先」を尋ねるなら、同じ対象について後から成立した B 社の記録を現在状態として選ぶことになる。つまり、記憶項目へ固定的な真偽を一つだけ割り当てるより、事実が成立した時刻、後続の更新、問い合わせが要求する時点を組み合わせて有効性を判定する方が、履歴と現在状態の双方を保持できる。

記録 保存する理由 現在の質問での扱い 歴史的な質問での扱い
以前の勤務先 A 社 過去の経歴と状態変化を保持するために必要である。 現在の勤務先を尋ねる場合は、後続の B 社勤務を現在状態として優先する。 A 社に在籍していた期間を尋ねる場合は有効な証拠になる。
現在の勤務先 B 社 A 社から更新された現在状態を表すために必要である。 現在の勤務先を尋ねる場合は主要な証拠になる。 B 社への転職後の時点を尋ねる場合に有効になる。
来週の出張予定 将来の行動計画と予定された状態変化を保持するために必要である。 予定日までの期間では将来予定として利用し、実施後は結果の記録と照合する。 実施後には、その時点で予定されていた内容を確認する履歴として参照できる。
撤回された指示 判断履歴と方針変更の経緯を追跡する用途がある。 現在の行動規則には後続の指示を適用し、撤回済みの指示は現在状態から外す。 過去の判断理由や方針変更の経緯を確認する場合に参照できる。

これらの例では、記録を残す価値と、現在の判断へ使う価値がそれぞれ異なる。以前の勤務先や撤回された指示は、現在状態を直接決める材料としての優先度を失っても、履歴としての意味を保つ。将来予定は予定日が近づく間は判断材料になり、実施後には過去の計画として位置付けが変わる。同じ記録でも、時間の経過と後続イベントによって役割が変化する。

この構造を持つ長期記憶では、「古い情報を持つか捨てるか」という二択だけでは状態を十分に表現できない。必要なのは、観測した記録を履歴として保持したうえで、現在時刻、対象となる期間、後続の更新、質問の意図を使って、その場で有効な記憶集合を構成することである。記憶の保存量が増えるほど、性能を左右する中心は保存能力から、履歴の中から現在有効な状態を再構成する能力へ移っていく。

2. 長い履歴をそのまま渡しても長期記憶にはならない

長期記憶を実現する最も単純な構成は、過去の会話や記録をできるだけ多くモデルのコンテキストへ含めることである。必要な情報が入力の中に残っていれば、外部記憶から検索する処理を省き、そのまま回答へ利用できる。しかし、入力可能な長さが増えることと、その内部にある情報を必要な場面で正確に利用できることは異なる。履歴が長くなるほど候補となる記述が増え、モデルは質問に関係する情報を見つけるだけでなく、複数の候補から現在の判断に適したものを選ぶ必要がある。

Lost in the Middle は、長い入力の中に必要な情報が含まれていても、その配置によって利用性能が変化することを示した[1]。関連情報が入力の先頭や末尾に置かれた場合と、中間に置かれた場合では回答性能に差が生じる。これは、コンテキストへ情報を格納できる容量と、その情報へ均等にアクセスできる能力が一致しないことを意味する。履歴を長くするほど記録の欠落は減らせる一方、必要な記録を安定して利用するという別の課題が大きくなる。

長期会話では、さらに時間関係と状態変化が加わる。LoCoMo は最長 32 セッション、平均約 600 ターンからなる長期会話を用いて、複数の会話をまたいだ記憶能力を評価した[2]。ここでは単一の発言を検索するだけでなく、異なる時点の出来事を結び付け、時間的な順序や因果関係をたどる必要がある。会話履歴が蓄積すると、同じ人物や対象について異なる時点の情報が複数存在するため、関連する記述を取得した後に、それらの関係を解釈する処理が必要になる。

LongMemEval は、この長期記憶の負荷をさらに分解して評価している。対象には、単一セッション内の情報検索、複数セッションをまたぐ推論、時間推論、後から更新された知識の利用、必要な情報が存在しない場合に回答を控える判断が含まれる[3]。500 問からなる評価では、商用チャットアシスタントや長文脈 LLM に長期間の対話履歴を与えた場合、記憶能力が約 30% 低下したと報告されている[3]。履歴の保持量を増やしても、更新前後の情報を区別し、質問が要求する時点の事実を選び、根拠が不足する場合には回答を抑制する能力まで自動的に得られるわけではない。

研究 主な評価対象 明らかになった制約 長期記憶への示唆
Lost in the Middle 長い入力内に置かれた関連情報の利用性能を評価する。 必要な情報が入力内に存在していても、その位置によって利用性能が変化する。 コンテキスト容量の拡大だけでは、保存された情報へ安定してアクセスできるとは限らない。
LoCoMo 複数セッションにまたがる長期会話で、時間関係や因果関係を含む記憶能力を評価する。 履歴が長期化すると、異なる時点の出来事を結び付けて解釈する処理が必要になる。 長期記憶には情報検索に加えて、時系列と状態変化を解釈する仕組みが必要になる。
LongMemEval 情報検索、複数セッション推論、時間推論、知識更新、回答抑制を分けて評価する。 長期間の対話履歴では記憶能力が約 30% 低下し、特に更新や時間を含む判断が負荷になる。 長期記憶は保存量だけでなく、更新関係、有効時点、回答可否まで管理する必要がある。

3 つの研究が扱う失敗は異なるが、共通しているのは「情報が入力や履歴の中に存在すること」と「その情報を適切に利用できること」の間に隔たりがある点である。Lost in the Middle は入力内での位置、LoCoMo は長期間にまたがる時間関係、LongMemEval は知識更新や回答抑制まで含めて、この隔たりをそれぞれ測定している。

長期会話では、現在も有効な情報、過去のある期間だけ有効だった情報、後から更新された情報、将来の予定、撤回された指示が同じ履歴へ蓄積する。たとえば、勤務先について A 社、B 社という記録が順番に現れた場合、「勤務先」に関連する記述としては両方が検索対象になる。ここで必要なのは、二つの情報の意味的な関連度を比較する処理に加えて、どちらが質問された時点に対応するかを判断する処理である。

履歴内の状態 検索時に起きること 回答時に必要な追加判断
現在も有効な情報 質問との意味的関連性が高ければ候補として取得される。 現在状態としてそのまま利用できるかを確認する。
過去に有効だった情報 意味的には現在情報と同程度に関連する場合がある。 質問が現在を対象とする場合は後続の更新を優先する。
更新された情報 更新前と更新後の両方が候補として取得される場合がある。 同じ対象の状態変化として関係付け、質問時点に対応する値を選ぶ。
将来の予定 関連する話題として検索される。 予定、実施済み、取消済みのどの状態にあるかを判定する。
撤回された指示 現在の指示と同じ語を含むため検索候補になり得る。 後続の撤回や変更を確認し、現在の行動規則から除外する。

このため、長期記憶の性能はコンテキスト長だけでは決まらない。履歴を保持する容量が増えると参照可能な過去は広がるが、それと同時に、候補情報の識別、時系列の解釈、更新関係の判定、利用する事実の選択という処理も増える。長いコンテキストは情報を残すための基盤になり、その上で「保存された履歴のどこを現在の判断へ使うか」を決める仕組みが必要になる。

この段階で、長期記憶の設計対象はモデルへ渡せる履歴量から、履歴をどこへ保存し、どの情報を検索し、どの状態を回答へ利用するかという管理機構へ広がる。

3. 長期記憶はモデルの外へ広がってきた

長い履歴をそのままコンテキストへ入れる方式では、入力可能な情報量を増やせても、必要な記録を安定して選び、時間関係や更新関係を解釈する処理まで解決できるとは限らない。この制約から、LLM エージェントの記憶研究は、モデル内部のコンテキストを唯一の記憶領域とする構成から、履歴をモデル外へ保存し、必要な情報を選択的に取り出す構成へ広がってきた。

この変化によって、長期記憶はモデルの能力だけで決まる機能から、独立したシステム設計の対象へ変わる。LLM エージェントの記憶研究を整理したサーベイでは、何を保存するか、どの形式で保持するか、どのように検索するか、取得した記憶を推論へどう利用するかといった記憶モジュールの設計、評価、応用が整理されている[4]。2026 年の別のサーベイは、この発展を「保存」「反省」「経験」という段階で捉え、履歴をそのまま保持する方式から、過去の記録を整理し、後続の判断へ利用可能な形へ再構成する方式へ進んでいると整理している[5]。

初期の重要な変化は、モデルが保持している知識と、モデル外から取得する知識を分けたことである。RAG は外部の文書集合から質問に関連する情報を検索し、その結果を生成時の根拠として利用する基本構造を示した[6]。この構成によって、モデルのパラメータにすべての情報を保持させる代わりに、必要な情報を外部から取得して一時的にコンテキストへ取り込めるようになる。

エージェントへ適用すると、外部記憶は一般知識の検索先だけでなく、エージェント自身の経験を保持する領域になる。Generative Agents は、行動や会話を自然言語の記憶として蓄積し、現在の状況に関連する記憶を検索するとともに、複数の経験から上位の「反省」を生成する構成を示した[7]。ここでは記憶が単なるログから、後続行動を決めるための材料へ変わっている。

MemGPT はさらに、有限のコンテキストと外部記憶の関係を階層的な記憶管理として整理した[8]。現在の推論に必要な情報をコンテキスト内へ置き、それ以外を外部へ退避し、必要に応じて読み戻す。入力上限を単純に拡張する代わりに、限られたコンテキストを作業領域として管理し、長期的な履歴を別の層へ保持する構成である。

研究・方式 記憶の主な役割 モデル外へ出したもの 次に残る課題
RAG 質問に関連する外部知識を検索し、生成の根拠として利用する。 モデルのパラメータだけでは保持しきれない文書知識を外部検索対象として持つ。 検索された情報同士の更新関係や時間的な有効性は別途扱う必要がある。
Generative Agents エージェント自身の経験を保存し、検索と反省によって後続行動へ利用する。 過去の行動、会話、観測を継続的な経験記録として保持する。 蓄積した経験の重複、更新、矛盾をどのように管理するかが課題になる。
MemGPT 有限コンテキストと長期記憶を階層として管理する。 現在の推論に不要な情報を外部記憶へ退避し、必要時に読み戻す。 取得した情報のうち、現在の状態としてどれを優先するかを判断する必要がある。

外部へ保存するだけでは、記憶量の増加に伴って新たな管理問題が生じる。長期間運用すると、同じ対象について複数の記録が追加され、似た内容の重複、後続情報による更新、重要度の低下、記憶同士の関連付けが必要になる。このため、研究の焦点は「保存場所を作る」段階から、「保存された記憶をどう更新し、整理するか」という段階へ進んだ。

MemoryBank は、記憶の重要度と時間経過を使い、利用される記憶を強化しながら、時間とともに記憶の重みを低下させる仕組みを導入した[9]。これは、保存されたすべての記憶を同じ優先度で扱う方式から、時間と利用状況によって検索時の影響を変える方式への移行である。

Mem0 は、会話をそのまま長期保存するだけでなく、そこから長期的に必要な情報を抽出し、既存記憶との関係を考慮して統合し、後続の問い合わせに応じて検索する構成を採る[10]。履歴の全文を検索対象とするより、エージェントが再利用する事実を記憶単位として切り出すことで、長期運用時の検索対象を整理する。

A-MEM は、個々の記憶を孤立した項目として保存する構成から一歩進み、Zettelkasten の考え方を取り入れて記憶同士を動的に関連付ける[11]。新しい記憶が追加されると、既存記憶との関係を作り、必要に応じて既存項目の表現も更新する。これにより、記憶集合そのものが追加順に蓄積するログから、関連性を持つ構造へ変化する。

MemoryOS は、短期・中期・長期という複数の記憶層を設け、記憶の利用状況や性質に応じて階層間を移動させる[12]。現在の会話で頻繁に使う情報と、長期間保持する個人情報を同じ領域へ置く代わりに、それぞれの役割に応じた管理方法を持たせる構成である。

Memory-R1 は、さらに記憶管理の操作自体を学習対象へ含める。ADD、UPDATE、DELETE、NOOP という操作を選択し、既存記憶をそのまま増やすだけでなく、新しい情報によって既存項目を更新するか、削除するか、変更を加えないかを判断する[13]。これによって、記憶管理は検索アルゴリズムだけの問題から、状態を変更する方策の問題へ広がる。

方式 追加された管理機能 記憶集合に対する操作 解決対象
MemoryBank 時間経過と重要度に応じて記憶の影響度を変える。 記憶の強化と減衰を行う。 長期間保存された記憶を同じ優先度で検索することによる候補増加を抑える。
Mem0 会話から長期的に必要な事実を抽出し、既存記憶と統合する。 抽出、統合、検索を行う。 生の会話履歴をそのまま蓄積することによる重複や検索対象の肥大化を抑える。
A-MEM 記憶同士の関連付けと既存表現の更新を行う。 追加、リンク生成、既存項目の更新を行う。 個別記憶が孤立したまま増えることを避け、関連する経験を構造化する。
MemoryOS 短期・中期・長期の記憶階層を管理する。 記憶を階層化し、利用状況に応じて更新する。 性質の異なる記憶を同じ保存領域と同じ規則で扱う負荷を減らす。
Memory-R1 記憶操作の選択自体を学習する。 ADD、UPDATE、DELETE、NOOP を選択する。 新しい観測を既存状態へどのように反映するかを方策として扱う。

これらの研究を並べると、長期記憶の設計対象が段階的に増えていることが分かる。最初はモデルへ渡せる履歴量が中心だった。外部記憶が導入されると保存場所と検索方法が設計対象になり、さらに運用期間が長くなると、追加、更新、削除、関連付け、階層化まで管理する必要が生じる。

発展段階 主な設計対象 解こうとしている問題 次に生じる課題
長文脈 より多くの履歴を一度にモデルへ渡す。 有限コンテキストによる情報欠落を減らす。 長い履歴の中から必要な情報を安定して選ぶ必要がある。
外部記憶 履歴をモデル外へ保存し、必要な情報を検索する。 長期間の経験を保持しつつ、推論時の入力サイズを抑える。 記憶量の増加に伴う重複、更新、矛盾を管理する必要がある。
動的な記憶管理 追加、更新、削除、リンク、階層化を制御する。 蓄積された記憶を再利用しやすい状態へ維持する。 検索された複数の事実のうち、現在の問いに有効なものを判定する必要がある。
有効性管理 時刻、置換関係、質問意図に応じて利用可否を決める。 過去の正しい事実が現在の判断へ誤って利用されることを防ぐ。 履歴の保存と回答時の利用を分離した状態管理が必要になる。

この発展で注目すべき点は、記憶管理が「保存するか」という判断から、「どのような状態として保存し、いつ更新し、どう検索するか」という判断へ広がっていることである。しかし、追加、更新、削除を適切に行っても、検索された記憶が現在の問いに対して有効かという判定は残る。

たとえば、過去の勤務先 A 社と現在の勤務先 B 社が正しく保存され、同じ人物に関する記憶として関連付けられていたとしても、「現在の勤務先はどこか」という質問に対してどちらを使うかは別の処理になる。検索システムから見れば両方とも「勤務先」に関連する正しい記憶である。回答時には、時刻と更新関係を使って B 社を現在状態として選ぶ必要がある。

長期記憶研究は、履歴をコンテキストへ詰め込む段階から、外部へ保存し、整理し、更新する段階まで進んできた。その先で設計対象になるのが、検索された記憶の有効性である。

4. 検索できることと、現在正しいことは別である

外部記憶を検索できるようになると、次に必要になるのは、取得した記憶をそのまま回答へ使ってよいかという判定である。ベクトル検索は、質問と記憶の意味的な近さを使って候補を選ぶ。たとえば「現在の勤務先はどこか」と尋ねた場合、過去の A 社勤務と現在の B 社勤務は、どちらも「勤務先」という概念に強く関連する。そのため、意味的な関連度だけを評価すれば、両方が有力な検索結果になり得る。

しかし、回答時に必要なのは意味的な関連性だけではない。A 社勤務という記録は過去のある期間では正しく、B 社勤務という記録はその後の期間で正しい。「現在の勤務先」という質問では、同じ意味領域に属する複数の記録から、質問された時点に対応する B 社を選ぶ必要がある。検索は「何についての記憶か」を絞り込み、有効性判定は「その記憶をいつの状態として使うか」を決める。

評価軸 判定する内容 A 社勤務 B 社勤務
意味的関連性 質問と記憶が同じ対象や話題に関係するかを判定する。 「勤務先」という質問に強く関連する。 「勤務先」という質問に強く関連する。
時間的有効性 質問された時点で、その記憶が成立しているかを判定する。 過去の在籍期間では有効だが、現在状態では後続の記録に置き換わっている。 現在の在籍期間を表す記録として有効である。
質問意図 現在、過去、将来のどの状態を回答対象とするかを判定する。 「以前」「2024 年時点」などの質問では回答候補になる。 「現在」「今」などの質問では回答候補になる。

この差は、検索精度を高めるだけでは解消できない。A 社と B 社の両方を高精度に取得できたとしても、その後に時系列と更新関係を解釈する処理がなければ、現在状態は確定しない。検索性能が向上するほど、関連する過去記録まで正確に取得できるため、回答時には複数の正しい記録から一つの有効状態を選ぶ処理が必要になる。

時間によって変化する事実を言語モデルで扱う研究は、この問題を以前から扱ってきた。Time-Aware Language Models は、知識ベースに含まれる事実へ時間情報を導入し、同じ対象について時点によって答えが変化する状況を扱った[14]。人物の役職、組織への所属、政治的地位などは、対象そのものが同じでも時間によって正しい値が変わる。この場合、質問と事実の意味的な対応に加えて、質問時点と事実が成立した期間の対応が必要になる。

Zep は、この時間性を AI エージェントの長期記憶へ持ち込み、時間付き知識グラフとして扱う[15]。会話や業務データから得られた人物、組織、出来事、関係をグラフとして保持し、それぞれの関係に時間情報を持たせることで、関係がいつ成立し、いつ変化したかを履歴として表現する。単に「A と B に関係がある」という記録を残すより、「どの期間にどの関係が成立していたか」を保存する構成である。

方式 主な対象 時間の扱い 長期記憶への意味
Time-Aware Language Models 時間によって変化する知識を言語モデルで扱う。 事実と時点を結び付け、同じ問いでも対象時点によって答えを変える。 事実の正しさを対象と時間の組み合わせとして扱う必要性を示す。
Zep AI エージェントが蓄積する会話や業務上の関係を管理する。 関係に時間情報を持たせ、状態変化を履歴として保持する。 現在状態と過去状態を同じ記憶基盤から参照できるようにする。

この考えを長期個人記憶へ適用すると、記憶項目には本文だけでなく、その事実がいつ観測されたか、どの期間で成立するか、同じ対象について後からどの記録が追加されたかという情報が必要になる。たとえば「A 社に勤務している」という文だけを保存するより、A 社勤務の開始時点と終了時点、B 社勤務への更新を関連付けて保存する方が、過去と現在の両方へ答えやすくなる。

記憶に必要な情報 役割 不足した場合に起きること
記憶本文 何について観測した記録かを表す。 検索対象となる内容そのものを保持できない。
発生時刻 出来事や事実がいつ観測されたかを表す。 複数の記録の時間的な順序を判定しにくくなる。
有効期間 その事実がどの期間で成立するかを表す。 過去の正しい記録と現在の正しい記録を区別しにくくなる。
更新関係 同じ対象について後続の記録が以前の状態を更新したことを表す。 古い値と新しい値が独立した記憶として並び、現在状態を確定しにくくなる。
質問意図 現在、過去、将来のどの状態を回答対象とするかを決める。 同じ記憶集合から質問に対応する時点を選べなくなる。

検索結果を作る処理も、この時間情報と無関係ではいられない。意味的に近い記憶を広く取得した後、時点と更新関係で絞り込む構成もあれば、検索時点から時間条件を加えて候補を制限する構成も考えられる。どちらの場合でも、意味的関連性と時間的有効性を同じ指標として扱うより、別の評価軸として組み合わせる方が、履歴と現在状態を両立しやすい。

長期記憶の処理は、ここで少なくとも三つの層に分かれる。保存層は過去の観測を残し、検索層は質問に関係する候補を取得し、有効性判定層は時刻、更新関係、質問意図を使って今回の回答に参加させる記憶を決める。

処理層 主な役割 勤務先の例
保存層 観測した履歴を継続的に保持する。 A 社勤務と B 社勤務の両方を記録する。
検索層 質問と意味的に関連する記憶候補を取得する。 「勤務先」に関連する A 社と B 社の記録を取得する。
有効性判定層 時点、更新関係、質問意図から回答へ使う記憶を選ぶ。 「現在」という条件に基づき B 社を現在状態として選ぶ。

この構造まで分けると、検索できることと正しく答えられることの間に何が不足しているかが明確になる。外部記憶によって必要な履歴を保持し、検索によって関連情報を取得できても、現在有効な記憶を決める処理がなければ、過去の正しい事実が現在の誤答へつながる。

5. Fortunate Recall は記憶にライフサイクルを持たせる

2026 年 9 月 9 日に公開された Fortunate Recall は、前章で整理した有効性判定を「記憶のライフサイクル管理」として具体化した研究である[16]。対象は個人に関する事実であり、保存されたすべての記憶へ同一の規則を適用する代わりに、事実の性質、時間経過、後続の更新、質問との関係に応じて扱いを変える。これにより、記憶を検索できるかという問題と、その記憶を現在の回答へ利用できるかという問題を分けて処理する。

個人に関する情報には、同じ管理規則を適用しにくいものが混在する。生年月日のように長期間変化しにくい情報がある一方、勤務先や役職は後続の出来事によって更新される。予定には将来の発生時刻があり、その時刻を過ぎると現在の予定から過去の出来事へ位置付けが変わる。Fortunate Recall は、この違いを記憶項目の属性として明示し、それぞれに適したライフサイクルを与える。

そのために、Fortunate Recall は個人事実を 10+1 種類の行動的オントロジーへ分類する[16]。分類結果は単なるラベルとして保存されるのではなく、時間減衰、同じスロットに属する記憶の置換、イベント時刻による有効性、カテゴリー別の検索ルーティングと結び付く。分類によって「この記憶をどの規則で管理するか」を決める構成である。

管理要素 判定する内容 長期記憶での役割 勤務先や予定への適用例
行動的オントロジー その事実がどの種類のライフサイクルを持つかを分類する。 記憶ごとに適用する管理規則を選ぶ。 勤務先のような更新される属性と、予定のような時刻依存の情報を異なる規則で扱う。
時間減衰 時間経過によって検索時の利用優先度をどの程度変えるかを決める。 時間が経過した記憶が現在の回答へ与える影響を調整する。 一時的な情報は時間経過に応じて優先度を下げる。
スロット単位の置換 新しい記録が同じ対象の以前の状態を更新するかを判定する。 過去の値を履歴として残しながら、現在状態として後続の値を優先する。 A 社勤務の後に B 社勤務が追加された場合、B 社を現在の勤務先として扱う。
イベント時刻 記憶に含まれる出来事がいつ成立するかを判定する。 現在、将来、過去という時間的位置付けに応じて利用方法を変える。 来週の出張予定を予定日までは将来情報として扱い、実施後は履歴として扱う。
検索ルーティング 質問に対してどの種類の記憶を検索対象とするかを決める。 すべての記憶を同じ条件で検索するより、質問に対応する候補集合を絞る。 現在状態を尋ねる質問と過去の出来事を尋ねる質問で検索対象を変える。

設計上の特徴は、これらの処理を LLM の自由な判断だけへ委ねていない点にある。LLM は記憶からカテゴリーや時間などのメタデータを抽出するが、その後の減衰、置換、有効性判定には規則として定義されたポリシーを適用する。自然言語から構造化情報を取り出す処理と、その情報に基づいて記憶の状態を変更する処理を分ける構成である。

この分離には、長期運用での意味がある。たとえば「B 社へ転職した」という記録を得たとき、LLM に毎回「A 社と B 社のどちらを現在状態として採用するか」を文章生成として判断させる構成では、問い合わせごとに解釈が変わる余地がある。勤務先という同一スロットへの後続値として B 社を登録し、規則に従って現在状態を更新すれば、同じ履歴に対して同じ置換関係を再利用できる。LLM が意味を抽出し、ポリシー層が状態遷移を管理するという役割分担になる。

評価では、FR-Bank が LifecycleBench 516 問で 76.9% の通過率を示した[16]。比較対象となった Mem0、A-MEM、Memory-R1、MemoryOS は 61% から 70.5% の範囲であり、FR-Bank はこの評価で最も高い値を記録している。LongMemEval-S でも 75.2% を記録した[16]。

正答率だけでなく、誤った内容を補って回答する confabulation も評価されている。回答を生成した質問だけを対象とすると、Mem0 の 45.1% に対して Fortunate Recall は 22.4% だった。回答を控えた質問も含む全質問では、32.2% から 13.0% へ低下したと報告されている[16]。この評価では、ライフサイクルを管理する構成で confabulation の低下が併せて観測されている。

評価 Fortunate Recall 比較対象 読み取れること
LifecycleBench FR-Bank は 516 問で 76.9% の通過率を記録した。 Mem0、A-MEM、Memory-R1、MemoryOS は 61% から 70.5% の範囲だった。 ライフサイクルを明示的に管理する構成が、この評価条件では比較対象を上回った。
LongMemEval-S 75.2% を記録した。 長期記憶を評価する別のベンチマークでも性能を確認している。 LifecycleBench 固有の評価だけでなく、別の長期記憶評価でも結果を確認している。
回答済み質問の confabulation 22.4% だった。 Mem0 は 45.1% だった。 回答を生成した場合に、記憶から十分に支えられない内容を補う割合が低下した。
全質問の confabulation 13.0% だった。 Mem0 は 32.2% だった。 回答を控える判断を含めても、誤った内容を出力する割合が低下した。

ただし、この結果だけから、10+1 種類の詳細なオントロジーが正答率向上の中心要因だったとは判断できない。Fortunate Recall は、この点を確認するためにオントロジーを外すアブレーションも行っている。10+1 の分類を 3 種類の一般的なライフサイクル属性へ置き換えた場合、正答率の差は -1.7 ポイントで、95% 信頼区間は -6.0 から +2.7 だった[16]。この区間には 0 が含まれるため、正答率について詳細なオントロジー固有の効果を明確に切り分ける結果にはなっていない。

一方、confabulation には差が現れている。一般的なライフサイクル属性へ置き換えた構成では 24.2% だったのに対し、オントロジーを利用する構成では 12.0% だった[16]。正答率と confabulation を分けて読むと、ライフサイクル管理そのものと詳細な分類の役割を区別できる。

比較項目 詳細な 10+1 オントロジー 一般的なライフサイクル属性 解釈
正答率 基準となる構成である。 差は -1.7 ポイント、95% 信頼区間は -6.0 から +2.7 だった。 詳細な分類自体による正答率の改善は、この結果から統計的に明確とは言えない。
confabulation 12.0% だった。 24.2% だった。 詳細な分類は、矛盾する記憶の扱いや回答の校正に寄与する可能性がある。
共通して残る機構 時間、置換、有効性をライフサイクルとして管理する。 より一般化した属性で同様のライフサイクルを管理する。 正答率を支える要因を考える際には、詳細な分類とライフサイクル管理を分けて評価する必要がある。

このアブレーションから読み取れる範囲では、Fortunate Recall の成果を「記憶を 10+1 種類へ細かく分類したから正しくなった」と説明するのは適切ではない。より基礎にあるのは、記憶へ時間、置換関係、有効期間といったライフサイクル情報を持たせ、それを回答時の利用条件へ反映する構造である。詳細なオントロジーは、その基盤の上で記憶の種類を区別し、矛盾解消や回答の校正を補助する位置にある。

Fortunate Recall によって、前章で分けた保存層、検索層、有効性判定層のうち、有効性判定を記憶側の属性と規則として実装する方法が見えてくる。過去の記録を保存しながら、新しい値による置換、時間経過、イベント時刻を使って、現在の回答へ参加する記憶を調整する構成である。

ただし、ここでは依然として「管理された記憶集合から何を今回の質問へ使うか」という処理が残る。記憶項目に適切なライフサイクル情報が付いていても、現在状態を尋ねる質問と歴史的な状態を尋ねる質問では利用する証拠が変わる。

6. RD-Forget は保存する記憶と使う記憶を分ける

同じ 2026 年 9 月 9 日に公開された RD-Forget は、Fortunate Recall とは別の方向から長期記憶の有効性を扱う[17]。Fortunate Recall が記憶項目へライフサイクル情報を持たせるのに対し、RD-Forget は「保存されている記憶」と「今回の回答に使う記憶」を分離する。過去の観測を保持する source archive を正本として残し、その中から質問ごとに query-conditioned memory view を構成する。

この分離によって、古い記録を保存する価値と、現在の回答へ参加させる価値を別々に管理できる。たとえば、A 社から B 社へ転職した履歴では、A 社勤務も B 社勤務も過去に観測された事実として保存する。一方、「現在の勤務先はどこか」という質問では B 社を回答時ビューへ残し、「2024 年の勤務先はどこか」という質問では A 社を再び利用する。保存層を変更せず、質問に応じて利用する証拠集合だけを変える構成である。

構成要素 保持する情報 回答時の役割 勤務先の例
source archive 過去に観測された元の記録を履歴として保持する。 現在質問と歴史質問の双方で参照できる正本になる。 A 社勤務と B 社勤務の両方を残す。
意味スロット 複数の記録が同じ属性について述べていることを表す。 更新前後の記録を比較する単位を作る。 A 社と B 社を同じ「勤務先」というスロットへまとめる。
置換関係 後続の値が以前の状態を更新した関係を保持する。 現在状態を尋ねる場合に新しい値を優先する。 B 社勤務が A 社勤務より後の状態であることを表す。
質問条件付け 質問が要求する時点や対象を解釈する。 現在、過去、期間指定などに応じて利用する記憶を変える。 「現在」と「2024 年時点」を区別する。
memory view 今回の質問に必要な証拠だけを一時的に集める。 LLM へ渡す回答用の記憶集合になる。 現在質問では B 社を中心にし、歴史質問では A 社を含める。

処理の中心になるのが、同じ意味スロットに属する記録の整理である。長期記憶では、同じ対象について異なる時点の値が複数蓄積する。勤務先、住所、役職、利用機器、好みなどは、後続の観測によって更新される可能性がある。RD-Forget は、これらを独立した記憶として並べるだけでなく、同じ属性に属する値としてまとめ、どの記録がどの記録を置き換えたかを利用する。

この処理によって、現在質問と歴史質問で同じ記憶集合を使い回す必要がなくなる。「現在の勤務先」を尋ねる場合は、勤務先スロットの中で後続の B 社を優先する。「以前の勤務先」や特定の過去時点を尋ねる場合は、A 社という記録を回答時ビューへ戻す。A 社の記録そのものを削除していないため、現在状態を整理した後でも過去について回答できる。

質問 source archive 回答時に優先する記憶 利用を抑える記憶
現在の勤務先はどこか A 社勤務と B 社勤務の両方を保持する。 後続の現在状態である B 社勤務を優先する。 置換前の A 社勤務が現在回答へ与える影響を抑える。
以前の勤務先はどこか A 社勤務と B 社勤務の両方を保持する。 過去状態である A 社勤務を回答候補へ戻す。 現在状態である B 社だけに回答が偏ることを避ける。
2024 年時点の勤務先はどこか 時系列を含む勤務履歴を保持する。 2024 年という指定時点に対応する記録を選ぶ。 指定時点の後に成立した状態の影響を抑える。

RD-Forget は単一属性の更新だけを扱う構成でもない。回答に複数の事実が必要な場合には、それらの関係を保持したまま回答時ビューへ含める。たとえば、ある人物がどこへ転職したか、その転職後にどの都市へ移ったかという質問では、勤務先と居住地という複数の事実を時系列に沿って結び付ける必要がある。古い記憶を一律に抑える方式では、この関係まで失う可能性があるため、質問への回答に必要な証拠関係を残す処理が必要になる。

さらに RD-Forget は、回答時に利用できる記憶量へ上限がある状況を率歪みの考え方で扱う[17]。ここで「率」は回答へ渡す記憶量に対応し、「歪み」は必要な情報を削ったことで回答能力がどの程度損なわれるかに対応する。目的は履歴全体を均一に短くすることではなく、限られた記憶予算の中で質問に必要な証拠をできるだけ残すことである。

観点 RD-Forget での意味 回答時に求められること
記憶量 回答時ビューへ含められる情報量には上限がある。 質問との関係が薄い記憶を減らし、必要な証拠へ容量を割り当てる。
情報損失 記憶を減らしすぎると、回答に必要な事実や関係まで失われる。 回答結果を支える情報を保持したまま不要な情報の影響を抑える。
質問条件 必要な記憶は質問ごとに変わる。 固定的な要約ではなく、問い合わせに応じて記憶ビューを作り直す。
履歴保持 回答時ビューから外れた記憶も source archive には残る。 後続の別の質問で必要になった記録を再利用できる状態を保つ。

この構成では、圧縮や忘却の基準が質問から独立して固定されない。ある質問では不要だった記録が、別の質問では主要な証拠になる。A 社勤務は現在の勤務先を答える場面では影響を抑える対象になるが、過去の経歴を尋ねる場面では保持すべき情報へ変わる。RD-Forget が質問条件付きの記憶ビューを作る理由は、この役割の変化に対応するためである。

実験では、会話記憶、知識更新、事実統合、長文脈推論、個人化を共通の回答パイプラインで評価している[17]。アブレーションでは、忘却処理または質問条件付けを外した構成で大きな性能低下が生じたと報告されている。保存された記憶を減らす処理だけでも、質問に関連する記憶を検索する処理だけでも十分ではなく、質問に応じて何を残し、何の影響を抑えるかを決める組み合わせが性能に関与している。

評価対象 必要になる記憶処理 RD-Forget が扱う点
会話記憶 長い履歴から質問に関係する過去の発言を選ぶ。 source archive から質問条件付きの証拠集合を作る。
知識更新 更新前と更新後の値を区別する。 同じ意味スロットの置換関係を使って現在状態を選ぶ。
事実統合 複数の記録を組み合わせて回答を作る。 必要な事実間の関係を保持したまま memory view へ含める。
長文脈推論 大量の候補から回答に必要な証拠を絞る。 限られた記憶量へ必要な情報を優先して残す。
個人化 過去の利用者情報から現在有効な状態を選ぶ。 更新された個人情報と履歴情報を質問に応じて使い分ける。

ここでいう「忘却」は、保存されたデータを物理的に消去する処理より広い。source archive では履歴を保持し、回答時には質問に不要な記憶の影響を抑える。現在の推論に参加しない記憶でも、別の質問では再び利用できる。この意味で RD-Forget の忘却は、情報の存在を消す操作というより、回答時の可視性と影響度を制御する操作として設計されている。

この区別は、プライバシー上の削除や誤記録の訂正とも切り分けられる。利用者から削除を求められた情報や保持根拠を失った情報では、source archive からの物理削除が必要になる場合がある。一方、過去の正しい履歴を保持しながら現在の回答から外したい場面では、推論上の忘却が機能する。保存ポリシーと回答時の利用ポリシーを別々に持つことで、二つの要件を分離できる。

Fortunate Recall が「記憶にどのようなライフサイクル情報を持たせるか」を主に扱ったのに対し、RD-Forget は「保存された履歴から今回どの記憶を使うか」を主に扱う。前者は記憶項目側の状態管理であり、後者は回答時の状態構成である。

7. 二つの研究は保存と利用を分ける設計へ収束する

Fortunate Recall と RD-Forget は、同じ仕組みを別名で提案した研究ではない。Fortunate Recall は、各記憶へライフサイクル情報を持たせ、時間経過や更新関係に応じて記憶項目側の状態を管理する。RD-Forget は、保存された履歴を維持したまま、質問ごとに回答へ使う記憶集合を構成する。前者は「記憶をどの状態で保持するか」を扱い、後者は「保持された記憶を今回どのように使うか」を扱っている。

両者の違いを残したまま並べると、共通する設計原理が見える。過去に観測した事実を保存する処理と、その事実を現在の判断へ参加させる処理を分離することである。履歴として保存する価値がある情報でも、現在の回答では影響を抑える場合がある。反対に、現在の回答から外した記憶でも、歴史的な質問では再び主要な証拠になる。保存可否と利用可否を別々に扱うことで、履歴の保持と現在状態の確定を両立できる。

観点 Fortunate Recall RD-Forget 設計上の位置
主な対象 記憶項目そのものの状態とライフサイクルを管理する。 質問ごとに回答へ利用する記憶集合を構成する。 前者は保存側、後者は利用側を主に扱う。
時間の扱い 時間減衰、イベント時刻、有効期間を記憶へ持たせる。 現在状態と歴史的な質問に応じて、古い証拠の利用可否を変える。 時間を記憶の属性と質問条件の両側から扱う。
更新の扱い 同じスロットの後続値によって現在状態を更新する。 同じスロットの置換関係を使い、回答時に古い値の影響を抑える。 更新前の値を履歴として残しながら、現在状態を確定する。
検索・選択 カテゴリーとライフサイクルに基づいて検索対象と優先度を決める。 質問条件に応じて memory view を構成する。 意味的関連性だけでなく、有効性と質問意図を使って回答候補を絞る。
最終的な役割 保存された記憶を、時間と更新関係を持つ状態として管理する。 その状態から、今回の回答に必要な証拠だけを取り出す。 履歴から質問時点の有効状態を再構成する。

勤務先の例へ戻すと、この役割分担を具体的に確認できる。A 社勤務の後に B 社勤務が記録された場合、Fortunate Recall の考え方では、両者を同じ勤務先スロットに属する記憶として関連付け、B 社を後続の現在状態として扱うためのライフサイクルを管理する。RD-Forget の考え方では、その履歴を保持したまま、「現在の勤務先」という質問では B 社を回答時ビューへ残し、「以前の勤務先」という質問では A 社を再び利用する。

処理段階 Fortunate Recall が主に担う処理 RD-Forget が主に担う処理 勤務先の例
記録 記憶の種類や時間情報を付与する。 元の観測を source archive に保持する。 A 社勤務と B 社勤務を履歴として残す。
更新 同じスロットの後続値として現在状態を更新する。 置換関係として更新前後を保持する。 B 社勤務が A 社勤務より後の状態であることを表す。
検索 カテゴリーとライフサイクルを使って候補を取得する。 質問に関連する証拠を source archive から選ぶ。 勤務先に関する A 社と B 社の記録を候補へ含める。
回答 現在有効な記憶へ高い優先度を与える。 質問条件付きの memory view を作る。 現在質問では B 社、過去質問では A 社を回答へ使う。

この構造は、既稿で扱ってきたコンテキスト管理とも接続する。「AI に自身の文脈を持ち運ぶ」では、恒久ルール、準恒久方針、更新型コンテキスト、時点記録を分け、情報の寿命と更新方法に応じて保存場所を分離した[18]。時点記録は過去のある時点を再現するために価値を持ち、更新型コンテキストは現在状態を表す。両者を同じものとして扱うより、履歴と現在状態を別の情報として管理する方が後続の判断へ利用しやすい。

「AI による大規模開発では、未確定な状態を一件ずつ閉じる」では、会話履歴そのものより、後続作業がそのまま利用できる確定状態を外部へ残すことを扱った[19]。長い会話の中には、提案、検討中の案、却下された案、確定した仕様が混在する。履歴をすべて保存していても、後続の AI が現在の仕様を判断できなければ作業状態は安定しない。履歴と現在の確定状態を分離することで、次の処理が参照すべき情報を明確にする。

さらに「AI に仕事を任せるには、モデルの外側を設計する」では、保存領域と作業領域を分け、モデルへ毎回すべての情報を投入する代わりに、現在の判断へ必要な情報を選択して参加させる構造を扱った[20]。保存領域は履歴や根拠を保持し、作業領域はその時点の処理に必要な状態を表す。今回の 2 研究は、この分離を長期記憶機構の内部へ適用している。

既稿・研究 保存するもの 現在利用するもの 共通する構造
AI に自身の文脈を持ち運ぶ 恒久ルール、方針、更新型コンテキスト、時点記録を役割別に保持する。 現在状態には更新型コンテキストを利用する。 情報の寿命と用途によって保存と利用を分ける。
AI による大規模開発では、未確定な状態を一件ずつ閉じる 検討や変更の履歴を保持する。 後続作業には確定した状態を渡す。 履歴そのものと、次工程が利用する状態を分ける。
AI に仕事を任せるには、モデルの外側を設計する モデル外へ履歴や根拠を保存する。 現在の作業に必要な情報だけをモデルへ参加させる。 保存領域と作業領域を分離する。
Fortunate Recall 時間と更新関係を持つ記憶を保持する。 ライフサイクルに基づいて現在有効な記憶を優先する。 履歴を保持したまま現在状態を管理する。
RD-Forget source archive に元の観測を保持する。 質問条件付きの memory view を構成する。 保存された履歴から、その場で必要な状態を導出する。

これらは扱っている対象が異なる。既稿では、コンテキストファイル、開発状態、モデル外部の作業環境を対象としてきた。Fortunate Recall と RD-Forget は、その同じ分離原理を AI の長期記憶そのものへ適用している。共通するのは、履歴を正本として保持することと、現在の処理へ利用する状態をその都度明確にすることである。

この分離が必要になる理由は、履歴が増えるほど「正しいが現在は使わない情報」が増えるためである。以前の勤務先、終了した予定、撤回された指示、変更前の仕様はいずれも過去の記録としては正しい。それらを削除すれば履歴を失う一方、現在状態と同じ優先度で利用すれば後続の判断へ古い状態が混入する。保存と利用を分けることで、履歴の完全性と現在判断の一貫性を同時に維持できる。

ここまでをまとめると、AI の長期記憶は少なくとも四つの段階へ分解できる。まず観測した事実を保存し、次に時間や更新関係を記録する。その上で質問に関連する候補を検索し、最後に現在の問いへ有効な証拠だけを回答時の状態として構成する。Fortunate Recall は主に二段目までを精緻化し、RD-Forget は三段目から四段目を中心に扱っている。

段階 処理内容 主な問い 対応する考え方
履歴保存 観測した事実や出来事を記録として保持する。 何を後から参照できるように残すか。 source archive、外部記憶、時点記録。
状態管理 時間、有効期間、更新、置換関係を記録する。 どの記録がどの時点の状態を表すか。 Fortunate Recall のライフサイクル管理。
候補検索 質問に意味的に関連する記憶を取得する。 どの履歴が今回の質問に関係するか。 検索ルーティング、意味検索。
回答時状態構成 時点と質問意図に応じて利用する証拠を確定する。 今回の回答には何を使うか。 RD-Forget の query-conditioned memory view。

この構造で捉えると、AI の長期記憶を「大量の事実を保存する箱」と考える必要はなくなる。保存されている情報は履歴であり、回答時に必要なのは、その履歴から質問された時点に対応する状態を構成することである。記憶の量より、履歴から現在有効な状態を導出できるかが長期運用を左右する。

8. AI の記憶は履歴から現在状態を再構成する仕組みになる

ここまで見てきた構造は、AI 固有の発想だけで成立しているわけではない。情報システムでは以前から、時間とともに変化する状態を一つの現在値へ上書きする方法だけでなく、変更履歴を残したまま必要な時点の状態を取り出す方法が使われてきた。AI の長期記憶も、保存された事実を蓄積する仕組みから、履歴を材料として質問時点の状態を再構成する仕組みとして捉えると、既存の状態管理技術との対応が見えやすくなる。

データベース分野では、時間とともに変化する事実を扱うために temporal database という考え方が発展してきた[21]。その代表的な考え方では、事実が現実世界で成立していた時間と、その事実がデータベースへ記録されていた時間を区別する。たとえば「A 社に勤務していた」という事実について、A 社に実際に在籍していた期間と、その情報がシステムへ登録された日時は別の時間軸になる。

この区別を持つと、現在の値だけを保存する場合より多くの問いへ答えられる。「現在の勤務先はどこか」という問いには最新の有効状態を返し、「2024 年時点の勤務先はどこか」という問いには、その時点で有効だった記録を返せる。さらに、登録が遅れた情報や後から訂正された情報も、現実世界の時間とシステム上の記録時間を分けることで追跡できる。

時間情報 表すもの 勤務先の例 AI 長期記憶での役割
事実が成立した時間 現実世界でその状態が有効だった期間を表す。 A 社に在籍していた期間、B 社に在籍している期間を表す。 現在質問と歴史的な質問で利用する記憶を切り替える。
記録された時間 その情報がシステムへ登録または更新された時点を表す。 B 社への転職情報を AI がいつ取得したかを表す。 後から取得した情報や訂正された情報の履歴を追跡する。
置換された時間 以前の状態が現在状態としての役割を終えた時点を表す。 B 社勤務の開始によって A 社勤務が過去状態へ移る。 複数の正しい記録から現在有効な状態を確定する。

Fortunate Recall が扱うイベント時刻、有効期間、置換関係も、この種の時間付き状態管理として理解できる。記憶本文だけを保存する場合、「A 社勤務」と「B 社勤務」は二つの関連記録として並ぶ。時間と置換関係を加えると、A 社から B 社へ状態が変化した履歴として表現できる。検索対象は同じでも、質問時点に応じて利用する値を変えられる。

ソフトウェア設計の Event Sourcing も近い構造を持つ。Event Sourcing では、現在状態だけを更新して保存する代わりに、状態を変化させた出来事をイベント列として保持し、その履歴から現在状態や過去状態を再構成する[22]。たとえば現在の勤務先として B 社という値だけを保存する代わりに、「A 社へ入社した」「A 社を退職した」「B 社へ入社した」という変更履歴を保持すれば、現在状態だけでなく途中の状態も再現できる。

この方式では、現在状態は履歴そのものではなく、履歴へ一定の規則を適用して得られる結果になる。新しいイベントが追加されるたびに状態を更新でき、過去のある時点までのイベントだけを適用すれば、その時点の状態も再構成できる。AI の長期記憶でも、保存された観測と状態変化を履歴として残し、質問に応じて必要な状態を導出するという構造を採れば、現在質問と歴史的な質問を同じ記憶基盤から扱える。

観点 Temporal Database Event Sourcing AI の長期記憶
正本として保持するもの 時間情報を持つデータを保持する。 状態を変化させたイベント列を保持する。 観測した事実、出来事、更新関係を履歴として保持する。
現在状態の得方 現在時刻で有効なデータを選ぶ。 イベント列を適用して現在状態を再構成する。 時間、更新関係、質問意図から有効な記憶を選ぶ。
過去状態の得方 指定時点で有効だったデータを取得する。 指定時点までのイベントを適用する。 歴史質問に対応する過去の記憶を回答時ビューへ戻す。
履歴を残す理由 時間変化した事実を追跡する。 状態変化の経緯を再現する。 過去の質問、現在の質問、状態変化の説明へ同じ履歴を利用する。

3 者は同じ技術ではないが、履歴と現在状態を分離する点で共通する。現在状態だけを保存すると参照は単純になる一方、過去の状態や変更理由を復元するための情報を別途保持する必要が生じる。履歴を正本として残し、現在状態を導出する構成では、保存量や再構成処理は増えるが、時間によって変化する状態を一貫した記録として扱える。

AI の長期記憶では、さらに質問意図が状態再構成へ加わる。同じ履歴を持っていても、「今どうなっているか」「以前どうだったか」「いつ変わったか」「変更前後で何が違うか」によって必要な証拠集合が異なる。Temporal Database が時点を指定してデータを取り出し、Event Sourcing がイベント列から状態を再構成するのと同様に、AI の記憶では質問が必要とする時点と関係に応じて回答用の状態を構成する。

質問 必要になる処理 利用する履歴 回答時に構成する状態
現在の勤務先はどこか 最新の有効状態を確定する。 A 社勤務と B 社勤務の更新履歴を参照する。 B 社を現在状態として採用する。
以前の勤務先はどこか 現在状態より前の有効状態を取得する。 置換前の A 社勤務を履歴から取得する。 A 社を過去状態として回答へ利用する。
いつ勤務先が変わったか 二つの状態をつなぐ変更時点を特定する。 A 社勤務の終了と B 社勤務の開始を参照する。 状態遷移そのものを回答対象にする。
転職前後で何が変わったか 複数時点の状態を比較する。 勤務先以外の役職、所在地、業務など関連する履歴も取得する。 変更前後の状態をそれぞれ再構成して比較する。

AI の記憶を人間の記憶になぞらえる研究も存在する。人間の感覚記憶、短期記憶、長期記憶などの分類と AI の記憶機構を対応付け、その設計への示唆を整理したサーベイもある[23]。人間の記憶を参考にすることで、忘却、統合、重要度、経験からの一般化といった研究課題を整理できる。

一方、Fortunate Recall と RD-Forget が直接操作している対象を見ると、中心にあるのは情報システムとしての状態管理である。Fortunate Recall は、記憶へ時間、カテゴリー、置換関係、有効期間を持たせる。RD-Forget は、source archive から質問条件付きの memory view を作る。両者が扱っているのは、人間がどのように記憶を想起するかという認知過程そのものより、保存された情報から回答に必要な状態をどのように選ぶかという処理である。

構成要素 保持・判定する内容 必要になる理由
履歴 過去に観測した事実や出来事を保持する。 過去状態の参照、変更経緯の説明、後からの再評価に利用する。
時間 事実がいつ成立し、どの期間で有効だったかを表す。 同じ対象について存在する複数の正しい記録を時点ごとに区別する。
置換関係 どの記録がどの記録を更新したかを表す。 履歴を残したまま現在状態を確定する。
問い合わせ 現在、過去、将来、期間、変更過程のどれを求めているかを判定する。 同じ履歴から質問ごとに異なる証拠集合を選ぶ。
回答時ビュー 今回の質問に必要な証拠だけを集めた状態を作る。 古い記録や無関係な履歴が現在の推論へ与える影響を抑える。

この構造で見ると、長期記憶の性能を「どれだけ覚えているか」だけで測ると、履歴保存の能力しか評価できない。実際のエージェントでは、その履歴から質問に対応する状態を再構成する処理まで含めて初めて記憶が機能する。大量の履歴を保持できても、更新前の値と更新後の値を区別できなければ現在質問へ正しく答えられない。反対に、古い値をすべて削除すれば、歴史的な質問や変更経緯の説明に必要な証拠を失う。

Fortunate Recall と RD-Forget の共通点は、この二者択一を避けるところにある。Fortunate Recall は、記憶へライフサイクルを付与し、古い記録を履歴として保持しながら現在の利用優先度を変える。RD-Forget は、保存された source archive を維持したまま、質問ごとの memory view で古い記録の影響を制御する。過去を残すことと、現在の判断を新しい状態へ合わせることを別々の操作として扱っている。

AI の長期記憶で管理すべき対象は、保存された事実の量だけではなく、その事実がいつ成立し、何によって更新され、どの質問に対して有効なのかという関係である。過去を履歴として保持しながら、時間、更新関係、質問意図に応じて回答時の状態を再構成する。この仕組みを持つことで、長期記憶は過去を多く保存する機能から、履歴を現在の判断へ正しく接続する状態管理へ広がる。

参考文献

  1. Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023). https://arxiv.org/abs/2307.03172
  2. Adyasha Maharana et al., Evaluating Very Long-Term Conversational Memory of LLM Agents (2024). https://aclanthology.org/2024.acl-long.747/
  3. Di Wu et al., LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory (2025). https://openreview.net/forum?id=pZiyCaVuti
  4. Zeyu Zhang et al., A Survey on the Memory Mechanism of Large Language Model based Agents (2024). https://arxiv.org/abs/2404.13501
  5. Jinghao Luo et al., From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms (2026). https://aclanthology.org/2026.findings-acl.2069/
  6. Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). https://arxiv.org/abs/2005.11401
  7. Joon Sung Park et al., Generative Agents: Interactive Simulacra of Human Behavior (2023). https://arxiv.org/abs/2304.03442
  8. Charles Packer et al., MemGPT: Towards LLMs as Operating Systems (2023). https://arxiv.org/abs/2310.08560
  9. Wanjun Zhong et al., MemoryBank: Enhancing Large Language Models with Long-Term Memory (2024). https://doi.org/10.1609/aaai.v38i17.29946
  10. Prateek Chhikara et al., Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory (2025). https://arxiv.org/abs/2504.19413
  11. Wujiang Xu et al., A-MEM: Agentic Memory for LLM Agents (2025). https://arxiv.org/abs/2502.12110
  12. Jiazheng Kang et al., Memory OS of AI Agent (2025). https://arxiv.org/abs/2506.06326
  13. Sikuan Yan et al., Memory-R1: Enhancing Large Language Model Agents to Manage and Utilize Memories via Reinforcement Learning (2026). https://aclanthology.org/2026.acl-long.583/
  14. Bhuwan Dhingra et al., Time-Aware Language Models as Temporal Knowledge Bases (2021). https://arxiv.org/abs/2106.15110
  15. Preston Rasmussen et al., Zep: A Temporal Knowledge Graph Architecture for Agent Memory (2025). https://arxiv.org/abs/2501.13956
  16. Ansuman Mullick, Eray Tüzün, Fortunate Recall: Ontology-Driven Memory Lifecycle Management for Persistent Coherence in LLMs (2026). https://arxiv.org/abs/2609.10413v1
  17. Yuhang Li, Yuchen Li, What Should an Agent Forget? Separating What Is Stored from What Is Used (2026). https://arxiv.org/abs/2609.10263v1
  18. id774, AI に自身の文脈を持ち運ぶ（2026-05-04）. https://blog.id774.net/entry/2026/05/04/4675/
  19. id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
  20. id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
  21. Christian S. Jensen, Richard T. Snodgrass, Temporal Database (2009). https://doi.org/10.1007/978-0-387-39940-9_395
  22. Martin Fowler, Event Sourcing (2005). https://www.martinfowler.com/eaaDev/EventSourcing.html
  23. Yaxiong Wu et al., From Human Memory to AI Memory: A Survey on Memory Mechanisms in the Era of LLMs (2025). https://arxiv.org/abs/2504.15965