🌡️

LLMプロダクトの評価はどう考えてどうやればいいの？

ojapi

2026/02/20に公開

!本稿における「LLMプロダクト」は、LLMを用いたプロダクトや機能のことを意味します。

 モチベーションLLMプロダクトの評価は難しい。
人事評価がとても難しいように、一見優秀に見えるLLMの主張やAIエージェントの行動を、一体どのように相対的に評価すれば良いのか。頭を抱えている方も多いと思います。
何を隠そう、かく言う私も頭を抱え続けている一人です。
という訳で、本稿では、LLMプロダクトをどのように評価すべきか、基本的な考え方を今一度整理することを目的に、現時点の情報をもとに調査した内容をまとめました。

 なぜ評価を行うのか？そもそもなぜ評価を行う必要があるのでしょうか？
評価を確立することで、サービスの受け入れ基準を定義することが可能になります。サービス改善の指針にすることも可能です。
しかし、それだけではなく、LLMプロダクトにおいては退行（リグレッション）抑制のためにも、評価が非常に重要になります。LLMプロダクトは、従来のソフトウェアと比較して退行が発生しやすい特性を持っています。主な要因として以下の2つが挙げられます。
1つ目は、サービス型LLMのサポート期間が非常に短いことです。

LLMプロダクトをいくつか運用している体感として、半年～1年に1回は必ずLLMを最新のバージョンに切り替える作業を行っています。利用しているモデルバージョンを変更すると、従来のプロンプトで正常に動いていたケースも、動かなくなることが多々あります。このように、頻繁なモデル更新を要する中で退行を検知するためには、評価データセットと手法を確立しておくことが重要です。
2つ目は、プロンプト調整による影響です。

サービス運用の中では、随時プロンプトの調整を行いますが、複数の指示や複雑なコンテキストを含むプロンプトにおいては、一箇所を修正すると別の箇所の指示を無視し始めるなどの、部分的な退行が発生することがあります。これらの退行を把握しながらプロンプト改善を継続するためには、評価という拠り所が必要になります。

 評価方法本章ではLLMプロダクトの評価方法について記述します。
LLMは多岐に渡る用途で利用可能であり、評価方法も様々に存在するものと思います。本稿においてはLLMプロダクトの出力を以下のように整理した上で、1~4の評価方法について記述をしていきます。

 1. 混同行列ベースの評価LLMを用いて分類や判断などを行うタスクにおいては、やはり古典的な混同行列ベースの評価が有効です。


https://note.com/anpanda_44075/n/n06364b57bf92 の図を参考に作成
混同行列や関連する各種指標の説明は、様々なところで良質な解説が読めるため、ここでは割愛します。LLMプロダクトの特性や重視したいことに応じて、再現率、適合率、正解率、F値といった指標を選択するのが良いと思います。
一例として、筆者が開発に携わった OLGA契約管理サービス のLLMプロダクトである「関連契約自動紐付け」という機能における評価について紹介します。
https://olga-legal.com/
この機能は、新しい契約書が保存された際に、関連のある既存の契約書を探し出して、自動で紐付けを行うものです。実現方法として、LLMワークフローを用いて契約書から多数の項目を抽出し、抽出項目が一致する契約書同士を紐づけています。本機能はLLMを用いたプロダクトではありますが、最終的なアウトプットは「紐づける / 紐づけない」であるため、シンプルな混同行列ベースの評価を行っています。
関連のない契約書間が誤って紐づいてしまう偽陽性の発生が、利用者の不満に繋がってしまうと考え、適合率を重視する方向で協働した他チームのメンバーに精度測定いただきました。


偽陽性の低減を目的として適合率で評価

 2. 伝統的な手法による評価LLMの生成文に対する評価として、以下のような伝統的な評価方法を利用することも可能です。


手法
説明


BLEU
主に機械翻訳タスクで用いられる手法。
生成文と参照文の一連の単語列(n-gram)の一致率を見る。

ROUGE-L
主に要約生成タスクで用いられる手法。
参照文と生成文の最長共通部分列（順序を保った共通部分）を評価する。

BERTScore
自然言語タスクで汎用的に利用される手法。
事前学習済みBERTから獲得できる文脈化トークン埋め込みを利用して、生成文と参照文の類似度を評価する。

