LLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】

LLM評価は、大規模言語モデルやそれを組み込んだアプリケーションの出力品質を、再現可能な手順で測る工程です。同じ入力を与えても出力が毎回変わるため、単体テストのような合否判定は成り立ちません。そこで公開ベンチマーク、文字列一致の自動指標、人手評価、そしてLLMに採点させるLLM-as-a-Judgeを目的ごとに組み合わせます。この記事では、モデル評価とアプリ評価の分離線、評価データセットの件数と難易度の決め方、lm-evaluation-harness・DeepEval・promptfoo・llm-jp-evalの守備範囲と2026年8月時点の実測版数、そして評価基盤を作らないでよい条件までを実装者の視点で整理します。

まとめ：LLM評価で最初に決める3点と、着手の順序

最初に決めるのは3点です。測る対象（モデルか、プロンプトを含むアプリか）、正解の持ち方（正解文字列があるか、判断基準しかないか）、そして採点者（人か、LLMか、機械的な一致か）。この3点が決まれば、使うべき指標とツールはほぼ一意に絞れます。

着手の順序は、公開ベンチマークからではなく自社の本番ログから始めるのが早道です。本番の入出力を50件ほど抜き出し、人が5段階で採点した表を作る。その表を基準にLLM-as-a-Judgeのプロンプトを校正し、人手スコアとの相関が取れた時点で自動化に移す。この順にすると、評価基盤に着手する前に「何を良い出力と呼ぶか」の合意が社内で先に取れます。

逆に、評価基盤を先に作ると失敗しやすくなります。採点基準が固まらないままダッシュボードだけが増え、数字が動いても誰も解釈できない状態に陥るためです。プロンプトが月に数回しか変わらず、出力を人が全件確認できる規模であれば、評価基盤は作らないという判断も成立します。

LLM評価の対象範囲と、モデル評価とアプリ評価を分ける実務上の判断線

LLM評価という言葉は、モデルそのものの能力測定と、モデルを組み込んだアプリの品質測定の両方を指します。混同すると、どのツールを入れても目的に届きません。

LLM評価の定義と、出力の良し悪しを再現可能な形で測る工程の全体像

LLM評価とは、評価用の入力集合、期待される出力または判断基準、採点方法、集計方法の4つを固定し、モデルやプロンプトを変えたときにスコアの差だけを比較できる状態を作る工程を指します。固定されていない要素が1つでもあると、スコアの上下が改善によるものか偶然かを切り分けられません。

温度パラメータやシード、few-shotの例示件数も固定対象に含めます。llm-jp-evalのREADMEでも、事前学習モデル用と指示チューニング済みモデル用で設定ファイルを分ける運用が案内されており、few-shotの与え方が結果に効くことが前提になっています。評価条件を書き残さないスコアは、後から再現できず資産になりません。

モデル評価とアプリ評価の違いと、開発現場で担当が分かれる境界線

モデル評価は「GPT系とClaude系とローカルモデルのどれを採るか」を決めるための測定で、公開ベンチマークのスコアや自社タスクでの正答率を見ます。アプリ評価は「このプロンプトとこの検索設定で、業務に耐える出力が出るか」を決める測定です。前者はモデル選定の一度きり、後者はプロンプトを変えるたびに繰り返します。

実務上の境界線は、変更の頻度で引くとうまくいきます。四半期に一度しか動かないモデル選定に自動化を作り込む必要は薄く、週に何度も動くプロンプト変更のほうに自動評価を寄せる。検索を伴うアプリであれば、検索側の指標は別工程になるためRAG評価の考え方と指標の分け方を先に押さえたうえで、生成側だけを本記事の範囲で測ります。

オフライン評価とオンライン評価の使い分けと、測定する時点の違い

オフライン評価は、固定した評価データセットに対してリリース前に採点する方式です。オンライン評価は、本番トラフィックの一部をサンプリングして採点します。前者は再現性が高く比較に向き、後者は実際のユーザー入力の分布を反映します。

