コンテンツにスキップ

RAG不要論争を整理：Claude Codeが「狭義RAG（ベクターDB）」を捨てた理由と、コード検索の現実解

「RAGはもう要らない」——この言い回しは強いですが、"何を探すRAGなのか" を分けずに語ると、議論は必ず噛み合いません。 本記事は論点を コードベース探索（repo exploration / code search） に絞り、狭義RAG（embeddings + vector DB の事前インデックス） と Agentic Search（grep/ls/read などツールを回す探索） のトレードオフを"設計判断"として整理します。

この記事で学べること

Claude Codeが狭義RAGを捨てた一次情報と設計根拠 Agentic Searchの強みと弱点（トークン消費・概念検索の限界） 2026年の現実解＝ハイブリッド＋context engineeringの落とし所 自分の現場で判断するための3つの実測KPI

この記事の対象者

  • AIコーディングツール（Claude Code / Cursor等）を業務で使っている開発者
  • RAGパイプラインの採用・見直しを検討しているアーキテクト
  • 「RAG不要論」の真偽を一次情報から判断したいエンジニア

この記事のポイント

3行まとめ

  1. Claude Code開発者は、初期に「RAG + ローカルvector DB」を試し、すぐにAgentic Searchの方が概ね良いと判断した（理由：simplicity / security / privacy / staleness / reliability）
  2. ただしそれは"コード探索"の文脈での話。RAG（semantic index）が勝つ領域（概念検索・巨大repo・非コード知識）は残る
  3. 2026年の現実解は二項対立ではなく、Agenticを基軸に、必要な場面だけsemantic indexを差す「ハイブリッド」＋context engineering

迷ったら、まず3つの実測KPI（TTFRF / Tokens-per-task / Staleness incidents）を2〜3タスクで比べれば決まる。

1. 発火点：Claude Code開発者の一次発言（"RAG→Agentic"）

議論の起点になったのは、Claude Code開発者の Boris Cherny 氏の投稿です。要旨はこうです。

  • 初期のClaude Codeは RAG + ローカルvector DB を使っていた
  • しかしすぐに agentic search の方が概ね良い と分かった
  • よりシンプルで、security / privacy / staleness / reliability の問題が小さい
一次ソース

参照：X投稿（Boris Cherny）

"Early versions of Claude Code used RAG + a local vector db, but we found pretty quickly that agentic search generally works better."

注意

ここで対比されている「RAG」は、現場でよく指される"embeddings + vector DB の事前インデックス"（狭義RAG）として読むのが自然です。

2. まず用語を固定する：広義RAGと狭義RAG

この論争の8割は「RAGの定義」で荒れます。この記事では、実務でよく使われる分け方で固定します。

区分定義具体例
狭義RAG（本記事の「RAG」）チャンク化 → embeddings → vector DB → semantic retrieval（インデックスが返す）Cursor のコードベースインデックス、Pinecone / Weaviate 等
Agentic SearchLLMが grep/ls/read/edit を繰り返し呼び、探索をループして必要情報を集めるClaude Code の探索、サブエージェントによる並列検索

学術的・広義には「検索して生成に使う」ならAgenticもRAGに含められる、という整理もあります。 ただ、現場の実装・運用判断としては"インデックス型か、ライブ探索型か"を区別する方が議論が速い。

RAGパイプラインの基礎を復習したい方へ

RAGの基本アーキテクチャについては RAGパイプライン実装ガイド で詳しく解説しています。

3. なぜ"コード探索"ではAgentic Searchが勝ちやすいのか

Boris氏が列挙した論点（staleness / reliability / simplicity / security）は、コード検索で特に刺さります。

3.1 staleness：インデックスは、速いが古くなる

コードは日々変化します。インデックスは常に古くなります。 これを正しく回すには、差分更新・再チャンク・再embedding・権限境界・暗号化・監査…と設計が増えます。

一方でCursorは、まさにこの"運用負債"を正面から解く方向に進んでいます。 「組織内のクローンは高い類似度を持つ」前提で、チームメンバーの既存インデックスを安全に再利用し、Time-to-first-queryを大幅短縮する設計を公開しました。

Cursorの設計アプローチ

参照：Cursor - Securely indexing large codebases

→ つまりstalenessや運用が地獄だからRAGが終わりではなく、RAG側も"運用に耐える設計競争"に入っているというのが実態です。

3.2 reliability：コードは"似てる"より"参照が正しい"

バグ修正やリファクタでは「似てるコード片」よりも、正確な情報が重要です。

  • 正確なシンボル名
  • import/参照元
  • 呼び出し箇所
  • ファイルパス

Agentic Searchは、grepやファイル読みによって証拠を積み上げて参照関係を確定しやすい。 ここが、semantic retrievalが外したときの手戻りを減らします。

3.3 simplicity：稼働部品が増えない＝壊れにくい

インデックス生成・保存・同期・権限・漏洩対策は、プロダクトとしては"もう1つのシステム"です。 Agentic Searchは既存のツール（rg/ls/cat等）とファイル実体を使うため、障害点が増えにくい。

Claude Codeの場合

Claude Codeでは Hooks や サブエージェント で探索を拡張でき、追加インフラなしで柔軟な検索が可能です。

3.4 security / privacy：データの行き先を最小化しやすい

クラウドembeddingや外部DBは、設計を誤ると情報流出経路になり得ます。 ローカル探索中心は「データを外に出さない」説明がしやすく、企業導入で刺さります。

