エージェントはモデル単体で動くわけではない。そのモデルをどうプロンプトし、どんなツールを持たせ、実行をどう監視・修正するか——こうしたモデルの外側の仕掛け全体をハーネス(harness)と呼ぶ。このハーネスを自動で改善していくとき、これまで関心はもっぱら「どう直すか」に向けられてきた。肝心の「何で学ぶか」、つまりどの失敗事例でフィードバックを集めるかは、最初に決めた順番をそのままなぞっていた。ActiveSaddlerはまさにここに手を入れる。ハーネスが変われば学ぶべき事例も変わる——だから練習メニュー(カリキュラム)もハーネスと一緒に変えていこう、というわけだ。同じ最適化器で訓練の順番だけを最初に固定した方式と比べたところ、二つのベンチマークのどちらでもテスト性能が向上した。
優れたハーネスは、同じモデルを使っても、いくつもの段階を踏む長期タスクの安定性を大きく引き上げる。問題は、モデルやタスク、環境が変わればハーネスも古びてしまう点だ。そこで登場したのが自動ハーネス最適化(AHO, Automated Harness Optimization)である。訓練シナリオを実行し、ログから欠陥を診断して、プロンプト・ツールインターフェース・制御ロジックを自動で修正する。
スポーツのコーチにたとえてみよう。コーチはフォームの直し方(=ハーネスの直し方)はどんどん精密に磨き込んでいく一方で、「今日この選手にどんな練習をさせるか」はシーズン初めに組んだスケジュール通りに進めてしまう。選手がすでに克服した弱点に同じドリルを繰り返して時間を浪費したり、練習中に新たに見えてきた弱点はスケジュールにないので手もつけられなかったりする。従来のハーネス最適化はまさにこれだ——「どう直すか」は精緻なのに、「何で学ぶか」は開始前に決めた訓練セット全体や、あらかじめ組んだ順番に縛られている。
実際、固定順序の方式では、訓練中に観測された失敗のかなりの部分が、最終的なハーネスでも直らないまま残る(論文の図3(b))。固定された練習メニューは二つを取りこぼす。第一に、すでに直した失敗にいつまでも張りついたり、まだ直せていない失敗を早々に見切ってしまったりする。第二に、「既知の失敗をもう一度見るか、まだ見ていない事例を新しく回すか」の損得も、最適化が進むにつれて刻々と変わるのに、固定メニューはこのバランスを調整できない。ロールアウト(一回の実行に使う予算)が切り詰められているほど、この無駄は痛く響く。
ハーネスを直せば学ぶ題材も変わる——このシンプルな事実がActiveSaddlerの出発点だ。どう動くのか、一つの失敗を最初から最後まで追いかけてみよう。
発見。 エージェントがタスクを解こうとして失敗すると、実行の記録が溜まっていく(失敗の軌跡=どこでどう詰まったかを残したログ)。たとえば、複数のタスクで「ツールを呼び出す順番をたびたび間違える」という失敗が繰り返されるとしよう。
まとめる。 ActiveSaddlerは、こうして散らばった似た失敗たちを、直せる欠陥一つにまとめる。このまとまりを失敗パターン(failure-pattern arm)と呼ぶ。タスクごとに切り分けると同じ欠陥がバラバラになり、「ツール利用全般」のようにざっくりくくると別々の欠陥が混ざってしまう——その中間あたりの解像度(失敗をどれだけ粗くまとめるか)で欠陥をとらえるのがコツだ。
伸びしろの見積もり。 次は優先順位だ。このパターンをさらに手入れすれば「どれだけ良くなり得るか」(学習の伸びしろ)を手がかりに、改善の余地が大きいパターンから先に攻める。同じ失敗でも、ハーネスが一度変われば見直す価値が変わるので、この見積もりは反復のたびにやり直す。
復習か探索か。 手を入れる余地が残っているなら、そのパターンをもう一度取り上げてさらに攻める(復習)。一度手を入れてほぼ解決したなら、同じパターンに予算を注ぎ足す代わりに、まだ回していない新しい事例を実行して次の弱点を掘り当てる(探索)。残っている失敗が多いときは復習が、少ないときは探索が得になるので、両者の比率も状況に応じて移り変わり続ける。
この四つのステップが一周するたびに、結果がフィードバックされる。各パターンの優先順位が更新され、掘り起こされたパターンの集合そのものも増えたり変わったりする。「カリキュラムがハーネスと一緒に進化する」という言葉の中身は、これだ。この仕組みを数学的には「当たりの確率が時間とともに変わるスロットマシン選び」の問題(専門用語でnon-stationary bandit)としてモデル化する。ただし、スロットマシンのレバーがあらかじめ決まっているのではなく、実行の途中で観測された失敗からその場で作られる、という点だけが普通のスロットマシンと違う。
うまいのは、ハーネスを直すメカニズム自体には一切手を触れない点だ。既存の最適化器(論文はAutoSaddlerの設定を土台にしている)の上に、「何で学ぶか」を選ぶカリキュラム層だけを乗せる形なので、既存の最適化器に差し替えて組み込むモジュールに近い。
ここに潜む難しさを一つ指摘しておきたい。ハーネス最適化では、カリキュラムの「目標」も「進み具合」も、どちらも目に見えない。シナリオ一つが特定の弱点を指し示してくれるわけではなく、弱点は実行してみて初めて現れ、同じシナリオでもハーネス次第で別の失敗を出す。おまけに、診断された弱点には「まだ解けていない」と知らせてくれる損失値のような直接の信号がない。ActiveSaddlerが失敗をパターンにまとめ、その価値を絶えず見積もり直すのは、まさにこの「見えなさ」に対処するためだ。
核心となる比較はシンプルだ。最適化器も同じ、ロールアウト予算も同じ。変えたのはカリキュラム一つだけ。最適化を始める前にシナリオの順番を打ちつけておいた方式と比べると、ActiveSaddlerはテストのPass@1(一回の試行でタスクを通過した割合)を、GAIA2で4.4%p、Terminal-Bench 2.0で7.5%p(%pはパーセントポイント、通過率の絶対差)引き上げた。
小さく見える数字だが、一度で終わらず、ツールを何度も使わなければならない高難度のタスクでは、数%pの通過率の差は決して小さくない。この結果が語っているのは、モデルの重みを一文字も触らずに、同じモデルを「何で学ばせるか」というカリキュラムの選び方だけでも、テスト性能を押し上げられる、という事実だ。
効率の面もある。論文のFigure 1は、累積のロールアウトが増えるにつれて「その時点までで最も良かった」開発セットの精度がどう上がっていくかを曲線で示しているが、同じ予算の中でより速く、より良いハーネスにたどり着く形になっている。
何がこの得を生んでいるのかは、アブレーション実験(ablation=要素を一つずつ外して貢献度を測る実験)で切り分けられる。(1) 最適化の目標をその都度動的に組み立てること、(2) その目標の移り変わる価値を見積もること、(3) 復習と新しい事例の探索とのバランスを取ること——この三つのどれか一つを外しただけでも得が減る。カリキュラム学習をハーネス最適化の独立した「最適化の軸」として立てた、というこの論文のより大きな主張は、ここから出てくる。
まず評価環境だ。実験はオフラインの設定で、学習・検証・評価用のデータを分けた標準的なやり方(train/dev/test)で、二つのベンチマーク(GAIA2・Terminal-Bench 2.0)だけに限られている。別のドメインや、オンライン・テストタイムの設定でも通用するかは、この論文の外の話だ。得の大きさもベンチマークごとに違っており(4.4%pと7.5%p)、どんなタスク分布で得が大きく、どこで小さいのかは、さらに見ていく必要がある。
次に方法そのものだ。ActiveSaddlerは単独で回る最適化器ではなく、その上に乗せるカリキュラム層である。下にハーネス最適化器があって初めて回り(論文はAutoSaddler、付録では別の最適化器GEPAにも適用)、報告された得はあくまで「同じ最適化器で固定順序を使った場合」に対する相対値だ。性能を左右する隠れた変数は、失敗をパターンにまとめる解像度である——粗すぎても細かすぎても損をするので、掘り起こしたパターンの一覧(パターンレジストリ)をうまく整える仕事が、静かな難題として残る。パターン抽出・価値の見積もり直し・探索の判断という付加的な作業には当然コストが伴うが、論文にはコスト分析の節が別に設けられている。
最後に、これはエージェントの制御ロジックを自動で書き換える手法だ。付録が安全性・セキュリティ・プライバシー・ガバナンスといった責任ある配備の項目を別立てで扱っているのも、そのためである。運用に乗せるときは、この軸のチェックを欠かしてはならない。
ONTLEのAI PMが抱えていた「言葉と行動の食い違い」の問題——成果物を送ると約束しておきながら、実際の送信アクションは抜け落ちる、といったズレ——を思い出してほしい。ONTLEはこの問題を、共通アクションサービスとサーバー側の決定論的な実行によって、すでにかなり狭めてきた。このPMも結局は、ハーネス(リクエストを解釈するプロンプト、呼び出すアクションツール、いつ止まって人の判断を待つかという制御ロジック)の上で動いている。
このハーネスを過去のリクエストログで改善するとしよう。よくあるやり方は「過去のリクエストN件を決まった順番で回し直しながら、プロンプトと制御ロジックを手直しする」ことだ。ActiveSaddlerのレンズをかけると、順番はこう変わる。まず、散らばった失敗ログから「約束した送信を抜かす」というズレを一つのパターンにまとめる。このパターンを一度手直ししてほぼ解決したなら、同じところに予算を注ぎ足さず、まだ回していない新しいタイプのリクエストに移って次の弱点を掘る。逆に手を入れる余地が残っていれば、そのパターンに張りつき続ける。
変わる要点は「何から直すかのリストを人があらかじめ打ちつけない」という点にある。ハーネスを一度直すたびに、「次は何で学ぶか」がその結果を見て決め直される。ONTLEのようにPMハーネスを地道に更新し続ける製品にとって、これは「どの失敗ログから見直すか」という運用判断を自動化する方向を指し示す。もちろんタダではない。論文は最適化器と評価用ハーネスがそろったオフラインの研究設定だ。実際に使うには、リクエストの成功・失敗を一貫して採点する基準と、ハーネスを安全に自動修正・ロールバックする仕組みが、まず立っている必要がある。
モデルの重みにまったく手を触れない点が違います。プロンプト・ツールインターフェース・制御ロジックといった、モデルの外側の状態だけを、実行フィードバックで繰り返し修正するのです。論文はこれを「重みを更新しないモデル訓練」にたとえています。
Pass@1は、たった一回の試行で正解しなければカウントされません。何度か試してそのうち一つでも当たればよいPass@kとは違い、本番で一発できちんとやり遂げる信頼度に近い指標です。
どちらも、ツールを何度も使い、実行を修正していく必要のあるマルチステップ・長期タスク型のベンチマークです。ハーネスの値打ちは、一度で終わる問い合わせではなく、まさにこうしたタスクでこそ際立つからです。