AIエージェントの記憶ライフサイクルをどう設計するか？

既存データは、そのままMemoryになるわけではない

　業務エージェントに接続されるデータは、すべてMemoryに変換する必要はありません。正式な参照元として扱うべきもの、検索対象にすべきもの、Memory候補として抽出すべきもの、監査や評価のために残すものを分ける必要があります。

　会話履歴は、過去のやり取りの記録です。しかし、それをすべて次回以降の前提にしてよいわけではありません。会話の中には、一時的な依頼、雑談、未検証の推測、すでに古くなった条件が含まれます。したがって、会話履歴からは、継続的に使える制約、ユーザーの好み、作業上のエピソードを抽出する必要があります。

　チケット履歴も同様です。過去対応の全文をそのままMemoryにするのではなく、類似障害、失敗した手順、成功した回避策、再利用できるRunbookを取り出します。一方、業務DBには、顧客ステータス、契約情報、最新の権限、価格表のように、業務システムで管理されている正式データがあります。これらはMemoryにコピーして固定化するのではなく、必要なタイミングで正式な参照元として確認する方が適している場合があります。

　つまり、Memory設計の出発点は、既存データをMemory Storeへ移すことではありません。既存データの中から、何を次回以降の判断に使える記憶として抽出するのか、何を正式な参照元として扱うのか、何を監査用ログとして残すのかを分けることです。

記憶ライフサイクルは、抽出・保存・想起・再編成に分けて考える

　ここで、第2回の最後に置いた「記憶のライフサイクルをどう実装するか」という問いに戻ります。業務エージェントのMemoryは、単一の機能ではなく、少なくとも次の4つの処理に分解できます。

　この整理は、特定の製品名に依存したものではありません。2026年の論文「From Storage to Experience: A Survey on the Evolution of LLM Agent Memory Mechanisms」は、LLM AgentのMemoryメカニズムを、Storage、Reflection、Experienceの3段階で整理しています。過去の軌跡を保存するだけでなく、それを振り返り、複数の経験から再利用可能な知識へ抽象化していく流れです。本稿で扱う「抽出」「保存」「想起」「再編成」という整理も、この流れを業務エージェントの実装に引き寄せたものです。

　このうち、特に見落とされやすいのが「想起」です。多くの場合、Memoryというと保存に目が向きます。しかし、業務エージェントでは、保存されたMemoryをいつ、どの条件で、どの範囲まで使ってよいかが品質を左右します。

　では、その条件はどのように判断すればよいのでしょうか。ここで重要になるのが、Memoryを「データの形」で分けることです。直近の会話状態、過去の対応履歴、顧客や担当者の情報、業務知識、手順書、時点付きの関係性は、すべて同じMemoryとして扱うことはできません。直近の会話状態は現在のタスク中だけでよいかもしれませんが、顧客情報や関係性はスコープや有効期間を確認する必要があります。手順書やRunbookは作業前に検索すべき知識であり、過去対応履歴は類似ケースとして使えるかを判断する必要があります。

Memory技法は、扱うデータと想起条件で分けて考える

　Memoryの実装技法は数多くあります。Agent_Memory_Techniquesでは、Short-Term Memory、Long-Term Memory、Cognitive Architectures、Retrieval & Multi-Agent、Frameworks & Platforms、Evaluation & Productionといった分類で、エージェント向けMemory技法が整理されています。

　このように見ると、Memory技法は抽象的な分類ではなく、データモデルと保存基盤の選択に直結します。過去の会話をベクトル化して検索するだけでは、担当者変更や契約条件の有効期間は扱いにくい場合があります。逆に、すべてをグラフにする必要もありません。扱う情報が「文章として似ているもの」なのか、「時点付きの出来事」なのか、「人や組織の関係性」なのかによって、適したMemory技法は変わります。