AIの記憶には有効期限が必要だ

Databricksは2026年10月20日、Agent Memoryのベータ版を発表した。この発表が、今週このテーマを取り上げるきっかけとなった。

併せて発表されたMemCurrentの研究では、生のセッションと要点を抽出した記憶を分け、即時更新とバックグラウンドでの統合によって維持する。

製品として、より重要な問いはその先にある。覚えておく価値のあったことが、もはや事実ではなくなったらどうするのか。有用なアシスタントには継続性が必要だが、修正を伴わない継続性は、昨日の間違いをことさらに長く残してしまう。以下は設計に関する私たちの分析であり、このベータ版がここで述べる機能をすべて実装しているという主張ではない。

記憶には作成日以外の時間情報も必要だ

仮想のプロジェクト支援アシスタントを考えてみよう。月曜日、チームは金曜日にリリースすると伝える。水曜日になると、リリースは翌月に延期される。システムは月曜日の発言を完璧に検索できても、誤った答えを返すことがある。問題は情報の不足ではない。過去の記録を、現在も正しい認識として扱ってしまうことにある。

三つの時間軸を設けると、この違いを整理できる。システムがその事実を知ったのはいつか。どの期間に当てはまるはずだったのか。いつ再確認すべきか。旅行に関する好みは何年も役立つかもしれないが、一時的な配送先住所は旅行の終了とともに失効すべきだ。両者に同じ保存期間を適用するのは、保存する側の都合とユーザーの実際の生活を混同することになる。

したがって、有効期限が切れたときに変えるべきなのは、その情報を利用対象にできるかどうかであり、必ずしも履歴を直ちに消すことではない。古いリリース日にも、なぜその計画が立てられたのかを説明する役割は残る。ただし、たまたま質問と表現がよく一致するというだけで、新しい計画を再び左右するようになってはならない。

訂正は過去の記録に埋もれてはならない

二つ目の仮想例は、問題をさらに明確にする。あるユーザーが会議は午前中を好むと言い、その後、今後6週間は午後がよいと訂正したとする。有用な記憶は、その一時的な適用範囲を保ち、変更を以前の好みと結び付け、見直しを予定する。二つの発言を平均して一つの好みにまとめたり、一時的な例外を恒久的なものにしたりはしない。

訂正の有効性を、数の多さで決めてもいけない。過去の要約が10件あり、そのすべてに午前中を好むと書かれているかもしれない。それでも、明示的で、その状況に当てはまる訂正が一つあれば、そちらを優先すべきだ。繰り返しの多さは、ユーザーがどれほど強く支持しているかではなく、システムが発言を何回コピーしたかを示しているだけかもしれない。

ここから考えられるのは、認識をバージョン管理するモデルだ。現時点で採用する認識、その適用期間と文脈、そして置き換える認識との関係を持たせる。期間が終わったら、ユーザーが指定したその後の扱いに従うか、その好みを不確かなものとして扱うべきだ。沈黙だけでは、古いルールを復活させる十分な根拠にはならない。

重要なインターフェースは、次の何気ない会話である。訂正するたびにユーザーが設定画面を開き直さなければならないなら、記憶は、本来助けるはずだった人にメンテナンス作業を押し戻している。

管理責任を持つとは、食い違いを解決できることだ

ここでいう管理責任は、実務上の責任であり、法的な所有権の主張ではない。本人は自分の好みを訂正できる。プロジェクトの責任者は、その運営上の前提を修正できる。アシスタントによる推測は、そのどちらとも見分けられる形で示されるべきだ。同じデータベースに保存されていても、これらは異なる種類の認識である。

ユーザーが2回の招待を断ったことから、アシスタントがワークショップを嫌いなのだと推測したとしよう。それはあくまで暫定的な解釈にすぎない。後から要約するシステムがより断定的に書き直したというだけで、長く変わらない個人の特徴になってはならない。その認識を管理する人には、元になった出来事を否定しなくても、手間をかけずに推測を退けられる手段が必要だ。

そのため記憶のインターフェースでは、「残す」「指定した日まで使う」「置き換える」「使用をやめる」といった、理解しやすい選択肢を用意すべきだ。エクスポートにも、文章だけでなく意味が必要になる。古い認識を、すでに置き換えられたという状態を伴わずに別のアシスタントへ移すと、ユーザーが訂正済みの内容を復活させかねない。

