Agent Memoryの実装方式をどう選ぶか？ クラウド統合型・ライブラリ・OSS・Agent Runtimeで異なる「責任範囲」

Agent Memoryの責任境界から、技術選定の選択肢を知る

　第1〜3回では、長い履歴で回答が崩れる理由、会話履歴やRAGとMemoryの違い、「抽出・保存・想起・再編成」からなるLifecycleを整理しました。第4回では、各工程を製品とアプリケーションのどちらが担うのかを具体化します。

　マネージドなMemoryを採用しても、記憶の正しさまで自動的に保証されるわけではありません。業務データとの優先順位、訂正時の扱い、削除要求を元データと派生Memoryへどう反映するかは、利用者が設計します。

　たとえば、顧客の「今後の連絡はメールで」という発話を保存した後に、「電話に変えてください」と依頼された場面では、次の5点を扱います。

• 以前の「メール」というMemoryを以後の回答で使わない
• 必要なら「以前はメール、現在は電話」という変更履歴を残す
• 削除要求では、元の会話と派生Memoryの両方を対象にする
• 別の顧客やTenantのSessionから取得できないようにする
• CRMに正式な値があれば、会話由来のMemoryより現在のCRMを優先する

　本稿は、既存AgentへMemoryを追加する実装者と、クラウド標準機能を比較するアーキテクトを想定しています。採用候補だけでなく、製品へ任せる処理とアプリケーションに残る処理を、同じ図で議論できる状態を目指します。

既存Agentの変更範囲と、Memoryの設計範囲で整理する

　図1は製品の性能ではなく、導入時の変更範囲と設計責任を示します。横軸は、既存AgentへLibrary／APIを追加する方式から、Agentの実行や会話StateまでPlatform／Runtimeへ移す方式までを表します。縦軸は、抽出、統合・矛盾解消、Schema／保存形式、検索、保持・更新・削除を利用者が変更できる範囲です。右ほどAgent基盤の移行範囲が広く、上ほどMemory設計の責任が利用者側に残ります。

　座標は2026年7月27日時点の公式仕様を基にした著者の相対評価です。縦方向は、①抽出、②統合・矛盾解消、③Schema／保存形式、④検索、⑤保持・更新・削除の五項目で配置しました。ひし形はLibrary／OSS、丸はManaged Memory API／Service、四角はAgent Platform／Runtime統合型です。責任境界が変わるため、AWSは三方式、Microsoftは二方式に分けています。

図1の読み方

　左側は、既存Agentの認証、業務Tool、監視、デプロイを維持したままMemoryを追加しやすい方式です。一方、書き込み・検索のTimingと、検索結果を回答コンテキストへ反映する処理はアプリケーションに残ります。

　右側は、Agentの実行や会話Stateまで製品へ統合できます。その代わり、認証、Tool、監視、デプロイを含む移行範囲が広がります。既存Agentへ段階導入するのか、これからAgent基盤を標準化するのかで、適した位置は変わります。

　縦方向では、設計自由度と検証責任を同時に見ます。下側は標準機能で試しやすい一方、記憶の種類、抽出条件、保存形式、削除単位が業務要件に合うかを確認します。上側は業務固有のFactや手順を設計できますが、抽出失敗、重複・矛盾、古いFact、Scope越境、Schema変更後の再処理までテスト対象になります。

　選定では、まず「既存Agent／Runtimeを維持するか」、次に「Memory Pipelineのどの工程を変更したいか」を決めます。同じ製品でも利用方式によってアプリケーションに残る実装が異なります。

　ただし、領域マップだけでは、抽出、保存、検索、回答コンテキストへの反映、更新・削除の各工程を誰が担うかまでは分かりません。次ページでは主要製品を同じ8工程に分解し、製品が処理する部分、アプリケーションに残る部分、両者で方針を分担する部分を具体的に比較します。