覚えてくれたはずのAIが、今回の依頼を間違える
資料作成を助けるAIに、毎回同じ好みを説明するのは面倒だ。 「説明は短めに」と一度伝えた希望を、翌日も使ってくれるなら仕事は始めやすい。 ところが、新入社員向けの資料を頼んで「今回は背景から詳しく」と伝えても、以前の好みを優先して短くまとめられたらどうだろう。 記憶の内容は正しくても、できた資料は依頼に合わない。これは記憶設計を考えるための想定例である。
この失敗は、検索精度だけでは直せない。 過去の希望、現在の依頼、組織の規則を、それぞれどの仕事へ適用するか決める必要がある。 さらに、希望が変わったときに何を書き換え、古い要約をいつ使わなくするかまで考えなければ、昨日の便利さが今日の誤りになる。
本稿は2026年4月8日までに公表された実装と研究を比較し、記憶を、情報を探す仕組みと、情報を有効な判断材料に保つ仕組みに分けて考える。 会話の状態、継続する好み、共有する記録を分ける理由は、それぞれの読み方、更新者、保持期間が違うからだ。 物理的な保存先を増やすことより、この違いを失わないことを重視する。
検索で見つけることと、仕事へ適用すること
外部資料を検索して回答へ渡すRAGは、モデルの入力に必要な情報を補う。 同じ検索を会話履歴や個人の記録へ使うこともできる。 ただし、文書に書かれた製品仕様を読むことと、利用者の過去の希望を今回の依頼へ適用することでは、確かめる条件が異なる。
「説明は短めに」という記録が見つかったとき、検索は似た情報を返しただけかもしれない。 その希望が誰のものか、どの資料についての発言か、今も続くのかは、記録の出所と条件から判断する必要がある。 ベクトル検索の類似度を、そのまま指示の優先順位にしてしまうと、よく似た古い希望ほど強く適用される恐れがある。
そこで、ベクトル検索、構造化した記録、グラフ、人が読めるファイルを別の判断として比べたい。 ベクトル検索は候補を探す方法、構造化記録は項目を明示する表現、グラフは関係を持たせる表現、ファイルは保存と編集の形式である。 ファイルを検索することも、グラフから取った情報を会話へ入れることもできる。 これらを一列の優劣へ並べると、検索の失敗と更新の失敗を区別できなくなる。
会話の状態と、次の会話でも使う情報を分ける
LangGraph v0.2の発表は、実行の段階ごとに状態を保存するチェックポイントを説明している。 これは、会話の途中や処理の中断から再開するための記録である。 一方、長期記憶の発表は、会話を越えて文書を保存、取得、検索するストアと、利用者や組織ごとの保存区分（namespace）を示した。 同じ「覚える」でも、止まった処理を戻すことと、次の仕事へ知識を渡すことは別の目的を持つ。
たとえば、作成中の資料の見出しと未完了の段落は、今回の仕事の状態である。 来月の別の資料へ、そのまま指示として持ち込む必要はない。 逆に、利用者が明示した継続的な希望は、今回の会話が終わっても使いたい。 保存期間だけでなく、再開のための記録か、別の仕事へ引き継ぐ判断材料かで分けると、何を読み込むべきかが明確になる。
今回の作業状態
依頼、途中の判断、進捗、成果物の版を保持する。現在の仕事へ適用し、再開する際は外部の保存結果も照合する。
個人の継続記憶
本人が続けたいと示した好みや事実を保持する。対象者、出所、適用する仕事、訂正を記録する。
組織の正式な規則
用語、承認条件、保持期限などを管理する。利用者の好みとは更新者と適用する権限を分ける。
共有する作業記録
担当、期限、根拠、未解決事項を引き継ぐ。誰がどの項目を更新したかと、競合の扱いを決める。
この四分類は本稿の設計例であり、四つのデータベースを必須にするものではない。 同じ保存先でも、情報の種類と適用条件を持たせれば区別できる。 namespaceも整理の単位であって、名前を付けただけで読み書きの許可を保証しない。 呼び出した人がその記録を扱えるかは、別に確認する必要がある。
記録を要約するほど、何を失ったかが重要になる
会話のすべてを毎回入力すれば、記録を選ぶ手間は小さく見える。 しかし、入力が増えるほど、今回に関係する条件と古い指示が同じ場所に並ぶ。 要約して量を減らすなら、今度は、対象や期限を落としても意味が変わらないかを確かめる必要がある。
記憶を加工する発想は、検索を追加するだけの設計より広い。 Generative Agentsは、経験の記録から抽象度の高い振り返りを作り、行動の計画へ使った。 評価対象は仮想環境の人物らしい振る舞いであり、業務の事実管理の正しさとは区別する。 MemGPTは、限られた入力の内外で情報を移動させる記憶管理を、文書分析と複数回の会話で検討した。
これらから本稿が重視するのは、記録を残すことと、モデルへ見せる情報を作ることの分離である。 元の発言は検証のために残し、短い要約は利用のために作る、と分ければ、要約が誤ったときに出所へ戻れる。 ただし、そのために保存量や処理が増える。 短い一回の相談なら、要約を育てる仕組みを追加せず、今の会話だけを扱う方が簡単な場合もある。
冒頭の希望も、「短い説明を好む」とだけ圧縮すると、資料の種類や例外を失い得る。 「通常の進捗報告は短め。ただし新人向け資料は背景を詳しく」と記録できれば、今回の依頼との関係を読み取りやすい。 これは要約方式の性能結果ではなく、残す条件によって適用判断が変わる想定例である。
グラフとファイルは、違う更新の問題を扱う
A-MEMは、記憶を属性のあるノートとして作り、関連する記憶を結び、新しい情報によって既存の記憶も更新する方式を提案した。 Zepの論文は、会話と業務情報を時間を扱う知識グラフへ統合する構成を示している。 どちらも、追加した記録を後から検索するだけでなく、記録同士の関係を整理する研究例である。
関係と時点を持てれば、同じ顧客の担当者変更や、以前の条件と現在の条件を別の事実として扱いやすくなる。 一方、抽出した人物や関係が誤っていれば、構造が整っていても判断は誤る。 関係の生成、訂正、失効に必要な処理まで含めて、元の記録を読む方式と比べる必要がある。 各論文のモデル、評価課題、比較対象が違うため、ここから方式の一律な順位は作れない。
Letta CodeのContext Repositoriesの発表は、別の性質を持つ。 記憶をローカルのファイルとGitの版で扱い、必要な内容を段階的に読み込む設計である。 人が差分を読み、どの説明を変更したかを調べたい仕事では、この編集可能性が選定材料になる。 ただし、Gitで変更履歴を持てることは、変更後の内容が正しいことの保証ではない。
顧客と契約の関係を追う仕事と、開発規約を読み直して訂正する仕事では、優先する扱いやすさが違う。 前者では関係と有効時点、後者では人が確認できる差分が重要になり得る。 保存形式を先に決めるより、誰が何を訂正するかを先に置くと、必要な複雑さを選びやすい。
訂正を、古い要約で上書きしない
利用者が「この資料だけ詳しく」と言う場合と、「今後は詳しい説明を基本に」と言う場合では、更新する範囲が違う。 一回の依頼から恒久的な好みを推定すると、次の短い報告まで長くなるかもしれない。 反対に、継続する訂正を今回限りとして扱えば、翌日また同じ説明を求めることになる。
本稿は、発言から見つけた保存候補と、将来に適用する記録を分けることを勧める。 候補には原発言と対象を残し、継続する意図を確認できた内容を、適用する記録へ反映する。 明示された今回の訂正は現在の作業へ直ちに反映し、長期記憶の整理を待たせない。 整理を後から行う場合も、古い会話の要約が新しい訂正を取り消さないようにする。
たとえば、昨日の会話を今日の夜に要約して保存すると、保存時刻は今日になる。 それでも、内容は今日の午前に受けた訂正より古い。 最新の保存時刻だけで優先順位を決めると、処理が遅れていた古い希望が勝ってしまう。 発言した時点、条件が有効になる時点、保存した時点を分けて持つ理由はここにある。
訂正前の記録をすべて消すかどうかも、用途によって違う。 現在の提案には新しい好みを使い、変更理由の確認には以前の発言を参照したい場合がある。 古い内容を検索結果から外すことと、履歴を削除することを分けて設計すれば、この二つの要求を混同せずに扱える。
共有記憶は、読む範囲と書く範囲を別に決める
Lettaの記憶ブロック（memory blocks）の技術説明は、複数のエージェントが同じ記憶ブロックを使う構成と、エージェントが編集できる内容、読み取り専用の内容を分ける仕組みを示す。 これにより、参照する情報をそろえつつ、すべての担当へ同じ更新権限を渡さない設計ができる。 共有できることと、同時更新の意味が正しいことは別の問題である。
調査担当Aが期限を訂正し、担当Bが古いメモへ担当者を追記して全体を保存する場面を考える。 全面保存を後の内容で置き換える実装なら、Aの訂正が消える。 これは想定する更新方式から生じる競合例であり、特定製品が常にこの結果になるという主張ではない。 検索を改善しても、保存時に失われた訂正は読み戻せない。
変更対象の項目を限定する、保存前に版を照合する、全面編集の担当を決めるといった対処には、それぞれ負担がある。 項目を分けても、期限と承認条件のように意味がつながる更新は一緒に確認したい。 担当を一人にすれば調整はしやすいが、その処理を待つ時間は増える。 共有記憶の選択では、検索の成績に加え、どの更新を同時に許し、どこで人や別の処理が競合を解くかを比べる必要がある。
忘れる操作を、利用者が確かめられるようにする
便利な記憶ほど、利用者は何が残り、何に使われたかを確かめたい。 ChatGPTの記憶に関する発表は、記憶の確認、削除、停止を用意し、会話を削除しても別に保存された記憶は消えないことを説明している。 製品のこの区別は、会話履歴と継続記憶を別の対象として扱う具体例になる。
自分のアプリでも、「忘れて」という依頼が何を対象にするかを決める必要がある。 現在の利用を止める、保存した好みを消す、元の会話を消す、共有記録からも外す、という操作は同じではない。 削除した要約を、残った古い会話から後で再生成すれば、利用者の意図に反して記憶が戻る恐れがある。 削除した対象と、その後の整理処理で再利用しない条件まで確認したい。
履歴を残す必要がある業務でも、個人の好みと正式な記録を一緒に扱う必要はない。 誰が訂正でき、誰が削除できるかを情報の種類ごとに決めれば、利用者の制御と仕事の記録を両立する選択肢を検討できる。 記憶の量が増えるほど便利になる、という前提だけではこの判断を説明できない。
記憶の評価を、検索の正答率で終わらせない
LoCoMoは、平均600ターン、最大32セッションの会話を含み、質問への回答、出来事の要約、複数の情報形式を使う対話を評価する。 長い会話を使うことで、離れた時点の発言や関係をどう扱うかを検査する研究例である。 単一の短い問い合わせの成績から、継続する会話の品質を推定しないための材料になる。
LongMemEvalのv2は500問を用い、情報抽出、複数セッションの推論、時間の推論、知識の更新、回答を控える能力を分けている。 本稿がこの分類から採るのは、過去の事実を答えられることと、訂正後に古い事実を使わないことを別に試す考え方である。 研究の評価項目を、自分の業務で特定方式が最良だという結論へ置き換えない。
冒頭の資料作成なら、以前の好みを聞く場合、今回だけ詳しくする場合、今後の希望を変える場合、希望を一度も述べていない場合を分けて試せる。 共有メモでは同時更新を、忘却では削除後の再利用を加える。 回答と一緒に、保存した候補、確定した記録、読み込んだ内容、適用した条件を見れば、どの工程が誤ったかを調べやすい。
費用も、回答に使う入力だけでは足りない。 情報の抽出、要約、関係の生成、更新確認、削除の反映に使う処理と、人が誤記を訂正する時間を含めて比べたい。 同じ課題とモデルで、会話だけを使う場合、検索を追加する場合、更新や共有の規則を加える場合を比べれば、どの追加処理に意味があるかを判断できる。
次の仕事で役に立つ記憶を作る
冒頭の利用者が翌日また資料を頼んだとき、AIは以前の希望を覚えた上で、今回の明示的な依頼へ合わせて書けることが望ましい。 希望が変わったなら訂正を保持し、何も示されていない条件は質問できる。 この一往復を支えるには、候補を探す精度と、記録を適用できる状態へ保つ処理の両方が必要になる。
したがって本稿は、記憶方式を選ぶ前に、読み落とし、古い条件の適用、誤保存、更新の消失、削除後の再利用のどれを直すかを決めることを勧める。 その失敗に応じて、会話の状態、継続する好み、正式な規則、共有記録を区別し、検索、更新、忘却へ必要な処理を置く。 記憶の設計が目指すのは、利用者が毎回同じ説明をし直さずに済み、変わった判断は変わったものとして扱われることである。