「Agentic RAG」の台頭：単なる検索から、マルチエージェントによる検証・反復・自律補正型ナレッジシステムへの進化

2026年の現在、LLMを用いたシステム開発において、社内ドキュメントや専門知識をAIに参照させる手法として RAG (Retrieval-Augmented Generation) は完全に一般化しました。しかし、多くの開発チームが「RAGを本番運用に載せたものの、回答の精度が一定以上に上がらない」という深刻な壁に直面しています。

従来のRAGは、「ユーザーの質問に関連しそうなドキュメントを検索し、それらをコンテキストに詰め込んでLLMに一度だけ回答させる」という 静的な一方通行のパイプライン (Naive RAG / Advanced RAG) でした。このアプローチでは、検索結果にノイズが混ざっていたり、必要な情報が部分的に不足していたりした場合、LLMは平気でハルシネーションを起こすか、「分かりません」と回答を拒否してしまいます。

この限界を突破するために登場したのが、自律的な意志決定を伴うループ構造を備えた 「Agentic RAG（エージェンティックRAG）」 です。今回は、単なるドキュメント検索から、マルチエージェントによる検証・反復・自律補正型ナレッジシステムへと進化したAgentic RAGの全貌と、具体的なシステム設計パターンを解説します。

従来のRAGとAgentic RAGの決定的な違い

従来のRAGシステムは、コード化された固定のワークフローに依存していました。一方、Agentic RAGは、検索や推論の各ステップをLLMベースの 「自律型エージェント」 に委ね、動的にプロセスを分岐・再実行する点に本質的な違いがあります。

1. 静的パイプラインから動的プランニングへの移行

従来のRAGでは、クエリに対して常に同じ検索アルゴリズムが実行されていました。Agentic RAGでは、最初の「クエリプランニング・エージェント」が質問を分析し、単一の検索で済むのか、あるいは複数の検索クエリに分解して並列実行すべきか、どのベクトルデータベースを参照すべきかを自律的に決定します。

2. 回答品質の自律評価と自己修復（Self-Correction）

Agentic RAGの最大の特徴は、生成された回答の妥当性をエージェント自身が評価する 「自己批判・修正ループ（Reflective Loop）」 が組み込まれている点です。回答が十分な根拠に基づいていないと判断された場合、エージェントは自動的に検索クエリをチューニングし、不足している情報を再検索します。

Agentic RAGを構成する4つのエージェントコアパターン

Agentic RAGを構築する際、システムは以下の4つの自律的機能（またはそれぞれを担当する独立したエージェント）を組み合わせることで成り立ちます。

パターン1：クエリ・ルーター (Query Router)

ユーザーの質問内容に応じて、検索元を柔軟に切り替えるエージェントです。例えば、ユーザーが「最新のリリース情報」について尋ねた場合はWeb検索ツールを呼び出し、「社内の旅費規程」について尋ねた場合は社内ベクトルDB（Vector DB）にアクセスする、といった意思決定を最初の1歩として自律的に行います。

パターン2：サブクエリ分解 (Sub-query Decomposition)

「競合A社と我が社の最新モデルの機能差分を、コストパフォーマンスの観点で比較して」といった複雑な質問に対して、1つのクエリで検索をかけても適切なドキュメントはヒットしません。このエージェントは、複雑なクエリを「A社の最新モデルの機能と価格」「我が社の最新モデルの機能と価格」といった 複数のシンプルな子クエリに分解（Decomposition） し、それぞれで検索を実行した結果を集約・統合します。

パターン3：検索結果チェッカー (Document Grader / Filter)

検索によってヒットしたドキュメントが、本当にユーザーの質問に回答するために役立つかどうかを1件ずつ評価するエージェントです。関連度が低いノイズ（無関係なドキュメント）を排除し、生成フェーズに回す情報純度を最大化します。もし役立つドキュメントが1件もなかった場合、エージェントは検索ワードを自動修正して再検索を指示します。

パターン4：回答評価・検証器 (Hallucination & Answer Grader)

生成された最終回答に対して、以下の2点から厳格なアサーション（検証）を行います。

忠実性検証 (Faithfulness) ：生成された回答が、検索されたソースドキュメントの記述に100%基づいているか（ハルシネーションがないか）。
有用性検証 (Answer Usefulness) ：生成された回答が、ユーザーの元々の質問に対して的確に答えているか。

いずれかの検証に失敗した場合、システムは回答を出力せず、生成エージェントまたは検索エージェントに対して「どの部分が矛盾しているか」のフィードバックを与え、自己修復のための再実行を促します。

Agentic RAGの実装アーキテクチャ設計

Agentic RAGを実装する場合、ステート（状態）を保持しながら循環型のワークフローをきれいに記述できる LangGraph などのフレームワーク、または Model Context Protocol (MCP) を用いたエージェント接続が最適です。

