生成AIの出力品質をどう評価するか：評価セットと採点基準の作り方

生成AIを業務で使えるかどうかは、何回か試して「よさそうだ」と感じたかどうかでは判断できません。生成AIの出力は入力の少しの違いで変わり、目立つ成功例の陰で、特定の種類の入力だけ誤る、といったことがよく起きるからです。業務に使えるかを判断するには、実際の業務に近い入力を集めた「評価セット」と、何をもって合格とするかを決めた「採点基準」を用意し、同じ条件で繰り返し測る仕組みが必要です。

結論として、評価の進め方は次のとおりです。まず業務の目的から、出力に求める条件と、許されない誤りを決めます。次に、典型的な例・難しい例・誤りやすい例を含む評価セットを作り、採点項目と合格ラインを定めます。採点は、基準がはっきりした項目は自動で、判断が必要な項目は人とAIを組み合わせて行います。そして、プロンプトやモデルを変えるたびに同じ評価セットで測り直し、改善の効果と悪化を確かめます。

この記事は、生成AIを使った社内ツールやサービスを開発・導入する担当者、開発会社から「精度は十分です」と言われて判断に迷っている発注側の方に向けています。評価データの作り方、採点基準の決め方、人による採点とAIによる採点の組み合わせ方、評価を回し続ける運用までを、手順とチェックリストで解説します。

なぜ生成AIの評価は難しいのか

従来のシステムでは、同じ入力には同じ出力が返り、正しいかどうかを仕様と照らし合わせて判断できました。生成AIには、評価を難しくする性質がいくつかあります。

• 正解が一つに決まらない：要約や文章の生成では、よい答えが複数あります。言い回しが違っても内容が正しければ合格、という判断が必要です。
• 同じ入力でも出力が変わる：設定によっては、同じ質問に対して毎回少しずつ違う答えを返します。一度の試行では品質を判断できません。
• もっともらしい誤りがある：文章として自然なまま、事実と違う内容や存在しない情報を含むことがあります。読み流すと気づきません。
• 変更の影響が広い：プロンプトを一行変えただけで、改善したい例は直っても、別の例が悪化することがあります。

こうした性質があるため、数件を試して判断するのではなく、多様な入力で体系的に測る必要があります。

評価の前に決めること：目的と許されない誤り

評価セットを作る前に、その生成AIが業務で何をするのか、どんな誤りが許されないのかを決めます。ここが曖昧だと、何を採点すればよいかが定まりません。

「許されない誤り」と「許容できる不足」を分けておくことが重要です。すべての点で完璧を求めると、いつまでも合格にならず、逆に重大な誤りを見逃す採点になりかねません。

評価セットの作り方

評価セットは、生成AIに与える入力と、それに対する望ましい出力の条件を組にしたものです。用語としては 評価データセット とも呼ばれます。

入力を集める

評価セットの入力は、実際の業務から集めるのが基本です。

1. 実データから集める：過去の問い合わせ、実際の会議の記録、処理済みの書類など、業務で実際に発生した入力を集めます。個人情報や機密情報は、評価に使う環境の条件に合わせて加工します。
2. 種類を偏らせない：よくある入力だけでなく、入力の種類ごとに偏りなく選びます。問い合わせなら、カテゴリごとに数件ずつ選ぶといった方法です。
3. 難しい例を意図的に入れる：複数の内容が混ざった入力、あいまいな入力、資料に答えがない質問、誤字の多い入力などを入れます。
4. 誤ってほしくない例を入れる：答えてはいけない質問、範囲外の依頼、不適切な依頼など、断ることが正しい例も含めます。
5. 後から追加する：運用中に見つかった誤りの例を、評価セットに追加していきます。

件数は、最初は数十件から始めて構いません。少ない件数でも、種類の偏りがなく難しい例が含まれていれば、大きな問題は見つかります。運用しながら、誤りの例を加えて育てていきます。

望ましい出力の条件を書く

