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

主要製品で見るAgent Memoryの責任範囲

　図2では、主要製品の責任範囲を、入力・Scope、Memory抽出、統合・表現、Memory保存、Memory検索、回答コンテキストへの反映、保持・更新・削除、Agent実行・状態管理の8工程に分けて整理しました。白抜きの丸はアプリケーション側、青い丸は製品またはLibrary側が担う工程です。黄土色の丸は、製品機能を利用しながら、ScopeやTrigger、保持期間、削除方法などを利用者側で設定・運用する工程を示します。背景色も同じ区分に対応しています。

　この図から確認したいのは機能の多さではなく、製品を採用した後もアプリケーション側に残る実装と運用です。製品に任せる工程が多い方式は導入時の実装を減らせる一方、既定のデータ構造や処理方式に沿う必要があります。利用者が担う工程が多い方式では、抽出条件、MemoryのSchema、保存先、検索方法を業務要件に合わせて設計できますが、その実装、評価、運用も利用者の責任になります。こちらの図は技術選定の議論の際にご参考にしてみてください。

Microsoft Foundry：エージェント実行と長期記憶を分けて導入できる

　Microsoft FoundryのMemoryは、エージェントが過去の会話から得た情報を、次回以降の会話でも利用できるようにする長期記憶機能です。現在はPublic Previewで、利用者の好み（User Profile）、過去の会話の要約（Chat Summary）、繰り返し行う作業の手順（Procedural Memory）を会話から抽出・整理して保存します。保存した記憶は項目ごとに確認・修正・削除でき、一定期間後に自動削除するためのTTLも設定できます。

　ここで押さえておきたいのは、Foundry Memoryを使うために、エージェント本体までFoundry Agent Service上で動かす必要はないという点です。エージェントの実行基盤と、記憶を保存するMemory Storeは分けて構成できます。

　たとえば、エージェント開発フレームワークのLangGraphで会話や処理の流れを管理し、セッションをまたいで残したい長期記憶だけをFoundry Memoryへ保存できます。エージェントが回答する前にMemory Storeから関連する記憶を取り出してプロンプトへ加え、会話後には新しく得た情報をMemory Storeへ送ります。Microsoftは、langchain-azure-aiを使ったLangGraphとの統合方法も公開しています。この構成では、記憶をいつ検索・更新し、回答へどう反映するかをアプリケーション側で制御します。

　一方、Foundry Agent Service上のエージェント（Prompt Agent）にMemory Search Toolを組み込む方法もあります。この場合、会話に必要な記憶の検索、回答への追加、会話後の更新までをAgent Serviceが担います。アプリケーション側で一連の処理を個別に実装する必要がないため、メモリー機能を会話へ組み込みやすくなります。Memory Search Toolの動作 つまり、既存のエージェントからMemory Store APIを利用する方法は、記憶の使い方をアプリケーション側で制御する構成です。Agent Serviceと統合する方法は、記憶の検索や更新を含む会話処理をFoundryへ任せる構成です。ただし、利用者ごとの記憶をどう分けるか、記憶と業務データが矛盾した場合にどちらを優先するか、訂正・削除の手段をどう提供するかは、どちらの方式でも導入企業・開発者が決める必要があります。

Amazon Bedrock AgentCore Memory：長期記憶化の3つの選択肢

　Amazon Bedrock AgentCore Memoryは、会話などの生データをEvent、そこから作った長期記憶をMemory Recordとして分けて管理します。アプリケーションはactorIdとsessionIdを付けてEventを送り、検索したRecordをエージェントのContextへ追加します。

違いが生じるのは、EventからMemory Recordを作る処理を誰が担うかです。 Built-in Strategyでは、重要な情報の抽出と、既存の記憶との重複・矛盾の整理をAgentCoreが実行します。作成されたRecordの保存と検索もAgentCoreが提供するため、アプリケーション側で長期記憶を作るPipelineを実装する必要はありません。

