企業AI AgentのRAGとMemory、2026年の選び方

企業AI AgentのRAGとMemoryは、通常どちらか一方に決めるものではありません。安定した企業知識はRAG、ユーザーの嗜好や継続中の作業状態はAgent Memoryに分け、業務システムの記録は別の状態層で管理する構成を優先してください。

この判断は、企業ナレッジベースをAI Agentへ接続する設計者、会話をまたいでユーザー状態を保持したい製品チーム、記憶の混入や権限越境を警戒するプラットフォーム責任者に向いています。

まず責務を分ける

RAGは単なるベクトル検索ではありません。文書の取り込み、分割、メタデータ付与、権限フィルター、検索、出典提示、更新・削除までを含む「外部知識を回答へ接続する流れ」です。原典のRAG研究でも、生成モデルが明示的な外部記憶へアクセスすることで、知識集約型タスクの具体性や事実性を高める方向が示されています。詳しくは原典論文の概要を確認できます。 (arxiv.org)

一方、Agent Memoryは無制限の会話保存ではありません。次回の応答や行動を変える価値があり、保存理由と訂正方法を説明できる情報だけを対象にします。

この分離をしないと、古い手順書がMemoryに残ったり、個人の例外設定が全社ルールのように検索されたりします。問題は回答品質だけでなく、誰が何を見られるか、誤りをどこから削除するかにも広がります。

利用者層ごとの選択

知識助手

社内規程や製品資料を答える知識助手では、最初にRAGを整備してください。文書の版、発効日、廃止日、部署、機密区分をメタデータとして持たせ、回答には参照元を添えます。

ユーザーの好みを保存する場合でも、企業知識のインデックスへ書き込んではいけません。たとえば「この人は簡潔な説明を好む」はMemory、「経費申請は承認者が必要」はRAGであり、同じ検索領域に置く理由はありません。

顧客サービスAgent

顧客サービスでは、過去の問い合わせ、希望する連絡手段、すでに完了した操作をMemoryへ保存すると、同じ確認を繰り返す負担を抑えられます。ただし、顧客の発言をそのまま長期記憶へ移すのではなく、保存対象を項目単位に要約し、保持期間と削除条件を付けます。

Memoryを導入する前に、記憶の範囲、失効条件、ユーザーが「忘れて」と依頼する入口、誤記憶を修正する管理画面を決めてください。これらが未定のまま長期保存を始めると、後から個別削除を実装するコストが大きくなります。

プロセス自動化Agent

ワークフローAgentでは、タスクの進捗や失敗理由を検索文書へ詰め込むのではなく、状態層として扱います。「請求書の確認が未完了」「外部APIの応答待ち」「承認者が不在」といった値は、次の処理を再開するための状態であり、自然言語の記憶とは性質が違います。

この構成では、Memoryは経験や個人設定、状態層は再開可能性、業務データベースは正式な取引記録という境界を置きます。Agentが判断した内容を業務記録へ反映する場合は、実行前後の差分と承認結果も残してください。

3層構成と権限

複数チームで使うプラットフォームでは、RAG、Memory、業務データベースを横並びで接続するだけでは不十分です。認証された利用者の属性を最初に解決し、その属性を各データソースの読み書き判定へ渡す共通の権限層が必要です。

RAG側では、文書ごとに利用者やグループの識別情報を持たせ、検索時にアクセス可能な範囲を絞り込みます。公式ドキュメントでも、文書単位の権限制御にはセキュリティフィルターやACL、RBACなど複数の方式があり、データソースとIDモデルに応じて選ぶ設計になっています。 (learn.microsoft.com)

ベクトル検索でも、メタデータフィルターを類似度検索と同時に適用できる方式があります。ただし、フィルターを後段で追加する設計や、権限情報を検索結果だけで判定する設計では、対象外文書が一時的に候補へ入る可能性を検討しなければなりません。公式のメタデータフィルター仕様でも、検索条件と属性条件を組み合わせる仕組みが説明されています。 (docs.aws.amazon.com)

