Claude CodeがRAGを捨ててAgentic Searchを選んだ理由——実務で使える検索パターン集

はじめに

「100万行のコードベースから、必要なファイルを素早く見つけるにはどうすればいい？」

AI開発ツールを使っていると、一度は考える問題です。従来の答えは「RAG（Retrieval-Augmented Generation）」——コードをベクトル化してデータベースに保存し、意味的に近いものを検索する手法でした。

ところが2026年初頭、Claude Code創設者のBoris Cherny氏が衝撃的な発言をしました。

「初期のClaude CodeではRAG＋ローカルベクターDBを使っていたが、最終的にAgentic Searchの方が圧倒的に良いと分かった」

この投稿は100万回以上表示され、業界で大きな議論を呼びました。本記事では、なぜClaude CodeがRAGを捨てたのか、そしてAgentic Searchがどう機能するのかを解説し、実務で使える検索パターンをハンズオンで紹介します。

この記事を読み終わったら、以下ができるようになります。

• RAGとAgentic Searchの本質的な違いを説明できる
• Claude Codeの検索ツール（Grep・Glob・Read）を戦略的に使い分けられる
• 大規模コードベースで効率的にファイルを探索できる

Claude CodeがRAGを捨てた4つの理由

従来のRAGアーキテクチャ

まず、Claude Codeが初期に採用していたRAGの仕組みを整理します。

コードをベクトル化してローカルDBに保存し、質問が来たら意味的に近いコードを検索してLLMに渡す。一見合理的に見えますが、Claude Codeチームは4つの課題に直面しました。

課題1: 精度の問題——コード検索は「完全一致」が命

RAGの得意技は「意味的に近いもの」を見つけることです。自然言語の質問応答では強力ですが、コード検索ではこれが裏目に出ます。

コードの世界では「意味的に近い」よりも「正確に一致する」ことの方がはるかに重要です。grepでhandleSubmitを検索すれば100%正確にヒットしますが、ベクトル検索では関係ないコードがノイズとして混入します。

課題2: 鮮度の問題——インデックスは必ず古くなる

開発中のコードベースは常に変化します。ファイルの追加・削除・リネームが頻繁に発生し、ベクトルDBのインデックスはすぐに古くなります。

インデックスの再構築にはコストと時間がかかります。毎回フルリビルドするのは現実的ではなく、差分更新の仕組みを作るのも複雑です。

課題3: セキュリティとプライバシー

ベクトルDBにコードを保存するということは、コードの埋め込み表現（Embedding）がローカルに残ることを意味します。企業のコードベースではこれがセキュリティリスクになります。

• 埋め込みデータからの情報漏洩リスク
• データポイゾニング（悪意あるコードが検索結果を汚染する）の可能性
• 企業のセキュリティポリシーとの衝突

課題4: 運用コスト

ベクトルDBの運用には、インデックス管理、ストレージ、初期化処理など、本来のコード検索とは関係ないオーバーヘッドが発生します。

Agentic Searchとは何か

人間のエンジニアの行動をそのままAIに

Agentic Searchの発想はシンプルです。「人間のエンジニアがコードを調べるとき、どうしているか？」をそのままAIに実行させます。

ポイントは、AIが自律的に検索→分析→再検索のループを回すことです。1回の検索で見つからなければ、キーワードを変えて再検索する。ファイル構造を確認してから、関連ディレクトリを深掘りする。人間のエンジニアとまったく同じ行動です。

RAGとAgentic Searchの本質的な違い

Claude Codeの3つの検索ツール

Claude Codeが使う検索ツールは3つだけです。シンプルですが、組み合わせ方次第で非常に強力になります。

Grep: テキストパターン検索

ファイルの中身を正規表現で検索します。「この文字列がどこに書かれているか」を知りたいときに使います。

# 関数名で検索
Grep: pattern="handleSubmit" path="src/"

# 正規表現で柔軟に検索
Grep: pattern="collection\([\"']users[\"']\)" path="src/"

# 特定のファイルタイプに限定
Grep: pattern="import.*firebase" glob="*.ts"

