Eval-Driven Development（EDD）とは？評価ファーストで作るAI開発プロセス

Eval-Driven Development（EDD）とは、評価指標の設計を AI 開発の起点に置き、継続的な評価サイクルによってモデルとプロダクトの品質を担保する開発手法です。

LLM（大規模言語モデル）を使ったアプリケーション開発では、「動いているように見えるが品質が測れていない」という状態に陥りやすい傾向があります。EDD はこの課題に対し、ハルシネーション検出・回答品質・安全性といった多角的な評価基準を実装前に定義することで、エンジニアとビジネス担当者が共通の品質基準を持ちながら開発を進められる仕組みを提供します。

本記事は、LLM アプリケーションの開発・運用に携わるエンジニアやプロダクトマネージャーを対象としています。

結論: EDD はテスト駆動開発の思想を LLM 開発に転用した手法であり、評価指標を開発の起点に置くことで品質を継続的に担保できる。

TDD と EDD の共通点・相違点、LLM 特有のテスト困難性、そして「評価なき開発」が引き起こす課題を順に整理します。

TDD（テスト駆動開発）と EDD は、どちらも「実装より先に品質基準を定義する」という思想を共有しています。TDD がコードを書く前にユニットテストを書くように、EDD は LLM アプリケーションを構築する前に評価指標と評価データセットを用意します。

共通点の整理:

• 品質基準を先に定義し、実装がその基準を満たすまで改善を繰り返す
• 失敗ケース（テスト失敗 / 評価スコアの低下）を開発サイクルの出発点にする
• 継続的インテグレーションと組み合わせることで、回帰を早期に検知できる

最初は「TDD の考え方をそのまま LLM 開発に適用すれば十分」と考えがちですが、実際には決定論的なコードテストと確率論的な LLM 出力では、品質検証の仕組みを根本から変える必要があります。

相違点の核心:

TDD では「テストが通るかどうか」を問いますが、EDD では「回答の正確さが閾値を超えているか」を問います。MLflow の評価例では correctness/mean が 0.

従来のソフトウェア開発では、「入力 A を与えたら出力 B が返る」という決定論的なテストが成立します。ところが LLM を使ったアプリケーションでは、この前提がそもそも崩れています。同じプロンプトを渡しても、温度パラメータや内部サンプリングによって毎回異なるテキストが生成されるため、完全一致による合否判定が機能しません。単体テストや E2E テストの枠組みをそのまま持ち込もうとすると、すぐに壁にぶつかります。

難しさはそれだけではありません。「良い回答」の定義がドメインや用途によってまったく異なるため、品質を単一の数値で表すことが難しく、ハルシネーションは流暢な文体で紛れ込むので表面的な文法チェックでは検出できません。さらに、与える文脈の長さや順序が変わるだけで回答品質が大きく変動するという、コンテキストウィンドウへの依存という問題もあります。

こうした特性を前にすると、「動いているように見える」という感覚的な確認だけでは品質保証が成立しないことがわかります。

ただし、何を重視すべきかは用途によって変わります。法務・医療・財務のように出力の正確性が最優先される業務用途では、グラウンディングチェックや事実整合性の定量評価を中心に据える必要があります。一方、クリエイティブ生成や対話用途であれば、流暢さ・多様性・ユーザー満足度といった定性評価の比重を高めるべきです。

評価駆動開発（EDD）が必要とされる背景には、こうした「テストできない」状態のまま本番リリースが行われるリスクがあります。

「プロンプトを変えたら改善したように見えるが、本当に良くなっているのかどうか判断できない」——そう感じた経験のある開発者は少なくないはずです。評価なき開発では、改善の根拠が主観や印象に依存してしまい、品質の変化を客観的に追跡できません。

