RAGとagentic searchの違いと選び方を解説

RAG と agentic search は、どちらも AI に自社のデータを参照させるための手段です。ところが両者を比べる議論はしばしばかみ合いません。原因のひとつは、agentic という同じ語が、ベクトル検索を捨てる構成と、ベクトル検索を賢く回す構成の両方に使われていることにあります。この記事では公式ドキュメントをもとに用語を整理したうえで、それぞれのメリットとデメリット、選定の判断軸を解説します。

RAGとagentic searchの違いはどこにあるのか

先に結論を書きます。両者の分かれ目は「検索用のインデックスを事前に作るかどうか」です。

RAG は、文書を細かく分割して埋め込みベクトルに変換し、ベクトルデータベースに格納しておきます。質問が来たら質問側もベクトル化し、意味的に近いチャンクを取り出してプロンプトに添えます。準備は重いぶん、問い合わせ1回あたりの動作は軽くて速くなります。

agentic search は、この事前準備を持ちません。エージェントが質問を受けてから検索語を自分で組み立て、その場で探し、足りなければ条件を変えてもう一度探します。準備が要らないぶん、1回の応答のなかで何度も検索が走ります。

ここまでは素直な対比です。話がややこしくなるのは、ベンダーによって agentic という語が指す中身が違うためです。

用語の整理：agentic search と agentic RAG の違い

同じ「エージェントが検索する」という説明でも、公式ドキュメントを読み比べると設計思想が分かれます。主要な使われ方を並べます。

Microsoft のエージェント取得の概要は、この機能が「RAG パターンおよびエージェント間ワークフロー向けに設計されたマルチクエリパイプライン」だと明記しています。既存のベクトル検索インデックスを前提に、その上へ LLM のクエリ分解を載せる構成です。Google の Agent Search も、既存の検索データストアの上でエージェントが順に検索を計画します。どちらもベクトル検索を捨ててはいません。

一方 Anthropic は、Claude Agent SDK のブログで agentic search をセマンティック検索の対概念として説明しています。チャンク化して埋め込み、ベクトルを問い合わせるやり方を semantic search と呼び、それとは別のものとして agentic search を置いています。

つまり 「RAG か agentic search か」という問いは、そのままでは答えられません。 検討しているのがベクトル検索を捨てる話なのか、ベクトル検索を賢く回す話なのかを先に確かめる必要があります。前者なら本記事の後半で扱う制約がそのまま課題になりますし、後者なら実質は RAG の発展形なので、比べるべき相手は素朴な単発検索の RAG になります。

RAGの仕組みと、得意なこと・苦手なこと

ここからは、インデックスを作る側の構成を見ていきます。呼び方はベンダーによって揺れますが、動作は共通しています。

仕組み：チャンク分割から生成まで

Anthropic が標準的なパイプラインとして整理している手順は5段階です。知識ベースを小さなテキストチャンクに分割し、埋め込みベクトルへ変換し、検索可能なベクトルデータベースへ格納します。実行時には意味的類似度で上位チャンクを取り出し、プロンプトに添えて生成します。AWS の Amazon Bedrock Knowledge Bases も同じ構造をマネージドで提供しており、前処理でチャンク化・埋め込み・インデックス書き込みを行い、元文書へのマッピングを維持すると説明しています。

この形式の出発点は2020年の論文です。Lewis らは RAG を「事前学習済みのパラメトリックメモリと非パラメトリックメモリを組み合わせた生成モデル」と定義し、非パラメトリックメモリとして「ニューラル検索器でアクセスする Wikipedia の密ベクトルインデックス」を挙げました。論文が動機に挙げたのは、知識の更新のしやすさと、判断の出所を示せることです。

得意なこと：レイテンシとコストが読める

事前に計算を済ませてあるため、問い合わせ時の処理は軽くなります。Microsoft は自社ドキュメントで「エージェント取得は単一クエリパイプラインと比べてレイテンシが増える」と明記しており、Anthropic も「セマンティック検索は通常 agentic search より速い」と書いています。低レイテンシが要件なら、インデックス型が有利だと両社の公式記述が支えています。

コストの見積もりやすさも実務では差になります。Microsoft の比較表によれば、従来の単一クエリパイプラインはクエリ単位の一律コストである一方、エージェント取得はトークン単位の可変コストになり、見積もりの立て方そのものが変わります。

出所を示しやすい点も、監査が必要な業務では重要になります。どのチャンクを根拠に答えたかが1回の検索結果として残るため、追跡が単純です。

苦手なこと：チャンクの文脈欠落と鮮度

弱点として公式が挙げているのが、チャンク分割による文脈の欠落です。Anthropic は「個々のチャンクには十分な文脈が欠けている」と述べ、企業名も期間も書かれていない売上成長率の断片を例に挙げています。

