Graph MemoryでAgentic Searchをさらに強化する

こんにちは。株式会社インゲージでAI周りの開発を行っているjinyangです。

弊社では、Claude Codeをエンジニア全員に導入済みであり、欠かせないツールとなりました。 Claude Code の開発元である Anthropic のブログや SNS をウォッチしている方は、目に穴が開くほど目にしてきた言葉があるのではないでしょうか。

それは 「Agentic Search（エージェンティック・サーチ）」です。

初期のRAGでは、Vector DBを用いて類似検索を行うことで大量のデータからエンドユーザのクエリに意味的に似たようなデータを高い精度で検索した。ただ、 Claude Codeの開発者であるBoris 氏はVector DBではなく、Agentが自律的にツールを利用し、検索を繰り返すことで回答を行う手法、いわゆる「Agentic Search」を活用することで、飛躍的にClaude Codeの精度を向上させたという。

Embedding を活用した類似検索は、文章のクラスタリングなどではこれからも活躍するのは間違いないでしょうが、マルチホップ QA（複数の情報元を活用する必要のある質問に回答するタスク）においては、Agentic Search を活用したシステムには精度が大きく劣るのではないかと考えています。

理由は、LLMがあまりにもかしこいからです。ツールを使って試行錯誤する過程をも理解し、凄まじい精度を叩き出すことができます。そして、これからもLLMは進化し続けていくことを考えると精度という点においては、Agentic SearchはVector DBを用いた手法より優れたものであり続けるのではないかと思います。

「精度という点において」を強調したのには理由があります。それはコストやレイテンシーが悪化することが多いということです。検索の精度と速さはトレードオフの関係にあるので、仕方のないことのようにも思えますが、これを改善できる方法を模索していきます。

Agentic Search がうまくいく前提

そもそも agentic search が高い精度を出すのは、特定の前提が揃ったときです。今回提案する「索引を渡す」アイデアを理解しやすくするために、まずその前提を 3つ整理させてください。

1. ツールが豊富で、十分にドキュメント化されている

agent が「この検索 API は何ができるのか」を理解できるよう、ツールの説明（tool description）が agent の振る舞いそのものを駆動します。

Tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts.

Bad tool descriptions can send agents down completely wrong paths.

2. 検索対象が構造化されている

スレッド、リンク、タグ、メタデータなど、最初の検索でヒットした情報から芋づる式に関連情報に辿り着ける構造が必要です。

Anthropic の context-engineering 公式記事はこう書いています:

Folder hierarchies, naming conventions, and timestamps all provide important signals that help both humans and agents understand how and when to utilize information.

フォルダ階層、命名規則、タイムスタンプ。これらは agent にとってナビゲーションの手がかり（navigation signal）として機能します。

3. 試行錯誤を許容できる latency

agent の検索は反復的なので、即時性が求められるユースケースには向きません。

これは Anthropic だけでなく、Google や OpenAI からも primary な evidence があります。

Anthropic はこの trade-off を明言しています:

Agentic systems often trade latency and cost for better task performance.

Google の最新 RAG 評価ベンチマーク (NAACL 2025) は、multi-step retrieval で精度を 50% 以上向上 という empirical evidence（経験的証拠）を示しています。

The accuracy is significantly improved with our proposed multi-step retrieval pipeline, achieving an accuracy of 0.66 (>50% improvement).

OpenAI の Deep Research も「tool call を増やすほど精度が上がる」と明示しており (Introducing deep research, 2025-02)、3 lab の primary source が同じ方向を指しています。

精度はいいけど、コスト・レイテンシ悪化がちょっと... というのが難点ですので、試行錯誤の回数 (turn 数) をなるべく減らせられないかが勝負になると思います。

そこで、ある程度事前に 索引のようなものをAgentに食わせると大きく改善できるという仮説が浮かびます。

agent に渡す索引って?

もっと具体的に 「query に対する索引 (index)」 — 「このクエリは検索対象のこのあたりが関係していそう」というルーティング情報そのものです。

索引を渡せば agent は試行錯誤の 出発点 を持てます。ベクトル top-K (semantic 類似順) でもいいけれど、それだけだと 構造的な関連性 (同じスレッドの返信、同じ概念に結びつく古いメッセージ、よく一緒に言及される人物など) を捉えきれない。

そこで脳のシナプスに着目した連想索引のアイデアを借りることにしました。

