用語: Agentic RAG
TERM_ID: G211
AI用語の分類: AIエージェント・開発・運用
Agentic RAGは、検索を固定された一回の前処理ではなく、AIエージェントが必要性・検索先・クエリ・再検索・停止を状況に応じて判断するRAGの設計です。[1][2][3]
目次
Agentic RAGとは
製品説明、RAGアーキテクチャ図、検索基盤、エージェント開発資料で現れます。従来型RAGが「質問→検索→取得文書をモデルへ渡す」という比較的固定した流れとして説明されるのに対し、Agentic RAGでは検索そのものがエージェントのツールになり、複雑な質問を分解したり、検索先を切り替えたり、結果が不十分なら問いを書き換えて再検索したりします。Microsoftの現行アーキテクチャ解説は、agentic RAGを、検索をオンデマンドで呼び出し、中間結果を評価しながら反復する設計として説明しています。NVIDIAの実装例でも、query decomposition、router、retriever、grader、query rewriteなどが組み合わされています。
この用語を読むときは、名称だけで製品機能や安全性まで推測しないことが大切です。エージェント分野の語は急速に変化しており、同じ言葉が設計パターン、製品機能、プロトコル上の正式オブジェクトを指すことがあります。そのため、元の文脈で誰が何を実行し、どの境界までをその用語が説明しているのかを確認します。
何と区別すればよいか
RAGならすべてAgentic RAGというわけではありません。単純なベクトル検索を一度行ってLLMに渡すだけなら、モデルが高度でも通常は従来型RAGです。また「エージェントがいる」ことだけでも十分ではありません。検索の要否、分解、検索先、検索の反復、結果評価などの一部を実行時に動的判断することが境界です。逆に、Agentic RAGは特定の製品名や単一アルゴリズムではなく、複数の設計パターンを含む総称です。
隣接語との境界を読むときは、「モデルが考える部分」「コードやワークフローが決める部分」「外部サービスとの通信契約」「人間が最終判断する部分」を分けると整理しやすくなります。同じシステムの中で複数の概念が同時に使われるため、一つのラベルだけでアーキテクチャ全体を説明しようとしないことが重要です。
仕組み
典型的には、①質問と会話履歴を解釈する、②必要なら質問を複数の検索課題へ分解する、③社内検索・Web・SQL・APIなど適切な取得手段を選ぶ、④取得結果を関連性や十分性で評価する、⑤不足があればクエリを書き換えるか別の検索先へ進む、⑥十分な根拠が集まった時点で回答・計画・次の行動へ進む、というループになります。すべての実装がこの順序を持つわけではなく、並列検索、リランキング、検証器、引用生成などを挟む設計もあります。重要なのは固定パイプラインより実行時判断の比重が高いことです。
実装図では、入力から最終出力まで一直線に追うだけでなく、状態を保持する箇所、外部へ出る箇所、権限が変わる箇所、再試行や停止が起きる箇所を見ると、用語の役割が分かりやすくなります。エージェント系システムでは「次に何をするかを誰が決めるのか」が設計上の重要な分岐です。
具体例
たとえば「今期の売上低下の原因を、社内資料と外部市場情報の両方から説明して」という依頼を考えます。通常のRAGなら一つの検索クエリで社内文書を検索して終えるかもしれません。Agentic RAGなら、売上推移、主要顧客の変化、競合、市場統計などに課題を分解し、社内検索とWeb検索を使い分け、見つからない論点だけ再検索できます。ただし、最終回答が自動的に正しいわけではありません。取得元の品質、検索漏れ、評価器の誤判定、モデルの統合ミスは残ります。
この例から分かるように、用語が示すのはシステム全体の賢さではなく、特定の接続、制御、実行、引き継ぎ、隔離などの仕組みです。実際の品質は、モデル性能だけでなく、入力データ、ツール設計、権限、エラー処理、評価、監視、人間の運用に左右されます。
利点と限界
利点は複雑な質問への検索カバレッジと適応性ですが、検索回数・モデル呼び出し回数が増えるため、レイテンシとコストが増えやすく、挙動の再現性も下がり得ます。検索先を誤る、低品質情報を何度も追う、不要なループを続けるといった失敗もあります。安全面では、Webや外部文書から取得した悪意ある指示をエージェントが命令として扱う間接プロンプトインジェクションにも注意が必要です。したがって、権限、検索範囲、停止条件、引用、ログ、評価を設計する必要があります。
特に本番運用では「できること」と「許可されていること」を分ける必要があります。エージェントが技術的に実行可能でも、業務ルール上は承認が必要な場合があります。また、通信や実行を標準化しても、内容の正確性、相手の信頼性、最終結果の適法性まで自動的に保証されるわけではありません。
元のニュース・製品説明へ戻ったときの読み方
元の資料でAgentic RAGと書かれていたら、まず「何をエージェントが動的に決めるのか」を確認します。検索するかどうかだけなのか、複数検索先の選択まで行うのか、質問分解や再検索があるのか、取得結果を評価するのか、停止条件は何か、を見ます。次に、検索性能の改善と回答精度の改善を同一視しないことが重要です。retrievalが良くても生成段階で誤ることはあり、逆に検索ログが豊富でも根拠が十分とは限りません。
確認項目を短くまとめると、対象、決定主体、権限、状態、失敗時の扱い、証拠やログ、仕様バージョンの7点です。製品比較では「対応している／していない」だけでなく、その機能がどの範囲で有効か、デフォルト設定は何か、管理者が制御できるかを確認してください。
次に起こりやすい誤解
次に起こりやすい誤解は「Agentic RAGならハルシネーションがなくなる」です。RAGは根拠を供給する方法であり、Agentic化はその取得過程を柔軟にする設計です。正確性を保証する仕組みではありません。
用語を理解した後に重要なのは、その用語から過剰な推論をしないことです。エージェント技術では、相互運用性があることと安全であること、隔離されていることと無害であること、人間承認があることと責任が明確であること、AI-nativeであることと完全自律であることは、それぞれ別の評価軸です。
実務チェックリスト
- この用語は、システムのどの層を説明していますか。
- 次の手順や接続先を、モデル・コード・人間の誰が決めますか。
- 外部データ、ツール、他エージェントへ渡る情報は何ですか。
- 読み取り、書き込み、送信、削除、決済などの権限はどこまでありますか。
- 失敗、タイムアウト、拒否、再試行、途中中断はどう扱われますか。
- ログ、引用、トレース、成果物など、後から確認できる証拠は残りますか。
- プロトコルや製品仕様に版がある場合、資料の日付と現在版は一致していますか。
関連AI用語
注・出典
- Microsoft Azure Architecture Center, Develop an agentic RAG solution — https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-agentic ↩
- Azure AI Search, Agentic retrieval overview — https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview ↩
- NVIDIA, Build an Agentic RAG Pipeline — https://developer.nvidia.com/blog/build-an-agentic-rag-pipeline-with-llama-3-1-and-nvidia-nemo-retriever-nims/ ↩
AI協働制作について
本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。