Claude Codeが「RAGを捨てた」理由｜開発者Boris Chernyが明かしたAgentic Searchの全貌

2026年2月1日、Claude Codeの生みの親であるBoris Cherny氏が、X（旧Twitter）で衝撃的な事実を明かしました。

「Claude Codeの初期バージョンはRAG＋ローカルベクトルDBを使っていたが、Agentic Searchの方が圧倒的に優れていることをすぐに発見した。Agentic Searchはよりシンプルで、セキュリティ・プライバシー・データの鮮度・信頼性の面でも問題がない」

年間売上10億ドル（約1,500億円）を突破したClaude Codeが、AI業界の「常識」であるRAG（ベクトル検索）を捨て、grep/globというシンプルな検索手法を選んだ ―― この設計判断は、AIアプリケーション開発の根本的な前提を覆すものです。

本記事では、Boris Cherny氏の一次ソース（Xポスト・ポッドキャスト・Hacker Newsコメント）を網羅的に検証し、Agentic Searchの技術的本質、RAGとの比較、Milvusからの反論、そしてあなたのプロジェクトへの実践的な示唆まで、徹底的に解説します。

目次

1. Boris Chernyとは何者か ―― Claude Codeを一人で作った男
2. 何が起きたのか ―― RAGを試し、捨てるまでの経緯
3. Agentic Searchとは何か ―― 技術的な定義と仕組み
4. Claude CodeのAgentic Search ―― 内部動作を完全解剖
5. なぜRAGより優れていたのか ―― 3つの決定的な理由
6. 「Vibes（感覚）で判断した」―― Boris流の評価哲学
7. Milvus（Zilliz）からの反論 ―― 「トークンを燃やしすぎだ」
8. Cursor vs Claude Code ―― 検索アーキテクチャ徹底比較
9. $1B ARRが証明したもの ―― ユーザーはどちらを選んだか
10. 判断フレームワーク ―― RAG vs Agentic Search、どちらを選ぶべきか
11. ハイブリッドアプローチという現実解
12. あなたのプロジェクトへの示唆 ―― 明日からできること
13. まとめ ―― 「複雑なシステムより、シンプルで精度が高い方が勝つ」

1. Boris Chernyとは何者か ―― Claude Codeを一人で作った男

記事の内容を正しく評価するために、まず発言者の背景を理解しておく必要があります。

Boris氏は2024年9月にAnthropicに入社後、Claude 3.6モデルを使ってClaude Code（当初の名称は「Claude CLI」）のプロトタイプを一人で構築しました。驚くべきことに、現在のClaude Codeのコードの80〜90%はClaude自身が書いたものです。

つまり、AIがAI開発ツールのコードを書き、そのツールで人間がさらにAIを活用する ―― という再帰的な構造が生まれています。

このような経歴を持つエンジニアが「RAGよりgrepの方が良かった」と言っているわけですから、その判断には相応の重みがあります。

2. 何が起きたのか ―― RAGを試し、捨てるまでの経緯

Boris Cherny氏の発言は、複数の一次ソースから確認できます。時系列で整理しましょう。

2025年3月：Hacker Newsでの初回言及

Boris氏はHacker News上で、以下のように述べています。

「Claude Codeは現在RAGを使っていない。テストの結果、Agentic SearchがClaude Codeのユースケースに対してRAGを上回る性能を示した」
― Boris Cherny, Hacker News（2025年3月頃）

2025年5月7日：Latent Spaceポッドキャストでの詳細説明

最も詳細な発言は、テックポッドキャスト「Latent Space」でのインタビューです。Boris氏とClaude Code PMのCatherine Wu氏が出演し、設計判断の背景を語りました。

「初期バージョンのClaude Codeは実際にRAGを使っていた。コードベースをインデックス化し、確かVoyage（エンベディング）を使っていたと思う」
― Boris Cherny, Latent Space Podcast（2025年5月7日）

「（Agentic Searchは）すべてを圧倒的に上回った。大幅に。大幅に。これは驚きだった」
― Boris Cherny, 同上

Catherine Wu氏も補足しています。

