原典: Automating eval design and hillclimbing with Claude
一行要約
良い eval の4条件（本番を映す・強いモデルと多い thinking で点が上がる・最上位でも余地が残る・実行ごとのぶれが小さい）と、自分を騙さずに改善する hillclimb の規律（訓練と検証に分け、検証が伸びない改善は戻す、失敗を prompt に貼らない）を、/claude-api build-eval と /claude-api hillclimb が手順にしている。
要点
良い eval の4条件
- タスクが本番を映す —— 作りやすい・採点しやすいから選んだタスクではなく、本当に気にする分布から取る
- 強いモデルと多い thinking で点が上がる —— 上がらないなら、曖昧なタスクか較正のずれた grader が足を引っ張っている
- 最上位でも「通過できる」余地が残る —— 最も強いモデルの最も高い effort でも 100% よりかなり下でないと、変更の効果を判断できない
Importantly, the gap should not be explained by impossible or ambiguous tasks: a common tell is that a task fails every evaluation run, regardless of the number of replicates. A good task is one where two domain experts would reach the same verdict and everything the grader checks is stated in the task.
大事なのは、その差が不可能なタスクや曖昧なタスクで説明されてはならないことだ。よくある兆候は、繰り返し回数に関わらず、あるタスクがどの実行でも落ちることである。良いタスクとは、2人の専門家が同じ判定に至り、grader が確かめることがすべてタスクに書かれているものである。
- 実行ごとのぶれが小さい —— ぶれの原因は曖昧なタスク、同じ出力に違う判定を出す grader、設定（effort が一貫して当たっていない）、環境（前の試行の残り —— ファイルや git の履歴 —— がエージェントに答えを渡す）
敵対的なサンプリングの罠
Model capability is jagged. If you pick cases because today’s model fails them, you are sampling the valleys of one model’s capability surface.
モデルの能力はでこぼこしている。今のモデルが落ちるからという理由でケースを選ぶと、1つのモデルの能力の谷を拾うことになる。
そうした eval は、アプリにとって本質的に難しいこと・価値のあることではなく、そのモデルの失敗の指紋を測ってしまう。人が難しいと判断したケースを選ぶ —— 入れる前に、なぜ難しいかを言えること。本番のトラフィック・バグ報告・チケットからの失敗を入れる。ただしユーザーのトラフィックを鵜呑みにしない（ユーザーは動くと思うことを試すので、易しい側に偏りうる）。
/claude-api build-eval
Claude がインタビューし、コードベースの中に eval を作り、決まった所で承認を待つ。
- 例の取り方の順: 本番の transcript（保持期間と機微データを確かめてから）→ バグ報告とサポートチケット → 手で書く5〜10件 → コードベースから合成。すべての入力を見せるページを作り、確認を待つ
- 最も安く合う grader を提案する —— 出力が限られるならコード（完全一致、固定集合のラベル、スキーマに合う JSON、通るテスト）、開かれているなら LLM-as-judge。rubric は 1〜5 の尺度ではなく、確かめられる主張として書く。基準がある比較なら、どちらが基準かを伏せ、ランダムな順で2つを読ませて良いほうを選ばせる。judge のモデルはテスト対象のモデルにしない
- grader を信じる前に、採点された transcript を読む —— 採点の失敗は、eval の設定の誤りで最もよくあるものの1つ
- 診断 —— 同じ出力に grader を2回かけて判定が変わるか、タイムアウト・API エラー・途中で切れた答え（基盤のノイズをモデルのぶれと取り違えないため）、基準がすでに約95%以上なら、品質ではなくコストや遅延を探るべきだと警告する
hillclimb の当てどころ
- 安く反復できる面 —— prompt や skill のようなテキストは変えるのも戻すのも安い。harness への開かれた変更は大きなコード変更になる
- 点の変化をその面に帰せる —— skill の発火率と skill の description のように、指標と変える面が直結しているもの
- 範囲の決まった目的 —— 余地を考えずに「性能を上げて」と頼むと止まりやすい。eval が飽和していても、性能を保ったままコストを下げるは強い目的になる
過学習
eval が本番の分布と完全に一致することはまれで、eval の内容が harness（prompt・ツール・Claude を呼ぶループ）に漏れる（本番ではほとんど役立たない OCR ツールを、eval のために足す、など）。
- ケースを分ける —— hillclimber が読める訓練用と、決して見ない検証用。訓練が伸びて検証が平らなら過学習の兆候
- 失敗を prompt に貼らない
- 答えを構造的にモデルの手の届かない所に置く（reward hacking を防ぐ）
/claude-api hillclimb
変えてよい面（system prompt、skill や指示ファイル、ツール説明、モデル・effort などの API パラメータ、harness のコード）と目的（性能、または性能を保ったコスト）を選ぶ。eval をランダムに訓練と検証に分ける。
- 最初の回の前に、eval のノイズが、動く価値のある最小の改善より小さいかを確かめる（大きければ繰り返しかケースを増やすよう勧める）
- 各回、前の回の訓練の transcript を読み、パッチを1つ提案する —— 言い回しを変えるのではなく、失敗の根を直す（原因の節を書き直す、欠けた規則を足す）
- 訓練が伸びて検証が平らなら過学習を疑って戻す。後退も戻す。両方伸びたら残す
- 2〜3回止まったら、残った訓練の失敗を1つずつ読んで原因で分ける（編集はしない）—— 曖昧なケース・harness のエラー・ぶれを拾い、正当な失敗だけを次の回に回す
- 終わると検証で最も良かった版にコードを残し、基準との差を信頼区間つきで報告する。差がノイズの範囲なら、マージしないよう勧める
結果の例（社内）
This cleared the baseline accuracy bar at 87.8% and cut cost to 1.9 cents per ticket, less than half the starting cost.
これで基準の正答率を 87.8% で越え、費用は1件 1.9 セントと、出発点の半分未満になった。
- コスト: サポートのベンチマーク44件（探索30・検証14）。Opus 4.8（
high）で正答率 74.4%、1件 4.6 セント → prompt を点検（必須のツール呼び出しの儀式、スクラッチパッド、矛盾する規則を外す）→ Opus 5.5（low）で 87.8%・1.9 セント（同じ44件で約25%減とする what-a-task-costs-on-opus-5-5 とは合わない。OVERVIEW §5） → Sonnet 5（low）で 88.9%・1 セント → 振り分けの規則などで 98.9%。検証の14件では 78.6% → 90.5%、コストは約5分の1 - 性能: claude-api skill の eval で 66% → 74%（欠けていた8機能の節）→ 77%（C# と Java の型表の誤り）→ 止まったので失敗を原因で分けると、内容はあるのに Claude が学習した古い API の形で書いていた → 冒頭に「覚えている形 → 今の形」の表を足して 80% → 直しても伸びないタスクは例か grader の欠陥の兆候（grader がタスクと違うことを求めていた、grader の指示がドキュメントと矛盾していた）を直して約88%
そのまま使える具体例
claude update/claude-api build-eval
/claude-api hillclimb原典で言及されている関連文書
- demystifying-evals-for-ai-agents — 採点された transcript を読む
- getting-the-most-out-of-opus-5-5 — Opus 5.5 の価格（原典のリンク先）