対策も同社が示しています。各チャンクの前に50〜100トークンの説明文脈を足してから埋め込む手法で、検索失敗率が単体で35%（5.7%から3.7%）、BM25 と組み合わせて49%、再ランクを加えて67%削減したと報告されています。ここで測られているのは検索の失敗率であって回答精度ではないので、読み替えないよう注意してください。コストはプロンプトキャッシュを使って文書100万トークンあたり1.02ドルとされています。

埋め込みモデルがドメインに合うかどうかも設計時の論点です。2021年のゼロショット評価 BEIR は、BM25 が頑健なベースラインであり、密検索モデルは計算効率に優れる一方で汎化の面に改善余地があると報告しました。2021年時点の結果なので現在のモデルにそのまま当てはまるとは言えませんが、ドメイン外での汎化が論点として提起されていることは押さえておく価値があります。

そしてインデックスは作った瞬間から古くなります。Anthropic は Claude Code の設計を説明するなかで、実行時探索が「インデックスの陳腐化と複雑な構文木の問題を回避する」と述べています。裏を返せば、インデックス型では陳腐化が構造的な課題だと同社も認識しているということです。

agentic searchの仕組みと、得意なこと・苦手なこと

インデックスを持たない側の構成を見ます。ここでは Anthropic の用法、つまりベクトル検索を使わない形を扱います。

仕組み：インデックスを持たず実行時に探す

Anthropic のコンテキストエンジニアリングの解説は、Claude Code の動きをこう説明しています。CLAUDE.md はあらかじめコンテキストへ読み込む一方、glob や grep といったプリミティブで環境を辿り、必要になった時点でファイルを取得する。この方式を同社は just-in-time と呼び、「関連データを事前処理せず、ファイルパスや保存済みクエリのような軽い識別子だけを保持し、実行時にツールで動的に読み込む」と定義しています。

実装レベルでも裏が取れます。Claude Code のツールリファレンスによると、Grep は ripgrep を基盤にしており、.gitignore を尊重します。Glob は結果を更新時刻順に並べ、100件で打ち切ります。このツール一覧に、埋め込みやベクトルインデックスを使う検索ツールは存在しません。

得意なこと：多段の問いと表記ゆれに強い

一度の検索で答えが出ない問いに向きます。Microsoft が適用例として挙げているのは、複数の条件を含む質問、会話の前の文脈に依存する質問、言い換えや同義語で網羅性が上がるクエリ、そして綴り間違いです。条件を分解して個別に探し、結果を統合する動きが利点になります。

インデックスの更新を待たなくてよい点も利点です。データが変わればその場で読みに行くため、鮮度のずれが構造的に生じません。

苦手なこと：レイテンシ・コスト・再現性

Anthropic は同じ記事でトレードオフを認めています。「実行時の探索は、事前計算済みのデータを取得するより遅い」。この一文が示すとおり、応答時間は伸びます。

トークン消費も増えます。同社のマルチエージェント研究システムの記事には、エージェントはチャット利用の約4倍、マルチエージェント構成では約15倍のトークンを使うという記述があります。ここで比較されているのはチャット利用であって RAG ではないので、そのまま置き換えないでください。

再現性の問題もあります。同記事は「エージェントは動的に判断するため、同じプロンプトでも実行ごとに結果が決定的にならない。デバッグが難しくなる」と述べ、「エージェントは状態を持ち、エラーが累積する」とも書いています。エージェント構築の指針では、まず最も単純な解を探し、必要になったときだけ複雑さを足すこと、多くのアプリケーションでは検索と例示を使って単一の呼び出しを最適化すれば足りることを勧めています。

もうひとつ、対象データの形が前提条件になります。glob と grep で探すということは、grep で拾える形に整理されたデータでなければ機能しないということです。スキャンした PDF や画像、構造化されていないダンプは、そのままでは対象になりません。

「Claude CodeがRAGを捨てた」は本当か

このテーマを検索すると「Claude Code は RAG を捨てた」という記事が数多く出てきます。実際に Google の関連する質問にも同趣旨の問いが並びます。一次情報にあたると、答えは「捨ててはいない」になります。事実の確度を3段階に分けて整理します。

公式に確認できるのは、Claude Code がコードベースを事前インデックスせず、ripgrep ベースの Grep と Glob で実行時に探索することまでです。ここは前章で引いたとおり、公式ドキュメントに記述があります。

一方で「RAG を試したうえでやめた」という経緯は、Anthropic の公式ドキュメントには見当たりません。この話の出所はエンジニア個人の発言とインタビュー記事で、初出の時期も二次記事によって食い違っています。経緯として語るなら、公式の記述とは分けて扱うのが正確です。

