生成AIの評価方法とは？研究開発で使えるLLM Evalsの設計と指標

生成AIを研究開発へ導入するとき、「どのモデルが最も高性能か」より先に決めるべきことがあります。それは、何ができれば合格とするのかです。

文章が自然でも、数値、単位、出典、計算、要求項目の一部が誤っていることがあります。反対に、最終回答が不完全でも、検索や情報抽出までは正しく動いている場合があります。生成AIを一つの総合点だけで評価すると、改善すべき場所を見失います。

このような生成AIシステムの評価を、一般にLLM Evals（LLM評価）と呼びます。結論から言えば、研究開発では、検索、根拠への忠実性、数値・単位、計算、要求網羅性、棄権、再現性を分けて測ることが重要です。

この記事では、LLM Evalsの設計方法と主要指標を解説します。さらに、企業の実データを含まない架空の材料科学文書とローカルAIを使った実測例から、「全項目正答率0％」をどのように診断し、改善策へつなげるかを示します。

LLM Evalsとは

LLM Evalsとは、大規模言語モデルや、それを組み込んだRAG・AIエージェントが、目的とする業務をどの程度適切に実行できるかを測定する仕組みです。

評価対象はモデル単体に限りません。実務では、次の要素を組み合わせたシステム全体を評価します。

• プロンプト
• 生成モデルと設定
• 埋め込みモデル
• 検索、チャンク分割、リランキング
• 計算・データベース・文献検索などの外部ツール
• 出力形式と後処理
• 人による確認と承認

NISTのARIA 0.1では、事前に定めたプロンプトによるモデルテストだけでなく、レッドチーミング、実利用に近いフィールドテスト、専門家による注釈、利用者への質問票を組み合わせています［１］。生成AIの評価は、ベンチマークの正答率だけでなく、利用場面で要求を満たすかまで見る方向へ広がっています。

通常の機械学習評価と何が違うのか

分類や回帰では、正解ラベルと予測値を比較し、Accuracy、F1、RMSEなどを計算できます。一方、生成AIは一つの質問に対して複数の適切な表現があり、回答の長さや構成も一定ではありません。

また、次の回答は、同じ「不正解」でも原因が異なります。

• 正解文書を検索できなかった
• 正解文書は取得したが、必要な箇所を抽出できなかった
• 数値は抽出したが、単位を間違えた
• 式は正しいが、計算や丸めを誤った
• 必要項目の一部を書き忘れた
• 資料にない値を推測した

原因が異なれば対策も異なります。検索失敗なら埋め込みやチャンクを見直し、計算失敗ならPythonやRへ処理を渡し、要求漏れなら構造化出力や必須項目検査を導入します。

最初に決めるべき「評価の単位」

LLM Evalsは、モデルの採点から始めるのではなく、業務上の成功条件を分解するところから始めます。

研究開発データ向けRAGの設計でも述べたように、検索と生成を一つの点数へまとめず、段階ごとに評価することで改善点が明確になります。

生成AI評価で使われる主な指標

正確性

正解データと出力を比較します。短い数値やラベルには完全一致が使えますが、説明文では表現の違いを許容する採点基準が必要です。

研究開発では、回答全体の正誤だけでなく、材料名、条件、測定値、単位、出典など、項目ごとの正確性も測ります。

忠実性・根拠支持率

回答中の各主張が、提示された資料によって支持されているかを確認します。内容が一般的に正しくても、指定された資料に書かれていなければ「資料への忠実性」という評価では不合格です。

RAGASは、RAGを検索と生成の複数側面へ分け、取得文脈の関連性や回答の忠実性などを評価する枠組みです［２］。自動評価は大量のテストに有効ですが、重要な用途では人による確認も組み合わせます。

要求網羅率

質問で求められた項目のうち、正しく回答された割合です。例えば、焼結条件、初期強度、処理後強度、保持率、出典の5項目を要求し、3項目を正しく答えた場合は60％です。

