Claude Code が RAG を捨てた理由 -「Agentic Search」という選択肢

先日、YouTube で公開された技術チャンネル The Pragmatic Engineer のインタビュー動画（2026年3月公開）を見ていて、興味深い話を耳にしました。ゲストは Claude Code の中心的な開発者である Boris Cherny 氏。動画全体では Claude Code の開発経緯や、AI がエンジニアの働き方をどう変えるかといったテーマが語られていますが、その中で特に印象に残ったのが「コードベースの検索をどう実現しているか」という話題でした。

https://www.youtube.com/watch?v=julbw1JuAz0

Boris 氏はこう言い切っています。

"Agentic search just outperformed everything. And when I say agentic search, it's a fancy word for glob and grep. That's all it is."

（Agentic search がすべてを上回った。Agentic search というのは、glob と grep のことだ。それだけ。）

RAGが当たり前のように語られている今、Claude Code がそれを試したうえで捨てたという判断は、かなり示唆的です。この記事では、Boris 氏の発言を起点に、なぜ Agent にとって RAG が不要になりうるのか、そして Agentic Search が機能するための前提条件について考えてみます。

Claude Code が RAG を試して捨てるまで

Boris 氏はインタビューの中で、Claude Code の初期開発における試行錯誤をかなり率直に語っています。

まず最初に試したのは、当時の主流だった RAG によるコード検索でした。具体的には、TypeScript で書かれたローカルのベクトルデータベースをユーザーのマシンに置き、クラウド側の埋め込みモデル（embedding model）で算出したベクトルを格納する構成です。

"The way I did it was it was like a local vector database. I think it was like written in TypeScript and it just lived on the user machine. And then I was using some like embedding model in the cloud to compute the embeddings before storing it."

この仕組み自体は「pretty good（まずまず良い）」だったそうですが、実運用してみるといくつかの問題が浮上しました。

コードとの同期ずれ。 ローカルで関数を新しく書いても、まだインデックスに反映されていないため、RAG では見つけられない。開発中のコードベースは絶えず変化するので、この遅延は致命的です。

インデックスの権限管理。 誰がインデックスにアクセスできるのか。社内の悪意のある IT 担当者が他人のデータにアクセスできないようにするにはどうすればいいのか。Boris 氏はこの問題を「really, really important（本当に重要）」と強調しています。

結局、チームはさまざまなアプローチを試しました。モデルを使って再帰的にすべてをインデックスする方法、glob と grep を使う方法など。その結果たどり着いたのが、Agentic Search、つまりモデルに glob と grep を使わせるシンプルな手法でした。

