LLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説

LLM評価（Evals）とは何か

LLM評価とは、LLMを組み込んだアプリの出力品質を、事前に定義したデータセットと採点基準で継続的に測る仕組みです。開発中のプロンプト調整からリリース後の劣化検知まで、判断を「感覚」から「指標」に置き換える役割を担います。

定義：期待する出力を満たしているかを再現可能に測る仕組み

Evalsは大きく「入力例・期待挙動・採点方法」の3点セットです。入力例は本番で来るクエリを模したデータ、期待挙動はゴールデンな出力や合格条件、採点方法は文字列一致・埋め込み類似度・LLMによる採点などを指します。この3つが揃うと、同じテストを繰り返し流して結果を比較できます。

再現可能であることが最重要です。プロンプトを1文字変えたときに、変更が改善なのか改悪なのかを、同じ入力・同じ採点で判断できる状態を作るのがEvalsのゴールです。

従来のソフトウェアテストとの違い

従来のユニットテストは「入力Xに対して出力Yが返る」という決定的な関係を検証します。一方、LLMは同じ入力でも表現がゆらぐ確率的な出力を返します。「Yが返ること」ではなく「Yと同じ意味の出力が返ること」を測る必要があり、比較演算子ではメトリクスが必要になります。

もう一つの違いは、テスト対象の変更頻度です。LLMアプリはプロンプト・モデル・検索対象のドキュメント・埋め込みモデルなど、多くの要素が独立に変化します。どれか一つを差し替えるだけで挙動が変わるため、変更のたびに全体を評価し直す運用が前提になります。

なぜLLM評価が必要になるか

現場で最も多いのは、プロンプトを改良したつもりが別ケースを壊しているリグレッションです。手作業でサンプルを見比べるやり方は、10ケース程度は回りますが、50〜200ケースに増えると担当者の記憶と気力で判断がブレます。

もう一つは、モデルの世代交代です。同じベンダーの上位モデルに差し替えるだけで、口調・回答の粒度・ツール呼び出しの選好が変わります。Evalsがないと「安くて速いモデルに寄せたい」という判断ができません。

ミニFAQ: LLM評価とベンチマークの違いは何ですか？

LLM評価は自分たちのユースケースに特化した独自データセットでの採点です。MMLUやHellaSwagのような公開ベンチマークはモデル一般の能力比較が目的で、自社アプリの成否は測れません。両者は別物として扱い、Evalsは自社データで組みます。

評価の3タイプ：オフライン／オンライン／人手

LLMアプリのEvalsは、次の3レイヤーを組み合わせて設計します。1つで済まそうとすると、必ずどこかに死角が残ります。

オフライン評価（データセットに対する自動採点）

事前に集めた入力例のセット（Golden Set）にモデルを流し、採点基準に沿ってスコアをつけます。開発中の改善判断・リリース前のリグレッション検知に使います。

Golden Setの規模は用途で変わります。小〜中規模のPoC〜初期運用における実務上の目安として、単純なQAなら30〜100ケース、複雑なタスクなら200〜500ケースあると多くのプロンプト変更が判定可能になる傾向があります。100ケース未満だと、変更の効果よりノイズが大きくなり判定できないケースが出てきます。

オンライン評価（本番トラフィックからのサンプリング）

本番で流れているリクエストをサンプリングし、そのままEvalsに乗せます。ユーザーが実際に使っているパターンを反映できるのが最大の強みです。開発中は想定できていなかった質問形式や、長期的な品質劣化を捕まえられます。

サンプリング率は、ログ量と評価コストに応じた実務上の目安として全リクエストの1〜10%程度から始めるケースが多くなります。ログ量が多いサービスは1%以下でも十分で、少ないサービスは全件記録して後からサンプリングする設計が扱いやすくなります。

人手評価（アノテーターによる採点）

自動採点で拾いきれないニュアンスや、そもそも自動採点の基準を作るための元データを集めるために使います。専任のアノテーターが採点する形式と、社内のドメイン専門家がスポットで採点する形式があります。