そして「捨てた」というフレーミング自体が、公式の立場と合っていません。根拠は3つあります。第一に、Anthropic 自身が Contextual Retrieval という RAG の精度改善手法を公開しています。第二に、同社の推奨は併用です。Claude Agent SDK のブログは「まず agentic search から始め、より速い結果や多くのバリエーションが必要な場合にのみセマンティック検索を足すことを勧める」と書き、あわせて「セマンティック検索のほうが通常は速い」とも述べています。

第三に、Claude Code の公式ドキュメントが RAG インデックスとの併用を明示的に勧めています。大規模コードベース向けのガイドには、組織がすでにコード検索や RAG インデックスをリポジトリに対して運用しているなら、それを MCP ツールとして公開し、ファイルを直接読ませる代わりに Claude から問い合わせさせる、という趣旨の記述があります。同じページには、大規模なコードベースではシンボルの定義や参照を探すのに多数のファイル読み込みと grep 呼び出しがかかるため、言語サーバー連携で直接ジャンプさせるという推奨もあります。grep 一本で押し切るとコストがかかる場面があることを、公式が認めている記述でもあります。なお、ここで出てくる MCP がどういう仕組みなのかはMCPとは？AIと外部ツールをつなぐ標準規格で解説しています。

検索そのものが要らなくなる境界：20万トークンという閾値

選定に入る前に確認しておきたい前提があります。そもそも検索の仕組みが要るのか、という点です。

Anthropic は Contextual Retrieval の記事で、明確な閾値を示しています。知識ベースが20万トークン（およそ500ページ分）より小さいなら、知識ベース全体をそのままプロンプトに含めればよい、という記述です。検索基盤の設計に入る前に、対象データの総量を測っておくと、作らなくてよいものを作らずに済みます。

コンテキストウィンドウは実際に広がっています。2026年9月時点の公表値では、Claude Fable 5.1・Opus 5・Sonnet 5 がいずれも入力100万トークン、GPT-5.5 が105万トークン、Gemini 3.1 Pro Preview が約104.8万トークンです。20万トークンという閾値の5倍前後にあたります。

ただしここから「コンテキストが広いのだから検索は不要だ」と飛躍させないでください。Anthropic が言っているのは20万トークン未満という規模条件つきの話で、それ以上の規模で検索が不要になるとは述べていません。全量を毎回入れれば、そのぶん入力トークンの課金と処理時間がかかります。判断材料の考え方はコンテキストエンジニアリングの記事でも整理しています。

権限・鮮度・監査：エンタープライズで差が出る3つの論点

社内データを扱う場合、精度やレイテンシより先に詰まるのがこの3点です。公開情報だけを扱う検証では表に出てきませんが、実際の導入では設計コストの大半がここに乗ります。

権限：検索サービスは利用者を認証しない

インデックス型を選ぶとき、最初に確認すべきなのが権限の扱いです。Microsoft は文書レベルのアクセス制御に関するドキュメントで、4つの方式を示しています。文字列比較によるセキュリティフィルタ、POSIX 風の ACL と RBAC スコープ、Microsoft Purview の秘密度ラベル、そして SharePoint の ACL です。このうち一般提供されているのはセキュリティフィルタのみで、残る3方式はプレビュー段階にあります（2026年8月時点のドキュメント）。

以前のバージョンのドキュメントには、より直截な記述があります。Azure AI Search は利用者の識別情報を認証せず、どのコンテンツを閲覧する権限があるかを判定するロジックも提供しない、というものです。つまりセキュリティフィールドの設計、グループ ID のインデックス投入、クエリ時のフィルタ生成は、実装側の仕事になります。

公平のために付け加えると、同じドキュメントはネイティブのアクセス制御の利点も挙げています。入れ子になったグループの解決や多階層の ACL 走査を自前で書かずに済むこと、そして検索後にトリミングするより高速であることです。作り込みを減らす方向の選択肢は用意されています。

agentic search 側は、探索先のシステムがもともと持っている権限をそのまま使える場合があります。gaipack の gaibot では、外部 SaaS へのアクセスを利用者ごとの OAuth 認可で行い、利用者本人の権限を超えない形にしています。

鮮度：権限変更が反映されるまで遅れがある

権限は一度決めて終わりではありません。異動や退職でグループのメンバーシップが変わります。Microsoft のドキュメントは、ソース側の権限変更が検索結果に反映されるのは、インデクサの後続実行や push API の更新といった同期の仕組みを経てからだと明記しています。冒頭の注記にも、アクセス制限のあるコンテンツを扱う場合に変更の認識までタイムラグが生じるとあります。

権限を落とした利用者に、同期が終わるまでの間だけ古い権限で検索結果が返る可能性がある、ということです。この窓をどこまで許容できるかは、扱うデータの機密度で決まります。実行時に元システムを直接引く構成なら、この窓は原理的に生じません。

