エージェンティックRAG（Agentic RAG）は、「検索するか」「何を手がかりに検索するか」「集めた根拠で答えてよいか」をLLM自身が判断するRAGです。質問ごとに1回検索して答える基本構成のRAGと違い、エージェンティックRAGでは検索がAIエージェントの道具の1つになり、根拠が足りなければ検索語を変えて引き直します。なお本記事で「従来RAG」と書くときは、この1回検索の基本構成を指します（RAG全体には検索の反復や検証を組み込む構成もあります）。
この記事では、混同されやすい「RAG」と「AIエージェント」の違いと関係を先に整理し、そのうえで両者を組み合わせたエージェンティックRAGの仕組み、関連する研究手法、採用を見送るべき条件と導入時の失敗パターンを説明します。
まとめ：エージェンティックRAGの要点
- RAGとAIエージェントは比較対象ではなく層が違う：RAGは「検索結果をプロンプトに足して生成する」手法、AIエージェントは「次の行動をLLMが決める」システム。RAGはエージェントが使う道具の1つになれる。
- エージェンティックRAGの中身は判断ループ：検索→根拠の採点→足りなければ検索語の書き換え→再検索、を上限付きで回す。
- 関連する研究：Self-RAG（検索の要否と根拠の妥当性をモデルが判定）、CRAG（検索結果を評価して不足ならWeb検索へ）、Adaptive-RAG（質問の複雑さで戦略を切り替え）。
- 反復や分業はトークン消費を増やしやすい：通常チャットを比較対象にしたAnthropicの自社データでは、エージェントは通常のチャットの約4倍、マルチエージェントは約15倍のトークンを使う。
- 1回の検索で答えが出る質問には不要：FAQ型・単一文書の参照なら従来RAGの改善（分割・再ランク）を先にやる。
- 反復ループには終了条件が必要：書き換えの回数上限と、上限に達したときの返し方を最初に決める。
RAGとAIエージェントの違い：手法とシステムの役割
「RAGとAIエージェントはどちらを選ぶべきか」という問いは、前提がずれています。RAGは回答の根拠を外部から取り込む手法で、AIエージェントは手順そのものをLLMに決めさせるシステムの形です。両者は排他ではなく、組み合わせたものがエージェンティックRAGです。
RAG：検索結果をプロンプトに足して生成する手法
RAG（Retrieval-Augmented Generation、検索拡張生成）は、Lewisらが2020年の論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（arXiv:2005.11401、NeurIPS 2020採録）で提案した手法です。質問に関連する文書を検索し、その文書をLLMへの入力に添えて回答を生成させます。モデルの学習データに無い社内文書や最新情報を、再学習なしで回答に反映できるのが利点です。
従来型のRAGは「質問を埋め込みベクトルに変換→類似文書を上位k件取得→プロンプトに連結→生成」という決め打ちの1本道で動きます。検索するかどうか、何件取るか、結果が的外れだったらどうするかは、すべて開発者がコードで固定しています。工程の詳細はRAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断で扱っています。
AIエージェント：次の行動をLLMが決めるシステム
Anthropicは2024年12月の解説「Building effective agents」で、LLMとツールをあらかじめ決めたコードの経路で動かすものを「ワークフロー」、LLMが自分の手順とツールの使い方を動的に決めるものを「エージェント」と区別しています。同じ記事では、検索・ツール・記憶で拡張したLLM（augmented LLM）を、ワークフローとエージェントの両方に共通する基本部品として位置づけています。
この定義に当てはめると、従来型RAGは「検索を1回挟むワークフロー」です。検索をLLMが呼び出す道具にして、呼ぶかどうか・何回呼ぶかをLLMに任せた時点で、エージェントの側に移ります。エージェントが動く反復の仕組みはエージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】で詳しく説明しています。
RAGとAIエージェントの関係：制御・検索・失敗時の比較
| 観点 | 従来RAG（本記事の1回検索型） | AIエージェント | エージェンティックRAG |
|---|---|---|---|
| 正体 | 生成の手法 | システムの形 | 両者の組み合わせ |
| 手順を決めるのは | 開発者のコード | LLM | LLM |
| 外部知識の扱い | 毎回1回検索 | 道具の1つとして任意 | 必要な回数だけ検索 |
| 主な目的 | 根拠のある回答 | タスクの完遂 | 根拠が揃うまで集める |
| 失敗時の動き | 再検索なし。回答保留も設計可能 | 別の行動を試す | 検索語を変えて再検索 |
RAGとMCP（Model Context Protocol）も同じように混同されますが、MCPはエージェントが外部ツールにつなぐ接続規格で、やはり層が違います。整理はMCPとRAGの違いとは？役割の違いと使い分け・併用アーキテクチャを実装者向けに解説【2026年版】を参照してください。
エージェンティックRAGの仕組み：検索判断と終了条件
固定パイプラインのRAGが取りこぼす質問
1回検索で根拠を取り切れない例が、複数段階の検索を要する質問です。Adaptive-RAGの原論文も、単純な質問と複数段階の質問を分けて検索戦略を選びます。
- 複数の根拠が要る質問：「返品の条件と送料は？」のように答えが別々の文書にあると、上位k件に片方しか入らないことがある。
- 段階的にたどる質問：「A社の親会社の決算期は？」のように、1回目の検索結果（親会社名）を使って2回目を検索しないと答えに届かない。
- 検索の要らない質問：挨拶や一般常識の質問でも毎回検索し、無関係な文書を混ぜて回答を劣化させる。
これらには、検索前の要否判断と、検索後に根拠の不足を見て追加検索を決める判断が必要です。エージェンティックRAGはこの判断をLLMに持たせます。
判断ループの流れ：検索・採点・書き換え・打ち切り
典型的な流れは次の5段階です。
- 質問を見て、検索が要るか・どの検索先（ベクトル検索、全文検索、SQL、Web）を使うかを決める。
- 検索を実行し、結果を手元の根拠に加える。
- 集まった根拠で質問に答えられるかを採点する。
- 足りなければ、欠けている観点で検索語を作り直して2へ戻る。
- 答えられる、または回数上限に達したら終了する。上限に達したときは推測で答えず、保留や人への引き継ぎを返す。
LLMの判断部分をルールに置き換えると、骨格は次の数十行に収まります。max_steps=1 にすると検索は1回で終わり、上位1件に入らなかった送料の根拠を取りこぼして回答を保留します。検索の要否判断とLLMによる回答生成は省略した、例題専用のコードです。
# LLMの判断部分をルールで置き換えた、判断ループの骨格
DOCS = {
"返品": "未開封なら到着から30日以内に返品できます。",
"送料": "返品の送料は購入者負担です。不良品は当社負担です。",
}
def retrieve(query, top_k=1):
# 上位1件だけ返す検索（ベクトル検索のtop_k=1に相当）
hits = [text for key, text in DOCS.items() if key in query]
return hits[:top_k]
def is_enough(question, contexts):
# 本来はLLMが「この根拠で答えられるか」を採点する
needed = [k for k in DOCS if k in question]
return bool(needed) and all(any(DOCS[k] == c for c in contexts) for k in needed)
def rewrite(question, contexts):
# 本来はLLMが足りない観点で検索語を作り直す
for key in DOCS:
if key in question and DOCS[key] not in contexts:
return key
return question
def agentic_rag(question, max_steps=3):
contexts, query = [], question
for step in range(1, max_steps + 1):
for c in retrieve(query):
if c not in contexts:
contexts.append(c)
if is_enough(question, contexts):
return f"回答（{step}回目の検索で確定）: " + " ".join(contexts)
if step < max_steps:
query = rewrite(question, contexts)
return "根拠が揃わないため回答を保留し、担当者へ回します。"
print(agentic_rag("返品の条件と送料を教えて"))
print(agentic_rag("返品の条件と送料を教えて", max_steps=1))回答（2回目の検索で確定）: 未開封なら到着から30日以内に返品できます。 返品の送料は購入者負担です。不良品は当社負担です。
根拠が揃わないため回答を保留し、担当者へ回します。is_enough と rewrite を別々のLLM呼び出しにすると、根拠が不足して次の検索へ進む回は採点と書き換えの2回、最終回または充足した回は採点の1回が必要です。回答生成の呼び出しは別途数えます。LangGraphでこのループを組む具体的な実装と落とし穴はAgentic RAGとは？従来RAGとの違い・設計パターンとLangGraph実装の落とし穴にまとめています。
エージェントが使う4つの設計パターン
2025年1月に公開されたサーベイ「Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG」（Singhら、arXiv:2501.09136）は、エージェンティックRAGを「RAGの処理にAIエージェントを埋め込んだもの」と定義し、エージェントが使う設計パターンとして次の4つを挙げています。
- Reflection（振り返り）：自分の回答や検索結果を評価し、直す。上の
is_enoughに当たる。 - Planning（計画）：複雑な質問を小さな検索に分解し、順番を決める。
- Tool use（ツール利用）：ベクトル検索・Web検索・APIなど、検索先を使い分ける。
- Multi-agent（マルチエージェント）：検索先ごとや役割ごとに担当エージェントを分け、結果を統合する。
同サーベイは構成の型として、1つのエージェントが検索先を振り分けるルーター型、複数エージェントが分担するマルチエージェント型、上位エージェントが下位を指揮する階層型、検索結果を検証して補正する修正型（Corrective）、質問の難しさで処理を変える適応型（Adaptive）、ナレッジグラフを使うグラフ型などを整理しています。
検索判断に関する関連研究：Self-RAG・CRAG・Adaptive-RAG
「エージェンティックRAG」という呼び名が広まる前から、検索の判断をモデルに持たせる研究は出ていました。検索の要否や結果の評価を理解する関連研究として、次の3つを取り上げます。
| 手法 | 公開 | 発表先 | モデルが判断すること |
|---|---|---|---|
| Self-RAG | 2023年10月 | ICLR 2024 | 検索の要否・根拠の妥当性 |
| CRAG（Corrective RAG） | 2024年1月 | arXiv | 検索結果の関連性・Web検索の追加／切替 |
| Adaptive-RAG | 2024年3月 | NAACL 2024 | 質問の複雑さ・検索回数 |
Self-RAG（Asaiら、arXiv:2310.11511）は、「検索するか」「取れた文書は関連しているか」「回答は文書に支えられているか」を表す特殊なトークン（reflection tokens）をモデル自身に出力させます。判断がモデルの出力に埋め込まれているので、専用に学習したモデルが必要です。
CRAG（Yanら、arXiv:2401.15884）は、軽量な検索評価器で質問との関連性を評価し、「正しい／誤り／曖昧」に分類します。誤りならWeb検索へ切り替え、曖昧なら既存の検索結果とWeb検索の情報を組み合わせます。原論文では、既存のRAG方式と組み合わせられる構成として提案されています。
Adaptive-RAG（Jeongら、arXiv:2403.14403）は、小さな分類器で質問の複雑さを3段階に分け、検索なし・1回検索・複数回検索を使い分けます。簡単な質問にまで多段の検索を回さないので、コストと精度の釣り合いを取りやすい設計です。
検索の要否を1問ずつ判断する発展形としては、DeepRAGとは？検索の要否を1問ずつ判断する仕組みと論文の実験結果【ICLR 2026】もあります。
従来RAGとエージェンティックRAGの比較：精度・コスト・遅延・運用
| 観点 | 従来RAG | エージェンティックRAG |
|---|---|---|
| 検索回数 | 1回（固定） | 0〜上限回（可変） |
| LLM呼び出し | 1回 | 判断ごとに追加 |
| 検索先 | 主に1つのベクトルDB | 複数を使い分け |
| 応答時間 | 比較的予測しやすい | 質問ごとにばらつく |
| 複数根拠の質問 | 取りこぼしやすい | 書き換えで拾える |
| 不具合の追跡 | 検索結果と生成入力の記録が必要 | 加えて途中の判断ごとの記録が必要 |
コスト差は小さくありません。Anthropicは自社のマルチエージェント調査機能の解説「How we built our multi-agent research system」（2025年6月）で、エージェントは通常のチャットの約4倍、マルチエージェント構成は約15倍のトークンを消費したと報告しています。この倍率は通常チャットに対するトークン消費の比較です。従来RAGとの精度・費用・待ち時間の差は、自社の質問セットと同じモデル条件で測って採否を決めます。
途中の判断を追えないと、誤答の原因が「検索が外れた」のか「採点が甘かった」のか切り分けられません。検索と生成を分けて測る方法はRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】で解説しています。
エージェンティックRAGを採用する判断基準
結論から言うと、社内QAでは、まず従来RAGの改善で要求を満たせるか評価すべきです。エージェント化は、従来RAGの検索精度を上げても解けない質問が一定割合あると分かってから入れます。
従来RAGを先に評価する条件
Anthropicの「Building effective agents」は、まず単純な構成を試し、必要な場合に複雑さを増やす方針を示しています。以下の条件では、1回検索型を先に評価します。
- 答えが1つの文書の1か所に書いてある（就業規則、製品マニュアルのFAQ）。
- 応答時間に上限がある（チャットで数秒以内、電話の自動応答など）。
- 1問あたりの推論費用を固定で見積もる必要がある。
- 誤答の原因が「チャンク分割が粗い」「再ランクが無い」など検索側にあると分かっている。この場合は、エージェント化に先立って分割や再ランクを改善し、検索結果が変わるかを評価する。
エージェンティックRAGが効く条件
- 答えが複数の文書やシステムにまたがる（契約書とSQLの取引履歴を突き合わせる、など）。
- 1回目の検索結果を見ないと2回目の検索語が決まらない、段階的な調査になる。
- 質問の難しさの幅が広く、Adaptive-RAGのように、検索なし・1回検索・複数回検索を質問の複雑さに応じて切り替えたい。
- 数十秒かかっても正確さを優先できる業務（調査レポート作成、監査、技術調査）。
1つのエージェントで足りるか、役割を分けた複数エージェントにするかは別の判断です。シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】で基準を比べています。
導入で起きる失敗パターンと対策
検索語の書き換えループ：回数上限と終了分岐
採点が「不十分」を返し続け、回数上限や別の終了条件もなければ、書き換えと再検索が終わらなくなります。LangGraphの公式チュートリアル「Build a custom RAG agent with LangGraph」の構成も、書き換えの回数を数える仕組みを持っていません。
フレームワークの既定上限だけでは、業務上の費用や待ち時間を十分に制限できません。Python版LangGraphの既定の再帰上限（recursion_limit）は、1.0.5では25でしたが、2026年1月12日公開の1.0.6で10,000に、1.1.4以降は10,007に引き上げられています（各版のソース _internal/_config.py で確認）。再帰上限が数えるのはグラフの実行ステップであり、LLMの呼び出し回数ではありません。とはいえチュートリアルの構成ではノード内の処理に加えて条件分岐の採点でもLLMを呼ぶため、既定値のままだと数千回規模の呼び出しが起きてから止まります。用途に合わせた再帰上限を明示的に設定し、LLMの呼び出し回数は別途制限します。
対策は、状態に書き換え回数を持たせて上限を評価データと費用・応答時間の予算から決めることと、上限到達時に推測で答えず「根拠不足」を返す分岐を用意することです。上のコード例の max_steps と最後の return がこれに当たります。
LLMの根拠採点：誤判定と評価基準
採点が甘いと、根拠が足りないまま回答してしまい、従来RAGと同じハルシネーションが残ります。厳しすぎると毎回上限まで回ってコストだけ増えます。採点用のプロンプトは「答えに必要な事実が根拠に書かれているか」を個別に問う形にし、評価データで一致率に加え、根拠不足を合格にする誤判定と、根拠十分を不合格にする誤判定を分けて測ります。検索評価器の検証例として、CRAG原論文の評価も参照できます。
複数検索先のアクセス制御とプロンプトインジェクション対策
エージェントは複数の検索先を自分で選ぶため、質問者が本来見られない文書やテーブルに届くことがあります。検索ツールのサーバー側で利用者の権限を検証し、許可された文書・行だけを返します。たとえばSQL検索では、利用者が閲覧できない取引行をLLMへ渡す前に除外します。Web検索を道具に含める場合は、取得したページに埋め込まれた指示（プロンプトインジェクション）が後続の判断に混ざるおそれがあります。LangGraphの公式例では、検索文書をデータとして扱い、その中の指示を無視するよう採点・生成プロンプトに明記しています。ただし、プロンプトだけに依存せず、ツールの実行権限もサーバー側で制限します。
エージェンティックRAGが使われる業務
- 社内ナレッジ検索：規程・議事録・チケット履歴など保管先の違う文書を横断する。検索先の振り分け（ルーター型）が中心。
- カスタマーサポート：FAQで答えられない問い合わせだけ注文DBや配送状況を追加で引き、根拠が揃わなければ有人対応へ回す。上限到達時の引き継ぎ設計がそのまま品質になる。
- 調査・リサーチ：論点を分解して複数の検索を並行し、結果を統合する。マルチエージェント型を採用する例があり、並列に動かすエージェント数や調査範囲によってトークン消費が増える。
- 医療・法務など根拠の明示が必須の領域：回答ごとに引用元を返すことが前提になる。自動回答ではなく、専門家が確認する下書きや文献候補の提示にとどめるのが現実的。
よくある質問
RAGとAIエージェントの違いは何ですか？
RAGは検索結果をLLMの入力に足して回答させる手法で、AIエージェントは次に何をするかをLLM自身が決めるシステムです。RAGはエージェントが使う道具の1つになれるため、どちらかを選ぶものではありません。
エージェンティックRAGとAgentic RAGは同じものですか？
同じものです。英語のAgentic RAGを日本語で表記したのがエージェンティックRAGで、「エージェント型RAG」「エージェントRAG」と書かれることもあります。
RAGの仕組みをわかりやすく言うと？
質問に関係する文書を先に検索し、その文書を「参考資料」としてLLMに渡してから答えさせる仕組みです。LLMが学習していない社内情報や最新情報を、再学習せずに回答へ反映できます。
エージェンティックAIとAIエージェントの違いは？
AIエージェントは個々のシステムを指す名詞で、エージェンティックAIは「自律的に判断して行動する性質を持つAI」という広い呼び方です。エージェンティックRAGの「エージェンティック」も、検索の判断をLLMに任せる性質を指しています。
エージェンティックRAGにすればベクトルデータベースは不要になりますか？
エージェント化だけでベクトルデータベースが不要になるわけではありません。ただし、従来RAGでもエージェンティックRAGでも、検索対象に応じてSQLや全文検索、Web APIだけで構成できます。エージェンティックRAGが変えるのは検索の使い方で、意味の近い文書を探す手段としてのベクトル検索は、エージェントが選ぶ検索先の1つとして残ります。
