Agentic RAG(エージェンティックRAG)とは｜1回検索で終わる従来RAGを、計画・再検索・自己反省で賢くする

RAGを本番で運用していると、単純なFAQ的質問はうまく答えるのに、「AとBを比べてどちらが条件を満たすか」といった多段の問いで急に精度が落ちる場面に出会います。多くの場合、原因は検索器そのものより「1回検索して、その結果でそのまま答える」という固定パイプラインの設計にあります。Agentic RAG(エージェンティックRAG)は、この検索の制御をエージェントに委ね、必要に応じて計画・再検索・自己反省を挟むことで、従来RAGが苦手だった問いに対処しようという枠組みです。この記事では、従来RAGの限界を出発点にAgentic RAGを定義し、中核となるパターンと、精度と引き換えに増えるコスト・レイテンシ・評価の難しさまでを、実務で判断できる粒度で整理します。

従来RAGはどこで詰まるのか#

まず従来のRAG(素朴なRAG)の形を確認します。質問が来たら検索器で関連文書を1回引き(retrieve)、その結果をコンテキストに載せてLLMに答えさせる(generate)。この一本道は、答えが単一の文書片に書かれている単純な質問には十分に機能します。実装も軽く、レイテンシも読みやすい。

つまずくのは、質問が一段の検索で閉じないときです。代表例が次の3つです。

• 多段(multi-hop)の質問: 「Xの後任が最初に担当した案件の予算は」のように、いくつかの事実を順にたどらないと答えに届かない問い。最初の1回では途中の事実しか引けません。
• 曖昧・複合のクエリ: 質問に複数の意図が混ざっていたり、言葉足らずだったりして、そのままでは検索語として弱いケース。
• 単一検索での取りこぼし: 1つの検索器・1つの言い回しだけでは、必要な文書がそもそも候補に入らないケース。

Weaviateの解説でも、Agentic RAGは、単発の検索と固定パイプラインでは扱いきれないこうした状況に応えるものだと位置づけられています。従来RAGの精度改善は、埋め込みの差し替え・チャンク分割の見直し・リランキングといった「検索の質」を上げる方向が中心ですが、それらは1回検索という構造自体は変えません。

Agentic RAGの定義#

Agentic RAGは、この検索の流れにエージェント(自律的にツールを使い、次の行動を判断するLLM)を組み込み、検索そのものを制御対象にする枠組みです。IBMの解説を借りれば、固定の1回検索を回して結果を渡すのではなく、何を検索すべきか判断し、得た結果が本当に役立つかを自分で確かめ、不十分なら検索し直し、問いに応じて複数のソースから引く、という振る舞いを指します。

Agentic RAGの調査論文(Singhらのサーベイ、arXiv:2501.09136)は、こうしたシステムがリフレクション(自己反省)・計画・ツール利用・複数エージェント協調といったエージェントの設計パターンを取り込み、検索戦略を動的に管理して文脈理解を反復的に洗練させる点を、従来RAGとの違いとして整理しています。ポイントは、検索器を強くするのではなく、検索の使い方を判断する層を上に足すという発想の転換です。

中核となる5つのパターン#

Agentic RAGを構成する振る舞いは、おおむね次の5つに整理できます。実際のシステムはこれらを組み合わせて成り立ちます。

クエリ理解と計画#

来た質問をそのまま検索語にせず、まず何を問われているかを解釈し、解き方の段取りを立てます。複数の意図が混ざっていれば分けて扱い、どのソースをどの順で当たるかの見取り図を作ります。ここがずれると後段が全部ずれるため、計画はAgentic RAGの入り口です。

ルーティング(検索器・戦略の動的選択)#

クエリの性質に応じて、使う検索器・戦略・データソースを動的に選びます。単純な問いは軽い1回検索で済ませ、複雑な問いには多段の反復を割り当てる、といった振り分けです。質問の複雑さを予測して検索戦略を出し分けるAdaptive-RAG(arXiv:2403.14403)は、このルーティングの考え方を示した代表例で、簡単な問いに重い処理をかけない無駄の削減と、難しい問いへの十分な検索の両立を狙います。

多段推論と分解(multi-hop)#

複雑な問いをサブ質問に割り、順に検索しながら答えを組み立てます。推論と検索を交互に回し、これまでに得た事実をもとに次に何を引くかを決める、という反復が多段質問への基本アプローチです。1回では届かない問いを、小さな検索の連鎖でたどります。

検索のオーケストレーション#

そもそも検索が必要かどうかも含めて、いつ・どう検索するかをエージェント自身が決めます。手持ちの知識で足りるなら検索せず、足りなければ検索器やAPIといったツールを呼ぶ。LlamaIndexのドキュメントでも、ルーティングやクエリ分割、ツール利用といったエージェント的な戦略を素朴なRAGに重ねる形が示されています。検索は目的でなく、答えに必要なときに使う道具という扱いになります。

自己反省(self-reflection)#

