Agentic RAGとは、RAGの検索・読解・検証を固定パイプラインではなく、AIエージェントが状況に応じて計画・実行する設計です。単に文書を検索するだけでなく、「何を調べるべきか」「検索結果は十分か」「次にどの情報源を見るべきか」をエージェントが判断します。[1]
従来RAGとの違い
Section titled “従来RAGとの違い”従来RAGは、開発者が検索手順を固定します。
graph LR
Q["質問"] --> R["検索"]
R --> C["根拠"]
C --> G["生成"]
G --> A["回答"]Agentic RAGでは、エージェントが検索を1回の処理ではなく、複数ステップの行動として扱います。
graph TD
Q["質問"] --> Plan["調査計画"]
Plan --> Tool["検索ツール選択"]
Tool --> Observe["結果観察"]
Observe --> Judge["十分か判定"]
Judge -->|不足| Refine["クエリ修正・別ソース検索"]
Refine --> Tool
Judge -->|十分| Verify["根拠検証"]
Verify --> Answer["回答生成"]重要な違いは、検索の意思決定にLLMが参加することです。
| 観点 | 従来RAG | Agentic RAG |
|---|---|---|
| 検索回数 | 固定 | 必要に応じて増減 |
| 情報源 | 事前に固定 | 質問に応じて選択 |
| クエリ | 1回の書き換えが中心 | 結果を見て改善 |
| 検証 | 生成後に軽く確認 | 根拠不足・矛盾を途中で確認 |
| 適用範囲 | FAQ、単一文書検索 | 調査、分析、複数資料統合 |
なぜAgentic RAGが必要になったのか
Section titled “なぜAgentic RAGが必要になったのか”RAGが本番利用されると、単純な質問よりも複雑な質問が問題になります。
たとえば、次の質問を考えます。
直近3か月の顧客問い合わせから、解約につながりそうな製品課題を分類し、
関連する既存チケットと対応優先度を整理してください。この質問には、複数のサブタスクがあります。
- 「直近3か月」の問い合わせだけを探す
- 解約リスクに関係する問い合わせを抽出する
- 製品課題ごとに分類する
- 既存チケットと照合する
- 対応優先度を判断する
- 根拠を示して要約する
1回のベクトル検索では不十分です。調査計画、複数検索、照合、検証が必要になります。
Agentic RAGの基本部品
Section titled “Agentic RAGの基本部品”Agentic RAGは、次の部品で構成されます。
| 部品 | 役割 |
|---|---|
| Planner | 質問を分解し、調査手順を決める |
| Tool Router | どの検索ツール・データソースを使うか選ぶ |
| Retriever Tools | キーワード検索、意味検索、DB検索、Web検索など |
| Reader | 取得した文書を読み、必要箇所を抜き出す |
| Critic | 根拠の十分性、矛盾、引用の正確性を評価する |
| Memory | 調査途中の発見、除外理由、既読文書を保持する |
| Generator | 検証済み根拠から回答を作る |
この構成は、人間の調査に近い動きです。最初に検索し、見つかった資料を読み、足りなければ検索語を変え、最後に根拠を整理して答えます。
代表的な設計パターン
Section titled “代表的な設計パターン”1. Corrective Agentic RAG
Section titled “1. Corrective Agentic RAG”検索結果の品質を判定し、悪ければ補正します。CRAGは、検索結果の品質評価に基づいて再検索や外部検索などの補正行動を取る設計を示しています。[2]
graph LR
Q["質問"] --> R["検索"]
R --> E["検索品質評価"]
E -->|良い| G["生成"]
E -->|曖昧| RR["再検索"]
E -->|悪い| WS["別情報源検索"]
RR --> E
WS --> E向いている用途は、検索失敗が回答品質に直結するFAQ、医療・法務・社内規定検索などです。
2. Multi-hop RAG
Section titled “2. Multi-hop RAG”複数の根拠を順番にたどる設計です。
質問: A社の買収後に、B製品の価格ポリシーはどう変わったか？
1. A社の買収時期を調べる
2. 買収後のB製品資料を探す
3. 価格ポリシーの変更点を抽出する
4. 買収前の資料と比較する1つ目の検索結果が、2つ目の検索条件になります。このような質問は、固定top-k検索だけでは取りこぼしやすくなります。
3. Tool-using RAG
Section titled “3. Tool-using RAG”文書検索だけでなく、API、SQL、計算、コード実行などを使います。
| ツール | 例 |
|---|---|
| SQL | 売上、利用状況、ログを集計する |
| Web検索 | 公開情報や最新情報を確認する |
| ファイル検索 | 社内文書やリポジトリを探す |
| コード実行 | 数値分析やテストを行う |
| ブラウザ操作 | Web画面上の情報を確認する |
RAGは「文書検索」から「根拠取得のためのツール利用」へ広がります。
4. Hierarchical Retrieval Interface
Section titled “4. Hierarchical Retrieval Interface”2026年のA-RAGのような研究では、LLMに階層的な検索インターフェースを直接使わせる方向が示されています。[4]
たとえば、エージェントには次のような道具を与えます。
- キーワード検索
- 意味検索
- チャンク本文の読み込み
- セクション全体の読み込み
- 関連文書の展開
エージェントは、最初に粗く探し、必要な部分だけ深く読むことができます。これは、人間が目次を見てから該当ページを読む行動に近い設計です。
Agentic RAGの強み
Section titled “Agentic RAGの強み”複雑な質問に対応しやすい
Section titled “複雑な質問に対応しやすい”質問を分解し、段階的に調査できます。単純なRAGが「一度に答えを探す」のに対して、Agentic RAGは「答えに近づくための探索」を行います。
情報源を使い分けられる
Section titled “情報源を使い分けられる”製品仕様は公式ドキュメント、障害情報はチケット、利用状況はDB、最新公開情報はWebというように、質問に応じて情報源を選べます。
検索失敗に気づきやすい
Section titled “検索失敗に気づきやすい”検索結果が弱い場合、エージェントは検索語を変えたり、別の情報源を試したりできます。固定RAGよりも、失敗から回復しやすくなります。
監査ログを残しやすい
Section titled “監査ログを残しやすい”どの検索を行い、どの根拠を採用し、どの根拠を除外したかを記録できます。業務利用では、回答そのものよりも「なぜその回答になったか」が重要なことがあります。
Agentic RAGのリスク
Section titled “Agentic RAGのリスク”Agentic RAGは強力ですが、設計を誤ると危険です。
| リスク | 内容 | 対策 |
|---|---|---|
| コスト増 | 検索・生成・検証を何度も行う | 最大ステップ数、予算、タイムアウトを設定する |
| 遅延 | 複数ステップで回答が遅くなる | 並列検索、キャッシュ、早期終了を使う |
| 暴走 | 不要な検索や行動を続ける | 行動ルールと停止条件を明確にする |
| 権限漏れ | エージェントが不適切な情報源を見る | ユーザー権限を検索層で強制する |
| 根拠混同 | 複数ソースの矛盾を見落とす | 引用単位で検証し、矛盾を明示する |
| プロンプトインジェクション | 検索文書内の命令に従う | 文書を命令ではなく参照資料として扱う |
実務での設計原則
Section titled “実務での設計原則”1. エージェントに自由を与えすぎない
Section titled “1. エージェントに自由を与えすぎない”Agentic RAGは、完全自律にするほど良いわけではありません。業務では、使えるツール、情報源、ステップ数、回答形式を明確に制限します。
許可:
- 製品ドキュメント検索
- チケット検索
- FAQ検索
禁止:
- 権限外の顧客データ検索
- 外部Webへの機密情報送信
- 根拠なしの断定2. 検索行動をログに残す
Section titled “2. 検索行動をログに残す”回答だけでなく、途中の検索行動を記録します。
- 生成したサブクエリ
- 使用した情報源
- 採用した根拠
- 除外した根拠
- 再検索した理由
- 最終回答の引用
ログがあると、誤答の原因分析と改善がしやすくなります。
3. 「答えない」能力を入れる
Section titled “3. 「答えない」能力を入れる”Agentic RAGでも、根拠がなければ答えない設計が必要です。Self-RAG は、検索の必要性、根拠の有用性、生成結果の根拠忠実性をモデルに評価させる方向を示しています。[3]
確認できた根拠では結論を出せません。
不足している情報は、契約プランと対象バージョンです。無理に答えるエージェントは、検索能力が高くても危険です。
4. 評価はタスク単位で行う
Section titled “4. 評価はタスク単位で行う”Agentic RAGの評価では、最終回答だけでなく行動も評価します。
| 評価観点 | 確認すること |
|---|---|
| Retrieval Success | 必要な資料を見つけたか |
| Tool Choice | 適切な情報源を選んだか |
| Step Efficiency | 不要な検索をしすぎていないか |
| Evidence Faithfulness | 回答が根拠に忠実か |
| Citation Accuracy | 引用が回答を支えているか |
| Refusal Quality | 根拠不足時に適切に拒否したか |
Agentic RAGはRAGを置き換えるのか
Section titled “Agentic RAGはRAGを置き換えるのか”Agentic RAGは、すべてのRAGを置き換えるものではありません。
単純なFAQ、短い社内規定検索、製品マニュアルの該当箇所検索では、Advanced RAGで十分な場合が多くあります。Agentic RAGが必要になるのは、調査、比較、複数情報源の統合、コード理解のように、検索行動そのものが複雑な場合です。
| 質問の種類 | 推奨 |
|---|---|
| 「パスワード変更方法は？」 | Advanced RAG |
| 「このエラーコードの原因は？」 | ハイブリッド検索 + リランク |
| 「直近の問い合わせ傾向を分類して」 | Agentic RAG |
| 「このリポジトリで認証処理を変更するには？」 | コードRAG + Agentic RAG |
| 「社内文書全体の主要テーマは？」 | Graph RAG または Agentic RAG |
- Agentic RAGは、検索・読解・検証をエージェントが計画するRAG
- 複雑な調査、複数情報源、コード理解、再検索が必要なタスクに向く
- 自由度が高いぶん、権限、ログ、停止条件、拒否設計が重要になる
- 実務では、Advanced RAGで足りない部分に限定してAgentic RAGを導入するのが現実的