評価（evals）の設計と保守— 結局どうすればいいか

14本を統合する。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 開発の手順が最も具体的:

ギャップを特定 —— skill なしで代表タスクを実行させ、失敗と不足を記録
eval を作る —— そのギャップを突く3シナリオ
ベースラインを測る
最小限の指示を書く —— ギャップを埋め eval を通す分だけ
反復する

「最小限の指示を書く」が要点。 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 the 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 the 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 より良い。

採点の方法は「速く・信頼でき・スケールする」順に選ぶ —— コード（exact / string match）→ LLM（まず信頼性を確かめてから広げる）。人手は最も柔軟で高品質だが遅く高いので、できれば避ける。LLM 採点では採点モデルの thinking をオンにして、点を出す前に推論させる（以前の取得では「<thinking> タグで推論させて捨てる」だった）。develop-tests

エッジケースの作り込みが具体的なのが develop-tests の実用性。たとえば感情分析なら皮肉（“I just love it when my flight gets delayed for 5 hours. bestdayever”）と混合感情を、PHI 検出なら明示的 / 仮定形 / 暗黙的の3種を埋め込んでいる。

忘れやすいエッジケースの類型:

無関係・存在しない入力
過度に長い入力
質の悪い / 有害な / 無関係なユーザー入力
人間でも合意が難しい曖昧なケース

良い eval の4条件と、改善で自分を騙さない方法

本番を映す・強いモデルと多い thinking で点が上がる・最上位でも余地が残る・実行ごとのぶれが小さい（automating-eval-design-and-hillclimbing）。上がらないなら曖昧なタスクか較正のずれた grader を疑い、どの実行でも落ちるタスクは不可能か曖昧の兆候。今のモデルが落ちるからという理由でケースを選ぶと、そのモデルの失敗の指紋を測ってしまう —— 人が難しいと判断した理由を言えるケースを選ぶ。

改善（hillclimb）は訓練と検証に分け、訓練が伸びて検証が平らなら過学習として戻す。失敗を prompt に貼らず、答えを構造的にモデルの手の届かない所に置く。直しても伸びないタスクは、例か grader の欠陥の兆候。

本番の実タスクで、終えたかだけを見ない

運用会社 BAM は、一般のベンチマークではなく答えの確かめられる数千の実際のタスクで、モデル単体と、利用者と同じツール・ファイルを持つ環境の中の両方を評価し、数値の誤りや根拠の無い結論のような失敗の型も見る。どのモデルも解けなかった問題が解けたとき、まず評価の誤りを疑って再実行し、採点の論理を独立に確かめた（balyasny-evaluates-fable-5）。

Cresta はエージェントを作るエージェントを、成果・実行の経路・品質・資源の4つ（品質は参照との比較、資源は時間とモデル使用）で測り、新しいモデルが出るたびに同じタスクと同じ採点で回し直してから変更を採る（cresta-agent-builder）。

4. エージェントの eval は別物

単発の入出力採点では済まない。多ターン・ツール呼び出し・環境の状態変化が絡む。

grader の3種と使い分け

種類	強み	弱み
code-based	速い・安い・客観的・再現する・デバッグしやすい	正当なバリエーションに脆い、ニュアンスを捉えない
model-based	柔軟・スケールする・自由記述を扱える	非決定的・高価・人間との較正が必要
human	ゴールドスタンダード。model grader の較正に使う	高価・遅い

実務での組み合わせ方（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	やること
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原則）

長い時間軸（数分ではなく数時間）
現実的な作業条件
強い候補者でも全部は終わらない分量
out-of-distribution な課題
独立したサブ問題を複数（単一の閃きによる分散を減らす）
可視化のショートカットを作らない（ツール開発への投資判断自体を問う）
実際の業務を代表している

重要な区別: 「無制限の時間なら人間が勝つ」ことと「制限時間内で区別がつく」ことは別問題。

② に対して — 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つ揃う。

事前に何を探すか決められないとき

§6 は eval が壊れる4つの機構を扱ったが、そもそも何を測るべきか分からない場合がある。clio はその状況への手法で、eval や red teaming との違いを明示している。

Traditional, top-down safety approaches (such as evaluations and red teaming) rely on knowing what to look for in advance. Clio takes a different approach, enabling bottom-up discovery of patterns by distilling conversations into abstracted, understandable topic clusters. — clio

従来のトップダウンな安全性手法（評価や red teaming など）は、何を探すかを事前に知っていることに依存する。Clio は異なる手法を取り、会話を抽象化された理解可能な話題クラスタへ蒸留することで、パターンのボトムアップな発見を可能にする。

処理は facet 抽出 → 意味クラスタリング → クラスタ記述 → 階層化の4段で、すべて Claude が実行し人間の分析者は個別の会話を読まない。§2 の「成功基準を先に言語化する」が効かない領域 —— 基準そのものを探しに行く段階 —— に対応する道具として置ける。

自分の eval に引き写すなら、失敗例を人手で読む代わりにクラスタリングして俯瞰するという形になる。個別の失敗（§6 の「個々の失敗」に相当）ではなくパターンを見るのは、ai-code-migration の「見るべきはパターンである」と同じ姿勢。

8. 手順にまとめる

成功基準を SMART で書き下す（多次元になることが多い）
実際の失敗から 20〜50 タスクを集める
参照解を書く（タスクが解けること + grader が動くことの両方を検証できる）
起きるべき場合と起きるべきでない場合を両方入れる
エッジケースを埋め込む（皮肉、混合、暗黙、曖昧）
決定的な grader を優先。主観軸だけ LLM rubric（別モデルで）
capability と regression を分ける
pass@k か pass^k か、プロダクト要件から選ぶ
クリーンな環境から各 trial を始める
transcript を読む
測定条件（資源設定、scaffold）を記録して報告する
飽和と汚染を監視する

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個」。

ai-docs

エクスプローラー

評価（evals）の設計と保守