前の希望を覚えていても、今回の依頼を間違える

資料作成を助けるAIが「この利用者は短い説明を好む」と記憶しているとする。 ところが今回は、利用者が「新入社員向けなので、背景から詳しく説明してほしい」と頼んだ。 過去の好みを正しく検索できても、それを今回の明示的な依頼より優先すると、役に立たない資料になる。これは記憶設計を考えるための想定例である。

問題は、思い出した内容が合っているかだけではない。 誰についての情報か、いつの判断か、今の作業にも適用するかを決める必要がある。 本稿は、2026年4月8日までの研究と実装資料を手掛かりに、記憶の検索、適用、更新を分けて考える。

検索方式と、記憶の適用範囲は別に選べる

「ベクトル検索」と「短期・長期・共有の記憶」は、対立する方式ではない。 ベクトル検索は、意味の近い候補を探す方法である。短期や長期は保持期間、共有は利用範囲に関わる分類であり、同じシステムで組み合わせられる。 ファイルに保存した記憶を検索することもできるため、保存形式と検索方式も区別したい。

LangGraphの説明は、スレッド内の会話を追う記憶と、会話を越えるユーザーやアプリの情報を分け、長期ストアの例でユーザー別のnamespaceを使っている。 これは、検索前に対象の範囲を選ぶ実装例として参考になる。 ただし、namespaceという名前を付けるだけでアクセス制御が成立するわけではなく、呼び出した人がその範囲を読めるかは別に保証する必要がある。

先ほどの資料なら、個人の好み、今回の依頼、組織の正式な執筆規則を区別して扱う。 同じデータベースでも、対象、出所、適用条件を持たせる方法はある。 物理的な保存先を増やすこと自体を目的にせず、判断に必要な区別を復元できるようにする。

訂正は、次の検索まで待たせない

利用者が「今後は詳しい説明を基本にして」と訂正したなら、今回限りの指示とは扱いが異なる。 記憶を更新する場合は、その変更が今後の希望なのか、特定の資料だけの条件なのかを残したい。 曖昧な一回の行動から、恒久的な好みを推定して上書きすると、別の作業まで影響が広がる。

私の提案は、明示的な訂正を現在の作業にすぐ反映し、長期保存の整理が後から走る場合にも、古い要約が訂正を上書きしないようにすることだ。 原発言や出所、更新対象、適用開始時点を記録し、最新の保存時刻だけで内容の優先順位を決めない。 昨日の会話を今日要約した記録は、今日の訂正より古い事実を含み得るからである。

グラフに関係を持たせても、この更新規則は必要である。 関係を明示できることと、その関係が正しく現在も有効であることは別だ。 グラフ、ベクトル検索、構造化レコードの優劣は、同じ更新課題と費用条件で試して判断する。

共有記憶では、検索とは別に書き込みが競合する

複数のエージェントが同じプロジェクトメモを編集すると、片方の更新が失われる場合がある。 Lettaの共有記憶の説明は、追記、部分置換、全面書き換えを区別し、複数の全面書き換えでは後の書き込みが勝つ問題を挙げている。 これは、その更新操作の仕様に由来する問題であり、共有記憶が常に失敗するという意味ではない。

たとえば、Aが期限を直す一方で、Bが古いメモに担当者を追記して全体を保存すると、Aの期限変更が消える。 この想定例では、変更対象を限定する、保存前に版を照合する、全面編集の担当を一人にする、といった対処を比較できる。 検索の精度を上げても、保存時に消えた変更は取り戻せない。

覚えた事実、訂正、答えない判断を別々に試す

LongMemEvalは、情報抽出、複数セッションの推論、時間の推論、知識の更新、回答を控える能力を評価対象にしている。 長期対話の記憶を、単に似た記録が見つかったかだけで評価しない研究例である。 この分類は参考になるが、個別の業務で特定の記憶方式が最良だと証明するものではない。

資料作成の例なら、過去の好みを聞く質問、今回だけ異なる指示、将来の好みを変える訂正、記録にない希望をそれぞれ試す。 回答とともに、何を保存し、何を読み、どの条件を適用したかを確認する。 記憶がない場合にも質問できるか、推測を事実として保存しないかまで見ると、追加すべき処理を絞り込める。

公開資料の例数だけから、ある構成が最も普及し、最も安く、最も正確だとは言えない。 ここで勧めるのは、必要な記憶を増やす前に、どの失敗を直すのかを特定することだ。 読み落とし、古い条件の適用、誤保存、競合による消失では、直す場所が異なる。