RAG Claude Code｜ベクトル検索と探索型の使い分け実例

rag claude codeで先に知るべきこと

RAGは、質問に関係する情報を先に検索し、その結果を生成AIへ渡して回答を作る仕組みです。一般に「RAG」と呼ぶときは、文書を分割して埋め込みを作り、ベクトルDBへ保存し、質問に近いチャンクを上位から取得する構成を指します。

一方のClaude Codeは、ターミナルでプロジェクトを開き、ファイル検索、読込、編集、コマンド実行、テストを必要に応じて組み合わせます。公式ドキュメントも、まず文脈を集め、作業し、結果を検証する流れとして説明しています。つまり「Claude CodeにRAGはあるか」という疑問は、標準のコード探索をRAGと呼ぶか、別途ベクトル検索を接続するかで答えが変わります。

出典URL: https://code.claude.com/docs/en/how-claude-code-works

Claude Code標準の探索は固定型RAGと違う

Claude Codeをリポジトリのルートで起動すると、現在のファイル、Gitの状態、ターミナルなどを使って必要な情報を探します。最初に全コードを埋め込み化してベクトルDBへ登録する前提ではなく、質問に応じてファイル名や内容を検索し、関係するファイルを読み進める方式です。公式FAQでも、Claude Codeはリポジトリを読み、ファイルを編集し、コマンドを実行する端末向けの機能として整理されています。

この方式は、関数名、設定キー、依存関係、ファイルパスのような正確な一致に強いのが特徴です。ブランチを切り替えた直後でも、現在の作業ツリーを対象にできます。コードの変更とテスト結果を往復する作業なら、別の検索基盤を運用しないほうが速いケースが多いでしょう。

ただし、リポジトリ外の社内規程、古いAPIマニュアル、複数プロジェクトにまたがるFAQを自然文で横断したい場合は、標準の探索だけでは対象をそろえにくくなります。そこでは外部RAGや検索サーバーを追加する意味が出てきます。

出典URL: https://support.claude.com/en/articles/14554922-claude-code-user-faq

RAGと探索型検索の使い分け

両者は優劣ではなく、検索対象の性質で選びます。固定型RAGは「意味が近い文書を大量の候補から取り出す」処理に向き、Claude Codeの標準探索は「今あるコードを調べ、追加の検索や検証を自分で組み立てる」処理に向きます。

「RAGを入れれば回答が正確になる」と決めつけるのは危険です。検索結果に出典、章、更新日時を含め、Claude Codeが根拠を確認できる状態まで設計して、初めて実務で使える検索になります。

RAGを追加するべき3つの条件

次の条件に当てはまるほど、Claude Codeへ外部RAGをつなぐ効果が大きくなります。

1. リポジトリ外の文書を、開発中にも参照したい。社内規程、製品マニュアル、顧客ごとの契約条件など、毎回ファイルをコピーできない情報が対象です。
2. 文書量が多く、ファイル名や保存場所を覚えていられない。質問の言い換えが多く、キーワード検索だけでは候補を漏らす場合も含みます。
3. 同じ検索を繰り返し、回答に出典を残したい。API仕様やサポート履歴を毎回読み直すより、検索結果を必要な範囲だけ渡すほうが、文脈と確認時間を抑えられます。

逆に、小規模なコードベース、更新頻度の高いソースコード、正確な識別子を探す作業なら、まず標準の検索とCLAUDE.mdで十分です。CLAUDE.mdは検索DBではなく、プロジェクトのルールや前提を毎回伝えるためのファイルなので、文書全文を詰め込まず、参照先と判断基準だけを短く書きます。

Claude CodeにRAGをつなぐ手順

実装を始める前に、検索対象と返す情報を決めます。最小構成なら、次の順番で進めると切り分けやすくなります。

1. 対象文書を決める。社内規程、API仕様、FAQなどを分類し、機密情報や対象外のフォルダを最初に除外する。
2. 索引を作る。見出し単位を基本に文書を分割し、source、ページまたは行、版、更新日時、アクセス範囲を各チャンクに付ける。表やコード例は意味が切れない単位で扱う。
3. 検索サーバーを用意する。質問を受けて上位チャンクと出典を返す読み取り専用のMCPサーバーにし、更新処理と検索処理を分ける。
4. Claude Codeから接続する。公式ドキュメントの形式なら、たとえば次のようにHTTPサーバーを登録できる。