人手評価は工数がかかるため、全ケースを人手で採点し続ける運用は非現実的です。初期のGolden Set作成時・LLM-as-a-Judgeの精度検証時・重大インシデント発生時の3タイミングに絞って投入するのが実務的です。

LLM-as-a-Judgeの仕組みと使いどころ

LLM-as-a-Judgeは、生成結果の採点を別のLLMに委ねる手法です。人手評価に近い柔軟な採点を、人よりも速く回せるのが利点で、Evalsの自動化を実用水準に押し上げた中心技術です。

別のLLMに採点させる考え方

構成要素は「判定LLM・判定プロンプト・評価軸」の3点です。判定LLMは採点役のモデル、判定プロンプトは採点手順を書いた指示、評価軸は何を測るかの定義（正確性・親切さ・簡潔さなど）です。

判定プロンプトには、評価軸の定義・スコアの範囲・スコアづけの例示（few-shot）を含めます。曖昧なまま採点させると、モデルは常に真ん中のスコアに寄せる傾向があります。例示は良い出力と悪い出力の両方を1〜3個ずつ入れると、スコアの分布が広がります。

単一評価・比較評価・多軸評価の3パターン

単一評価は、1つの出力に対して0〜5点や合否ラベルをつけます。実装が最も簡単で、閾値運用に向きます。

比較評価（Pairwise）は、2つの出力を並べて「どちらが良いか」を判定させます。人間にも判定させやすく、スコアより信頼度が高い傾向があります。プロンプトAとプロンプトBの比較や、モデルAとモデルBの比較に向きます。

多軸評価は、正確性・完全性・スタイル・安全性など複数の軸で個別に採点します。単一評価より情報量が多く、どこが弱いかを特定できます。RAGやエージェントの評価は多軸評価が向きます。

既知の失敗パターン（バイアス）

LLM-as-a-Judgeにはいくつかの再現性の高いバイアスがあります。設計時に対策を打っておかないと、Evalsの結果自体が信用できなくなります。

• 位置バイアス：比較評価で、先に提示された選択肢を選びやすい傾向

• 冗長性バイアス：長い出力を良いと判定しやすい傾向

• 自己贔屓バイアス：判定LLMと同じベンダーのモデルを高く評価する傾向

• 形式バイアス：Markdownで整形された出力を無条件に評価しがちな傾向

バイアスへの対策

位置バイアスは、AとBの提示順をランダムに入れ替えて2回採点し、両方でAが勝った場合のみAの勝ちとする運用で緩和できます。

冗長性バイアスは、判定プロンプトに「簡潔さも評価軸に含める」「不要な冗長化はマイナス」と明記します。加えて、出力の文字数を採点前に判定LLMに読ませてから採点させる手順を挟むと、長さの影響を意識化できます。

自己贔屓バイアスは、判定LLMを評価対象と別ベンダーのモデルにする、または複数モデルの多数決にする方法で回避します。GPT-4系で生成した出力をClaude系で採点する、といった組み合わせが典型的です。

ミニFAQ: 判定LLMはどのモデルを使えばよいですか？

一般的には、評価対象より1段上のモデル、または別ベンダーの上位モデルが安定します。同一モデルで採点させると自己贔屓バイアスが出るため、少なくとも評価対象と同じモデルは避ける設計が無難です。

評価軸の設計：メトリクスと基準の作り方

評価軸はタスクごとに設計します。汎用メトリクスに寄せすぎると、自社の失敗パターンを検知できません。以下はよく使う軸と、タスク別の組み合わせ例です。

汎用メトリクス

• 正答性（Correctness）：期待する事実や結論を含んでいるか

• 忠実性（Faithfulness）：与えたコンテキストに沿っているか（幻覚がないか）

• 完全性（Completeness）：質問の要素を漏れなく答えているか

• 安全性（Safety）：不適切な出力・機密の漏洩・攻撃的表現がないか

