Agent Memory in 2026 SSOT をどこに置き、どう検索するか

エージェントの記憶層がやることは2つに尽きる。セッションを越えて状態を永続化することと、必要な断片だけをコンテキストウィンドウに戻すこと(検索)。この2つはそれぞれ独立した設計判断であり、混ぜると議論が濁る。

• 軸A — SSOT の所在: 永続化された正本をどこに置くか。人間可読なプレーンテキストのファイル(Markdown 等)か、DB(リレーショナル / ベクトル / グラフ)か。SSOT は「ここが消えたら復元できない唯一の正本」を指す。インデックスは SSOT ではない。
• 軸B — 検索戦略: SSOT から関連断片をどう取り出すか。字句スキャン(grep / ripgrep / BM25)か、事前計算した dense ベクトルインデックス(近似最近傍)か、グラフ走査か、これらのハイブリッドか。
• 駆動力 — スケール: ドキュメント数・ユーザー数・書き込み頻度。軸Aと軸Bの選択は、これによって変わる。規模が小さく単一ユーザーなら、軸Bは字句スキャン・軸Aはファイルが向く。規模が大きく多テナントなら、軸Bはインデックス・軸AはDBが向く。

重要なのは A と B が独立している点だ。「ファイル SSOT + ベクトルインデックス」も「DB SSOT + 字句検索」も成立する。前者は実際に最も人気の中間解になっている。だから「ファイルか、ベクトルか」は座標の取り違えで、正しくは2次元の地図になる。

FILEファイルを SSOT にする

正本を Markdown 等のプレーンテキストファイルとしてファイルシステムに置く。技術的な帰結は次の通り。

• ポータビリティ(ベンダー非依存): フォーマットが特定サービスに縛られない。ファイルシステムを読めるツールなら何でも消費できる。SSOT がプロプライエタリな DB スキーマに閉じない。
• クロスエージェント性: 任意のエージェントが同じファイルを読める。記憶が Claude Code・Cursor・Codex・自作スクリプトの間で共有資産になる。MCP サーバ越しに公開すれば、任意の MCP クライアントから一様にアクセスできる(§06)。
• バージョン管理が無料で付く: Git で差分・履歴・blame・revert・ブランチ。記憶の変更が監査可能になり、壊れたら巻き戻せる。これを DB で得るには監査ログとスナップショットを別途作る必要がある。
• filesystem-native なコーディングエージェントに最適化: Claude Code / Cursor / Devin はそもそもファイルツリー走査・ripgrep・Tree-sitter で動く(§03)。記憶もファイルなら、コードを読むのと同じツール経路で記憶を読める。新しい検索インフラが要らない。
• 弱点: スキーマ強制・トランザクション・行レベルのアクセス制御・並行書き込みの調停・マルチテナント分離が言語機能として無い。必要ならアプリ層で自作する。

DBDB を SSOT にする

正本を DB の状態(行・ベクトル・グラフのノード/エッジ)として持つ。代わりに次が手に入る。

• 分離と一貫性: スキーマ制約・ACID トランザクション・user_id 単位のマルチテナント分離・並行書き込みの調停がエンジン側の保証として付く。多人数サービスではこれが事実上必須になる。
• サーバ越しの同時アクセス: 多数のクライアントが同じ記憶へ同時に読み書きできる。ファイル + Git のマージモデルでは破綻する領域。
• 代償: ロックイン(そのサービスのプロトコル / SDK 経由でしか引けない)とブラックボックス性(中身を人が直接読めない、監査しづらい)。SSOT が外部サービスに預けられる。

字句スキャン(grep / BM25)— インデックスを事前計算しない

エージェントが正本を直接走査する。静的な RAG(事前にチャンク化して埋め込み、クエリ時に近傍取得)と根本的に違うのは、LLM が実行時にツールを選び、反復で絞り込む点だ。コーディングエージェントの典型ループ:

具体的には、ディレクトリ一覧で構造を把握し、grep -r "def processPayment" . や ripgrep で定義箇所を引き、必要なファイルだけを読み、Tree-sitter で AST(関数定義・クラス階層・import グラフ)をたどる。ベクトル検索が苦手とする構造関係(呼び出しグラフ、定義の一意性)をここで捉える。コード文脈ではベクトルのチャンク境界問題や silent failure(存在しない関数を自信満々に呼ぶ)を回避できる。

字句検索が効くのは、書いた本人が探すと語彙が一致し、クエリと文書の意味ギャップがほぼ無いから。ある実装報告では、個人ノート規模で BM25 が9割超の確率で正しい文書を引き、FTS5 のランキングが崩れ始めるのは1万件超だとする。Anthropic 自身も「まず agentic search から始め、必要になってから semantic を足せ」と公式に推奨している。

dense ベクトル(埋め込み + 近似最近傍)

テキストを埋め込みベクトルにし、HNSW や IVF といった近似最近傍(ANN)インデックスで近傍検索する。言い換え・同義・cross-lingual に強い。代償は書き込み増幅(write amplification)だ。

• 編集のたびに該当チャンクを再埋め込みし、インデックスを同期する必要がある。
• チャンク分割の設計が品質を左右する(小さすぎると文脈が切れ、大きすぎるとノイズが増える)。
• 埋め込みモデルを変えると原則として全件再計算になる。
• つまりインデックスは「正本のまわりに維持し続けるコスト」を伴う。だからこそ SSOT ではなく派生物として扱うのが正しい。

グラフ(エンティティ + 関係、bi-temporal)