生成した回答や引いた文書を、エージェント自身が批評します。取得した内容が質問に本当に答えているかを、生成の前に別途チェックし、外れていれば検索し直す。LangGraphのSelf-RAG(自己反省型RAG)のチュートリアルでも、取得文書の関連性や、生成が根拠に裏づけられているか(幻覚でないか)を判定し、必要なら再検索・再生成へ戻すループが実装例として示されています。この「批評して差し戻す」仕組みが、1回検索との最大の違いを生みます。

アーキテクチャの段階#

Agentic RAGは、いきなり複雑にする必要はありません。エージェントの数と役割で段階があります。

もっとも軽いのは単一エージェントのルーター型です。1つのエージェントが複数の検索ツール(ベクトル検索・キーワード検索・特定DBやAPIなど)を持ち、クエリごとにどれを使うかだけを判断します。従来RAGからの最小のアップグレードで、社内ナレッジ検索のような用途ではこれで足りることも多いです。

そこから、自己反省ループを足して再検索を許す構成、さらに役割の異なる複数エージェントが協調して1つの問いを分担する構成へと広がります。複数エージェント型は、専門の異なるソースを横断する調査のような重い問いで力を発揮しますが、状態管理やエージェント間の受け渡し、停止条件の設計など、作り込みと運用の負担も段違いに増えます。

何が良くなり、何が難しくなるのか#

Agentic RAGは、従来RAGが苦手だった多段・横断・条件分岐を含む問いで、精度と網羅を上げられる可能性があります。反面、代償も明確です。

• レイテンシ: 検索と生成を何度も往復するため、1回検索に比べて応答は確実に遅くなります。反復回数が読みにくく、遅延の上振れも起きます。
• コスト: 検索・判定・再生成のたびにLLM呼び出しとトークンが積み上がります。1つの質問に何度も推論を走らせるため、単価は跳ねやすくなります。
• 実装と評価の複雑さ: 分岐・ループ・複数ツールを含むため、動作の追跡やデバッグが難しくなります。どこで間違えたのかの切り分けに手間がかかります。

失敗様式もあります。停止条件が甘いと検索と再生成を延々繰り返すループ暴走、必要のない問いにまで重い多段検索をかける過剰検索、自己反省が誤った批評をして正しい候補を捨てる、といった形です。

評価がとりわけ難しい#

Agentic RAGで見落とされがちなのが、評価の難しさです。従来RAGなら、検索の再現率(正解を候補に拾えたか)と最終回答の正しさを見れば、ある程度切り分けられます。Agentic RAGは経路が動的に変わるため、同じ質問でも通るルートや検索回数が変わり、どの段が効いた・外したのかが見えにくくなります。

現実的には、最終回答の正しさだけでなく、途中のサブ質問の妥当性、各検索が正解を拾えたか、自己反省の判定が当たっていたか、といった中間段も観測できるようにしておくことが要ります。加えて、精度だけを追うと反復が増えてコストとレイテンシが膨らむため、精度・レイテンシ・コストをセットで並べて評価しないと、実運用に耐えるかの判断ができません。

Agentic RAGの用語・分類・実装は、各フレームワークや論文で呼び方や粒度が異なります。この記事の整理はSinghらのサーベイ(arXiv:2501.09136)やベンダー各社の解説に基づく一般化で、特定製品の仕様や優劣を示すものではありません。実装前に利用するフレームワークの公式ドキュメントで現行の挙動を確認してください。

従来RAGで足りる場面・Agentic RAGが効く場面#

導入判断は、問いの性質で切り分けるのが素直です。

従来RAGで足りるのは、答えが単一または少数の文書片に収まる、単純なFAQ的検索です。1回検索で正解を拾えるなら、エージェント性は遅延とコストを増やすだけの過剰装備になりがちです。まずは素朴なRAG(必要ならハイブリッド検索やリランキングで検索の質を底上げした構成)で評価し、どんな質問で落ちるかを見るのが出発点です。

Agentic RAGが効くのは、複数の事実をたどる多段質問、複数ソースを横断する調査、条件分岐や比較を含む問いです。1回検索では構造的に届かない質問群に、計画・再検索・自己反省で対処できる余地があります。ただしその効果は、増えるコストとレイテンシに見合う場合に限られます。

導入の進め方#

よくある質問#

まとめ#

Agentic RAGは、検索器そのものを強くするのではなく、いつ・何を・どう検索するかの判断をエージェントに委ねる、検索を制御する上位の枠組みです。計画・ルーティング・多段推論・オーケストレーション・自己反省という中核パターンによって、従来RAGが1回検索では届かなかった多段・横断の問いに対処できる余地が生まれます。ただしその代償として、レイテンシ・コスト・実装と評価の複雑さは確実に増え、ループ暴走や過剰検索という新しい失敗様式も抱えます。だからこそ、素朴なRAGで落ちる質問を見極め、単一のルーター型から必要な分だけ足し、精度とコストを並べて判断する姿勢が欠かせません。検索の質を支える埋め込み・チャンク分割・ハイブリッド検索・リランキングとあわせて押さえると、RAGのどこを直せば効くのかの見通しが良くなります。