Agentic RAGの実践：LLMアプリの精度を爆上げする評価駆動開発3つのコツ

Posted at 2026-06-29

Agentic RAGの実践：LLMアプリの精度を爆上げする評価駆動開発3つのコツ

「従来のRAGでハルシネーションが減らない」「複雑な質問に答えるのが難しい」と感じていませんか？

多くのLLMアプリケーション開発者が直面するこれらの課題は、RAGの直線的な限界に起因することが少なくありません。しかし、Agentic RAGと**LLM評価駆動開発（EDD）**を組み合わせることで、LLMアプリの精度と信頼性は飛躍的に向上します。この記事では、従来のRAGの限界をAgentic RAGで克服し、さらに評価駆動開発を導入することで、LLMアプリの精度を飛躍的に向上させるための具体的な手法と実践的な3つのコツを、LangChainやLangGraphを用いた実装例を交えながら解説します。

この記事を読めば、あなたのLLMアプリは単なる応答システムから、自律的に思考し、高品質な情報を提供する強力なエージェントへと進化を遂げるでしょう。

従来のRAGの限界とAgentic RAGがもたらす革新

このセクションでは、従来のRAGが抱える課題を明らかにし、Agentic RAGがどのようにそれらの課題を解決し、LLMアプリに新たな可能性をもたらすのかを解説します。

従来のRAG（Retrieval-Augmented Generation）は、外部知識を検索してLLMのハルシネーションを抑制する強力な手法として広く普及しました。しかし、その直線的なワークフローは、以下のような課題を抱えています。

検索ノイズの影響を受けやすい: 検索結果にノイズが混ざると、LLMが誤った情報に基づいて回答を生成し、ハルシネーションを引き起こすリスクがあります。
複雑な質問への対応困難: 複数のドキュメントを横断する比較や集計、多段階の推論を要する複雑な質問に対しては、単一の検索と生成では対応しきれません。
情報の断片化: 長文ドキュメントの固定長チャンキングでは、文脈が途切れてしまい、関連情報を見落とすことがあります。

Agentic RAGとは何か？

Agentic RAGは、LLMに「推論」と「道具の使用」を行わせるAIエージェントの仕組みを、検索拡張生成のプロセスに統合した手法です。従来のRAGが固定的なワークフローであるのに対し、Agentic RAGではLLMが自律的に判断し、動的かつループを含むワークフローで情報取得や回答生成を行います。NVIDIAの技術ブログでも、「RAGをLLMの推論プロセスに統合し、LLMが能動的に情報収集を管理する動的アプローチ」と説明されています。

Agentic RAGの基盤となる要素は以下の通りです。

意思決定エージェント: ユーザーの質問や現在の状況に応じて、次に取るべき行動（検索、ツールの使用、回答生成など）を判断します。
ツールアクセス: Web検索、データベースクエリ、計算ツールなど、様々な外部ツールを呼び出して情報を取得・処理します。
短期/長期記憶システム: 会話の履歴や過去の経験を記憶し、より賢明な意思決定に役立てます。

Agentic RAGが解決する課題

Agentic RAGは、LLMが自律的に検索戦略を最適化し、外部ツールを効果的に利用することで、従来のRAGの課題を克服します。

検索ノイズとハルシネーションの抑制:
- LLMが検索結果の品質を評価し、情報が不十分な場合はクエリのリライトや再検索、Web検索への切り替えを行います。
- Self-RAGや**Corrective RAG (CRAG)**といった手法を導入することで、LLM自身が検索と生成のプロセスを批評し、ハルシネーションを抑制し、根拠整合性を高めます。
複雑な質問への対応:
- LLMが「どのツールを使って、どのデータを、どのような順序で取得すべきか」を自律的に判断し、必要に応じて情報取得や計算などのステップを挿入します。
- これにより、複雑なクエリを分解して多角的に検索し、多段階の推論が可能になります。
情報断片化の回避と文脈の最適化:
- 親ドキュメント検索（Parent Document Retrieval）やウィンドウ拡張などのチャンキング戦略を最適化し、ヒットしたチャンクの前後を含む大きなテキストブロックを取得することで、文脈の断絶を防ぎます。
- LangChainのTextSplittersツールを活用し、意味的に意味のある小さなチャンクに分割することも有効です。