具体的にどんな問題が起きるか、少し想像してみてください。プロンプトを書き換えるたびに「なんとなく良くなった気がする」という感覚が判断基準になれば、以前は正しく動いていた挙動がいつの間にか壊れていても気づけません。チームメンバーが増えるほど「品質が良い」の定義がバラバラになり、改善サイクルは属人化していきます。さらに、技術的な動作確認に終始するうちに、ユーザーが実際に求める回答品質とのギャップは静かに広がっていきます。

EDDはこれらの課題に対し、評価指標を開発サイクルの起点に置くことで対処します。具体的には、開発着手前に「何をもって成功とするか」の基準を定義し、すべての変更をその基準で計測するフローを組み込みます。MLflowの評価ワークフローでは、ベースライン計測値（例: correctness/mean = 0.2）と改善後の計測値（例: correctness/mean = 1.0）を比較することで、変更の効果を定量的に確認できます。

さらにEDDは、エンジニアだけでなくビジネス担当者も評価基準の議論に参加できる構造を持ちます。評価指標を事前に合意することで、「技術的には動いているが、ビジネス的には使えない」という典型的なすれ違いを防ぎやすくなります。

評価設計を先行させるといっても、土台なしには評価ループは回りません。まず「何を評価するのか」が曖昧なまま指標だけ用意しても、計測結果が改善の手がかりにならないことが多いです。アプリケーションの種類・ゴールデンデータセット・MLOps基盤の三点を順に確認しておくことが、EDDを実際に機能させるための前提条件になります。

EDD を導入する前に、まず「何を評価するのか」を明確にする必要があります。LLM アプリケーションは用途によって評価すべき特性が大きく異なるため、アプリケーションの種類を先に整理することが出発点になります。

最初は「どのアプリにも同じ評価指標を当てればよい」と考えがちですが、実際にはアプリケーションの特性に合わせた評価設計のほうが、後工程での手戻りを大幅に減らせます。

主な LLM アプリケーションの種類と、それぞれが持つ評価上の特性は以下のとおりです。

• Q&A・チャットボット: 回答の正確性・ハルシネーション率・応答速度が主要指標。ゴールデンデータセットとの一致度を定量評価しやすい
• RAG（検索拡張生成）パイプライン: 検索品質（Retrieval）と生成品質（Generation）を分離して評価する必要がある。

評価の精度はデータの質に直結するため、ゴールデンデータセットの設計は EDD の成否を左右する最初の関門です。

ゴールデンデータセットとは、正解ラベル付きの入出力ペアを集めたもので、評価指標の基準点となります。準備方針は大きく二段階に分かれます。

実データが十分にある場合は実データを優先し、ない場合は合成データで補完するという判断軸が基本です。具体的には、本番ログや QA 履歴が 100 件以上確保できる場合は実データを中心に構築し、ドメイン専門家がラベルを付与します。一方、ローンチ前の PoC 段階や希少ケースのカバレッジが不足する場合は、LLM を活用した合成データで不足分を補う方法が有効です。

合成データを作成する際の留意点を以下に整理します。

• 多様性の担保: 同一パターンの言い換えだけでなく、難易度・ドメイン・長さのバリエーションを意図的に設計する
• 品質フィルタリング: 生成後に人手またはルールベースで明らかな誤りや重複を除去する
• 実データとの比率管理: 合成データが大半を占めると評価が現実の利用パターンから乖離するリスクがあるため、比率を記録して管理する

また、ゴールデンデータセットは一度作成して終わりではありません。ユーザーの利用パターンや要件の変化に合わせて定期的に更新しないと、評価スコアが高くても実運用品質が低下するという乖離が生じます。更新サイクルの目安をあらかじめ決めておくことが重要です。

「評価スクリプトは書いたのに、どこに結果を蓄積すればいいのか分からない」——EDD を始めようとした現場でよく聞かれる問いです。評価を継続的なサイクルとして回すには、評価結果を記録・比較できる MLOps 基盤と、推論時の挙動を可視化する AIオブザーバビリティ（AI Observability）の両輪が不可欠です。

