meguli
業務効率化読了 約11分

Agentic RAGとは?RAG・AIエージェントとの違いと導入判断

Agentic RAGとは何かを、RAG・AIエージェントとの違いから解説。検索を繰り返す仕組みや構成要素、従来型RAGとの比較、導入時の注意点を整理します。

こんにちは、平岡です。Agentic RAGとは、検索を決められた手順で一度だけ実行するのではなく、エージェントが検索をツールとして呼び出し、結果を評価して追加の検索を進めるRAGの設計です。

単純な社内FAQのように、質問に対して一度情報を探せば答えられる業務なら、従来型RAGが候補になります。一方、複数の資料を照合したり、問いに応じて検索先を選んだりする必要があるなら、Agentic RAGを検討する余地があります。要点は、RAGが情報を検索して回答に使う仕組み、Agenticが検索や判断を動的に進める性質を指すことです。

Agentic RAGとは

Agentic RAGの位置づけ

Agentic RAGは、RAG(検索拡張生成)にエージェント的な動きを組み合わせた方式です。Microsoftの説明では、エージェントが検索をツールとして必要に応じて呼び出し、途中で得た結果を評価します。情報が足りなければ、追加の検索に進みます。

たとえば、営業担当が「この顧客の契約条件と、直近の問い合わせ内容を踏まえて提案の注意点をまとめて」と尋ねる場面を考えます。契約書と問い合わせ記録の両方を調べ、結果を照らし合わせる必要があるなら、質問を一度検索するだけの処理では足りない可能性があります。Agentic RAGでは、何を調べるか、結果が十分かを処理の途中で判断する設計にできます。

ただし、Agentic RAGの「Agentic」を、すべてのサービスに共通する厳密な仕様名として扱うのではなく、ここでは検索や判断を動的に進める性質として整理します。

位置づけ

RAGに、検索の選択・結果の評価・追加調査という動きを加えた設計です。何度も検索すること自体ではなく、問いや途中結果に応じて次の行動を決める点が特徴です。

RAGとは:検索拡張生成の基本

RAGの基本

RAGは、検索と大規模言語モデル(LLM)を組み合わせ、モデルが学習時に持っていない特定の情報や独自データに基づく回答を生成するパターンです。社内規程や製品資料などを検索し、その情報を回答づくりに利用するイメージです。

基本の流れは、質問を受けて関連情報を検索し、検索結果を文脈としてLLMに渡して回答を生成することです。Microsoftは従来型RAGを、ユーザーの質問、検索、文脈の組み立て、LLMの呼び出しという固定的な処理順で説明しています。

RAGの初期研究論文では、検索で得る「非パラメトリックな記憶」と、生成モデルが持つ「パラメトリックな記憶」を組み合わせる手法が扱われています。つまり、モデルの内部にある知識だけに頼らず、検索した情報も生成に使うという考え方です。

たとえば、総務担当が就業規則について質問されたとき、RAGは規程の該当箇所を検索し、その内容を踏まえた回答を作ります。回答の正しさは参照する資料や検索結果にも左右されるため、どの文書を検索対象にするかが実務上の判断点です。

RAGとAIエージェントの違い

RAGとAIエージェント

RAGは、情報を検索して回答生成に活用する仕組みです。AIエージェントは、タスクに対してどの処理を行うか、どのツールを使うかを決めながら進める仕組みを指します。RAGが情報取得と回答生成の方法を表すのに対し、エージェントは行動の決定や実行を担います。

Anthropicは、事前定義されたコード経路でLLMとツールを調整する仕組みをworkflow、LLMが処理やツール利用を動的に決める仕組みをagentとして区別しています。この区別で見ると、決まった検索をして回答するRAGは固定的なworkflowとして設計できます。Agentic RAGでは、エージェントが検索の実行や追加調査を決める構成を取ります。

OpenAIのエージェント定義ガイドでは、エージェントの設定要素として、名前、指示、モデル、ツール、ガードレール、引き継ぎなどを挙げています。情報を探すだけのRAGと違い、エージェントの設計では「何を任せ、どこで人や別の処理に引き継ぐか」も設計対象です。

OpenAIはエージェント用ツールを、情報取得に使うデータツール、システムを操作するアクションツール、他のエージェントを利用するオーケストレーションツールに分類しています。社内資料を探すだけならデータツールが中心ですが、顧客管理システムへの登録まで任せるなら、アクションツールを含む別の設計になります。

AgentとAgenticの違い

AgentとAgentic

Agentは、タスクを進める主体となるエージェントを指します。Agenticは、その主体が状況に応じて行動を選んだり、処理を繰り返したりする性質を表す言葉として使うと、両者を区別しやすくなります。

たとえば、検索ツールを備えたAgentが存在しても、必ずしも自由に検索を繰り返すとは限りません。処理が「質問を受ける→検索する→回答する」と固定されていれば、エージェントという構成要素があっても、動きは決められたworkflowに近い場合があります。

Agentic RAGでは、質問の内容や検索結果を踏まえて、次に検索するか、別のツールを使うかを決める動きを重視します。「Agentがある」ことと「Agenticな振る舞いをする」ことは同じではありません。

Agentic RAGの仕組みと構成要素

Agentic RAGの流れ

