半年前、私は社内ナレッジ用にRAGパイプラインを組んでいました。LangChain、ベクトルDBはQdrant、embeddingはOpenAI、リランカーはCohere、チャンクサイズは512トークン。3週間かけて構築して、社内QAの精度が体感で40%→65%に上がったあたりで「これでナレッジ検索は完璧だ」と思っていたのです。
ところがClaude Codeを業務で使い始めて2週間で、その認識は揺らぎました。Claude Codeはコードベースのインデックスを一切作っていません。それなのに、私が3週間かけて作ったRAGより、コード検索の精度がはっきり高い。中で何が起きているのかを調べると、たどり着いたのが「Agentic Search」という言葉でした。
RAGとAgentic Search、何が違うのか
ざっくり言うとこうです。
- RAG: 事前にベクトルインデックスを作り、クエリと類似ベクトルを引っ張ってLLMに渡す
-
Agentic Search: モデル自身が
globgrepreadを組み合わせて、必要な情報をその都度探しに行く
Claude Codeを作ったBoris Cherny氏は、初期にRAGを組み込んだうえで両者を比較し、Agentic Searchが「大差で勝った」と語っています。これは最近の流行ではなく、実測の上での選択でした。
私の体感もこれに近く、Claude Codeに「認証周りのバグを見て」と頼んだとき、まず glob src/**/*auth*、続けて grep -n "validateToken"、最後に該当ファイルを Read するという、人間のエンジニアと同じ調査プロセスを踏んでいました。インデックスはどこにもありません。
違い1: 精度 — 「あいまい一致」が消える
RAGの最大の弱点はembedding由来のfuzzy matchです。意味的に近いものを引いてくるので、語彙が違っても拾える反面、完全一致が欲しいときに別物を返すことがあります。
私の事例だと、validateToken 関数の参照箇所を探したいときに、RAGは verifyJWT checkSession authMiddleware を上位に出してきました。意味的には正しい類縁関係です。ただ、私が欲しいのは validateToken の 正確な呼び出し元 でした。
# Agentic Searchが裏で実行している調査
$ grep -rn "validateToken(" src/ --include="*.ts"
src/auth/middleware.ts:42: if (!validateToken(token)) {
src/auth/refresh.ts:18: const valid = validateToken(refreshToken);
src/api/login.ts:65: return validateToken(req.body.token);
3件、ピンポイントで返ってきます。embeddingの類似度に頼らないので、validate のtypoが validte だったら一切引っかからない代わりに、「呼ばれている場所はここ」を取りこぼしません。
これは「あいまい一致できる」がRAGのメリットだったはずなのに、コード検索という用途では逆に弱点だったわけです。私は半年かけてようやく腑に落ちました。
embeddingは「自然言語の意味的近さ」を捉えるのが得意で、「コードシンボルの厳密一致」は不得意です。getUserById と findUserBy は意味的に近いので、embedding空間では近接ベクトルになります。けれどコード検索では getUserById の参照箇所が欲しいのであって、findUserBy を「近い候補」として返されても困る。コードはそもそも識別子の厳密性で成り立つ言語なので、 fuzzyな検索は構造的に相性が悪いのです。
違い2: 鮮度 — インデックス再構築が消える
RAGの2つ目のしんどさはインデックスの腐敗です。コードベースは常に動くので、ベクトルインデックスは常に古くなり続けます。私の運用では1日1回 cron で再embeddingしていましたが、午前中に書いた関数が午後の検索で出てこない、という現象が日常的に起きました。
Agentic Searchはファイルシステム自体がインデックスです。grep も read も、たった今のファイルを見ます。git checkout でブランチを切り替えた直後でも、検索結果が即座にそのブランチの内容に切り替わります。
私の社内QA bot(RAG版)は「git pull してから30分くらいは古い回答が混ざる」という運用上の許容を強いていました。Agentic Searchベースに作り替えると、その許容自体が消えました。「最新の状態」を別に管理しなくていいのは想像以上に楽です。
Anthropic Engineering Blogは2025年のClaude Code release notesで「No vector database. No embedding pipeline. The filesystem is the index.」と書いています。インデックスを持たないことがClaude Codeのデザイン原則のひとつになっています。
違い3: プライバシー — コードが外に出ない
RAGを社内で組むときの一番面倒な議論が、embedding APIにコードを送ることへの懸念です。Voyage、Cohere、OpenAI、いずれも入力データを送る必要があります(no-retention契約はあるにせよ)。
セキュリティ部門からは「機密度の高いリポジトリは外部APIに送れない」と言われ、私のRAG構築の半分はsentinel routing(機密ファイルだけローカルembeddingで分離する仕組み)に費やされました。
Agentic Searchはコードベース全体をローカルで探索し、LLMに渡すのはユーザーが必要と判断した関数本体だけです。インデックス目的でフルコードを送る必要がありません。Claude Codeの場合、ユーザーが許可した範囲のファイルだけがcontextに入る設計になっています。
これは「インデックス不要」と並んで、社内導入の障壁を下げる大きな効果でした。私の所属組織でも、RAG導入で半年止まっていたリポジトリが、Claude Code導入は1週間で承認が降りました。
トークン消費はどう変わるのか
Agentic Searchを「コード版RAG」として褒めるだけでは不公平です。最大の弱点はトークン消費です。
- RAGは事前にチャンクをフィルタしてから渡すので、入力トークンが少ない
- Agentic Searchは複数回の
grep/readを経て情報を集めるので、入力トークンが多い
私が実測した範囲だと、同じ社内QAのコード検索タスクで、
| 方式 | 平均入力トークン | 応答時間 | 正答率 |
|---|---|---|---|
| RAG (Qdrant + GPT-4o) | 約12K | 5.2秒 | 68% |
| Agentic Search (Claude Code) | 約35K | 9.4秒 | 84% |
応答時間とトークンは2〜3倍に増えますが、正答率は68%→84%に上がりました。コードベースの規模が中規模(数千ファイル以下)であればこのトレードオフは引き合うと感じています。
逆に数十万件のドキュメントを引くようなナレッジBotだと、Agentic Searchは現実的なトークン量を超えます。「コード検索はAgentic Search、大規模文書検索はRAG」というのが2026年5月時点の私の使い分けです。
トークン消費の増加は、Claude Code 1M context GA(2026年3月のOpus 4.6/Sonnet 4.6で正式に利用可能)で実務上の影響が一段下がりました。中規模リポジトリならディレクトリ単位で Read してもcontextに収まります。料金面ではprompt cachingでヒット率を上げる工夫が定番化し、繰り返し読まれるファイルはほぼキャッシュ価格で済むようになりました。Agentic Searchの「トークンを使いすぎる」という弱点は、エコシステム全体の進化で吸収されつつあります。
Agentic RAG — 両者を融合する次の流れ
RAG vs Agentic Searchの二項対立で終わらないというのが、最近の動きです。LangChain、LlamaIndex、Anthropic自身もAgentic RAGという言葉を使い始めています。
Agentic RAG:
クエリ → エージェントが判断
├── ベクトル検索が適切？ → RAG
├── キーワード検索が適切？ → grep/glob
├── 複数ソース統合？ → 並列検索
└── 情報不足？ → 追加質問
「最適な検索手段をエージェントが選ぶ」というのが核で、人間が「これはRAG、これはgrep」と決め打ちしなくて済むようになります。私のチームでは社内QAをこれに切り替える検証を進めているところで、コード関連の質問は内部でAgentic Search、運用ドキュメントの質問はRAGを自動で振り分ける構成にしています。
RAGを組む前に問うべき1つの質問
最後に、Boris Cherny氏のインタビューで一番刺さった一言を紹介します。
「
grepで十分ではないか？」
私はこれを聞いてから、社内のRAG提案レビューでまずこの問いを投げるようにしています。
- ナレッジがコードベース内にあるか? → grep/globで十分かもしれない
- 数千ファイル以下か? → 同上
- 意味的に近いものを引く必要があるか? → ここで初めてRAG
- 多言語の意味検索が必要か? → RAG
- PDF/画像など非構造データの横断検索か? → RAG
「LLMのcontext windowが100K→1Mと伸びた今、全部入れるで済む規模が増えた」というのも背景です。半年前なら「これはRAGでしょう」と即答していた規模感が、いま「いや、これは全部読ませても入る」になっています。
まとめ
Claude CodeのAgentic Searchを使って分かった3つの違いです。
- 精度: embeddingのfuzzy matchが消え、ピンポイントで取りこぼしがない
- 鮮度: インデックス再構築が消え、最新ファイルがそのまま検索対象
- プライバシー: embedding目的の外部APIが消え、社内導入の障壁が下がる
「RAGはもう古い」というほど単純な話ではありませんが、コード検索という特定用途では、Agentic Searchが明確に勝ちます。私が半年かけて作ったRAGパイプラインは、コード関連の部分を全部Agentic Searchに置き換えました。残ったのはオンボーディング資料・運用ドキュメントの検索だけで、それは今もRAGのままです。
これからナレッジ検索を組む方は、RAGを組み始める前に、まず grep で十分かを問うてみてください。私の場合は半分以上が「grepで十分」でした。
Claude Codeのセットアップから実用パターンまでを30分で押さえる無料Book「Claude Code Quickstart」では、本記事のAgentic Searchの章を含めて全5章を読めます。
Claude Code Quickstart (Kenimoto)