実践！Agentic RAGを実装する3つのコツ

このセクションでは、Agentic RAGを効果的に実装するための3つの具体的なコツと、LangGraphを用いた実装の概念的な例を紹介します。

Agentic RAGの導入は、LLMアプリのインテリジェンスを次のレベルへと引き上げます。ここでは、その実践的なアプローチを解説します。

コツ1: LangGraphで動的な意思決定ワークフローを構築する

Agentic RAGの核となるのは、LLMが自律的に判断し、動的なワークフローを生成する能力です。これを実現するために、LangChainのサブプロジェクトであるLangGraphが非常に強力なツールとなります。LangGraphは、状態管理と条件分岐、ループを組み込んだグラフベースのワークフローを構築することを可能にします。

LangGraphによるAgentic RAGのワークフロー例（概念的な状態定義）

from typing import List, TypedDict
from langchain_core.documents import Document

class AgentState(TypedDict):
    """
    Agentの現在の状態を定義するTypedDict。
    この状態がワークフローの各ノード間で共有・更新される。
    """
    question: str  # ユーザーの質問
    documents: List[Document]  # 検索されたドキュメントのリスト
    generation: str  # 生成された回答
    grade: str  # ドキュメントまたは回答の評価結果（例: "satisfactory", "unsatisfactory"）
    retry_count: int # 再試行回数（例: 検索失敗時などにインクリメント）
    # 必要に応じて、さらにツール利用履歴、思考プロセスなどの状態を追加する

# ワークフローのノードとエッジの定義は、LangGraphの公式ドキュメントやチュートリアルで詳細な実装例を確認してください。
# 一般的なノードの例:
# - Retrieve Node: 質問に基づいてドキュメントを検索する
# - Grade Node: 検索結果や生成された回答の品質を評価する（LLM-as-judgeなど）
# - Expand / Rewrite Node: 検索クエリを拡張・リライトする
# - Generate Node: 取得したドキュメントを基に回答を生成する
# - Reflect Node: 生成された回答を自己評価し、必要に応じて修正を指示する
# LangGraphのチュートリアルやサンプルコードは、atsushi3hsgw/agentic_rag_sample (GitHub) やLangGraphの公式ドキュメントで確認できます。

このAgentStateを基に、以下のような意思決定の流れを実装できます。

ユーザーからのquestionを受け取る。
Retrieve Nodeでドキュメントを検索し、documentsを更新する。
Grade Nodeでdocumentsの品質を評価し、gradeを更新する。
gradeが「不十分」であれば、Expand / Rewrite Nodeでquestionをリライトし、retry_countを増やして再度Retrieve Nodeへ戻る（ループ）。
gradeが「十分」であれば、Generate Nodeでgenerationを生成する。
最後に、Reflect Nodeでgenerationの品質を評価し、必要であれば修正指示を出す、といった流れです。

コツ2: Adaptive RAGで精度とコストのトレードオフを最適化する

Agentic RAGは高い精度をもたらしますが、その複雑性ゆえに処理コストと実行時間（レイテンシ）が増大する傾向があります。すべてのクエリにAgentic RAGを適用するのはコスト効率が悪いため、**Adaptive RAG（適応的RAG）**の導入がベストプラクティスとなります。

Adaptive RAGでは、クエリの複雑さに応じて処理パイプラインを切り替えるルーターを導入し、ユーザー体験とコストのバランスを最適化します。

