最先端AIを技術の中身まで読み解く「AIウォッチ」の連載記事です（RAG 全10回・第4回）。初出は本サイトです。全10回の一覧もそちらに。 → https://aiwatch-jp.pages.dev/rag-overview-04
前回までで、検索ツールを見てきました。
BM25。
ベクトル検索。
RRF。
grep。
reranker。
どれも欠かせません。
ただ、RAG の問題は、検索器を選べば終わるわけではありません。
本当に難しいのは、次の問いです。
この情報で、もう答えてよいのか。
まだ足りないのか。
足りないなら、次に何を探すべきなのか。
ここに Agentic RAG の入口があります。
Agentic RAG は、「RAG に Agent を付ける」という名前だけを見ると、少し派手に聞こえます。
多くの agent が役割分担し、query を書き換え、複数のデータソースを探し、最後に答えをまとめる。
もちろん、それも一つの形です。
でも本質は、もっと地味です。
一回検索して答えるのではなく、足りなければ調べ直す。
そして、答える前に「情報は十分か」を見る。
第4回では、Agentic RAG をこの視点から整理します。
単発 RAG が苦しくなる場面
普通の RAG は、だいたいこう動きます。
質問を受ける
検索する
上位の文書を取る
LLM に渡す
答える
この形は、単純な質問にはよく効きます。
「この仕様書で API の認証方式は何か」
「この議事録で決まった次回の締切はいつか」
「このエラーコードの説明はどこにあるか」
必要な情報が一つの文書、あるいは少数の文書にまとまっているなら、単発 RAG で十分なことが多いです。
しかし、現実の質問はすぐに複雑になります。
たとえば、企業の中でこう聞かれたとします。
「Project X の本番サーバーのスペックは、今の負荷に足りていますか」
この質問に答えるには、一つの文書だけでは足りません。
Project X の設計資料に、サーバー ID がある。
インフラ台帳に、そのサーバーの CPU とメモリがある。
監視ダッシュボードに、最近の負荷がある。
障害報告に、過去のボトルネックがある。
運用ルールに、許容ラインがある。
最初の検索で Project X の資料だけ拾っても、答えは出ません。
そこにはサーバー ID しか書いていないかもしれないからです。
単発 RAG は、ここで止まりがちです。
関連文書は見つかった。
でも、答えに必要な情報はまだ足りない。
それなのに、モデルがその断片だけを見て答えてしまう。
これが危ない。
見つけたことと、答えられることは違います。
「見つかった」ではなく「足りているか」
Agentic RAG の中心は、検索回数を増やすことではありません。
大事なのは、検索結果を見たあとに、もう一つ判断を挟むことです。
この根拠で答えられるか？
答えられるなら、生成に進む。
足りないなら、何が足りないかを言語化し、次の検索に戻す。
この「何が足りないかの判断」が入るだけで、RAG は別物になります。
たとえば、最初の検索で Project X の設計資料が見つかったとします。
そこには、server-prod-17 という ID だけが書いてある。
普通の RAG は、その資料を根拠に答えようとするかもしれません。
Agentic RAG では、ここで止まります。
今ある情報：
Project X の本番サーバー ID は server-prod-17
足りない情報：
server-prod-17 の CPU / メモリ
最近の負荷
許容ライン
過去の障害履歴
次に探すべきもの：
インフラ台帳で server-prod-17 を検索する
監視データで直近 30 日の負荷を見る
障害報告で server-prod-17 を探す
このように、検索結果をそのまま答えに使うのではなく、次の調査計画に変える。
これが Agentic RAG の強さです。
Google の Agentic RAG が示したこと
この方向を分かりやすく示しているのが、Google Research と Google Cloud が 2026年6月5日に公開した Gemini Enterprise Agent Platform の Agentic RAG です。
重要なのは、名前に Agent が入っていることではありません。
核心は、Sufficient Context Agent という役割です。
日本語で言えば、「この文脈で十分か」を見る検査役です。
この仕組みでは、検索した断片をそのまま合成に回しません。
まず、検索結果と中間生成物を見て、答えるための情報が足りているかを確認します。
足りていれば、最終回答に進む。
足りなければ、どの情報が欠けているかを明確にして、次の検索に戻します。
この設計は単純ですが、実務上かなり効きます。
RAG の失敗には、2 種類あります。
1 つは、何も見つからない失敗です。
もう 1 つは、少し見つかったせいで、足りないまま答えてしまう失敗です。
後者のほうが危ないことがあります。
なぜなら、モデルは「それっぽい根拠」を持っているからです。
完全に空なら「分かりません」と言えるかもしれない。
でも半分だけ根拠があると、残りを推測で埋めてしまうことがあります。
Sufficient Context Agent の価値は、ここにあります。
それは答えを作る agent ではありません。
答えてよいかを止める agent です。
多 agent より、役割分離が大事
Google の例では、複数の役割が出てきます。
全体を編成する役割。
情報の経路を考える役割。
query を書き換える役割。
複数の検索を並列に投げる役割。
文脈が十分かを見る役割。
最後に答えを合成する役割。
こう書くと、かなり大がかりに思えます。
でも、個人や小さなプロジェクトで最初から全部を作る必要はありません。
大事なのは、agent の数ではなく、役割を混ぜないことです。
検索する役割。
読む役割。
不足を見る役割。
答える役割。
この 4 つを頭の中で分けるだけでも、設計は変わります。
たとえば、普通の RAG では、検索結果が LLM に渡され、そのまま答えが生成されます。
Agentic RAG では、答える前に次のようなチェックを入れます。
質問に含まれる条件はすべて確認したか
必要な数値、日付、固有名詞は原文で確認したか
複数の情報源が必要な質問なら、その両方を見たか
検索結果に矛盾はないか
足りない場合、次に何を探すべきか
これを別 agent にしてもよい。
同じモデルに別ステップとしてやらせてもよい。
ルールベースのチェックを混ぜてもよい。
実装形態はさまざまです。
本質は、生成の前に「検収」を置くことです。
query rewrite は目的ではない
Agentic RAG の説明では、query rewrite がよく出てきます。
ユーザーの質問を分解する。
検索しやすい形に変える。
複数の query に分ける。
別の言い方で探し直す。
ここが要点です。
ただし、query rewrite そのものが目的ではありません。
目的は、足りない情報に届くことです。
最初の検索で、答えに必要な情報が一部しか見つからなかった。
そのとき、何が足りないかを見て、次の query を作る。
ここが要点です。
たとえば、質問がこうだったとします。
この契約は、途中解約した場合の返金条件を満たしていますか。
最初に契約書の「解約」条項が見つかった。
でも、返金条件には「利用開始日」「最低利用期間」「通知期限」「例外条項」が関わっている。
このとき、次に探すべき query は、ただの 解約 ではありません。
返金
最低利用期間
通知期限
例外
利用開始日
さらに、契約書だけでなく、申込書や請求履歴も見る必要があるかもしれません。
query rewrite は、この不足から生まれるべきです。
最初から派手に query を増やすことではありません。
いつ Agentic RAG が必要か
では、どんなときに Agentic RAG が必要になるのか。
大きく 4 つあります。
1 つ目は、マルチホップ質問です。
一つの文書に答えがない。
文書 A で ID を見つけ、文書 B で仕様を見つけ、文書 C で現在値を確認する。
こういう質問です。
2 つ目は、多ソース質問です。
情報が複数のシステムに分かれている。
社内 wiki、チケット、ログ、DB、スプレッドシート、メール。
どこを見るべきかから判断しなければならない。
3 つ目は、足りない情報を見極める必要がある質問です。
法律、医療、金融、セキュリティ、インフラ運用のように、条件の抜けが危ない領域です。
一つの根拠だけで答えると、事故になります。
4 つ目は、答えの根拠を後から追いたい場面です。
なぜその結論になったのか。
どの文書を見たのか。
どの情報は見つからなかったのか。
どこで追加検索したのか。
こうした trace が必要な場面では、単発 RAG より Agentic RAG のほうが設計しやすいです。
いつ普通の RAG でよいか
逆に、Agentic RAG がいらない場面もあります。
質問が単純で、答えが一つの文書にある。
検索対象が小さい。
遅延を増やしたくない。
コストを抑えたい。
答えの失敗コストが低い。
ユーザーが検索結果を見ながら自分で判断できる。
この場合は、普通の RAG で十分です。
Agentic RAG は、検索を増やします。
LLM 呼び出しも増えます。
実装も複雑になります。
失敗の種類も増えます。
たとえば、Sufficient Context Agent が過度に慎重すぎると、いつまでも検索を続けます。
逆に甘すぎると、結局足りないまま答えます。
Planner が間違ったデータソースを選ぶと、検索の回数だけ無駄が増えます。
query rewrite が広がりすぎると、ノイズも増えます。
だから、Agentic RAG は「高度だから入れる」ものではありません。
単発 RAG では足りない理由があるときに入れるものです。
最小構成で考える
実装を考えるなら、最初から複雑な multi-agent 構成にしなくてもよいです。
最小構成は、次の 3 ステップで十分です。
1. retrieve
2. check sufficiency
3. answer or search again
まず検索する。
次に、今の根拠で答えられるかを見る。
足りなければ、不足しているものを明示してもう一度検索する。
十分なら答える。
このとき、check sufficiency の出力は、できるだけ構造化したほうがよいです。
status: sufficient / insufficient
known_facts:
missing_facts:
next_queries:
risk:
これだけでも、RAG はかなり扱いやすくなります。
重要なのは、「足りない」と言うだけでは不十分なことです。
何が不足しているのか。
なぜそれが必要なのか。
次に何を探すべきなのか。
ここまで出さないと、次の検索につながりません。
Agentic RAG の失敗モード
Agentic RAG には、独自の失敗もあります。
まず、検索しすぎる問題です。
情報が不足していると判断するたびに検索を増やすと、コストと遅延が膨らみます。
しかも、検索を増やせば正しくなるとは限りません。
ノイズも増えるからです。
次に、問いを広げすぎる問題です。
query rewrite がうまく見えても、広げすぎると別の話題を拾います。
最初の質問から離れた資料が混ざり、モデルがそちらに引っ張られます。
三つ目は、検査役の過信です。
Sufficient Context Agent も LLM です。
足りているかどうかの判断を間違えることがあります。
だから、重要な領域では、チェックの基準や評価データが必要です。
四つ目は、trace が残らない問題です。
Agentic RAG は複数ステップになります。
どの query を投げたか。
どの文書を見たか。
どこで十分と判断したか。
どの情報は見つからなかったか。
これを残さないと、後から検証できません。
Agentic RAG は、RAG を賢くする仕組みであると同時に、運用対象でもあります。
入れたら終わりではなく、評価し、ログを見て、失敗を回収する必要があります。
RAG は検索から調査に変わる
ここまでを一言で言うと、Agentic RAG は RAG を「検索」から「調査」に変えます。
検索は、候補を取ってくることです。
調査は、答えに必要な材料がそろうまで、問いを分解し、資料を確認し、不足があれば戻ることです。
この違いは大きいです。
検索器を強くするだけでは、調査にはなりません。
調査には、進め方があります。
止め方があります。
根拠の見方があります。
不足を認める判断があります。
Agentic RAG が目指しているのは、ここです。
だから、第1回で書いたように、RAG は「検索して答える仕組み」ではなくなりつつあります。
どの情報を、どの順番で、どこまで見て、いつ止めるかを決める仕組みになっています。
第4回の結論は、こうです。
Agentic RAG の価値は、agent の数ではありません。
答える前に、情報が十分かを判断できることです。
次回は、この「どこを見に行くか」をさらに別の角度から見ます。
PageIndex です。
長い文書を平たい chunk の集まりとして扱うのではなく、上から順にたどれる地図として扱う考え方を見ていきます。
―― AI未来編集室「AIウォッチ」