LLM as a Judgeの運用知見：AIエージェント開発で『暗黙知 → 評価指標 → 自動評価』をどう繋いだか

AIエージェント開発でLLM as a Judgeを機能させるには、評価AIを用意するだけでは不十分です。人間の暗黙知を評価基準へ落とし込み、実行ログをテストケースとして蓄積し、評価器であるLLM自体のズレも継続的に点検する運用設計が必要です。

こちらの記事では、AIがAIを評価する仕組みである「LLM as a Judge」の基本的な考え方を紹介しました。しかし、実際にLLM as a Judgeを導入するのはそう簡単ではありません。

本記事では、dotDataで開発した「UseCase Advisor（UCA）」を例に、LLM as a Judge導入を成功させ、効率よく運用するための知見を紹介します。特に、次の3点に焦点を当てます。

• 評価基準を作る: 人間の暗黙知やフィードバックを、評価可能な観点へ分解する
• ログをテストケース化する: 実運用で得た対話ログを、将来の品質保証に使える評価資産へ変える
• Judge Driftをメタ評価で検知する: 評価AIの判定が人間の判断からずれていないかを点検する

1. AIエージェント開発に立ちはだかる「80点の壁」

LLM（大規模言語モデル）の登場により、AIエージェントの開発は驚くほど容易になりました。優れたAPIやフレームワークを組み合わせれば、数日、場合によっては数時間でプロトタイプを作ることも珍しくありません。

しかし、プロトタイプが動くことと、商用サービスとして安心して提供できることは別の話です。実際には、多くの開発プロジェクトで最後の20点を詰める作業に最も時間がかかります。

dotDataが開発しているAIエージェント「UseCase Advisor（UCA）」でも同じでした。

UseCase Advisorは、dotDataのデータ分析プラットフォーム「dotData Insight」に搭載されたAIエージェントです。dotData Insightは、分析に詳しくないビジネスユーザーでも高度な分析が可能な分析プラットフォームで、独自のAIが業務データから重要なパターンを自動探索し、ビジネスKPIに関連するインサイトを発見します。

UseCase Advisor（以下、UCA）は、その中でも「データを活用したいが、どんなテーマで何を分析すべきか分からない」というビジネスユーザーの悩みに向き合う壁打ちツールです。分析に着手する前に、ユーザーの業務課題を対話形式で深掘りし、分析ユースケースを整理。具体的な分析テーマの提案からKPI・評価指標の設定まで、データ分析の企画書としてとりまとめます。

このようなAIエージェントでは、一度のプロンプトで回答が完結するわけではありません。ユーザーへの問診、追加質問、回答内容を踏まえた企画書の修正など、複数回の対話を経て最終的な成果物を生成します。そのため、ユーザーの入力や対話の流れによって生成結果が大きく変わります。

従来のソフトウェアのように、「この入力なら、この出力が正しい」というテストケースだけで品質を保証することはできません。

その結果、開発現場では次のような課題が生じます。

• テストケースを十分に用意できない
• 出力品質を人手で確認する負荷が大きい
• 「なんとなく良い」「少し違う」といった判断が属人的になる
• 改善によって本当に品質が向上したか客観的に判断しにくい

UCA開発でも当初は、開発者が数件の対話を確認して品質を判断する、いわゆる「バイブスチェック」に頼らざるを得ませんでした。しかし、この方法では品質改善を継続的に進めることはできません。

そこで導入したのが、LLMにより評価を自動化する仕組みであるLLM as a Judgeです。

2. AIエージェント開発でLLM as a Judgeを導入する際に直面した課題

しかし、LLM as a Judgeの導入には、大きく2つの課題がありました。1つは評価基準をどう具体化するか、もう1つは評価データをどう育てるかです。

課題①：評価基準の具体化 ─ 人間の暗黙知をどう評価基準へ落とし込むか

LLM as a Judgeで評価用のAI（評価AI）に人間の評価を代替させるには、「何を良い出力と判定するか」を定義した評価基準（ルーブリック）の定義が不可欠です。評価基準が曖昧なままでは、LLMによる自動評価も一貫した結果を返せません。

一方で、実際のAI開発では、必要となる評価基準をあらかじめすべて定義しておくことは現実的ではありません。UCAの開発では特に、「適切な問診」「質の高い企画書」といった判断基準の多くが分析コンサルタントが持つような暗黙知であり、開発初期の段階では何を評価項目として定義すべきか自体が明確ではありませんでした。

そのため重要なのは、最初から完璧な評価基準を作ることではなく、ユーザーフィードバックや改善要望をもとに、人間の暗黙知を少しずつ評価基準へ落とし込み、継続的に評価基準を強化していくことです。

課題②：評価データの具体化 ─ 現実的なテストケースをどう育てるか

