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

OSSを選ぶなら、「Memoryだけ追加」と「Runtime変更」を分ける

　Mem0、Letta、Graphitiは、扱う記憶と導入範囲が異なります。Mem0はPreference／Fact、LettaはAgent State、Graphitiは時間と関係を持つFactが中心です。比較では、既存AgentへMemoryだけを足すのか、Agent Runtimeまで変更するのかを分けます。

　Mem0：好み、目標、意思決定、フィードバックなど、次回以降も再利用したい情報に向きます。addへ会話を渡すと、既定ではLLMが候補を抽出し、既存Memoryとの重複や矛盾を確認して保存します。次のRequestではsearchを呼び、user／agent／runなどのScopeを指定して回答コンテキストへ渡します。既存Agentへaddとsearchを組み込むだけで始められる点が利点です。

　Mem0 OSSではLLM、Embedder、Vector Store、Rerankerを選び、データを自社環境へ置き、抽出・検索も変更できます。その代わり、可用性、Scaling、Backup、監視、Upgradeは利用者が担います。Mem0 PlatformはこれらをManagedにし、Dashboard、Analytics、Webhooks、Memory Export、Managed Graph、Memory Decayも提供します。

　期限付きの希望条件にはExpirationを設定できます。期限後は通常のsearchとget_allから除外されますが、物理削除ではありません。古いMemoryを残して検索順位だけ下げるのがPlatformのMemory Decayです。Expiration、Decay、Deleteは結果が異なるため、保持要件と削除要件を分けます。

　Letta：プロフィール、現在の目標、作業方針など、Agentが常に参照して自ら更新するStateに向きます。重要で小さい情報はMemory Blockとして毎回Contextへ入れ、過去のEpisodeはArchival Memoryから検索し、大きな資料はFileとして読みます。長期Taskを引き継ぐAI Coworkerでは、好み、途中状態、守るべき手順を同じAgent Stateとして継続できます。

　会話履歴とMemoryをServerが保持するため、アプリケーションは新しいMessageだけを送ります。Letta Cloudは運用をManagedにし、Letta App Serverを自社運用する場合はRuntime、Database、Model、Embedding、Backup、Securityを管理します。Memory APIの追加ではなくStateful Agent Runtimeへの移行になるため、長期稼働するAgentには強力ですが、既存Agentを維持する場合は移行範囲が大きくなります。

　Graphiti：担当者、所属、契約状態など、「何と何がどう関係し、いつまで正しかったか」を扱う記憶に向きます。Message、Text、JSONをEpisodeとして取り込み、EntityとFactを抽出し、Factに有効期間とProvenanceを持たせます。Semantic Search、Keyword Search、Graph Traversalを組み合わせ、現在だけでなく過去時点の関係も検索できます。

　Graphiti OSSではGraph Database、LLM、Embedding、Ontology、検索条件を選べますが、User／Thread管理、Scaling、監視、Security、低Latency運用は利用者が構築します。ZepはContext GraphをManagedで提供し、抽出、保存、検索、Governance、Dashboard、User／Thread管理をまとめます。独自Ontologyと抽出指示も設定できます。

既存データからMemory化と「忘却」

　この節では、既存データの取り込みと、不要になったMemoryを使わなくする処理を分けます。取り込み方は、①過去のMessage／Eventを発生順に再生して抽出する、②確認済みFact／SummaryをMemory Recordとして直接登録する、③CRM／TicketをSource of Truthのまま残し、必要時に検索する、の三つです。すべての履歴を必ずMemoryへ変換するわけではありません。

　Microsoft Foundryは会話からの抽出とMemory Item作成、AWS AgentCoreはEvent処理とBatchCreateMemoryRecords、DatabricksはMemory EntryのREST登録、Oracle AI Agent Memoryはadd_messagesとadd_memory、Mem0は会話抽出とinfer=Falseを使い分けます。Graphiti／ZepはMessage、Text、JSONのEpisodeを取り込めます。一方、OCIの長期Memoryは会話からの抽出であり、任意のRecordを直接一括登録する方式とは区別します。

