生成AIの評価セットをどう作るか：業務で使えるLLM評価の設計

生成AIを業務へ導入するとき、最初に作るべきものはプロンプト集ではなく、評価セットです。

モデルを変える、RAGを追加する、プロンプトを調整する、ファインチューニングする――こうした改善を行っても、比較する基準がなければ、本当に良くなったか判断できません。「今回の回答は良さそうだった」という印象だけでは、モデル更新や利用量の増加に耐える仕組みになりません。

評価セットは、対象業務の入力、期待する出力、採点基準を記録したテストケースの集合です。本記事では、LLMを使った業務アプリケーションのために、評価セットを小さく始めて育てる方法を紹介します。

評価セットは、モデルの試験問題ではない

公開ベンチマークのスコアは、モデル選定の参考になります。しかし、実際の業務で必要なのは、自社のデータ、利用者、失敗許容度に対する品質です。

たとえば、問い合わせを分類するAIであれば、一般的な知識問題に正解できることよりも、次のようなことが重要です。

• 緊急性の高い問い合わせを見落とさないか
• 分類不能な入力を無理に断定しないか
• 指定したカテゴリ名以外を出力しないか
• 個人情報を含む入力を適切に扱えるか
• 繁忙期や新しい商品に関する表現でも安定するか

評価セットは「どのモデルが最も賢いか」を決めるためではなく、そのシステムを業務で使ってよいかを判断するために作ります。まず、評価結果を誰が見て、どの判断に使うのかを決めましょう。モデル選定、リリース判定、モデル更新の検証、障害調査では、必要なケースと合格基準が変わります。

最初に、失敗すると困ることを言語化する

評価ケースを集め始める前に、対象業務について次の三つを書き出します。

1. AIにさせる判断・生成は何か
   例：問い合わせを3カテゴリへ分類する、契約書から更新日を抽出する、社内規程に基づいて回答案を作る。
2. 正しい結果はどのような状態か
   例：正しいカテゴリを一つだけ返す、日付と根拠箇所を返す、根拠文書がない場合は「確認できない」と答える。
3. 許容できない失敗は何か
   例：緊急案件の誤分類、存在しない規程の引用、個人情報の不要な出力、外部操作を誤って実行すること。

この三つが曖昧なままでは、「回答が自然である」「役に立つ」といった主観的な評価になりがちです。業務への影響が大きい失敗ほど、独立した評価カテゴリと明確な合格条件を用意します。

評価セットの1件に何を入れるか

評価データはCSV、JSON、データベースなど、管理しやすい形式で構いません。重要なのは、後から同じ条件で再実行でき、なぜその判定になったかを追えることです。

最小限、各ケースに次の項目を持たせます。

{
	"id": "support-042",
	"scenario": "解約に関する緊急問い合わせ",
	"input": "今月末で解約したい。請求が二重になっている。",
	"context": "必要な場合にだけ与える検索結果や業務ルール",
	"expected": "billing_urgent",
	"acceptance_criteria": "カテゴリは billing_urgent のみ。根拠のない返金確約をしない。",
	"risk": "high",
	"source": "過去問い合わせを匿名化・編集",
	"reviewer": "業務責任者",
	"version": "1.0"
}

生成文のように正解が一つに決まらないタスクでは、expectedに模範回答を一つだけ置くよりも、満たすべき条件と避けるべき条件を記録する方が実用的です。たとえば「結論を先に書く」「根拠がない数値を出さない」「引用元を示す」「禁止表現を含めない」といったルーブリックで採点します。

ケースは「よくある入力」だけで作らない

運用で問題になるのは、典型的な入力よりも境界ケースや失敗しやすい入力です。評価セットには、少なくとも次の層を含めます。

• 代表ケース：日常的によく発生する、標準的な入力
• 重要ケース：金額、契約、健康、安全など、誤りの影響が大きい入力
• 境界ケース：分類が迷わしい入力、情報が不足した入力、複数の意図を含む入力
• 異常ケース：誤字、口語、長文、表形式、OCR由来の崩れた文字列
• 安全性ケース：機密情報の要求、プロンプトインジェクション、不正な操作指示
• 変化ケース：新商品、制度改定、季節性など、時間とともに内容が変わる入力