claude mcp add --transport http company-docs https://example.com/mcp

5. 接続を確認する。claude mcp listやセッション内の/mcpで状態を確認し、「認証仕様のタイムアウト値」のような質問で、回答だけでなく出典パスと更新日時が返るかをテストする。

MCPの公式仕様では、外部ツールやデータソースをClaude Codeへ接続し、貼り付けずにデータを参照できると説明されています。実際の社内サーバーでは、認証情報を設定ファイルへ直書きせず環境変数で渡し、プロジェクト単位の許可範囲を設定してください。

出典URL: https://code.claude.com/docs/en/mcp

MCP検索サーバーの設計ポイント

検索ツールの入力は、まずquery、top_k、任意のprojectやversion程度に絞ります。出力には、本文の抜粋だけでなく、文書名、見出し、URLまたはパス、版、更新日時を含めます。Claude Codeがそのまま回答へ引用できるため、利用者は検索結果の正しさを確認しやすくなります。

検索結果を増やしすぎると、RAGを使っても文脈を圧迫します。最初は上位3〜5件に抑え、質問に該当しない低スコアの候補は返さない設計が安全です。ヒットしない場合は、無理に近い文書を返さず「該当なし」と返し、質問を言い換えるか、標準のファイル探索へ切り替えます。

また、外部コンテンツには悪意のある指示が混ざる可能性があります。検索サーバーには読み取り専用の権限を与え、文書内の命令をシステム設定として扱わないこと、接続先を確認してから使うことを運用ルールにします。MCP公式ドキュメントも、外部コンテンツを取得するサーバーには指示の混入リスクがあると注意しています。

出典URL: https://code.claude.com/docs/en/mcp

精度・トークン・速度を確認する方法

導入効果は「回答が賢くなった」という感想だけで判定せず、同じ質問を複数の方式で比べます。まず、正解となる文書と章が分かる質問を20〜30件用意し、次の順番で記録します。

1. Claude Code標準の探索だけで回答し、参照したファイル、所要時間、読み込んだ量を残す。
2. RAGだけで回答し、上位何件に正解チャンクが入ったか、出典が回答に残ったかを確認する。
3. 標準探索とRAGを併用し、RAGの出典から実ファイルや最新版の仕様へたどれるかを調べる。

評価では、正解文書が上位に入る割合、根拠のない記述の割合、回答までの時間、文脈に入ったトークン量を見ます。Zennの無料RAG実例には大きな削減効果が報告されていますが、これは特定の構成での測定値です。文書の分割方法、埋め込みモデル、質問の種類で結果は変わるため、自分のデータで測ることが重要です。

実例URL: https://zenn.dev/abalol/articles/claude-code-rag

Claude ProjectsのRAGとClaude Codeは別物

Claude ProjectsにもRAG機能があります。公式ヘルプによれば、プロジェクトへ資料を追加すると、内容がコンテキストの上限に近づいたとき自動でプロジェクト知識の検索が使われ、追加設定なしでより多くの資料を扱えます。これはアップロードした知識へ質問する用途に便利です。

ただし、ProjectsのRAGは、ローカルリポジトリの変更、テスト実行、Git操作を中心にしたClaude Codeの開発フローとは役割が違います。資料を読むだけならProjects、コードと資料を行き来して実装するならClaude CodeにMCP検索を接続する、という分け方が分かりやすいでしょう。

出典URL: https://support.claude.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projects

まとめ

rag claude codeの答えは、すべての開発環境にベクトルDBを追加することではありません。コードの調査は標準のファイル探索を優先し、社内文書やAPI仕様の横断検索が必要になった段階で、出典付きのRAGをMCP経由で足します。最後に、Claude Codeがファイルを必要な範囲で読む仕組みは公式の初日ガイドでも確認できます。

固定型RAGと探索型検索を同じものとして扱わず、検索対象、更新頻度、出典の要否、運用コストで選べば、過剰な構成を避けながら回答の再現性を高められます。