　Built-in with Overridesでは、AgentCoreのManaged Pipelineを使いながら、Strategyが対応する工程の指示とAmazon Bedrockのモデルを変更できます。ただし、RecordのSchemaは選択したStrategyに固定されます。 Self-managed Strategyでは、モデル、Prompt、処理ロジック、Record Schemaを含むPipelineを開発者が実装します。AgentCoreは設定した条件で通知とEventデータを送り、開発者は作成したRecordをBatch APIでAgentCoreへ保存します。Recordの保存と検索は引き続きAgentCoreが担います。

　つまり、3方式の違いは、長期記憶を作る処理を「すべて任せる」「一部を調整する」「自分で実装する」のどれを選ぶかです。

なお、EventとMemory Recordは別管理です。DeleteEventでEventを削除しても生成済みのRecordは残るため、削除要求への対応ではRecordも別途削除する必要があります（参考: Event削除時の注意事項）

Databricks：個人と組織の長期記憶をUnity Catalogで管理する

　Databricks Managed Agent Memoryは現在、Beta段階で、Agentがセッションをまたいで利用する情報をMemory Entryとして保存・検索します。記憶はScopeで分離され、利用者IDを指定すれば個人の好みや過去の判断を、組織やチームのIDを指定すれば社内用語やベストプラクティスを保存できます。1つのAgentが個人用と組織用のScopeを併用でき、権限を付与した複数のAgentやプロジェクトで同じMemory Storeを共有することも可能です。 Databricksの特徴は、Memory StoreがUnity Catalogの管理対象になる点です。通常のデータ資産と同様にアクセス権限、監査証跡、リネージュを適用でき、Databricksが保存基盤の運用とScopeごとの分離を担います。そのため、開発者が利用者ごとのテーブルやパーティションを設計する必要はありません。Scopeは利用者間の分離境界となるため、モデルには選択させず、認証済みの利用者IDなどを基に信頼できるコードで設定します。

一方、現行仕様には、会話から長期記憶を自動抽出・統合するマネージドPipelineはありません。何を記憶として残すかはアプリケーションまたはAgentが判断してMemory Entryへ書き込みます。検索も現時点ではpath、contents、descriptionを対象としたキーワード検索に限られ、ベクトル検索やセマンティック検索は提供されていません。そのため、記憶の保存単位や、検索結果を回答のコンテキストへどう組み込むかは、アプリケーション側で設計します。

　Managed Agent Memoryは任意のフレームワークで構築したAgentから利用できるため、実行基盤をDatabricksへ移す必要はありません。ただし、利用にはUnity Catalogを有効にしたDatabricks WorkspaceとAPI認証が必要で、Memory StoreとMemory Entryの操作は現在Unity Catalog REST APIで提供されています。

製品選択の観点では、Databricksは「記憶を自動で作るサービス」というより、「アプリケーションやAgentが作成した記憶を、個人用・組織用に分け、企業のデータ資産として統制・共有するサービス」だと整理できます。 はBetaで、Memory Storeの運用、Scope分離、Unity Catalogによる権限・監査、Memory EntryのCRUD、Keyword Searchを提供します。既存Agentから利用でき、保存基盤とアクセス統制をDatabricksへ任せる方式です。

　長期Memoryの内容はアプリケーションまたはAgentが作成・更新します。Memory StoreとScopeをConversationへ紐づければ会話履歴を保持できますが、長期Memoryの抽出内容と回答コンテキストへの反映方針はアプリケーション側に残ります。Scopeは認証済みIDからコードで設定します。

OCI Enterprise AI Agents：OpenAI互換のResponses APIで長期記憶とContext圧縮を一体化する

　OCI Enterprise AI AgentsのAPIファースト方式では、OpenAI互換のResponses APIとConversations APIから、OCIで提供されるモデル、Tool、会話状態、長期Memoryを利用できます。OpenAI SDKや互換Agent Frameworkの実装パターンを活かしやすいため、OCI独自の会話APIを一から学び直す負担を抑えられます。 Projectで長期Memoryを有効にすると、OCIが会話から重要な情報を抽出し、Embeddingへ変換して保存します。Conversationにmemory_subject_idを設定すれば、同じProject内で同じIDを持つ別のConversationでも記憶を共有できます。新しい会話や役割の異なるAgentでも利用者の好みや過去の情報を引き継げるため、記憶のコピーや同期をアプリケーションで実装する必要がありません。

