LLMを使ったアプリケーションが本番に進まない理由の一つは、「どのくらい正しければ使ってよいか」が決まっていないことだと私は見ている。デモでは良い答えが返ってくる。しかし、担当者が10問試して「だいたい合っている」と言うだけでは、本番に出す判断はできない。
ここでは、LLMの評価（Eval）の作り方を、評価セットの集め方、採点の方法、測る観点、合格ラインの決め方の順にまとめた。AnthropicやAIセーフティ・インスティテュート（AISI）が公開している資料と、LLMによる採点を検証した論文を下敷きにしている。
LLMが事実と違うことを答える問題そのものはハルシネーション対策で、PoCの前に決めておくことはAI開発の要件定義で扱った。この記事は、作ったものを測る方法を扱う。業務の現場に入ってこの評価から本番の運用までを受け持つ職種についてはFDEとは？に書いた。
ベンチマークと、業務で使うLLMの評価は別物
「LLMの評価」という言葉は、2つの違うものを指して使われる。
| モデルの評価（ベンチマーク） | アプリケーションの評価（Eval） | |
|---|---|---|
| 何を測るか | モデルそのものの一般的な能力 | 自社のプロンプト・データ・モデルを組み合わせたアプリケーション |
| 問題 | 公開された共通の問題 | 自社の業務から集めた質問と正解 |
| 使い道 | モデルを選ぶときの目安 | 本番に出してよいか、変更で悪くなっていないかの判断 |
| 誰が作るか | 研究機関やモデルの提供者 | 自社（業務の担当者と開発者） |
ベンチマークの点数が高いモデルでも、自社の書式、社内の用語、社内文書の検索の質によって結果は変わる。私の見方では、本番に出す判断に使えるのは右の列だけだ。以下は右の列の作り方を扱う。
評価セットの作り方
評価セットは、入力（質問や文書）と、期待する出力または採点基準の組を並べたものだ。Anthropicの評価の解説は、評価の設計について次の3つの原則を挙げている。
| 原則 | 解説の要旨 |
|---|---|
| タスクに即して作る | 実際のタスクの分布を写した評価を作る。エッジケースも入れる |
| できるだけ自動化する | 自動で採点できる形（選択式、文字列の一致、コードでの判定、LLMでの採点）に問題を組み立てる |
| 質より量を優先する | 人が丁寧に採点する少数の問題より、自動採点で信号が少し弱くても問題数が多いほうがよい |
同じ解説は、入れておくべきエッジケースの例として、関係のない入力や存在しないデータ、長すぎる入力、不適切または有害なユーザーの入力、人でも判断が分かれるあいまいなケースを挙げている。
集め方は、私の見方では次の順が進めやすい。
- 業務の実物から集める。問い合わせの履歴、過去の申請書、実際に担当者が受けた質問を使う。開発者が想像で作った質問は、実際より易しくなりやすい。
- 正解は業務の担当者が書く。開発者が書くと、業務上は間違っている「正解」が混ざる。
- 失敗した例を足し続ける。本番やテストで間違えた入力は、そのまま評価セットに加える。
最初から大きなセットを作る必要はない。数十問でも、毎回同じ問題で測れることのほうが大事だ。
採点の3つの方法と使い分け
Anthropicの解説は、採点の方法を3つに分け、それぞれの特徴を次のように書いている。
| 方法 | 解説の評価 | 向いている項目 |
|---|---|---|
| コードによる採点 | 最も速く信頼でき、規模を広げやすい。ただし、決まりごとで判断できない複雑な判断には細かさが足りない | 完全一致、キーワードを含むか、JSONの形式、数値の範囲 |
| 人による採点 | 最も柔軟で質が高いが、遅く高い。できれば避ける | 採点基準を作る段階、LLMの採点の確認 |
| LLMによる採点 | 速く柔軟で、規模を広げやすく、複雑な判断に向く。まず信頼できるかを確かめてから広げる | 要約の質、回答の丁寧さ、根拠に沿っているか |
右の列は私の整理だ。私の見方では、実務では3つを重ねて使う。形式や必須項目のように正解が決まるものはコードで落とし、残りをLLMに採点させ、そのLLMの採点が人の判断と合っているかを、人が一部抜き取って確かめる。
LLMに採点させるときの注意
LLMに採点させる方法は「LLM-as-a-Judge」と呼ばれる。2023年の論文「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」（NeurIPS 2023 Datasets and Benchmarks Track）は、GPT-4のような強いLLMの判定が人の好みと80%超一致し、人同士の一致と同じ水準だったと報告した。同時に、次の偏りがあることも示している。
- 位置の偏り: 2つの回答を比べさせると、提示した順番で判定が変わる
- 長さの偏り: 長い回答を高く評価しやすい
- 自己ひいき: 自分が生成した回答を高く評価しやすい
- 推論の限界: 推論の力に限りがあり、採点そのものを誤ることがある
Anthropicの解説も、採点させるときのコツとして、詳しく明確な採点基準を書くこと、「正しい／正しくない」や1〜5のように具体的な形で出させること、採点の前に考えさせることを挙げている。コードの例には、評価される出力を作ったモデルとは別のモデルで評価するのが一般的に望ましい、という注記もある。
これを踏まえると、LLMに採点させる前に次を決めておく。
| 決めること | 中身 |
|---|---|
| 採点基準 | 「何が書いてあれば正解か」「何が書いてあれば即不合格か」を文章で書く |
| 出力の形 | 合否か段階評価に限る。自由記述の感想を出させない |
| 採点するモデル | 回答を作るモデルとは別のモデルにする |
| 比べ方 | 2つを比べるときは順番を入れ替えて2回採点する |
| 人との突き合わせ | 一部を人も採点し、一致しない問題を見て採点基準を直す |
何を測るか——評価の観点
正しさだけを測っても、本番で困ることは防げない。AISIの「AIセーフティに関する評価観点ガイド」の第1.20版（2026年7月7日）は、LLMを構成要素とするAIシステムの評価観点として10個を挙げ、AIエージェント特有の観点として2個を加えている。
| 区分 | 観点 |
|---|---|
| LLMシステムの10の観点 | 有害情報の出力制御、偽誤情報の出力・誘導の防止、公平性と包摂性、ハイリスク利用・目的外利用への対処、プライバシー保護、セキュリティ確保、説明可能性、ロバスト性、データ品質、検証可能性 |
| AIエージェント特有の観点 | 自律的な挙動、外部環境との相互作用 |
業務のアプリケーションでは、私の見方では、まず次の5つを評価セットに入れる。AISIの観点のうち、業務の数字や事故に直結しやすいものを選び、費用と速さを足した。
| 観点 | 測り方の例 |
|---|---|
| 正しさ | 正解と照らして合否をつける（コードかLLM） |
| 根拠に沿っているか | 参照した社内文書に書いてないことを答えていないかをLLMが判定する |
| ロバスト性 | 誤字、長すぎる入力、関係のない質問を混ぜて、答えが崩れないかを見る |
| 安全 | 個人情報を出さない、指示を上書きする入力に従わないかを見る |
| 費用と応答時間 | 1件あたりの費用と、応答までの時間を記録する |
安全の観点で攻撃を試す方法はOWASP Top 10 for LLMにまとめた。
本番で使える精度の決め方
いちばん難しいのは、何点なら本番に出してよいかだ。私の見方では、精度の数字だけで決めると、どこに線を引いても根拠がない。次の2つを先に書き出す。
- 今その業務を人がやったときの誤りの程度。人の作業にも間違いはある。AIの合格ラインは、ゼロではなく、まず人と比べて決める。
- AIが間違えたときの損失の大きさ。社内の資料を探す手伝いで間違えるのと、顧客への回答で間違えるのとでは、許せる誤りが違う。
この2つから、業務ごとに線の引き方を変える。次の表は考え方の例で、数字を決めるのは業務の責任者だ。
| 業務の例 | 間違えたときの損失 | 線の引き方の例 |
|---|---|---|
| 社内文書の検索の補助 | 小さい。人が原文を見て確かめられる | 人の検索と同じ程度に見つかれば出す |
| 問い合わせの回答の下書き | 中くらい。担当者が送る前に読む | 担当者の手直しが減るなら出す。送信は人が行う |
| 顧客に直接返す回答 | 大きい。誤りがそのまま顧客に届く | 即不合格の誤りがゼロになるまで出さない。出したあとも抜き取りで確かめる |
合格ラインは一度決めて終わりではない。評価セットを増やし、本番の誤りを足していくと、同じ点数でも意味が変わる。
評価を回し続ける
AISIのガイドは、評価は一度だけでなく、繰り返し実施するものだとしている。また、客観的な評価のために、対象システムの開発や提供に直接携わらない専門家やサードパーティによる評価も有効だとしている。
LLMのアプリケーションは、モデルの版が上がる、プロンプトを直す、参照する文書が増える、のどれでも出力が変わる。私の見方では、評価セットは変更のたびに自動で流し、点数が下がった変更は出さない、という決まりにしておくのがよい。本番で回し続ける仕組み全体はLLMOpsとはにまとめた。
評価セットを作ると、「どこまでできれば使うか」を業務の担当者と開発者が同じ表で話せるようになる。私たちが業務の現場に入って、評価の設計から本番の運用までを進める支援の中身はサービス詳細に書いた。