目次
AIエージェントを作ったあと、必ずぶつかる壁がある。「で、これはちゃんと動いているのか？」だ。プロンプトを変えた、モデルを変えた、ツールを足した——その結果、良くなったのか悪くなったのかを"感覚"でなく"データ"で判断する仕組みが Evals（エバル＝評価、Evaluations） である。
LLMは同じ入力でも出力が毎回変わりうる（確率的）。だから「動いてるっぽい」で本番に出すと、静かにデグレしたり、例外で事故ったりする。本記事は Evals とは何か、品質を測る5つの方法、エージェント特有の評価、そして小さく始める手順までを実務者向けに整理する。
30秒で結論
迷ったらここだけ
1. なぜEvals（評価）が要るのか
普通のソフトウェアは決定的だ。同じ入力なら同じ出力。だから「期待値と一致するか」を確認する単体テストが効く。ところがLLMは確率的——同じ質問でも言い回しや内容が毎回少し変わる。AIエージェントとRPAの違いで言えば、決定的な「手」ではなく確率的な「頭」であり、完全一致のテストがそのままでは使えない。
ここで起きがちな失敗が3つある。
数例を手で試して「良くなった気がする」で判断。別のケースが壊れていても気づかない。
プロンプトやモデルを変えた結果、ある種類の入力だけ悪化。本番のクレームで初めて発覚。
「たまに変な答えを返す」。確率的なので1回試しても再現せず、原因が追えない。
Evals はこの3つをまとめて防ぐ。評価用のデータセットを用意し、変更のたびに一括採点してスコアを比べる——これだけで「感覚」が「データ」に変わり、デグレが可視化される。AIエージェントに判断を任せるほど、ガードレールと並んで Evals が"品質の土台"になる。
2. Evalsとは何か
Evals（Evaluations）＝AIの出力やエージェントの挙動が、期待どおり正しく・安定して動くかを測る評価のことだ。人間のテストで言えば「採点」にあたる。構成要素はシンプルで、次の3つに分解できる。
評価に使う入力の集まり。実際の利用例・過去ログ・想定される例外を集める。
出力をどう点数化するか。完全一致・ルール判定・別のAIによる採点など。
全件を通して採点し、変更の前後でスコアを比較。良化/悪化を判定する。
Evals は「一度作って終わり」ではなく、プロンプト・モデル・ツールを変えるたびに回す回帰テストとして運用するのが本質。テストコードと同じく、育てていく資産だ。
3. 品質を測る5つの方法
採点のやり方（スコアラー）には代表的に5つある。タスクの性質で使い分け、複数を組み合わせるのが定石だ。
入力に対する期待出力（正解ラベル）を用意し、一致率で採点。分類・抽出・Yes/Noなど答えが決まっているタスクに最適。
正規表現・完全一致・JSONの妥当性・必須キーの有無などを機械的にチェック。「必ずこの形式で返す」の検証に強く、速くて安い。
出力の良し悪しを別のLLMに基準付きで採点させる。要約の質・回答の丁寧さ・関連性など正解が一つに決まらないタスク向け。
プロンプト/モデル変更の前後で同じデータセットのスコアを比較。全体は上がっても一部が下がる"隠れデグレ"を検知する。
実運用のログを継続的に採点・観測。失敗率・コスト・レイテンシ・入力傾向のドリフトを監視し、劣化を早期発見する。
| 方法 | 向くタスク | コスト | 客観性 |
|---|---|---|---|
| ① 正解照合 | 分類・抽出・判定 | 低 | ◎ 高い |
| ② ルールベース | 形式・構造の検証 | 低 | ◎ 高い |
| ③ LLM-as-judge | 要約・生成・対話の質 | 中 | ○ 基準次第 |
| ④ 回帰テスト | 変更のデグレ検知 | 中 | ◎ 相対比較 |
| ⑤ 本番モニタリング | 運用中の劣化検知 | 中〜高 | ○ 継続観測 |
ポイントは「機械で測れるものは機械で（①②）、測れない質はLLM-as-judgeで（③）、それを回帰と本番で回し続ける（④⑤）」という重ね方だ。③のLLM-as-judgeは便利だが、採点用LLM自体もブレるので、判定基準（ルーブリック）を明文化し、可能なら人間の採点と突き合わせて校正する。
4. エージェント特有の評価
単発の応答（1入力→1出力）なら上の5つで足りる。だがAIエージェントは複数ステップで、自分でツールを呼び、途中で判断する。だから「最終出力」だけでなく「過程」も評価する必要がある。
最終的に目的を達成できたか（例：正しい予約が取れたか）。エージェント評価の主指標。
正しいツールを、正しい引数で、正しい順に呼べたか。誤呼び出し・余計な呼び出しを検知。
結論に至る手順・判断の道筋が妥当か。遠回り・無限ループ・不要な再試行を評価。
同じ成功でもトークン消費・所要ステップ・レイテンシが少ないほど良い。実運用では無視できない。
これらを観測するには、エージェントの各ステップ（入力・思考・ツール呼び出し・結果）を記録するトレーシングが前提になる。フレームワークや後述のツールの多くは、このトレースと評価をセットで提供している。複数エージェント構成なら、どのエージェントで失敗したかを切り分けられるよう、階層でトレースを残すとよい。
5. 始め方——小さく作る手順
最初から完璧な評価基盤を作る必要はない。20件のデータセットから始めるのが現実的だ。
- 失敗例を集める：まず"うまくいかなかった入力"を10〜20件。実ログやクレームが宝の山。ここが評価セットの核になる。
- 期待する挙動を書く：各入力に「正解」または「満たすべき条件」を添える。全部に厳密な正解が要るわけではない（③で質を測ればよい）。
- スコアラーを選ぶ：形式チェックは②ルールベース、答えが決まるなら①正解照合、質なら③LLM-as-judge。まず1〜2種類でよい。
- 一括実行してベースライン化：現状のスコアを記録。これが"基準点"になる。
- 変更のたびに回す：プロンプト/モデルを変えたら再実行し、④回帰でスコアを比較。下がったら採用しない。
- 本番でも観測を足す：運用に乗ったら⑤モニタリングで失敗率・コストを継続監視し、悪い実例を評価セットに還流させる。
💡 コツ：評価セットは「よくある成功例」より「起きてほしくない失敗例」を厚く。エッジケース・悪意ある入力・曖昧な依頼を入れておくと、変更で壊れやすい所を先回りで守れる。良い採点基準（ルーブリック）はプロンプト設計と同じで、具体的なほど再現性が上がる。
6. よくある落とし穴
- データセットが小さすぎ／偏りすぎ：成功例ばかり集めると、実運用の失敗を捉えられない。失敗・例外を意図的に混ぜる。
- LLM-as-judgeを盲信する：採点用LLMもブレる・偏る。基準を明文化し、時々人間の採点と突き合わせて校正する。自作自演（同じモデルに書かせて同じモデルに褒めさせる）に注意。
- 最終出力しか見ない：エージェントは過程が命。ツール呼び出し・軌跡・コストを見ないと、"たまたま当たった"を良しとしてしまう。
- 1回の実行で判断する：確率的なので、重要な評価は複数回走らせてばらつきも見る。
- 評価を更新しない：仕様や利用のされ方は変わる。本番の新しい失敗を評価セットに足し続ける。
7. 主要ツール
評価は自作スクリプトでも始められるが、トレーシングと評価をまとめて扱える専用ツールも増えている。代表例（いずれも公式サイト）。
| ツール | 特徴 |
|---|---|
| Anthropic Console / Evals | Claude 向けにプロンプトのテスト・評価をUIで実行。モデル選定の比較にも。 |
| OpenAI Evals | 評価を定義・実行するOSSフレームワーク。データセット＋スコアラーの基本形。 |
| LangSmith | トレーシング＋評価。エージェントの各ステップを記録し、回帰・本番監視まで。 |
| Langfuse | OSSのLLM観測基盤。トレース・評価・コスト監視をまとめて。 |
| Ragas | RAG（検索拡張生成）に特化した評価。関連性・忠実性などの指標。 |
どれを使うにせよ、本質は「データセット＋採点基準＋比較の運用」で変わらない。ツールはそれを楽にするだけだ。まずは小さな評価セットを1つ、手元のスクリプトででも作るところから始めるのがいい。
まとめ
- Evalsとは：AIの出力・挙動を数値で測る"採点"。感覚でなくデータで良化/悪化を判断する仕組み。
- なぜ要る：LLMは確率的でブレる。単体テストが効きにくく、デグレや例外を見逃すから。
- 5つの方法：①正解照合 ②ルールベース ③LLM-as-judge ④回帰テスト ⑤本番モニタリング。機械で測れるものは機械で、質はLLMで、回帰と本番で回し続ける。
- エージェントは過程も評価：タスク成功率・ツール呼び出し・軌跡・コスト。トレーシングが前提。
- 始め方：失敗例20件から。ベースライン化して、変更のたびに回す。
「作れた」と「使える」の間には、Evalsという橋がある。ガードレールが"暴走を止める"守りなら、Evals は"品質を測って上げ続ける"攻めだ。小さな評価セットひとつが、エージェント開発を「感覚」から「工学」に変える。
FAQ
Q. Evalsと普通の単体テストは何が違う？
単体テストは「入力に対し出力が期待値と完全一致するか」を確認します。ところがLLMは確率的で毎回出力が変わるため、完全一致がそのままでは使えません。Evalsは、正解照合に加えてルールベース・LLMによる採点・複数回のばらつき観測など、確率的な出力に合った測り方を組み合わせるのが違いです。
Q. LLM-as-judge（AIに採点させる）は信用できる？
便利ですが万能ではありません。採点役のLLMもブレたり偏ったりします。採点基準（ルーブリック）を具体的に明文化し、時々人間の採点と突き合わせて校正すること、そして生成と採点で役割やモデルを分けて自作自演を避けることが大切です。数値ではなく相対比較（AとBどちらが良いか）にすると安定しやすい傾向があります。
Q. 評価用データは何件くらい必要？
まずは10〜20件で十分に始められます。少数でも「変更でスコアが上がった/下がった」の相対比較には役立ちます。運用しながら、本番で見つかった失敗例を足して育てていくのが現実的です。件数より失敗・例外・エッジケースをちゃんと含めることが重要です。
Q. エージェントの「軌跡（trajectory）」まで評価する必要ある？
本番運用するなら必要です。最終出力が正しくても、遠回り・不要なツール呼び出し・無限ループがあればコストと信頼性を損ないます。各ステップを記録するトレーシングを入れ、タスク成功率と合わせて過程も見るのが定石です。業務自動化のユースケースやクラウド運用の自動化のように権限や副作用が絡む用途ほど、過程の評価が効きます。