入力ごとに、望ましい出力の条件を書きます。書き方は、タスクの種類によって変わります。

• 分類・抽出：正解のカテゴリや、抽出すべき値を書きます。自動で正誤を判定できます。
• 質問への回答：回答に含まれるべき要点、根拠となる資料、含まれてはいけない内容を書きます。模範解答を一つ書くより、要点を箇条書きにする方が採点しやすくなります。
• 要約・文章生成：含めるべき要素、長さの範囲、守るべき形式や言葉遣いを書きます。
• 断るべき入力：「回答を断り、問い合わせ窓口を案内する」など、望ましい振る舞いを書きます。

採点項目と合格ラインの決め方

採点項目は、目的と許されない誤りから導きます。項目を増やしすぎると採点の手間が増えるため、業務上重要なものに絞ります。

採点は、「はい・いいえ」で判定できる形にすると、人による揺れが減ります。5段階の評価は細かく見えますが、採点者によって基準がずれやすくなります。どうしても段階で評価したい場合は、各段階の具体的な基準を例とともに書いておきます。

分類のように正解が決まるタスクでは、正しく拾えた割合と、拾ったものが正しかった割合を分けて見ると、誤りの性質が分かります。考え方は 適合率・再現率 の用語ページで説明しています。

合格ラインは、人が同じ作業をした場合の品質や、誤りの影響を考えて決めます。人が担当者として確認する前提の「下書き」なら、多少の不足は許容できます。利用者に直接届く回答なら、許されない誤りがないことを強く求めます。

人による採点とAIによる採点の組み合わせ

評価セットの件数が増え、プロンプトの変更のたびに測り直すようになると、すべてを人が採点するのは負担になります。そこで、採点の方法を項目ごとに使い分けます。

自動で判定できる項目

形式の遵守、文字数、指定した項目の有無、分類の正誤、根拠として挙げた資料名が実在するか、といった項目は、プログラムで自動判定できます。最も安く速く、揺れもありません。

AIに採点させる項目

要点が含まれているか、資料の内容と矛盾していないか、言葉遣いが適切か、といった判断が必要な項目は、別の生成AIに採点基準を渡して採点させる方法があります。LLM-as-a-Judge と呼ばれる手法です。人よりも速く多くの件数を採点できますが、採点するAIも誤ることがあるため、次の点に注意します。

• 採点基準を具体的に書き、「はい・いいえ」と理由を出力させる
• 採点するAIに、資料や要点など判断の材料を渡す
• 定期的に一部を人が採点し、AIの採点と一致しているかを確かめる
• 一致しない例が多い項目は、採点基準を見直すか、人の採点に戻す

人が採点する項目

業務上の影響が大きい誤りの判定、専門知識が必要な判断、断るべき入力への対応などは、人が採点します。採点者が複数いる場合は、最初に同じ数件を全員で採点し、判定のずれを話し合って基準をそろえます。

組み合わせの例

1. 全件を自動判定にかけ、形式の不備などを確認する。
2. 全件をAIに採点させ、正確性や網羅性の一次判定を出す。
3. AIが不合格とした例と、無作為に選んだ一部の例を、人が確認する。
4. 人とAIの判定が食い違った例を記録し、採点基準の改善に使う。

この流れなら、人の採点の手間を抑えつつ、重要な誤りの見落としを防げます。業務の流れの中に人の確認を組み込む考え方は、ヒューマン・イン・ザ・ループ の用語ページでも説明しています。

評価を回して改善する運用

評価は、一度測って終わりではありません。プロンプト、参照する資料、モデルなどを変えるたびに、同じ評価セットで測り直します。

1. 基準となる結果を記録する：現在の設定での評価結果を、項目ごとに記録します。
2. 一つずつ変える：プロンプトの変更とモデルの変更を同時に行うと、どちらの効果か分かりません。
3. 全件で測り直す：直したい例だけでなく、評価セット全体で測ります。改善と同時に悪化した例がないかを確認するためです。
4. 悪化した例を確認する：合格から不合格に変わった例を人が確認し、変更を採用するかを判断します。
5. 結果と設定を記録する：どの設定でどの結果が出たかを残しておけば、後から元に戻すことも、経緯を説明することもできます。

