社内で試作したAIエージェントが、デモでは見事に動いたのに、実際にユーザーへ公開した途端に妙な受け答えを始めた——そんな経験はないでしょうか。
チャットボットが注文内容を勝手に書き換えたり、リサーチエージェントが存在しない数字を自信満々に報告したり。動いているように見える状態と、業務で任せられる状態のあいだには、思っている以上に大きな溝があります。
この溝を埋めるための考え方が、この記事で扱うEvals（エバルズ、評価の意味）です。ソフトウェアのテストに似ていながら中身はかなり違うこの手法を、専門用語をひとつずつほどきながら整理していきます。
読み終えるころには、なぜ一度動いただけでは安心できないのか、そして何から手をつければよいのかが見えてくるはずです。プロダクトを預かる立場の方ほど、開発の細部より先に押さえておきたい考え方です。
Evalsとは何か——「動く」と「信頼できる」は別の話
定義
EvalsはEvaluationsの略で、AIモデルやAIエージェントの出力を、あらかじめ決めた基準に沿って体系的に採点する仕組みを指します。単発の出力だけでなく、複数の手順を踏んで結論にたどり着くAIエージェントの場合は、途中の判断や道具の使い方まで含めて評価の対象になります。
従来のソフトウェアテストとの違いは、正解がひとつに定まらない場面が多いことです。バグ修正のプログラムなら出力は白か黒かで判定できます。
一方、問い合わせ対応のAIエージェントが書いた返信文は、文面が違っても内容として合格になる場合が珍しくありません。テストと呼ぶには曖昧で、勘に頼るには重要すぎる、その中間を埋めるのがEvalsだと考えるとしっくりきます。
なぜ今Evalsが話題になっているのか
背景にあるのは、AIエージェントが単純な一問一答から、複数ステップの作業をこなす存在へと役割を広げてきたことです。MCP（Model Context Protocol）とは？で触れたように、外部のツールやデータへ安全につなぐ規格が整いました。
その結果、AIエージェントは検索し、計算し、他のシステムを呼び出すところまで任されるようになりました。任せる範囲が広がるほど、どこかの一手順でつまずいたときの影響も大きくなります。
動作確認を勘や思いつきの手元テストで済ませる段階から、体系立てて品質を測る段階へ移る必要が出てきた、というのがEvalsが注目される理由です。AI関連のベンダーやプラットフォームが、2025年以降そろって評価まわりの機能やガイドを整備し始めているのも、この移行を裏付ける動きだと言えます。
リリース前のチェックリストにEvalsの項目が並ぶ会社と、まだ並んでいない会社との差は、今後じわじわ効いてくるはずです。
なぜAIエージェントは「なんとなく動く」が壊れやすいのか
一度うまく動いたからといって、次も同じように動くとは限らないのがAIエージェントの厄介なところです。壊れやすさの正体を、3つの角度から見てみます。
出力が毎回同じとは限らない
同じ質問を同じAIエージェントに投げても、返ってくる文面や手順の順序が毎回微妙に変わることがあります。人間の担当者に同じ仕事を二度頼んでも、細部の進め方が少し変わるのと似ています。
この性質は非決定性と呼ばれ、AIエージェントの品質確認を難しくしている根本の原因のひとつです。一度の手動確認で問題なしと判断しても、その一回がたまたま調子の良い試行だった可能性は常に残ります。
同じ入力を何度か試して、答えのばらつき方まで見ておく姿勢が欠かせません。
複数ステップの複合誤差
エージェントが5つの手順を踏んで結論を出すとして、各手順の正解率が仮に95%だったとします。あくまで説明用の仮定ですが、5手順すべてが正しく通る確率は0.95の5乗で、およそ77%まで下がる計算になります。
手順が10段階に増えれば、同じ条件でも成功率はおよそ60%まで沈みます。一つひとつの精度が高く見えても、手順を重ねるほど全体としての成功率は掛け算で下がっていく、という複合誤差の性質を頭に入れておく必要があります。
人手の作業と違い、AIエージェントは疲れも遠慮もなく最後まで手順を実行し切ってしまいます。その分、途中のつまずきに気づきにくいという面もあります。
サイレント障害という厄介さ
もっとも見つけにくいのが、エラーメッセージを出さずに間違った結論へたどり着くサイレント障害です。存在しない情報をもっともらしく提示したり、古いデータを最新の数字であるかのように扱ったりします。
それでも、システムとしてはエラーなく処理が完了してしまいます。例外処理で止まってくれる従来型のバグと違い、こうした失敗はログを眺めているだけでは気づけません。
だからこそ、意図的に出力の中身を採点する仕組みが必要になるわけです。
Evalsの3つの層——ユニットテスト・LLM審査・本番モニタリング
Evalsと一言でいっても、実務では性質の異なる3つの層を組み合わせて使うのが定番の型です。まずは全体像を表で整理します。
| 層 | 何を測るか | 向いている場面 | 限界 |
|---|---|---|---|
| ユニットテスト的評価 | 特定の入力に対する正解の有無 | フォーマットや必須項目の抜け漏れ | 自由記述の良し悪しは測れない |
| LLM審査（LLM-as-a-judge） | 文章としての質や妥当性 | 自由記述の応答、要約、レポート | 審査役自身のクセや誤りを引き継ぐ |
| 本番モニタリング | 実際のユーザーとのやり取り | リリース後の継続的な品質確認 | 問題に気づくのが利用後になる |
入り口はユニットテスト的な評価から
必須項目が入っているか、数値のフォーマットが崩れていないか、禁止された操作を行っていないか。こうした機械的にチェックできる項目は、通常のソフトウェアテストとほぼ同じ発想で自動化できます。
手をつけやすく、かつ土台として欠かせない層です。ここが崩れているうちは、その上の層を積んでも意味がありません。
自由記述の評価をどう自動化するか
厄介なのは、要約やレポート、問い合わせへの返信文のように、正解がひとつに定まらない出力です。人間が一件ずつ読んで採点するのが理想ですが、件数が増えるとすぐに手が回らなくなります。
ここで使われるのが次の節で扱うLLM審査で、別のAIモデルに採点役を任せる方法です。
本番での継続的な確認
事前のテストをどれだけ丁寧にやっても、実際のユーザーが投げてくる質問は開発者の想定を超えてきます。リリース後も一定のサンプルを継続的に採点し続ける仕組みがあって、はじめてEvalsは効果を発揮します。
開発中だけの一過性の作業ではなく、運用フェーズに入ってからも回し続ける前提で設計しておくべき層です。
本番モニタリングでは、採点そのものに加えて、ユーザーの高評価・低評価ボタンや、人間の担当者への引き継ぎが発生した頻度といった、行動として現れるシグナルも手がかりになります。採点結果と行動シグナルを突き合わせることで、机上の基準だけでは見つからなかった弱点が浮かび上がることもあります。
LLM審査（LLM-as-a-judge）の仕組みと落とし穴
どういう仕組みか
LLM審査は、評価したい出力と採点基準を別のAIモデルに渡し、合格・不合格やスコアを判定させる手法です。人間が一件ずつ目視で読むより圧倒的に速く、数百件、数千件という規模の出力を継続的に採点できます。
採点基準は、人間が読んでもぶれない具体的な文章に落とし込む必要があります。たとえば問い合わせ対応であれば、事実に基づいているか、必要な情報を漏らしていないか、トーンが適切かといった観点をあらかじめ言語化しておきます。
基準があいまいなままでは、LLM審査の結果もあいまいなまま揺れ動いてしまいます。
判定基準の書き方のコツ
判定基準は、抽象的な形容詞だけで書かないことが重要です。丁寧な対応とだけ書くより、敬語の誤りがない、相手の質問に答え漏れがないというように、読んだ人によって解釈が割れない粒度まで具体化しておきます。
判断が分かれそうな境界事例を合格例・不合格例のペアとしてあらかじめ用意しておき、判定基準と一緒に渡す方法も有効です。基準の文章だけでは伝わりにくいニュアンスを、具体例が補ってくれます。
自己贔屓というクセ
LLM審査には見落とされがちな落とし穴があります。採点役に使うAIモデルと、評価される側のAIモデルが同系統だと、自分に近い書き方を無意識に高く評価してしまう傾向が指摘されています。
これは自己贔屓バイアスと呼ばれる現象です。対策として、採点役には評価対象とは別系統のモデルを使う、あるいは複数のモデルに採点させて結果を突き合わせるといった工夫が取られます。
採点役も間違える存在だという前提に立つことが、この手法を使いこなす第一歩です。
人間の判断との相関を定期的に確認する
LLM審査の結果をそのまま信じ込むのは危険です。定期的に人間が同じサンプルを採点し、LLM審査の結果とどれだけ一致しているかを確認する作業が欠かせません。
ここがずれ始めたら、採点基準の文章か、採点役のモデルを見直すサインです。この考え方は、A/Bテストのサンプルサイズ設計｜検定力とMDEをどう決めるかで扱った、判定の土台になる基準を事前に固めておくという発想と重なります。
どちらも、後から都合よく基準を動かさないという規律が、数字の信頼性を支えています。
評価データセットをどう作るか——実務の手順
理屈がわかっても、実際に手を動かすとなると何から始めればよいか迷うものです。順を追って考えます。
実運用のログから始める
架空のテストケースをゼロから考えるより、実際にユーザーが投げた質問やエージェントが失敗した事例を集めるほうが、はるかに実務に効く評価データセットになります。失敗の記録は宝の山です。
うまくいかなかったやり取りこそ、最初に採点対象へ加えるべき材料です。うまくいった事例だけを集めても、どこに弱点があるかは見えてきません。
合格基準を先に決めておく
同じ仕様書を読んでも、担当者によって境界線の判断が割れることは珍しくありません。何が合格で何が不合格かを、実装に着手する前に文章として固定しておくことで、後からの言った言わないを防げます。
この順序は、仮説検証型のプロダクト開発｜思いつきで作らないための型で述べた、作り始める前に何を確かめるかを決めておく進め方とそのまま重なります。Evalsも突き詰めれば、AIエージェントという新しい種類の機能に対する仮説検証の一形態です。
- 実際の失敗ログから20〜30件ほどの代表的なケースを集める
- 各ケースについて、合格・不合格の判断基準を文章で書き出す
- 複数人で採点してみて、判断が割れる項目を洗い出す
- めったに起きないが重大なエッジケースも、意図的に数件混ぜておく
- 割れた項目は基準を書き直すか、判断が難しい例として別枠にする
少しずつ育てる前提で運用する
一度作った評価データセットで満足せず、新しい種類の失敗が見つかるたびに追加していく前提で運用します。プロダクトの仕様が変わればAIエージェントの振る舞いも変わるためです。
評価データセットは完成品ではなく、常に手を入れ続ける資産だと捉えるのが実務的です。鮮度が落ちると、実態とずれた基準で合格判定を出し続けることになりかねません。
Evalsとプロダクト分析は何が違うのか
見ている問いが違う
ここまでのEvalsは、AIエージェントの出力そのものが正しいかどうかを測る仕組みでした。一方で、プロダクトを預かるチームがもうひとつ気にすべきなのが、その出力を受け取ったユーザーが実際にどう動いたかという行動データです。
二つは似ているようで、見ている問いがまったく違います。
| 観点 | Evals | プロダクト分析（行動データ） |
|---|---|---|
| 中心の問い | 出力は正しいか | ユーザーは実際に使い続けたか |
| データ源 | テストケースや本番ログの採点結果 | クリック・遷移・コンバージョンなどの行動 |
| 向いている場面 | リリース前の品質担保、回帰防止 | 機能全体の効果測定、離脱の発見 |
両方そろって初めて見える景色
正しい答えを返すAIエージェントを作っても、ユーザーがその機能にたどり着けていなければ意味がありません。逆に利用回数が伸びていても、裏側で誤った案内を繰り返していれば、いずれ信頼を失います。
片方だけを見ていては、もう半分の失敗に気づけないのです。たとえば、Evalsのスコアが十分に高いAIエージェント機能なのに、実際の利用開始率が低いままというケースを考えてみます。
この場合、原因はエージェントの回答精度ではなく、機能への導線やボタンの見つけにくさといった、行動データの側にしか映らない要因かもしれません。一例として、MonaLensのようなウェブ解析ツールは、AIエージェントの出力そのものの正しさまでは判定しません。
測れるのは、その機能がどれだけ使われ、どこで離脱され、最終的な成果につながったかという行動の軌跡までです。Evalsとプロダクト分析は担当する層が違うからこそ、どちらか一方で済ませようとせず、両輪として運用する発想が必要になります。
ガードレール設計ともつながる
評価で品質を確かめるだけでなく、AIエージェントに与える実行権限そのものを絞る設計も欠かせません。GTMにAIエージェントを入れる｜人間承認とガードレールの設計で扱ったように、金額の大きい操作や取り消せない操作には人間の承認を挟むといった仕組みが必要です。
そうした仕組みは、Evalsで品質を底上げする取り組みとセットで機能します。採点で品質を測る仕組みと、暴走を防ぐガードレールは、どちらか一方では足りません。
まとめ——「なんとなく動く」から抜け出す最初の一歩
AIエージェントは、デモの場では驚くほど賢く見えます。ただし、その賢さが実務で毎回再現されるかどうかは、体系的に測って初めて分かることです。
ユニットテスト的な機械採点、LLM審査による自由記述の評価、そして本番での継続的なモニタリングという3つの層を積み上げていくことで、勘と度胸に頼った品質確認から抜け出せます。
大がかりな仕組みを一度に整える必要はありません。まずは実際に失敗したやり取りを数十件集め、何が合格で何が不合格かを言葉にしてみることから始められます。
そこから少しずつ評価の目を育てていくことが、AIエージェントを安心して任せられる存在に変えていく、遠回りに見えて確実な道筋です。