各種指標の具体的な計算式についての説明は、ここでは割愛します。

詳細については、以下が大変参考になります。
https://gihyo.jp/book/2023/978-4-297-13633-8
BLEUやROUGEは、シンプルに評価を行うことが可能ではありますが、表層的な語彙の一致度に大きく依存した方法となるため、生成文に対する深いニュアンスを評価しきれないという問題があります。これを解決する方法として、LLMに内容を踏まえて評価させる「LLM-as-a-Judge」 が多く利用されるようになっています。

 3. LLM-as-a-Judgeによる評価LLM-as-a-JudgeはLLMを用いて評価を行う手法です。
LLM-as-a-Judgeに関するサーベイ論文[1]によると、LLM-as-a-Judgeとは、LLMを用いて事前に定義されたルール、基準、または嗜好に基づいて、対象物、行動、あるいは決定を評価する手法と説明されています。LLMが出力する評価結果は、スコア、選択肢、ラベル、文章など様々な形式を取り得ます。
https://arxiv.org/abs/2411.15594

 汎用的な指標を用いたスコアリングLLM-as-a-Judgeでは生成文章の内容評価を、「正確性」や「関連性」などの汎用的な指標を用いてスコア評価を行っているケースがよくあります。
ここでは、LLM-as-a-Judgeを簡単に行うことができる Langfuse にて、デフォルトで用意されている汎用的な指標をいくつか挙げてみます。


評価指標
日本語名
説明


Conciseness
簡潔性
提示された質問に直接的かつ簡潔に答え、不必要・無関係・過剰な詳細を含んでいないか。

Correctness
正確性
正解データに含まれるすべての重要な事実を含んでおり、かつ生成された各事実がいずれも正解データまたは常識的な知識によって事実的に裏付けられているかを評価する。

Hallucination
ハルシネーションの程度
生成内容が確立された知識、データ、または論理的推論と整合しているか。

Helpfulness
有用性
正確で関連性の高い情報を提供することでユーザーの質問に効果的に回答できているか。

Relevance
回答の関連性
生成された回答が質問の理解を深め、明確にしているか。

Toxicity
有害性
有害、攻撃的、不敬、あるいは否定的な態度を助長する言語、提案、または見解を含んでいるか。

Langfuseではこれらの指標を0~1の尺度でスコア評価させるデフォルトプロンプトが用意されています。
以下に、 Conciseness のデフォルトプロンプトを筆者の方で和訳したものを掲載します。
生成文の簡潔性を0から1の連続尺度で評価してください。
生成文は、提示された質問に直接的かつ簡潔に答え、求められている情報に焦点を絞り、
不必要・無関係・過剰な詳細を一切含まない場合、簡潔であると評価できます（スコア：1）。

具体例：
質問：ニンジンを食べると視力は向上しますか？
生成文：はい、ニンジンを食べることは視力、特に夜間視力を大幅に向上させます。これが、ニンジンをたくさん食べる人が眼鏡を必要としない理由です。これと異なることを言う人は、おそらく高価な眼鏡を売り込もうとしているか、あるいはこのシンプルで自然な治療法の恩恵を受けてほしくないと考えているのでしょう。眼鏡業界の影響によって、ニンジンなどの野菜が視力改善に役立たないという誤った認識が広まっているのは驚くべきことです。人々はこうした金儲けの策略に簡単に騙されてしまうものです。
スコア：0.3
評価理由：質問に対する回答は「ニンジンを食べると視力が向上する」という簡潔な事実だけで十分でしたが、実際の生成文には求められていない補足情報が多く含まれており、簡潔性に欠けています。ただし、もし科学的にニンジンが人間の視力を改善するメカニズムについての説明が含まれていた場合、それは妥当な内容であり、決して不必要とはみなされません。

入力：
質問：{{query}}
生成文：{{generation}}