社内文書を検索して回答する仕組みでは、誤りの原因が検索にあるのか、回答の生成にあるのかを分けて確認すると、改善が早く進みます。改善の方法は RAGの回答精度を改善する方法 で詳しく解説しています。

公開後の品質をどう見守るか

公開前の評価で合格しても、実際の利用では想定していなかった入力が来ます。公開後は、次の方法で品質を見守ります。

• 利用者が回答に「役に立った・役に立たなかった」を付けられるようにする
• 役に立たなかった回答や、人に問い合わせが回った例を定期的に確認する
• 確認した誤りの例を評価セットに追加する
• 一定の期間ごとに、評価セットで測り直し、品質が落ちていないかを確認する

利用者の評価は、付けてもらえる件数が少ないことや、不満のある人ほど付けやすいことに注意が必要です。利用者の評価だけで品質を判断せず、評価セットでの定期的な測定と組み合わせます。

評価を担う体制と役割分担

評価の仕組みは、誰がどこを担うかを決めておかないと続きません。特に発注側と開発会社に分かれて進める場合、役割の切れ目で作業が止まりがちです。

• 業務担当者（発注側）：評価セットの入力を集め、望ましい答えの要点と許されない誤りを書きます。人による採点のうち、業務知識が必要な判定も担います。
• 推進担当者（発注側）：合格ラインの決定、評価結果をもとにした公開や変更の判断、評価セットの管理を担います。
• 開発担当者（開発会社または社内）：自動判定とAIによる採点の仕組みを作り、プロンプトや設定の変更と再測定を行い、結果を記録して報告します。

評価セットは、業務の知識が詰まった資産です。開発会社の環境にだけ置くのではなく、発注側でも管理し、開発会社が変わっても使い続けられるようにしておきます。また、業務担当者が評価に割く時間は、通常業務の合間では確保しにくいため、評価セットを作る期間や、定期的な採点の時間をあらかじめ計画に入れておくことが大切です。評価の結果は、推進担当者が月に一度など決まった頻度で確認し、改善を続けるか、利用範囲を広げるかを判断する場にすると、評価が形だけの作業になりません。

具体的な場面で考える（架空の例）

架空の機械部品メーカーで、営業担当者が製品カタログと技術資料をもとに、顧客からの技術的な質問への回答案を作るツールを開発していたとします。開発会社からは「試したところ精度は十分」と報告されていましたが、発注側としては判断の根拠がありませんでした。

• 過去の問い合わせ記録から、製品の仕様、互換性、使用条件、納期の質問など、種類ごとに60件を選び、資料に答えがない質問と、他社製品の比較を求める質問も含めた。
• 技術部門の担当者が、各質問に回答の要点と根拠の資料名を書いた。
• 採点項目を、仕様の数値の正確性、要点の網羅性、根拠資料の提示、資料にない質問への対応の四つに絞った。許されない誤りは「仕様の数値の誤り」と「資料にないことを推測で答えること」とした。
• 形式と根拠資料の実在は自動で判定し、正確性と網羅性はAIに一次採点させ、不合格の例と無作為の一部を技術担当が確認した。
• 最初の測定で、資料にない質問に推測で答える例が複数見つかったため、プロンプトに断り方を明記し、再測定で改善を確認した。

この評価セットは、その後のモデルの切り替えや資料の追加のたびに使われ、品質の判断の共通基準になりました。

よくある失敗と避け方