最初から数千件を作る必要はありません。まずは業務責任者が目視できる規模で、重要な失敗を代表するケースを集めます。その後、実運用のログ、利用者からの指摘、障害・ヒヤリハットを評価セットへ追加していきます。

このとき、成功例だけを増やさないことが重要です。「以前失敗した入力」「人間でも判断が割れた入力」「仕様変更で挙動が変わった入力」は、将来の回帰を防ぐ資産になります。

採点方法は、タスクに合わせて使い分ける

すべての出力をLLMに採点させる必要はありません。判定できるものは、より単純で再現性の高い方法を優先します。

• 完全一致・集合一致：カテゴリ、ID、真偽値、抽出した項目など
• 構造検証：JSON Schema、必須フィールド、型、許可された値
• ルール判定：禁止語、必須の注意文、引用の有無、文字数上限
• 人によるレビュー：正確性、業務上の妥当性、表現の適切さ
• LLM-as-a-Judge：大量の自由文を、あらかじめ定義したルーブリックで補助的に採点する

LLM-as-a-Judgeは便利ですが、採点側のモデルにも誤りや偏りがあります。導入時には、人が採点したサンプルと比較して、どの基準で一致・不一致が起きるかを確認します。また、生成するモデルと採点するモデルを同一に固定せず、採点プロンプト、モデルのバージョン、ルーブリックも評価結果と一緒に記録します。

RAGやエージェントは「回答」だけを評価しない

RAGでは、最終回答が正しく見えても、誤った文書を参照していたり、根拠が不足していたりすることがあります。評価セットには、質問と期待回答だけでなく、参照されるべき文書・避けるべき文書・根拠として必要な箇所を入れます。

ツールを呼び出すエージェントでは、最終的な文章だけでは不十分です。ツール選択、引数、実行順序、権限確認、人の承認を求めるタイミングを別々に評価します。たとえば、返金処理を実行できるエージェントなら、「返金の説明が自然か」だけでなく、「権限のない利用者に実行しないか」「金額や対象者を復唱して確認するか」をテストします。

評価をリリースの工程に組み込む

評価セットは、スプレッドシートに置いて終わりではありません。プロンプト、モデル、検索インデックス、ツール定義、ガードレールのいずれかを変更したら、同じセットで再実行できるようにします。

リリース判定では、全体の平均点だけでなく、リスク別の結果を確認します。高リスクケースが一つでも失敗したら止めるのか、一定の人手レビューを入れるのか、条件をあらかじめ決めておきます。モデルを更新したときに平均点が改善していても、重要なカテゴリで悪化していれば、その変更を採用すべきではありません。

NIST AI RMFでは、テストセット、指標、評価に使うツールを文書化し、実際の配備条件に近い環境で評価すること、運用中の挙動を監視することが示されています。評価セットをバージョン管理し、実行日時、モデル、プロンプト、検索インデックス、採点方法を残しておくと、問題発生時に原因を追いやすくなります。

評価データにも、データガバナンスが必要

実データを評価に使うと、顧客情報、契約情報、社内の機密が含まれることがあります。評価セットは「テスト用だから安全」とは限りません。

利用目的を決め、不要な識別子を削除・置換し、アクセス権を制限します。外部の評価基盤やLLM-as-a-Judgeを利用する場合は、評価データも外部へ送信される点を見落とさないでください。匿名化の有無、保存期間、ログ、学習利用の条件を、通常の生成AI利用と同じように確認します。

まとめ：評価セットは、失敗から育てる

よい評価セットは、一度作って完成するものではありません。対象業務の重要な判断を定義し、失敗しやすいケースを集め、変更のたびに同じ条件で比較し、運用で見つかった問題を追加する。この循環を作ることが、生成AIを安定して改善する近道です。

まずは、一つの業務について「許容できない失敗」を10件書き出すところから始めてみてください。その10件が、モデルやプロンプトを選ぶための、最初の評価セットになります。

参考資料

• Evaluation best practices（OpenAI API）
• NIST AI Risk Management Framework 1.0
• NIST AI RMF: Generative AI Profile（NIST AI 600-1）