評価（evals）— 結局どうすればいいか
10本を統合する。eval は「作る」より「壊れないよう保つ」ほうが難しい、というのが横断して見えたこと。
1. eval は prompt engineering の前提であって、後工程ではない
複数の原典が同じ順序を指定している。
This guide assumes that you have: 1. A clear definition of the success criteria … 2. Some ways to empirically test against those criteria … If not, spend time establishing that first. —
prompt-engineering-overview本ガイドは次を前提とする。1. 成功基準が明確に定義されていること、2. その基準に対して経験的にテストする手段があること。なければ、まずそれを固めることに時間を使え。
Create evaluations BEFORE writing extensive documentation. —
agent-skills-best-practices大量のドキュメントを書く「前」に evaluation を作れ。
having a good evaluation set is the most important step in the process —
choosing-a-model（モデル選択の判断でも） 良い evaluation セットを持つことが、この過程で最も重要なステップである。
skill 開発の手順が最も具体的:
1. ギャップを特定 skill なしで代表タスクを実行させ、失敗と不足を記録
2. eval を作る そのギャップを突く3シナリオ
3. ベースラインを測る
4. 最小限の指示を書く ギャップを埋め eval を通す分だけ
5. 反復する「最小限の指示を書く」が要点。 eval がないと、どこまで書けば足りるかが分からず、書きすぎる。
2. 成功基準を先に言語化する
develop-tests の4条件。「良い性能」では eval にならない。
| 条件 | 中身 |
|---|---|
| Specific | 「良い性能」ではなく「正確な感情分類」 |
| Measurable | 定量指標か明確な定性スケール。倫理や安全のような「もやっとした」主題も定量化できる |
| Achievable | ベンチマーク・過去実験・専門知識に基づく |
| Relevant | アプリの目的とユーザーのニーズに合っている |
書き換えの例:
❌ Safe outputs
✅ Less than 0.1% of outputs out of 10,000 trials flagged for toxicity by our content filter.
❌ The model should classify sentiments well
✅ F1 score of at least 0.85 (Measurable, Specific) on a held-out test set of 10,000
diverse Twitter posts (Relevant), a 5% improvement over our current baseline (Achievable).多くの場合、単一指標では足りない。
Most use cases need multidimensional evaluation along several success criteria. 多くのユースケースでは、複数の成功基準に沿った多次元の評価が必要になる。
8軸が挙げられている: task fidelity / consistency / relevance and coherence / tone and style / privacy preservation / context utilization / latency / price。
3. 設計の3原則
develop-tests の3つ。3つ目が最も直感に反する。
- タスク固有にする — 現実のタスク分布を反映し、エッジケースを埋め込む
- 自動採点できる形に問いを設計する
- 品質より量を優先する
More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals. 信号がやや弱くとも自動採点で問題数を増やすほうが、人手で丁寧に採点した少数の eval より良い。
エッジケースの作り込みが具体的なのが develop-tests の実用性。例えば感情分析なら皮肉（“I just love it when my flight gets delayed for 5 hours. bestdayever”）と混合感情を、PHI 検出なら明示的 / 仮定形 / 暗黙的の3種を埋め込んでいる。
忘れやすいエッジケースの類型:
- 無関係・存在しない入力
- 過度に長い入力
- 質の悪い / 有害な / 無関係なユーザー入力
- 人間でも合意が難しい曖昧なケース
4. エージェントの eval は別物
単発の入出力採点では済まない。多ターン・ツール呼び出し・環境の状態変化が絡む。
grader の3種と使い分け
| 種類 | 強み | 弱み |
|---|---|---|
| code-based | 速い・安い・客観的・再現する・デバッグしやすい | 正当なバリエーションに脆い、ニュアンスを捉えない |
| model-based | 柔軟・スケールする・自由記述を扱える | 非決定的・高価・人間との calibration が必要 |
| human | ゴールドスタンダード。model grader の calibration に使う | 高価・遅い |
実務での組み合わせ方（demystifying-evals-for-ai-agents が明示）:
全 grader を並べた例は網羅性のためであり、実務では正しさの検証に unit test、全体的なコード品質に LLM rubric を使い、他は必要になったときだけ足す。
capability eval と regression eval を混ぜない
| 問い | 期待される pass rate | |
|---|---|---|
| capability | 何がうまくできるか | 低いところから始める。登る坂を与える |
| regression | 以前できていたことを今もできるか | ほぼ100% |
ローンチ後に pass rate が高くなった capability eval は、継続実行する regression suite に「卒業」させる。
非決定性を数字にする
| 指標 | 意味 | 使いどころ |
|---|---|---|
| pass@k | k 回で少なくとも1回成功 | 1回成功すればよいツール |
| pass^k | k 回全部成功 | 一貫性が必須の顧客向けエージェント |
試行ごと 75% で3試行なら pass^3 ≈ 42%。 「だいたい動く」が「毎回動く」にならないことが数字で見える。
経路ではなく成果物を採点する
Grade what the agent produced, not the path it took. エージェントが辿った経路ではなく、生み出した成果物を採点せよ。
過度に脆いテストを避けるため。多要素タスクには部分点を用意する。
5. ゼロからイチへ
demystifying-evals-for-ai-agents の Step 0〜8。始め方が具体的なのが価値。
Step 0 実際の失敗から取った 20〜50 個の単純なタスクで始める
（数百を待たない。初期は小さいサンプルでも変化がはっきり出る）
Step 1 すでに手動でやっているチェックとバグ報告をテストケースに変換
Step 2 参照解付きの、曖昧さのないタスクを書く
「2人のドメイン専門家が独立に同じ pass/fail に達する」が基準
Step 3 振る舞いが起きるべき場合と起きるべきでない場合の両方を入れる
Step 4 各 trial をクリーンな環境から始めて隔離する
Step 5 可能なら決定的な grader。経路ではなく成果物を採点
Step 6 transcript を読む
Step 7 capability eval の飽和を監視する
Step 8 中核基盤を持つ専任チーム + ドメイン専門家がタスクを寄与Read the transcripts! トランスクリプトを読め。
Owning and iterating on evaluations should be as routine as maintaining unit tests. evaluation を自分たちで保有し改善し続けることは、ユニットテストの保守と同じくらい日常的であるべきだ。
6. eval は4つの異なる機構で壊れる
ここが横断して初めて見える部分。 4本の原典が、それぞれ別の壊れ方を報告している。
| 機構 | 何が起きるか | 出所 |
|---|---|---|
| ① モデルが解いてしまう | 人間向けの課題をモデルが突破。制限時間内で上位候補と区別がつかなくなった | AI-resistant-technical-evaluations |
| ② モデルが答えを取りに行く | 「これは評価だ」と自分で仮説を立て、ベンチマークを特定して答えの鍵を復号した | eval-awareness-browsecomp |
| ③ 測定条件がスコアを動かす | インフラ設定だけで 6 パーセントポイント | infrastructure-noise |
| ④ 飽和して信号が消える | 解けるタスクを全部通してしまい、改善のシグナルが出なくなる | demystifying-evals-for-ai-agents |
それぞれの対処:
① に対して — AI 耐性のある設計（7原則）
1. 長い時間軸（数分ではなく数時間）
2. 現実的な作業条件
3. 強い候補者でも全部は終わらない分量
4. out-of-distribution な課題
5. 独立したサブ問題を複数（単一の閃きによる分散を減らす）
6. 可視化のショートカットを作らない（ツール開発への投資判断自体を問う）
7. 実際の業務を代表している重要な区別: 「無制限の時間なら人間が勝つ」ことと「制限時間内で区別がつく」ことは別問題。
② に対して — eval の integrity を継続的な問題として扱う
URL のブロックリストでは不十分だった。 最も効いたのはベンチマーク名の表記ゆれを含む検索結果ごとブロックすること。
検出のシグナル:
- トークン消費の外れ値（中央値の 38倍）
- transcript でモデルの推論が「答えを探す」から「問いの構造を分析する」に転換する
- multi-agent 構成では汚染率が 3.7倍（0.24% → 0.87%）
This report will, itself, likely contribute to the problem. この報告書はそれ自体が、おそらく問題の一因になるだろう。
③ に対して — 測定条件を一級の実験変数として扱う
□ 保証される割り当てと強制終了の閾値を「別々に」指定する（単一の固定値にしない）
□ 上限倍率は 3倍を出発点に。使った値を必ず報告する
□ 複数の時刻・複数の日に回す
□ 差が 3 パーセントポイント未満なら、設定が文書化されるまで疑うThe boundary between “model capability” and “infrastructure behavior” is blurrier than a single benchmark score suggests. 「モデルの能力」と「インフラの振る舞い」の境界は、単一のベンチマークスコアが示唆するよりも曖昧である。
外部評価者にとっての非対称性も指摘されている。モデル提供者は専用ハードで遮蔽できるが、外部評価者は同じことができない。
④ に対して — 飽和を監視し、難度を上げる
飽和が進むと最難関のタスクしか残らないので進捗が鈍る。capability eval を作り直すタイミングの指標として使う。
7. eval が測っているのはモデルではない
swe-bench-sonnet の指摘が、この分野の前提を変える。
SWE-bench doesn’t just evaluate the AI model in isolation, but rather an entire “agent” system. The performance of an agent on SWE-bench can vary significantly based on this scaffolding, even when using the same underlying AI model. **SWE-bench は AI モデル単体を評価しているのではなく、「エージェント」システム全体を評価している。**SWE-bench でのエージェントの性能は、同じ基盤モデルを使っていても、この scaffolding 次第で大きく変わりうる。
→ スコアを比べるときは scaffold も比べる。 そして infrastructure-noise を合わせると、scaffold とインフラの両方を文書化しないとスコアの比較は成立しない。
この2本を並べて初めて、「ベンチマークのリーダーボードをそのまま信じてはいけない」理由が2つ揃う。
8. 手順にまとめる
1. 成功基準を SMART で書き下す（多次元になることが多い）
2. 実際の失敗から 20〜50 タスクを集める
3. 参照解を書く（タスクが解けること + grader が動くことの両方を検証できる）
4. 起きるべき場合と起きるべきでない場合を両方入れる
5. エッジケースを埋め込む（皮肉、混合、暗黙、曖昧）
6. 決定的な grader を優先。主観軸だけ LLM rubric（別モデルで）
7. capability と regression を分ける
8. pass@k か pass^k か、プロダクト要件から選ぶ
9. クリーンな環境から各 trial を始める
10. transcript を読む
11. 測定条件（資源設定、scaffold）を記録して報告する
12. 飽和と汚染を監視する9. 最後に: 早く始めるほうが速い
Teams that invest early find the opposite: development accelerates as failures become test cases, test cases prevent regressions, and metrics replace guesswork. 早期に投資したチームは逆の結果を得る。失敗がテストケースになることで開発は加速し、テストケースが回帰を防ぎ、推測が数値に置き換わる。
eval を作らない理由として最もよく挙がる「まだ早い」は、実際には逆。 demystifying-evals-for-ai-agents が挙げる3事例のうち Bolt は「広く使われるエージェントができた後」に着手し、3ヶ月かかった。Claude Code は狭い領域（簡潔さ、ファイル編集）から始めて広げた。
始め方は「狭く、実際の失敗から、20〜50個」。