Microsoftが示すAgentic RAGの主な構成要素は、ワークフローを調整するエージェント、実行可能な関数やAPIなどのツール、結果を評価して処理を反復する推論ループです。エージェントが問いを受け取り、ツールの実行結果を見て次の行動を選びます。

処理例は、質問理解、次の行動の決定、ツール呼び出し、結果評価、必要に応じた反復、回答生成という流れです。たとえば「製品Aと製品Bの保守条件の違い」を調べる場合、製品ごとの資料を探し、条件がそろっているかを評価してから比較回答をまとめる、といった設計が考えられます。これは仕組みを説明するための例であり、実際の検索先や処理順は設計によって異なります。

質問を理解する
→ 次の行動を決める
→ 検索ツールやAPIを呼び出す
→ 結果を評価する
→ 不足があれば追加で調べる
→ 回答を生成する

ここで重要なのは、ツールを使えるだけでなく、結果を見て次の行動に反映することです。検索結果が不十分なのに回答を確定するのか、別の情報源を探すのか。その判断条件を設計しないと、検索を繰り返すだけで業務上の答えにつながらないことがあります。

従来型RAGとAgentic RAGを比較

RAGとAgentic RAG

Microsoftの説明では、従来型RAGは単一クエリでの検索が中心です。一方、agentic retrievalは複雑な入力から複数のサブクエリを作り、並列実行する方式として説明されています。別の説明では、Agentic RAGが必要に応じて検索を呼び出し、結果を評価して追加検索する流れも示されています。

  • 従来型RAG:質問を受けて検索し、文脈を組み立て、LLMで回答。検索の手順が固定されやすい。
  • Agentic RAG:問いに応じて調べ方を選び、複数のサブクエリや追加検索を行う設計が可能。
  • 従来型RAGの候補:社内FAQや製品仕様のように、検索先と質問の対応が比較的明確な業務。
  • Agentic RAGの候補:複数段階の推論が必要な問いや、実行時に検索先を選ぶ必要がある業務。

営業部門で「返品条件を教えて」という質問なら、対象の規程を一度検索する従来型RAGで足りるかもしれません。「取引先との契約内容、過去の問い合わせ、製品仕様を踏まえて、提案時の注意点を整理する」という問いでは、複数の情報源を調べて照合する処理が必要になる可能性があります。後者のような問いが、Agentic RAGを検討する分かれ目です。

比較の基準

検索先が決まっていて、一度の検索で答えられるなら従来型RAGを優先して検討します。複数の調査や検索先の選択が必要な問いでは、Agentic RAGの追加価値を見積もります。

Agentic RAGを検討するときの観点

導入を考える観点

Microsoftは適用候補として、複数段階の推論や、実行時に検索先を選ぶ必要があるワークロードを挙げています。導入を考える際は、まず実際の質問を集め、「どの文書を探せば答えられるかが決まっているか」「複数の資料を照合するか」を分けてみます。

たとえば、経理部門の申請手順を答えるだけなら、規程を検索する従来型RAGで対応できる可能性があります。一方、申請内容に応じて規程、過去の処理例、関連する社内資料を順に調べる必要があるなら、検索先の選択や追加調査が必要かを検証します。最初から全業務をエージェント化せず、複数段階の判断が含まれる質問を対象にする方法が現実的です。

注意したいのは、動的な判断を増やすほど、処理の遅延やコストが増える可能性があることです。Anthropicは、自律性に伴ってエラーが累積するリスクも説明しています。検索結果の読み違いが次の検索や回答に引き継がれると、最終回答の誤りにつながりかねません。

自律性の管理

Agentic RAGに顧客情報の更新や申請処理などの操作を任せる場合、検索だけの構成とはリスクが異なります。Anthropicは、エージェントを使う場合にサンドボックス環境で十分にテストし、適切なガードレールを設けることを推奨しています。本番データに対する操作を、検証前のエージェントに任せない設計が重要です。

導入前の検証では、実際の質問と期待する回答、参照すべき資料、許可するツールをセットで試します。たとえば「規程に記載がない場合は回答を確定せず、担当者に引き継ぐ」という条件を設け、検索不足時の動きも確かめます。遅延やコストを許容できる問いに限定し、従来型RAGで足りる業務と分けて運用するのが判断のポイントです。

まとめ

RAGは検索した情報をLLMの回答に活用する仕組み、Agentはタスクに応じて処理やツール利用を進める主体、Agenticは状況に応じて行動を選ぶ性質として整理できます。Agentic RAGは、エージェントが検索結果を評価し、必要に応じて追加調査を行うRAGの設計です。

次の一歩は、自社でよくある質問を数件選び、必要な情報源と検索回数を洗い出すことです。一度の検索で答えられるなら従来型RAG、複数の情報源を照合し、途中結果に応じて次の調査を変える必要があるならAgentic RAGを比較します。
複雑な問いに必要な範囲だけ自律性を加え、遅延・コスト・誤りへの対策とあわせて判断することが導入の基本です。

参考・出典

この記事をシェア
𝕏 でポストB! はてブ
m
株式会社meguli

AI×DXで、社会の巡りをよくする。中小企業の現場で使えるAI活用・業務改善の実践情報を発信しています。

ご相談・お問い合わせはこちら →

あわせて読みたい