段階的に考察してください。
上記のように汎用的な指標を用いてLLMに評価スコアを出力させる方法は、簡単に実装ができる反面、ざっくりとした曖昧な評価となってしまうこともあります。
この点について、過去の筆者のRAGシステムの評価における失敗例を踏まえて説明します。
RAGシステムの最終的な生成文を評価するために、以下のような評価プロンプトを用いてLLM-as-a-Judgeによるスコアリングを行いました。その結果、ほぼ全ての評価ケースが3点で採点されてしまい、評価として機能しているのかどうか良く分からないものとなってしまいました。（以下は実際の評価プロンプトの一部です。）
# 評価方法
以下の指標について、0~3点の範囲で評価を行ってください。（整数のみ可）

1. factuality_score: 「法務システムが生成した回答」の内容は「類似案件情報」に基づいて回答されているか
    - 0点: 回答は類似案件情報の内容を全く参照していない
    - 1点: 回答は類似案件情報の内容を部分的に参照しているが、全体的には参照していない回答が多い
    - 2点: 回答は類似案件情報の内容を概ね参照しているが、参照していない回答が一部ある
    - 3点: 回答は類似案件情報の内容を完全に参照している
(以下、複数の評価指標が続く...)
評価が偏ってしまい、有効性が曖昧になってしまった原因の一つとして、離散的な整数値で評価を行っているという点があります。
この点に対する解決策として、G-Eval論文[2]ではスコアの出力トークン確率を利用して、確率による加重平均で最終スコアを算出する方法を提案しています。


出力トークンの確率を用いた加重平均でスコア算出するイメージ
出力トークンの確率を取得できるモデルであれば、そのまま上記手法を利用することができますが、サービス型のクローズドモデルでは、これを取得することができないものもあります。そのため、G-Eval論文ではGPT-4を利用して、temperature を 1 に設定した上で、20回サンプリングを行い確率を推定するという方法を採っています。
しかし、そもそも、曖昧な評価指標を用いていること自体が、有効性に欠ける評価に繋がっている可能性があります。これを回避するための方法として、ルーブリックを用いた評価方法があります。

 ルーブリック評価の活用ルーブリック評価とは、明確な評価基準である"ルーブリック"を用意することによって、より厳格な評価を行う方法です。
ルーブリックが定義されているベンチマークデータセットとして OpenAIのHealthBench があります。このデータセットでは、ユーザーの入力プロンプトと、それに対する複数のルーブリック項目が与えられています。以下のようなイメージです。


https://openai.com/ja-JP/index/healthbench/ の内容から作成（和訳）
このデータセットにおいては、与えられた「ユーザーの入力」からLLMプロダクトが生成した内容が、各種ルーブリック項目を満たしていればスコアを加算していくという評価方法になります。ルーブリック項目には加点項目だけでなく、やってはいけないこと（落とし穴）を定めた減点項目も存在しています。
Rubrics as Rewards論文[3]によると、効果的なルーブリック項目を作成するためには、以下の4つの要件を満たしている必要があるとしています。


要件
説明


専門家の指導に基づくこと
正解に必要な本質的な事実、推論手順、結論を捉え、当該分野の専門知識を反映すべき。

包括的な網羅性
事実の正確性、論理的一貫性、完全性など、品質応答の複数側面をカバーすべき。否定的な基準（落とし穴）も設けることで、全体品質を損なう誤りを特定できる。

評価基準の重みづけ
ルーブリック項目ごとの重要度に差異があることを、重みなどを用いて反映すべき。正確性などは文体の明瞭さなどの二次的な要素よりも優先される必要がある。

自己完結的な基準であること
評価者（人間 or AI）が外部の文脈や分野固有の知識が無くとも正誤を判定できるような、明示的な評価基準内容になっていること。

また、このRubrics as Rewards論文の主題は、GRPOを用いたLLMの強化学習において、LLM-as-a-Judgeを用いた報酬関数におけるルーブリック評価の有効性を証明するものです。
https://arxiv.org/abs/2507.17746
ルーブリック評価の有効性を証明するために、以下それぞれの報酬スコアリング方法を比較しています。いずれもLLM-as-a-Judgeによる評価ではありますが、 RaR-* が付いた評価方法がルーブリックを用いたものになります。（RaR = Rubrics as Rewards）


報酬スコアの計算方法
説明


Direct-Likert
入力プロンプトとレスポンスのみから、レスポンスの品質を1-10のリッカート尺度で評価。

