公式READMEのPersonaMem検証では、Agent Memory導入後の正解率が48％から76％へ改善したと報告されています。ただし、これは特定プロジェクトのベンチマークであり、RAGの代替を意味しません。RAGは外部知識の検索、Agent Memoryはユーザー・会話・タスク状態の継続保存です。長期稼働するAI Agentなら、原則として双轨構成を選び、書き込み規則、根拠追跡、削除方針を別々に設計してください。 (github.com)
この記事は、客服Agent、個人アシスタント、コーディングAgent、多段タスクシステムを開発している方に向いています。すでにRAGを導入しているチーム、会話履歴をどこまで保存するか決める技術責任者にも役立つ判断材料をまとめます。
最終更新：2026年8月10日。TencentDB-Agent-Memoryの公式README、導入資料、公開変更内容を確認しています。最新版では構成、対応フレームワーク、権限機能が変わる可能性があるため、導入前に公式リポジトリの記載も確認してください。
Agent MemoryとRAGは、何を記憶する設計か
RAGは、製品仕様書、社内規程、APIリファレンス、FAQ、ソースコードのような「外部に存在する知識」を検索して、回答の根拠として使う設計です。質問が「返品期限は何日ですか」「このAPIの必須項目は何ですか」であれば、文書の該当箇所と出典を返すことが目的になります。RAGは静的文書だけに限定されず、更新されるデータやコードを再取り込みする構成にもできます。(support.claude.com)
一方、Agent Memoryは「次回の処理でも使うべき状態」を保存します。たとえば次のように分類すると、責任範囲が明確です。
- 外部知識：製品マニュアル、社内規程、料金表。主担当はRAGです。
- ユーザー設定：回答形式、利用言語、通知時間。Agent Memoryに保存します。
- 事実記憶：契約条件、過去に確定した判断、担当者の役割。根拠付きで保存します。
- シーン要約：現在の案件、障害対応の進行状況、開発中の機能。作業単位で更新します。
- タスク状態：未完了の手順、直前のツール結果、次に実行する処理。短期記憶として扱います。
「Agent Memoryとベクトルデータベースは何が違うのか」という疑問には、保存方式ではなく責任範囲で答えるとよいでしょう。ベクトルデータベースは検索基盤の一部です。Agent Memoryは、何を保存するか、いつ更新するか、誰が読めるか、元の発言へ戻れるかまで含むアプリケーション設計です。したがって、Agent Memoryがベクトル検索を利用することはありますが、両者は同じものではありません。
すべての情報を1つのインデックスに入れると、文書の改訂とユーザー設定の変更が同じ更新処理になります。その結果、古いFAQが残ったのか、ユーザーの希望が誤って抽出されたのか、障害発生時に切り分けにくくなります。
書き込みと更新を分けると、誤記憶を直しやすい
RAGでは通常、文書を登録し、分割し、メタデータを付け、検索対象へ取り込みます。文書の版、所有者、公開範囲、更新日時を管理し、改訂時には古いチャンクを無効化または置換します。明示的な取り込みが中心なので、書き込みの起点を監査しやすい点が長所です。
Agent Memoryでは、会話から重要な事実や好みを抽出し、複数回の発言をまとめて上位の記憶へ集約します。TencentDB-Agent-Memoryの公式説明では、会話をL0 Conversation、L1 Atom、L2 Scenario、L3 CoreまたはPersonaへ段階的に整理し、上位の要約から下位の原文へ戻れる設計が示されています。(github.com)
この違いは、更新処理に表れます。
- 衝突：以前は「メール通知」、現在は「通知不要」と言った場合、最新発言だけで上書きせず、日時と根拠を残します。
- 期限切れ：一時的な案件状態をPersonaへ昇格させないよう、保持期限と昇格条件を分けます。
- 重複：同じ事実が複数の会話に現れても、原文を消さず、正規化したAtomへ統合します。
- 誤記憶：削除や訂正を行った場合、上位の要約、検索インデックス、キャッシュまで反映状況を確認します。
「AI Agentの対話記録はすべて保存すべきか」という問いには、保存範囲を3層に分けて答えます。監査や誤答調査に必要な原文はアクセス制御付きで保管し、毎回のプロンプトへは投入しません。再利用価値のある事実だけを抽出し、短期タスクのログは期限を決めて削除します。全保存と全投入は別の設計です。
TencentDB-Agent-Memoryでは、記憶資産の所有者、公開範囲、Agent単位の割り当てを管理する考え方が示されています。個人用、チーム共有、ACLによる限定公開を分けられるため、単純な「全員が同じベクトル検索を行う」構成より、権限の説明を作りやすくなります。(github.com)
召回の目的と根拠の残し方を比較する
RAGの検索目標は、質問に対して正しい根拠を見つけることです。回答には文書名、節、版、URL、レコードIDなどを添え、後から「どの情報を使ったか」を確認できるようにします。キーワード検索とベクトル検索を組み合わせるハイブリッド方式は、固有名詞や型番と、意味の近さを同時に扱いたい場合に有効です。(anthropic.com)
Agent Memoryの召回目標は、現在のユーザーやタスクに必要な背景を復元することです。「この顧客は簡潔な回答を希望する」「前回の実装で認証方式を変更した」「この障害は再起動後に再確認する」といった状態が候補になります。ここでは検索スコアだけでなく、ユーザーID、Agent ID、案件ID、時点、記憶の信頼度を条件に加える必要があります。
長期記憶の召回ミスを追跡するには、最低限次の関連を残してください。
- 召回された記憶のID。
- それを生成した原文またはログの参照先。
- 抽出・統合された日時と処理バージョン。
- 検索条件、権限フィルター、採用理由。
- Agentの回答やツール実行に実際に利用されたか。
TencentDB-Agent-Memoryの公式READMEでは、上位のPersonaやScenarioからAtom、Conversationへ段階的に確認できる追跡設計が説明されています。これは、単にベクトルの類似度だけを表示する構成より、誤記憶の原因を調べやすい考え方です。ただし、実際の既定値や対応範囲は導入時の設定資料で確認してください。(github.com)
判断表：単独構成と双轨構成
| 判断軸 | RAG単独 | Agent Memory単独 | RAG＋Agent Memory |
|---|---|---|---|
| 主な対象 | 文書、規程、コード | ユーザー、会話、タスク状態 | 文書と継続状態 |
| 書き込み | 明示的な取り込み | 会話から抽出・統合 | 系統ごとに分離 |
| 回答の根拠 | 文書出典を提示しやすい | 原会話への追跡が必要 | 両方を別ラベルで提示 |
| 更新責任 | 文書版と取り込み処理 | 衝突、期限、訂正 | それぞれの更新処理 |
| 向く場面 | 一回限りの質問、社内検索 | 個人秘書、継続案件 | 業務Agent、開発Agent |
| 主な失敗 | 古い文書、誤検索 | 誤記憶、越境参照 | ルーティングと削除漏れ |
どの構成を選ぶべきか
次の条件分岐で、最初の構成を決めてください。
- 質問が1回ごとに独立し、回答根拠が文書にあるなら、まずRAG単独を選びます。
- 同じユーザーの好み、契約、作業状態を次回も使うなら、Agent Memoryを追加します。
- 文書の正確性とユーザーの継続状態の両方が必要なら、双轨構成にします。
- ユーザーごとの権限や削除要求が異なるなら、共有RAGへ会話記憶を混ぜず、記憶層を分離します。
- 物理的に保存できない情報を扱うなら、Memoryへ書き込む前に除外、匿名化、短期保持のいずれかへ振り分けます。
- 自動ルーティングの誤りを評価できないなら、最初はRAGとMemoryの検索結果を別々にログへ出し、手動で採用可否を確認します。
実装前には、次の5段階で検証してください。
- 代表的な質問を、知識質問、個人設定、案件状態、混合質問に分類します。
- 各分類について、保存対象、保存禁止対象、保持期限、閲覧主体を定義します。
- RAG用とMemory用に、別々の書き込みAPIまたは処理キューを用意します。
- 競合する発言、古い文書、ユーザー切り替え、Agent再起動、削除要求を固定テストします。
- 誤召回率、根拠の追跡可能性、ユーザー間の隔離、再起動後の復元、削除の反映を合格条件にします。
ローカル環境で試す場合でも、データを外部へ送らないことだけで合規性が完了するわけではありません。バックアップ、ログ、管理者権限、端末の盗難、削除対象の複製まで確認する必要があります。個人情報の扱いについては、NISTのプライバシーリスク管理資料を設計時の確認項目として利用できます。
RAGの基本構成を見直すなら、外部知識を検索して回答へ反映する公式解説と、ハイブリッド検索を扱う技術解説を確認してください。TencentDB-Agent-Memoryを試す場合は、公式リポジトリのREADMEと導入資料を起点に、対応フレームワーク、権限、最新版の構成を確認します。企業向けの記憶階層や検索機能を比較したい場合は、公式の製品資料も参照してください。
現在の検証環境が手元のノートPCだけだと、長時間稼働でスリープや再起動が入り、Agent Memoryの復元試験、ログ保持、複数Agentの同時実行を安定して繰り返しにくいことがあります。一般的なクラウド環境へ移す場合も、共有権限、データ所在地、停止時の状態保持を個別に確認する必要があります。
短期間だけ長期稼働環境を用意するなら、KvmzenのMacレンタル利用方法を確認し、RAGの再取り込み、Memoryの隔離、再起動復元を同じ環境で検証する方法があります。米国西部の作業拠点が必要な場合は、Macレンタルの米国西部向け案内も候補になります。
ただし、固定 workloadを長期にわたり高負荷で動かす場合、物理ポートや専用機器への接続が必要な場合、毎回同じ端末を保有したい場合は、自社購入や専用サーバーの方が適しています。反対に、公開前のAgent設計、複数構成の比較、短期の検証、チーム内デモが目的なら、手元PCの制約を抱え続けるより、必要な期間だけKvmzenのMac環境を借りて、記憶の分離と削除まで検証する方が判断しやすくなります。