整備すべき要素は大きく三つに分かれます。

① 実験トラッキング MLflow などの実験管理ツールを導入し、プロンプトのバージョン・パラメータ・評価スコアを一元管理します。MLflow の Evaluation Datasets 機能は PostgreSQL・MySQL・SQLite・MSSQL のいずれかの SQL バックエンドを必要とするため、事前にデータベース環境を確認してください。

② パイプラインのバージョン管理 プロンプト、RAG（Retrieval-Augmented Generation）のチャンクサイズ、モデル設定をコードと同様に Git で管理します。「どの変更が評価スコアを動かしたか」をトレースできる状態を維持することが目的です。

③ オブザーバビリティの組み込み 本番環境では、レイテンシ・トークン消費量・ハルシネーション（Hallucination）発生率などをリアルタイムで収集します。収集したログを評価データセットへフィードバックする仕組みを持つことで、評価と運用が断絶せずつながります。

結論: EDD は「評価指標の定義 → テストケース作成 → ハーネス実装 → ベースライン計測 → 改善 → 継続ループ」の 6 ステップで回す。

評価設計から継続的な改善サイクルまで、各ステップの役割と順序を正しく理解することが EDD 実践の鍵です。以下の H3 で各フェーズを順に解説します。

EDD の最初の落とし穴は、「とりあえず動くものを作ってから評価を考える」という進め方です。実際には、評価指標を後付けしようとすると何を測ればよいか定まらず、改善の方向性が曖昧になりがちです。評価指標とテストケースを先に決めることが、開発全体の羅針盤になります。

Step 1：評価指標の定義

まず、プロダクトのゴールを「測定可能な指標」に分解します。指標の選び方は用途によって異なります。

• 正確性（Correctness）: 回答が事実と一致しているか。RAG（Retrieval-Augmented Generation）システムでは特に重要
• グラウンディング（Grounding）: 回答が参照ソースに根拠を持つか
• 安全性: 有害・不適切な出力が含まれないか
• レイテンシ: 応答時間がユーザー体験の許容範囲内か

指標は 3〜5 個に絞ることが推奨されます。多すぎると優先度が拡散し、改善の意思決定が遅くなります。MLflow の評価例では correctness/mean をベースライン指標として一元管理するアプローチが示されており、まず 1 つの主要指標を定めることが出発点として有効です。

Step 2：テストケースの作成

指標が決まったら、それを検証するテストケースを用意します。

• ゴールデンデータセット: 期待する入力と正解出力のペアを人手で作成する。

評価ハーネスとは、テストケースをモデルに一括投入し、結果を自動収集・集計する実行基盤です。ハーネスエンジニアリング（Harness Engineering）の観点では、再現性と自動化の二点が設計の核になります。

ハーネス実装の基本構成

• 入力ローダー: ゴールデンデータセットを読み込み、プロンプトテンプレートと結合する
• 実行レイヤー: LLM API を呼び出し、レスポンスをログとして保存する
• 評価レイヤー: 定義済みの指標（正確性・安全性など）でスコアを算出する
• 集計・可視化: 指標ごとの平均値やパスレートをダッシュボードに出力する

MLflow を例に挙げると、mlflow.evaluate() を呼び出すだけでこの一連のフローを実行できます。リサーチノートに示された実測値では、ベースライン時点の correctness/mean が 0.2 という低水準から始まるケースも報告されており、改善前の現状を数値で把握することがいかに重要かがわかります。

ベースライン計測の判断軸

プロジェクトが PoC 段階であれば、まず単一指標（例: 正確性スコア）だけを計測してベースラインを確定させるのが現実的です。一方、本番リリース後の継続改善フェーズであれば、安全性・レイテンシ・コストを含む複数指標を並行計測し、トレードオフを可視化することが求められます。