「最初はベクトルエンベディングを使っていた。でも維持が非常に難しい。コードを継続的に再インデックスしなければならず、古くなるし、ローカルの変更もある」
「Claudeモデルはagentic searchが非常に得意。同じ精度レベルをagentic searchで達成でき、デプロイメントがはるかにクリーンになる」
― Catherine Wu, Every Podcast

2026年2月1日：X（旧Twitter）での発言（バイラル化）

@EthanLipnikが「なぜCodexやClaude Codeは、Cursorのようなクラウドベースのエンベディングを使わないのか？」と質問。Boris氏が返答しました。

「Claude Codeの初期バージョンはRAG＋ローカルベクトルDBを使っていたが、agentic searchの方が一般的に優れていることをすぐに発見した。よりシンプルで、セキュリティ・プライバシー・データの鮮度・信頼性の面でも同じ問題がない」
― Boris Cherny, X（2026年2月1日）

このポストが大きな反響を呼び、プロダクト・アナリストのAakash Gupta氏は次のようにコメントしました。

「Claude Codeの開発者が『RAG業界全体が間違った問題を解いている』と言ったのに、誰もまだ価格を修正していない」
― Aakash Gupta, X

3. Agentic Searchとは何か ―― 技術的な定義と仕組み

まず、用語を正確に定義しましょう。

RAG（従来型）の仕組み

1. コードベースを事前にチャンク分割
2. 各チャンクをエンベディングモデル（Voyage等）でベクトル化
3. ベクトルDBに保存（Pinecone、Milvus、Turbopuffer等）
4. ユーザーのクエリもベクトル化し、類似度検索で関連チャンクを取得
5. 取得したチャンクをLLMのコンテキストに挿入して回答生成

本質：情報をモデルに「プッシュ」する

Agentic Searchの仕組み

1. 事前のインデックス構築はしない
2. モデル自身がgrep（全文検索）やglob（ファイルパターン検索）などのツールを呼び出す
3. 検索結果を分析し、追加の検索が必要か判断
4. 必要に応じて検索を繰り返し（マルチショット）、段階的に必要な情報を収集
5. 十分な情報が集まった段階で回答を生成

本質：モデルが情報を「プル」する

Hacker Newsユーザーのjcheng氏が簡潔に表現しています。

「追加情報がクエリの一部としてモデルにプッシュされたなら、それはRAG。モデルがツール呼び出しで追加情報をプルしたなら、それはAgentic Search」

4. Claude CodeのAgentic Search ―― 内部動作を完全解剖

Claude Codeは、以下の専用ツールを使ってagentic searchを実行します。

重要なのは、Claude CodeのシステムプロンプトでBashでのgrep/find/catの使用が明示的に禁止されていることです。代わりに、専用のGlob・Grep・Readツールの使用が指示されています。これにより、検索の安全性と効率性が担保されます。

実際の検索フロー（例：「認証機能のバグを修正して」）

Claude Codeが「認証機能のバグを修正して」というリクエストを受けた場合、以下のような思考・検索プロセスが発生します。

ステップ1：ファイル構造の把握（Glob）

