PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
Agentic RAG（エージェンティックRAG）とは、どこを何回検索するかをエージェントが実行時に決めるRAGの構成です。通常のRAG（記事タイトルの従来のRAGと同じ意味で使います）では、何を・どこから・何回取るかが、設計した時点で決まっています。Agentic RAGでは検索がエージェントの道具になり、中間結果を見てから次の検索を決めます。
Microsoftは、エージェント的な取得を、単一の静的な検索を走らせるのではなく情報の見つけ方を計画して実行するものと説明し、従来の取得が固定の取得パイプラインを走らせるのに対し、エージェント的な取得はループとして働くと述べています。本記事は新語の紹介ではなく、通常のRAG・単なる複数回検索・GraphRAG・Agentic RAGの4つを1本の軸で並べ直し、境界を1文ずつ定義します。
- 通常のRAG＝検索の判断が設計時に確定している
- 単なる複数回検索＝判断は検索を走らせる前に確定し、結果を見ても覆らない
- Agentic RAG＝判断が実行時に決まり、中間結果を見て変わる
Agentic RAGとは何か？通常のRAGと何が違うのか？
違いは、検索の判断がいつ確定するかです。通常のRAGでは、何を・どこから・何回取るかを設計した時点で人が決めておきます。Agentic RAGでは、エージェントが実行時にそれを決め、返ってきた結果を見て次の一手を選びます。
Microsoftの設計ガイドは、Agentic RAGがこの前提を変えるとしています。同社によれば、固定のパイプラインの代わりに、AIエージェントが取得を必要に応じて呼び出せる道具として扱い、利用者の質問について推論し、どの道具を呼ぶかを決め、中間結果を評価し、根拠のある回答を出せるだけのコンテキストが集まるまで反復します。
得られるものも同じ資料が挙げています。Microsoftは、Agentic RAGが多段の推論、動的なクエリ計画、そして性質の異なるデータ源をまたいだ調整を可能にすると述べています。
別の設計ガイドでは、同じ違いが取得の側から説明されています。Microsoftは、エージェント的な取得が単一の静的な検索を走らせるのではなく情報の見つけ方を計画して実行するとしたうえで、従来の取得は固定の取得パイプラインを走らせ、エージェント的な取得はループとして働くと書いています。
学術側の整理も方向が一致します。arXivで公開されたサーベイ論文は、従来のRAGが静的なワークフローに制約され、多段の推論や複雑なタスク管理に必要な適応性を欠くと述べ、Agentic RAGは自律的なAIエージェントをRAGのパイプラインに埋め込むことでその限界を超えるものだと定義しています。
ループの中身には既存の呼び名があります。Microsoftは、言語モデルが推論エンジンとして働き、使える道具を確認して特定のデータを要求する関数呼び出しを生成し、実行結果を受け取ったモデルがもう一度道具を呼ぶか最終回答を出すかを決めると説明したうえで、このループがReason + Act（ReAct）パターンと呼ばれることがあると書いています。
通常のRAGそのものの作り方は、本記事の対象ではありません。社内データで一本目を立ち上げる手順はRAG導入の手順は？社内データで失敗しない進め方で扱っています。
エージェントという語の定義と、ワークフローとの違いも本記事では扱いません。任せる範囲をどう決めるかはAIエージェントとは？ワークフローとの違いと実務で使う条件で整理しています。
単に複数回検索するのとは、どこが違うのか？
分かれ目は、何回どこを検索するかという判断が、検索の前に確定しているかどうかです。複雑な質問を小さな問いに割って何度も検索する手法は、通常のRAGにもあります。ただしそこでは、割るかどうかを検索を走らせる前に決め、返ってきた結果を見てその判断を見直しません。
分解という手法自体はMicrosoftが定義しています。同社は、分解を複雑なクエリを複数の小さく単純な部分クエリに割る処理だとし、割った各クエリを独立に実行して、すべての上位結果を集めたものを蓄積コンテキストにすると説明しています。
判断の時点も明記されています。Microsoftは、そのクエリが複数回の検索を必要とするかどうかを、検索を走らせる前に決めるべきだとしています。
複数回の検索は分解に限りません。同社は、ベクトル検索とキーワードの全文検索のような複数のクエリを手動で走らせ、結果を集約し、手動で並べ替えて上位を返すこともできると書いています。
そして同じ資料が、境界そのものを注記の形で引いています。Microsoftは、分解の手法がオーケストレーターの中に自分で定義した固定のフローに従うとしたうえで、オーケストレーターはクエリを分解するかどうかを検索を走らせる前に決め、検索が返してきた内容に基づいて分解の判断を見直すことはないと述べています。
分岐の条件も同じ注記に書かれています。Microsoftは、中間結果についての推論に基づいて、実行時に分解するかどうか・どう分解するかをエージェントに決めさせる必要があるなら、Agentic RAGを検討するよう促しています。動的な情報源の選択や実行時の反復的な絞り込みを要する複雑な多段クエリでも、同じ判断になるとしています。
| 手法 | 判断が確定する時点 | 結果を見て判断を変えるか |
|---|---|---|
| 通常のRAG（単一の検索） | 設計時 | 変えない |
| 通常のRAG（クエリの分解・手動の複数検索） | 検索を走らせる前 | 変えない |
| Agentic RAG | 実行時 | 変える（中間結果を見て次を決める） |
ここから判定の仕方が決まります。何回検索したかは、Agentic RAGかどうかの判定材料になりません。判定材料になるのは、その回数を誰がいつ決めたかです。
検索そのもののチューニングは本記事の対象外です。検索・データ・生成のどこで落ちているかを順に切り分ける手順はRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで扱っています。
GraphRAGとは何が違うのか？
比べている軸が違います。GraphRAGは索引の側で、文書を実体と関係のグラフに作り変える選択です。Agentic RAGは実行の側で、検索の判断を誰がいつ下すかの選択であり、両者は二者択一の関係になりません。
索引側の設計原則は公開ドキュメントに書かれています。MicrosoftのGraphRAGのドキュメントは、聞いている質問のタイプによって検索結果を比べられるようにしてあるとし、質問の種類ごとに複数の検索方式を用意しています。
方式の並びも同じ資料が説明しています。ローカルな検索はAIが抽出したナレッジグラフの関連データを生の文書のテキストチャンクと組み合わせて回答を作り、グローバルな検索はAIが生成したコミュニティ報告の全体をmap-reduce的にたどって回答を作ります。比較用に基本的なベクトルRAGの実装も同梱されています。
軸の違いを言い切ると、2つの選択は直交します。GraphRAGは「何を索引に持つか」の選択、Agentic RAGは「実行時に誰が判断するか」の選択です。したがって「GraphRAGとAgentic RAGのどちらがよいか」という問いは、そのままでは答えが出ません。
順序としては、索引側が先に決まります。どの検索方式を用意するかが決まった後で、その方式をエージェントに道具として渡すかどうかを決められるためです。例えば、グラフをたどる検索と通常のベクトル検索の2つを道具として並べ、どちらを引くかをエージェントに選ばせる構成が考えられます。
GraphRAGとナレッジグラフの定義そのものは、本記事では扱いません。従来のRAGとの違いと使いどころはHybrid(ハイブリッド)RAGとはなにか？従来のRAGとGraphRAGの新手法で解説しています。
どんな検索に向いているのか？
1つの索引に1回検索すれば答えが出る質問には向きません。向くのは、先に取った結果を見ないと次に何を取ればよいか決まらない質問です。Microsoftは、多段の推論・実行時の情報源の選択・クエリの分解・反復的な絞り込み・取得と行動が同じ流れに入る場合の5つを挙げています。
| 条件 | どういう質問か | Microsoftが挙げる例 |
|---|---|---|
| 多段の推論 | 一方の情報源から取り、その結果を分析してから別の情報源に問う | 直近90日で未解決のリコールがある製品はどれか |
| 実行時の情報源の選択 | どの情報源を引くかを実行時に決める | 関係のある情報源だけを引き、全部は引かない |
| クエリの分解 | 複雑な問いを後続の複数の問いに割る | 2つの拠点の可用性の約束を比べる |
| 反復的な絞り込み | 最初の取得で足りず、不足を見つけて条件を変えて取り直す | 結果を評価し、絞り込んだ語や条件で追加のクエリを走らせる |
| 取得と行動が同じ流れに入る | 情報を集めたうえで実際に処理を実行する | 情報を集めて行動する |
向かない側の線引きのほうが実務では効きます。Microsoftは、単一の索引に対する単一の検索で解けるほど単純な質問なら標準的なRAGのほうが適合するとしたうえで、エージェントの推論の1ステップごとに遅延・トークン消費・複雑さが増えると述べています。同社は、推論と柔軟性がその費用に見合うときにAgentic RAGを使うよう勧めています。
サーベイ論文の側は、向く場面を設計パターンの言葉で整理しています。arXivで公開されたサーベイ論文は、reflection・planning・tool use・multi-agent collaborationという設計パターンによって、取得の戦略を動的に管理し、文脈の理解を反復的に洗練させると述べています。査読前のプレプリントであるため、本記事では論文による整理として扱います。
向く条件のうち、私が実感を持って挙げられるのは、超大規模なデータを探索的に探させてあたりをつけるという使い方です。Microsoftが挙げる5条件に当てはまる場面は、私の実務ではそれほど多くありません。
実用的に考えると、探索的に探させる前にやることがあります。データを綺麗にして、AIエージェントが機械的に探しに行ける仕組みを作るほうが大事で、私の実務ではそこを先に置きます。
Agentic RAGにすると、何を失うのか？
応答時間と、実行のばらつきです。Microsoftは自社の構成を前提とした目安として、1回の検索と1回の生成で済む標準的なRAGの要求が2〜3秒程度で終わるのに対し、3〜5回の道具呼び出しを伴うAgentic RAGの要求は8〜15秒かかりうるとしています。
ばらつきの中身も同じ資料が挙げています。Microsoftは、エージェントが最適でない道具を選んだり、推論のループに入り込んだり、回答に到達できなかったりすることを挙げ、反復の上限・時間の予算・代替の挙動といった防護を用意するよう勧めています。
代償は5つに整理されています。Microsoftが挙げるのは、推論のステップごとにモデル呼び出しが増える遅延、モデル呼び出しとトークンが増える費用、到達の不確かさという信頼性、推論ループの各ステップを計測する必要が生じる観測、そしてエージェントが呼べる道具の1つひとつが攻撃面になるというセキュリティです。
| 何が増えるか | Microsoftが示す目安 | 打つ手 |
|---|---|---|
| 応答時間 | 標準的なRAGは2〜3秒、Agentic RAGは8〜15秒（道具呼び出し3〜5回） | 反復の上限を置く |
| 費用 | モデル呼び出しとトークンが1要求ごとに増える | 1要求あたりの費用を標準的なRAGと比べる |
| 到達の不確かさ | 最適でない道具の選択・推論ループ・未到達 | 上限、時間の予算、代替の挙動を用意する |
| 攻撃面 | エージェントが呼べる道具の数だけ増える | 引数の検証と最小権限 |
上限の置き方には具体的な数字が示されています。Microsoftは、1要求あたりの道具呼び出し回数に上限を設けるべきだとし、5〜10回が典型だとしています。同社は、そこで収束しないなら、その質問には人の助けか別のやり方が要ると述べています。
実務で採るかどうかの判断は、代償の側から決まります。Agentic RAGを使った経験は私にはほとんどなく、コストとレイテンシの観点でやや不利になるという見立てが理由です。
ハーネスを作り込んだ経験からも言えることがあります。LLM側に自由にやらせることはあまり望ましくなく、ある程度の制御をしたうえで使った方がよい、というところに私の実務は落ち着きました。エージェント側に全て丸投げするのは得策ではありません。
運用面から見ると、探索的にAIに探させるやり方は非効率です。呼び出しの回数とトークンの消費が1要求ごとに積み上がるため、避けたいアプローチとして私は扱っています。
代償は速度と費用だけではありません。同じ質問でも通る経路が変わりうるため、再現性の側にも出ます。中間結果を見て次の検索を決める構成では、「先週は返せたのに今日は返せない」という形の劣化が起こり、判断が設計時に固定されている通常のRAGでは起きにくい種類の失敗になります。
評価は何が増えるのか？
測る対象が4つ増えます。Microsoftが追加で測るものとして挙げるのは、道具選択の正確さ、1要求あたりの道具呼び出し回数という取得の効率、端から端までの遅延、そして1要求あたりの費用です。回答が正しいかどうかだけでは、構成を変えた効果を判定できなくなります。
道具選択の正確さは、直し方まで含めて説明されています。Microsoftは、特定の質問に対してエージェントが正しい道具を選ぶ頻度を測るべきだとしたうえで、道具選択の正確さが低いことは道具の説明文に改善の余地があることを示すと述べています。
費用の見方も同じ資料が指定しています。Microsoftは、1要求あたりの費用を標準的なRAGを基準として比べ、追加の推論が十分な価値を出しているかを確かめるよう勧めています。基準となる標準的なRAGの数字を先に取っておくことが前提になります。
いま動いているRAGから、何を変えればよいのか？
検索そのものを作り直す必要はありません。Microsoftは、すでに最適化された検索構成を持つRAGのパイプラインがあるなら、その処理を関数に包むよう勧めています。エージェントが関数を呼び、関数が検索の中身を引き受ける形になるため、作り直すのは検索ではなく道具の見せ方と止め方です。
設計の中心は1点に置かれています。Microsoftは、Agentic RAGの中心的な設計判断が、取得をエージェントの呼べる道具としてどう見せるかであるとし、各検索ツールには言語モデルがいつどう使うかを理解できる明確な説明が要ると述べています。
構成要素は3つです。Microsoftは、ワークフローを組み立てる推論の主体であるエージェント、エージェントが呼べる関数やAPIである道具、そして次の行動を計画し道具を呼び結果を評価する反復の周期である推論ループを挙げ、Agentic RAGでは少なくとも1つの道具が取得を担うとしています。エージェント自身が、いつ反復をやめて最終回答を出すかを制御します。
道具が返す量にも初期値が示されています。Microsoftは、返す結果が多すぎるとトークンを消費して信号を薄めるとしたうえで、1回の道具呼び出しあたり3〜5件から始め、評価に基づいて調整するよう勧めています。
最初に置く3つは何か？
包むこと、説明文、上限の3つです。既存の検索を関数で包み、その関数に何を探せる道具なのかという説明文を付け、1要求あたりの反復上限を置く、という順番になります。3つとも後から足すと過去の実行と条件が揃わなくなるため、自律の幅を広げる前に置く順序が実務的です。
例えば、社内文書を引く既存の検索処理を1つの関数に包み、扱える文書の範囲と使うべき場面を説明文に書いて渡す、という構成が考えられます。想定例として、反復上限を先に置いておけば、道具を2つ目に増やしたときに応答時間と呼び出し回数が同じ条件で比較できます。
構成をAgentic RAGに寄せても、渡す情報の作り込みからは逃げられません。どのみちAIエージェントにも、この時はこの情報を見に行って、という指示は渡すことになるためです。私が手をかけるのは、その渡す中身のほうです。
何をどの順でモデルへ渡すかという設計は、本記事では扱いません。道具の数や返り値まで含めた組み立てはコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で解説しています。
よくある質問
Agentic RAGとエージェント検索（agentic search）は同じものですか？
指しているものが違います。エージェント検索は、ベクトル検索の代わりに文書の構造をたどらせるという検索手法そのものの選択であり、Agentic RAGは検索を道具として呼ばせる実行の構成です。片方だけを採ることもでき、通常のベクトル検索を道具として渡すAgentic RAGも、固定の手順の中でエージェント検索だけを使う構成も成立します。
Agentic RAGにすれば、RAGの精度は上がりますか？
上がるとは限りません。Microsoftは、単一の索引に対する単一の検索で解けるほど単純な質問なら標準的なRAGのほうが適合するとしており、質問の形が合っていなければ遅延と費用だけが増えます。精度が出ない原因が検索・データ・生成のどこにあるかはRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで切り分けられます。
AIエージェントを入れれば、RAGは要らなくなりますか？
要らなくなりません。Microsoftは、Agentic RAGでは少なくとも1つの道具が取得を担うとしており、エージェントを入れても情報を取りにいく仕組みそのものは残ります。要らなくなるのは取得の仕組みではなく、どこを何回引くかをあらかじめ固定しておく手順のほうです。
Agentic RAGは何から学べばよいですか？
いま動いているRAGの検索処理を1つ関数に包み、道具として渡してみるところからです。Microsoftも既存の検索処理を包む方法を勧めており、索引や検索の構成を作り直さずに、道具の説明文と反復上限だけを新しく設計すれば試せます。1要求あたりの呼び出し回数と応答時間を測っておくと、標準的なRAGとの比較がそのまま判断材料になります。
まとめ
Agentic RAGとは、どこを何回検索するかをエージェントが実行時に決めるRAGの構成です。分かれ目は検索の回数ではありません。クエリを分解する通常のRAGも複数回検索しますが、分解するかどうかの判断は検索を走らせる前に確定し、結果を見ても覆りません。
1つの索引への1回の検索で解ける質問なら、通常のRAGのほうが適合します。まずは既存の検索処理を関数に包み、反復の上限を置くところから試せます。
Agentic RAGという言葉に惑わされないことが、実務では効きます。やるべきことを真にやる、という順序を私は崩さないようにしています。
PR
検索を道具として渡す構成まで、手を動かして学び直す
道具の見せ方や反復の止め方は、公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学び直したい場合や、チームに説明する必要がある場合は、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の比較軸は生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
にほんブログ村