「スコアが上がらないのは、プロンプトが悪いのか、それともデータの問題なのか」——現場でよく直面するこの問いに、EDD は評価ループを通じて答えを与えます。

Step 5 では、ベースライン計測の結果をもとにプロンプトエンジニアリングを実施します。改善の優先順位は以下の順で検討するのが一般的です。

• システムプロンプトの構造化: 役割・制約・出力フォーマットを明示し、ハルシネーション率の低下を狙う
• Few-shot 例の差し替え: ゴールデンデータセットから代表例を選び、CoT（思考連鎖）形式で提示する
• チェーン分割: 複雑なタスクを複数ステップに分解し、各ステップで評価スコアを計測する

プロンプト変更のたびに評価ハーネスを実行し、スコアの変化を MLflow 等のトラッキングツールに記録します。MLflow の評価例では、ベースラインの correctness/mean が 0.2 だった指標が、プロンプト改善後に 1.0 まで改善したケースが示されています。

プロンプト改善で頭打ちになった場合に初めて Step 6 のファインチューニングを検討します。LoRA や QLoRA を用いた PEFT（パラメータ効率型ファインチューニング）を活用すると、計算コストを抑えながらモデルをタスクに適応させることができます（詳細は

結論: LLM 評価指標は「何を改善したいか」によって定量・定性を使い分けることが品質向上の鍵になります。

評価指標の選定は EDD サイクルの精度を左右します。テキスト品質・安全性・ユーザー満足度など目的の異なる指標を正しく組み合わせることで、改善の方向性が明確になります。

安全性指標は、LLM アプリケーションの信頼性を左右する最も優先度の高い評価軸です。

最初は「回答が流暢かどうか」を品質の代理指標として使いがちですが、実際には流暢さとファクトの正確さはほぼ独立しており、流暢な誤答ほど見逃されやすい傾向があります。安全性評価を先に設計することが、EDDの「評価ファースト」原則の核心です。

代表的な安全性指標は以下の通りです。

• ハルシネーション検出: モデルの出力が、与えられたコンテキストや既知の事実と矛盾していないかを判定します。RAG（Retrieval-Augmented Generation）構成では、検索結果に含まれない情報を断定的に述べていないかを確認します
• グラウンディングチェック（Grounding Check）: 出力の各クレームがソースドキュメントに根拠を持つかをスコアリングします。

BLEU や ROUGE は、機械翻訳・要約タスクで長年使われてきた参照ベースの定量指標です。正解テキスト（参照文）との n-gram 一致率を計算するため、スコアの算出が高速で再現性があり、CI/CD パイプラインへの組み込みが容易という利点があります。

主な指標の特性を整理すると次のとおりです。

• BLEU（Bilingual Evaluation Understudy）: 生成文が参照文の n-gram をどれだけ含むかを精度側から測る。翻訳品質の評価に向く
• ROUGE-N: 参照文の n-gram が生成文に再現されている割合（再現率）を測る。要約の網羅性評価に向く
• ROUGE-L: 最長共通部分列（LCS）をベースにするため、語順のズレにも対応できる

ただし、これらの指標は「参照文との表面的な一致」しか測れないという限界があります。LLM が参照文とは異なる言い回しで正確な情報を返した場合でも、スコアが低く出るケースが報告されています。

判断軸として重要なのは、タスクの性質です。 翻訳・要約のように「正解テキストが一意に定まる」タスクでは BLEU/ROUGE が有効な基準になります。一方、チャットボットの応答生成や RAG の回答合成のように「正解の表現が多様」なタスクでは、次のセクションで解説する LLM-as-a-Judge などの定性評価と組み合わせることが推奨されます。

「回答のトーンや文脈への適切さをどうスコア化すればいいのか」——この問いは、LLM アプリケーション開発の現場で繰り返し聞かれます。BLEU や ROUGE のような字句一致指標では捉えられない定性的な品質を、人手レビューなしに評価する手段として注目されているのが LLM-as-a-Judge アプローチです。