Reference-Likert
入力プロンプトとレスポンスと参考となる回答を与えて、レスポンスの品質を1-10のリッカート尺度で評価。

RaR-Implicit
入力プロンプトに対応するレスポンスの品質を、複数のルーブリック項目を提示し、それらを踏まえた総合的な品質を1-10のリッカート尺度で評価

RaR-Explicit
入力プロンプトに対するレスポンスを、単一のルーブリック項目によってスコア評価。事前に決められたルーブリックごとの重みで最終結果を計算。

実験結果として、ルーブリック評価を用いた RaR-Implicit が強化学習の報酬スコアリングとして最も高い優位性を示したと結論づけられています。
この実験において興味深いのは、ルーブリック項目ごとに評価を行った RaR-Explicit よりも、複数ルーブリックをまとめて1つのスコアとしてLLMに評価させた RaR-Implicit の方が優位であった点[4]です。
Anthropicの Research 機能の開発におけるブログ記事 においても、LLM-as-a-Judgeを用いた評価について、各評価項目ごとにLLMを実行したケースよりも、単一のプロンプト中で複数項目を評価した方が効果的であったという記述があります。
上記した2点について、強化学習の報酬関数とプロダクト出力の品質評価という用途の差異はありますが、類似した主張になっているのは興味深い点です。
https://zenn.dev/gvatech_blog/articles/68e9c89c894ff2#llm-as-judgeの活用

 4. AIエージェントの軌跡を評価AIエージェントを用いたLLMプロダクトでは、最終的なアウトプットだけでなく、エージェントが辿った軌跡も評価対象になり得ます。 非効率な行動や不当な行動を取ってないかを評価することができます。
軌跡（Trajectory）を評価するツールとして langchain-ai/agentevals や Google Cloud VertexAIの Gen AI Evaluation Service などがあります。
これらのツールに指定された形式でエージェントの実行結果を渡すことで、評価を行うことが可能なようです。以下のような評価方法が用意されています。

完全一致(Strict Match): 事前に定義した順番と値でtoolが呼ばれていることを評価

順序を問わない一致(Unordered Match): 事前に定義したtoolが順序を問わず呼ばれていることを評価
後述するAnthropicのブログ記事にも記載がありますが、人間が想定した方法よりもAIエージェントの方が最短経路で答えに辿り着く可能性があります。そのため、まずはAIエージェントの最終出力を評価することから検討し、必要に応じて軌跡を評価するという戦略が一般的なケースには良いものと考えます。

 評価の考え方・進め方2026年1月9日に、Anthropicによって公開されたブログ記事 Demystifying evals for AI agents では、AIエージェントの評価の考え方について様々な観点が記述されており、大変学びの多い内容でした。
本章では、このブログ記事からLLMプロダクトの評価の考え方や進め方について、非常に参考になった部分についてピックアップします。
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

 品質評価と退行評価評価については、以下2つのカテゴリで分けて考えると良いとしています。

 1. 品質評価（Capability）品質評価では 「このエージェントが何をうまく実行できるか」を評価します。エージェントが苦戦するタスクに焦点を当てることで、チームが改善すべき課題を明確に把握できるように設計すると良いようです。

品質評価においては、常にスコアが100%になるような評価飽和状態（Eval Saturation）を避けることによって、常に改善の余地を残すことを推奨するとのことです。

 2. 退行評価（Regression）退行評価では 「エージェントは従来通り全てのタスクを適切に処理できているか？」を検証します。ほぼ100%の通過率を目標とします。品質評価テストを利用しながら改善を進める際に、同時に退行が発生していないか退行評価テストも行いながらバランスを取ります。

開発初期に品質評価として用意したケースについて、リリースを迎えほぼ解決できるような状態になっていたら、これらを退行評価として昇格させると良いようです。

 評価方法確立までのSTEP上記のAnthropicのブログ記事では、評価指標が存在しない状態から、信頼性の高い評価指標を確立するまでの実践的なSTEPが紹介されています。LLMプロダクトの評価におけるロードマップとして利用することができそうです。


