LLM を組み込んだアプリやエージェントは、同じ入力でも毎回少しずつ違う答えを返します。
そのため、プロンプトやモデルを変えたあとに「前より良くなった気がする」で判断していると、別の場所で壊れた変化を見落とします。
入力と採点のルールを組にして、品質を数字で測り続ける仕組みが評価（Evals）です。
公開ベンチマークとの違い、評価セットの作り方、採点方法の選び方、回帰テストとしての回し方が分かると、自分のアプリへの変更が良かったのか悪かったのかを数字で説明できます。
Evalsとは何か
Anthropic は 2026 年 1 月に公開したエージェントの評価の解説記事で、評価を「AI システムのためのテスト」と定義しています。
AI に入力を渡し、その出力に採点のロジックを当てて、うまくいったかどうかを測るものです。
OpenAI の評価のベストプラクティスも、生成 AI は同じ入力から違う出力を返すことがあるため、従来のソフトウェアのテストだけでは足りないと説明しています。
評価は、出力の揺らぎを前提にしたうえで、AI の振る舞いを繰り返し確かめられる形にしたテストと考えると分かりやすいでしょう。
同じガイドは、「evals」という言葉が指すものを次の 3 つに分けています。
- モデル同士を比べる業界のベンチマーク（MMLU など）
- ROUGE や BERTScore のような、決まった計算式で出す指標
- 自分の LLM アプリの性能を測るために作る、個別のテスト
ここから先で扱うのは 3 つ目の、自分のアプリのための評価です。
公開ベンチマークとの違い
公開ベンチマークは、多くのモデルに同じ問題を解かせて、能力を横並びで比べるための共通の物差しです。
一方で自分のアプリの評価は、自分のユーザーが実際に送ってくる入力と、自分たちが決めた合格の基準で作ります。
| 項目 | 公開ベンチマーク | 自分のアプリの評価 |
|---|---|---|
| 測るもの | モデル単体の一般的な能力 | プロンプト・ツール・モデルを組み合わせたアプリ全体 |
| 問題の出どころ | 研究者が用意した共通の問題 | 自分のユーザーの入力や不具合の報告 |
| 合格の基準 | ベンチマークごとに決まっている | 自分たちのプロダクトの要件で決める |
| 主な使い道 | モデルの比較と選定 | 変更の良し悪しの判定と回帰の検出 |
Anthropic は、エージェントを評価するときに測っているのはモデル単体ではなく、モデルとそれを動かす仕組みの組み合わせだと書いています。
OpenAI のガイドも、学術的な指標だけに頼ることや、本番の利用のされ方を再現していないデータで評価することを避けるべき例に挙げています。
評価を持っているチームは、新しいモデルが出たときにも強みと弱みをすぐに確かめ、数日で乗り換えられるとも Anthropic は述べています。
公開ベンチマークの高い点数をそのまま信じてよいかという話は、次の記事が詳しいです。
評価を組み立てる部品
Anthropic の解説記事は、評価を組み立てる部品に次の名前を付けています。
- タスク: 入力と成功の条件を決めた 1 問で、テストケースとも呼ばれる
- 試行（trial）: タスクを 1 回解かせること。出力が毎回変わるので、1 つのタスクを何回も試す
- 採点器（grader）: 出力のある側面を採点するロジックで、1 つのタスクに複数付けてよい
- 記録（transcript）: 1 回の試行の全記録で、出力・ツールの呼び出し・途中の結果を含む
- 結果（outcome）: 試行が終わった時点の環境の最終状態
- 評価ハーネス: タスクを並べて走らせ、記録を残し、採点して集計する仕組み
- 評価スイート: 同じ目的のタスクを集めたもの
なかでも記録と結果の区別は、エージェントの評価で効いてきます。
航空券を予約するエージェントが最後に「予約しました」と言っても、それは記録に残った発言にすぎません。
結果として確かめるべきなのは、予約のデータベースに本当に予約が入っているかどうかです。
評価セットの作り方
評価セットを作る前に、まず「成功」の中身を決めます。
Claude の公式ドキュメントの成功の基準と評価の作り方は、基準を具体的で、測れて、達成できて、用途に合ったものにするよう求めています。
例として挙がっているのは、「感情をうまく分類する」ではなく「1 万件の保留テストセットで F1 スコア 0.85 以上」と書く形です。
基準が決まったら、問題を集めます。
Anthropic は、何百問も要ると思い込んで評価を後回しにするチームを見てきたと書いています。
そのうえで、実際の失敗から作った 20〜50 問の簡単なタスクで始めれば十分だとしています。
開発の初期は 1 回の変更の効き目が大きいので、少ない問題数でも違いが見えるという理由です。
問題の出どころとして挙がっているのは、次のようなものです。
- リリースの前に毎回手で確かめている操作
- ユーザーがよく試す使い方
- 不具合の管理表やサポートへの問い合わせに残った失敗
OpenAI のガイドも、開発中からログを残しておき、そこから評価に使える例を掘り出すよう勧めています。
問題の書き方では、曖昧さをなくすことが求められます。
Anthropic の基準は、その分野に詳しい人が 2 人で別々に採点しても、同じ合否になる問題かどうかです。
正解の例を 1 つ用意しておけば、その問題が解けることと、採点器の設定が正しいことを同時に確かめられます。
また、ある振る舞いが起きるべき場面と、起きるべきでない場面の両方を入れます。
Anthropic は Claude.ai のウェブ検索の評価で、天気のように検索すべき質問と、「Apple の創業者は誰か」のように手持ちの知識で答えるべき質問の両方を用意しました。
片側だけを試すと、何でも検索するような片寄った改善に向かってしまうからです。
Claude のドキュメントは、人が手で採点する少数の問題より、自動で採点できる多数の問題を優先するよう勧めています。
採点のしかたは3種類
採点器は、大きく分けてコード、モデル、人の 3 種類です。
Anthropic の解説記事にある比較を短くまとめると、次のようになります。
| 種類 | 例 | 強み | 弱み |
|---|---|---|---|
| コード | 完全一致・正規表現・単体テスト・静的解析・ツール呼び出しの確認 | 速い・安い・何度でも同じ結果 | 正しい言い換えにも不合格を付ける・細かな良し悪しは測れない |
| モデル | 採点表（ルーブリック）での採点・2 つの回答の比較・正解例との照合 | 自由な文章を扱える・数を増やしやすい | 判定が毎回同じとは限らない・人の判定との突き合わせが要る |
| 人 | 専門家のレビュー・抜き取りの確認・A/B テスト | 質が最も高い | 遅い・費用がかかる |
Anthropic は、コードで決まるものはコードで採点し、必要なところだけモデルに任せ、人は確かめのために絞って使うよう勧めています。
Claude のドキュメントも、いちばん速くて確実で数を増やせる方法を選び、人の採点はできるだけ避けるよう書いています。
モデルに採点させる LLM-as-a-Judge では、まず人の採点と比べて判定がずれていないかを確かめます。
情報が足りないときに「不明」と返す逃げ道を用意することや、観点ごとに別々の採点役を立てることも、Anthropic が挙げている工夫です。
OpenAI のガイドは、回答の並び順や長さに判定が引っ張られる偏りを挙げ、2 つの回答の比較か合否の判定にすると安定すると書いています。
LLM-as-a-Judge の仕組みと偏りの詳しい中身は、こちらの記事で扱っています。
採点の対象については、エージェントがたどった手順より、最後に作ったものを見るよう Anthropic は勧めています。
ツールを決まった順番で呼んだかまで採点すると、設計者が想定しなかった正しいやり方まで不合格にしてしまうからです。
いくつもの工程があるタスクでは、途中まで正しくできた分に部分点を付けると、改善の度合いが数字に表れます。
回帰テストとして回す
評価には、目的の違う 2 つの使い方があります。
Anthropic は、「何がうまくできるか」を測る能力の評価と、「前にできたことが今もできるか」を測る回帰の評価を分けています。
能力の評価は、低い合格率から始めて少しずつ上げていく目標になります。
回帰の評価は、ほぼ 100% の合格率が当たり前で、点数が下がったら何かが壊れた合図です。
能力の評価で高い合格率に届いたタスクは、回帰の評価に移して回し続けます。
出力が毎回変わる以上、1 回だけ試して合否を決めるのは危うい判断です。
Anthropic は、k 回のうち 1 回でも成功する確率を pass@k、k 回すべて成功する確率を pass^k と呼び分けています。
1 回あたりの成功率が 75% のエージェントを 3 回試すと、3 回とも成功する確率は 0.75 の 3 乗で約 42%まで下がります。
1 回でも成功すればよい道具なら pass@k、毎回同じように動いてほしい顧客向けのエージェントなら pass^k を見る、というのが Anthropic の使い分けです。
次のコードは、問い合わせを分類するタスクをコードで採点し、1 問を 3 回ずつ試す考え方を示した短い例です。
cases = [
{"input": "注文はいつ届きますか", "expected": "order_status"},
{"input": "返品の条件を教えてください", "expected": "return_policy"},
]
K = 3
def run_case(case, classify):
results = [classify(case["input"]) == case["expected"] for _ in range(K)]
return {
"any_pass": any(results), # k 回のうち 1 回でも正解（pass@k の考え方）
"all_pass": all(results), # k 回すべて正解（pass^k の考え方）
}
# 以下、全タスクの結果を集計する処理は省略こうした評価は、変更のたびに自動で回してこそ意味があるものです。
OpenAI のガイドは、変更のたびに評価を回し、本番の様子を見ながら評価セットを増やし続ける継続的な評価を勧めています。
Anthropic も、自動の評価を、リリース前と CI/CD で変更やモデルの更新ごとに回す最初の防御線と位置づけています。
リリース後は、本番の監視や利用者の声、記録の読み込みと組み合わせるという考え方です。
評価の問題が固定されていれば、応答の速さやトークンの使用量、1 タスクあたりの費用も同じ物差しで追えます。
なお、OpenAI がダッシュボードと API で提供してきた Evals プラットフォームは、2026 年 6 月に終了が告知されました。
2026 年 10 月時点の非推奨の一覧では、10 月 31 日に読み取り専用になり、11 月 30 日に停止する予定です。
評価の枠組みについて Anthropic は、手早く選んで、力は問題と採点器の質に注ぐよう勧めています。
大学のAI-TAの記録を評価の目で読む
評価の考え方が実際の運用にどう当てはまるかは、公開された運用記録を読むとつかみやすくなります。
物理学の講義を担当する大学教員が、講義資料をもとに答える AI の TA を 1 学期動かした運用記録を Zenn に公開しています。
記録の著者は評価の仕組みの話として書いているわけではないので、ここから先の読み方は私の解釈です。
最初の失敗は、「資料にないことは答えない」という規則が強すぎたことでした。
「どのような質問ができますか」という使い方の質問にまで講義の内容以外は受け付けないと答え、資料の理解に必要な基礎の数学の補足まで断っていたと記録にあります。
これは、断るべき質問だけを想定して、答えるべき質問の側を試していないときに起きる片寄りと同じ形です。
次の失敗は、資料に実在する用語を、別の式の名前として引用したことでした。
式 (2.13) の直前に印字された名前を逐語で引用するよう求める質問に対し、AI は式 (2.12) を指す文の「フリードマン方程式」を、資料からの直接引用として答えていました。
同じ質問は 6 回繰り返され、6 回とも同じ種類の誤りが出たと書かれています。
1 回の偶然ではなく再現する失敗であり、資料の原文と照らせば合否が決まるので、評価のタスクに書き直しやすい種類の失敗です。
後期の改修では、回答を「資料に直接ある」「資料の式から計算できる」「理解に必要な補足」「確かめられない逐語の引用は言い切らない」の 4 種に分けて扱うようにしました。
ただし、同時にモデルも gemini-2.5-flash から gemini-3.8-flash に替えたため、個々の改修の効果は切り分けられていないと著者自身が書いています。
7 月に見つけた誤引用は、後期版で同じ条件の再試験をする予定だと記録の末尾にあります。
固定した問題をあらかじめ持っておき、1 か所ずつ変えるたびに回せば、どの変更が効いたのかを数字で分けられます。
評価そのものの落とし穴
評価は作って終わりではなく、評価の側が間違っていることもあります。
Anthropic によると、Claude Opus 4.5 の CORE-Bench の点数は最初 42% でした。
採点と問題の不備を直し、制約の少ない実行の仕組みに替えると、95% まで上がっています。
答えが「96.124991…」の問題で「96.12」を不合格にする厳しすぎる採点や、曖昧な問題文が原因でした。
点数が低いときは、モデルより先に採点器と問題を疑う必要があります。
試行どうしが影響し合うのも、よくある落とし穴です。
Anthropic の内部の評価では、前の試行が残した git の履歴を Claude が読んで、一部のタスクで有利になっていた例がありました。
試行ごとにまっさらな環境から始めないと、点数が実力以上にも以下にもぶれます。
合格率が 100% に張り付いた評価は、回帰の検出には使えても、改善の手がかりにはなりません。
採点の抜け道を突かれないように、問題を本当に解かなければ合格できない作りにしておくことも求められます。
どの落とし穴に対しても、Anthropic が繰り返し勧めているのは、採点結果だけでなく記録そのものを読むことです。
失敗した試行の記録を読めば、エージェントが本当に間違えたのか、採点器が正しい答えをはじいたのかを見分けられます。
最後に
評価は、自分のアプリにとっての「良い」を、入力と採点のルールで書き下したテストです。
公開ベンチマークの点数はモデル選びの参考になりますが、自分のユーザーの使い方で壊れていないかまでは教えてくれません。
実際の失敗から 20〜50 問を作り、変更のたびに回し、点数と一緒に記録を読むことが、評価を始めるときのいちばん小さな一歩です。
以上です。
コメントを残す