両方を回すのが理想ですが、オンライン評価は採点のたびに推論コストが乗ります。全件採点は費用が跳ねるため、まずは数％のサンプリングから始めて、指標が荒れる場合だけ率を上げる。トレース収集や費用監視まで含めた運用の組み立てはLLMOpsとして整理した運用の型の側で扱っており、本記事は採点の中身に絞ります。

自動指標・人手評価・LLM-as-a-Judgeの3方式と適用条件の切り分け

採点方法は大きく3つです。どれが優れているかではなく、正解の持ち方によって使える方式が決まります。

BLEU・ROUGEなど文字列一致指標が機能する条件と限界の実例

BLEUやROUGEは、生成文と参照文のn-gram一致率を測る指標です。翻訳や定型的な要約のように、正解文が1つに近い形で存在するタスクでは今も有効に働きます。計算コストがほぼゼロで、CIに載せても実行時間が伸びません。

限界がはっきり出るのは、言い換えが許される自由記述です。「解約は管理画面から手続きできます」と「管理画面で解約手続きが可能です」は同義でも、n-gramの重なりは小さくなります。ここでスコアが下がっても品質は落ちていないため、自由記述の主指標には使えません。埋め込みベクトルの類似度で補う手もありますが、意味の近さと正しさは別物で、誤った内容でも語彙が近ければ高得点になります。

人手評価の設計とコストの見積り、評価者2名体制と一致率の測り方

人手評価は最も信頼できる代わりに、費用と時間が重くのしかかります。設計の要は、採点基準を先に文章化することです。5段階なら各段階の該当例を1つずつ書き、境界にあたる出力を「3か4か」で迷わないところまで具体化します。

評価者は2名以上を置き、同じ出力を独立に採点させて食い違いを数えます。食い違いが3割を超えるようなら、モデルの問題ではなく採点基準の記述が曖昧だと判断してください。基準を直してから採点をやり直すほうが、結局は早く終わります。1件あたりの採点時間を実測しておくと、評価データセットの件数を増やす判断も見積もれます。

LLM-as-a-Judgeの仕組みと、人手スコアとの相関で校正する手順

LLM-as-a-Judgeは、採点基準（ルーブリック）を書いたプロンプトを別のLLMに与え、対象の出力を採点させる方式です。自由記述を意味の面から採点できるため、文字列一致指標が使えない領域を埋めます。ただし採点器そのものが確率的に振る舞うため、校正なしでは数字を信用できません。採点器としてのLLMの仕組みそのものはLLM-as-a-Judgeの手法解説で詳しく扱っています。

校正の手順は決まっています。人手で採点済みの数十件を用意し、同じ出力をJudgeにも採点させ、両者の相関を見る。相関が低ければルーブリックの記述を直し、再度突き合わせる。相関係数0.6程度を目安として挙げる解説が多く、この水準に届かないうちは自動採点の結果を意思決定に使わない運用が無難です。エージェントのように複数ステップの軌跡を採点する場合は評価の単位自体が変わるため、AIエージェント評価で軌跡を測る方法を別立てで参照してください。

評価データセットの作り方と、件数・難易度・更新頻度を決める実務基準

評価の質は、ツールよりもデータセットで決まります。手元に良いデータセットがあれば、採点方法は後から差し替えが利きます。

評価データセットに含める4項目と、本番ログから抽出する具体手順

1件あたりに持たせる項目は4つです。入力、期待される出力または判断基準、そのケースを入れた理由、想定される失敗の型。3つ目と4つ目が抜けると、半年後に見直したときに削ってよいケースかどうかを誰も判断できなくなります。

1. 本番ログから直近1か月分の入出力を抽出する
2. 問い合わせ内容の種類でグループ分けし、件数の多い順に並べる
3. 各グループから代表例を機械的に取り、偏りを避ける
4. 苦情やリトライが発生した会話を、失敗例として別枠で拾う
5. 個人情報を含む箇所を匿名化し、判断基準を人手で書き足す

この手順で作ると、机上で考えた質問文よりも本番の分布に近いデータセットになります。匿名化を後回しにすると評価環境の取り扱いが面倒になるため、抽出直後に済ませてください。

件数の決め方：50件から始めて相関が安定する規模まで増やす基準

