필사 모드: 評価者のボトルネック — 弱い採点者がシステム全体の上限になります

• ハーネスをいくら直してもスコアが動かない
• 測定できない品質は選択できません
• 評価者のはしご：スモークからパネルまで
• ルーブリック：何を良しとするかを先に書く
• 隔離と牽制：採点に触れられないようにする
• 評価の較正を先に
• 実際に練習する
• 参考資料

ハーネスをいくら直してもスコアが動かない

ツール表面を磨き、失敗の返し方を構造化し、コンテキストをプレイブックに変えたのに、成功率のグラフが平らなままだとします。構成した例ですが、この平らさにはよくある原因がひとつあります。改善がなかったのではなく、いまの評価者にその改善が見えないのです。実行が落ちさえしなければ合格と数える採点器の下では、結果の品質を引き上げるすべての変更がスコアに現れません。

この状況が危険なのは、結論が逆さまに出るからです。本当の状態は「改善を測れていない」なのに、グラフだけ見ると「ハーネスを直しても無駄」と読めてしまいます。

測定できない品質は選択できません

この連載が繰り返し戻ってくる原則です。ハーネス改善は結局、選択のループです。変更を作り、評価し、良いほうを採用する。このループが選び取れる品質は、評価者が区別できる品質だけです。評価者が区別できない軸では、どんなに良い変更も偶然と同じ確率でしか採用されません。だから弱い採点者は単なる物足りない要素ではなく、システム全体の上限なのです。

Lilian Wengのハーネスの記事も、ハーネスエンジニアリングの難問リストの筆頭に弱い評価者を挙げています。速く精密な検証器がない課題が多く、研究的な審美眼や長期的価値のように検証器を作ること自体が難しい品質もある、というものです。ボトルネックがハーネスの外ではなく評価にあるという診断は、この分野を実際に推し進めている人たちの共通の結論に近いものです。

評価者のはしご：スモークからパネルまで

評価者は有るか無いかではなく、強さの問題です。この連載では5段のはしごとして整理します。

• スモーク — 実行が終わったかだけを見ます。何をしたかは見ません。結果の品質、変更範囲、リグレッションが全部死角です。
• ユニットテスト合格率 — 数字がひとつ出ます。その数字はテストファイルが正直なときだけ意味を持ち、テストが触れない品質は死角のままです。
• ルーブリック採点 — 何を良しとするかを先に書き、その基準で採点します。ノイズが大きく減ります。
• ルーブリック＋採点データ隔離 — 採点基準と正解データを、エージェントが読めず書けない場所に置きます。
• ルーブリック＋牽制指標のパネル — 成功率だけを見ず、ツール呼び出し数、修正範囲、削除されたテスト数を一緒に見ます。

上に行くほど高くつきます。要点はいつも最上段を使えということではなく、いま自分がどの段に立っていて、その段の死角が何かを知ることです。スモークの段でハーネスを丁寧に直す作業は、目盛りのない秤で材料を計る料理のようなものです。

ルーブリック：何を良しとするかを先に書く

はしごの真ん中の段が、実務では最も費用対効果が良いところです。Anthropicのマルチエージェントシステムの回顧は、自社の評価でLLM審査者にルーブリックを渡し、0.0から1.0のスコアと合否を出させたと書いています。基準は事実の正確さ、引用の正確さ、完全性、出典の品質、ツール効率でした。そして自動採点が見逃す微妙な失敗は人間のテストが捕まえた、という回顧が続きます。

# コードレビュー要約エージェントのルーブリック（構成した抜粋）
- id: grounded
  weight: 3
  pass: 'すべての指摘にファイルパスと行の根拠が付いている'
- id: scope
  weight: 2
  pass: '要求された変更範囲の外のファイルに言及しない'
- id: actionable
  weight: 2
  pass: 'レビュアーがすぐ実行できる次の一歩がある'

ルーブリックの価値は、採点の自動化より先に、合意の文書化にあります。何が良い結果かをチームが合意できていなければ、どんな採点器を付けてもその不一致がノイズとして現れます。

隔離と牽制：採点に触れられないようにする

4段目からは評価の無欠性が主題になります。採点基準と正解データがエージェントの書き込めるパスの中にあれば、指標を上げるいちばん安い方法は課題をうまくやることではなく、採点を書き換えることになります。5段目の牽制指標は、成功率が上がる間にほかの信号が奇妙になっていないかを見ます。この2つの段は第6回のリワードハッキングの主題に直結するので、詳しくはそちらで扱います。

評価の較正を先に

順序についての結論です。ハーネス改善を自動化したいなら、評価者の較正が先です。評価がノイズならループはノイズに従って動き、自動化はその動きを速くするだけです。指標は上がるのに実使用の品質はそのまま、というシステムは、たいていこの順序を逆にした結果です。

較正の実務はこのブログの別の記事で扱いました。人間のラベルと審査者の判定の一致率を測り、不一致の事例でルーブリックを直す循環です。評価駆動開発でまず較正すべきなのは審査者ですを併せて読むのがおすすめです。

実際に練習する

ハーネスエンジニアリングRPGのティア5が、まさにこの記事のタイトルの「評価者のボトルネック」です。ゲーム内で評価者は課題スコアの上限を決めるルールとして実装されているので、同じハーネスをスモークの下で回したときとルーブリックの下で回したときで、結果がどう分かれるかを直接確認できます。

• 前の記事: ループ設計 — 無限ループと早すぎる諦めの間
• 次の記事: リワードハッキング — 指標は上がるのに課題は失敗します

参考資料

• Harness engineering for self-improvement — Lilian Weng, 2026-07-04 — 弱い評価者をハーネスエンジニアリングの第一の難問に挙げるくだりがこの記事にあります。
• How we built our multi-agent research system — Anthropic, 2025-06-13 — ルーブリックに基づくLLM審査者と0.0-1.0の採点、自動採点の隙間を人間のテストが捕まえたという回顧がこの記事にあります。
• 5段のはしごはこの連載とハーネスRPGが使う整理の仕方で、本文のルーブリック例は構成したものです。冒頭の平らなグラフの話も構成した例です。