シンプルな質問: Basic RAG（単一の検索と生成）
中程度の複雑さの質問: Advanced RAG（クエリの拡張、複数の検索手法の組み合わせなど）
複合的な質問: Agentic RAG（動的な意思決定、ツール利用、複数ステップの推論）

これにより、必要な精度を確保しつつ、リソースの無駄遣いを防ぐことができます。

コツ3: データ品質の最適化とチャンキング戦略

どれだけ高度なAgentic RAGシステムを構築しても、「Garbage In, Garbage Out」の原則は回避できません。高品質な入力データがなければ、適切な出力は得られません。RAGの精度向上は、「高度なRAGアーキテクチャ構築」と「高品質な入力データ整備」という二つの車輪を同時に回す作業です。

チャンキング戦略の最適化:
- 固定長のチャンク分割だけでなく、意味的に意味のある単位で分割するためにLangChainのTextSplittersツールを積極的に活用します。
- Parent Document RetrievalやWindow Extensionといった手法を導入し、ヒットした小さなチャンクだけでなく、その前後を含む大きな文脈も取得することで、情報の断片化を防ぎます。
データクレンジングと前処理: 不要な情報やノイズを除去し、LLMが理解しやすい形式にデータを整えます。
メタデータの活用: ドキュメントに付随するメタデータ（作成者、日付、カテゴリなど）を埋め込み検索に利用することで、より関連性の高い情報を絞り込むことができます。

LLM評価駆動開発（EDD）で品質を担保する3つのコツ

このセクションでは、LLMアプリの品質を継続的に向上させるためのLLM評価駆動開発（EDD）の重要性と、その実践的な3つのコツを解説します。

LLMの出力は確率的で非決定的な挙動を持つため、従来のテスト駆動開発（TDD）のような決定論的なテストだけでは品質保証が困難です。そこで重要となるのが、LLM評価駆動開発 (Eval-Driven Development: EDD) です。EDDは、システムの出力の評価（evaluation）を中心に設計、開発、改善の開発プロセスを回す手法です。

コツ1: 「測れるLLMアプリ」を先に作る

LLMアプリ開発では「動くLLMアプリ」より「測れるLLMアプリ」を先に作ることが重要です。評価基準を明確に定義し、評価ハーネス（評価を行うための仕組み）を構築してからプロンプトや実装に手を入れることで、場当たり的な試行錯誤を避け、効率的に改善サイクルを回せます。

評価には大きく3つの階層があります。

決定的チェック: 正規表現、JSONスキーマ、型チェックなど、厳密にパターンマッチできる部分。
LLM-as-judge: 別モデルにルーブリック（採点基準表）に基づいて採点させることで、人間による評価のコストを削減しつつ、意味の正しさ、トーン、指示追従、忠実性などを評価します。
人間サンプリング: 最終的な品質判断や、LLM-as-judgeでは難しいニュアンスの評価のために、人間が直接評価を行います。

コツ2: LLM-as-judgeのためのルーブリックを設計する

LLM-as-judgeを効果的に活用するためには、明確で詳細なルーブリック（採点基準）の設計が不可欠です。ルーブリックはYAMLやMarkdownで外出しにして管理し、バージョン管理を行うのが一般的です。

評価駆動開発におけるルーブリック設計の例（LLM-as-judge用）

# rubric/customer_support_v1.yaml
name: customer_support_evaluation_v1
description: 顧客サポートチャットボットの回答品質評価
criteria: # 評価基準のリスト
  - id: accuracy
    name: 回答の正確性
    description: 提供された情報が事実に基づいているか、ハルシネーションがないか
    score_range: [1, 5] # スコアの範囲
    guidance: # 各スコアに対する具体的なガイドライン
      1: 完全に不正確、または重大なハルシネーションがある
      3: 一部不正確な情報が含まれる、または曖昧な表現がある
      5: 完全に正確で、信頼できる情報源に基づいている
  - id: completeness
    name: 回答の網羅性
    description: ユーザーの質問に完全に答えているか、必要な情報が不足していないか
    score_range: [1, 5]
    guidance:
      1: 質問にほとんど答えていない、または重要な情報が欠落している
      3: 質問の大部分に答えているが、一部不足がある
      5: 質問の全てに網羅的に答えている
  - id: tone
    name: トーンと表現
    description: 顧客に対して適切で丁寧な口調であるか
    score_range: [1, 5]
    guidance:
      1: 不適切、失礼、または攻撃的なトーン
      3: 中立的だが、改善の余地がある
      5: 非常に丁寧で、共感的、かつプロフェッショナルなトーン