LLM-as-a-Judge とは、別の LLM（評価モデル）が生成結果を採点する手法です。評価モデルにルーブリック（採点基準）と評価対象テキストを渡し、スコアと根拠を返させます。主な評価軸は次のとおりです。

• 正確性（Correctness）: 事実と一致しているか
• 関連性（Relevance）: ユーザーの意図に沿っているか
• 流暢さ（Fluency）: 自然な文体で書かれているか
• 安全性（Safety）: 有害・不適切な表現を含まないか

MLflow の評価フレームワークでは、この仕組みを組み込みの評価メトリクスとして利用でき、correctness/mean のような集計値を実験トラッキングと連携させることが可能です。

実践上の注意点は以下の 2 点です。

結論: EDD の導入で陥りやすい失敗は、指標設計・データ管理・フィードバック連携の三点に集中する。各パターンを事前に把握し、回避策を講じることが継続的な品質改善の鍵となります。

評価指標を網羅しようとするあまり、10種類以上の指標を並べて「どれが下がっても問題」と定義してしまうチームは少なくありません。最初は「多角的に評価するほど安全」と考えがちですが、実際は3〜5個の核心指標に絞り込むほうが改善サイクルが速く回ります。

指標が多すぎると、問題が連鎖的に発生します。たとえば指標Aが改善し指標Bが悪化した場合、どちらを優先すべきか合意できず判断が止まります。全指標の評価ハーネスを維持するだけでエンジニアリングリソースが枯渇しますし、ビジネス担当者にとって意味が見えにくい指標が増えると、評価結果が意思決定に使われなくなっていきます。

回避策として有効なのは、指標を「北極星指標（North Star Metric）」と「診断指標」の2層に分けるアプローチです。北極星指標は開発判断の最終基準となる1〜2個に絞り、correctnessスコアやタスク完了率がその典型です。診断指標はあくまで原因特定のための補助で、ハルシネーション率・レイテンシ・グラウンディングチェック通過率など3〜5個程度に留めます。

MLflowの評価例でも、correctness/meanを主指標として計測し、他の指標はその低下原因を掘り下げる補助として扱う構成が示されています。

一度作成したゴールデンデータセットを「完成品」として放置してしまうのは、EDD の現場で繰り返し起きる失敗パターンです。

ゴールデンデータセットとは、評価の基準となる正解付きサンプル群のことです。ただし LLM アプリケーションの用途や利用者の期待値は時間とともに変化するため、データセットも同じペースで更新し続けなければ、評価基準そのものが現実から乖離していきます。

陳腐化が起きやすい原因はいくつかあります。プロダクトの機能追加やドメイン拡張に伴って既存サンプルがカバーしていないケースが増えること、ユーザーの言い回しや質問パターンが変化して当初の正解例が「古い回答」になること、そして法令・業界ルールの改定によって以前の正解が不正解に変わることなどが代表的です。

更新頻度の目安としては、プロダクトが頻繁に機能更新される場合は月次でのサンプル見直しが望ましく、比較的安定した用途であれば四半期ごとの定期レビューでも対応できます。重要なのは「いつ更新するか」をあらかじめ開発プロセスに組み込んでおくことで、後回しにしない仕組みを作ることです。

実践的な対策として有効なのは、本番ログから定期的にサンプルを抽出して人手でラベル付けし追加するパイプラインを整備することです。あわせてデータセットのバージョン管理を行い、評価スコアの変化がモデル改善によるものかデータ更新によるものかを区別できる状態にしておくことも欠かせません。また、陳腐化の兆候として見落とされがちなのが「評価スコアは高いのに本番品質への苦情が増える」というギャップです。このズレを監視指標として明示的に設定しておくと、データセットの劣化に早期に気づきやすくなります。

ゴールデンデータセットは一度作れば終わりではなく、プロダクトと並走して育て続けるものだと考えるのが自然です。