AIとユーザーの対話が複雑になると、テストケースは無限の組合せを持ちます。分析企画書の作成では、ユーザーへの問診、回答内容に応じた追加質問、フィードバックを踏まえた企画書の修正など、複数の対話プロセスを経て最終的なアウトプットを生成します。そのため、エージェントへの入力パターンは非常に多岐にわたります。ユーザーの業種や課題だけでなく、回答の粒度や曖昧さ、途中で寄せられるフィードバックによっても、エージェントがたどる経路や生成結果は大きく変化します。

こうした無数の入力パターンを、あらかじめテストケースとして網羅することはできません。実運用で得られるログを効率よく継続的に評価データとして蓄積し強化するプロセスが必要です。

3. LLM as a Judgeを機能させる改善サイクル

そこで、AI機能の開発では、最初から高品質なシステムを作り込むのではなく、検査不足でも利用可能な状態を作った後早くリリースし、社内の関係者やテストユーザーから実際のフィードバックを収集することが重要です。これにより、「どのような出力が望ましいのか」「どのようなケースで失敗しやすいのか」といった、品質そのものを定義するための情報を蓄積し、評価基準・テストケース、AIエージェントの三つを改善する3つのサイクルを回します。

① 評価基準の強化：暗黙知を評価基準へ反映

ユーザーから寄せられる「分かりにくい」「期待と違う」といったフィードバックは、そのままではLLM as a Judgeの評価基準として利用できません。重要なのは、その背景にある原因を分析し、評価可能な観点へ分解することです。

例えば、ユーザーテストで「UCAの問診が難しくて、どう答えていいか分からない」というフィードバックが寄せられたケースを考えます。このフィードバックだけでは、評価基準としては曖昧です。

そこで「何が難しさを生んでいるのか」を分析し、原因を評価可能な観点へ分解する必要があります。この例の場合、

• 専門用語の壁：分析用語（目的変数など）が説明なく使われていないか
• 意図・ガイドの不足：質問の目的や回答例が十分に示されているか
• 認知負荷の高さ：一度に多くの情報を求め、回答しづらくなっていないか

このようにフィードバックを具体的な観点へ分解することで、「用語の平易性」「意図とガイドの提示」「認知負荷の軽減」といった評価基準を追加できます。このように、実際のフィードバックや改善事例を通じて評価観点を継続的に追加・見直し、人間の暗黙知を少しずつ評価基準として資産化していくことが重要です。

LLM as a Judgeの価値は、単にスコアの割り当てを自動化することではなく、このような改善サイクルを通じて評価基準そのものを継続的に管理できる点にあります。こうして言語化された評価基準をLLM as a Judgeの評価プロンプトに組み込むことで、新しい基準が反映されます。人間が毎回目視で判断していたプロセスを、AIが一貫した基準で担えるようになります。

② ログの資産化：生データを「テストケース」へ

実運用で得られた実行ログを継続的に収集し、失敗したケースや判断に迷ったケース、特徴的な対話をテストケースとして保存・管理することが重要です。こうして蓄積されたテストケースは、一度限りのログではなく、将来の品質保証に活用できる評価資産になります。AIエージェントを改善した後も同じケースを繰り返し評価することで、品質向上の確認だけでなく、劣化の検知にも利用できます。

③ AIエージェントの改善：継続的なアップデートと品質維持

評価基準とテストケースが整備されると、AIエージェントを改善するたびに、その効果を継続的かつ効率的に評価できるようになります。AIエージェントを改善した際には、過去に保存した同じテストケースに対して再度評価を実施することで、改善したかった項目が実際に向上しているかを確認できます。

一方で、ある機能を改善した影響で、これまで問題なく動作していた別のケースの品質が低下してしまうこともあります。例えば、回答を簡潔にする改善によって必要な説明まで削られてしまったり、専門用語を分かりやすく説明する改善によって別のケースでは冗長な回答になったりすることがあります。このような意図しない品質劣化（デグレード）を早期に検知し、修正できることも、テストケースを蓄積する大きな価値です。

さらに近年では、LLM as a Judgeによる評価結果を利用して、プロンプトやエージェント全体を自動的に改善する技術も登場しています。例えば、DSPyでは、あらかじめ定義した評価指標（Metric）を目的関数として、プロンプトやFew-shot例を自動探索・最適化するMIPROv2や、実行ログや自然言語フィードバックを利用して改善を繰り返す GEPA などの最適化手法が提供されています。これらは、「評価」と「改善」を自動的に結び付けるアプローチとして注目されています。

このように、評価基準・テストケース・AIエージェントの改善を一つのサイクルとして継続的に回すことが、AIエージェントの品質を効率よく向上させるポイントです。

4. LLM as a Judgeを継続的に機能させるポイント