初期は50件前後で足ります。少なすぎると1件の増減でスコアが数％動きますが、最初に必要なのは精密な絶対値ではなく、プロンプトを変えたときの方向が読めることです。

増やす合図は2つあります。プロンプトを変えてもスコアが動かなくなったとき（難易度が飽和している）、そして同じ変更を2回測ってスコアの差が改善幅より大きいとき（サンプルが足りない）。後者に当たったら、まずは倍の100件を目指す。数千件規模が必要になるのは、モデルの微調整結果を比較する段階に入ってからです。

難易度の配分と、過去の失敗例を意図的に含める負例セットの作り方

全問正解するデータセットは、改善の役に立ちません。目安として、現行構成で7割前後が合格する難易度に配分を寄せます。簡単すぎるケースは回帰検出のために少数だけ残し、大半は判断が割れる帯に置く。

負例セットは別枠で管理します。実際に苦情が来た出力、社外に出してはいけない情報を漏らしかけた入力、答えられないと言うべきなのに答えてしまった質問。この3類型を集めておくと、プロンプト変更で古い不具合が復活したときに即座に気づけます。攻撃者視点で意図的に破る入力を作る作業は範囲が異なるため、専門の工程として切り出すほうが整理しやすくなります。

評価データセットの更新頻度と、陳腐化を検知する2つの実務的な合図

更新は四半期ごとの棚卸しを基本とし、機能追加のタイミングで臨時に足します。放置すると、実際のユーザー入力とデータセットの分布がずれていきます。

陳腐化の合図は2つ。オフライン評価のスコアは高いのに本番の苦情が減らないこと、そして本番ログの上位グループがデータセットに1件も入っていないこと。どちらかを検知したら、件数を増やす前に分布を作り直してください。古い分布のまま件数だけ増やしても、測っていない領域は測れないままです。

日本語LLMの評価に使える公開ツールと2026年8月時点の版数

日本語のタスクを扱う場合、英語圏のベンチマークだけでは判断材料が足りません。日本語向けに整備された公開ツールが2つあります。

lm-evaluation-harnessの位置づけと0.4系の版数・ライセンス

EleutherAIのlm-evaluation-harnessは、公開ベンチマークを共通の手順で一括実行するための土台です。GitHub APIで確認したところ、2026年8月9日時点の最新リリースは v0.4.12（2026年5月11日公開）、ライセンスはMIT、スター数は13,576でした。多くのモデル公開元が自社スコアの算出にこの実装を使っており、条件を揃えた比較の共通言語になっています。

ただし測れるのは「ベンチマークのタスクに対する能力」であって、自社アプリのプロンプトの良し悪しではありません。モデル選定の段階で使い、選定後はアプリ側の評価に切り替えるのが実務の流れです。

llm-jp-evalとllm-jp-judgeが担う日本語評価の範囲と最新版

llm-jp-evalは、日本語の公開データセットを評価用に整形し、推論と採点をまとめて回すツールです。2026年8月9日時点で最新リリースは v2.1.5（2026年6月3日公開）、ライセンスはApache-2.0。READMEではTaskfileによる推論と評価の一括実行と、vLLMのOpenAI互換サーバ経由での同期評価が案内され、並列数はmax_concurrentで調整します。

llm-jp-judgeは、日本語のLLM-as-a-Judge評価を担う別リポジトリで、最新リリースは v2.0.0（2026年7月15日公開）、ライセンスはApache-2.0です。生成品質、マルチターン対話、応答の安全性という3つの観点に対応しており、日本語のルーブリックをゼロから書き起こす前に参照する価値があります。スター数は前者が166、後者が55と小規模ですが、日本語評価の設計を追える一次資料としての位置づけです。

公開ベンチマークのスコアを社内のモデル選定に使うときの2つの落とし穴

1つ目は汚染です。ベンチマークの問題文がモデルの学習データに含まれていれば、スコアは実力を上回ります。公開から時間が経ったベンチマークほどこの疑いが強くなるため、リーダーボードの順位差が数ポイントなら誤差として扱ってください。