事実をノードとエッジで持ち、関係をたどる。Zep の Graphiti は各事実に2つの時間軸——valid-time(その事実が世界で真だった期間)と transaction-time(システムがそれを取り込んだ時刻)——を持つ bi-temporal モデルを採る。矛盾する新事実が来ても古い事実を削除せず、valid-time の区間を閉じて無効化する。これにより「ある時点で何が真だったか / 何を信じていたか」という point-in-time クエリが成立する。記憶の更新を「上書き」でなく「履歴の積層」として扱う設計だ。

ハイブリッド + RRF / HyDE — 実務はほぼ全部ここ

疎(BM25)と密(ベクトル)、さらにグラフやキー一致を併用し、順位を融合する。標準的な融合手法が Reciprocal Rank Fusion だ。スコアが互いに非互換な複数のランキングを、順位だけで統合する:

もう一つよく使われるのが HyDE(Hypothetical Document Embeddings)。クエリをそのまま埋め込む代わりに、LLM に仮説的な回答文を生成させ、その回答文を埋め込んで近傍検索する。短い質問より、生成された回答文のほうが本物の回答文書に埋め込み空間で近いことを利用する。Cloudflare Agent Memory は全文・キー一致・原文・ベクトル・HyDE の5系統を重み付き RRF で融合している。

軸Aと軸Bをどちらに選ぶかは、規模によって変わる。効くのは検索精度だけではない。多テナント分離・並行書き込み・書き込み頻度も同時に効く。

• 意味ギャップの発生条件: 字句検索が崩れるのは「書き手 ≠ 検索者」「言い換え / 同義語」「cross-lingual」が増えたとき。単一ユーザーが自分の語彙で書いて自分で探す限り、ギャップは小さいまま保たれる。
• 規模の目安: 個人ノート規模(おおむね 10³〜10⁴ オーダー)では字句検索で十分。ある報告では1万件超で FTS5 のランキングが劣化し始める。これは厳密な閾値ではなく、書き手・検索者・言い換え率に依存する経験則として読むべき。
• 検証可能なベンチマーク: Amazon の AAAI 2026 研究では、キーワード検索エージェントがベクトルストアなしで RAG faithfulness の 94.5% に到達。Cursor は semantic と grep の併用で+12.5% の精度を報告。純 grep でも純ベクトルでもなく、併用が勝つことを示す。
• 精度以外で効くもの: マルチテナント分離(file-per-memory は水平スケールしない)、並行書き込みの調停、高い書き込み頻度。これらは検索手法と無関係に DB 側へ押す力になる。

2軸を取ると、実在ツールは3つの安定領域に集まる。「DB を SSOT にしつつ字句スキャンだけで引く」左下はほぼ空で、DB を選んだ時点でインデックスも持つのが自然だからだ。

2026年6月時点の検証済みデータ。SSOT の所在で陣営を分け、検索戦略・想定規模帯・ポータビリティを併記する。スター数は変動が速いので目安。

軸A をファイルに倒す最大の見返りは、検索精度ではなく所有と相互運用にある。ここが「ベクトルDB 対 ファイル」の対立では見えなくなる論点だ。

• どのエージェントでも読める: プレーンテキスト + Git の記憶は、ファイルシステムを読める任意のエージェントが消費できる。SSOT が一社のサービスに閉じないので、Claude Code で書いた記憶を Cursor や Codex がそのまま使える。DB を SSOT にすると、その記憶はそのサービスのプロトコル / SDK を話せるクライアントにしか開かれない。
• MCP が配布層になる: ファイル群を MCP サーバ越しに公開すれば、任意の MCP クライアントから一様な道具インターフェースで読める。2026年の趨勢は明確で、「ベクトルインデックスを構築する」より「データを MCP で公開する」が一般的な設計判断になりつつある。検索を事前計算された索引問題から、実行時のエージェント挙動へ反転させる動きだ。
• 監査と巻き戻しが移行可能性を支える: Git 履歴ごと持ち出せるので、ツールやベンダーを乗り換えても記憶の連続性が切れない。移行は「検索クエリの書き換え」であって「DB のエクスポートと再整形」ではない。
• トレードオフの正味: ファイル SSOT が買うのはポータビリティ・監査性・クロスエージェント性。DB SSOT が買うのはマルチテナント分離・一貫性・マネージドな運用。どちらを上位に置くかが、軸A の判断そのものだ。

軸A(SSOT の所在)の判断を、5つの問いで近似する。検索戦略(軸B)は規模に応じて後から足せるが、SSOT の選択は土台なので先に決まる。

注意: これは軸A の判断であって、検索戦略(軸B)は独立だ。ファイル SSOT を選んでも、規模が増えれば grep → ハイブリッド(`RRF`)へ検索層だけ足せる(memweave・GBrain がその形)。「まず単純に始め、実際に壊れてから層を足す」が一貫した助言だ。

各サービスは LoCoMo や LongMemEval のスコアを誇る。だが横並び比較には致命的な前提がある。

LoCoMo(arXiv 2402.17753)は、最大35セッション・平均約300ターンの超長期会話で記憶を試す学術ベンチマークで、単一ホップ・複数ホップ・時間推論・敵対的質問を QA で測る。問題は、公表スコアのほぼ全てがベンダー自己申告で測定条件が各社で異なること。mem0 が 91.6、Zep が 94.7 と並んでも、埋め込みモデル・チャンク設計・採点プロンプトが違えば比較は成り立たない。`LongMemEval` や `BEAM` も同様だ。スコアは「そのツールが何を得意と主張しているか」を読む材料であって、優劣の判定材料ではない。