「試したときは良さそうだったのに、本番に出したら的外れな回答が混じる」「モデルを新しくしたら、なぜか精度が落ちた気がする」——生成AIを業務に載せる段階で、多くの企業がこの不安に突き当たります。原因は、AIの性能ではなく、出力の良し悪しを測る“物差し”がないことにあります。ここで鍵になるのが 生成AIの評価（Evals） です。結論から言うと、評価とは、AIの品質を基準とテストで継続的に測る仕組みで、「なんとなく良さそう」という主観を、数値で「使える／まだ」と判断できる状態に変えるものです。
この記事では、評価とは何か、なぜ必要か、何を・どう測るか、業務に組み込む進め方を解説します（誤答そのものの抑え方はハルシネーション対策、運用全体の回し方は本番運用の監視・評価も参照）。
生成AIの評価（Evals）とは？——品質を「測れる」ようにする
評価とは、AIの出力の品質を、あらかじめ決めた基準とテストで採点する仕組みです。 感覚で「良い・悪い」を判断するのではなく、物差しを用意して数値で測れるようにします。
評価には、大きく3つのやり方があります。
| 採点の方法 | 内容 | 向くところ |
|---|---|---|
| 人手評価 | 人が出力を読んで採点する | 正解の判断が難しい・重要な項目 |
| 自動評価（ルール） | 決まった正解や形式と機械的に照合する | 答えが一意・形式が決まっている項目 |
| LLM-as-judge | 別のAIに基準を与えて採点させる | 大量の出力を安く速く採点したいとき |
また、評価するタイミングにも2種類あります。本番に出す前に測る「オフライン評価」（代表的な質問セットで一括採点）と、運用しながら測る「オンライン評価」（実際のやりとりの品質を継続的に見る）です。この2つを回すことで、「出す前に使えるか」と「出した後も保てているか」の両方を押さえられます。
なぜ「なんとなく良さそう」では本番に出せないのか？
主観の「良さそう」は、再現性がなく、品質が下がったことにも気づけないからです。 ここが評価を必要とする最大の理由です。
担当者が数件試して良く見えても、それは氷山の一角です。実際の業務では、想定外の聞き方・専門用語・例外的なケースが次々に来ます。数件の印象で本番に出すと、多様な入力で誤答が混じり、しかもそれに気づけません。
さらにやっかいなのが、品質は変化することです。モデルのバージョンが上がる、参照データを入れ替える、プロンプトを直す——こうした変更で、昨日まで正しかった回答が、今日は崩れることがあります。評価の仕組みがあれば、変更のたびに代表的な質問セットで測り直し、「前より良くなったか・悪くなっていないか」を確認できます。これは、ソフトウェア開発の回帰テストと同じ発想です。
生成AIでは何を・どう測るのか？
すべてを一度に測ろうとせず、その業務で最も重要な観点から測るのが実践的です。 代表的な評価の観点は次のとおりです。
| 観点 | 何を見るか |
|---|---|
| 正確性 | 事実として正しい答えか |
| 根拠 | 出典やデータにもとづいているか |
| 形式 | 指定した構造・書式で出力されているか |
| 安全性 | 不適切な出力や情報漏洩がないか |
| タスク成功率 | エージェントが目的を達成できたか |
測り方の中心になるのが、評価データセットです。これは「代表的な質問」と「期待される答え（や満たすべき条件）」をセットにしたもので、いわばAIの“テスト問題集”です。実際の業務で来る質問、過去に失敗した質問、例外的なケースを集めて作ります。この問題集に対してAIを走らせ、観点ごとに採点すれば、品質を数値で把握できます。
採点を規模に広げたいときは LLM-as-judge（別のAIに採点させる） が有効ですが、注意が要ります。採点AIにも偏りや誤りがあるため、採点基準を明確に与える／重要項目は人の採点と突き合わせて採点AI自体の精度を確かめる／判断が難しいものは人がレビューする、といった補正を組み合わせます。LLM-as-judgeは人の評価を置き換えるのではなく、人の評価を規模に広げるもの、と捉えるのが安全です。
具体例：社内AIに「評価」をつける
抽象的なので、ある社内AIの評価を例にします（数値はすべて説明用の仮の値です）。
社内規程に答えるAIを本番に出す前に、評価の仕組みを入れるとします。まず、現場からよく来る質問と、過去に間違えた質問を集めて、50問の評価データセットを作ります。それぞれに「正しい答え」と「満たすべき条件（根拠の条項を示す・最新版で答える）」を定義します。
| 観点 | 測り方 | 合格の目安（仮） |
|---|---|---|
| 正確性 | 50問の回答を正解と照合（一部は人が確認） | 正答率95%以上 |
| 根拠 | 回答に根拠の条項が示されているか | 根拠提示率100% |
| 最新性 | 古い規程で答えていないか | 旧版参照0件 |
| 安全性 | 権限外の情報を出していないか | 漏洩0件 |
この評価を走らせて、たとえば「正答率88%、旧版参照が3件」と出れば、まだ本番に出せないと客観的に判断できます。原因（古い規程が混ざっている等）を直し、再び評価を走らせて基準を満たしたら公開する。公開後も、月次でこの問題集を回し、品質が落ちていないかを見張ります。「良さそう」ではなく「正答率95%を満たしたから出す」——この判断の土台をつくるのが評価です。
評価を業務に組み込む進め方
成功の鍵は、完璧な評価を最初から目指さず、小さな評価データセットから始めて回し続けることです。 進め方の勘所は3つです。
- 重要な観点を1〜2個に絞って始める：その業務で最も大事な観点（多くは正確性と根拠）から、数十問の評価データセットを作る。小さくても、無いよりはるかに良い
- 失敗を評価データセットに育てる：本番で見つかった誤答を、テスト問題集に追加していく。これで、同じ失敗を繰り返さない仕組みになる
- 変更のたびに測る：モデル更新・データ変更・プロンプト修正のたびに評価を走らせ、良くなったか・悪化していないかを確認する（運用の回し方は本番運用の監視・評価を参照）
難しいのは、「何をもって正解とするか」が自社の業務に強く依存する点です。汎用のベンチマークで高得点でも、自社の業務で使えるとは限りません。自社の質問・正解・合格基準を定義する作業こそが、評価の中核であり、外部の一般的な指標では代替できないところです。
DeploAIのFDEは生成AIの評価をどう支援するか
DeploAI の FDE（Forward Deployed Engineer）は、その業務に合った評価の観点と基準を定め、品質を数値で管理できる状態を現場でつくります。
AIを安心して業務に載せる難所は、モデル選びより「何をもって“使える”とするか」を決め、測り続ける仕組みをつくることにあります。FDE は、評価の観点と合格基準の設計、評価データセットの作成、自動採点やLLM-as-judgeの実装、本番前後で品質を測り続ける流れの構築までを一気通貫で担います。評価は自社の業務と正解の定義に依存するため、汎用ツールの設定だけでは機能しません。「良さそう」を「基準を満たしたから出す」に変え、その物差しと運用を社内に残すところまで伴走するのが特徴です。
まとめ
- 生成AIの評価（Evals）とは、AIの出力品質を基準とテストで継続的に測る仕組み。「なんとなく良さそう」を数値の判断に変える。
- 「良さそう」で本番に出せないのは、主観で再現性がなく、品質低下に気づけないから。モデルやデータの変更で回答は崩れうる。
- 測り方は、評価データセット＝テスト問題集を作り、正確性・根拠・形式・安全性・タスク成功率などを採点する。LLM-as-judge は補正しながら規模を広げる手段。
- 進め方は、重要な観点に絞って小さく始める→失敗を問題集に育てる→変更のたびに測る。
- 「何を正解とするか」は自社の業務に依存し、汎用ベンチマークでは代替できない。DeploAI の FDE が、評価の設計・実装・運用まで伴走する。
生成AIを安心して業務に載せたい方は、本番運用の監視・評価で運用の回し方を、ハルシネーション対策で誤答の抑え方を確認してみてください。導入のご相談はお問い合わせから承っています。
関連記事：生成AI・AIエージェントの本番運用｜生成AIのハルシネーション対策｜コンテキストエンジニアリングとは？｜生成AIのセキュリティ
