AIエージェントが会話を忘れる問題を解く：RAGの限界を超える3つの戦略

何が起こっているか：AIエージェントの「記憶喪失」

生成AIを使ったエージェント（自動で判断して動作するプログラム）を運用していると、こんな経験はないでしょうか。

• 10分前の会話の内容をエージェントが忘れている
• ユーザーが「さっき言ったあの件」と言っても、過去のやり取りが反映されない
• チャットボットが同じ質問を何度もしてきた

これは「セッション間記憶喪失」と呼ばれる問題です。エージェントが新しいセッションを開始すると、前のセッションの文脈が完全に失われてしまうんです。

従来、この問題を解決するために多くの開発者が採用していたのが RAG（検索補強生成） でした。過去のやり取りをデータベースに保存しておいて、新しい質問が来たときに関連する過去の情報を検索して、生成AIに渡すという方法です。

しかし実運用では、RAGにも大きな弱点があることがわかってきました。

RAGは「検索」でしかない

開発者の間で最近よく指摘されているのが、「RAGは検索であって、記憶ではない」 という認識です。RAGは基本的に「キーワードやベクトル（数値化された意味）の類似性で過去の情報を探す」という仕組みに過ぎません。

たとえば、ユーザーが「あの プロジェクトの進捗は？」と聞いたとき、RAGは「プロジェクト」というキーワードで検索します。でも、前のセッションでそのプロジェクトの具体的な名前が出ていなかったら、検索に引っかかりません。つまり、RAGは「キーワードに引っかかる情報」しか持ってこられないという限界を持っています。

さらに、大量のドキュメントの中からエージェントが必要な情報を見つけ出すことは、単なる「検索精度」の問題ではなく、「構造と文脈」の理解にかかっているケースが多いです。つまり、単に似ている情報を持ってくるだけでは不十分なのです。

戦略1：グラフ構造を使った関連情報の追跡

最近注目されているアプローチが、グラフ走査（グラフ traversal） を使った方法です。これは、情報をノード（点）とエッジ（つながり）で構造化し、関連情報を「つながりに沿って」探していくという手法です。

RAGのように「似ているものを検索する」のではなく、「ユーザーが言及した実体（人物、プロジェクト、商品など）から出発して、その周辺のつながった情報を次々と辿っていく」というイメージです。

たとえば：

• ユーザーが「太郎の プロジェクト」と言及
• グラフから「太郎」というノードを見つける
• そのノードから「プロジェクトに参加」というエッジをたどる
• 関連するプロジェクトのノードに到達
• そのプロジェクトから「予算」「期限」「チームメンバー」といった属性情報を取得

この方式は、RAGのように「キーワード検索で引っかかるかどうか」に依存しません。明示的な関連性をたどるので、より正確に必要な文脈を取得できるわけです。

戦略2：スキーマ設計で予測不可能な出力を防ぐ

AIエージェントが生成する出力を構造化する（スキーマ設計）ことで、信頼性を大きく向上させるという取り組みも注目されています。

具体的には、「エージェントから返ってくる情報はこの形式でなければならない」という厳密な定義を事前に決めておくということです。これにより：

• エージェントが勝手な形式で情報を返す（ハルシネーション）を防ぐ
• 次のセッションでその情報を再利用するときに、形式が統一されている
• 過去のセッションの記録を確実に検索・参照できる

つまり、「きちんと構造化された記録」があれば、それを検索したり、グラフで関連付けたりすることが容易になるということです。

戦略3：エージェントのライフサイクル全体で情報を保持する

一般的に「エージェントの実行が終わった = タスク完了」と考えられています。しかし実は、エージェントの実行（ラン）が完了した後にやることがあります。

エージェントが「生成AIがもう返答を止めた」という状態に到達しても、実は重要な情報整理が済んでいないケースが多いです。たとえば：

• セッション中に出た決定事項を整理して、構造化形式で保存する
• 新しく得られた情報を既存のグラフに追加する
• 矛盾や未解決の課題をマークしておく

このような「実行終了後の処理」を組み込むことで、次のセッションがより確実な情報を参照できるようになります。

実装のポイント

これら3つの戦略を組み合わせるなら：

1. 前のセッションの情報をグラフ構造で保持する：単なるテキスト保存ではなく、実体と関連性を明示的に記録
2. 新しいセッションの入力をグラフの既存ノードに接続する：「太郎」と言われたら、過去に出たノードの「太郎」かどうかを確認
3. エージェントの出力をスキーマに従わせる：決まった形式で、構造化されたデータとして保存
4. セッション終了時に情報を整理・記録する：ラン完了後も、得られた情報をグラフに統合する処理を走らせる

これにより、RAGの「キーワード検索」の限界を超えた、より安定した文脈管理が可能になります。

注意点と現実的な課題

ただし、これらの戦略にも実装上の課題があります。

グラフ構造は設計が複雑になりやすく、小規模なプロジェクトでは過剰設計になる可能性があります。また、スキーマ設計を厳密にしすぎると、予期しない状況に対応しにくくなるというトレードオフもあります。

実務では、「完璧な構造化」を目指すのではなく、「よく出現するパターンは構造化し、珍しいケースは柔軟に対応する」という段階的なアプローチが現実的と思われます。

まとめ

AIエージェントの記憶喪失問題は、単に「過去の情報を検索できればいい」という次元ではなく、「情報をどう構造化し、どう関連付け、どう保持するか」という設計問題です。RAGだけでは不足しており、グラフ構造、スキーマ設計、ライフサイクル管理を組み合わせることで、より堅牢なエージェントが実現できるようになります。