　過去データにはUser／Tenant Scope、発生日時、元データIDを保持し、古い順に処理します。順序を失うと、過去の住所や希望条件が最新Factとして残り得ます。Graphitiのadd_episode_bulkは空Graphの初期投入には使えますがEdge Invalidationを行わないため、変更履歴が重要なら時系列のadd_episodeで検証します。ZepのBatch APIではcreated_atを付け、Factのvalid_at／invalid_atへ反映させます。

　「忘却」は目的の異なる五つの処理です。①CompactionはContextから外す、②Decayは検索順位を下げる、③Invalidationは旧Factを失効させる、④Expiration／TTLは期限後に通常検索から外す、⑤Delete／Purgeは物理的に消します。Mem0 PlatformのDecay、GraphitiのInvalidation、MicrosoftのEntry TTL、AWSのRaw Event Expiry、Mem0 Expirationは別の要件を満たすため、一つを実装しても残りを満たしたことにはなりません。

　連絡先変更では旧値を回答コンテキストから外しつつ、履歴として残せます。一方、個人情報の削除要求では、Raw Message、派生Memory、Embedding、Graph Fact、全文・Vector検索索引まで削除対象になり得ます。訂正、順位調整、保存期限、物理削除を同じ「忘却」という言葉だけで実装しないことが重要です。

公開実装の一例：Grok Buildの記憶を古くして、整理し、消す仕組み

　保存構造：Agent Memoryの忘却は、古いデータを一定期間後に削除するだけではありません。Grok Buildの公開実装では、「古い会話を現在のContextから外す」「時間とともに思い出しにくくする」「残す情報を整理する」「不要な記憶を削除する」が別の処理として実装されています。以下は、2026年7月27日に確認した公開ソースツリー（xai-grok-shell 0.2.112）の実装です。Sessionをまたいで利用するMemoryは実験機能で、既定では無効です。MemoryはGlobal、Workspace、Sessionの３つのScopeに分かれ、記憶の実体はMarkdownファイル、検索用索引はWorkspaceごとのSQLite Databaseに保存されます。検索はSQLite FTS5による全文検索を基本とし、Embeddingとsqlite-vecを利用できる場合はvec0によるVector検索も組み合わせます。利用できなければ全文検索だけで動作します。WatcherはMemoryファイルの作成・変更・削除を検知し、次回のmemory_searchで索引を同期します。したがってSQLite Databaseは記憶の原本ではなく、Markdownファイルから作られる検索用の派生データです。

　時間経過と再編成：会話が長くなると、Compactionが古いTurnを現在のContextから外します。これに対し、Session Memoryはすぐに削除せず、検索Scoreへ時間減衰係数を掛けます。既定の半減期は7日で、7日後には約2分の1、14日後には約4分の1になります。Global MemoryとWorkspace Memoryは減衰の対象外です。さらに、既定ではSession終了時にDreamの実行条件を確認します。新しいSession Logが3件以上あり、前回の統合から4時間以上経過している場合、DreamはSession Logと既存のWorkspace MemoryをLLMへ渡し、関連情報の統合、新情報と矛盾する古い記述の除外、一時情報の除去を指示します。その出力でWorkspaceのMEMORY.mdを更新し、成功後に処理済みLogの削除を試みます。ただし直近5分以内に更新されたLogは削除せず、実際に削除できたLogについてのみ、対応するSQLite索引Entryを消去します。

　削除とDatabase設計：削除方法はScopeによって異なります。grok memory clear --workspaceは、WorkspaceのMEMORY.md、Session Log、index.sqliteを含むMemory Directoryを削除します。--globalが直接削除するのはGlobalのMEMORY.mdで、対応する索引はWatcherによる次回検索時の同期、または次回Session開始時の再索引で更新されます。自然言語によるForgetは、該当Entryを検索して削除を試みるbest-effortの処理です。この実装から、業務Agentでも、元の会話履歴、抽出したMemory、全文検索・Vector検索の索引を対応付け、更新や削除をどこまで反映するかを決める必要があると分かります。Relational、JSON、全文検索、Vector検索を一つのDatabaseで扱えれば、複数Store間の同期を減らし、権限管理や削除処理を一つの管理境界へまとめやすくなります。ただし同じDatabaseに保存しても、元データ、派生Memory、検索索引は別の論理データとして管理します。