最終回答のログには、単に「Agentが回答した」と書くのでは足りません。RAGから取得した文書、Memoryから再利用した情報、業務システムから取得した値、最終的な判断を分けて記録すると、誤回答の原因を切り分けやすくなります。

導入判断の分岐

次の条件分岐を、設計レビューの最初に使ってください。

• 公式文書の正確な参照が目的で、ユーザーごとの継続状態が不要なら、RAG単独から始めます。
• ユーザーの好みや過去対応を使いたいが、企業文書を検索する必要がないなら、範囲を限定したMemoryを選びます。
• タスクを中断後に再開する必要があるなら、Memoryへ押し込まず、状態層または業務データベースを追加します。
• RAGとMemoryの両方を使うなら、書き込み経路を分離し、企業知識への自動昇格を禁止します。
• 権限、削除、期限、訂正を実装できないなら、長期Memoryは見送り、セッション内の一時コンテキストへ戻します。
• 規制対象のデータを扱い、参照元と削除履歴を追跡できないなら、対象データを匿名化するまで本番投入しません。

この判断では、モデルの性能よりも「間違えたときに何が起きるか」を優先します。古い文書を参照する問題は更新処理で直せますが、誤った顧客属性を長期記憶として利用し続ける問題は、削除対象の特定から難しくなります。

受け入れ検査

本番へ進める前に、次の項目をチェックしてください。

• [ ] RAG、Memory、状態層、監査ログの書き込み先が別れている
• [ ] すべての企業文書に出典、版、所有者、権限情報がある
• [ ] Memoryごとに保存理由、作成日時、期限、削除方法がある
• [ ] ユーザーが記憶内容を確認し、訂正または削除できる
• [ ] 権限のない文書が検索候補へ入らないことを検証している
• [ ] Agentの推測を公式知識へ自動登録しない
• [ ] 中断したタスクを状態IDから再開できる
• [ ] 回答、記憶の再利用、業務APIの実行を別々に監査できる
• [ ] 脱敏データで越境アクセスと削除処理を確認している

受け入れ検査では、正常回答だけでなく、権限変更直後、文書の廃止後、記憶の訂正後、外部処理の失敗後も確認してください。公式資料上でも、権限メタデータの反映やラベル変更にはインデックス更新のタイミングが関係するため、取り込み完了前の過渡状態を試験対象に含める必要があります。 (learn.microsoft.com)

FAQ

企業AI AgentのRAGとMemoryを比較する際は、保存場所ではなくデータの責務で判断してください。安定した知識は出典と版を持つRAG、個人設定は訂正可能なMemory、処理の進行は状態層へ分けると、権限や削除の設計が明確になります。

長期Memoryを導入できない場合でも、RAGの品質改善は進められます。文書の所有者、更新手順、権限メタデータ、回答の出典表示を整備すれば、Memoryなしで運用できる知識助手は多くあります。

現在の構成が会話ログの一括保存や共有インデックスに依存しているなら、主な弱点は3つあります。個人情報と企業知識の境界が曖昧になり、古い情報の削除範囲を特定しにくく、権限変更後の検索結果を監査しにくい点です。

だからこそ、企業AI AgentのRAGとMemory、2026年の選び方としては、いきなり大規模な永続記憶を購入するより、脱敏データを使った隔離環境で責務分離を検証する方が堅実です。ZavCloudのサービス概要で利用形態を確認し、環境や運用に関する疑問はヘルプセンターで確認しながら、まずは開発・受け入れ用のMac環境でRAGとMemoryの境界を試してください。長期の安定稼働や物理インターフェースが必要なケースでは自社保有が適しますが、短期間の検証やチーム別の隔離環境では、ZavCloudのMacレンタルを使う方が構成を固定する前の比較を進めやすい場合があります。