監査：非決定性と実行ログ

agentic search は同じ質問でも毎回同じ経路を辿るとは限りません。回答の根拠を後から再現する必要がある業務では、この性質が制約になります。

ただし「agentic だから監査できない」わけではありません。Microsoft のエージェント取得は、統合された内容とあわせてソース参照とアクティビティログを返せると公式に説明しています。何を検索し、どの結果を採ったかを記録する手当ては用意されています。設計段階でログの保持方針を決めておけば、追跡は成り立ちます。

RAGとagentic searchの違いを踏まえた選定の判断軸

ここまでの材料を、判断の順序に並べ替えます。

条件ごとの向き不向きを表にします。優劣ではなく、前提の違いとして読んでください。

gaipack 自身も、この判断を一度やり直しています。社内ナレッジ基盤の gaibot は、当初 Amazon Bedrock Knowledge Bases と検索インデックスを組み合わせた集約型の構成で作っていました。現在は集約インデックスを持たず、実行時探索と MCP 連携を中核とする構成へ切り替えています。検索して答えるだけでなく、GitHub の Issue 起票のような操作まで同じ経路で実行したかったことが、切り替えの理由のひとつです。ベクトルストア型の仕組みも、必要に応じて併用する前提は残しています。実際の運用と成果は社内ナレッジ基盤の事例で紹介しています。

業界固有の用語や文脈にあわせた作り込みが必要な場合は、上位サービスの gaibot Pro で、データソースの選定からリランクやコンテキスト設計の最適化までを扱っています。

RAGとagentic searchの違いに関するよくある質問

選定の相談で判断が割れやすい点を、一次情報で確認できる範囲にしぼって整理します。

Agentic Search とは何ですか

エージェントが実行時に検索語を組み立て、結果を見て必要なら再検索する検索の進め方です。Anthropic の用法では、チャンク化と埋め込みを使うセマンティック検索の対概念として、インデックスを持たずファイルシステムを直接探索する方式を指します。ベンダーによっては、ベクトル検索インデックスの上でエージェントが複数回検索する構成を同種の名前で呼んでいます。

Agentic Search と RAG の違いは何ですか

検索用のインデックスを事前に作るかどうかが分かれ目です。RAG は文書を分割・埋め込みしてベクトルデータベースに入れておき、質問時に類似検索します。agentic search はその準備を持たず、質問を受けてから探します。前者は応答が速くコストが読みやすく、後者は多段の問いに強く鮮度のずれが生じにくい、という違いになります。

エージェント型 RAG（Agentic RAG）とは何ですか

RAG のパイプラインに、LLM が全体の進行を判断する層を載せた構成を指す呼び方です。主要ベンダーの製品ドキュメントに正式な定義は見当たらず、学術・業界用語として使われています。多くの場合ベクトル検索を使う前提で語られるため、インデックスを捨てる方向の agentic search とは別の概念です。

なぜ Claude Code は RAG を捨てたのですか

公式ドキュメントの記述に沿うと「捨てていない」が答えになります。Claude Code がコードベースを事前インデックスせず ripgrep ベースの検索で探索することは事実ですが、Anthropic は RAG の精度改善手法も公開しており、公式の推奨は agentic search から始めて必要ならセマンティック検索を足す併用です。Claude Code のドキュメント自体、既存の RAG インデックスがあれば MCP ツールとして公開して併用するよう勧めています。

RAG にはどんな種類がありますか

ベクトル検索を使う素朴な構成のほか、キーワード検索を組み合わせるハイブリッド検索、チャンクに文脈を補って埋め込む手法、検索結果を再ランクする構成、グラフ構造を使う構成などがあります。LLM がクエリを分解して複数回検索する構成も、インデックスを前提にする限りは RAG の発展形にあたります。

まとめ

RAG と agentic search の分かれ目は、検索用のインデックスを事前に作るかどうかにあります。インデックス型は応答が速くコストが読みやすく、根拠の追跡も単純です。実行時探索は多段の問いに強く鮮度のずれが生じにくい一方、レイテンシとトークン消費が増え、結果が毎回同じにはなりません。

選定に入る前に確かめたいことが2つあります。ひとつは対象データの総量で、20万トークンに満たないなら検索基盤を作らない選択肢が先にあります。もうひとつは用語の確認で、検討している agentic search がベクトル検索を捨てる話なのか、ベクトル検索を賢く回す話なのかで、比較すべき相手が変わります。

そして社内データを扱うなら、精度より先に権限・鮮度・監査の3点を詰めてください。設計コストの大半はここに乗ります。gaipack では、こうした検索基盤の選定から実装・運用までを gaibot として提供しています。開発プロセス全体への AI の組み込みはAI駆動開発の記事で扱っていますので、あわせてご覧ください。ご相談はお気軽にお寄せください。