• スタイル：想定するトーン・フォーマット・言語に沿っているか

RAG向けメトリクス

RAGは検索と生成の2段構成のため、両方の品質を切り分けて測ります。RAGASなどのフレームワークで標準化されている軸です。

• Context Precision：取得したコンテキストのうち、質問に関連している割合

• Context Recall：質問に必要な情報が、取得コンテキストにどれだけ含まれているか

• Answer Relevance：生成された回答が質問に対して的を射ているか

• Faithfulness：生成された回答が取得コンテキストの内容に忠実か

これらを組み合わせると、失敗が「検索が悪い」か「生成が悪い」かを分離できます。RAGの実装や案件動向はRAGとは？仕組み・活用事例・導入メリットをわかりやすく解説とRAG構築案件の実情｜単価相場・必要スキル・獲得方法で整理しています。

エージェント向けメトリクス

AIエージェントは「複数ステップで目標を達成する」タスクのため、生成物単体ではなく実行過程も評価対象になります。

• タスク完了率：最終的な目標達成の成否

• ツール選択正答率：適切な外部ツールを選べたか

• ステップ数：目標達成までのステップ数（少ないほど良い）

• エラー回復率：途中でエラーが出た際にリカバリできたか

エージェントの設計や案件についてはAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説とAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説を参照してください。

チャット向けメトリクス

チャットやカスタマーサポート系のLLMアプリでは、単発の正誤より会話全体としての振る舞いを見ます。

• 意図充足：ユーザーの質問意図に沿った回答になっているか

• 指示追従性：フォーマット指定・言語指定・トーン指定に従えているか

• 会話継続性：文脈を保ちながら複数ターンで自然に応答できているか

• 簡潔さ・トーン適合：想定するブランド調・過剰な冗長さのなさ

チャット系は判定LLMのバイアス（冗長性を良しとしがち）が特に効きやすい領域のため、後述のバイアス対策を厚めに設計します。

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

Golden Setは以下の順で作ると集めやすくなります。

1. 本番想定のクエリを50〜100件、実際の想定利用シーンから拾う

2. 各クエリに対して、期待する回答・出力の要件を書き下ろす

3. 明確な失敗ケース（禁止事項に触れる質問など）を10〜30件加える

4. エッジケース（曖昧な質問・長すぎる入力・意地悪な質問）を10〜20件加える

初回に完璧を目指すよりも、まず50件で運用を回し、本番で見つかった失敗ケースを継続的に追加していく設計のほうが実務に馴染みます。

ミニFAQ: 評価データセットは公開データを使ってもいいですか？

汎用能力の比較には使えますが、自社アプリの合否判断には向きません。想定ユースケースと入力分布が違うため、自社データで作ったGolden Setの補助として位置づけるのが安全です。

LLM品質保証の実務プロセス

Evalsは仕組みだけ整えても回りません。「いつ・誰が・何を判断するか」を運用プロセスに埋め込んで初めて意味を持ちます。以下は多くのプロジェクトで採用しやすい標準形です。

開発フェーズ：プロンプト変更のたびにオフラインEvals

プロンプトを変えるたびに、Golden Setに対してオフラインEvalsを流し、既存ケースへの影響を可視化します。CIに組み込むと、プルリクエストの差分に沿って自動でスコアが出ます。

判断は「合計スコア」ではなく「悪化したケース数」で見るのが実務的です。合計スコアは改善しても、特定の重要ケースが壊れていることがあります。ケース単位のダッシュボードを用意すると、壊れた部分だけを追跡できます。

リリース前：Golden Setに対するリグレッションチェック

リリース候補モデルやプロンプトに対して、Golden Setを流して閾値を満たすかを確認します。閾値は、たとえば「全ケース中の合格率90%以上」のように、タスクの重要度とケース難易度に応じて事前に決めておきます。

重要ケース（絶対に壊してはいけないもの）はGolden Setとは別に「Must-Passセット」として管理する運用も有効です。Must-Passは全件合格が条件で、1件でも落ちればリリースを止めます。