https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents より画像引用

 STEP0: 早期開始最初から何百もの評価タスクを作成する必要はなく、20~50程度のタスクから始めるだけで十分とのことです。評価タスクの作成は着手が遅れるほど困難となるため、早めに小さく始めることを推奨します。

 STEP1: 手動で実施しているテスト項目から始める開発段階で実施している手動テスト項目から、評価タスク化していくことを推奨しています。本番環境に既にリリースされている場合には、ユーザーからの不具合報告を評価スイートに組み込んでいくことも有効です。

 STEP2: 正解例と明確なタスクを作成する各評価タスクに対して、誰が見ても明確な正解例を作成することを推奨しています。同時に評価タスクの内容について、解釈曖昧性がなく確実に正解に辿り着けるような内容になっていることが、重要な前提になります。

 STEP3: バランスの取れた評価セットを構築するエージェントの行動が「発生する場合」と「発生しない場合」の両方がバランスよくテストできる評価セットを作ることが重要であると強調されています。
例として、Claude.aiのWeb検索ツールの評価テストでは、適切なタイミングで検索しない「過小トリガー」と、不適切なタイミングで検索する「過剰トリガー」のバランス調整が困難を極めたことが挙げられています。このプロジェクトにおいては、新たな問題が発生する度に、評価用データセットを継続的に拡張し、網羅性の向上を図る運用をしているとのことです。

 STEP4: 堅牢な評価を行うことができる安定した環境を構築する開発中のエージェントを試行する評価環境については、隔離されたクリーンな環境であることが重要です。残存ファイルやキャッシュデータや、リソース（CPU、メモリ不足）によって、エージェントの結果が変わらないよう、本番環境同様の評価環境を担保するべきとのことです。

 STEP5: 評価基準を慎重に設定するこのSTEPでは、慎重に最適な評価方法を選択することの重要性が主張されています。

可能であれば決定論的な評価方法を採用し、必要に応じてLLMベースの評価方法を、そして追加的な検証が必要な場合に限り人間による評価を活用することを推奨しています。
複数の構成要素からなるタスクの場合、部分的な評価を考慮すると良いようです。

問題を正確に特定し顧客を確認したものの、返金処理を失敗したサポートエージェントは、即座に失敗に終わるエージェントよりも実質的に優れているためです。
AIエージェントの軌跡を評価するのも考えうる手段ではありますが、エージェントは人間が想定しなかった創造的なアプローチで結果に辿り着く可能性もあります。創造性を不要に低評価することを避けるためにも、エージェントが選択した軌跡よりも、成果物そのものを評価する方が適切である場合が多いとのことです。

 STEP6: 評価実行トレースの確認評価テスト実行における、エージェントの実行記録であるトレースを閲覧可能な環境を構築し、常に確認できる状態にすることが継続的改善において重要とのことです。

 STEP7: 品質評価の飽和状態を監視する上記した通り、品質評価においては評価飽和状態を避けられるように監視し、必要に応じて適宜評価フレームワークを見直すことが重要であるとしています。

 STEP8: 評価スイートを長期的に健全に保つために、オープンな貢献とメンテナンスを継続する体制を構築する特定の能力や動作を測定するために設計された一連のタスク群である評価スイートは、生きた成果物であり、継続的なメンテナンスがあって初めて有用性を維持できます。
Anthropicでは、評価インフラは専任の評価チームが担当する一方で、評価タスクの作成と評価の実施自体はドメイン専門家や製品開発チームが行う体制が最も効果的であったとのことです。

 おわりにLLMプロダクトの評価方法や評価の進め方について、私なりの観点でまとめてみました。
今回、調査を終えて改めて感じたことは、LLMプロダクトの評価における銀の弾丸はなく、プロダクトの特性に適した評価セットや評価手法を、しっかり考え抜いて作り込んで行く必要があるということです。
ところで、本稿にて紹介したAnthropicのブログの中に、非常に感銘を受けた一文がありました。
評価タスクを定義することは、製品要件が具体化されており、開発を開始できるレベルにあるかどうかを検証する最良の手段
明日から、私はこれを三度詠唱してから業務を開始することとします。

評価、やっていきましょう。