さらに、memory_access_policyによって、Conversationごとに「読み書き」「参照のみ」「保存のみ」「利用しない」の4方式を指定できます。たとえば、ヒアリング用Agentは情報を保存するだけ、回答用Agentは既存の記憶を参照するだけにできます。これはIAMによる認可ではありませんが、同じ利用者のMemoryを共有しながら、Agentの役割に応じて不要な参照や保存を抑制できます（参考：Memoryの読み書き制御）。

短期的な会話履歴についても、長くなったContextを自動的に圧縮できます。過去の重要な内容を残しながらToken使用量とLatencyを抑えられるため、長時間続く対話を管理しやすくなります。つまりOCIは、OpenAI互換の会話フローを保ちながら、会話状態、長期記憶の共有、読み書き制御、Context圧縮までを一体化した方式です。

ただし、利用者IDとmemory_subject_idの対応、業務データとの優先順位、訂正・削除方針はアプリケーション側で設計します。また、長期Memoryの抽出・EmbeddingモデルとContext圧縮モデルはProject作成時に選択し、後から変更できないため、PoC段階でモデルとデータライフサイクルを確認する必要があります。

Oracle AI Agent Memory：既存Agentを維持し、Memory LifecycleをDB上で制御する

　Oracle AI Agent Memory 26.6.0は、既存Agentへ組み込むPython Libraryです。Agent Runtimeを置き換えずに、Message保存、長期Memoryの抽出・統合、短期Context圧縮、検索、Context Card、更新・削除をLibraryへ任せられます。同時に、Oracle AI Database、Model、Scope、抽出Timing、保持方針をアプリケーションから選択できます。既存Agentを維持しながらMemory LifecycleとDatabaseを制御できる点が特徴です。

　公開ベンチマーク：現行のPyPI に公開されたバージョン26.6.0では、LongMemEval 94.4％（472／500）が報告されています。本稿は実装方式に焦点を当てるため、評価条件、カテゴリ別の読み方、PoCの合否条件への落とし込みは次回以降で扱います。

　検索：Vector、Keyword、Hybridを選べます。Hybrid SearchはOracleDBEmbedderとDatabase内のEmbedding Modelを使い、Managed Hybrid Vector Indexを構築します。Keyword SearchはEmbedderなしでも利用でき、検索結果はContext CardとしてAgentへ渡せます。Vector類似度とKeywordを組み合わせるため、固有名詞や識別子を含むMemoryも検索できます。

　データ統合：Message、Memory、Summary、検索用データをOracle AI Databaseへ保存します。Relational、JSON、Vector、Text、Property Graphを一つのDatabaseで扱えるため、要件が合えばMemoryと業務データを同じ基盤へ集約し、権限、監査、Backup、削除を一つの管理境界へ寄せられます。ただし、元のMessage、派生Memory、検索索引は別の論理データとして区別します。

　運用制御：自動抽出と確定済みFactの明示登録を使い分け、抽出頻度、会話Window、同期／Background抽出、Metadata Filter、user／agent／thread Scope、更新・削除を設定できます。LibraryがLifecycleを実行し、抽出Timing、共有範囲、保持方針は利用者が決める構成です。

　2026年7月14日にarXivで公開された論文「Oracle Agent Memory as an Enterprise Memory Substrate for Long-Horizon AI Agents」は、取り込み、抽出、統合、検索、要約、更新・削除を一つのLifecycleとして整理しています。さらに、モデルへ渡すActive Memory Coreと永続的なMemory Storeを分ける階層構造、user・agent・thread単位のScope、Evidence Retrieval、Recall、Latency、Token使用量を合わせて測る評価方法を提示しています。検索品質、コンテキスト量、運用制御を一体で評価する資料として参照できます。

　登録と削除：add_messagesはMessageを保存し、設定に応じてMemoryを自動抽出します。add_memoryは確認済みFactなどの明示登録です。Messageと派生Memoryは別Recordのため、delete_messageでMessageだけを消してもMemoryは残ります。delete_threadはMessage、Durable Memory、Managed Retrieval DataをThread単位で連鎖削除します。PoCでは両方を試し、原本の削除要求をどのAPIへ連鎖させるか決めます。