タスク分割
Part IIではハーネス（harness）をどう改善するかを見た。Part IIIでは、その改善が未知の条件でも有効かを問う。ハーネス自体の重みを学習しなくても、修正案を作り、タスクで試し、その結果から次の案を選ぶ過程はデータへ適合する。あるタスクの結果が一度でも次の修正や候補の選択に影響したなら、そのタスクを最終評価には使えない。
最適化用と最終評価用を分ける
タスク集合を少なくとも三つに分ける。
| 分割 | 最適化器（optimizer）が見られるもの | 用途 |
|---|---|---|
| 開発用データ（development data） \(\mathcal{D}_{\mathrm{dev}}\) | タスク、実行軌跡（trajectory）、エラー、スコア | 失敗分析と更新候補の生成 |
| 昇格用検証データ（promotion validation） \(\mathcal{D}_{\mathrm{val}}\) | 制限したスコア、必要なら集約値 | 探索、ハイパーパラメータ、停止判断 |
| 封印テスト（sealed test） \(\mathcal{D}_{\mathrm{test}}\) | 更新候補の確定まで何も見せない | 最終的な汎化評価 |
重要なのはフォルダ名ではなく情報の流れである。最適化器がテストのスコアを読める、テストを再実行できる、テストの失敗を次のプロンプトへ入れるなら、その集合は昇格用検証データになっている。
ハーネスを作る外側ループ（outer loop）全体を学習アルゴリズムとみなし、汎化はそのループがアクセスしなかったテストで測る。
個々の更新候補（candidate）がテストを見ていなくても、最適化器の設計者がテスト結果を見てアルゴリズム、プロンプト、予算を調整したなら、研究の最適化期間（campaign）全体ではテストへ適合している。
何を未使用にしたか
「保留タスク（held-out task）」とだけ書くと、何が未知か分からない。
| 水準 | 未知の要素 | 例 |
|---|---|---|
| インスタンス単位の保留 | 同じベンチマーク内の別インスタンス | MATHの別問題 |
| テンプレート単位の保留 | 同じドメインの別形式・制約 | 未見の指示制約 |
| タスク系統単位の保留 | 別のタスク種別 | Mathで探索し、コードで評価 |
| 対象単位の保留 | 別の対象モデル（target model）またはモデルの版 | GPT系で探索し、Llama系で評価 |
| 環境単位の保留 | 別のツールAPI、実行環境、権限、ウェブサイト | Browser APIやデータベースのスキーマの変更 |
| 時間単位の保留 | 探索後に発生したタスク | 将来の課題、更新後のウェブサイト |
同じベンチマークの無作為分割はインスタンス単位の保留であり、ベンチマーク系統からの漏洩を除かない。モデル横断であっても同じタスクを使うなら対象横断であり、タスク横断ではない。各軸を別々に報告する。
同じタスクを繰り返し使う設定
最適化器が配備対象と同じタスク集合またはベンチマーク分布を反復利用する設定を、本書では観測済みタスクへの適応（transductive optimization）と呼ぶ。これは必ずしも不正ではない。固定された社内ワークフローを、そのワークフローの過去ログで改善する目的なら合理的である。
問題は、観測済みタスクへの適応の結果を未知タスクへの一般化として報告することである。
Harness-R1の同一バッチ報酬やDGMのベンチマーク候補集合探索は、局所改善や探索には有効だが観測済みタスクへの適応である (Shao ほか 2026年; Zhang ほか 2026年)。別に報告される保留・対象横断の結果と分けて読む。
観測済みタスクへの適応の研究では、次を明示する。
- 何件のタスクを何回再利用したか
- スコアだけか、実行軌跡と期待される解答も見たか
- タスク固有の例外処理を許したか
- どの成果物（artifact）を本番環境へ配るか
- 将来のタスクをいつ、誰が評価するか
昇格用検証データを使いすぎる
昇格用検証データは選択に使うため、反復するほど最適化器へ情報を返す。更新候補 \(H_1,\ldots,H_N\)から昇格用検証データ上の最大値を選ぶと、観測ノイズと昇格用検証データ特有のパターンへ適合する。
モデル選択手順自体の過適合は古くから指摘されている (Cawley と Talbot 2010年)。公開順位表に適応的に提出し続ける問題に対しては、制限したフィードバックを返すLadderのような設計が提案されている (Blum と Hardt 2015年)。ハーネス最適化（harness optimization）でも同じ問題が起きる。
更新候補単位の照会数、全件走査数、返した情報量、停止判断への利用、人間が結果を見て変更した回数を記録する。昇格用検証データのスコアを見て探索用プロンプトを変更するなら、人間も最適化器の一部である。
論文の分割を読む
分割名ではなく、更新候補の生成、選択、停止判断、図の作成のどこへデータを使ったかを読む。たとえばProTeGiは最適化ステップごとのテスト曲線を示し、OPROの分析にはテスト正解率が最大の指示を選んだ表がある (Pryzant ほか 2023年; Yang ほか 2024年)。これらは探索機構の分析には使えるが、封印テストによる最終値とは区別する。
推論時の追加計算と比べる
ハーネスの探索は多くの対象エージェント（target agent）の実行を使う。同じ計算量を、一つのハーネスを改善せず推論時サンプリングへ使った場合と比較する必要がある。
予算 \(B\)について、少なくとも三つを比較する。
- 現行版（incumbent）を一回実行
- 現行版を\(B\)内で複数回実行して選択または投票する
- \(B\)をハーネス最適化へ使い、確定したハーネスを一回実行
三番が二番を上回らなければ、改善は永続的な成果物ではなく追加試行の効果かもしれない。
Rethinking the Evaluation of Harness Evolutionは、Terminal-Bench 2.1上でハーネス進化と推論時スケーリング（test-time scaling）を同条件で比較し、同一タスクで大きく見えた改善が互いに素な分割では小さくなると報告する (Wang ほか 2026年)。単一ベンチマークのプレプリントによる初期証拠だが、永続的な成果物と追加試行を分ける必要性を示す。
評価データへの情報漏洩を分ける
漏洩には複数の経路がある。
| 経路 | 何が漏れるか |
|---|---|
| 対象モデルの汚染 | 事前学習で見たベンチマーク問題や解答 |
| 最適化器モデルの汚染 | 既知の解法や公開エージェント実装 |
| フィードバックの漏洩 | 隠された解答、単体テスト、判定モデル（judge）の根拠、反復スコア |
| 研究者の適応 | テストを見た最適化器、プロンプト、シード、予算の選択 |
| 時間的漏洩 | 「将来のタスク」がモデルの学習期限以前に公開済み |
既知のベンチマークでも、封印したインスタンス、制限したフィードバック、時間分割を組み合わせて情報流入を減らせる。これらを一つの「汚染あり／なし」へまとめない。
封印テストを実装する
封印テストは「最適化器のプロンプトに名前を書かない」だけではない。
- テストデータを最適化器と別のストレージ・プロセスへ置く
- 最適化器に読み取り権限を与えない
- 評価器（evaluator）は更新候補の成果物を受け取り、集約結果だけ返す
- 更新候補の確定後に一度だけ実行する
- テスト結果で再探索しない
- 環境のイメージとツールの版を固定・記録する
- 人間の評価者に更新候補の識別情報を隠す
- 再評価が必要な場合は新しいテスト集合を用意する
公開ベンチマークしかない場合、研究開始前にインスタンス分割とハッシュを固定し、テストを別の運用者が管理する。テストのスコアを見た後の変更は次の研究として扱う。
要点
ハーネス最適化器全体を外側ループの学習アルゴリズムとして扱い、開発用データ、昇格用検証データ、封印テストを情報の流れで分ける。同じベンチマークへの反復改善は観測済みタスクへの適応であり、未知タスクへの汎化とは別である。推論時スケーリング、昇格用検証データの過剰利用、対象モデルと最適化器モデルの汚染を明示し、保留の水準を分解して報告する。