回答が自然でも、研究条件の一つが抜ければ再現性や意思決定へ影響します。そのため、自由文だけでなく必須項目リストを使って採点します。

完全正答率

すべての必須項目が正しい回答の割合です。高い品質を要求する業務には重要ですが、この指標だけでは「ほぼ正しい回答」と「すべて間違った回答」を区別できません。項目単位の指標と併記します。

適切な棄権率と誤棄権率

資料内に答えがない質問へ、推測せず「確認できない」と回答できた割合が適切な棄権率です。一方、資料に答えがあるのに回答しなかった割合が誤棄権率です。

棄権を増やすだけなら誤答は減りますが、システムの有用性も下がります。2025年のUAEval4RAGでは、回答可能な質問の正確性と、回答不能質問への適切な対応を両方測る必要性が示されています［３］。

再現性・安定性

同じ質問を複数回実行し、結論、数値、引用、形式がどの程度一致するかを確認します。temperatureを0にしても、モデルや実行基盤、並列処理、サービス更新によって完全に同じ結果になるとは限りません。

モデル名、版、実行日、プロンプト、temperature、seed、検索条件、取得文書を保存します。

速度・費用・人の修正時間

正確性が同程度なら、回答時間、API費用、GPU使用量、人が修正する時間も重要です。研究開発では「正答率が高いが確認に時間がかかるシステム」より、「根拠箇所が明確で短時間に承認できるシステム」が実用的な場合があります。

材料科学のローカル実測例

ここでは、実在企業の材料や機密情報を含まない、架空の月面レゴリス模擬土に関する疑似報告書3件を用いた実験を、LLM Evalsとして再集計します。

評価用の質問

月面レゴリス模擬土LS-01について、−150℃から120℃までの熱サイクルを100回与えた後の圧縮強度が確認できる焼結条件を示してください。初期強度、熱サイクル後強度、強度保持率、出典も示してください。資料にない値は推測しないでください。

正解は次の5項目です。

1. 焼結条件：マイクロ波焼結1100℃、20分
2. 初期圧縮強度：48.3 MPa
3. 100サイクル後の圧縮強度：34.1 MPa
4. 強度保持率：70.6％
5. 出典：文書ID B

実行条件

全項目正答率は0％だった

モデルは5回とも、初期強度48.3 MPa、処理後強度34.1 MPa、出典Bを正しく回答しました。しかし、焼結条件を回答から落とし、保持率を70.5％と誤りました。正しくは次の計算です。

round(34.1 / 48.3 * 100, 1)
# 70.6

5項目すべてが正しい回答は0/5回だったため、完全正答率は0％です。これだけを見ると、システムは何もできなかったように見えます。

項目単位に分けると改善点が見える

この結果から、検索モデルや埋め込みを最初に変更する必要はありません。優先すべき対策は次の二つです。

1. 回答を固定スキーマにして、焼結条件などの必須項目を検査する
2. 保持率の計算を言語モデルからPythonなどの決定論的ツールへ移す

このように、Evalsは順位表を作るためだけでなく、次の改善箇所を決める診断として使います。

回答不能質問への棄権は5/5回成功した

文書には100サイクル後の値しかない状態で、「200サイクル後の強度」を質問しました。その結果、5/5回で「資料に記載されていないため回答できない」と回答し、値を外挿しませんでした。

この試験では、適切な棄権率は100％でした。ただし、質問は1種類だけです。実運用では、次のような回答不能問題を増やします。

• 必要条件が不足した質問
• 誤った前提を含む質問
• データベース外の質問
• 対応していない画像・音声を要求する質問
• 複数文書が矛盾する質問
• 安全・権限上、回答すべきでない質問

この実験の詳細は、生成AIのハルシネーションが起こる理由と検証方法およびRAGの研究開発での活用と限界でも解説しています。

評価データセットの作り方

1．実際の利用場面から質問を集める

一般ベンチマークだけでなく、利用者が実際に尋ねる質問、過去に間違えた質問、確認に時間がかかった質問を集めます。高頻度の質問と、頻度は低くても影響が大きい質問の両方を含めます。

2．難易度と失敗パターンを分ける

3．正解だけでなく採点規則を作る

正解文、許容表現、必須項目、許容誤差、棄権条件、禁止事項を記録します。数値では丸め桁、単位換算の可否、範囲表現を明確にします。

4．学習用・調整用・最終評価用を分ける

プロンプトやシステムを調整するときに使った質問だけで評価すると、その質問へ過適合します。最終評価用データは調整中に見ないように分け、定期的に新しい実例を追加します。

5．データセットの版を管理する

質問、正解、採点規則、参照文書にバージョンを付けます。文書更新で正解が変わる場合があるため、評価データと根拠文書の対応を保存します。

自動評価・人手評価・LLM-as-a-Judgeの使い分け

LLM-as-a-Judgeとは

生成AIの回答を、別のLLMに採点させる方法です。大量の自由文を評価できる利点があります。MT-Benchの研究では、人の選好との高い一致が報告された一方、回答位置、文章量、自己モデルを好む傾向、推論能力の限界なども示されています［４］。

研究用途では、LLM-as-a-Judgeだけで合否を決めず、次の対策を組み合わせます。

• 回答順を入れ替えて再採点する
• モデル名を隠す
• 具体的なルーブリックと採点例を与える
• 引用や数値はルールベースでも確認する
• 重要な失敗と境界事例は専門家が再確認する
• 人手評価との一致率を定期的に測る

オンライン評価とオフライン評価

オフライン評価

事前に用意した質問セットを使い、モデル、プロンプト、RAG構成の候補を比較します。安全に反復でき、回帰テストに向きます。

オンライン評価

本番利用時の修正率、再質問率、根拠リンクの閲覧、回答採用率、作業時間、利用者評価を測ります。実験室内の正答率が高くても、実務で使いにくければ改善が必要です。

公開前はオフライン評価を行い、公開後は匿名化・権限管理されたログからオンライン指標を確認します。重要な意思決定では、利用者が承認する段階を残します。

モデルやプロンプトを更新するときの回帰テスト

生成AIサービスは、同じ名称でも内部更新される場合があります。RAGの文書追加やチャンク変更でも、以前正しかった質問が誤る可能性があります。

変更前後で同じ評価セットを実行し、少なくとも次を比較します。

• 全体平均と重要カテゴリ別の成績
• 新しく正解した質問
• 以前正解していたのに失敗した質問
• 回答可能問題の誤棄権
• 回答不能問題への誤回答
• 処理時間と費用

平均点が上がっても、安全性や重要業務の成績が下がった場合は、そのまま更新しません。

研究開発向けLLM Evalsの実装手順

1. 用途を限定する：文献検索、実験条件抽出、解析支援など、対象業務を定義する
2. 失敗の影響を整理する：誤った数値、機密漏洩、誤った操作などを列挙する
3. 評価層を分ける：検索、抽出、忠実性、計算、回答、行動へ分解する
4. 評価セットを作る：通常、難問、回答不能、矛盾、権限問題を含める
5. 採点規則を固定する：必須項目、許容誤差、棄権条件を定義する
6. ベースラインを測る：現在のモデルとプロンプトを保存して実行する
7. 一要因ずつ変更する：モデル、チャンク、top-k、プロンプトを同時に変えない
8. 専門家レビューを入れる：重要な誤りと自動評価の境界事例を確認する
9. 公開基準を決める：重大項目の最低点と許容できない失敗を定義する
10. 本番で監視する：利用者の修正、失敗例、モデル更新を評価セットへ戻す

評価記録のテンプレート

{
  "eval_version": "1.0",
  "run_date": "2026-10-02",
  "use_case": "材料試験報告書からの条件抽出",
  "model": "モデル名と版",
  "prompt_version": "prompt-v3",
  "retrieval": {
    "embedding": "埋め込みモデル",
    "chunk": "1報告書1チャンク",
    "top_k": 1
  },
  "test_case": {
    "id": "LS01-001",
    "answerable": true,
    "required_fields": [
      "焼結条件",
      "初期強度",
      "処理後強度",
      "保持率",
      "出典"
    ]
  },
  "scores": {
    "retrieval_hit": true,
    "field_accuracy": 0.60,
    "complete_correct": false,
    "faithful": true,
    "appropriate_abstention": null
  }
}

モデル応答だけでなく、入力、取得文書、採点結果、実行条件を一緒に保存すると、後から原因を追跡できます。

よくある質問

何件あれば評価できますか？

初期段階では、代表的な質問と重大な失敗例を含む小規模セットから始められます。ただし、5件や10件の結果を一般化することはできません。運用ログから継続的に追加し、業務カテゴリごとの偏りを確認します。

公開ベンチマークで高得点のモデルを選べば十分ですか？

公開ベンチマークは基礎能力の比較に役立ちますが、社内文書、専門用語、出力形式、権限、棄権など固有要件は測れません。HELMのような多面的評価も参考にしながら、最終的には自社・自分の用途に合わせた評価を行います［５］。

LLM-as-a-Judgeだけで自動化できますか？

大量評価の一次判定には役立ちますが、評価モデルにもバイアスや誤りがあります。数値・形式はコード、専門的妥当性は人、文章比較はLLMのように分担するのが実用的です。

正答率と棄権率のどちらを優先すべきですか？

誤りの影響によって変わります。研究上の参考情報なら回答率も重要ですが、安全、規制、特許、顧客仕様などでは、誤った断定より適切な保留を重視します。回答可能問題の正確性と、回答不能問題の棄権を同時に測ります。

生成AIに統計解析を任せる場合も同じですか？

基本は同じです。解析手法の選択、コードの実行、前提条件の診断、数値、解釈を分けて評価します。詳しくは、生成AIによる統計解析の誤りと検証方法をご覧ください。

まとめ

LLM Evalsは、生成AIの優劣を一つの点数で決めるためだけの仕組みではありません。どの段階が機能し、どこを改善すべきかを明らかにするための測定設計です。

材料科学の実測例では、完全正答率は0％でしたが、正解文書の検索、主要数値、出典は100％成功していました。評価を分解したことで、「検索モデルを変更する」よりも「必須項目検査と計算ツールを追加する」という具体的な改善策を導けました。

私は10年以上の素材開発経験と、8年以上のインフォマティクス活用経験を持っています。その経験からも、生成AI導入で重要なのは、最新モデルを選ぶことだけではなく、現場の成功条件を測定可能な指標へ落とし込み、改善を継続できる仕組みを作ることだと考えています。

参考文献

1. Amironesei R, Godil A, Greenberg C, et al. Assessing Risks and Impacts of AI（ARIA）: Pilot Evaluation Report. NIST AI 700-2. 2025.
2. Es S, James J, Espinosa Anke L, Schockaert S. RAGAs: Automated Evaluation of Retrieval Augmented Generation. EACL System Demonstrations. 2024:150–158.
3. Peng X, Choubey PK, Xiong C, Wu CS. Unanswerability Evaluation for Retrieval Augmented Generation. ACL. 2025:8452–8472.
4. Zheng L, Chiang WL, Sheng Y, et al. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS. 2023.
5. Liang P, Bommasani R, Lee T, et al. Holistic Evaluation of Language Models（HELM）. Stanford CRFM.
6. Saad-Falcon J, Khattab O, Potts C, Zaharia M. ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems. NAACL. 2024.

本記事の実測例は、架空の疑似文書3件と小型ローカルモデルを用いた説明用試験です。特定モデル一般の性能を示すものではありません。記事内容と参考文献は2026年10月2日時点で確認しています。

ABOUT ME

モス

材料開発・データ解析の実務経験と、ベンチプレス180kg到達までの実践をもとに、筋トレ・データサイエンス・英語の情報を発信しています。

BLOG：https://www.mos-lantana.com