Glob: **/*auth*  →  src/middleware/auth.ts, src/services/auth-service.ts, tests/auth.test.ts ...

ステップ2：関連コードの検索（Grep）

Grep: "authenticate|authorization|token" --type=ts  →  該当箇所を特定

ステップ3：ファイルの詳細読み込み（Read）

Read: src/middleware/auth.ts  →  コード全体を理解

ステップ4：追加調査（判断→再検索）

Grep: "jwt.verify|jwt.sign" →  トークン検証ロジックを追跡
Read: src/config/jwt.ts →  設定値を確認

ステップ5：依存関係の追跡

Grep: "import.*auth" →  authモジュールを使っている全ファイルを特定

このように、モデルが文脈を理解しながら段階的に情報を集めるため、ベクトル類似度では見つけられない「論理的なつながり」を追跡できます。RAGでは「authに関連するチャンク」を返すだけですが、Agentic Searchでは「authモジュールをインポートしている設定ファイルの中身」まで自律的にたどり着きます。

5. なぜRAGより優れていたのか ―― 3つの決定的な理由

Boris Cherny氏の発言を整理すると、RAGを捨てた理由は3つに集約されます。

理由1：精度が圧倒的に高かった

「すべてを圧倒的に上回った。大幅に。大幅に。これは驚きだった」
― Boris Cherny, Latent Space Podcast

なぜモデルがgrepで検索する方が、ベクトル類似度検索より精度が高いのか？

コードベースには、自然言語の文書とは異なる特性があります。

• 構造が明確：ディレクトリ構造、ファイル命名規則、import文が「地図」の役割を果たす
• シンボルが正確：関数名・変数名・クラス名は一意であり、grep一発で特定できる
• 文脈依存性が高い：同じ「auth」という単語でも、ミドルウェア・サービス・テストでは意味が異なる。モデルはファイルを読んで文脈を理解できるが、エンベディングではこの違いが潰れる

ベクトル検索は「意味的に似ている」チャンクを返しますが、コードの世界では「意味的に似ている」と「実際に関連がある」は別物です。認証バグの修正に必要なのは、authに「似た」コードではなく、authを「呼び出している」コードです。

理由2：運用がシンプル

「Agentic Searchはこれらすべてを回避する。レイテンシとトークンのコストと引き換えに、セキュリティの懸念なしに本当に素晴らしい検索が得られる」
― Boris Cherny, Latent Space Podcast

RAGには以下の運用負担があります。

Catherine Wu氏が指摘した通り、コードベースは絶えず変化します。ブランチを切り替えるだけでファイルが大量に変わり、ローカルの未コミット変更もあります。RAGではこれらすべてを追跡してインデックスに反映する必要がありますが、Agentic Searchではファイルシステムを直接見るため、同期問題が原理的に発生しません。

理由3：セキュリティ・プライバシー設計がシンプル

Boris氏が特に強調したのがセキュリティです。

RAGでは、コードのチャンクをベクトル化してどこかに保存する必要があります。

• ローカルに保存：ディスク容量を消費し、マシン紛失時のリスク
• クラウドに保存：コードがサードパーティのサーバに渡る。企業のセキュリティポリシーに抵触する可能性

Boris氏は、Anthropic自身のコードベースですらこの問題があったと示唆しています。Agentic Searchではインデックスを一切作成しないため、コードがローカルマシンから一切出ない（検索結果のみがLLMに送信される）という設計が可能です。

6. 「Vibes（感覚）で判断した」―― Boris流の評価哲学

Boris氏の発言の中で、最も議論を呼んだのがこの一言です。

「これはvibes（感覚）だった。内部的なvibes。内部ベンチマークもあるが、主にvibes。単純に良い感じがした」
― Boris Cherny, Latent Space Podcast

この「vibes-based evaluation（感覚ベースの評価）」は、一見すると非科学的に聞こえます。しかし、Boris氏がここで言っていることは、AI開発における重要な真実を含んでいます。

なぜ数値ベンチマークだけでは不十分なのか

コード検索の品質は、単純な「Precision/Recall」では測定しきれません。

• 関連ファイルを10個中8個見つけても、最も重要な1個を見逃せば意味がない
• 検索速度が速くても、結果が「惜しい」レベルでは人間が追加調査する手間が増える
• ベンチマークで高スコアでも、実際のワークフローで「使いやすい」とは限らない

Boris氏が「vibes」で判断したのは、実際に使った時のエンドツーエンドの体験が決定的に異なったということです。これは、SaaS開発において「NPS（顧客推奨度）がGTM指標より重要」という考え方と同じです。

実際、Claude Codeはこの「vibes-first」の判断で市場に投入され、半年で$1B ARRという驚異的な成長を遂げました。結果が判断の正しさを証明しています。

7. Milvus（Zilliz）からの反論 ―― 「トークンを燃やしすぎだ」

Boris氏の発言に対し、ベクトルDB大手のMilvus（開発元：Zilliz）が反論記事を公開しました。

Milvusの3つの主張

主張1：トークン消費が多すぎる

Milvusは、grepベースの検索が大量の無関係なコードをLLMに送り込み、リポジトリの規模に応じてコストが急激に増加すると主張しました。

主張2：時間効率が悪い

意味的な理解なしに複数のクエリを実行するため、ワークフローに遅延が生じるという指摘です。

主張3：意味的な認識力が欠如

「grepはリテラル文字列のマッチングしかできず、コードの関係性や意味についてのコンテキスト理解がゼロ」というのが技術的な核心です。

Milvusは、ベクトル検索によりトークン消費を約40%削減できると主張し、自社製品「Claude Context」（Claude Code用MCPプラグイン）を発表しました。

この反論をどう評価すべきか

Milvusの主張には一定の妥当性がありますが、重要な文脈を考慮する必要があります。

Milvusの反論で見落とされているのは、「grep + LLMの推論力」というシステム全体の能力です。grepは確かにリテラルマッチしかできませんが、その結果をClaude（世界最高水準のLLM）が読み解き、次の検索を自律的に判断します。これは単なる「grep検索」ではなく、「LLMが知性を持ってgrepを使いこなしている」状態です。

8. Cursor vs Claude Code ―― 検索アーキテクチャ徹底比較

Agentic Search vs RAGの議論を具体的に理解するために、Claude CodeとCursorのアーキテクチャを直接比較します。

Cursorは2026年2月にセキュリティの懸念に応え、インデックスの暗号化とMerkle Tree方式の効率的な差分更新を導入しました。一方、Claude Codeはインデックスを作らないことで、そもそもこの問題を「解決する必要がない」状態にしています。

Jolt AIのベンチマークによると、大規模コードベースでの検索タスクにおいて、Claude Code（Agentic Search）はCopilot（ベクトル検索）より多くの関連ファイルを発見しましたが、処理時間は3〜5倍長かったとされています。

つまり、速度を重視するならCursor、精度と安全性を重視するならClaude Codeというのが現時点での使い分けです。

9. $1B ARRが証明したもの ―― ユーザーはどちらを選んだか

Claude Codeの商業的成功は、Boris氏の設計判断を市場が支持したことの証明です。

わずか7ヶ月で$0→$1.1B。Claude CodeはAnthropicの総売上$9Bの約12%を占め、SaaS史上でも異例のスピードです。

この成長を支えたのは「RAGの方がトークン効率が良い」ではなく、「実際に使った時に、正確に目的のコードを見つけてくれる」という体験でした。

Boris氏が「vibes」で判断した精度とUXの優位性を、数百万人のユーザーが財布を開いて証明した形です。

10. 判断フレームワーク ―― RAG vs Agentic Search、どちらを選ぶべきか

「RAGは不要」という単純な結論は正しくありません。Boris氏の判断はあくまで「コードベース検索」における最適解です。用途に応じた使い分けが重要です。

5つの質問で判定する

以下の質問に答えることで、あなたのプロジェクトにどちらが適しているか判断できます。

ユースケース別の推奨

11. ハイブリッドアプローチという現実解

実務では「RAGかAgentic Searchか」の二者択一ではなく、両者を組み合わせるハイブリッドアプローチが最も現実的です。

ハイブリッドの実装パターン

パターン1：Agentic Search + MCP経由のRAG

Claude CodeはMCP（Model Context Protocol）をサポートしており、必要に応じてベクトル検索をツールとして追加できます。Catherine Wu氏も公式にこの方法を推奨しています。

「もしClaude Codeにセマンティック検索を持ち込みたいなら、MCPツール経由で行うことができる」
― Catherine Wu, Every Podcast

パターン2：初回はRAGで候補を絞り、Agentic Searchで深掘り

大規模なコードベース（数百万行以上）では、最初にベクトル検索で関連ファイルの候補を50個程度に絞り込み、その後Agentic Searchで詳細な分析を行うという二段構えが有効です。

パターン3：検索対象によって使い分け

同一プロジェクト内でも、コードファイルにはAgentic Search、ドキュメント（README、Wiki、設計書）にはRAGという使い分けが考えられます。

ClineやRelaceの実践例

AIコーディングツール「Cline」もClaude Codeと同様にRAGを使わない設計を選択し、公式ブログで「意図的な設計判断」と明言しています。

一方、「Relace」はAgentic Searchの速度問題に取り組み、ツール呼び出しの並列化によりレイテンシを4分の1に削減することに成功しました。

これらの事例は、Agentic Searchが「Claude Codeだけの特殊な選択」ではなく、AIコーディングツールの業界トレンドになりつつあることを示しています。

12. あなたのプロジェクトへの示唆 ―― 明日からできること

Boris Cherny氏の設計判断から、以下の実践的な教訓を引き出せます。

教訓1：RAGを導入する前に「grepで十分か」を試す

特にコードベース検索の場合、以下の条件が揃っていれば、複雑なRAGパイプラインを構築する前にAgentic Searchパターンで十分かもしれません。

• ファイル構造が明確（ディレクトリ名、ファイル名が内容を表している）
• 命名規則が統一されている（関数名、変数名で検索可能）
• モデルがコンテキストを理解できる（自然言語のコメントやドキュメントがある）

教訓2：「複雑なシステムより、シンプルで精度が高い方が勝つ」

RAGは「正解」と思われていました。ベクトルDB、エンベディングモデル、チャンク戦略、リランキング ―― 複雑なパイプラインを構築することが「正しいアプローチ」とされてきました。

しかし、Claude Codeチームは実験して、シンプルな方法を選びました。

• ベクトルDB構築の手間がない
• インデックス同期の問題がない
• モデルの能力向上に伴い、検索精度も自動的に上がる

最後のポイントは特に重要です。RAGの精度はエンベディングモデルとパイプラインの品質に依存しますが、Agentic Searchの精度はLLMの推論能力に直結します。モデルが賢くなるほど、検索も賢くなります。

教訓3：評価は「vibes」から始めていい

完璧なベンチマークを作ってから比較するのではなく、まず実際に使ってみて「どちらが良い感じがするか」を体感する。Boris氏のアプローチは、スタートアップ的な「Build → Measure → Learn」のサイクルそのものです。

数値的な評価は重要ですが、ユーザー体験の微妙なニュアンスは数値だけでは捉えきれません。「vibes」は非科学的ではなく、高度なドメイン知識に基づく直感的評価です。

教訓4：トレードオフを受け入れる

Agentic Searchは万能ではありません。Boris氏自身が認めているように、「レイテンシとトークンのコスト」というトレードオフがあります。

• 大規模ドキュメント検索や非構造化データには、RAGやハイブリッドアプローチが有効
• ミリ秒レベルのレスポンスが求められるリアルタイムシステムには不向き
• APIコストを最小化したいプロジェクトでは、RAGの方がトークン効率が良い

重要なのは「どちらが正解か」ではなく、「自分のユースケースにはどちらが最適か」を実験して判断することです。

13. まとめ ―― 「複雑なシステムより、シンプルで精度が高い方が勝つ」

Boris Cherny氏の設計判断は、AI開発における重要な教訓を示しています。

事実の要約：

• Claude Codeの初期バージョンはVoyageエンベディング + ローカルベクトルDBを使用していた
• Agentic Search（grep/glob + LLM推論）に切り替えた結果、「すべてを圧倒的に上回った」
• 精度、運用シンプル、セキュリティの3つの理由でRAGを捨てた
• この判断のもとでClaude Codeは7ヶ月で$1.1B ARRを達成した

学べること：

• 「業界の常識」を疑い、実験で検証することの重要性
• シンプルな設計がもたらす運用・セキュリティ上の優位性
• LLMの推論能力が向上するほど、Agentic Searchの精度も自動的に向上する
• RAGとAgentic Searchは対立するものではなく、用途に応じて使い分けるもの

次にRAGパイプラインを構築しようとしているなら、まず一歩引いて考えてみてください。

「本当にベクトル検索が必要か？ モデルにgrepを渡すだけで十分ではないか？」

Claude Codeの成功は、この問いかけが単なる怠慢ではなく、最も賢い設計判断になりうることを証明しました。

---

関連記事

• Claude Code 完全攻略ガイド｜ハッカソン優勝者が明かす本当の使い方
• Claude Code Agent Teams完全ガイド｜セットアップから実践活用まで徹底解説
• RAGとは？仕組み・メリット・導入判断を徹底解説
• RAG vs ファインチューニング徹底比較｜どちらを選ぶべき？
• Claude Code vs Codex 徹底比較｜料金・性能・実機検証で選び方を解説