🧠 AI プロダクト動向

Claude Code の「エージェント検索」は、事前にコードベース全体をベクトル化してインデックスを作る代わりに、grep と glob による反復探索をエージェント自身に実行させる方式だ。クエリのたびにファイルを絞り込み、読み、必要なら検索語を変えて再検索する——人間のエンジニアがコードを探すのと同じ手順をツール呼び出しの連鎖として再現する。

Anthropicは当初、埋め込みベースのRAGパイプラインをClaude Codeに組み込んでいたが、後にエージェント検索へ完全に置き換えた。理由は精度だけでなく運用コストにある。ベクトルインデックスはコード変更のたびに再構築が必要で、ローカルの未コミット変更とはすぐにズレる。さらに社外のベクトルDBへコードをアップロードすること自体がセキュリティ上のリスクになる。エージェント検索はレイテンシとトークン消費の増加を引き受ける代わりに、この2つの負債を丸ごと回避した。

一方でCursorとGitHub Copilotは埋め込みベースの検索を手放していない。むしろ索引の構築・更新コストを下げる方向に工数を投じている。Cursorはファイルツリーをハッシュ差分で管理し、変更があったブランチだけを再索引する。新規メンバーが参加した際は、その人のコードベースと類似度の高い既存インデックスを組織内で探して再利用し、初回検索までの待ち時間を数秒からミリ秒単位に縮めた。GitHub Copilotも新しい埋め込みモデルを投入し、検索精度を約38%引き上げつつインデックスサイズを8分の1に圧縮している。

この2社が埋め込みを維持する理由は、Claude Codeとは前提が違うからだ。IDEに常駐して多数のユーザーが同じリポジトリに繰り返しアクセスする製品では、索引コストを一度払えば以後のクエリで償却できる。エージェント検索のように毎回ファイルシステムを探索するコストは、多人数・高頻度アクセスの場では割に合わない。

SourcegraphのMCPサーバーは、キーワード検索とベクトル検索に加えて、SCIPという静的解析ベースのコードインデックスを使う13種類のツールをエージェントに公開する。シンボルの定義元や参照元を尋ねるクエリには、テキスト類似度に基づく確率的な検索ではなく、コンパイラ相当の精度を持つ確定的なルックアップで答える。

この使い分けが効くのは、クエリの種類によって「正解が一意に決まるか」が違うからだ。「この関数はどこで定義されているか」への答えは1つしかなく、検索より静的解析の方が向いている。Sourcegraph自身のベンチマークでは、MCPサーバー経由でのファイル再現率が0.127から0.277まで改善し、grepベースのベースラインではタイムアウトしていたタスクが制限時間内に完了する例もあったという。