AIエージェントの記憶とは何か？会話履歴を業務判断に変える設計

会話履歴は、記憶そのものではない

　前回は、AIエージェントが本番業務で崩れる理由として、コンテキスト劣化と記憶設計の不足を取り上げました。多くの人は、AIエージェントの「記憶」と聞くと、まず過去の会話履歴を保存することを思い浮かべるかもしれません。たしかに、会話履歴は重要です。しかし、それは記憶そのものというより、記憶に変換される前段階のものです。Agent Memoryとして再利用するために、抽出・要約・構造化等を行います。

　たとえば、問い合わせ対応の中で担当者が「A社は通常のメール回答ではなく、専用ポータルにチケットを起票して回答する必要がある。緊急度が高い障害の場合は、情報システム部にも同時に連絡する」と話したとします。この発話をそのまま保存するだけでは、次回の対応で使いやすい形にはなっていません。Agent Memoryとして扱うなら、「A社への正式回答は専用ポータル経由」「緊急障害時は情報システム部にも通知」「メール返信だけで完了扱いにしない」といった、再利用可能な前提に変換する必要があります。

　ここで重要なのは、メモリを「保存された情報」として見るのではなく、「次の業務判断で使ってよい前提」として見ることです。AIエージェントが過去の文脈を使うということは、昔の発話を丸ごと参照することではありません。その発話から抽出された前提を、現在の業務判断に再利用することです。

　Agent Memoryの全体像を整理する補助線として、サーベイ論文「Memory in the Age of AI Agents」は参考になります。同論文は、Agent Memoryを単なる保存場所ではなく、記憶がどのように作られ、更新され、取り出されるかという動的な仕組みとして捉える視点を示しています。この考え方を企業のAIエージェント実装に引き寄せると、Agent Memoryは単一の保存先ではなく、複数の領域で構成されるものとして捉えられます。会話やツール実行結果のようなログ、人間が確認・編集できるファイルベースの記憶、Agentが検索・更新・統合するDBベースの記憶、そしてそれらを横断して制御するMemory Orchestrationです。図1は、これらの構成要素の関係を整理したものです。

RAGで足りる業務、Memoryが必要になる業務

　Agent MemoryはRAGの上位互換ではありません。RAGは、外部文書や知識を検索し、現在の回答に使うための重要な技術です。最新の社内規程、製品仕様、FAQ、契約条件のように、常に信頼できる最新情報を参照すべき業務では、まずRAGや検索品質を高めることが優先されます。過去の記憶を使うことで、古い規程や旧バージョンの仕様を回答に混ぜてしまう可能性があるからです。

　RAGとは、現在の質問に対して関連する外部知識を検索し、その知識を根拠として回答生成に組み込むアーキテクチャです。一方で、Agent Memoryが価値を持つのは、「過去の文脈を、次の判断にどう持ち越すか」が品質に影響する場合です。同じ顧客や案件に継続的に対応するAgentでは、過去の対応方針、顧客ごとの制約、前回の検討結果、以前の失敗や修正履歴が重要になります。

　サーベイ論文のFigure 2（本記事の図2）は、Agent Memory、LLM Memory、RAG、Context Engineeringの関係を示しています。RAGやContext EngineeringはAgent Memoryと一部重なりますが、RAGが主に静的な外部知識へのアクセス、Context Engineeringが一時的なコンテキスト資源の管理に寄るのに対し、Agent Memoryは事実や経験を統合しながら持続的に進化する状態を扱うものとして位置づけられています。

　RAGで足りる業務とMemoryが必要になる業務を分けると、次に考えるべき論点は「過去の文脈をどこに、どのような形で持たせるか」です。過去の文脈を次の判断に持ち越すといっても、すべてを同じ場所に保存すればよいわけではありません。人間が読み、修正し、レビューすべき前提もあれば、Agentが検索し、更新し、アクセス権限や監査ログとあわせて扱うべき情報もあります。そこで次に、ファイルベースの記憶とDBベースの記憶の使い分けを整理します。