「評価スコアは毎週レポートに載っているのに、プロダクトが一向に改善されない」——そんな状況に心当たりはないでしょうか。

評価結果がエンジニアチームと事業側の間で共有されず、改善アクションに結びつかない「サイロ化」は、EDD 導入後に最も多く見られる失敗パターンのひとつです。評価を実施すること自体が目的化し、スコアが意思決定の材料として使われない状態に陥ります。

サイロ化が起きる原因は、だいたい似たところに集約されます。評価結果の共有先が技術チーム内に限定されてプロダクトオーナーや事業担当者に届いていないこと、スコアの解釈基準が統一されておらず「改善が必要な閾値」が定義されていないこと、そして評価レポートと開発スプリントのサイクルがそもそも連動していないこと——この三つが重なると、レポートは毎週生成されるのに誰も動かない、という状況が出来上がります。

解消するには、評価結果を開発サイクルに組み込む仕組みが必要です。評価スコアの閾値を事前に定義し、閾値を下回った場合は自動的にチケットが起票される運用にしておけば、「誰かが気づいて報告する」という属人的なステップを省けます。加えて、週次のスプリントレビューに評価サマリを必ず議題として組み込み、事業側も参加する場で改善方針を決める流れにすると、技術チームだけが問題を抱え込む構造が崩れやすくなります。

MLflow などの評価基盤を活用すれば、スコアの推移をダッシュボードで可視化し、関係者全員が同じ指標を参照できる環境を整えやすくなります。評価結果を「記録するもの」から「行動を起こすトリガー」へと位置づけ直すこと——それがサイロ化を防ぐ本質的な対策です。

結論: RAG やマルチエージェントシステムは評価対象が多層化するため、EDD の適用方法を構造に合わせて設計し直す必要がある。

単一の LLM 呼び出しと異なり、これらのアーキテクチャでは検索・生成・エージェント間連携それぞれに独立した評価軸が求められます。各レイヤーの評価設計と統合方法を解説します。

RAG（Retrieval-Augmented Generation）パイプラインの評価では、最初は「最終回答の品質だけを見れば十分」と考えがちです。しかし実際は、検索フェーズと生成フェーズを分離して評価するほうが、問題の根本原因を素早く特定できます。

検索品質の評価指標

検索フェーズでは、クエリに対して適切なチャンクが取得できているかを測ります。代表的な指標は以下のとおりです。

• Recall@K: 正解チャンクが上位 K 件に含まれる割合
• MRR（Mean Reciprocal Rank）: 最初の正解チャンクの順位の逆数平均
• Context Precision: 取得したチャンクのうち、回答に実際に使われた割合

これらを計測することで、ベクトルデータベースの設定やチャンクサイズの見直しが必要かどうかを判断できます。

生成品質の評価指標

生成フェーズでは、取得されたコンテキストをもとに正確な回答が生成されているかを評価します。

マルチエージェントシステムでは、単一エージェントの品質評価とは異なる視点が必要になります。個々のエージェントが正しく動作していても、オーケストレーション層での指示伝達や結果統合に問題があれば、システム全体の出力品質は大きく低下するためです。

EDD をマルチエージェント構成に適用する際は、評価の粒度を次の 3 層に分けて設計するのが有効です。

• エージェント単体層: 各エージェントが受け取ったタスクに対して正しい出力を返しているか
• エージェント間通信層: A2A（Agent-to-Agent Protocol）でのメッセージが意図通りに解釈・引き継がれているか
• エンドツーエンド層: ユーザーの最終目標に対してシステム全体が期待する結果を出力しているか

評価対象が複雑な場合は、エージェント単体のテストを先に安定させてから上位層の評価に進む「ボトムアップ評価」が有効です。一方、ビジネス要件の検証が急がれる場合は、エンドツーエンド評価を先行させて問題のある層を絞り込む「トップダウン評価」が適しています。