記憶の種類・データ表現・製品を同じ言葉で呼ばない

　Agentの記憶の実装と一言で言っても、扱う範囲は様々あります。「何を覚えるか」「どの形式で保存するか」「どの製品で運用するか」を同じ階層で話さずに分類して1つずつ整理する必要があります。表1では、利用目的、記憶内容、構築、表現、取得、運用、技術基盤、責任分界、評価の順に並べました。業務上の目的と記憶内容を先に決め、その後に実装方式と製品を当てはめます。

表1　Agent Memoryの選定会議で確認する9の論点

　Working／短期／長期は保持期間とコンテキスト上の位置、Episodic、Semantic、Proceduralは出来事、事実・概念、手順という内容の違いです。Document、Key-Value、Relational／JSON、Vector、Graphは保存・検索の表現です。一つのMemoryが複数の分類に属するため、これらを一列の選択肢として扱わないことが重要です。

　「顧客が連絡方法をメールから電話へ変更した」という一件では、Episodic Memoryは変更依頼、Semantic Memoryは現在値＝電話、Procedural MemoryはCRM更新と旧Memory失効の手順です。原文はDocument、現在値はRelational／JSON、意味検索にはVector索引、変更関係にはTemporal Graphを使えます。Catalogは所在、Schema、Provenance、権限を管理するMetadata層です。

　用語を網羅すること自体が目的ではありません。選定会議では、一つの業務例を使って次の三つを作ります。

• Memory定義書：何を再利用するか、Source of Truthはどこか、どのScopeで共有し、いつ更新・失効・削除するかを記載する
• 責任境界図：入力、抽出・統合、保存、検索、回答コンテキストへの反映、更新・削除を、製品とアプリケーションのどちらが担うか示す
• PoC試験と合否条件：Write、Recall、Update、Invalidate、Delete、Scopeを実データで再現し、回答品質、旧Fact利用率、Scope越境、削除時間、Latency、Token、基盤Costの許容値を決める

まとめ：何を記憶し、どこまで製品に任せるか

　Agent Memoryの実装方式は、製品名や機能数だけでは選べません。既存Agentを維持してMemory機能を追加するのか、Managed Memory APIを組み合わせるのか、Agentの実行・状態管理を含むPlatform／Runtimeへ移行するのかによって、アプリケーション側に残る実装と運用が変わります。同じクラウド製品でも利用方式によって責任範囲が異なるため、サービス単位ではなく、実際に採用する方式単位で確認する必要があります。

　本稿では、その責任範囲を、入力・Scope、Memory抽出、統合・表現、保存、検索、回答コンテキストへの反映、保持・更新・削除、Agent実行・状態管理の8工程に分けて整理しました。製品に任せる工程が多ければ導入時の実装を減らせますが、製品が定めるSchemaや検索方法、更新単位に沿う必要があります。LibraryやOSSを組み込む方式では、抽出条件、保存先、検索方法を業務に合わせて設計できる一方、その品質と運用は利用者が担います。

　また、Memoryの「忘却」も単一の機能ではありません。回答コンテキストから外す、検索順位を下げる、古いFactを失効させる、保持期限を設定する、データを削除するといった処理では、目的も対象データも異なります。製品を比較するときは、Memoryを作成・検索できるかだけでなく、訂正、失効、保持期限、削除をどの単位で制御できるかまで確認することが重要です。

　ここまでで、Agent Memoryを「どの方式で実装するか」を判断するための選択肢と責任範囲を整理できました。しかし、製品に任せる範囲を決めただけでは、そのMemoryが必要な情報を正しく思い出し、古い情報を適切に更新できるかまでは判断できません。

　次回以降は、LongMemEvalやBEAMなどのAgent Memoryベンチマークが、想起、時間関係の理解、情報更新、複数Sessionをまたぐ記憶をどのように評価しているのかを整理します。そのうえで、公開ベンチマークの数値を製品順位として読むのではなく、自社データを用いたPoCの評価項目と合否条件へ落とし込む方法を取り上げます。