このルーブリックをLLMに与え、ユーザーの質問とLLMの回答、そして場合によっては正解データを比較させて採点させます。RAGASのようなフレームワークも、回答の忠実性（Faithfulness）や文脈の関連性（Context Relevance）といったRAG特有の評価指標を提供しており、自動評価に活用できます。

コツ3: 評価の自動化とCI/CDへの組み込み

評価ハーネスを作成したら、コードやプロンプト、モデルの更新を行うたびに評価をCI/CDに組み込み、反復的に実行します。これにより、以下のメリットが得られます。

回帰検出: 変更によってパフォーマンスが悪化していないかを早期に発見できます。
品質の継続的な監視: システムの品質が一定のレベルを保っているかを常に確認できます。
効率的な改善サイクル: 評価結果に基づいて具体的な改善点を特定し、次の開発サイクルへと繋げられます。

さらに、AIエージェントの挙動をリアルタイムに監視できる**可観測性（オブザーバビリティ）**ツールを導入することで、どの入力に対してどの出力が生成されたのか、どのツールが呼び出されたのかを追跡し、エラーの原因分析や改善点の特定を容易にします。

Agentic RAGと評価駆動開発におけるハマりどころと回避策

このセクションでは、Agentic RAGと評価駆動開発を導入する際によく直面する課題と、それらを効果的に回避するための具体的な戦略を解説します。

1. 検索ノイズの影響とハルシネーション

ハマりどころ: 従来のRAGでは、検索結果にノイズが混ざったり、関連性の低いドキュメントが含まれたりすると、LLMが不適切な情報を使って回答を生成し、ハルシネーションを引き起こすことがあります。また、長文のQ&Aドキュメントにおいて、固定長のチャンキングでは「意味の断片化」が発生し、質問と回答が物理的に離れている場合や回答が複数のチャンクにまたがる場合に検索が失敗することがあります。

回避策:

Agentic RAGの導入: LLMが検索結果の品質を評価し、情報が不十分な場合はWeb検索への切り替え、クエリのリライト、再検索を行うことで、ノイズの影響を軽減し、回答精度を向上させます。
Corrective RAG (CRAG) / Self-RAG: 検索結果の品質を評価する軽量な「検索評価器（Retrieval Evaluator）」をパイプラインに導入したり、LLM自身に検索と生成のプロセスを批評（Critique）させたりすることで、RAGの堅牢性を高め、ハルシネーションを抑制し、根拠整合性を高めます。
チャンキング戦略の最適化: 親ドキュメント検索（Parent Document Retrieval）やウィンドウ拡張を使用し、ヒットしたチャンクの前後を含む大きなテキストブロックを取得することで、文脈の断絶を防ぎます。また、意味的に意味のある小さなチャンクに分割するためにLangChainのTextSplittersツールを活用することも有効です。

2. 複雑な質問やマルチステップ問題への対応困難

ハマりどころ: 従来のRAGは直線的で固定的なワークフローのため、複数のドキュメントをまたぐ比較・集計が必要な複雑な質問や、複数回の反復や対話を要するマルチステップ問題に対応しきれないことがあります。

回避策:

