はじめに
LLM（Large Language Model）を搭載した AI エージェントは、コード生成や対話、意思決定など多様なタスクをこなします。
しかし、コンテキストウィンドウの制限により、エージェントが過去の経験や知識を長期的に保持・活用することは容易ではありません。
この課題に対する有力なアプローチが「グラフベースメモリ」です。
エンティティ間の関係性をノードとエッジで表現し、構造化された形で記憶を保持します。
単純なテキスト検索では失われがちな因果関係や時系列の文脈を、グラフ構造が自然に捉えます。
本記事では、サーベイ論文「A Survey on Graph-based Agentic Memory」（arXiv:2602.05665）を軸に、MAGMA（arXiv:2601.03236）と DeepImageSearch（arXiv:2602.10809）の 2 つの具体的アーキテクチャも参照しながら、グラフベースエージェントメモリの設計パターンを包括的に解説します。
この記事を読むことで、以下の知識が得られます。
- エージェントメモリの分類体系と設計上の判断基準
- 5 つのグラフ構造パターンの特徴と使い分け
- メモリのライフサイクル（抽出・格納・検索・進化）の具体的な設計手法
- 実世界のシステム（MAGMA、DeepImageSearch）における実装アプローチ
- 主要なオープンソースライブラリとベンチマークの選定指針
従来のエージェントメモリの限界
エージェントメモリの設計には、従来いくつかの代表的なアプローチが存在します。
それぞれの特徴と限界を整理します。
テキストベースメモリの課題
最もシンプルなアプローチは、過去の会話やドキュメントをテキストとして蓄積し、RAG（Retrieval-Augmented Generation）で検索する方法です。
テキストをチャンクに分割し、ベクトル埋め込みを計算して類似度検索を行います。
この方法には、以下の限界があります。
- 関係性の喪失: エンティティ間の因果関係や依存関係がフラットなテキストでは表現できない
- 時系列の欠落: いつ、どの順序で情報が得られたかの文脈が失われる
- 冗長性の蓄積: 同じ情報が異なる表現で何度も格納され、矛盾が発生する
- 推論の困難: 複数の事実を組み合わせたマルチホップ推論が難しい
Key-Value ストアの課題
構造化された Key-Value 形式で記憶を管理する方法もあります。
検索は高速ですが、キー間の関係性を表現する手段がありません。
「ユーザー A は Python を好む」「ユーザー A はデータ分析を担当している」という 2 つの事実を個別に格納できても、これらを統合した推論は別途ロジックが必要です。
グラフベースメモリが解決すること
グラフベースメモリは、これらの限界を構造的に解決します。
ノードがエンティティや概念を、エッジがそれらの関係性を表現します。
この構造により、以下が可能になります。
- 関係性の明示的な表現: 「A は B に依存する」「C は D の原因である」をエッジで直接表現
- 時系列の保持: タイムスタンプ付きエッジで情報の時間的順序を維持
- 矛盾の検出と解消: 同一エンティティに関する矛盾した情報をグラフ上で検出
- マルチホップ推論: グラフトラバーサルにより、複数の事実を連鎖的にたどった推論が可能
グラフベースメモリの分類体系
エージェントメモリを設計する際、まず全体の分類体系を理解する必要があります。
サーベイ論文では、3 つの軸で分類しています。
時間的範囲による分類
メモリは時間的な持続性に基づいて 3 つに分類されます。
| 分類 | 持続時間 | 用途 | 実装例 |
|---|---|---|---|
| 感覚メモリ（Sensory） | 数秒以下 | 直近の入力バッファリング | 現在のプロンプト、直近の API レスポンス |
| 短期メモリ（Short-term） | タスク実行中 | 作業記憶、一時的な状態管理 | 会話履歴、スクラッチパッド |
| 長期メモリ（Long-term） | 永続 | 知識・経験の蓄積 | ナレッジグラフ、ユーザープロファイル |
人間の記憶モデルと同様に、感覚メモリから短期メモリへ、短期メモリから長期メモリへと情報が選択的に転送されます。
グラフベースメモリは主に長期メモリの実装に用いられますが、短期メモリとの連携設計も重要です。
内容による分類
メモリに格納する内容は、大きく 2 種類に分かれます。
知識メモリ（Knowledge Memory） は、事実や概念に関する宣言的な情報です。
「Python は動的型付け言語である」「Kubernetes はコンテナオーケストレーションツールである」といった情報が該当します。
ナレッジグラフとして構造化されることが多く、エンティティ間の is-a 関係や has-a 関係を表現します。
経験メモリ（Experience Memory） は、エージェントの行動履歴や手続き的な知識です。
「このエラーに対して X という手順で解決した」「ユーザーは Y 形式のレスポンスを好む」といった、行動とその結果の記録です。
時系列グラフやエピソードグラフとして構造化されます。
構造による分類
メモリの構造は、非構造化と構造化に大別されます。
グラフベースメモリは構造化メモリの一種です。
非構造化メモリと比較して、検索効率と推論能力に優れますが、構築コストが高くなります。
メモリグラフの 5 つの構造パターン
グラフベースメモリの核となるのが、グラフ構造の選択です。
サーベイ論文では、5 つの構造パターンを整理しています。
それぞれの特徴、適用場面、トレードオフを解説します。
ナレッジグラフ（Knowledge Graph）
最も広く使われる構造です。
エンティティをノード、関係性をエッジとしたトリプル（主語, 述語, 目的語）で知識を表現します。
特徴:
- RDF やプロパティグラフなど、成熟したデータモデルが利用可能
- SPARQL や Cypher などの問い合わせ言語でパターンマッチングが可能
- 大規模な知識ベースとの統合が容易（Wikidata、DBpedia など）
適用場面:
- 技術ドキュメントの知識管理
- ドメイン固有の概念体系の構築
- FAQ やヘルプデスクの知識ベース
トレードオフ:
- エンティティと関係の抽出精度が品質を左右する
- 時間的な変化の表現にはタイムスタンプの付与が別途必要
- 大規模化するとグラフの管理・更新コストが増大する
階層グラフ（Hierarchical Graph / DAG）
有向非巡回グラフ（DAG）として、情報を抽象度の異なるレイヤーで階層化します。
特徴:
- 異なる抽象レベルで同じ情報を参照可能
- トップダウン検索（概要→詳細）とボトムアップ検索（詳細→概要）の両方をサポート
- 情報の粒度を明示的に管理できる
適用場面:
- タスク分解と進捗管理（高レベル目標 → サブタスク → 具体的手順）
- ドキュメントの階層的な要約
- マルチエージェントシステムでの責任分担
時系列グラフ（Temporal Graph）
時間情報を組み込んだグラフ構造です。
サーベイでは 2 つのバリエーションを紹介しています。
Bi-temporal Graph は、事実が成立した期間（valid time）と記録された時点（transaction time）の 2 つの時間軸を管理します。
(Alice, works_at, Company_A, valid: 2020-2023, recorded: 2023-01)
(Alice, works_at, Company_B, valid: 2023-present, recorded: 2023-06)
Temporal Knowledge Graph（TKG） は、トリプルにタイムスタンプを追加した四つ組（quadruple）で知識を表現します。
(Alice, promoted_to, Senior Engineer, 2024-Q1)
特徴:
- 情報の鮮度を管理でき、古い情報の自動的な優先度低下が可能
- 「いつ時点での情報か」を明確に追跡できる
- 変化のパターン（トレンド）を検出できる
適用場面:
- 会話の文脈追跡（誰がいつ何を言ったか）
- ユーザーの嗜好変化の追跡
- インシデント対応の時系列記録
ハイパーグラフ（Hypergraph）
通常のグラフでは 1 つのエッジが 2 つのノードを接続しますが、ハイパーグラフでは 1 つのハイパーエッジが任意の数のノードを同時に接続します。
ハイパーエッジ: "チームミーティング_2024-01-15"
接続ノード: [Alice, Bob, Carol, 議題X, 決定事項Y]
特徴:
- 多対多の関係を 1 つのエッジで自然に表現できる
- 複合的なイベントやコンテキストの表現に優れる
- 通常のグラフでは複数のエッジに分解が必要な関係を一体的に扱える
適用場面:
- 複数の参加者が関わるイベントの記録
- 論文の共著関係やプロジェクトの共同作業の表現
- 複合条件のルール表現
トレードオフ:
- 標準的なグラフデータベースでは直接サポートされないことが多い
- 検索クエリの設計が複雑になりやすい
ハイブリッドグラフ（Hybrid Graph）
上記の構造を組み合わせたアーキテクチャです。
実際のシステムでは、単一の構造では要件を満たせないことが多く、複数のグラフ構造を統合する設計が現実的です。
後述する MAGMA は、4 つの異なるグラフ（意味グラフ、時系列グラフ、因果グラフ、エンティティグラフ）を並列に管理するハイブリッドアーキテクチャの代表例です。
以下の表に、5 つの構造パターンの比較をまとめます。
| 構造 | 表現力 | 検索効率 | 実装の容易さ | 代表的なユースケース |
|---|---|---|---|---|
| ナレッジグラフ | 中 | 高 | 高 | 知識管理、FAQ |
| 階層グラフ | 中 | 高 | 中 | タスク分解、要約 |
| 時系列グラフ | 高 | 中 | 中 | 会話追跡、変化検出 |
| ハイパーグラフ | 最高 | 低 | 低 | 複合イベント、多対多関係 |
| ハイブリッド | 最高 | 中 | 低 | 実運用システム全般 |
MAGMA: マルチグラフによる関係性の分離
MAGMA（Memory-Augmented Graph-based Multi-Agent Architecture）は、グラフベースメモリの設計における先進的なアーキテクチャです。
論文（arXiv:2601.03236）で提案されたこのシステムは、4 つの直交するグラフレイヤーで記憶を管理します。
4 つのグラフレイヤー
MAGMA の核心は、異なる種類の関係性を別々のグラフに分離する設計です。
セマンティックグラフ（Semantic Graph） は、概念間の意味的な関連性を管理します。
トピックの類似性や上位・下位関係を表現し、意味ベースの検索を支えます。
テンポラルグラフ（Temporal Graph） は、イベントの時間的順序と因果的な連鎖を記録します。
「何がいつ起こり、何の後に続いたか」を追跡します。
コーザルグラフ（Causal Graph） は、原因と結果の関係を明示的にモデル化します。
「なぜそうなったか」という因果推論を可能にします。
エンティティグラフ（Entity Graph） は、人物・組織・ツールなどの実体間の関係を管理します。
社会的ネットワークや組織構造の表現に使われます。
デュアルストリームメモリ進化
MAGMA のもう 1 つの重要な設計が、2 つの速度で記憶を更新するデュアルストリーム方式です。
高速ストリーム（Fast Synaptic Ingestion） は、新しい情報を即座に短期メモリに取り込みます。
構造化の処理を後回しにして、リアルタイム性を優先します。
低速ストリーム（Slow Structural Consolidation） は、短期メモリの情報を分析し、既存のグラフ構造に統合します。
重複の検出、矛盾の解消、関係性の推論を行い、長期メモリの品質を維持します。
この設計は、人間の脳における海馬（短期記憶）と新皮質（長期記憶）の関係に着想を得ています。
適応的トラバーサルポリシー
検索時には、クエリの意図に応じてグラフの探索戦略を動的に切り替えます。
- 事実確認型クエリ: エンティティグラフとセマンティックグラフを優先的に探索
- 時系列追跡型クエリ: テンポラルグラフを中心に探索
- 原因分析型クエリ: コーザルグラフを起点にマルチホップ推論
各グラフレイヤーのエッジに意図認識型の重みを付与し、クエリの種類に応じて探索の優先度を調整します。
ベンチマーク結果
MAGMA は LoCoMo ベンチマークで 0.700 のスコアを達成しています。
これは従来のベースライン手法（Full Context: 0.563、RAG: 0.542）を大幅に上回る結果です。
特に、マルチホップ推論を要する質問と時系列追跡の質問で大きな改善が見られました。
メモリのライフサイクル設計
グラフベースメモリの運用には、4 つのフェーズからなるライフサイクルの設計が必要です。
抽出（Extraction）
生の情報源からグラフの要素（ノード、エッジ、属性）を抽出するフェーズです。
抽出手法は 3 つに分類されます。
LLM ベースの抽出 は、大規模言語モデルを使ってテキストからエンティティと関係を抽出します。
プロンプトエンジニアリングにより、抽出対象のスキーマを指定できます。
以下は、LLM を使った関係抽出の擬似コードです。
from openai import OpenAI
client = OpenAI()
def extract_relations(text: str) -> list[dict]:
"""テキストからエンティティと関係を抽出する"""
prompt = f"""
以下のテキストからエンティティと関係を抽出してください。
出力形式: [{{"subject": "...", "predicate": "...", "object": "..."}}]
テキスト: {text}
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"},
)
return response.choices[0].message.content
ルールベースの抽出 は、正規表現や構文解析で特定のパターンを検出します。
精度は高いですが、カバレッジが限定的です。
ハイブリッド抽出 は、LLM とルールベースを組み合わせます。
LLM で広範に抽出し、ルールベースで精度を補完する方式が効果的です。
格納（Storage）
抽出した情報をグラフデータベースに格納するフェーズです。
格納時には以下の設計判断が必要です。
- ノードの粒度: 文単位か、エンティティ単位か、チャンク単位か
- エッジの型定義: 自由記述か、事前定義されたスキーマか
- メタデータ: タイムスタンプ、信頼度スコア、ソース情報の付与
- インデックス: ベクトルインデックス（意味検索用）とグラフインデックス（構造検索用）の併用
実装では、Neo4j や FalkorDB などのグラフデータベースにプロパティグラフとして格納するのが一般的です。
検索（Retrieval）
格納されたメモリから、クエリに関連する情報を取得するフェーズです。
検索パラダイムの詳細は次章で解説します。
進化（Evolution）
メモリの品質を継続的に向上させるフェーズです。
進化メカニズムの詳細は後述しますが、グラフの統合・圧縮・矛盾解消が主な処理です。
以下の図に、ライフサイクル全体の流れを示します。
検索の 3 つのパラダイム
グラフベースメモリからの情報検索には、大きく 3 つのパラダイムがあります。
それぞれ異なる強みを持ち、実際のシステムでは複数を組み合わせて使用します。
セマンティック検索（Semantic Retrieval）
ベクトル埋め込みを使った類似度ベースの検索です。
クエリとメモリの意味的な近さに基づいて関連情報を取得します。
基本的な仕組み:
- グラフのノードやエッジの情報をテキストに変換する
- テキストのベクトル埋め込みを計算する
- クエリのベクトル埋め込みとのコサイン類似度を計算する
- 類似度の高い上位 K 件を返す
グラフ特有の拡張として:
- グラフ埋め込み: Node2Vec や TransE などのアルゴリズムで、グラフ構造を考慮した埋め込みを生成
- サブグラフ検索: ヒットしたノードの周辺ノード（1-hop、2-hop 近傍）も合わせて返す
- コミュニティ検索: グラフのクラスタリング結果を活用し、関連するコミュニティ全体を返す
構造化検索（Structured Retrieval）
グラフの構造的な特性を活用した検索です。
ルールベース検索 は、事前定義されたパターンやテンプレートに基づいて検索します。
// Neo4j Cypher クエリの例: 特定の人物の関連情報を2ホップで取得
MATCH (p:Person {name: "Alice"})-[r*1..2]-(related)
RETURN p, r, related
時系列検索 は、タイムスタンプに基づいて特定期間の情報を取得します。
// 特定期間のイベントを時系列順に取得
MATCH (e:Event)
WHERE e.timestamp >= datetime("2024-01-01")
AND e.timestamp <= datetime("2024-03-31")
RETURN e ORDER BY e.timestamp
グラフトラバーサル は、特定のノードを起点にグラフを探索し、関連する情報をたどります。
BFS（幅優先探索）や DFS（深さ優先探索）、最短パスアルゴリズムなどが使われます。
ポリシーベース検索（Policy-based Retrieval）
強化学習やエージェントベースの手法で、検索戦略を動的に最適化します。
強化学習ベース の手法では、検索結果の品質をリワードとして、検索パラメータ（取得数、深さ、フィルタ条件）を自動調整します。
エージェントベース の手法では、専用の検索エージェントがクエリを分析し、最適な検索戦略を選択・実行します。
MAGMA の適応的トラバーサルポリシーもこの分類に該当します。
以下の表に、3 つのパラダイムを比較します。
| パラダイム | 強み | 弱み | 適用場面 |
|---|---|---|---|
| セマンティック | 意味的な類似性に強い | 構造的な関係を見逃す | オープンドメインの質問応答 |
| 構造化 | 正確なパターンマッチング | 柔軟性に欠ける | 定型的なクエリ、時系列分析 |
| ポリシーベース | 動的に最適化される | 学習コストが高い | 複雑なマルチホップ推論 |
メモリの進化メカニズム
グラフベースメモリは、格納後も継続的に進化させる必要があります。
サーベイ論文では、進化メカニズムを「内部的な自己進化」と「外部的な自己探索」の 2 つに分類しています。
内部的な自己進化（Internal Self-evolving）
メモリ内部の処理だけで品質を向上させる手法です。
統合（Consolidation） は、関連する記憶を統合し、冗長性を削減します。
同じエンティティに関する複数のノードをマージしたり、類似したエッジを統合したりします。
グラフ推論（Graph Reasoning） は、既存のエッジから新しい関係を推論します。
「A は B の上司」かつ「B は C の上司」から「A は C の上位管理者」を推論するようなトランジティブな関係の導出です。
再構成（Reorganization） は、グラフの構造自体を見直します。
使用頻度の低いノードの削除、頻繁にアクセスされるサブグラフのインデックス最適化、階層構造の調整などが含まれます。
外部的な自己探索（External Self-exploration）
外部からのフィードバックやアクティブな情報収集によってメモリを改善する手法です。
フィードバック駆動型 は、エージェントの出力に対するユーザーフィードバックをメモリに反映します。
「この回答は不正確だった」というフィードバックから、関連するノードの信頼度スコアを下げるといった処理です。
アクティブ探索型 は、メモリの空白領域やあいまいな部分を検出し、自発的に情報を収集します。
「ユーザーの技術スタックについて情報が不足している」と判断した場合に、次の対話で質問を投げかけるといった動作です。
MAGMA のデュアルストリーム方式は、この進化メカニズムを効果的に実現しています。
高速ストリームで即座に情報を取り込み、低速ストリームで構造的な統合と品質向上を行うことで、リアルタイム性と品質を両立しています。
実世界での応用: DeepImageSearch の事例
理論的な分類体系を実際のシステムでどう活用するか、DeepImageSearch（arXiv:2602.10809）の事例で見ていきます。
このシステムは、ユーザーの写真コレクションに対する自然言語クエリ検索を実現するもので、グラフベースメモリの実践的な応用例です。
メモリグラフの構造
DeepImageSearch では、写真コレクションの情報を 4 種類のノードで表現します。
- Photo: 個々の写真。撮影日時、場所、キャプションなどのメタデータを持つ
- PhotoSet: 写真のグループ。旅行、イベントなどの単位
- VisualClue: 写真に含まれる視覚的な手がかり。場所、物体、シーンなど
- Person: 写真に写っている人物
これらのノード間の関係をエッジで表現することで、「パリ旅行で Alice と一緒に撮った夕焼けの写真」のような複合的なクエリに対応できます。
デュアルメモリシステム
DeepImageSearch は、2 種類のメモリを使い分けます。
明示的状態メモリ（Explicit State Memory） は、ユーザーの検索状態を構造化して保持します。
検索対象の条件（人物、場所、時期など）を JSON 形式で管理し、対話の進行に応じて更新します。
圧縮コンテキストメモリ（Compressed Context Memory） は、過去の対話履歴を要約して保持します。
全会話履歴をそのまま持つのではなく、重要な情報だけを圧縮して保持することで、コンテキストウィンドウの制限に対応します。
ImageSeeker エージェント
検索を実行する ImageSeeker エージェントは、以下のツールを使いこなします。
- search_photos: メモリグラフに対するクエリを実行
- view_photo: 特定の写真の詳細情報を取得
- view_photoset: アルバム単位の情報を取得
- ask_user: ユーザーに追加情報を質問
エージェントはユーザーのクエリを分析し、適切なツールを選択してグラフを探索します。
「去年の夏に海に行った写真」というクエリに対して、テンポラルグラフで時期を絞り込み、VisualClue ノードで「海」に関連する写真を特定します。
この事例は、グラフベースメモリが単なる知識管理だけでなく、マルチモーダルな情報検索にも効果的であることを示しています。
実装に向けて: ライブラリとベンチマーク
グラフベースエージェントメモリを実装する際に活用できるオープンソースライブラリと、評価に使えるベンチマークを紹介します。
主要なオープンソースライブラリ
サーベイ論文では 11 のライブラリが紹介されています。
ここでは特に重要な 6 つを取り上げます。
| ライブラリ | 特徴 | グラフサポート | GitHub Stars |
|---|---|---|---|
| Mem0 | ユーザーレベルのメモリ管理に特化。自動的な記憶の追加・更新・削除 | ナレッジグラフ | 25k+ |
| Graphiti | Zep が開発。時系列ナレッジグラフに強み。エピソード記憶とセマンティック記憶の統合 | 時系列 + ナレッジグラフ | 3k+ |
| Cognee | ECL（Extract-Cognify-Load）パイプラインで構造化メモリを自動構築 | ナレッジグラフ | 2k+ |
| LangMem | LangChain エコシステムと統合。メモリの形成・更新・削除の標準化 API | ナレッジグラフ | 1k+ |
| OpenMemory | MCP（Model Context Protocol）サーバーとして動作。エージェント横断のメモリ共有 | 汎用 | 1k+ |
| MemoryScope | 長期対話向け。バイリンガル対応、反射的・統合的メモリ管理 | 汎用 | 500+ |
Mem0 は、最もスター数が多く、導入の容易さが特徴です。
以下は Mem0 でグラフメモリを利用する基本的な例です。
from mem0 import Memory
# グラフメモリの設定
config = {
"graph_store": {
"provider": "neo4j",
"config": {
"url": "bolt://localhost:7687",
"username": "neo4j",
"password": "password",
},
},
"version": "v1.1",
}
m = Memory.from_config(config)
# メモリの追加
m.add(
"Alice は Python と TypeScript が得意で、現在マイクロサービスの設計を担当している",
user_id="alice",
)
# メモリの検索
results = m.search("Alice の技術スタック", user_id="alice")
for result in results:
print(result)
Graphiti は、時系列の扱いに特化しています。
エピソード（会話や出来事）を時系列に沿って記録し、そこからエンティティや関係を自動抽出してナレッジグラフに統合します。
from graphiti_core import Graphiti
from datetime import datetime
# Graphiti の初期化
graphiti = Graphiti(
neo4j_uri="bolt://localhost:7687",
neo4j_user="neo4j",
neo4j_password="password",
)
# エピソードの追加（時系列情報付き）
await graphiti.add_episode(
name="meeting_2024_01",
episode_body="Alice がチームに Kubernetes への移行計画を提案した。Bob は懸念を示したが、最終的にチームは移行に合意した。",
source_description="チームミーティング議事録",
reference_time=datetime(2024, 1, 15),
)
# 検索
results = await graphiti.search("Kubernetes 移行の経緯")
ベンチマークの選定
サーベイ論文では 53 以上のベンチマークが紹介されています。
用途に応じた代表的なベンチマークを以下に示します。
| カテゴリ | ベンチマーク | 評価内容 |
|---|---|---|
| 長期対話 | LoCoMo | 長期会話からの情報検索・推論 |
| 長期対話 | LongMemEval | 長期メモリの 5 つの能力（情報抽出、マルチセッション推論、時系列推論、知識更新、拒否判断） |
| 知識グラフ | FB15k-237 | ナレッジグラフの補完（リンク予測） |
| パーソナライゼーション | LaMP | ユーザープロファイルに基づく応答のパーソナライズ |
| マルチエージェント | Sotopia | 社会的インタラクションにおけるメモリの活用 |
特に LoCoMo と LongMemEval は、エージェントメモリの総合的な能力を評価するのに適しています。
MAGMA が LoCoMo で従来手法を大幅に上回った結果は、グラフベースアプローチの有効性を示す重要な証拠です。
まとめ
本記事では、グラフベースエージェントメモリの設計パターンを包括的に解説しました。
重要なポイントを振り返ります。
分類体系の理解が設計の出発点です。
時間的範囲（感覚・短期・長期）、内容（知識・経験）、構造（非構造化・構造化）の 3 軸でメモリを分類し、要件に合った設計を選択しましょう。
グラフ構造の選択はトレードオフです。
ナレッジグラフは汎用性が高く導入しやすい一方、時系列やハイパーグラフはより豊かな表現力を提供します。
実運用では MAGMA のようなハイブリッドアプローチが有力な選択肢です。
メモリのライフサイクル全体を設計する必要があります。
抽出・格納・検索・進化の 4 フェーズを一貫して設計し、特に進化メカニズムによる品質維持が長期運用の鍵となります。
検索パラダイムの組み合わせが性能を決めます。
セマンティック検索、構造化検索、ポリシーベース検索を適材適所で組み合わせることで、多様なクエリに対応できます。
実装にはオープンソースライブラリを活用しましょう。
Mem0、Graphiti、Cognee などのライブラリが成熟しつつあり、ゼロからの実装よりも既存のフレームワークを活用する方が効率的です。
グラフベースメモリは、エージェントが真に知的な長期記憶を持つための有力なアプローチです。
本記事で紹介した設計パターンを参考に、自身のエージェントシステムにメモリ機能を組み込んでみてください。
参考文献
- A Survey on Graph-based Agentic Memory — グラフベースエージェントメモリのサーベイ論文
- MAGMA: Multi-Graph Multi-Agent Memory Architecture — マルチグラフメモリアーキテクチャ
- DeepImageSearch: A Memory-Augmented Agent for Visual Search — 視覚検索向けメモリグラフの応用