面白いのは、このアプローチの着想源です。Boris 氏は以前 Instagram（Meta）でエンジニアをしていたのですが、当時の開発環境では「クリックで定義元にジャンプ」する機能がよく壊れていたそうです。そこでエンジニアたちは、関数 foo の定義を探すときに foo( でグローバル検索をかけるという方法を身につけた。これがそのままモデルにも通用した、という話です。

"Instead of click to definition, what you would do is you would use the global index, which is quite good at Meta, and then you would search for foo opening parenthesis. And this worked pretty well. And it's funny because like this works for the model pretty well too."

RAG の各手法を整理する

ここで一度、現在の RAG 周辺の技術を整理しておきます。Boris 氏の判断をより深く理解するために、それぞれの特徴と限界を把握しておくのは有用です。

従来型 RAG

2020 年に Facebook AI Research（現 Meta）が提案した手法で、外部知識をリアルタイムに検索して LLM の生成に組み込むアプローチです。

ハルシネーションの抑制や知識の鮮度を保ちやすいといった利点がある一方、チャンク分割の粒度設定が難しい、インデックスの同期遅延がある、権限管理が複雑になるといった課題を抱えています。

GraphRAG

2024 年に Microsoft Research が提案。LLM でドキュメントからナレッジグラフを構築し、コミュニティ検出と階層的な要約を行うことで、包括的な質問に強くなります。ただしインデックス構築コストが非常に高く、リアルタイム性には欠けます。

Agentic RAG

Agent が「どのツールで」「何を」「どの順序で」検索するかを動的に決定する仕組みです。固定パイプラインではなく、Agent の判断力に委ねる点が従来型と異なります。Claude Code の glob + grep もこの文脈に位置づけられます。

ハイブリッド検索

BM25（キーワード一致）とベクトル検索（意味的類似度）を組み合わせ、RRF などで結果を統合する手法です。検索精度は上がりますが、二重のインデックス管理が必要です。

これらを並べると、こんな構図が見えてきます。

手法	検索の賢さの置き場所	インデックス構築	リアルタイム性
従来型 RAG	パイプライン（Embedding + ベクトル検索）	必要	△（同期遅延）
GraphRAG	パイプライン（ナレッジグラフ + コミュニティ要約）	必要（高コスト）	✕
Agentic RAG	Agent の判断力	ツール次第	○
ハイブリッド検索	パイプライン（BM25 + ベクトル）	二重に必要	△
Claude Code 方式	Agent + grep/glob	不要	◎

なぜ Agent には RAG が要らないのか

さて、ここからが今回一番書きたかったところです。

従来の RAG は、ある前提のもとに設計されています。それは、検索者が「賢くない」 ということです。

一般的な RAG システムでは、ユーザーが入力した自然言語をそのまま埋め込みベクトルに変換し、ベクトル空間で最も近い文書チャンクを取り出します。ユーザーが適切な専門用語を知らなくても、意味的に近い文書を拾えるようにする。これが RAG のセマンティック検索の価値でした。

しかし、検索者が LLM Agent になると、この前提が崩れます。

Agent は自分で「意味をキーワードに変換」できます。 「デプロイの手順を教えて」という曖昧な意図があったとき、人間ユーザーはそのまま検索するかもしれません。しかし Agent は、grep "deploy"、grep "CI/CD"、grep "Dockerfile" といった具体的なキーワードを自ら生成して検索できます。RAG のベクトル検索が担っていた「意味の橋渡し」を、Agent 自身が行えるわけです。

Agent は検索を反復できます。 1回で見つからなければ、別のキーワードで試したり、まずディレクトリ構造を見て当たりをつけたりできます。従来の RAG が「1回の検索で最適な結果を返す」ことに最適化されているのに対し、Agent は試行錯誤を通じて目的の情報にたどり着けます。

Agent はディレクトリ構造を読める。 プロジェクトのフォルダ構成を見れば、設定ファイルは config/ に、テストは tests/ にある、といった推測ができます。これはベクトル検索では不可能な、構造的な推論です。

つまり、こういう対比になります。

知性をどこに置くか、という設計思想の違いです。RAG はパイプラインに知性を埋め込みました。Agentic Search は Agent 自身の知性に委ねました。LLM の能力が十分に高くなった今、パイプライン側の知性は冗長になった。これが Boris 氏の判断の本質だと思います。

Agentic Search を支える前提条件

ただし、「Agent が賢ければ grep で十分」という話には、語られていない前提条件があります。

実際に Claude Code を使い込んでみると、Agent がいくら賢くても、対象のドキュメントやコードベースが整理されていなければ、grep で必要な情報にたどり着くのは難しいということに気づきます。Agent が整理されていないファイル群の中で手当たり次第に検索を繰り返す、という状況は普通に起こりえます。

Agentic Search がうまく機能するためには、実は 3 つの要素がそろっている必要があります。

1. ドキュメントの構造化（人間の仕事）

ファイルの命名規則、ディレクトリ構成、ドキュメントの書き方。これらが整理されていれば、Agent は構造から推測して効率的に検索できます。逆に言えば、これは RAG のチャンク分割やインデックス構築に相当する作業を、人間が手動で行っているとも言えます。ただし、人間が意図を持って構造化したものは、自動的なチャンク分割よりもはるかに質が高いと言えます。

2. 検索ガイドの整備（Skills / CLAUDE.md）

Claude Code には CLAUDE.md という仕組みがあります。プロジェクトのルートにこのファイルを置いておくと、Agent が最初にそれを読み、プロジェクトの構造や規約を把握します。これは本質的に「Agent のための検索インデックス」です。

RAG がベクトルインデックスで担っていたことを、人間が自然言語で書いた案内文として提供しているわけです。実際の運用感としても、こちらの方がずっと正確に機能します。

3. Agent の検索能力（LLM + ツール）

最後に、Agent 自身が grep や glob を適切に使いこなせること。これは LLM の能力に依存しますが、Boris 氏が言うように、現在のモデルはこの点で十分な水準に達しています。

この 3 つの関係を図にすると、こうなります。

人間がやること          Agent がやること
─────────────         ──────────────
ドキュメント構造化       glob でファイル探索
検索ガイド作成          grep でコード検索
(CLAUDE.md / Skills)   反復的に戦略を調整

従来の RAG パイプラインでは、埋め込みベクトルの計算、ベクトル DB の構築・運用、チャンク戦略の設計、インデックスの同期など、これらすべてが自動化されている代わりに、その品質を人間がコントロールしにくいという問題がありました。

Agentic Search のアプローチでは、人間は「ドキュメントを整理する」「検索ガイドを書く」という、より直感的で制御しやすい作業に集中できます。技術的な複雑さは Agent 側が吸収する。この分業は、かなり理にかなっていると感じています。

まとめ

RAG が不要になった、という話ではありません。検索者が人間であるシステム（社内ナレッジ検索、カスタマーサポートなど）では、依然として RAG のセマンティック検索は有効です。

ただ、検索者が LLM Agent である場合——つまり AI コーディングツールや自律型エージェントの文脈では、パイプラインに知性を埋め込むよりも、Agent 自身の判断力と単純なツールの組み合わせの方が効率的に機能します。Boris 氏の経験はそれを示しています。

そして、その Agentic Search を支えているのは、整理されたドキュメントと、Agent への適切なガイド。ここに手を抜くと、どんなに賢い Agent でも迷子になります。結局のところ、ツールの選択以上に、検索対象の整備の方が重要なのかもしれません。