• 成功例だけで判断する：デモで見せられたうまくいく例だけで判断すると、誤りやすい入力を見落とします。難しい例と断るべき例を必ず入れます。
• 評価セットを開発会社だけで作る：望ましい答えを判断できるのは業務を知る発注側です。要点と許されない誤りは、業務担当者が書きます。
• 採点基準があいまい：「よい回答か」のような基準では、採点者によって判定が変わります。「はい・いいえ」で判断できる項目に分けます。
• AIの採点を確かめない：AIによる採点も誤ります。定期的に人の採点と比べます。
• 変更のたびに一部だけ確かめる：直したい例だけを確認すると、別の例の悪化に気づきません。全件で測り直します。
• 評価セットを更新しない：運用で見つかった誤りを追加しないと、評価セットが現実の利用から離れていきます。
• 一度の試行で判断する：出力が毎回少し変わる設定では、同じ入力を複数回試して、結果が安定しているかも確認します。

評価の仕組みづくりのチェックリスト

• 目的、必須の条件、許されない誤り、許容できる不足を決めたか
• 実際の業務から、種類の偏りなく入力を集めたか
• 難しい例、資料に答えがない例、断るべき例を含めたか
• 入力ごとに望ましい出力の条件（要点・根拠・禁止事項）を書いたか
• 採点項目を絞り、「はい・いいえ」で判定できる形にしたか
• 採点項目ごとに、自動・AI・人のどれで採点するかを決めたか
• AIの採点を人の採点と比べる手順を決めたか
• 変更のたびに全件で測り直し、結果と設定を記録する運用にしたか
• 公開後の利用者の評価と、評価セットの追加の手順を決めたか

モデルの比較に評価セットを使う方法は、業務に使うLLMの選び方 でも紹介しています。

よくある質問

Q. 評価セットは何件くらい必要ですか？

最初は数十件から始めて構いません。件数より、入力の種類の偏りがないこと、難しい例や断るべき例が含まれていることが大切です。運用で見つかった誤りを追加しながら増やしていきます。誤りの影響が大きい業務では、件数を多めに用意します。

Q. 正解率が何割を超えれば業務に使えますか？

一律の基準はありません。人が確認する前提の下書きか、利用者に直接届く回答か、誤りの影響がどの程度かによって必要な水準が変わります。全体の正解率だけでなく、許されない誤りが起きていないかを別に確認することが重要です。

Q. AIに採点させると、同じAIの誤りを見逃しませんか？

その可能性はあります。採点するAIには判断の材料（資料や要点）を渡し、採点の理由も出力させます。そして、定期的に一部を人が採点して一致を確かめます。重大な誤りの判定は人が行う、と役割を分けておくと安心です。

Q. 評価の作業は開発会社に任せられますか？

採点の仕組みや自動化は開発会社が担えますが、望ましい答えの要点や許されない誤りを決めるのは、業務を知る発注側の役割です。評価セットの作成には業務担当者の時間が必要になることを、計画の段階で見込んでおきます。

Otsumuに相談できること

AIに任せる業務が一つで、出力を必ず人が確認する使い方であれば、この記事の手順で数十件の評価セットを作り、表計算ソフトで採点を記録するだけでも、十分に品質を判断できます。まずは業務担当者が要点と許されない誤りを書き出すところから始めてみてください。

一方で、プロンプトやモデルを頻繁に見直す、件数が多く人の採点が追いつかない、顧客向けのサービスで品質の説明責任がある、社内文書を参照する仕組みで誤りの原因を切り分けたい、といった場合は、評価を自動化し、継続的に測れる仕組みを作る価値があります。開発会社から報告された精度の妥当性を確かめたい場合も、第三者の視点が役に立ちます。

Otsumuでは、業務の目的から採点項目と合格ラインを一緒に整理し、評価セットの作り方の支援から、自動採点とAIによる採点を組み合わせた評価の仕組みづくり、評価結果にもとづく改善までを、必要な範囲で支援します。進め方は 生成AIシステム開発 のページで紹介しています。

いま使っている、または開発中の仕組みの品質をどう確かめればよいか迷っている段階でも構いません。30分の無料相談 で状況を伺い、評価の進め方を一緒に検討します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01