図解
はじめに
同じモデルの、同じベンチマークのスコアが 42% から 95% になりました。
モデルは変えていません。採点側のバグを直しただけです。
Anthropic の Demystifying evals for AI agents に出てくる話です。Opus 4.5 を CORE-Bench で測ったら 42% だった。調べたら、評価の仕組み側に問題があった。直したら 95% になった。
つまり、最初の 42% という数字はモデルの能力ではなく、測り方を測っていたわけです。
AIに何かをやらせたとき、多くの人は出力を見て「良さそう」「イマイチ」と判断します。それを数字にしたのが評価です。
そしてその数字自体が壊れていることがあります。
この記事では、AIの出力をどう測るのかを、公開された指針から整理します。
この記事で扱うこと
- 42% が 95% になった話
- 採点するのは、コードか、モデルか、人か
- 1回通ればいいのか、3回連続で通る必要があるのか
- 最初のデータセットは何件あればいいのか
- 評価はいつ書くのか
🔬 42% が 95% になった
まず、この話から入ります。
CORE-Bench というベンチマークで Opus 4.5 を測ったところ、42% でした。
数字だけ見れば「半分も解けない」という評価になります。改善の方向を考え始めるところです。
ところが、調べてみると問題は別のところにありました。採点する側にバグがあった。
この図の左と右で変わっているのは、採点の仕組みだけです。モデルも問題も同じものです。
直した結果が 95%。53ポイントの差が、評価側の不具合で生まれていました。
ここから持ち帰るべきことは1つです。評価の数字が低いとき、疑う先はモデルだけではありません。
低いスコアを見て、プロンプトを直し、モデルを変え、データを足す。**その前に、採点が正しく動いているかを確かめる。**この順番を飛ばすと、存在しない問題を何週間も追いかけることになります。
🧭 採点するのは、コードか、モデルか、人か
評価の中心は、採点者です。公式の記事は3種類に分けています。
| 採点者 | 向いているもの | 強み | 弱み |
|---|---|---|---|
| コード | 結果が客観的に決まるもの（テストが通る、状態が変わった） | 速い・安い・再現する・追える | 正しい表現ゆれに弱い |
| モデル | 開きのある判断が要るもの | 柔軟・スケールする・機微を拾う | 非決定的・高い・較正が要る |
| 人 | 基準そのものを決めるとき | 専門家の判断に一致する | 高い・遅い・スケールしない |
この図の3本が、採点を引き受ける主体です。上ほど速く、下ほど賢い。
そして、選び方まで書かれています。
Choose deterministic graders where possible, LLM graders where necessary or for additional flexibility, and using human graders judiciously.
（できるところは確定的な採点者を選び、必要なとき、または柔軟さが要るときに LLM の採点者を使い、人間の採点者は慎重に使う）
順番が決まっています。まずコード。無理ならモデル。人は絞って使う。
具体的には、コードの採点は文字列の一致、正規表現、あいまい一致、テストの成否、静的解析、状態の確認、ツール呼び出しの確認。モデルの採点は観点表による採点、自然文での判定、2つを比べる、正解と照らす、複数の判定を合議にかける。
**LLM の採点者は非決定的です。**同じ出力に、毎回同じ点が付くとは限りません。白黒が確定的に付く場所にモデルを置くと、揺らぎを持ち込むことになります。
🎯 1回通ればいいのか、3回連続で通る必要があるのか
数字の読み方でもう1つ。同じ成功率でも、数え方が2つあります。
pass@k は「k回試して1回でも成功すればよい」。pass^k は「k回とも成功する必要がある」。
具体的に見ます。1回あたりの成功率が 75% のとき、3回連続で成功する確率はこうなります。
0.75 × 0.75 × 0.75 ≈ 0.42
75% が 42% になります。
この図の右側の落ち方が、連続で求めたときに起きることです。同じ能力でも、要求の仕方で数字が半分近くになります。
どちらで測るかは、使い方で決まります。人が見て、失敗したらやり直させる使い方なら pass@k で足ります。無人で最後まで走らせるなら、pass^k で見るべきです。途中で1回失敗したら、そこで終わりだからです。
「成功率75%」という数字を見たときに、どちらの数え方かを確かめる癖があると、判断を外しません。
📏 最初は20〜50件でいい
「評価を作る」と聞くと、大量のテストケースを揃える話に聞こえます。
そうではない、と書かれています。**最初のデータセットは20〜50件の単純なタスクで足ります。**数百件ではありません。
この図の左端が出発点です。小さく始めて、外れたところを足していく。
理由は単純で、最初から大量に作ると、採点の仕組みが正しいかを確かめられないまま量が増えるからです。42% の話がまさにそれで、規模が大きいほど、採点側の不具合に気づきにくくなります。
評価の種類も分かれています。能力を測るものは、最初の通過率が低いのが正常です。伸びしろを測るためのものだからです。壊れていないかを測るものは、通過率が高いのが正常です。下がったら回帰が起きています。
この2つを混ぜると、数字を見ても何も判断できなくなります。
🚧 測れないものもある
評価で全部が見えるわけではありません。ここも明記されています。
The capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them harder to evaluate.
（AIエージェントを有用にしている性質、つまり自律性・知性・柔軟さは、そのまま評価を難しくする）
自由に動けるほど、正解が一意に決まらなくなります。**同じ目的地に、違う道で着くことがある。**コードの採点者が表現ゆれに弱いのは、これが理由です。
だから評価だけで完結させない、とも書かれています。
A complete picture includes production monitoring, user feedback, A/B testing, manual transcript review, and systematic human evaluation.
（全体像には、本番の監視・利用者の声・A/Bテスト・やりとりの目視・体系的な人手の評価が含まれる）
この図で評価が占めているのは一部です。残りは、出したあとに分かることです。
数字が良くても、実際に使われなければ意味がありません。逆に数字が悪くても、利用者が満足していることもあります。
🪜 評価は、作り終わってから書くものではなかった
並べ直すと、順番の話になります。
評価はふつう、作ったあとに「どれくらいできているか」を測るものとして扱われます。
ところが、こう書かれています。
Evals are especially useful at the start of agent development to explicitly encode expected behavior.
（評価は、エージェント開発の最初に、期待される振る舞いを明示的に符号化するものとして特に有用である）
この図の矢印の向きが、ふつうの順番と逆です。測るために書くのではなく、決めるために書く。
評価を先に書くと、「何をもって正しいとするか」を先に決めることになります。決められないなら、その時点で仕様が決まっていません。
これはテストを先に書く考え方と同じ形です。違うのは、AIの出力は毎回変わるので、「通る／通らない」だけでは足りないところです。だから採点者の選び方が要る。
📝 まとめ
3つに絞ります。
1つ目。数字が低いとき、採点側を先に疑う。 42% が 95% になった例があります。モデルを変える前に、測り方が動いているかを確かめます。
2つ目。採点者はコード・モデル・人の3つ。 できるところはコード、必要なところだけモデル、人は絞って使う。順番が決まっています。
3つ目。同じ成功率でも数え方で変わる。 1回あたり75%は、3回連続なら42%です。無人で走らせるなら後者で見ます。
明日いちばん先に試すことを1つ挙げるなら、これをおすすめします。
いま「うまく動いている」と思っているAIの処理について、何をもって成功とするかを20件だけ書き出してみてください。
書けない項目が出てきたら、そこはまだ仕様が決まっていない場所です。評価が書けないものは、正しさを誰も判定できていません。
そして書き出した20件を、コード・モデル・人のどれで採点するかに仕分けてください。全部が「人が見る」になっていたら、その処理は自動で回せません。
📚 参考
一次資料
- Demystifying evals for AI agents — Anthropic、2026年1月9日。本記事の数字と引用はすべてここから
関連
- Designing AI-resistant technical evaluations — Anthropic、2026年1月21日
- Quantifying infrastructure noise in agentic coding evals — Anthropic、2026年2月5日
- Eval awareness in Claude Opus 4.6's BrowseComp performance — Anthropic、2026年3月6日
💡 この記事について
本記事は2026年9月18日時点で公開されている情報をもとにまとめています。英文の引用はすべて原典と照合しています。日本語訳は筆者によるもので、公式訳ではありません。
数字はすべて Anthropic が公開したものです。筆者による計測は含まれません。
ベンチマークのスコアはモデルの版と測定時期で変わります。42%／95% という値は CORE-Bench での Opus 4.5 の例であり、他のモデルや他のベンチマークに一般化できるものではありません。
エンジニアがAIを活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。