最適化ループ
たとえば、現行のハーネス(harness)がツール結果を確認せずに回答するとする。修正案を一つ作るだけでは、改善したか分からない。複数の案を実行し、元の版と比べ、採用する案を決めて保存する必要がある。この一連の手続きを最適化ループと呼ぶ。
Part Iでは、この流れの基本形を示した。本章では、現在使っているハーネスを現行版(incumbent)、新しく試すハーネスを更新候補(candidate)、更新候補を作る仕組みを最適化器(optimizer)と呼び、各役割を分解する。広義の自己進化エージェントやワークフロー最適化のサーベイは、変更対象や更新時点による分類体系を提示している (Gao ほか 2026年; Yue ほか 2026年)。本書では、モデル外部のハーネスを将来の実行へ残す場合だけを扱う。
五つの役割を分ける
ハーネス最適化(harness optimization)には少なくとも五つの役割がある。
| 役割 | 入力 | 出力 | 変更権限 |
|---|---|---|---|
| 対象エージェント(target agent) | タスク、ハーネス、実行環境 | 実行軌跡(trajectory)、回答、動作 | ハーネスだけが事前に許可した範囲で変わる |
| 最適化器 | 現行版、実行軌跡、スコア、探索の履歴 | ハーネスの更新候補 | 編集範囲内だけを変更する |
| 評価器(evaluator) | 更新候補の実行結果 | 品質、コスト、安全性などの評価記録 | 最適化器から変更できない |
| 採否規則(acceptance rule) | 現行版と更新候補の評価記録 | 採用、棄却、判定保留 | 実験前に固定する |
| 履歴保存 | 版、差分、根拠、評価記録 | 再利用・差し戻し可能な履歴 | 採用済みハーネスと探索履歴を保存する |
評価器と採否規則は同じではない。評価器は「テストを何件通過したか」「ツール呼び出しが何回か」「権限違反があったか」を測る。採否規則は、それらの記録に対して「品質が上がり、コスト上限を守り、性能退行(regression)がなければ採用する」と判断する。単一のスカラースコアを返す判定器(judge)に測定と採用をまとめると、どの条件で更新したかを追跡できない。
更新ループ
ラウンド\(t\)で、最適化器は現行版\(H_t\)、探索履歴\(S_t\)、実行証拠\(Z_t\)から更新候補集合を作る。
\[ \mathcal{C}_t = O(H_t, S_t, Z_t; B_t), \]
ここで\(B_t\)は更新候補数、対象モデル(target model)呼び出し、トークン、経過時間などを含む探索予算である。各更新候補\(c\in\mathcal{C}_t\)を固定した環境で実行し、評価器が評価記録を返す。
\[ r_{\mathrm{dev}}(c)=E(c;\mathcal{D}_{\mathrm{dev}},\xi), \]
\(\xi\)はモデルサンプリング、環境の揺らぎ、シードによる確率性を表す。一回のスコアだけで更新候補を順位づけると、この揺らぎを探索信号と誤認する。必要な反復回数と集計方法を先に決める。最適化器は開発用データ(development data)で得た\(r_{\mathrm{dev}}(c)\)を暫定順位づけと探索状態の更新に使う。
版の昇格(promotion)には、開発用データとは別の昇格用検証データ(promotion validation)、保持用データ集合、コスト、安全性をまとめた評価記録\(g(c)\)を使う。
\[ H_{t+1}= \begin{cases} c^*_t & V\bigl(g(c^*_t),g(H_t)\bigr)=\mathrm{accept},\\ H_t & \text{otherwise}. \end{cases} \]
更新候補の生成、開発用データ上の選択、昇格用検証データによる昇格、封印テスト(sealed test)での最終報告を分けることが重要である。封印テストは昇格ループへ戻さず、最適化期間(campaign)を閉じた後に一度だけ使う。
最適化器は何を決めるか
同じ編集面(edit surface)でも、次の軸が違えば別の最適化器である。
| 軸 | 主な選択肢 | 問うべきこと |
|---|---|---|
| 探索状態(search state) | 現行版だけ、ビーム、木、母集団、候補集合(archive) | 過去の更新候補をどこまで残すか |
| 提案演算子(proposal operator) | 無作為、テンプレート、大規模言語モデル(large language model, LLM)による編集、変異、学習済み方策 | どの情報から次の変更を作るか |
| 証拠 | スカラースコア、誤答、批評、実行軌跡、実行時診断 | 失敗のどの構造を最適化器へ見せるか |
| 更新候補評価器 | 完全ロールアウト、部分集合、代理モデル(surrogate)、静的検査 | 高価な実行を何に割り当てるか |
| 選択 | 最大値選択、バンディット、パレート、親保持 | 平均値以外の能力をどう保持するか |
| 停止規則(stopping rule) | 予算、収束、検証停滞、リスクゲート | いつ探索を止めるか |
| 昇格 | スコア閾値、多目的契約、人手レビュー | どの版を将来へ配るか |
主要手法をこの軸へ置くと、同じ「LLMによる最適化」でも更新単位が異なることが分かる。
| 手法群 | 主な保存成果物(artifact) | 主なフィードバック | 探索状態 | 候補生成器の重み更新 |
|---|---|---|---|---|
| APE、OPRO、ProTeGi (Zhou ほか 2023年; C. Yang ほか 2024年; Pryzant ほか 2023年) | 指示 | スコア、誤答、批評 | 履歴、ビーム | なし |
| DSPy、MIPRO、GEPA (Khattab ほか 2024年; Opsahl-Ong ほか 2024年; Agrawal ほか 2026年) | 言語モデル(language model, LM)プログラムのテキストパラメータ | エンドツーエンドスコア、実行軌跡 | ベイズ探索、パレート候補集合 | なし |
| GPTSwarm、AFlow (Zhuge ほか 2024年; Jiayi Zhang ほか 2025年) | ワークフローグラフまたはコード | ワークフロースコア | グラフ、木 | なし |
| ADAS、DGM、Meta-Harness (Hu ほか 2025年; Jenny Zhang ほか 2026年; Lee ほか 2026年) | エージェントまたはハーネスのコード | スコア、実行記録(trace)、実装診断 | コード候補集合 | なし |
| ExpeL、SkillOpt (Zhao ほか 2024年; Y. Yang ほか 2026年) | 経験、スキル文書 | 成否の実行軌跡、保留スコア | 洞察集合、編集履歴 | なし |
| AutoHarness、Self-Harness (Lou ほか 2026年; H. Zhang ほか 2026年) | 検証器(verifier)、コード方策、実行時ハーネス | 環境エラー、失敗実行記録(failure trace) | 改良木、版履歴 | なし |
| Harness-R1 (Shao ほか 2026年) | 実行時フック(runtime hook)のパッチ | 対応再実行報酬 | 学習用エピソード | あり |
この表は優劣ではなく、各手法が何を最適化しているかを示す。たとえばAutoHarnessは違反動作を防ぐコードハーネスから、LLMを使わないコード方策まで探索する。後者は強い結果でも、ハーネスがモデルを補助する設定とは別に報告すべきである。SkillOptのスキル文書はメモリ項目より構造化され、プロンプトより持続的な手続き成果物である。これらの境界は次章以降で扱う。
探索中には単一スコアを使えても、採用時は品質、コスト、遅延、安全性を別々に記録する。平均スコアは、あるタスクの改善と別タスクの悪化を相殺するためである。GEPAのパレート候補集合は事例別の強みを探索中に残すが、配備への採用を保証するものではない。
探索予算を定義する
「10反復」の意味は手法間で揃わない。一つの更新候補が1回のLLM呼び出しで済むプロンプト最適化器もあれば、一つのワークフローを評価するために複数エージェントとツールを動かす最適化器もある。少なくとも次を分ける。
- 最適化器モデルのトークンと呼び出し
- 対象エージェントのトークンと呼び出し
- 環境やツールの実行回数
- 更新候補数と事例実行(case-run)数
- 静的検査、コンパイル、隔離環境(sandbox)実行の回数
- 経過時間と並列数
- 採用後の一タスクあたり実行コスト
保存すべき探索記録
成果物保管庫には最良スコアだけでなく、次を保存する。
- 親版と更新候補の差分
- 提案に使った実行軌跡、フィードバック、スコア
- 最適化器、対象モデル、ツール、環境の版
- 更新候補が実行可能だったか、棄却理由は何か
- 開発用データと昇格用検証データへの照会回数
- 昇格用性能退行テスト一式と、最適化期間終了後の封印テストの結果
- 採用先と差し戻し先
DGMは単調に最良更新候補だけを残さず、評価済みコードの分岐候補集合を保持する (Jenny Zhang ほか 2026年)。これは探索上の踏み石を残す設計であるが、候補集合内の更新候補が将来のタスクへ一般化する保証ではない。履歴の保存と、採用の正当性は別に評価する。
要点
ハーネス最適化器は、提案モデルだけでなく、探索状態、実行フィードバック、更新候補評価器、選択、予算、昇格から成る。最適化器、評価器、採否規則、成果物保管庫を分離し、探索中の最良更新候補をそのまま次の版とみなさない。