7月24日、Toward Data ScienceのEmmimalが「Context Windows Forget What Matters — I Built a Usage-Reinforced Decay Engine for AI Agent Memory」と題した記事を公開した。この記事では、140年前の心理学研究「エビングハウス忘却曲線」をAIエージェントのメモリ管理に応用した、使用頻度強化型の減衰エンジンの設計と実装について詳しく紹介されている。
AIエージェントのメモリが抱える構造的欠陥
多くのAIエージェントは「スライディングウィンドウ」でコンテキストを管理している。N ターン以内に参照されなかった情報は問答無用で削除される仕組みだ。
この方式の問題は単純かつ根本的だ。ターン1で示された重要なシステム制約と、ターン40の使い捨てデバッグログを全く同等に扱う。どちらが「古いか」だけで判定するため、どれほど頻繁に参照された情報でもウィンドウ外に滑り出れば消える。
具体例を挙げる。150ターンのセッションで、ターン1にユーザーが「このライブラリのバージョンXを使うこと」「このファイルは絶対に編集しないこと」という重要ルールをエージェントに伝えたとする。エージェントは最初の30ターンで数回参照するが、その後100ターンはログ解析や別のタスクに費やす。後半でそのルールが必要になったとき——スライディングウィンドウはすでにそれを捨てている。
コーディングエージェントがこの問題でコードベースを壊す、カスタマーサポートBotがユーザーの問題をセッション途中で忘れる、RAGパイプラインが現在参照されていないという理由だけで核心的な事実を削る——こうした障害は例外も出さず、ただ静かに誤った回答を返す。
エビングハウス忘却曲線の応用
Emmimalが採用したのは、1885年にドイツの心理学者ヘルマン・エビングハウスが確立した忘却曲線の数式だ。エビングハウスは自分自身を被験者として無意味綴りの記憶実験を行い、「記憶は最初に急速に失われるが、復習のたびに忘却曲線が平坦化する」ことを示した。現代のスペース反復学習の基礎にもなっている概念である。
AIエージェントへのこの応用は完全な新規性ではなく、オープンソースプロジェクトのYourMemory（Mishra）はLoCoMoデータセットで比較メモリツール比約16ポイントの再現率改善を報告している（※元記事にGitHubリポジトリへの直接リンクの記載なし）。StanfordのGenerative Agents論文も類似アプローチを採用している（ただしrecency・importance・relevanceの組み合わせ）。
Emmimalの目標は「最小かつ完全決定論的な実装を自作し、基本的なスライディングウィンドウと比較し、破綻する正確な条件を特定すること」だったと述べている。
減衰エンジンの核心：数式と実装
各メモリアイテムは last_touched_turn、stability、recall_count の3値を持つ。経過ターン数 t でのリテンションスコアは：
Ret = e^(-t / S)
アイテムが参照されるたびに、stability が非線形に強化される：
S_new = S_old × (1 + ln(1 + recall_count))
リテンションスコアがデフォルト閾値 0.20 を下回ったとき初めてエビクション（削除）が発動する：
score = math.exp(-elapsed / item.stability) if elapsed > 0 else 1.0
if score < eviction_threshold:
evict(mem_id)
スライディングウィンドウの判定は単純比較だ：
if (current_turn - item.last_touched_turn) > window_size:
evict(mem_id)
4回参照されたアイテムは stability が約292に達し、0回のアイテム（S=8）が15ターンで閾値を下回るのに対し、950ターン以上生存できる。同じ数式・同じ閾値で、recall_countの差だけがこの差を生む。
ベンチマーク結果と正直な限界
**50セッションのシード固定テストで、減衰エンジンは Foundational Recall Rate 100%、スライディングウィンドウは0%**という結果が出た。ただしこれは「セッション序盤に導入され、その後複数回参照される重要情報」という特定条件下での比較であり、全面的な優位性を示すものではない点に注意が必要だ。
記事は「これは全面的に優れたメモリではない」と明示している。事実が一度だけ導入されて以降まったく参照されないケースでは、減衰エンジンとベースラインの性能は同一だ。recall_count が0のままでは stability は強化されず、通常の指数減衰と変わらない。
また実装は wall-clock時間を一切使わず、整数のターンカウンターのみで動作するため完全決定論的だ。2台の異なるマシン・OSで実行した出力はバイト単位で一致したという。
発見された2つのバグ
記事が詳しく解説している2つのバグは、実装上の教訓として有益だ。
バグ1：初期の baseline_stability = 2.0 では、登録直後のアイテムがターン3.22で閾値を下回る。最初の強化が行われる前にエビクションされてしまい、エンジン全体が機能しない。S = 8.0（約13ターンの猶予期間）に変更して解決した。
バグ2：合成セッション生成の初期実装で、ベンチマーク自体が最初から通過不可能な設計になっていた。具体的には、ベンチマーク用の合成セッションを生成するコードが「重要情報への参照イベント」をセッション内に埋め込まない構造になっており、減衰エンジンが強化対象とすべきアクセス履歴をそもそも受け取れない状態だった。結果としてどのアイテムも recall_count が増加せず、stability が強化されないまま閾値を下回り続けるため、エンジンとベースラインの挙動が区別できなかった。セッション生成ロジックに参照イベントを正しく挿入することで解決した。
Emmimalは「ベンチマーク数値を見て首をひねる前に、数式の挙動を先に検証する」というアプローチを強調している。
実装の全コードはGitHubリポジトリで公開されている。
詳細はContext Windows Forget What Matters — I Built a Usage-Reinforced Decay Engine for AI Agent Memoryを参照していただきたい。
