普通のソフトウェアは「動く／動かない」で合否が決まりますが、LLM（大規模言語モデル）アプリは同じ入力でも答えが揺れ、品質が連続的に上下します。「だいたい良さそう」で本番に出すと、プロンプトを少し変えただけ・モデルを乗り換えただけで静かに劣化し、誰も気づかないまま使われ続けます。これを防ぐのが評価（eval）です。この記事では、初めての人でも今日から組める評価の三本柱と、それをCI（自動テスト）と本番監視につなぐ流れを、図とともに具体的に説明します。
FIG.1 評価がないと劣化は本番で初めて発覚する。評価があれば変更の直後に検知できる
01評価は「三本柱」で考える
LLMアプリの評価は、性質の違う3つを組み合わせるのが定石です。1つだけでは穴が残ります。まずは全体像を押さえましょう。
FIG.2 Golden Set（出す前の基準）＋ LLM-as-a-Judge（大量採点）＋ ユーザーフィードバック（本番の実態）
Golden Set
「この入力にはこの答えが理想」という正解ペアを人が作る。リリース前に必ず通す“最低ライン”の検査。
LLM-as-a-Judge
別の強いLLMに答えを採点させる。人手では追いつかない件数を、安く速く評価できる。
ユーザーフィードバック
本番の反応（良い／悪い・編集・離脱）を集める。Golden Setにない“現実の質問”の穴を教えてくれる。
02Golden Set：評価の土台になる正解集
Golden Set（ゴールデンセット）は、「入力」と「理想の答え／合格条件」のペアを集めた問題集です。新しいプロンプトやモデルを試すたびにこの問題集を通し、点数を比べます。最初は30〜100件でも十分に効果があり、運用しながら増やしていきます。
- 作るのは業務担当者：実際の質問を一番知っているのは現場。エンジニア任せにすると“実際には来ない質問”ばかりになりがち。
- 難所を必ず入れる：エッジケース、過去に間違えた質問、紛らわしい例。簡単な質問ばかりだと満点が出て改善が止まる。
- 定期的に更新：新機能・新ルール・新製品が出たら追記。古いまま放置すると「テストは通るのに現実は外す」状態になる。
- 合格条件は具体的に：「正しい結論を含む」「禁止表現を出さない」「引用を付ける」など、採点できる形で書く。
03LLM-as-a-Judge：大量採点と、その落とし穴
答えを1件ずつ人が読むのは現実的ではありません。そこで、別の強いLLM（GPT‑5やClaude Opusなど）に「この答えは良いか悪いか」を採点させるのがLLM-as-a-Judgeです。安く速く、数千件でも回せます。ただし判定にクセ（バイアス）があるので、そのまま盲信してはいけません。
- 採点ルブリックを明示する：「正確性0〜5」「明瞭さ0〜5」のように観点と尺度を具体的に渡す。曖昧な「良い？」では判定がブレる。
- 位置バイアスに注意：2つの答えを並べて比べさせると、内容と関係なく先（または後）に置いた方を選びやすい傾向が確認されています。
- 順番を入れ替えて検証：同じペアを順番を逆にしてもう一度採点させ、判定がひっくり返ったらバイアスの疑い。順番をランダム化して平均する。
- 定期的に人間と突き合わせる：一部を人が採点し、Judgeの結果とどれくらい一致するかを測る。ずれていたらルブリックやモデルを見直す。
FIG.3 順番を入れ替えても結論が同じなら信頼でき、反転したら位置バイアスを疑う
LLM-as-a-Judge は「人の代わり」ではなく、人の確認で校正し続ける計測器として使う。
04用途別：見るべきメトリクス
「何を測るか」は用途で変わります。一般的な対応は次の通り。最初から全部やる必要はなく、自分のアプリの型に合うものを選びます。
| 用途 | よく使うメトリクス |
|---|---|
| 分類（ラベル付け） | Accuracy、Precision、Recall、F1 |
| 抽出（項目の取り出し） | Exact Match、F1 |
| 要約 | BERTScore、LLM-as-a-Judge |
| RAG（検索＋生成） | Faithfulness、Answer Relevancy、Context Precision、Context Recall（RAGAS） |
| 対話 | 一貫性、有用性、安全性（多くはLLM-as-a-Judge） |
| コード生成 | HumanEval、MBPP、自社のユニットテスト通過率 |
RAG（社内データを検索して答えさせる構成）では、RAGASの4指標が定番です。意味の目安として、よく引かれる推奨ラインはFaithfulness ≈ 0.75（答えが根拠に忠実か）、Answer Relevancy ≈ 0.8（質問に答えているか）、Context Precision ≈ 0.7（取った根拠にノイズが少ないか）、Context Recall ≈ 0.8（必要な根拠を取りこぼしていないか）。これらは絶対基準ではなく、自分のデータで“合格ライン”として調整する出発点です。
05主要ツール：性格の違いで選ぶ
評価ツールは大きく「テスト系（出す前の採点・CI向け）」と「観測系（本番のログ・監視向け）」に分かれます。実運用では両方を組み合わせるのが普通です。どちらか片方だけだと、出す前か本番のどちらかが見えなくなります。
| テスト系（出す前・CI） | 観測系（本番・監視） |
|---|---|
| Promptfoo、DeepEval、Ragas、Giskard | Langfuse、LangSmith、Arize、Datadog LLM Observability |
| Golden Setで採点・しきい値で合否 | 本番の応答・コスト・遅延・品質を継続記録 |
- Promptfoo：OSS・CLI中心で、プロンプトのA/B比較やCI組み込みに強い。2026年3月にOpenAIが買収を発表したが、コアはMITライセンスのOSS・モデル非依存を維持すると表明されている。
- DeepEval：CIの品質ゲート（合格しないとマージできない）として人気。Pythonからユニットテスト感覚で評価を書ける。
- Ragas：RAG専用。Faithfulnessなどの指標を手軽に計測でき、最初のメトリクス探索や評価用データ生成に向く（本番監視機能は持たない）。
- Langfuse：OSSで自己ホスト可。トレース・評価・プロンプト管理・コスト追跡を一体で扱える、観測系の定番。
- LangSmith：LangChain／LangGraph環境で導入が最も簡単。トレースと評価、アノテーション（人手採点）を一括で扱える。
どれを選ぶかは「使っているフレームワーク」「OSSで自己ホストしたいか」「CI重視か本番監視重視か」で決まります。料金・無料枠は頻繁に変わるため、採用前に必ず公式の最新情報を確認してください。
06Regression Test：CIに評価を埋め込む
Regression（リグレッション）テストとは、「前は通っていたのに、変更で壊れた」を自動で捕まえる仕組みです。LLMアプリでは、プロンプトの修正やモデルの乗り換えのたびにGolden Setを自動で回し、点数がしきい値を下回ったらマージをブロックします。これでうっかり劣化を本番に出さずに済みます。
Golden Setを用意する
入力と合格条件のペアをファイル化（例：golden-set.json）。最初は30〜100件で始める。
CIで評価を実行
プルリク時に評価コマンドを走らせる。例：npm test → promptfoo eval ./golden-set.json。DeepEvalならテストとして書ける。
しきい値で合否を判定
「合格率90%以上」などのラインを決め、下回ったら自動でマージをブロック。判断を人の気分に頼らない。
失敗例をGolden Setへ還元
本番で見つかった失敗を問題として追加。テストが現実に追いつき続ける。
07本番モニタリング：出した後こそ見る
評価はリリースで終わりではありません。本番では入力の傾向が変わり、モデル提供側のアップデートで挙動がずれることもあります。次の観点を継続的に記録します。
- 応答時間：P50／P95／P99（中央値だけでなく“遅い側”を見る）
- コスト：入力・出力トークン。拾いすぎ・長文化で急に膨らむ
- エラー率：API失敗、レート制限、タイムアウト
- 品質指標：ユーザーの好意的反応の割合、回答後の手直し率、途中離脱
- 異常検知：急な応答長の変化、特定キーワードの頻発（プロンプトインジェクションの兆候など）
重要なのは、オフラインの評価点と本番ログを突き合わせること。テストでは高得点なのに本番で苦情が出るなら、Golden Setが現実をカバーできていない合図です。
Field Note
「総合点は満点なのに苦情が来る」の正体
実例として、ある法務向けRAGはリリース時のFaithfulnessが0.91と高く、十分に見えました。ところが本番から数週間後、「重要な条文を見落とす」という苦情が6件に1件の割合で発生。調べるとFaithfulnessは0.91のまま変わっていなかったのに、Context Recallが0.62に落ちていた——検索が、複数の条文をまたぐ質問で必要な根拠を取りこぼしていたのです。
FIG.4 平均や1指標だけ見ると見逃す。指標を分解すると「どこが壊れたか」が分かる
教訓はシンプルです。指標は分解して見ること、そして本番でも測り続けること。総合点や単一指標だけを追うと、こうした“片側の劣化”を取りこぼします。
08よくある失敗パターン
- Golden Setが古いまま：新しいユースケースが反映されず、「テストは通るのに現実は外す」。
- LLM-as-a-Judgeを盲信：人間との突き合わせをせず、Judgeのクセをそのまま採点結果にしてしまう。
- 本番ログと突き合わせない：評価と現実が乖離し、満点なのに苦情が来る。
- コストを測らない：品質ばかり見て、トークン課金が静かに膨張してから気づく。
- 単一指標で判断：総合点が高くても、Context Recallのような片側だけが落ちているのを見逃す。
092026年のトレンド
評価の世界も動いています。研究で確認できている範囲で、押さえておきたい流れは次の通りです（個別ツールの仕様・料金は変動するため、採用時は公式を確認）。
- エージェント評価：最終回答だけでなく、ツールを多段で呼ぶ「過程（トラジェクトリ）」全体を評価する流れ。正解にたどり着いても、途中の手順が非効率・危険なら問題、という見方が一般的になってきています。
- マルチモーダル評価：テキストだけでなく、画像・音声を扱うAIの品質をどう測るかが課題に。
- テスト系と観測系の連携：CIのGolden Set評価（DeepEval等）と本番トレース（Langfuse／Braintrust等）を分担・連携させる構成が、エンジニア主導チームの定番になりつつあります。
- LLM-as-a-Judgeの精緻化：位置バイアスなどの偏りを、順番のランダム化やメタ判定で抑える手法の研究が進行中。多数決やディベート方式は、やり方によってバイアスを増幅しうることも報告されています。
10まとめ：今日から始める一歩
LLMアプリの評価は、「Golden Set ＋ LLM-as-a-Judge ＋ ユーザーフィードバック」の三本柱で考え、CIにRegressionテストとして埋め込み、本番でモニタリングし続ける——この3点が骨格です。完璧を目指すより、まずはよく来る質問を30問集めてGolden Setを作るところから。点数で変更を判断できるようになれば、モデル乗り換えもプロンプト改修も「お祈り運用」を卒業できます。