以下は、自己修正型RAG（Corrective RAG / Self-RAG）の処理フローをコードレベルでイメージするための、TypeScript風の擬似設計コードです。

// Agentic RAG の状態定義
interface RagState {
  query: string;
  subQueries: string[];
  documents: Document[];
  draftAnswer: string;
  gradingScore: number;
  retryCount: number;
}

// Agentic RAG の実行コントロールノード
async function agenticRagWorkflow(userQuery: string): Promise<string> {
  let state: RagState = {
    query: userQuery,
    subQueries: [],
    documents: [],
    draftAnswer: '',
    gradingScore: 0,
    retryCount: 0
  };

  // 1. クエリの解析と分解
  state.subQueries = await analyzeAndDecomposeQuery(state.query);

  // 2. 評価基準を満たすまでループする自律検索・生成サイクル
  while (state.retryCount < 3) {
    // 並列検索の実行
    state.documents = await retrieveDocuments(state.subQueries);

    // ドキュメントの適合性チェック
    const validDocs = await gradeDocuments(state.query, state.documents);
    if (validDocs.length === 0) {
      // 適合ドキュメントがなければクエリをリライトして再試行
      state.subQueries = await rewriteQueries(state.query, state.subQueries);
      state.retryCount++;
      continue;
    }

    // 回答のドラフト生成
    state.draftAnswer = await generateDraftAnswer(state.query, validDocs);

    // 忠実性と有用性のダブル評価
    const isFaithful = await checkFaithfulness(state.draftAnswer, validDocs);
    const isUseful = await checkAnswerUsefulness(state.query, state.draftAnswer);

    if (isFaithful && isUseful) {
      console.log("✓ 回答の品質評価に合格しました。");
      return state.draftAnswer;
    }

    // 評価失敗時のフィードバックとクエリ修正
    console.warn("⚠ 品質チェック不合格。再プランニングを実行します。");
    state.subQueries = await feedbackAndOptimize(state.query, state.draftAnswer);
    state.retryCount++;
  }

  return "申し訳ありません。複数の検索と検証を試みましたが、信頼できる回答を構築できませんでした。";
}

このループ構造により、従来のRAGでは防げなかったハルシネーションを、ユーザーの画面に届く前にバックエンドで自律的に検知し、修正することが可能になります。

プロダクション導入における2つの大きな課題と対策

Agentic RAGは極めて強力ですが、実務のプロダクション環境に導入する際には、避けて通れない 2つの大きな課題 が存在します。

課題1：APIコストと遅延（レイテンシ）の増加

エージェントが検索、評価、リライト、再生成のループを回すため、1回のユーザーの質問に対して何度もLLM APIを呼び出すことになり、回答までのスピードが低下し、API利用料金も跳ね上がります。

対策：役割の分担とSLMの活用

すべてのステップに最高峰のフロンティアモデル（Claude 3.7 SonnetやGPT-4oなど）を使う必要はありません。「ドキュメントの関連度評価（Document Grader）」や「ハルシネーションの検知（Faithfulness Check）」といった判断タスクには、機能呼び出し（Tool Calling）が高速で安価な 軽量モデル（Claude 3.5 HaikuやGPT-4o-mini、あるいはファインチューニングされたLlama-3クラスのSLM） を割り当てることで、コストを10分の1に抑え、体感レイテンシを大幅に改善できます。

課題2：無限ループとスタックの防止

クエリのリライトと評価が噛み合わず、エージェントが「検索 ⇄ 不合格」を永遠に繰り返してしまうリスクがあります。

対策：決定論的な最大リトライ制限とフォールバックの設計

上記の擬似コードで示したように、エージェントループには必ず「最大試行回数（retryCount < 3）」などの厳格な上限を設定してください。また、上限に達した場合は「自律回答をあきらめ、ソースドキュメントの単純な要約と参照リンクのみを提示する」といった、決定論的なセーフティフォールバック（安全な代替処理）をコード側で定義しておくことが重要です。

結論：エージェントがナレッジシステムを「能動的」にする

従来のRAGは、本質的に「データベースのインデックスからテキストを拾ってくる賢い検索窓」の延長線上にありました。しかし、Agentic RAGへと進化したシステムは、情報の不足を自ら察知し、データの真偽を疑い、必要であれば外部の知識源まで自律的に手を伸ばす 「能動的なAIリサーチャー」 へと変貌を遂げています。

これからRAGシステムを新規構築、あるいは改善する予定のあるエンジニアの皆さんは、まずは「回答評価器」や「クエリルーティング」といった小さな1ステップからエージェント化を始めてみてはいかがでしょうか。その小さなループが、システムの回答信頼性を劇的に引き上げるはずです。