脚注
A Survey on LLM-as-a-Judge https://arxiv.org/abs/2411.15594 ↩︎
G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment https://arxiv.org/abs/2303.16634 ↩︎
Rubrics as Rewards: Reinforcement Learning Beyond Verifiable Domains https://arxiv.org/abs/2507.17746 ↩︎
ただし、上記論文において、十分な説明可能性が求められるタスクにおいては RaR-Explicit も有効な選択肢であるとしています。RaR-Implicitでは全ルーブリック項目に対して1つのスコアが出力されるのみであり、どのルーブリック項目がスコアに影響したか明示的ではないためです。 ↩︎

手法	説明
BLEU	主に機械翻訳タスクで用いられる手法。生成文と参照文の一連の単語列(n-gram)の一致率を見る。
ROUGE-L	主に要約生成タスクで用いられる手法。参照文と生成文の最長共通部分列（順序を保った共通部分）を評価する。
BERTScore	自然言語タスクで汎用的に利用される手法。事前学習済みBERTから獲得できる文脈化トークン埋め込みを利用して、生成文と参照文の類似度を評価する。

評価指標	日本語名	説明
Conciseness	簡潔性	提示された質問に直接的かつ簡潔に答え、不必要・無関係・過剰な詳細を含んでいないか。
Correctness	正確性	正解データに含まれるすべての重要な事実を含んでおり、かつ生成された各事実がいずれも正解データまたは常識的な知識によって事実的に裏付けられているかを評価する。
Hallucination	ハルシネーションの程度	生成内容が確立された知識、データ、または論理的推論と整合しているか。
Helpfulness	有用性	正確で関連性の高い情報を提供することでユーザーの質問に効果的に回答できているか。
Relevance	回答の関連性	生成された回答が質問の理解を深め、明確にしているか。
Toxicity	有害性	有害、攻撃的、不敬、あるいは否定的な態度を助長する言語、提案、または見解を含んでいるか。

要件	説明
専門家の指導に基づくこと	正解に必要な本質的な事実、推論手順、結論を捉え、当該分野の専門知識を反映すべき。
包括的な網羅性	事実の正確性、論理的一貫性、完全性など、品質応答の複数側面をカバーすべき。否定的な基準（落とし穴）も設けることで、全体品質を損なう誤りを特定できる。
評価基準の重みづけ	ルーブリック項目ごとの重要度に差異があることを、重みなどを用いて反映すべき。正確性などは文体の明瞭さなどの二次的な要素よりも優先される必要がある。
自己完結的な基準であること	評価者（人間 or AI）が外部の文脈や分野固有の知識が無くとも正誤を判定できるような、明示的な評価基準内容になっていること。

報酬スコアの計算方法	説明
Direct-Likert	入力プロンプトとレスポンスのみから、レスポンスの品質を1-10のリッカート尺度で評価。
Reference-Likert	入力プロンプトとレスポンスと参考となる回答を与えて、レスポンスの品質を1-10のリッカート尺度で評価。
RaR-Implicit	入力プロンプトに対応するレスポンスの品質を、複数のルーブリック項目を提示し、それらを踏まえた総合的な品質を1-10のリッカート尺度で評価
RaR-Explicit	入力プロンプトに対するレスポンスを、単一のルーブリック項目によってスコア評価。事前に決められたルーブリックごとの重みで最終結果を計算。

GVATECHブログ

GVA TECH株式会社のテックブログです。

モチベーション

なぜ評価を行うのか？

評価方法

1. 混同行列ベースの評価

2. 伝統的な手法による評価

3. LLM-as-a-Judgeによる評価

汎用的な指標を用いたスコアリング

ルーブリック評価の活用

4. AIエージェントの軌跡を評価

評価の考え方・進め方

品質評価と退行評価

1. 品質評価（Capability）

2. 退行評価（Regression）

評価方法確立までのSTEP

STEP0: 早期開始

STEP1: 手動で実施しているテスト項目から始める

STEP2: 正解例と明確なタスクを作成する

STEP3: バランスの取れた評価セットを構築する

STEP4: 堅牢な評価を行うことができる安定した環境を構築する

STEP5: 評価基準を慎重に設定する

STEP6: 評価実行トレースの確認

STEP7: 品質評価の飽和状態を監視する

STEP8: 評価スイートを長期的に健全に保つために、オープンな貢献とメンテナンスを継続する体制を構築する

おわりに

Discussion