Agent Memoryの能力と導入効果を評価する

　第4回では、Agent Memoryの実装方法と主要なツールを紹介しました。今回は、PoCを進める実装担当者に向けて、メモリ導入後の評価方法と本番利用の判断基準を説明します。公開ベンチマークの評価項目と、ツール選びで確認したい結果も整理します。

記憶の設計と評価が必要な理由

　AzureやAWSのサービス、OSSなどでメモリ機能を導入し、会話の内容を記憶として保存できるようになった。それだけで「Agentの記憶機能の実装は完了した」と考えていないでしょうか。必要な記憶を取り出し、依頼に使えるかまで確かめる必要があります。

　何を記憶として残し、いつ更新し、誰のどの依頼に使うか。これらを決めずに運用すると、次の問題が起こり得ます。

• 誤った内容や古い指定を再利用する。抽出時の誤解や更新漏れが残ると、後の回答でも誤りを繰り返す。
• 記憶を使うユーザーや案件を取り違える。別案件の指定を適用したり、ユーザーに閲覧権限のない記憶を回答に含めたりする。
• 必要な記憶が見つかっても依頼を完了できない。検索結果がLLMへの入力やツール操作に反映されなければ、依頼は失敗する。
• 時間と費用が増える。不要な記憶まで蓄積・検索・入力すると、改善効果に見合わない負担になる。

　Huangらのサーベイ論文「A Survey of Agent Memory in the Second Half: Towards Self-Evolving and Long-Horizon Agents」第7節では、記憶の内容、検索結果、依頼の成功に関する評価指標が整理されています。

　Mem0の解説記事「State of AI Agent Memory 2026: Benchmarks & Trends」でも、回答の正確さに加え、トークン消費量や検索・回答生成の時間を評価の観点に挙げています。

　本稿では、記憶を残す、取り出す、依頼に使うという処理ごとに、確認する内容と評価方法を掘り下げます。公開ベンチマークも、どの能力を測り、その結果をどうツール選びに使うかまで説明します。

記憶が使われるまでのどこで失敗するか

　抽出時に必要な内容が抜けたのか、記憶を検索できなかったのか、取り出した記憶を使い損ねたのか。図1の処理を順に調べると、直す箇所を絞れます。

必要な内容を記憶として残せているか

　要約で条件が抜けたり、アシスタントの提案をユーザーの確定した希望として保存したりすると、検索できても誤った判断につながります。新しい指定を残しても、古い指定を現行情報として使う場合があります。

　Chenらの論文「HaluMem: Evaluating Hallucinations in Memory Systems of Agents」では、抽出した記憶を正解の記憶と照合し、誤りや取りこぼしを調べます。更新後の記憶と最終回答も別々に評価するため、回答の正誤だけでは見えない誤りを追う参考になります。データとコードは「MemTensor/HaluMem」で公開されています。メモリを導入したAgentを評価するときは、次の点を調べます。

• 抽出では、残すべき事実の取りこぼしと、元の履歴にない内容の追加を別々に評価する。
• 更新では、新しい指定を使えるかと反映までの時間を調べる。変更前の記憶を履歴として残すことと、現行の指定として誤用することを区別する。

　保存内容を一覧取得APIなどで取り出し、元の発話と記憶をIDで対応付け、意味の欠落や変更を調べます。取得できない処理は未確認とします。

検索できた記憶が回答と操作に届いているか

　保存した記憶も、検索語や案件の絞込み、検索後の並べ替えによって候補から落ちることがあります。Wuらの論文「LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory」の評価コードを公開する「xiaowu0162/LongMemEval」の検索評価では、必要な根拠を一つでも取得した場合と、全て取得した場合を分けています。根拠の不足と、不要な記憶の混入を調べます。

　検索した記憶も、LLM入力の要約や長さの制限で内容が欠ける場合があります。LangChainのLangSmithガイド「How to evaluate an application's intermediate steps」では、RAGの処理記録から、検索語に合う文書を取得できたか、回答がその文書に基づくかを別々に評価しています。記憶を使うAgentでは、検索結果と実際のLLM入力も照合すると、回答前に根拠が欠けていないかを調べられます。

　必要な記憶が届いても、Agentがツールや操作対象を間違えれば依頼は失敗します。Mem0の研究チームによる論文「DolphinBench: Mapping the Pareto Frontier of Agent Memory」では、過去の会話を基に模擬アプリを操作する600件の依頼を扱います。ツール名や宛先・日付はプログラムで照合し、作成した文章は意味も評価します。データとコードは「mem0ai/dolphinbench」で公開されています。メモリを導入したAgentを評価するときは、返事に加えて成果物や処理後の状態を確認します。

　根拠がない質問は別に評価します。推測で補わず、不明と伝えるか必要事項を確認できれば成功です。

実装したAgentで評価を始める

　まず、Agentへ頼みたい依頼を少数選び、人の目で確かめます。最初から図1の全項目を自動判定する必要はありません。

　① 依頼と期待する結果を書き出す

　一件の依頼ごとに「過去の会話」「今回の依頼」「成功条件」を用意します。回答だけでよいのか、ファイル作成やシステム更新まで必要かを、利用者と決めます。指定の変更、複数の会話の参照、答えが分からない場合も含めます。

　過去の会話は登録する材料、今回の依頼は実行時の入力です。期待する結果は評価側だけが持ち、調整に使わない最終確認用の依頼も残します。

　② メモリの追加前後で同じ依頼を実行する

　現在のAgentとMemoryを追加したAgentに同じ依頼を出します。LLM、ツール、業務データ、従来の履歴をそろえ、履歴の取込み完了後に実行します。保存した記憶、検索結果、LLM入力、回答・操作結果を残します。

　「作成しました」という返事だけでなく、成果物の存在と内容を確認します。形式や件数はプログラムで、文章の意味は担当者が確認します。LLMで判定する場合も、人の判定と合うかを先に確かめます。必須条件が一つでも欠ければ成功とは数えません。

　③ うまくいかなかった依頼を調べて直す

　図1の記録を見比べ、失敗した処理に対応する設定を一つ変え、同じ依頼をもう一度実行します。

　再実行では記憶と操作対象を元へ戻し、前の実行で覚えた内容や成果物の影響を防ぎます。同条件での繰返しと、調整に使わなかった依頼でも改善を確かめます。

適用範囲と権限は正答率と分けて確認する

　閲覧できる記憶でも、別案件の指定を今回の依頼に使ってよいわけではありません。最終回答が正しくても、検索結果やLLM入力に権限外の記憶が含まれる場合があります。依頼の成否とは別に、次を確認します。

• 適用範囲：同じユーザーの別案件の記憶を保存し、Agentが今回の案件へ誤適用しないかを調べる。検索結果に含まれたかと、判断に使われたかを分けて記録する。
• 閲覧権限：権限のあるユーザーで取得できた記憶を、権限のないユーザーで要求する。Agentの回答だけでなく、検索結果やLLMへの入力にも含まれないかを調べる。
• 削除：削除前に取得できた記憶が、定めた期限後に検索結果やLLMへの入力から除かれるかを調べる。物理削除が要件なら、保存先での削除完了も確認する。

　削除は第4回で扱った「検索で見えなくすること」と「データを消すこと」の区別です。更新・権限・削除は別に集計し、重大な違反を成功率に埋もれさせません。