2つ目はタスクのずれ。社内文書の要約に使うモデルを、常識推論や数学の正答率で選んでも接点がありません。公開スコアは足切りに使い、最終判断は自社の評価データセットで行う。MT-Benchの実装元であるlm-sys/FastChatは2026年5月1日を最後にプッシュが止まっており、スコアの前提となる実装の更新状況まで見ておく必要があります。

評価ツール3種の守備範囲比較と、社内に常設するツールの選定基準

評価ツールは目的が異なる3系統に分かれます。1つで全部をまかなおうとすると、どこかで無理が出ます。

DeepEval・promptfoo・harnessの守備範囲と実測した版数の比較

3つの守備範囲を、2026年8月9日にGitHub APIで実測した版数とあわせて整理します。

DeepEvalはアプリの出力に対する指標をコードで定義し、テストとして実行する設計です。promptfooは複数のプロンプトやモデルを並べて出力を突き合わせる用途に強く、比較表の形で差分を確認できます。なお、かつて標準的だったopenai/evalsは、2026年8月9日時点で releases にタグがなく最終プッシュも2026年4月14日で、新規採用の第一候補には置きにくい状況です。RAGの指標をそのまま使いたい場合はRagasの指標と実装手順を先に確認すると、自前実装の手間を削れます。

CI組み込みの判断と、評価をパイプラインに載せる際の実行時間の目安

CIに載せるかどうかは、実行時間と費用で決まるものです。50件をLLM-as-a-Judgeで採点すると、採点用モデルの呼び出しが50回発生し、待ち時間は数分規模になります。プルリクエストごとに回すには重いため、多くの現場では2段構えにします。

• プルリクエスト時：文字列一致とルール検査だけを走らせ、1分以内で終える
• マージ後の夜間：評価データセット全件をJudgeで採点し、前回との差分を記録する
• リリース前：負例セットを追加で回し、既知の不具合の再発を確認する

この分け方なら、開発者の待ち時間を延ばさずに回帰を検出できます。夜間実行の結果は、スコアの絶対値ではなく前回比で見るのが実務的です。

トレース基盤との接続：Langfuse v4系と評価ツールの役割分担

オンライン評価を回すには、本番の入出力が保存されている必要があります。トレース基盤はその保存と検索を担い、評価ツールは採点を担う。この分担を最初に決めておくと、後から採点方法を差し替えても記録は残ります。

Langfuseは2026年8月6日に v4.6.0 が公開されており、更新が続く状況です。トレース基盤側にスコアを書き戻せる構成にしておけば、「どのプロンプト版のときにスコアが落ちたか」を後から追跡できます。逆に採点結果をツール側にしか持たない構成にすると、原因究明のたびにログを突き合わせる作業が発生します。

評価基盤を作らない判断と、LLM-as-a-Judgeを信用してよい条件

ここからは判断を言い切ります。評価は投資であり、規模に見合わなければ作らないほうが結果は良くなります。

評価基盤を作らないでよい3条件と、作るべきに切り替わる判断の分岐点

次の3条件がすべて当てはまるなら、評価基盤は作らないでください。プロンプトの変更が月1回以下であること、1日の生成件数が数十件規模で人が全件を目視できること、出力の誤りが業務に与える損害が限定的で、人の確認が最終工程に入っていること。この状態では、採点の自動化に投じた工数が回収できません。

分岐点は明確です。人が全件を見られなくなったとき、または誤った出力が確認を通過して外部に出る経路ができたとき。この2つのどちらかが起きた時点で、まず50件のオフライン評価から着手します。生成件数が伸びる見込みだけを根拠に先回りして基盤を作るのは、過剰投資になりやすい判断です。

LLM-as-a-Judgeを信用してよい条件と、採用を見送るべき場面

Judgeを意思決定に使ってよいのは、人手スコアとの突き合わせが済み、ルーブリックが更新履歴とともに管理されている場合に限ります。校正を経ていないJudgeのスコアは、モデルの機嫌を測っているだけです。採点器のモデルを変えたときも、校正はやり直してください。

