社内文書検索、カスタマーサポート、FAQ自動応答——RAG（Retrieval-Augmented Generation）を使ったPoCを立ち上げた企業は多いでしょう。しかし、実際に運用を始めると必ず出てくるのが次のような声です。
「動いてはいるけど、精度が上がっているのか下がっているのか分からない」「チャンクサイズを変えたら良くなった気がするが、本当にそうなのか説明できない」「埋め込みモデルを差し替えたいが、回帰が怖くて踏み切れない」——これらはすべて、評価の仕組みが無いまま本番に入ってしまったことに起因します。
本記事では、Ragas・DeepEval・TruLens・LangSmith Evaluation といった主要ツールを使い、「とりあえず動くRAG」から「精度を継続的に改善できるRAG」へ引き上げるための評価駆動開発（Eval-Driven Development, EDD）の実践手法を整理します。指標設計、ゴールデンデータセット構築、LLM-as-a-Judgeのバイアス対策、CI/CDへの組み込み、シャドウテスト設計まで、中小企業でも現実的に回せる内容を中心にまとめました。
- 目次
- はじめに——なぜ「動くRAG」では不十分なのか
- 評価駆動開発（EDD）とは何か——テスト駆動開発との違い
- RAG特有の評価指標——5つのコア指標を正しく理解する
- Retrieval層とGeneration層を分離して評価する意味
- 主要評価ツール比較——Ragas・DeepEval・TruLens・LangSmith
- ゴールデンデータセット構築——50〜200問で始める現実解
- LLM-as-a-Judge——評価者LLMのバイアスと対策
- CI/CDへの組み込み——GitHub Actionsで回帰テストを回す
- シャドウテスト設計——本番データから継続的にテストケースを追加
- Difyの評価機能とオープンソースツールの使い分け
- よくある質問（Q&A）
- まとめ——「測れなければ改善できない」
- 参考リンク
目次
- はじめに——なぜ「動くRAG」では不十分なのか
- 評価駆動開発（EDD）とは何か——テスト駆動開発との違い
- RAG特有の評価指標——5つのコア指標を正しく理解する
- Context Precision（検索精度）
- Context Recall（検索再現率）
- Faithfulness（忠実性）
- Answer Relevancy（回答関連性）
- Noise Sensitivity（ノイズ耐性）
- Retrieval層とGeneration層を分離して評価する意味
- 主要評価ツール比較——Ragas・DeepEval・TruLens・LangSmith
- ゴールデンデータセット構築——50〜200問で始める現実解
- 設計の4原則
- 質問カテゴリの分類
- 合成データ生成と人手レビューの組み合わせ
- LLM-as-a-Judge——評価者LLMのバイアスと対策
- CI/CDへの組み込み——GitHub Actionsで回帰テストを回す
- シャドウテスト設計——本番データから継続的にテストケースを追加
- Difyの評価機能とオープンソースツールの使い分け
- よくある質問（Q&A）
- まとめ——「測れなければ改善できない」
- 参考リンク
はじめに——なぜ「動くRAG」では不十分なのか
RAGは仕組みとしては比較的シンプルです。ドキュメントをチャンクに分割し、埋め込みベクトル化し、ユーザーの質問に類似したチャンクを検索して、そのコンテキストをLLMに渡す——この流れを実装するだけなら、LangChainやLlamaIndexを使えば数時間で動くものが作れます。
問題はその先です。PoCで「動いた」状態から本番運用に入ると、必ず次のような改善ニーズが出てきます。
- 埋め込みモデルを OpenAI から multilingual-e5 に変えたい
- チャンクサイズを 500 → 800 トークンに変えたい
- プロンプトに「参考にした部分を必ず引用せよ」を追加したい
- ハイブリッド検索（BM25＋ベクトル）に切り替えたい
- リランカーを導入したい
これらの変更は個別には「良さそう」に見えます。しかし評価の仕組みがないと、「良くなった」「悪くなった」を数値で判断できないため、担当者の感覚や、目立つ数件の出力例に頼った意思決定になります。結果として、ある質問は改善するが別の質問は悪化する、という「もぐら叩き」に陥ります。
この停滞から抜け出す唯一の方法が、評価駆動開発（EDD）です。
評価駆動開発（EDD）とは何か——テスト駆動開発との違い
評価駆動開発は、ソフトウェア工学のテスト駆動開発（TDD）の考え方をLLMアプリケーション開発に応用したものです。
| 観点 | テスト駆動開発（TDD） | 評価駆動開発（EDD） |
|---|---|---|
| 対象 | 決定的なロジック（関数・API） | 確率的な出力（LLM・RAG） |
| 合否判定 | 二値（Pass / Fail） | スコア（0.0〜1.0） |
| テストデータ | 単体テストケース | ゴールデンデータセット |
| 判定者 | アサーション（等価比較） | 指標関数 or LLM-as-a-Judge |
| CI/CD連携 | 全テスト Pass で merge | スコア閾値 or 回帰なしで merge |
EDDの要点は3つです。
1. 変更の前に評価する。 プロンプト、埋め込みモデル、チャンクサイズを変更する「前」にベースラインのスコアを取り、変更後と比較します。
2. スコアで意思決定する。 「なんとなく良さそう」ではなく、「Context Recallが 0.72 → 0.78 に改善し、Faithfulnessに回帰は無い」という形で判断します。
3. 継続的に回す。 一度きりの評価ではなく、CI/CDに組み込んで全コミットで回帰テストを実行します。
RAG特有の評価指標——5つのコア指標を正しく理解する
RAGの評価指標は LLM 単体の評価指標とは異なる視点が必要です。RAGは「検索（Retrieval）」と「生成（Generation）」という2つの処理の連鎖で成り立っているため、どちらの層に問題があるのかを切り分けられる指標が求められます。
ここでは Ragas フレームワークで広く使われている5つのコア指標を取り上げます。
Context Precision（検索精度）
検索されたチャンクのうち、質問の回答に本当に関連するものの割合を測る指標です。関連する情報が上位に来ているほどスコアが高くなります。
スコアが低い場合、検索層で「ノイズ（無関係なチャンク）」を拾いすぎていることを意味します。対策は、ハイブリッド検索の導入、リランカーの追加、チャンクサイズの調整などです。
Context Recall（検索再現率）
正解となる情報（グラウンドトゥルース）のうち、検索されたチャンクでどれだけカバーできているかを測る指標です。必要な情報を取り逃していないかの指標と言えます。
スコアが低い場合、検索層で「取りこぼし」が発生しています。対策は、検索件数（top-k）の増加、埋め込みモデルの変更、Multi-Query検索の導入などです。
Faithfulness（忠実性）
生成された回答が、検索されたコンテキストに忠実かを測る指標です。LLMが勝手に情報を足したり（ハルシネーション）、コンテキストと矛盾することを言ったりしていないかをチェックします。
スコアが低い場合、生成層のプロンプト設計に問題があります。「コンテキストに無い情報は答えない」「推測で補わない」といった指示の強化、temperature の引き下げ、モデルの変更などが対策になります。
Answer Relevancy（回答関連性）
生成された回答が、元の質問に対してどれだけ的を射ているかを測る指標です。Faithfulness が高くても、「質問と噛み合わない長い説明」をしていればこのスコアは下がります。
スコアが低い場合、プロンプトに「簡潔に答える」「質問に直接答える」という指示を強化するか、chain-of-thought の過剰な思考を抑制します。
Noise Sensitivity（ノイズ耐性）
検索結果に無関係なチャンクが混入した場合に、回答がどれだけ影響を受けるかを測る指標です。Ragas の比較的新しい指標で、実運用では top-k を上げると必ず混入するノイズへの堅牢性を評価します。
スコアが低い場合、リランカーの導入やプロンプトでの「関連性の低い情報は無視せよ」という明示が有効です。
Retrieval層とGeneration層を分離して評価する意味
RAGで最もよくある落とし穴が、「総合スコアだけ見て改善する」ことです。最終的な回答の品質（Answer Relevancy）だけを追うと、原因が検索層にあるのか生成層にあるのかが分からず、無関係な場所を修正してしまいます。
| 症状 | 原因となる層 | 関連指標 | 典型的な対策 |
|---|---|---|---|
| 回答が質問とズレている | 生成層 | Answer Relevancy ↓ | プロンプト改善 |
| 回答が事実と違う | 生成層 | Faithfulness ↓ | プロンプト強化・モデル変更 |
| 「分かりません」が多い | 検索層 | Context Recall ↓ | top-k 増・埋め込み改善 |
| 関係ない情報で答える | 検索層 | Context Precision ↓ | リランカー・ハイブリッド検索 |
| 質問を変えると品質がバラつく | 両方 | Noise Sensitivity ↓ | リランカー・プロンプト明示 |
この切り分けができるようになることが、評価駆動開発の最初のマイルストーンです。
主要評価ツール比較——Ragas・DeepEval・TruLens・LangSmith
RAG評価の主要ツールを比較します。いずれもPythonから利用でき、LangChain や LlamaIndex と統合可能です。
| ツール | 特徴 | 強み | 向くユースケース |
|---|---|---|---|
| Ragas | RAG特化のOSS評価ライブラリ | RAG特有の指標が豊富・合成データ生成機能 | RAG精度を体系的に測りたい中小企業 |
| DeepEval | pytest風の書き味 | ユニットテスト感覚で書ける・CI/CD親和性が高い | エンジニアリング文化のあるチーム |
| TruLens | トレーシングと評価の統合 | 各ステップの可視化が強い・デバッグ向き | 複雑なエージェント型RAGの内部分析 |
| LangSmith Evaluation | LangChain公式のマネージドサービス | トレース・評価・データセット管理が一体化 | LangChain本番運用中のチーム |
選定の考え方： 中小企業で「これから評価を始める」なら、まず Ragas で指標を定義しゴールデンデータセットを作り、CI/CD組み込みの段階で DeepEval を足す、という組み合わせが現実的です。LangChain をフル活用しているチームは LangSmith、複雑なエージェント型の内部を追う必要があるなら TruLens、という住み分けになります。
Ragas の最小実装例
from ragas import evaluate
from ragas.metrics import (
context_precision,
context_recall,
faithfulness,
answer_relevancy,
)
from datasets import Dataset
# ゴールデンデータセット（質問・正解・RAGが返したコンテキストと回答）
data = {
"question": ["返品ポリシーを教えて"],
"contexts": [["弊社の返品は購入から30日以内であれば可能です。..."]],
"answer": ["30日以内であれば返品可能です。"],
"ground_truth": ["購入から30日以内の返品が可能"],
}
dataset = Dataset.from_dict(data)
result = evaluate(
dataset,
metrics=[context_precision, context_recall, faithfulness, answer_relevancy],
)
print(result)ゴールデンデータセット構築——50〜200問で始める現実解
評価駆動開発の成否を決めるのは、どのツールを使うかよりも「ゴールデンデータセット」の質です。「正しい質問・コンテキスト・理想の回答」のセットがなければ、どのツールを使っても意味のある評価はできません。
「1000問規模が必要」と誤解されがちですが、中小企業の業務RAGなら50〜200問で十分に有用な評価ができます。むしろ少数でも品質の高いデータセットを作るほうが、大量の粗いデータセットより改善サイクルが回しやすくなります。
設計の4原則
1. 業務の実分布を反映する。 実際にユーザーが問い合わせる質問の分布に合わせます。FAQ の上位20問ばかりではなく、エッジケースも含めます。
2. 難易度を段階化する。 「1つのチャンクで答えられる簡単な質問」「複数のチャンクを統合する必要がある質問」「答えが存在しない質問（Don’t know問題）」の3レベルを混ぜます。
3. 正解を明示する。 理想の回答（ground_truth）と、回答に必要なチャンクの出典を人手で明示します。これが無いと Context Recall が測れません。
4. 継続的に育てる。 一度作って終わりではなく、本番で見つかった失敗ケースをテストケースとして加えていきます（後述のシャドウテスト）。
質問カテゴリの分類
| カテゴリ | 例 | 測れるもの | 目安比率 |
|---|---|---|---|
| 単一チャンク回答 | 「営業時間は？」 | 基本的な検索・生成精度 | 40% |
| 複数チャンク統合 | 「返品と交換の違いは？」 | Multi-hop な推論能力 | 25% |
| 条件付き質問 | 「法人契約で返品したい場合は？」 | 条件分岐と特化情報の検索 | 15% |
| 言い換え・口語表現 | 「返すことってできる？」 | 表記ゆれへの耐性 | 10% |
| Don’t know（回答不能） | 「競合A社の営業時間は？」 | ハルシネーション耐性 | 10% |
合成データ生成と人手レビューの組み合わせ
ゼロから200問を人力で作るのは負担が大きいため、次のハイブリッドが現実的です。
- Ragas の
TestsetGeneratorや Claude Opus / GPT-5 で、ドキュメントから質問と回答を合成生成する（目標数の1.5〜2倍） - 人手で不自然な質問の除去・正解の検証・難易度バランスの調整を行う
- Don’t know 問題を人手で追加（合成だと生成されにくい）
- 業務担当者（エンドユーザー側）に10〜20問だけレビューを依頼し、実分布との乖離を修正
この手順なら、2〜3日の稼働で100問規模のゴールデンデータセットが作れます。
LLM-as-a-Judge——評価者LLMのバイアスと対策
Faithfulness や Answer Relevancy のような指標は、計算式だけでは算出できないため、評価者としてLLMを使う「LLM-as-a-Judge」が主流です。GPT-5 や Claude Opus 4.6 に「この回答はコンテキストに忠実か？」を判定させる方式です。
便利な一方で、LLM-as-a-Judge には以下の既知のバイアスがあり、対策が必要です。
| バイアス | 内容 | 対策 |
|---|---|---|
| 位置バイアス（Position Bias） | ペア比較で最初に提示された回答を好む傾向 | 提示順序をランダム化、両方向で評価し平均 |
| 冗長性バイアス（Verbosity Bias） | 長い回答を「詳しい」と高評価しがち | 評価プロンプトで「長さではなく正確性」と明示 |
| 自己選好バイアス（Self-preference） | 評価者LLMが自身のスタイルに近い出力を好む | 生成モデルと評価モデルを別ベンダーにする |
| 単調スコアリング | 中央値（3 / 5点）ばかり付ける | 二値判定（Yes / No）や Chain-of-Thought を併用 |
実務上の鉄則： 生成に使うLLMと評価に使うLLMは必ず別ベンダーにします。Claudeで生成してClaudeで評価すると、自己選好バイアスで甘い評価になります。生成がClaude、評価がGPT-5（またはその逆）という組み合わせが安全です。
さらに、月に1回程度は人手評価とLLM評価のアライメント（一致率）を測ると、LLM評価のドリフトを早期に検知できます。100問中20問程度を人手でスコア付けし、LLM評価との相関が低下していれば、評価プロンプトを見直します。
CI/CDへの組み込み——GitHub Actionsで回帰テストを回す
評価は「一度実行して終わり」では意味がありません。埋め込みモデル変更・プロンプト変更・チャンクサイズ変更のたびに自動で回帰テストを回すことで初めて改善サイクルが閉じます。
GitHub Actions ワークフローの例
name: RAG Evaluation
on:
pull_request:
paths:
- 'rag/**'
- 'prompts/**'
- 'configs/**'
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run RAG evaluation
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: python scripts/evaluate_rag.py --dataset golden_set.json --output results.json
- name: Compare with baseline
run: python scripts/compare_baseline.py --current results.json --baseline baseline.json --threshold 0.02
- name: Comment results on PR
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const report = fs.readFileSync('report.md', 'utf8');
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.name,
body: report
});閾値設計のポイント
絶対値ではなく相対値で見る。 「Faithfulness 0.85 以上」という絶対閾値よりも、「ベースラインから -0.02 以上の低下はブロック」という相対閾値のほうが実用的です。絶対閾値は作業者が麻痺しやすく、不安定なためです。
指標ごとに閾値を分ける。 Faithfulness の低下は致命的なので厳しめ（-0.01 でブロック）、Context Precision は -0.03 まで許容、のように重要度で使い分けます。
警告と失敗を分ける。 軽度の低下は CI を失敗させずコメントのみ、致命的な低下は merge をブロック、という2段階にすると運用が回りやすくなります。
シャドウテスト設計——本番データから継続的にテストケースを追加
ゴールデンデータセットは作った時点が最高の状態ではなく、本番で見つかる失敗ケースを吸収して育てていくものです。そのための仕組みがシャドウテストです。
シャドウテストの基本フロー
- 本番ログの蓄積： 本番RAGのクエリ・検索されたチャンク・回答・ユーザーフィードバック（Good / Bad）をログに残す
- 失敗ケースの収集： Bad評価 or 低信頼度スコア or 「分かりません」回答を週次で抽出
- テストケース化： 失敗ケースから質問を取り出し、正解をドキュメント担当者が記述してゴールデンデータセットに追加
- 回帰テスト： 次のリリースで「過去に失敗したケースが再度失敗しないか」を確認
シャドウテストで検知しやすい問題
| 問題 | 発見シグナル | 対応 |
|---|---|---|
| 新ドキュメントの追加で既存質問が悪化 | 既存テストのスコア低下 | チャンク戦略の見直し |
| ユーザーの表現が想定と違う | 類似質問で検索結果が不安定 | 言い換えパターンをデータセットに追加 |
| ドキュメント内の矛盾 | Faithfulness の散発的低下 | ドキュメントのクレンジング |
| LLMのバージョンアップで挙動変化 | 同一入力で出力が変わる | プロンプトの再チューニング |
シャドウテストを導入すると、ゴールデンデータセットは月あたり10〜30問のペースで自然に育ちます。半年運用すれば、作成時の初期100問が300〜280問規模になり、評価の信頼性が大きく向上します。
Difyの評価機能とオープンソースツールの使い分け
ノーコード／ローコードでRAGを作れる Dify にも評価機能が組み込まれています。オープンソースの評価ツールと競合するように見えますが、役割は明確に分かれます。
| 観点 | Dify の評価機能 | Ragas / DeepEval など OSS ツール |
|---|---|---|
| 利用者 | 業務担当者・非エンジニア | エンジニア |
| 評価タイミング | GUI での手動実行 or 定期実行 | CI/CD 自動実行 |
| データセット管理 | Dify 内で完結 | Git管理・バージョン管理可能 |
| 指標のカスタマイズ | 限定的（提供指標の中から選択） | 完全カスタマイズ可能 |
| 大規模回帰テスト | 不向き | 得意 |
おすすめの使い分け： プロトタイピング段階や業務担当者による定性チェックは Dify の評価機能で回し、エンジニア主導の継続的改善と CI/CD 連携は Ragas/DeepEval で回す、という二段構えが効率的です。「定性は Dify、定量は OSS ツール」と役割分担すると、両者の強みを活かせます。
よくある質問（Q&A）
Q1. ゴールデンデータセットは何問あればいいですか？
業務RAGのPoCなら50問、本番運用なら100〜200問が現実的な目安です。1000問規模は本格的なプロダクトで継続改善を重ねた結果として到達するもので、最初から目指す必要はありません。それよりも「質問分布が実運用を反映しているか」「正解が明確に定義されているか」が重要です。
Q2. 評価に使うLLMのコストが気になります。安く抑える方法は？
3つのアプローチがあります。まず、毎PR全件ではなく差分のみ評価する（変更された埋め込み・プロンプトに関連する質問サブセットのみ実行）。次に、評価用にGPT-5 miniやClaude Haiku 4.5など軽量モデルを使う（Faithfulnessは軽量モデルでも精度が出やすい）。最後に、夜間バッチ／週次バッチで全件評価し、PR時は軽量な部分評価のみとする二段構えです。
Q3. 人手評価は完全に不要ですか？
不要ではありません。月1回程度、ゴールデンデータセットの10〜20%を人手で評価し、LLM評価との一致率（アライメント）を確認することが推奨されます。一致率が下がっている場合は評価プロンプトの見直しか、LLM評価者のバージョン変更を検討します。
Q4. LangSmith・Ragas・DeepEval のどれを選べばいいですか？
チームの構成と使用中のフレームワークで決めます。LangChain を本番で使っていて有料枠が問題にならないなら LangSmith の一体感が強力です。OSS 志向・自前運用志向なら Ragas（RAG特化・指標が豊富）＋ DeepEval（CI/CD組み込み）の組み合わせが汎用的です。Ragas だけでも始められます。
Q5. ベクトルDBや埋め込みモデルを変更するとき、どう評価を回せばいいですか？
機能ブランチで変更後の設定に切り替え、ゴールデンデータセットで全件評価します。Context Precision と Context Recall が主要な観察指標です。Faithfulness や Answer Relevancy も副次的に動くので、同時に回帰を確認します。重要なのは「1つだけ変える」こと——埋め込みモデルとチャンクサイズを同時に変えると、改善・悪化の原因切り分けができなくなります。
まとめ——「測れなければ改善できない」
RAGの PoC フェーズから本番運用への移行で最大の壁は、技術ではなく「評価の仕組み」です。評価がないままチューニングを続けると、改善と悪化の判別がつかず、担当者の感覚に依存した属人的な運用に陥ります。
今日から始められるステップは以下の5つです。
1. 50問のゴールデンデータセットを作る。 業務担当者と協力して、実際の質問分布を反映した質問・正解・難易度バランスを設計します。
2. Ragas で5つのコア指標を計測する。 Context Precision / Recall / Faithfulness / Answer Relevancy / Noise Sensitivity で現状のベースラインを取ります。
3. 生成LLMと評価LLMを別ベンダーにする。 自己選好バイアスを避けるための最小の工夫です。
4. CI/CD に組み込む。 GitHub Actions で PR ごとに評価を回し、ベースラインからの低下をブロック条件にします。
5. 本番ログからシャドウテストを育てる。 週次で失敗ケースをデータセットに追加し、テストの網羅性を高めます。
「とりあえず動くRAG」と「継続的に改善できるRAG」を分けるのは、モデルやインフラではなく、評価を中心に据えた開発サイクルです。評価駆動開発を回せるチームは、埋め込みモデルの新製品が出ても、LLMのバージョンが上がっても、自信を持って切り替えられます。それが RAG をビジネスで長期運用するための基礎体力になります。
参考リンク
- Ragas 公式ドキュメント
- DeepEval（GitHub）
- TruLens 公式サイト
- LangSmith Evaluation ドキュメント
- Ragas 論文「Ragas: Automated Evaluation of Retrieval Augmented Generation」
- Dify 公式ドキュメント
- 関連記事：ローカルRAG構築ガイド（ID 523）
- 関連記事：本番チャットボット運用ガイド（ID 639）
免責事項： 本記事は2026年4月時点の公開情報に基づく情報提供であり、特定のツール・サービスを推奨するものではありません。本記事で紹介した指標値・手法は一般的な目安であり、実際の業務RAGの品質保証を保証するものではありません。導入にあたっては、業務要件・コスト・セキュリティ要件に応じて、必要に応じて専門家にご相談ください。RAG評価ツールは急速に進化しているため、最新情報は各公式ソースで確認してください。
コメント