エンタープライズ導入のセキュリティ考慮

Claude Codeのエンタープライズ向けセキュリティ設計については Claude Code エンタープライズ展開ガイド を参照してください。

4. ただしAgentic Searchにも"刺される弱点"がある

ここを隠すと負ける

バランスを取るなら、弱点を明示した方が反論耐性が上がります。

4.1 トークン/時間が膨らむ（探索ループ・試行錯誤の連鎖）

実際にClaude CodeのIssueでは「レビュー/検索でトークンを燃やすので、コードベースの索引が欲しい」という要望が出ています。

→ Agenticは"最悪ケースのコスト上振れ"を抱えます。ここはRAG側の反論として最も強い。

トークン消費を抑える工夫

Claude Codeの Task Tool（サブエージェント） を活用すると、探索範囲を分割して並列実行でき、無駄な探索ループを抑制できます。

4.2 概念検索の初動が弱い

「名前が分からない」「仕様用語と実装用語がズレている」局面は、semantic indexがナビとして効きます。 Cursorも "semantic searchは性能を左右する" と位置づけ、インデックスの高速化を最重要テーマの一つとして扱っています。 （参照：Cursor - Secure codebase indexing）

4.3 ローカル探索でも"権限/監査"は消えない

ローカルであっても「どのディレクトリを読ませるか」「秘密情報をどう除外するか」「どの操作を許可するか」は設計が必要です。 Claude Codeはモデル設定や挙動を複数経路で切り替えられ、運用ポリシー側の工夫余地もあります。

Claude Codeの設定体系を詳しく知りたい方へ

Claude Codeの設定ファイル・パーミッション・環境変数を網羅した 完全リファレンス も参考になります。

5. 第三者比較：Cursorが勝つ場面／Claude Codeが勝つ場面

「結局どっち？」に対して、第三者比較があると議論が落ち着きます。 Renderのベンチマークでは、ざっくり以下の傾向が示されています。

評価軸CursorClaude Code
セットアップ、デプロイ系 優位—
コード品質 優位—
素早いプロトタイピング— 優位
ターミナルUX— 優位
ベンチマーク出典

参照：Render - Testing AI coding agents（2025/08）

この結果は「RAGが死んだ/Agenticが絶対勝つ」ではなく、用途別最適を示唆します。

関連記事

AIコーディングツールの比較については AI開発ツール総合ガイド も参照してください。

6. 2026年の現実解：二項対立ではなく"ハイブリッド＋context engineering"

最近の整理として分かりやすいのが、「RAGは死んでない。ただ"context engineering"が主戦場になった」という見立てです。

Context Engineeringの台頭

参照：The New Stack - RAG isn't dead, but context engineering is the new hotness

ここでいう"context engineering"を、コード探索に翻訳するとこうなります。

6.1 典型的な勝ち筋アーキテクチャ

graph LR
    A[コード探索タスク] --> B{探索タイプ?}
    B -->|シンボル名/パス既知| C[Agentic Search<br/>grep / ls / read]
    B -->|概念/仕様用語| D[Semantic Index<br/>embeddings検索]
    C --> E[探索ログ圧縮<br/>要約/スケッチ]
    D --> E
    E --> F[LLM生成<br/>コード修正/回答]
    F --> G[権限/除外ガード]
レイヤー役割具体例
基軸：Agentic Search正確性・鮮度・参照確定grep / ls / read のループ
補助：Semantic Index概念検索、巨大repoのナビ、横断探索embeddings + vector DB
圧縮：要約/スケッチ探索ログを短く保ち、再読を減らすコンテキスト要約
ガード：権限/許可リスト漏洩と事故を潰す.claude/settings.json 等

Context Engineeringの実践

Claude Codeでのコンテキスト制御は プロンプティングガイド や CLAUDE.md入門 が実践的です。

7. 迷ったらこれを測る：3つの実測KPI

「閾値（LOC何万行）」は根拠が薄い

「〇万行以上ならRAG」のような閾値は再現性が低く、反論されやすい。代わりに測れるKPIを置くと強いです。

KPI何が分かる目安の読み方
Time-to-first-relevant-file（TTFRF）当たりファイルに最短で辿り着けるか概念探索が多いならRAG/semanticが効く
Tokens-per-taskコスト上振れのしやすさAgenticが暴れるならhybrid検討
Staleness incidents古い文脈で手戻りした回数多いなら"ライブ探索"が有利

おすすめ手順

同じ2〜3タスクを用意する（バグ修正、リファクタ、新機能追加など）

  • (A) Agenticのみ（Claude Code標準）
  • (B) Semantic indexあり（Cursor等のRAG寄りツール）

上記3指標を比較 → "あなたの現場"の最適解が出る

8. 結論（コード検索限定）

コード検索で争点になるのは「RAGかAgenticか」ではなく、結局この3つです。

  1. 鮮度（staleness）
  2. 当たりへの到達速度（TTFRF）
  3. 総コスト（トークン/時間/運用）

多くの現場では、まずAgentic Searchを基軸に置きつつ、 概念検索・巨大repo・横断探索だけsemantic indexを補助として差すのが、最も失敗しにくい落とし所になります。

次のステップ

参考リンク（一次・準一次）

補足（因果主張には使わない）

AnthropicがClaude Codeの"run-rate revenue"到達を公式記事で言及：https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone