LLM評価の進め方｜モデル選定を導入判断につなげる比較基準・手順・チェックリスト

LLM評価とは、候補となる大規模言語モデル（LLM）や、その周辺のプロンプト、検索、ツール連携を含む仕組みが、自社の業務で求める品質・安全性・速度・費用を満たすかを確かめる活動です。

導入判断で重要なのは、「最も高いベンチマークを持つモデルはどれか」ではありません。どの業務の、どの入力に対して、どの失敗まで許容し、誰が確認するかを先に定義し、同じ評価ケース・同じ実行条件で候補を比べることです。

LLMは、もっともらしい誤情報や、入力と矛盾する内容を出力することがあります。NISTはこの現象をconfabulationとして整理しており、一般にハルシネーションやfabricationとも呼ばれると説明しています。重要な業務では、正答率だけでなく、誤りの影響、検知方法、人による確認まで評価対象に含める必要があります。NIST AI 600-1

本記事の評価手順、判定表、テンプレートは、特記がない限りMojiによる実務上の提案です。モデル、入力品質、評価指標、許容誤差、業務上の影響によって結論は変わります。

結論：LLM評価は「公開情報・ベンチマーク」「自社タスク」「運用」「リスク」の4層を分ける

公開ベンチマークは候補を絞る材料にはなりますが、そのまま採用判断には使えません。HELMは、複数のシナリオと複数の指標で言語モデルを評価する枠組みを提示し、正確性だけでなく、較正、頑健性、公平性、バイアス、有害性、効率性などを扱っています。単一スコアだけで、品質、安全性、効率性のすべてを代表させることには限界があります。HELM原論文

特にRAGやエージェントでは、モデル単体を評価しても不十分です。検索結果、渡したコンテキスト、ツールの実行可否、人へ引き継ぐ条件を含めて評価します。RAGの設計全体はRAGとは？導入すべき業務の判断基準・他方式との違い・評価の進め方、評価データの作り方はRAG評価データセットの作り方を参照してください。

最初に決めること：モデル名ではなく「業務上の合格」を定義する

評価を始める前に、経営・事業・現場の担当者で次の4点を合意します。Anthropicの公式ドキュメントでも、LLMアプリケーションでは具体的な成功基準を定め、実際のタスク分布とエッジケースを反映した評価を設計することが案内されています。Claude Platform Docs：Define success criteria and build evaluations

1. 対象業務：何を支援・自動化するか。例：問い合わせ分類、規程回答、議事録からのタスク抽出。
2. 成果物：何を出せば完了か。例：分類ラベル、根拠付き回答、構造化JSON、下書き。
3. 許容できない失敗：例：存在しない根拠の提示、個人情報の露出、送信・更新の誤実行。
4. 運用上の制約：誰が確認するか、回答待ち時間の上限、1件あたりの予算、利用量の見込み。

合格条件の書き方

「自然な回答をする」「精度が高い」といった表現だけでは、比較も改善もできません。以下のように、対象・条件・測り方・下限・失敗時の扱いを分けます。

評価条件テンプレート（Mojiによる提案）

• 対象業務：［業務名］
• 入力範囲：［文書種別、言語、平均・最大の長さ、画像の有無］
• 期待成果：［出力形式と必須項目］
• 品質指標：［正確性、根拠整合、形式適合、漏れ、表現など］
• 合格下限：［指標ごとの下限］
• 重大失敗：［発生時点で不合格にする事象］
• 運用条件：［応答時間、1件あたりの費用、確認者、ログ保存］
• 判定責任者：［導入可否を決める役割］

架空の例：「問い合わせを3分類できる」ではなく、「事前に定義した保留条件に該当する問い合わせは分類せず人へ回し、それ以外は指定ラベルのみを返す。誤振り分けのうち、契約・請求に関わるものは重大失敗として別集計する」と定義します。正答数が同じでも、どの誤りを起こしたかで採用判断は変わります。

LLM評価の比較軸：品質だけで順位を決めない

上表は一般的な設計上の目安です。最適な比重は、モデル、入力データの品質、評価指標、許容誤差、誤りが業務へ与える影響によって変わります。たとえば、社内文書の下書きでは表現品質を重視しやすい一方、顧客への送信やデータ更新では、禁止操作率・確認可能性・復旧容易性を優先します。

実務で使う評価方法：自動採点、人手評価、LLM-as-a-Judgeを使い分ける

1. 自動採点：正解が明確なタスクを大量に測る

分類、抽出、固定形式の出力、コード実行結果などは、自動採点が向きます。対象ケースを増やしやすく、モデル・プロンプト・検索設定の変更を継続比較できます。Anthropicの公式ドキュメントでも、選択式、文字列一致、コード評価、LLMによる評価など、自動化できる形式へ構造化する考え方が案内されています。Claude Platform Docs：評価設計の原則

2. 人手評価：重大な誤りと業務価値を判定する

自然な文章、説明の分かりやすさ、実務で使えるかといった評価は、人によるルーブリック評価を残します。ただし、「全体的に良いか」だけでは担当者ごとに基準がぶれます。採点者には、必須要件、減点対象、重大失敗、保留の扱いを渡してください。

3. LLM-as-a-Judge：主観評価の量を増やす補助

LLM-as-a-Judgeは、別のLLMにルーブリックに沿った採点や比較をさせる方法です。自由記述の比較を高速化できますが、導入判断を判定モデルだけに委ねるべきではありません。MT-Bench／Chatbot Arenaの研究は、LLM-as-a-Judgeで生じる提示順、冗長さ、自己優遇などの偏りを検討し、人の選好との一致も評価しています。Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

Mojiでは、LLM-as-a-Judgeを使うなら、人手評価との一致度を先に確認し、回答の提示順を入れ替え、採点ルーブリック・判定モデル・バージョンを記録することを提案します。仕組みと注意点はLLM as a judgeとは？自動評価の仕組みと活用例で解説しています。

評価データセットの作り方：平均ケースだけでなく、失敗を再現する

評価データは、公開データセットをそのまま流用するより、業務で実際に起こる入力を匿名化・権限確認したうえで使う方が、選定判断に直結しやすくなります。最低限、次の4群を含めます。

• 通常ケース：最も多い入力。日常業務の基準性能を測る。
• 難しいケース：長文、曖昧な依頼、複数条件、表記ゆれを含む入力。
• 境界ケース：正解が複数あり得る、情報不足、対象外の依頼。
• 重大失敗ケース：誤ると損害、契約違反、誤送信、権限逸脱につながる入力。

評価用データには、少なくとも「入力」「期待する結果または判定基準」「正しい根拠」「重要度」「失敗分類」を持たせます。RAGの場合は、質問と回答だけでなく、正解根拠となる文書・箇所も紐付けてください。最終回答が悪いときに、検索の失敗なのか、根拠を使わない生成の失敗なのかを切り分けられるためです。RAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説

LLM評価を導入判断へつなげる6ステップ

1. 候補を絞る：入出力、データの取り扱い、リージョン、ツール連携、契約条件など、非機能要件で候補を外す。
2. 合否ゲートを決める：重大失敗、必須形式、最大待ち時間、予算上限を先に定義する。
3. 評価ケースを固定する：通常・難問・境界・重大失敗を含む評価セットを作り、採用候補へ同じ入力を渡す。
4. 実行条件を記録する：モデルID、プロンプト、検索設定、ツール、温度などの生成設定、実行日時、評価データ版を残す。
5. 結果を層別する：平均点だけでなく、業務種別、入力長、難易度、失敗分類、再試行の有無で分けて確認する。
6. 導入・限定継続・見送りを決める：合否ゲートを満たさない候補は、平均点が高くても本番採用しない。満たす候補だけを運用コスト・改善余地・供給リスクで比較する。

NIST AI RMF Playbookは、AIリスク管理をGovern、Map、Measure、Manageの4機能で整理しています。評価を一度の比較で終わらせず、責任、利用文脈、測定、対応を運用としてつなげる際の参考になります。NIST AI RMF Playbook

意思決定シート：候補の平均点ではなく「採用可能か」を見る

この表では、重大失敗ゲートを通過しない候補を、加重平均で救済しないことが重要です。一方、すべての候補がゲートを通過した場合に限り、品質、総コスト、速度、運用負荷を比較して優先順位を付けます。

本番後も評価を続けるべき変化

LLM評価はモデル選定時だけの作業ではありません。モデル更新、プロンプト変更、検索対象の追加、文書改訂、ツール権限の変更で、出力品質とリスクは変わります。NIST AI RMF PlaybookのMEASURE 3.3では、エンドユーザーや影響を受けるコミュニティが問題を報告し、システムの結果へ異議を申し立てるためのプロセスを設け、それをAIシステムの評価指標へ統合することが示されています。NIST AI RMF Playbook：MEASURE 3.3

• モデル、プロンプト、検索設定、ツールを変更する前後
• 業務文書・商品・規程・FAQを追加または改訂した後
• 重大な誤り、苦情、手戻り、誤操作が発生した後
• 利用部署・利用言語・入力データの範囲を広げる前

本番化の判断基準、移行ゲート、定着指標はAI PoCを本番化する進め方、誤情報を含む文書の承認・改善フローは生成AIの正確性課題とは？企業文書の誤情報を防ぐ評価・承認・改善フローも参照してください。

LLM評価チェックリスト

• 公開ベンチマークを候補選定の参考にとどめ、自社入力で比較したか
• 対象業務、期待成果、重大失敗、確認者を文章で定義したか
• 通常・難問・境界・重大失敗の各ケースを評価セットに含めたか
• モデル単体ではなく、プロンプト、検索、ツール、権限を含めて測ったか
• 自動採点、人手評価、LLM-as-a-Judgeの役割を分けたか
• モデルID、設定、評価データ版、実行日時、採点ルールを記録したか
• 平均値だけでなく、失敗分類・業務別・難易度別に結果を見たか
• 重大失敗の発生時に、平均点が高くても不採用とするゲートを置いたか
• 本番後の再評価契機、停止条件、改善の責任者を決めたか

LLM評価の目的は、モデルの絶対的なランキングを作ることではありません。自社が許容できる失敗の範囲で、どの業務を、どこまで、どの条件なら任せられるかを説明可能にすることです。評価セットと運用条件を資産として残せば、モデルや実装を入れ替える場面でも、同じ基準で再判断できます。