使いどころ: 関数名、変数名、エラーメッセージ、import文、設定値など、「正確な文字列」で探すとき。

Glob: ファイルパターン検索

ファイル名やディレクトリ構造をパターンで検索します。「このファイルはどこにあるか」を知りたいときに使います。

# TypeScriptファイルを探す
Glob: pattern="src/**/*.ts"

# 特定のディレクトリ配下のページコンポーネント
Glob: pattern="src/app/**/page.tsx"

# テストファイルを探す
Glob: pattern="**/*.test.ts"

使いどころ: プロジェクト構造の把握、ファイルの存在確認、特定パターンのファイル一覧。

Read: ファイル内容の読み取り

ファイルの中身を読みます。GrepやGlobで見つけたファイルの詳細を確認するときに使います。

# ファイル全体を読む
Read: file_path="src/lib/firebase.ts"

# 長いファイルの一部だけ読む
Read: file_path="src/app/page.tsx" offset=50 limit=30

使いどころ: GrepやGlobで特定したファイルの詳細確認、型定義の確認、設定ファイルの内容把握。

ハンズオン 1: 基本の検索パターン

ここからは、架空の業務システム「KanriPro」（Next.js + Firestore + TypeScript）のコードベースを例に、Agentic Searchの実践パターンを見ていきます。

パターン1: 関数の定義場所を探す

シナリオ: calculateTax 関数がどこで定義されているか知りたい。

Claude Codeへのプロンプト:
calculateTax関数の定義場所を探して、その実装内容を教えて。

Claude Codeの内部動作を見てみましょう。

ポイント: Grepの正規表現で function calculateTax と const calculateTax の両方にヒットさせています。TypeScriptでは関数宣言とアロー関数の両方がありえるため、パターンを広めにとるのがコツです。

パターン2: コンポーネントの使用箇所を探す

シナリオ: PaymentTable コンポーネントがどのページで使われているか知りたい。

Claude Codeへのプロンプト:
PaymentTableコンポーネントの使用箇所を全部リストアップして。

ポイント: 最初の Grep で名前の出現箇所を把握し、次に import 文を検索して実際に使っているファイルを絞り込んでいます。2段階検索で精度を高めるのがAgentic Searchの特徴です。

ハンズオン 2: 依存関係の調査パターン

パターン3: Firestoreコレクションの参照箇所を洗い出す

シナリオ: payments コレクションを参照しているすべてのファイルを特定し、影響範囲を把握したい。

Claude Codeへのプロンプト:
Firestoreのpaymentsコレクションを参照している箇所を全て特定して。
読み取り・書き込み・削除のそれぞれでどこから使われているかまとめて。

Claude Codeは以下のような多段検索を実行します。

実際のClaude Codeの動きをもう少し詳しく見ます。

[Claude Code内部の思考]
1. まず "payments" コレクションへの参照を全検索する
   → Grep: pattern="collection\([\"']payments[\"']\)" で6件ヒット

2. 型定義を確認する
   → Grep: pattern="interface Payment|type Payment" で src/types/payment.ts を発見
   → Read: src/types/payment.ts で構造を把握

3. ヒットしたファイルをそれぞれ読んで、操作種別を分類する
   → Read: src/app/accounting/payments/page.tsx    → 読み取り（getDocs）
   → Read: src/app/accounting/payments/actions.ts  → 書き込み（setDoc, updateDoc）
   → Read: src/lib/accounting/bank-transfer.ts     → 読み取り（query + where）
   → Read: src/app/api/payments/route.ts           → 読み取り + 書き込み
   → Read: src/app/accounting/reports/page.tsx      → 読み取り（集計用）
   → Read: src/lib/accounting/journal.ts           → 読み取り（仕訳生成用）

4. 結果を整理

出力例:

RAGでは「payments」に意味的に近いコード（例えば billing や invoice 関連）もノイズとして返ってきますが、Agentic Searchでは collection("payments") に完全一致するコードだけを正確に特定できます。

ハンズオン 3: プロジェクト構造の全体把握パターン

パターン4: 新メンバーのオンボーディング

