導入
こんにちは、株式会社ナレッジセンスの須藤英寿です。
今回は、なぜClaude Codeがベクトル検索[1]ではなく、agentic search(Agentic RAG)を利用しているのかを簡単に解説していこうと思います。
Claude Codeの初期バージョンではRAGとローカルのベクトルDBを使用していたが、agentic searchの方が概ね優れていることがすぐに判明した。agentic searchはよりシンプルで、セキュリティ、プライバシー、情報の鮮度、信頼性に関する問題も抱えていない。
— Boris Cherny (@bcherny) 2026年2月1日
少し話を進める前に、簡単に整理したいと思います。
まずRAGというのは、検索とLLMを組み合わせた手法全般のことを指しています。そして、ベクトル検索手法は、そのRAGの中の一番オーソドックスな手法と言えます。Boris Chernyさん(Claudeの開発における中心的な人物)のいうところでは、Claude Codeでは、この一番オーソドックスなベクトル検索手法を使っていないよ！とのことです。(RAGそのものは言うまでもなく使用しています)
ではClaude Codeではどんな手法が使われているかというと、agentic search(Agentic RAG)が使われています。これは、LLMが繰り返し、Agentとして動作する過程で必要に応じて、情報を繰り返し検索して、必要な情報を集める方法です。
今回は、なぜClaude Codeがベクトル検索手法を使わないに至ったかを順を追って解説していきます。
前提
そもそもClaude Codeはどんな方法でコードを検索しているのでしょうか？MCPやバージョンで異なると思いますが、探索の中核は以下の3種類のツールで、これらを組み合わせてコードを検索しています。
- Glob: ファイル名をパターン（ワイルドカード）で検索
- Grep: ファイルの内容を検索
- Read: ファイルの内容を読む
これらをAgentが思考しながら繰り返していき、必要なコードを探しています。ポイントは、検索のための機能は一つに絞る必要がないということです。つまり、ベクトル検索とGlob, Grep, Readは対立的な構造ではなく、同時に利用することも可能です。しかし、Claude Codeでは採用されていません。その理由は「手法の比較」以降で解説していきます。
課題意識
コーディングエージェントの重要なタスクの一つとして、「コード(ファイル)を検索する」というものがあります。ここでは関数を検索することを想定してみます。関数を探すシチュエーションを想定したときに、どんなケースが最も難しい検索でしょうか？
それは、コードベースを把握していないタイミングで、任意の関数を探すケースです。こうしたケースでは、出入り口のわかりやすい実装部分から関連する処理を順番に探したり、文字の一致検索でそれらしい関数を検索することになります。
手法の比較
性能の比較
ここまでで、登場した検索方法は以下の二つです。
- Glob, Grep: コードやファイル名の一致検索をする機能
- ベクトル検索: 自然言語で意味の類似したファイルを検索する機能
この二つをコードベースの検索方法で比べてみましょう
| Glob, Grep | ベクトル検索 | |
|---|---|---|
| ファイル名で一致検索 | 〇 | △ |
| コードで一致検索 | 〇 | △ |
| 自然言語でコードを検索 | × | △ |
| コードの要約で検索 | △ | 〇 |
(〇: 可能,相性が良い, △: できなくはないが相性悪い, ×: できない)
一致検索をするだけであれば、Glob, Grepで十分であり、ベクトル検索は相対的に不安定です。そして、コードの内容を元に検索する手法では確かに、ベクトル検索に軍配が上がります。ただし、コードを対象とするベクトル化は難しく[2]精度が上がりにくい問題があります。精度が上がりにくい理由としては、たとえば、コードは本来機能で検索する必要があるにも関わらず、名前に引っ張られて検索を阻害することがあるためです。
コストの比較
性能が上がるケースがあるのであれば、ベクトル検索を追加すればよいのでは？と考えられます。実際、最も精度が良いのはGlob, Grepとベクトル検索を組み合わせた手法です。ただし、かかるコスト(費用, 時間)が大きく異なります。
| Glob, Grep | ベクトル検索 | |
|---|---|---|
| 検索コスト | - | 低 |
| 事前準備コスト | - | 高 |
| 検索結果の入力コスト | 高 | 低 |
| コード変更のコスト | - | 高 |
※かかる費用, 時間の程度を表します。-は費用, 時間がかからないことを意味しています
Glob, Grep手法は、初期コストが0で済む一方で、検索を繰り返しやすくトークンの消費と時間がかかります。一方、ベクトル検索は事前にインデックスの作成や、コードの変化に合わせてインデックスを更新する必要があり、そのたびにベクトル化のコストがかかりますが、検索時のコストは少なく済みます。
比較まとめ
ベクトル検索はたしかに、Glob, Grep手法と比べて精度の面で優位な部分があります。一方で、管理のためのコストはGlob, Grepと比べて、変更頻度の高さも相まって非常に高いため、採用されなくなっていると考えられます。(本当はベクトル検索の場合、セキュリティ・プライバシーの問題も考慮する必要があるのですが、今回は長くなってしまうので触れません)
どんなケースでベクトル検索が必要？
コードの検索とベクトル検索の相性
コードの検索は実は0から検索をしないといけない機会はそこまで多くありません。というのも、コードは参照関係が明示されていることが多いため、参照をたどることで簡単に関連するファイルを見つけることができます。このため、ベクトル検索の活かせる検索は最初の1回だけのことが多く、相対的に相性が悪いといえます。(DIなどを使用しているケースではその限りではないです)
ベクトル検索と相性の良いケース
ベクトル検索は、大量の情報の中から意味的に近い文章を見つけ出すことを得意としています。ただし、それだけでは検索の精度に限度があるため、最近では多くのケースでベクトル検索をさらに工夫することで実用的な検索を実現できます。
例えば、以前紹介したVersionRAGは、更新の発生するドキュメントをバージョン単位で管理することで、常に最新の情報を検索することができます。
Hindsightは、検索精度の下がりやすい会話データの検索を、カテゴリ分類して整理することで高い精度で検索し、過去の内容を記憶したLLMとの会話を実現します。
このように、ベクトル検索と相性のよい使い方も様々なものが存在します。
まとめ
Claude Codeでベクトル検索を使用しない理由について解説しました。確かに、ベクトル検索によって得られる効果は限定的で、採用するコストも高いため少なくとも公式には対応されていません。ただし、ドキュメントが整備されている場合はその限りではなく、変更に合わせてドキュメントもしっかりと整理されている場合、ベクトル検索の恩恵を強く受けることができます。また、コード探索は参照を辿れますが、ドキュメントや議事録などは参照が辿れないので、こちらも引き続きベクトル検索の恩恵を受けられます。このブログが、皆様の理解の一助となれれば幸いです。
株式会社ナレッジセンスは、「大企業の知的活動を最速にする」をミッションに掲げ、社内データ検索ができるAIチャットボットを開発・提供しているスタートアップです。このブログでは、LLMや検索技術、RAGの実装戦略について知見を共有します。生成AIやRAG技術を使って最高品質の実装をしたいエンジニア向けのコンテンツです
Discussion