【詳細④】AIの「良し悪し」をどう測るか:評価(テスト)の基本

「なんとなく良さそう」では判断できない

 AIの出力は、毎回少しずつ違います。「何度か試したらうまくいった」では、本番で通用するかわかりません。

 そこで必要になるのが、評価(eval、エバル)です。決まった問題とチェック基準を用意して、AIの答えを測る作業のことです。

先に「成功の基準」を決める

 Anthropicの公式ガイドは、評価の前に、何をもって成功とするかを具体的に決めるよう求めています。

 例えば、医療のアプリでは出典の正確さが非常に重要でも、気軽な雑談のチャットボットではそこまで重要ではないかもしれない、という例を挙げています。
 多くの用途では、複数の基準で多面的に評価する必要があるとも書かれています [S9]。

評価の問題を作る:5つの原則

 同じく公式ガイドは、評価用の問題(テストケース)を作る原則を示しています [S8]。

  • 実際の仕事に近づける:本番で扱う問題の分布に似せる。珍しいケース(エッジケース)も入れる
  • 変な入力も入れる:関係のない入力、存在しないデータ、不適切・有害な利用者の入力、人間でも判断が割れる曖昧なケース
  • できるだけ自動で採点できる形にする:「正しい/誤り」や、1〜5点のように、数字や選択肢で答えさせる。感想のような定性的な評価は確かめにくい
  • まず信頼性を確かめ、それから数を増やす
  • 数は用途しだい:公式の例では、感情分類のテストに1,000件、要約に200件など、用途によって数が違う

 採点の方法は、大きく3つあります。

  • プログラムで機械的に採点する方法(速くて信頼性が高いが、使える場面が限られる)
  • 人が採点する方法
  • 別のAIに採点させる方法(採点用の指示文を書く[S9])

モデルが変わったら、同じテストをもう一度

 公式ガイドは、指示文を変えていないときでも、評価を定期的に行うよう勧めています [S9]。
 AIのバージョンが変わると、結果も変わるからです。

 デジタル庁のガイドラインも、AIモデルが大きく更新されたときは、利用者に提供する前に出力の品質や安全性、費用の変化などを確認するよう求めています [S12]。

評価の仕組み自体がAIの振る舞いを変える

 OpenAIは、ハルシネーションが減りにくい理由のひとつに評価の仕組みを挙げています。
 多くの評価が正解の数だけを数えるため、AIが当てずっぽうで答えるほうが得になってしまう、という指摘です。

 同社は、誤答を減点し、不確かさを適切に示した答えに部分点を与える採点を提案しています [S5]。評価の設計は、AIがどう振る舞うかに影響を与えるのです。

発注・導入の場面で、何を評価するのか

 デジタル庁の調達チェックシートには、評価に関する要求事項が整理されています [S12]。

  • 期待する品質をあらかじめ決め、それを満たしているか、測定して評価する
  • 複数の種類のテストケース(一括処理、情報検索など)で評価する
  • 同じ質問を複数回、また意味が近い質問を複数入力しても出力に一貫性があるか
  • 誤入力、表記のゆれ、文字化けのあるデータでも安定して動くか
  • RAGを使うなら、検索の精度と、検索結果と出力の関連性・一貫性
  • 使っているAIモデルを、バージョン情報も含めて示せるか

 リリース前のテストの例として、禁止されている出力をしていないか、不適切な生成や偏りがないか、仕様書の要件を満たすか、攻撃者の視点でのテスト(レッドチーム)を含めて、複数の独立した方法で試す、といった内容が挙げられています。
 リリース後も、利用ログのサンプルチェックや利用者へのアンケートで、出力の品質や不適切な生成を監視するとされています [S12]。

契約の注意:「精度○%保証」は難しい

 契約チェックシートは、AIモデルが原因の性能や出力の品質は、学習データなどの影響を受けるため「○○%以上の精度」のような成果の保証が難しい場合がある、と説明しています。その場合は、成果の保証ではなく、性能改善や品質向上のための技術支援を受ける形が望ましいとされています。
 システムプロンプトの設計・評価のような作業も、成果物を明確に決めにくいため、「取り組みを実施すること」を契約に盛り込む、という考え方が示されています。

 一方、性能要件を含まない形の成果物(指定された構造のシステムプロンプト、テストシナリオ、設定パラメータ一式など)は、成果物として定めうるとされています [S12]。

注記:契約書の書き方は、案件ごとに変わります。
   ここに書いたのは、デジタル庁のチェックシートの考え方の要約です。
   実際の契約は、専門家にご確認ください。

導入側が、あらかじめ決めておきたいこと

  • 何をもって成功とするか(基準と合格ライン)
  • 評価に何のデータを使うか。できれば、自社の実際のデータや、過去の問い合わせから作る
  • 誰が、いつ、どのくらいの頻度で再評価するか。特にAIモデルの更新時

注記:この3点は、上の公式資料から整理した、実務上の確認項目です。
   公式資料がこの形で示しているわけではありません。

参照元

[S5] OpenAI, Why language models hallucinate — https://openai.com/index/why-language-models-hallucinate/

[S8] Anthropic, Create strong empirical evaluations — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests

[S9] Anthropic, Define success criteria and build evaluations — https://platform.claude.com/docs/en/docs/empirical-performance-evaluations

[S12] デジタル庁, DS-920 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン(2026年6月12日) — https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/decb64eb-f26e-41cb-8d37-f3dd173108b8/59054b35/20260612_resources_standard_guidelines_guideline_01.pdf

総集編に戻る

コメント

タイトルとURLをコピーしました