シナリオ: 新しいプロジェクトに参加したとき、全体構造を素早く把握したい。

Claude Codeへのプロンプト:
このプロジェクトの全体構造を分析して。
ディレクトリ構成、主要なモジュール、データモデル、APIエンドポイントを整理して。

Claude CodeはGlobで構造を把握 → Readで詳細確認という流れを取ります。ベクトル検索では「プロジェクトの全体構造」のような抽象的なクエリに対して適切な結果を返すのが難しいですが、Agentic Searchではファイルシステムを直接探索するため、正確な構造情報を取得できます。

検索を効率化するCLAUDE.mdの活用

Agentic Searchの弱点は、トークン消費量が多いことです。検索のループが増えるほどコストがかかります。これを軽減するのが CLAUDE.md です。

プロジェクトのルートに CLAUDE.md を置いておくと、Claude Codeが毎回のセッション開始時に読み込みます。ここにプロジェクト構造のヒントを書いておくと、検索ループの回数を減らせます。

# プロジェクト構造

## ディレクトリ構成
- `src/app/`: Next.js App Routerのページ
- `src/components/`: 共有コンポーネント
- `src/lib/`: ユーティリティ・ビジネスロジック
- `src/types/`: TypeScript型定義

## Firestore コレクション
- `users`: ユーザー情報
- `payments`: 支払データ
- `suppliers`: 仕入先マスタ
- `journal_entries`: 仕訳データ

## 命名規則
- コンポーネント: PascalCase（例: PaymentTable.tsx）
- ユーティリティ: camelCase（例: calculateTax.ts）
- Server Actions: actions.ts（各ページディレクトリ内）

この情報があることで、Claude Codeは「payments コレクションの操作は src/app/accounting/payments/ あたりにありそうだ」と推測でき、最初の検索で正解に近づけます。

トークンコストとの付き合い方

Agentic Searchの最大のトレードオフはトークンコストです。最適化されたRAGと比べて4〜5倍のトークンを消費することがあります。

コストを抑えるためのTipsを3つ紹介します。

Tip 1: CLAUDE.mdで初期コンテキストを与える

前述の通り、プロジェクト構造を CLAUDE.md に書いておくだけで検索ループが減ります。

Tip 2: 具体的なプロンプトを書く

# 悪い例（検索範囲が広すぎる）
支払い関連のコードを調べて。

# 良い例（検索範囲が明確）
src/app/accounting/payments/actions.ts の updatePaymentStatus 関数で、
ステータスを「支払済み」に変更する処理を確認して。

Tip 3: パスを指定する

ファイルやディレクトリが分かっている場合は、プロンプトにパスを含めるとClaude Codeが直接 Read で読みに行けます。

# パスなし → GrepやGlobで探索が必要
PaymentTableコンポーネントの実装を確認して。

# パスあり → 直接Readで読める
src/components/PaymentTable.tsx の実装を確認して。

Agentic Searchが可能になった背景

なぜ今このアプローチが実用的になったのか。3つの技術的進歩が背景にあります。

2024年時点では、トークンコストが高すぎてAgentic Searchは非現実的でした。しかしClaude Opus 4.6世代では、推論能力の向上により少ない検索ループで正解にたどり着けるようになり、トークン単価の低下と合わせて実用的なコストに収まるようになりました。

まとめ

Claude CodeがRAGを捨てた理由と、Agentic Searchの実践パターンを整理します。

「RAGは不要になった」というのは語弊があります。正確には、コード検索という文脈では、ベクトル検索よりもエージェント型の反復検索の方が適しているということです。ドキュメント検索やナレッジベース検索では、RAGは依然として有効なアプローチです。

まずは普段のClaude Code利用で、CLAUDE.md にプロジェクト構造を書くことから始めてみてください。それだけでも検索精度と速度が体感できるレベルで改善します。

---

参考リンク：

• なぜ、Claude Codeは、RAGを捨ててAgentic Searchを選んだのか？（Zenn）
• なぜAnthropicはClaude CodeでベクトルDBを捨て「Agentic Search」に舵を切ったのか？（note）
• Claude Code 公式ドキュメント