評価器であるLLM（評価AI）も、長期運用の中で判定基準が徐々に変化する可能性があります。LLM as a Judgeを継続的に機能させるには、適切にAIと人間の役割分担することと、評価器自体の品質を監視することが重要です。

AIと人間の役割分担

AIと人間の役割を以下のように分けたHuman-in-the-loop（人間が評価ループに介在する設計）の運用を推奨します。

AIの役割：大量データの一次評価

評価AIは、実行ログを継続的に評価し、問題がありそうなケースを抽出します。LLMは確率的に動作するため、同じ入力でも評価結果がわずかに変動します。そのため、1回の評価結果だけで判断するのではなく、複数回評価の平均と分散を確認することが重要です。分散が大きい（＝判定がぶれている）ケースを「迷い」として数値化し、確信度が低いものは人間へ引き継ぎます。

人間の役割：判断と評価基準の更新

人間は、AIが判断に迷ったケースを重点的に確認します。また、新機能の追加やユーザー要求の変化に応じて、「何を良い出力とするか」という評価基準自体を継続的に見直します。

Judge Driftの検知：評価AIの品質を保つ

長期運用では、評価AI自体の品質が徐々にずれるJudge Drift（評価指標の乖離）が発生します。

Judge Driftは、たとえば次のような要因で発生します。

• 基盤モデルのアップデートにより、同じ評価プロンプトでも判定傾向が変わる
• アプリケーションの機能追加により、以前の評価基準では品質を捉えきれなくなる
• ユーザーの要求水準が上がり、良い出力の定義が変化する
• 人間側の評価観点が更新されたのに、評価プロンプトへ反映されていない

メタ評価：AIの評価結果を人間が検品する

このズレを検知するために、dotDataはメタ評価（Meta-Evaluation）の仕組みを取り入れています。メタ評価とは、評価AIの判定が人間の感覚とずれていないかを評価する、二重のフィードバックループです。

運用では、評価AIの評価結果に対して、定期的に人間がサンプリング検品を行います。AIが過大評価したケース、過小評価したケース、人間の評価と割れたケースを分析し、評価プロンプトやテストケースへ反映します。

この改善ループでは、次のような更新を行います。

• 評価プロンプト内の判定基準をより厳密にする
• 人間が修正した正解例を新しいベンチマークとしてテストケースへ追加する
• 評価軸の粒度を見直し、曖昧な評価項目を分解する
• 確信度が低いケースを重点的にレビューする

LLM as a Judgeを長期運用するには、評価AIもまた評価対象として扱う必要があります。評価AIの品質保証まで含めて設計することで、自動評価システムへの信頼性を保ちやすくなります。

5. LLM as a Judge運用に向けた提言まとめ

UCAの開発を通じて見えてきたのは、LLM as a Judgeの成否は、評価モデルの性能だけで決まらないということです。むしろ、評価対象、評価基準、人間の判断、改善プロセスをどうつなぐかが重要です。

実務上のポイントは、次の3つです。

1. まずリリースし、ログを集める: 開発者が想像したテストケースだけでは、実際のユーザー入力を十分に再現できません。ユーザーが入力した生のログこそが、AIエージェントが進化すべき方向を示す重要な材料になります。
2. 評価観点を資産化し続ける: カジュアルに集まったフィードバックや失敗ログを、テストケースと評価基準へ還元します。複数回試行による確信度の算出やメタ評価を通じて、評価の品質そのものも改善し続けます。
3. 評価器自身の品質も継続的に改善する: LLM as a Judgeは一度設計すれば維持できるものではありません。基盤モデルのアップデートや要件の変化により、評価基準は徐々にずれていきます。評価AIのスコアと人間の判断を定期的に照合し、評価プロンプト自体を見直す仕組みを持つことが、長期運用での信頼性を支えます。

複雑化するAIエージェント開発では、データとフィードバックに基づく継続的な改善プロセスが、品質向上の土台になります。

6. dotDataが提供するビジネスユーザーに寄り添った分析AI

dotDataは、創設以来一貫して「高度なデータサイエンスを、誰もがビジネスの現場で使える形にする」という考え方を掲げています。UCAも、その考え方を生成AIの技術で具体化する取り組みの一つです。

AIが生成したアウトプットだからといって、品質の曖昧さを受け入れる必要はありません。専門家が持つ暗黙知を評価基準やテストケースへ変換していくことが、ビジネス現場で実用に耐えるAIをつくるうえで重要です。

感覚（バイブス）に頼る開発の壁を感じている方は、ぜひdotDataとともに、データとシステムに基づいた確かなLLMアプリケーション開発への一歩を踏み出してみませんか。ぜひお気軽にお問い合わせください。

LLM as a Judgeに関してよくある質問