本番稼働後：オンラインEvalsとインシデント検知

本番トラフィックのサンプリングにオンラインEvalsを流し、スコアの時系列変化を監視します。モデル側のアップデート・データ側の変化・ユーザー行動の変化のいずれでも、スコアが落ちる可能性があります。

閾値を割ったらアラートを出す設計にしておくと、劣化に気付ける速度が変わります。アラート疲れを避けるため、運用チームが継続的に確認できる件数に収まるよう閾値を調整し、鳴り続けるなら閾値が厳しすぎるサインとして見直します。

ダッシュボードと閾値運用

見える化するダッシュボードは、少なくとも次の3つを分けて表示します。

• プロンプト・モデル別のスコア推移（改善判断用）

• メトリクス別のスコア分布（弱点の特定用）

• 失敗ケースの詳細ログ（原因追跡用）

閾値は最初から厳密に決めず、2〜4週間の運用でスコア分布を確認したうえで置きます。実測なしに閾値を置くと、アラートが鳴り続けるか、鳴らなさすぎるかのどちらかになりがちです。

ミニFAQ: どれくらいの評価データがあれば十分ですか？

用途で変わりますが、目安としては「単純タスク30〜100ケース」「複雑タスク200〜500ケース」です。統計的な有意差検定を厳密にやるなら1,000ケース以上が望ましい水準ですが、ほとんどの現場では実務判断ができる規模で始めて拡張していく形が現実的です。

主要な評価フレームワーク・ツール

Evalsを自前で全部書くと工数が跳ねます。既存フレームワークとの併用が実務標準です。

評価フレームワーク

• OpenAI Evals：OpenAI公式の評価フレームワーク。YAML定義でテストを書けるのが特徴。OpenAI Evals（GitHub）

• DeepEval：Pythonネイティブで、Pytest風にテストを書ける。LLM-as-a-Judgeもビルトイン。DeepEval 公式ドキュメント

• RAGAS：RAG特化の評価ライブラリ。Context Precision / Recall などRAG向けメトリクスが揃う。RAGAS 公式ドキュメント

• promptfoo：プロンプト間のA/B比較に強く、CLIベースで扱いやすい。promptfoo 公式サイト

観測プラットフォーム

評価データの管理と、本番ログの観測を一元化するプラットフォームです。トレース記録・データセット管理・自動評価をまとめて提供するのが共通の特徴です。

• LangSmith：LangChain純正の観測基盤。LangChainベースの実装との相性が良い

• Langfuse：OSSでセルフホスト可能。トレース・データセット・Evalsをカバー

• Braintrust：評価データセットの管理と本番モニタリングを重視した商用サービス

LangChain・LangGraphでエージェントを組んでいるプロジェクトは、LangChainとは？できること・活用事例から年収・将来性まで解説とLangGraphとは｜LangChainとの違い・エージェント構築の基本を確認したうえでLangSmithと組む選定が滑らかです。

選定の考え方

小さく始めるならDeepEvalかpromptfooをローカルで動かし、CIに組み込む形で始めます。本番トラフィックの観測が必要になった段階で、LangSmith・Langfuse・Braintrust のいずれかを加える二段階が扱いやすい構成です。

ミニFAQ: 自前実装とフレームワーク、どちらから始めるべきですか？

汎用メトリクス（正答性・忠実性など）はフレームワークに寄せ、自社固有の合格条件は自前関数で追加する併用が実務的です。すべて自前で書くと保守が重くなり、すべてフレームワーク任せだと自社の失敗パターンを検知できません。

よくある失敗と対策

Evals導入プロジェクトで繰り返し起きる失敗を、対策とあわせて整理します。

失敗1：Golden Setがないまま「印象で」プロンプトを直す

最も多い失敗です。担当者の記憶で「これで良くなった」と判断してリリースし、後日別のケースが壊れていることに気付きます。

