「RAGはエージェントに淘汰される」「RAGは死んだ」といった話を、記事や議論で目にすることがあります。結論から言うと、淘汰されているのは「固定的で単純なRAGパイプライン」であって、RAGそのものではありません。実際の流れは、RAGがエージェントに置き換わるのではなく、RAGがエージェントの中に組み込まれて再編されているという表現がいちばん近いです。
そこで本記事では、従来のRAGとAgentic Search（エージェント型検索） の違いを押さえたうえで、なぜ実務では「安い検索から始めて、足りなければ重い探索に進む」構成が合理的なのかを、IT技術者向けに整理します。大手ベンダーの動向や研究の潮流にも触れつつ、設計の勘どころまで一気に読める形でまとめます。
関連記事： エージェントの任せ方と止め方や社内システムとの組み合わせは、筆者の記事一覧（AIエージェント・RAG・任せる設計など）から参照できます。
まず押さえたい：RAGとAgentic Search、何がどう違う？
「両方を組み合わせる設計が増えている」と聞いても、そもそも何が違うのかがぼんやりしていると、設計判断がしづらいものです。ここでは従来のRAGとAgentic Searchの設計思想の違いをはっきりさせておきましょう。この違いが頭に入ると、後半の「なぜ段階的に乗せるのが合理的か」が自然に腹落ちします。
従来型RAGは「必要だけ渡す」でコストを抑える
RAG（Retrieval-Augmented Generation） は、LLMに答えを生成させる前に、あらかじめ用意した文書群から「必要な部分だけ」を検索して渡す仕組みです。検索は通常、ベクトル検索（意味検索）やキーワード検索で行い、ヒットしたチャンクをプロンプトに載せてLLMに渡します。
設計の狙いは明確です。トークン消費とコストを抑えること。長い文書を丸ごと渡すのではなく、質問に関連しそうな断片だけを絞り込んでコンテキストに載せるため、入力トークン数が抑えられ、応答も比較的速く、遅延とコストが読みやすいという利点があります。OpenAIの公式ガイドでも、RAGは「実行時に外部の関連文脈を付与する技法」として説明され、ベクトルDBだけでなく built-in file search のような形も含めて扱っています（Retrieval Augmented Generation (RAG) and Semantic Search for GPTs | OpenAI Help Center）。長い手続き文書を正確に扱うための構成として、OpenAI Cookbook（File Search） でもRAGが解説されています。
こうした「必要な部分だけ渡す」設計の裏返しとして、検索語や検索の粒度は人間や固定パイプラインが決めることになります。そのため、「聞かれ方」や「文書の構造」に合わせた柔軟な探索は苦手で、質問が複雑だったり1回の検索では答えに届かない場合、精度が頭打ちになりやすい、という限界があります。
Agentic Searchは「AIが何度でも探す」代わりに重くなる
これに対し、Agentic Searchは、AI自身が検索語や探索方針を決め、必要なら何度も検索・ツール実行を繰り返すアプローチです。コードベースを扱う Claude Code が典型例で、事前にリポジトリ全体をベクトル化してインデックスするのではなく、glob や grep などで just-in-time（その場で） に必要なファイルや行を取得する動きをします。Anthropicの説明や Vadim's blog の解説 でも、Claude Code は「事前に全部をインデックス化するのではなく、その場で探索するハイブリッド型」として位置づけられています。
メリットは精度が上がりやすいことです。モデルが「何が足りないか」を判断し、検索語を変えたり、別のツールを呼んだり、何度でも探索できるため、複雑な質問や依存関係の深いコードにも対応しやすくなります。
その代わり、デメリットは遅くなりやすく、コストも読みにくい点にあります。検索→再検索→ツール実行→再計画、という多段階になりがちで、呼び出し回数やトークン数がクエリごとにばらつきます。低遅延・予測可能なコストが求められる業務では、エージェント型だけに寄せると運用が重くなりがちです。
だから「どちらか」ではなく「段階的に重くする」が筋がいい
ここまでを整理すると、こうなります。
- 従来RAG：コストと遅延を抑えやすいが、検索の仕方や粒度が固定的で、複雑な問いには精度が届きにくい。
- Agentic Search：精度は出しやすいが、遅くなりやすく、コストが読みにくい。
どちらか一方に寄せると、どこかで無理が出る。だからこそ、「RAGかエージェントか」の二者択一ではなく、場面に応じて使い分けたり、段階的に重い探索に進んだりする設計が、実務では合理的になってきています。次のセクションでは、その「段階的に乗せる」中身を具体的に見ていきましょう。
実務の正解は「安い検索から始めて、足りなければ重い探索へ」
前のセクションで、RAGとAgentic Searchはトレードオフがあり、どちらか一方に寄せると無理が出る、という話をしました。では実務ではどう設計すればよいか。答えは、まずは軽い・安い検索で試し、足りなければ重い・エージェント型の探索に進む構成です。この考え方は、最近の研究や各社の製品方針とも整合しています。
片方だけに寄せると、どこかで無理が出る
単純なRAGだけに頼ると、複雑な質問や、コードのように頻繁に変わり・依存関係が深い対象では、1回のベクトル検索では答えに届かないことが多いです。逆に、最初からすべてのクエリをエージェント型の多段探索にすると、レイテンシとコストが膨らみ、社内FAQやマニュアル参照のように「決まった文書から素早く答えてほしい」という需要には過剰になります。
そこで有効なのが、クエリの難しさやタスクの性質に応じて、使う検索の「重さ」を変える発想です。最初はキーワード検索やベクトル検索で数チャンクだけ取り、それで十分ならそこで回答する。足りないと判断した場合だけ、エージェントに検索語の再生成や複数回の検索・ツール実行を任せる——こうしたルーティングが、コストと性能の両立に効きます。
この「軽い検索から始め、ダメなら重い探索へ」という考え方は、研究でも裏付けられています。2024年の SELF-ROUTE では、クエリを「RAGで足りるか」「長文コンテキスト（LC）が必要か」で振り分けることで、コストを大きく削減しつつ、長文モデルと同等に近い性能を維持できることが示されました（Self-Route: RAG vs. Long Context の概要）。実務的にも筋がいい、という評価につながっています。
具体的な設計：第一段階と第二段階で何をするか
設計イメージは、次のような二段構えです。
第一段階では、ユーザーの質問をそのまま、または少し正規化して、キーワード検索・ベクトル検索で候補チャンクを取得します。コストと遅延を抑えつつ、多くの単純な質問にはここで回答して終わりにできます。
第二段階は、信頼スコアが低い、または「これだけでは不十分」と判定した場合にだけ動かします。エージェントに検索語の再生成・複数回検索・ツール呼び出しを任せる。コード探索なら glob / grep / read の組み合わせ、文書ならキーワード・文・チャンクなど複数粒度の検索をモデルに選ばせる、という形です。
この「段階的に重くする」発想をさらに進めたのが、2026年に提案されている A-RAG のような Agentic RAG です。モデルに keyword_search / semantic_search / chunk_read といった階層的な検索インターフェースを渡し、モデル自身が「何を・どの粒度で取るか」を決める枠組みが示されています（A-RAG: Scaling Agentic RAG via Hierarchical Retrieval）。「静的パイプラインから動的エージェント型への転換」と位置づけられており、RAGを捨てるのではなく、RAGの再設計という方向性になっています。
大手は「RAG終了」ではなく「RAGをエージェントに載せる」路線
「RAGは終わり、エージェントの時代」という単純な図式は、各社の公式見解とは一致しません。むしろ、RAGをエージェントに載せて進化させる動きがはっきりしています。
OpenAI は、RAGを外部文脈の付与技法として説明し、File Search in the Responses API など実務向けのRAG構成を提供しています。
Google Cloud の Vertex AI Agent Builder では、エージェントに RAG capability を持たせることを前面に出しており、「RAG-capable generative AI application」のアーキテクチャが公開されています。エージェントとRAGは対立概念ではなく、エージェントにRAGを装備させる発想です。
Microsoft はさらに明確で、Azure AI Search の agentic retrieval を、「RAGパターンとエージェント間ワークフロー向け」 だと説明しています。「RAGの次はエージェントだからRAGは終わり」ではなく、RAGをエージェント化する方向で製品を進めている、と読めます。
いずれも、RAGが消えるのではなく、RAGとキーワード検索・全文検索・ツール呼び出し・エージェントによる再探索を組み合わせた Agentic RAG / Agentic Retrieval が、これからの主流になりつつある、という整理と整合しています。この流れを踏まえると、次の疑問——「ではRAGは本当に消えないのか？」——に答えやすくなります。
「RAGが消える」は言い過ぎ——再編されているだけ
「RAGはエージェントに淘汰される」という言い方は、現時点では言い過ぎです。より正確には、「RAGだけでは足りない時代になった」 ということ。固定的で単純なRAGパイプラインが限界を迎え、RAGがエージェントの中に組み込まれて再編されている、という見方が、2026年3月時点では妥当です。研究の世界でも、実務の世界でも、その方向性がはっきりしてきています。
研究も「脱RAG」より「Agentic RAG」の再設計
研究では、RAGを否定するより、RAGをより動的にする方向が目立ちます。SELF-ROUTE は「RAGと長文コンテキストのどちらを使うかをルーティングする」ことでコストと性能を両立させる発想です。A-RAG は、静的RAGでも単純な長文投入でもなく、複数粒度でモデルが検索できる Agentic RAG を提案し、「静的パイプラインから動的エージェント型への転換」と位置づけています。いずれも結論は「RAG終了」ではなく、RAGの再設計です。
つまり、設計者に求められているのは「RAGかエージェントか」の二者択一ではなく、どこでRAGのままにして、どこでエージェントに任せるかの見極めです。その見極めの参考になるのが、次の「RAGのままが合う場面」と「エージェントが合う場面」の整理です。
RAGのままが合う場面、エージェントが合う場面
実務では、RAGのほうが向いている場面がまだ多く残っています。
安定した社内文書・規程集・FAQ・マニュアルでは、更新頻度が高くなく、根拠文書を明示したい場合、RAGのほうが設計しやすく、監査や再現性も取りやすいです。各社が citations 付きRAGやエンタープライズ検索を強化しているのはこのためです。
低遅延・低コストが求められる場面では、エージェント型の多段探索はレイテンシとコストが増えがちなため、固定ルールのRAGが依然として有効です。
ガバナンスが重い業務（法務、医療、金融、教育、行政など）では、「どの情報源を根拠に答えたか」を後から辿れることが重要です。検索対象が明確なRAGは、その点で運用しやすく、OpenAI・Anthropic・Microsoft が citations や grounded response を重視しているのも、この要請に応えるためです。
一方、コード探索や複雑なマルチステップ調査のように、コードベースが頻繁に変わり、依存関係が深く、その場で grep / glob / 実行が必要な環境では、最初から全部をベクトル化するより、AIがその都度ツールで調べるほうが自然です。ここでは「単純RAGよりエージェントが優勢になりやすい」という整理が妥当です。こうした「場面による向き・不向き」を押さえたうえで、最後に設計で押さえる3つのことをまとめます。
まとめ：設計で押さえる3つのこと
ここまで、RAGとAgentic Searchの違い、段階的に乗せる設計の合理性、そして「RAGが消えるのではない」という整理を見てきました。最後に、設計で押さえておきたい3つのことをまとめます。
第一に：「RAG vs エージェント」の二者択一ではない
最新の製品や論文は、RAGとエージェントを組み合わせた構成を推しています。RAGが消えるのではなく、RAGだけでは足りない時代になった、という見方が現時点では妥当です。設計の議論も、「どちらか」ではなく「どう組み合わせるか」から始めると、判断がしやすくなります。
第二に：安い検索から始め、足りなければ重い探索へ
実務では、まず軽い検索（キーワード・ベクトル）で試し、不十分なときだけエージェント型の多段探索に進む設計が合理的です。SELF-ROUTE や A-RAG に代表される「ルーティング」「Agentic RAG」の考え方と一致しており、コストと精度のバランスを取りやすくなります。
第三に：精度の本丸は検索手法だけでなくデータ整形にある
検索方式を変えるだけでなく、文書をAIが読める形に整える前処理（レイアウト付きMarkdown抽出、意味解析など）が依然として重要です。Microsoft も RAG の品質向上のために analyzers で前処理を説明しています。AI Ready なデータをどう用意するかは、RAGでも Agentic RAG でも共通の土台になります。
不安を一言でまとめるなら、「RAGが消える」のではなく、「RAGだけでは足りない時代になった」——ここを押さえたうえで、安い検索から重い探索へ段階的に乗せる設計を選んでおくと、2026年以降の構成変更にも対応しやすくなると思います。
作成日： 2026年3月11日