SYNAPSE 論文 (arXiv:2601.02744) は脳の長期記憶を 連想ネットワーク + 活性伝播 でモデル化したもので、LoCoMo という長期会話 QA ベンチマークで SOTA を出している retriever です。

仕組みは「事前にネットワークを作る」「クエリ時に連想を起こす」の 2 段階。

材料は弊社 Slack の 5 チャンネル × 26 週、合計 20,205 メッセージです。やることは以下の 3 つです。

  1. メッセージ一つ一つを ノードにする (発言そのもの)
  2. 各メッセージから「何の話題か」を Gemini で抽出して、抽象概念のノードも作る (例: 「foo 認証」「Terraform リファクタ」など)
  3. ノード同士を関係でつなぐ ── 「同じスレッドにいる」「同じチャンネル」「同じ人がよく出てくる」「時間的に近い」など

最終的なグラフは 22,157 ノード / 101,196 接続。Slack の発言・人物・話題・チャンネルが、互いに参照し合う網の目として残ります。

連想が広がる様子

実際にクエリを投げると活性が graph 上を 4 フェーズでこう広がります。

  • t=0 trigger: BM25 + HNSW の dual-trigger でシードノードが点火される（query との直接的なヒット）
  • t=1 propagate: 隣接ノードに活性が伝搬。Fan Effect で隣接数に応じてエネルギーが分割される
  • t=2 inhibit: Lateral Inhibition で弱い節点が消され、勝者の輪郭が浮かび上がる
  • t=3 fire: 勝者ノードが残り、agent に渡されるサブグラフとして確定

22,157 nodes / 101,196 edges を背景に薄く表示し、活性化した 300 nodes / 4 timesteps を 強調しています。

検証 — 60 問 × 3条件

条件

  • agentic_flat — 索引なし、baseline
  • agentic_embedding — embedding 近傍 top-15 メッセージを索引として渡す
  • agentic_graph (④) — 上記 spreading activation の subgraph を索引として渡す

Claude Code で Opus 4.7 を使い、60 問（Easy 11 / Medium 20 / Hard 29）の Q&A データセットを作成し、上の 3 条件で合計 180 回の実行（run）を claude-agent-sdk + claude-sonnet-4-6 で検証しました。

平均 turn 数 (低いほど効率的)

難度 n flat embedding graph
easy 11 5.64 5.36 4.82
medium 20 7.45 6.25 5.35
hard 29 8.83 6.34 8.76
all 60 7.78 6.13 6.90

平均コスト (USD/run、低いほど安い)

難度 n flat embedding graph
easy 11 $0.184 $0.108 $0.146
medium 20 $0.252 $0.180 $0.189
hard 29 $0.345 $0.209 $0.321
all 60 $0.284 $0.181 $0.245

LLM rater Opus 4.7 による blind ranking、1 位獲得回数

各クエリに対して 3 候補を blind でランク付けし、1 位 (best) に選ばれた回数 を集計しました。

難度 n flat embedding graph
easy 11 3 4 4
medium 20 3 7 10
hard 29 7 16 6
all 60 13 27 20

60 問中、embedding が 27 問（45%）で 1位 ── 3 条件で最多です。graph は 20 問（33%）、flat は 13 問（22%）。

特に Hard 難度では embedding が 29 問中 16 問で 1位を獲得し、graph は 6 問のみ。一方 Medium 難度では graph が 20 問中 10 問（半分）で 1位を取り、ここが graph のスイートスポットとして現れています。

結局、今回の結果以下のようにまとめることができます。

  1. embedding 索引が普遍的に最良: 全難度で turn −21% / cost −36% / 1 位獲得 27/60 (45%)。シンプルな意味類似 top-K で十分、というのが正直な結論
  2. graph 索引は Medium 限定で勝つ: turn −28% / cost −25% / 1 位 10/20 で sweet spot を出すが、Hard では効果が消え (turn −0.8% / 1 位 6/29)、平均すれば embedding に届かない

まとめ

agentic search を強化する方法として、agent に 「索引」を渡すことを考えました。

検証の結果、シンプルな embedding top-K の索引 が全難度で普遍的に効く（turn −21% / cost −36% / preference 0.60）ことが分かりました。一方、我々が主役として試した 脳の連想索引（SYNAPSE memory graph） は Medium 難度でスイートスポットを示すが Hard では効果が消える、という限定的な強さでした。

embedding 索引のほうが全体的に良いパフォーマンスを示しました。

参考