Agentic RAGによる動的な意思決定: LLMが「どのツールを使って、どのデータを、どのような順序で取得すべきか」を自律的に判断し、必要に応じて情報取得や計算などのステップを挿入することで、複雑なクエリを分解して多角的に検索し、多段階の推論を可能にします。
LangGraphなどのフレームワークの活用: 状態管理と条件分岐、ループを組み込んだグラフベースのワークフローを構築することで、エージェントの判断と遷移を綺麗に表現できます。
Adaptive RAG (適応的RAG): すべてのクエリにAgentic RAGを適用するのはコスト効率が悪いため、クエリの複雑さに応じて処理パイプラインを切り替えるルーターを導入し、ユーザー体験とコストのバランスを最適化します。

3. LLMの出力の不確定性による品質保証の難しさ

ハマりどころ: LLMの出力は確率的で非決定的な挙動を持つため、同じ入力でも異なる出力を返すことがあり、従来のテスト駆動開発（TDD）のような決定論的なテストでは品質保証が困難です。プロンプトの変更がシステム全体のパフォーマンスにどのような影響を及ぼすかを把握しきれなくなる問題も発生します。

回避策:

評価駆動開発（EDD）の導入: 評価指標を中心に設計、開発、改善のサイクルを回すことで、LLMならではの確率的な振る舞いや自然言語による入出力の品質を継続的に評価し、改善サイクルに組み込みます。
LLM-as-judgeの活用: 別モデルにルーブリック（採点基準表）に基づいて採点させることで、人間による評価のコストを削減しつつ、意味の正しさ、トーン、指示追従、忠実性などを評価します。
評価の自動化とCI/CDへの組み込み: 評価ハーネスを先に作成し、コードやモデルの更新を行うたびに評価をCI/CDに組み込み、反復的に実行することで、回帰検出や品質の継続的な監視を可能にします。
可観測性（オブザーバビリティ）の導入: AIエージェントの挙動をリアルタイムに監視し、どの入力に対してどの出力が生成されたのかを追跡することで、エラーの原因分析や改善点の特定を容易にします。

まとめ：Agentic RAGと評価駆動開発でLLMアプリを次のレベルへ

この記事では、LLMアプリの精度と信頼性を飛躍的に向上させるための2つの重要なアプローチ、Agentic RAGと**LLM評価駆動開発（EDD）**について、その概念から具体的な実装のコツ、そしてよくあるハマりどころとその回避策までを解説しました。

Agentic RAGは、LLMを単なる生成器ではなく、自律的に思考し、ツールを使いこなすエージェントとして活用することで、従来のRAGの限界（ハルシネーション、複雑な質問への対応困難）を克服します。LangGraphのようなフレームワークを活用し、動的なワークフローを構築することが鍵となります。
**LLM評価駆動開発（EDD）**は、LLMの確率的な性質に対応するための必須プロセスです。「測れるLLMアプリ」を先に作り、LLM-as-judgeを用いた自動評価とCI/CDへの組み込みによって、品質を継続的に担保し、改善サイクルを効率的に回すことができます。

Agentic RAGは従来のRAGと比較して精度と信頼性を向上させる一方で、処理コストと実行時間（レイテンシ）が増大する傾向にあるため、Adaptive RAGを導入して、精度、コスト、レイテンシのトレードオフを最適化することが重要です。また、どれだけ高度なアーキテクチャを構築しても、高品質な入力データがなければ意味がありません。データ品質の改善とチャンキング設計の最適化は、常に優先度の高い改善策として取り組むべきです。

これらの手法を組み合わせることで、あなたのLLMアプリはより賢く、より信頼性の高いものへと進化し、ユーザーに真の価値を提供できるようになるでしょう。ぜひ、この記事で紹介した具体的なコツを参考に、ご自身のプロジェクトにAgentic RAGと評価駆動開発を導入してみてください。

さらなる詳細や最新の技術情報は、LangGraphやLlamaIndexなどの公式ドキュメント、およびProgress Agentic RAGの公式ドキュメントをご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up