対策は「Golden Setを作ってから直す」の順序を徹底することです。初期のGolden Setは30〜50件で十分で、完璧を目指すより早く運用に乗せる方が価値が高くなります。

失敗2：LLM-as-a-Judgeを盲信する

「LLMが良いと言っている＝良い」と判断してしまうケースです。判定LLM自体が体系的なバイアスを持つため、人手評価と照合しないと信頼できません。

対策は、初期に50〜100ケースだけ人手評価とLLM-as-a-Judgeを両方走らせ、相関を確認することです。相関が低い評価軸は、判定プロンプトを直すか、その軸だけ人手評価に戻します。

失敗3：本番の観測をせずに開発中の指標だけで判断する

開発時のGolden Setだけを見ていると、本番で頻出する未知のクエリパターンに気付けません。リリース直後は問題なくても、時間とともにドリフトします。

対策は、リリース時からオンライン評価を組み込むことです。サンプリング率が低くても、記録さえ残しておけば後から掘り下げられます。

失敗4：評価基準を頻繁に変える

評価軸や採点プロンプトを毎週のように書き換えると、スコア推移の比較ができなくなります。改善なのか基準変更の影響なのかが判別不能になります。

対策は、評価軸のバージョン管理です。基準を変えたら旧版と新版を並走させ、少なくとも2〜4週間は両方のスコアを見る運用にします。

失敗5：エッジケースだけを追い続ける

失敗した1ケースの解決に時間をかけすぎると、全体のスコアが上がらない状況になります。エッジケースを潰しても、頻度が低いため合計スコアには反映されません。

対策は、失敗ケースを頻度でランキングし、頻度の高いものから対応する方針にすることです。頻度が低い失敗は「既知の限界」として明示し、優先度を下げます。

LLM評価まわりのフリーランス案件動向

LLM評価は、生成AIプロジェクトの「作った後」の空白領域です。RAGやエージェントの実装は先行して進む一方、評価基盤まで整えられている企業はまだ限られており、Evals設計・実装・観測基盤整備を求める案件も見られるようになっています。

案件の実務内容としては、Golden Setの設計・LLM-as-a-Judgeの実装・観測プラットフォーム（LangSmith / Langfuse等）の導入支援・アノテーション運用設計などが典型です。データアノテーション寄りの案件と評価基盤寄りの案件で、必要スキルが分かれます。

単価相場・案件の探し方・参入ルートの詳細はLLM評価・データアノテーション案件｜単価相場と参入ルートに整理しています。関連領域として、LLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務やQAエンジニアのフリーランス単価相場｜案件動向と単価アップの条件も、Evals実装者のキャリア接続先として参考になります。

自分がどの領域でどのくらいの単価を狙えるか整理したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

まとめ

LLM評価は「Golden Setを作る → CIでオフライン評価 → 本番でオンライン評価」の3ステップを最短で回すことから始めるのが実務的です。完璧な評価基準を最初から作ろうとすると立ち上がらず、感覚判断のまま運用が続きます。

• LLM評価は「オフライン」「オンライン」「人手」の3レイヤーで組む

• LLM-as-a-Judgeは強力だがバイアスがあるため、人手評価との相関確認が必須

• タスク別（RAG・エージェント・チャット）に評価軸を分けて設計する

• 開発・リリース前・本番の各フェーズで役割の異なるEvalsを回す

• DeepEval・promptfoo・LangSmith・Langfuse など既存ツールとの併用で工数を抑える

案件動向・単価・参入ルートについてはLLM評価・データアノテーション案件｜単価相場と参入ルートを、隣接領域としてLLMコスト最適化案件・QAエンジニアのフリーランス単価相場を確認すると、自分の強みからどの案件に接続できるかの見通しが立ちます。実装スキル側の隣接記事として、生成AIエンジニアとは？仕事内容・必要スキル・年収とAIエンジニアとの違いを解説やプロンプトエンジニアリングとは？基本から実践テクニックまでわかりやすく解説もあわせて整理してみてください。