最適化器の独立評価
同じ最終スコアへ到達しても、10個の更新候補（candidate）で見つけた方法と1,000個を試した方法は同じではない。出発点のハーネス（harness）、対象モデル（target model）、編集面（edit surface）、見せたデータ、探索の予算が違えば、最終スコアだけから最適化器（optimizer）の良し悪しは判断できない。
ここまでの三章では、各更新候補について未使用のタスク、別のモデル・環境、性能退行（regression）・コスト・安全性を調べた。最後に、評価対象を完成したエージェントから、条件を揃えたときにハーネスをどれだけ確実かつ効率よく改善できるかへ移す。
最終スコアに混ざる要因
最適化期間の最終スコアは、最適化器だけでなく初期ハーネス、対象モデル、環境、開発用データ（development data）・昇格用検証データ（promotion validation）、予算、フィードバック開示方針に依存する。最適化器だけを比較するには、他の要素を固定するか、要因計画で一つずつ変える。
「手法Aのエージェントが手法Bより高得点」だけでは、Aの最適化器が優れているとは言えない。Aが高い初期ハーネスから始めた、テストを多く見た、更新候補を多く試した可能性がある。
固定すべき条件
| 条件 | 固定しない場合の交絡 |
|---|---|
| 対象モデルと復号 | 基礎能力とサンプリングの差 |
| 初期ハーネス | 改善余地と初期品質の差 |
| 編集面 | 変更可能な失敗クラスの差 |
| 環境イメージ | ツール、遅延、状態の差 |
| 開発用データ・昇格用検証データ | フィードバック量とタスク難度の差 |
| 評価器（evaluator） | スコア定義と判定モデル（judge）の偏りの差 |
| 開示方針 | 実行記録（trace）、ラベル、批評の情報量の差 |
| 予算 | 更新候補数、事例実行（case-run）、トークンの差 |
| 採否規則（acceptance rule） | 採用基準と性能退行許容度の差 |
| 無作為性 | 幸運な最適化期間の選択 |
すべてを一つの設定に固定すると外的妥当性が低い。まず統制比較を行い、その後に対象、初期ハーネス、編集面、環境を一つずつ変える。
最終的な改善量以外の指標
最適化器の更新実行軌跡（trajectory）を直接測る。
| 指標 | 定義 | 分かること |
|---|---|---|
| 提案有効率（proposal validity） | 実行可能な更新候補数 / 提案数 | 編集面を扱えるか |
| 改善的中率（improvement hit rate） | 現行版（incumbent）を上回る更新候補率 | 提案の品質 |
| 性能退行率（regression rate） | 旧成功を壊す更新候補率 | 変更の局所性 |
| 標本効率（sample efficiency） | 事例実行あたりの昇格用検証データ上の改善量 | 予算効率 |
| 暫定最良曲線（best-so-far curve） | 予算 \(b\)に対する昇格用検証データ上の最良スコア | 探索の速度 |
| 昇格後悔（promotion regret） | 昇格用検証データ上の最良更新候補との差 | 選択の品質 |
| 帰属精度（attribution accuracy） | 真の失敗箇所・優先順位との一致 | 診断能力 |
| 較正（calibration） | 予測改善量と実差分 | 自己評価の信頼性 |
| 頑健性（robustness） | シード・対象・環境間の分散 | 転用（transfer）の安定性 |
最終スコアが同じでも、片方が10個の提案で到達し、もう片方が1,000個の提案を使ったなら最適化器の効率は異なる。
候補生成と選択を分ける
最適化器には少なくとも二つの能力がある。
- 良い更新候補を集合に含める能力
- その更新候補を限られた評価から選ぶ能力
生成集合の中で昇格用検証データのスコアが最大の更新候補と、最適化器が実際に選んだ更新候補の差を選択後悔（selection regret）とする。この指標は探索中の代理モデル（surrogate）や限られた照会からどれだけ良い更新候補を選べたかを測る。封印テスト（sealed test）では生成集合を再順位づけせず、確定した更新候補と現行版だけを評価する。
更新候補集合に良い成果物（artifact）がなければ提案の問題である。良い成果物があるのに選べなければ代理モデルや昇格用検証データの問題である。
ハーネス更新と利益を分ける
ある最適化器が有効な更新を作る能力と、ある対象エージェント（target agent）が更新済みハーネスから利益を得る能力は同じではない。Harness Updating Is Not Harness Benefitは、複数の基準エージェントに対する更新後の平均改善量を更新能力（updating capability）、複数の進化器（evolver）が作った更新から対象エージェントが得る平均改善量を利益享受能力（benefit capability）として分ける (Lin ほか 2026年)。
進化器×解答器の組み合わせを交差させることで、良い更新器（updater）と良い受益者（beneficiary）を区別できる。独立評価（independent evaluation）ではこの二軸を報告し、一つのエンドツーエンド改善量（end-to-end gain）を最適化器固有の診断能力と解釈しない。
評価器と採否規則
評価器は測定、採否規則は意思決定を担う。一つの大規模言語モデル（large language model, LLM）の判定モデルへ「改善したか」とだけ聞くと、測定、集約、閾値が隠れる。実行可能テスト、タスク別スコア、コスト、無効・安全性事象、人間評価を別々に返し、事前の閾値で採否を決める。
従来の最適化器研究では、開発用データの指標とフィードバックを最適化器が直接使うことが多く、評価器と採否の分離が確立した標準とは言えない。この分離は、評価への過適合と昇格理由の不明確さを避けるための推奨手順である。
判定モデルの独立性
対象モデル、最適化器モデル、評価器モデルを別にしても、判定モデルの偏りは残る。LLMの評価器が自身の生成物を好む自己選好は実証されている (Panickssery ほか 2024年)。プロンプトの文言の小さな差でモデルのスコアが大きく変わることも報告されている (Sclar ほか 2024年)。
LLMの判定モデルを使う場合は、更新候補の識別情報を隠し、解答順を無作為化し、プロンプトとモデルの版を固定する。実行可能な検証器を優先し、人間が検証した部分集合との一致度と複数の判定モデル間の不一致を報告する。
判定モデルの説明を最適化器へ返す場合、その判定モデルは開発用フィードバック生成器である。最終採用評価器とは分ける。
優先順位による直接評価
Towards Direct Evaluation of Harness Optimizers via Priority Rankingは、最適化器にハーネス構成要素の改善優先順位をつけさせる最近のプレプリントである (Ong ほか 2026年)。SHORはプロンプト、ツール、ワークフロー、メモリなどを含む182件の人間が検証したシナリオから成る。
この評価では、完全な多段階最適化を毎回実行せず、どの構成要素を先に変えるべきかという段階単位の判断を測る。論文は順位づけ性能と実際の最適化能力の相関を報告するため、試行錯誤で偶然改善した最適化器と診断能力を区別しようとする。
ただしPriority Rankingは次を直接測らない。
- 具体的な編集の正しさ
- 更新候補の実行可能性
- 最終エージェントスコア
- コストと安全性
- 環境横断の転用
人間の優先順位を正解とするため、複数箇所の相互作用や人間が見落とす改善も扱いにくい。エンドツーエンド評価を置き換えるのではなく、診断指標として使う。
条件を揃えたエンドツーエンド評価
VeROは、最適化目的、環境、ハーネス、フィードバック、予算を版管理し、8つの最適化器構成を5タスク、各3反復で比較するベンチマークハーネスである (Ursekar, Shanker, Chatrath, ほか 2026年)。主実験は対象エージェントをGPT-4.1 miniに固定した120実験で、初期スコア、最良スコア、改善量、実行時間、実行間の分散を報告する。国際機械学習会議（International Conference on Machine Learning, ICML）2026採択研究であり、最適化器を更新過程から直接評価する主要な先行例である。
HarnessOpt-Benchは、開発用データ、昇格用検証データ、隠しテスト、事例通過数、対象モデルのトークン予算を固定し、OfficeQA、BrowseComp-Plus、Terminal-Bench、GAIAで最適化器を比較する新しいプレプリントである (Ursekar, Shanker, Maurya, ほか 2026年)。
重要な設計は次である。
- 対象モデル、環境、検証器を固定
- 開発用データでは事例単位の結果と実行記録を開示
- 昇格用検証データでは集約スコアを返す
- 隠しテストを探索から遮断
- 最終更新候補とシードをテストで反復評価
- 最適化器構成自体も複数の最適化期間で評価
VeROとHarnessOpt-Benchはいずれも交絡を減らすが、用意された最適化問題内での比較である。実運用の権限、秘密情報、長期メモリ移行、環境更新は別に評価する。HarnessOpt-Benchは2026年8月公開の未査読プレプリントであり、標準として確立したとは言えない。
最適化問題を複数用意する
一つのタスクベンチマーク内でハーネスを探索するだけでは、最適化器の汎化を測りにくい。初期ハーネス、対象、環境、タスク、編集面を組にした最適化問題を複数用意し、一部の問題で最適化器を設計し、保留問題で評価する。
- 保留初期ハーネス
- 保留編集面
- 保留対象モデル
- 保留環境
- 保留失敗形態
これにより、一つの最適化済みハーネスの汎化と、最適化器アルゴリズムの汎化を分けられる。
採否判定をベンチマーク側に置く
ベンチマークが最終スコアだけを返し、各手法が独自に更新候補を選ぶと、採否規則も手法の一部になる。二種類のトラックを分ける。
全体評価
提案、探索、選択を含む最適化器全体を評価する。採否規則の自由度もアルゴリズムとして記録する。
固定した採否規則による評価
更新候補集合または一つの更新候補を提出し、ベンチマーク側の固定した昇格契約（promotion contract）で採否を決める。評価器への過適合を減らし、提案能力を比較しやすい。
両トラックが必要である。固定した採否規則だけでは実際の最適化器運用を測れず、エンドツーエンドだけでは更新候補の品質と選択を分解できない。
最小限のベンチマーク仕様
最適化器から独立した評価には次の契約が必要である。
| 要素 | 固定・報告するもの |
|---|---|
| 問題 | 初期ハーネス、対象、環境、編集面・禁止面 |
| フィードバック | 開発用データ・昇格用検証データで返す情報、照会ログ |
| 予算 | 事例実行、トークン、ツール、経過時間 |
| テスト | 最適化器と研究者から封印した実行時点 |
| 基準手法 | 現行版、best-of-\(N\)、推論時スケーリング（test-time scaling） |
| 診断 | 有効性、的中率、性能退行、標本効率 |
| 昇格 | 評価器、採否規則、安全関門 |
| 成果物 | 最適化器の版、更新候補の系譜、差分、シード |
APIモデルや動的ウェブサイトでは、タイムスタンプ、応答キャッシュ、環境スナップショットを保存し、完全再現できない範囲を明記する。
現在分かっていること
プロンプト、ワークフロー、コードの探索には、採択済み一次研究による複数の最適化器系統がある。VeROは直接評価を採択済み研究として具体化し、Priority Ranking、Rethinking Evaluation、HarnessOpt-Bench、Harness Updating Is Not Harness Benefitは診断・汎化・能力分解を広げる2026年の新しいプレプリントである。共通の問題設定は形成され始めたが、まだ独立追試や分野横断的な合意ではない。
したがって、Part IIIの手順は「既存研究が一貫して実施している標準」ではなく、既存手法の評価上の欠落と、最近の直接評価研究を組み合わせた推奨である。
要点
最終エージェントスコアは最適化器、対象、初期ハーネス、編集面、予算、評価器を交絡する。統制したエンドツーエンド評価と段階単位の診断を併用し、更新候補の生成と選択を分解する。評価器は測定、採否規則は採用を担当し、両者を最適化器から固定する。最近の直接評価プレプリントは有用な設計を提示するが、確立済み標準として扱わない。