保存にはメンテナンス費用が伴う

コストの問題は、保存するバイト数にとどまらない。残した認識の一つひとつが、将来の検索、矛盾の解消、見直し、そしてユーザーの注意を必要とする可能性がある。ストレージ自体が安価でも、蓄積量の増大はコストを生む。これらは設計上の考慮事項であり、特定製品について測定した結果ではない。

予算配分を考えるうえで有用な問いは、この記憶が将来のどんな作業を減らし、どんな間違いを生み得るか、というものだ。同じ編集ミスを繰り返し防ぐ指示なら、残す価値があるかもしれない。一度だけのレストランの提案は、継続的な好みにする必要はないかもしれない。完了した作業の根拠を保存することと、それを今後のあらゆる作業に読み込ませることは、別の判断である。

チームは、現在使う記憶、過去の文脈、使用を終えた認識を区別できる。現在使う記憶は、少数のよく手入れされた情報に絞る。過去の文脈は、質問が本当に過去について尋ねているときに利用できるようにしておく。使用を終えた認識は、バックグラウンド処理でインデックスが再構築されたというだけで、通常の検索対象に戻ってはならない。

削除についても、関連する運用上の検証が必要になる。ユーザーが推測から導かれた好みを削除した場合、翌日、古い会話から自動的に再生成されることはないか。製品はこれに明確な答えを持つ必要がある。今後の抽出を止めることと、元になる記録をすべて削除することは別の要求であり、説明なく一方をもう一方に置き換えてはならない。

思い出せるかだけでなく、変化に対応できるかを試す

LongMemEvalには、時間的推論、知識の更新、回答の見送りという評価項目が含まれる。Zepの2025年1月の論文は、過去の関係性を保持する時間的知識グラフを提案している。いずれも新しいDatabricksのベータ版を独立に検証したものではなく、別の研究上の背景を提供する資料である。

導入する側と開発する側にとって、ライフサイクルを確かめる簡潔なテストは、議論を具体化する助けになる。以下はすべて、提案する仮想的なテストであり、報告された顧客の事故事例ではない。

• 複数の要約に登場した後で、締め切りを変更する。次の計画は修正後の日付を使いながら、以前の判断がなされた理由は消さずに残すべきだ。
• 終了日のある一時的な好みを追加する。その後、アシスタントは明示された方針に従うか、確認すべきだ。恒久化や元の状態への復帰を勝手に決めてはならない。
• 推測された好みを直接訂正する。訂正は、元の推測のコピーよりも優先されるべきだ。古い資料から後日生成されたコピーも例外ではない。
• 先月は何を正しいと考えていたか、現在は何を正しいと考えているかを尋ねる。記録が変わった部分では答えが異なり、不確かな点も明示されるべきだ。
• 記憶の使用を終了し、検索インデックスを再構築し、古いエクスポートをインポートする。どの操作も、使用を終えた認識を黙って再び有効にしてはならない。
• 影響の大きい事実について、見直し期日を過ぎても未検証のままにする。アシスタントは確認するか、確認できていないことを示すべきだ。見慣れた情報であることを、新しさの証拠にしてはならない。

こうしたテストには、検索精度を超えた測定が必要になる。訂正が反映されるまでの遅れ、期限切れの記憶の使用、使用終了後の復活、忘れすぎによって生じる不要な質問などだ。すべてをユーザーに再確認させる設計なら、古い内容の断定を避けられるかもしれない。しかし、それでは記憶の利点も失われる。

役に立つ約束とは、修正できることだ

持続的な記憶の価値が最も高まるのは、ユーザーを過去の生活に縛り付けず、同じ説明を繰り返す手間から解放するときだ。製品が約束することは、理解しやすいものであるべきだ。今はこう認識している、これが当てはまるのはこの期間と状況であり、訂正すると次の行動がこう変わる、と。

エージェントの記憶がインフラになるにつれ、比較すべきなのは、実際に使う少数の情報を修正可能な状態で、どれだけ確実に維持できるかだ。ストレージ容量だけでは、次の判断でも訂正内容が優先されるかどうかは分からない。