見送るべき場面もはっきりしています。医療・法務・金融の判断に直結する出力の合否を、Judgeだけで決めてはいけません。誤りの損害が非対称に大きい領域では、Judgeは人手確認の対象を絞り込む道具として使い、最終判定は人が持つ。また、採点対象が事実の正誤である場合、Judge自身が同じ誤りを共有している可能性があるため、参照文書と突き合わせる検査に置き換えるほうが確実です。

評価の外部委託で見積書に書かせる4項目と、成果物の受け取り条件

評価の設計を外部に頼む場合、見積書に次の4項目を明記させてください。評価データセットの件数と作成方法、採点基準の文章と改訂履歴の管理方法、Judgeを使う場合の人手スコアとの相関の実測値、そして納品後に自社だけで再実行できる手順書の有無。この4つが書かれていない見積は、成果物が引き継げないまま終わります。

受け取り条件は「自社の環境で同じスコアが再現できること」に置きます。再現できないなら、それは評価ではなく一度きりの調査です。LLMを組み込んだ業務システムの設計から評価の型づくりまでを含めて相談したい場合は、生成AI導入支援で要件の整理から引き受けています。委託範囲を決める前に、社内で測りたい品質を1文で書けるかどうかを確認しておくと、見積の精度が上がります。

よくある質問

LLM評価の実装でよく出る疑問を5つ挙げ、判断の基準とあわせて回答します。

LLM評価は何件のデータから始めればよいですか？

本番ログから抜き出した50件前後で始めてください。この規模なら人手採点が半日から1日で終わり、採点基準の曖昧さも早期に洗い出せます。件数を増やすのは、プロンプトを変えてもスコアが動かなくなったときか、同じ変更を2回測ってスコアの差が改善幅を上回ったときです。いきなり数千件を用意しても、採点基準が固まっていなければ作り直しになります。

LLM-as-a-Judgeの採点はどれくらい信用できますか？

人手スコアとの相関を実測していない状態では、信用できません。人手採点済みの数十件と突き合わせ、相関が取れることを確認してから使ってください。相関係数0.6程度を目安に挙げる解説が多く、それに届かない場合はモデルではなくルーブリックの記述を直します。採点に使うモデルを変更したときも、校正はやり直しが必要です。

BLEUやROUGEは今でも使う場面がありますか？

翻訳や定型的な要約のように、正解文がほぼ1つに定まるタスクでは有効です。計算コストがほぼゼロなので、プルリクエスト時の軽量な回帰検出にも向いています。一方、言い換えが許される自由記述では、同義の出力でもスコアが下がるため主指標にはできません。自由記述はLLM-as-a-Judgeか人手評価に寄せてください。

日本語のLLM評価に使える公開ツールはありますか？

llm-jp-eval と llm-jp-judge が代表的です。2026年8月9日時点の最新リリースは前者が v2.1.5（2026年6月3日）、後者が v2.0.0（2026年7月15日）で、どちらもApache-2.0です。llm-jp-judgeは生成品質・マルチターン対話・応答の安全性の3観点に対応しており、日本語のルーブリックを自作する前の参照先になります。

評価をCIに組み込むと開発が遅くなりませんか？

全件をLLM-as-a-Judgeで採点する構成にすると遅くなります。プルリクエスト時は文字列一致とルール検査だけを1分以内で回し、Judgeによる全件採点はマージ後の夜間に寄せる2段構えにしてください。夜間実行の結果はスコアの絶対値ではなく前回比で見ると、回帰の検出に集中できます。

関連記事

• LLMとは？大規模言語モデルの仕組み・生成AIとの違いと企業導入の判断基準を解説：評価の前提となるLLM本体の仕組みと導入判断を整理しています。
• Weights & Biasesとは？実験管理の仕組みとWeave・料金・MLflowとの使い分け：評価スコアを実験単位で記録・比較する道具の選び方を扱っています。
• AIレッドチーミングとは？生成AIの脆弱性を洗い出す実施手順とツール選定：負例セットの発展形として、攻撃者視点で入力を作る工程を解説しています。
• LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説：評価の実行時間を左右する推論側の設計を扱っています。