6月26日、Emmimalが「Vector RAG Isn't Enough — I Built a Context Graph Layer for Multi-Agent Memory」と題した記事を公開した。マルチエージェントシステムにおけるクロスエージェントメモリの限界を、コンテキストグラフ層の実装とベンチマーク比較によって検証した実践的な取り組みだ。結論から言えば、コンテキストグラフを導入することで精度が38.9ポイント向上し、トークン消費は約18倍削減できたという。
なぜ今、マルチエージェントのメモリ管理が課題になっているのか
LLMを複数組み合わせたマルチエージェントシステムの実用化が進む2026年時点において、エージェント間の「記憶の引き継ぎ」は未解決の重要課題として認識されつつある。単一エージェントであればコンテキストウィンドウ内で完結するやり取りも、複数エージェントが長期にわたってバトンをつなぐ構成では、「あるエージェントが下した決定を、別のエージェントが後から正確に参照できるか」という問題が浮上する。
既存のアプローチとしては、Knowledge Graph（Neo4jなどに代表されるグラフデータベース技術）を用いた構造化知識の管理がある。Emmimalが提案する「コンテキストグラフ」はこれと近い発想に基づくが、汎用的な知識ベースの構築ではなく、マルチエージェントの会話セッション内で生じた決定・依存関係・担当割り当てをリアルタイムに記録・取得することに特化した軽量な実装として位置づけられる。
ベクトルRAGが壊れる場所
Emmimalが問題に気づいたのは、3エージェント構成のパイプラインを動かしていたときだ。Agent_PlannerがPostgreSQLを使う決定を下し、その後20ターンほど「了解」「確認します」といったやり取りが続く。最終的にAgent_Reviewerが「ストレージ技術は何でしたっけ？」と尋ねると、生のトランスクリプト全体がコンテキストウィンドウに収まっているにもかかわらず、エージェントは正確に答えられない。
モデルの限界だと思いがちだが、そうではない。これはメモリアーキテクチャの構造的な問題だ。
ベクトル検索に切り替えるとノイズは減るが、別の天井にぶつかる。ベクトルストアは「クエリに意味的に近いチャンク」を返すが、チャンク間の関係性は返せない。「ある決定に関する情報」と「その依存関係に関する情報」が別チャンクに分かれていれば、どれだけ高精度な埋め込みモデルを使っても、2つを組み合わせた回答は生成できない。
コンテキストグラフとは何か
フラットなメモリ（生トランスクリプトもベクトルインデックスも）は、すべての発言を独立したテキスト単位として扱う。
コンテキストグラフはこの構造を根本から変える。記憶をエンティティ（ノード）と型付きの関係（エッジ）として保持する：
AuthModule→DEPENDS_ON→RateLimiterAgent_Implementer→ASSIGNED_TO→AuthModule
Knowledge Graphが静的な世界知識を格納するのに対し、コンテキストグラフはあくまでセッション内の動的な決定・関係を逐次記録する点が異なる。取得はキーワードマッチングや意味ベクトルの検索ではなく、グラフのトラバーサル（関係をたどること）で行われる。
「Agent_Implementerが担当するモジュールが依存しているコンポーネントはどれか？」という質問を考えると、この答えはどこにもテキストの塊として存在しない。複数の事実を組み合わせた「パス」としてのみ存在する。フラットなストアはこのパスを構築できないが、グラフは一直線にたどれる。
ベンチマークの設計
Emmimalは「グラフに有利なベンチマーク」を作らないよう4つのルールを設けた：
- ノイズが多数派：「了解」「後で確認します」といった具体的決定を含まないターンが、実際の決定より多い
- クエリは距離で分類：事実が述べられた直後（direct）、多数ターン後（distant）、2つの事実を組み合わせる必要があるもの（join）
- 単純なクエリも含める：フラットアーキテクチャに有利な単一事実検索も意図的に含む
- 採点は完全に決定論的：LLMジャッジではなく、手書きの正解への部分文字列マッチング
5シナリオ（ソフトウェア計画、研究パイプライン、インシデント対応、カスタマーサポートエスカレーション、データパイプライン）、18クエリ（direct 6件、distant 7件、join 5件）。LLM呼び出しはゼロ。2台の異なるマシンで実行し、結果はバイト単位で一致した。
なお、5シナリオ・18クエリという規模は決して大きくない。Emmimalも記事内でこの点を認識しており、結果はあくまで「特定条件下での構造的差異の検証」として読む必要がある。一般化可能性については今後の追試が待たれる。
結果：精度とトークンコストの両方で差が出た
| アーキテクチャ | 精度 | クエリあたりトークン数 |
|---|---|---|
| コンテキストグラフ | 88.9% | 26.9 |
| 生ヒストリーダンプ | 61.1% | 490.9 |
| ベクトルのみRAG | 50.0% | 75.9 |
精度で38.9ポイント、トークン消費で約18倍の差がついた。ベクトルRAGが生ヒストリーより精度で劣るのは、joinクエリで構造的に詰まるためだ。
実装中に見つかった2つのバグ
Emmimalは最初の完全実行で**コンテキストグラフの精度0%**という結果を得た。この失敗談が記事の中で正直に語られている。実装全体はGitHubリポジトリで公開されており、バグ修正の経緯も含めてコードで確認できる。
1つ目のバグ：古い事実の上書き問題（stale-fact retrieval）
同一ファクトIDを持つエッジが更新されたとき、グラフはすべてのエッジを保持してしまっていた。最新の事実を取得しようとしても古い情報が残り続ける。
2つ目のバグ：エンティティマッチングのギャップ
クエリのエンティティ名がグラフに格納されているノード名と完全一致しない場合（例：「auth」と「AuthModule」）、グラフが関連ノードを見つけられない。部分一致のフォールバックで対処した。
このアーキテクチャが有効な条件
Emmimalは用途の線引きを明確にしている。
使うべき場合：
- あるエージェントの決定を、別のエージェントが多数ターン後に参照する必要がある
- クエリが複数の事実の組み合わせを必要とする
- 会話が長期化し、ヒストリー再送のトークンコストが問題になっている
使わなくていい場合：
- 単一エージェント・単一ターンのタスク
- 常に単一事実検索で完結するクエリ（ベクトルRAGで十分）
- 追加コンポーネントの保守コストを許容できないチーム（本番環境ではエンティティ抽出にLLM呼び出しが必要）
なお、ベンチマークではエンティティ抽出を決定論的なルールベースで代替しているが、これは「抽出を解決した」と主張するものではなく、ストレージと取得のアーキテクチャ差を純粋に測定するための設計判断だと明記されている。
実装全体はGitHubリポジトリで公開されており、手元で再現実行が可能だ。
詳細はVector RAG Isn't Enough — I Built a Context Graph Layer for Multi-Agent Memoryを参照していただきたい。
