MILOは、AIエージェントの「ハーネス」を、人が手作業でチューニングする代わりに自動で見つけ出すフレームワークだ。さらに一歩進んで、ハーネスを探す探索戦略そのものも同時に進化させるという点が、この論文の核心である。Terminal-Bench 2.1、PaperBench、DeepSWEという3つの長期ホライズン(long-horizon)型ベンチマークにおいて、MILOが発見したハーネスは、よく作り込まれた既存のハーネス8種と探索手法6種をすべて上回った。
近ごろのAIエージェントは、2つの部分に分けて考えられる。1つはモデル(LLM)そのものであり、もう1つはそのモデルを包み込むハーネス(harness)だ。ハーネスとは、モデルが提案した行動を実際の環境で実行し、プロンプト・ツール・コンテキスト・メモリといった足場(scaffolding)や制御フローを管理するソフトウェア層のことである。サブエージェントを立ち上げるか、ツール呼び出しに割り込むか、結果を検証するか、いつ作業を止めるか——それを決めているのが、まさにハーネスだ。
興味深いのは、同じモデルでもハーネスが変わると成績が大きく変わるという点である。論文が引用する例(Merrill et al., 2026)を見ると、Terminal-BenchでGPT-5はTerminus 2ハーネスでは35.2%しか解けないが、Codexハーネスでは49.6%を解き、しかもトークンは35%少なく済む。モデルを変えたわけではなく、枠組みだけを変えただけでこれほどの差が出る。
ここで問題が生じる。良いハーネスを作る作業は、いまだに職人の手仕事に近い。Claude CodeやCodexのような商用ハーネスは、チームが数か月をかけて作り上げる。エンジニアが失敗事例をじっくり観察し、ヒューリスティックを手直しし、ごく少数の設計を繰り返し磨き込んでいく、という具合だ。しかもハーネスはモデルごとに異なる。あるモデルに合わせたハーネスが別のモデルには合わず、モデルが変わるたびに一から再チューニングしなければならない。この反復労働を自動化しようというのが、自動ハーネス発見(AHD, automated harness discovery)である。
AHDは通常、LLMベースの進化探索(evolutionary search)で解かれる。LLMの変異器(mutator)が新しいハーネスを提案し、採点器がスコアをつけ、その結果が次のラウンドを導く、という反復ループだ。ところが論文は、既存の方式には4つの弱点があると指摘する。
MILO(Meta-evolutionary Island Orchestration)の発想は、ハーネスだけを進化させるのではなく、「ハーネスを探す方法」までを一緒に進化させよう、というものだ。これは、複数の独立した研究チームを運営する組織にたとえると理解しやすい。
まず、島(island)構造だ。各島はそれぞれ異なる初期ハーネス(種)から出発し、隔離されたまま育っていく。島ごとに専属の変異器エージェントが付いているため、その変異器特有の偏りはその島の中だけに閉じ込められる。島どうしは成功したアイデアをやり取りするが、生存をかけて競争はしない。この設計のおかげで、もっとも弱そうに見えた種から、かえって最高のハーネスが生まれることもある。目先の成績が悪いという理由でチームを解散させないので、ゆっくりと花開く方向が生き残るというわけだ。
2つ目は、階層的血統メモリ(hierarchical lineage memory)だ。種から候補へとつながる経路を、却下された候補まで含めてすべてツリーとして記録する。成功した編集は「何が効いたか」を教えてくれ、失敗した編集はその方向を枝刈りして、より大胆な構造的変化のほうへ探索を押し出していく。失敗を負の証拠(negative evidence)として使うという点が巧みだ。数時間分の採点を1回ふいにした代償を、少なくとも「そこへは行くな」という情報として回収するのである。
3つ目として、変異器エージェントはプロンプトを数行だけ直すのではなく、ハーネス全体を書き直す。その際、グローバルな探索履歴と、親ハーネスの失敗トレース(failure trace)、そしてその親の弱点についてのフィードバックを合わせて参照する。
4つ目は、オーケストレーター(orchestrator)エージェントが外側のループで戦略を調整する点だ。ある島が停滞すると、その島を診断して変異器を交代させ、メモリを手直しし、カリキュラム(どの課題で評価するか)を書き換える。血統を接ぎ木したり(grafting)、系統を分けたり(speciation)するのもオーケストレーターの役目だ。言うなれば、各チームは自分のやり方で研究し、研究所長が行き詰まったチームのアプローチそのものを再編する、という構造である。
全体の流れは、内側のループと外側のループで回る。内側では、島の合格候補の中から親を選び、変異器が失敗トレースと血統メモリを根拠にハーネスを丸ごと書き直し、その子を採点する。このとき子は、精度・トークン・遅延時間という3つの軸のパレート境界(Pareto frontier)を前進させたときだけ合格する。ただし、コストが増えてもそれ自体で脱落するわけではない。論文§4.2によれば、精度差が許容誤差(ε)を超える場合は精度の高いほうを選び、精度がほぼ互角(ε以内)のときにだけ、トークン・遅延の少ないほうを選ぶ。コストは、精度が近いときに働く決定基準というわけだ。進捗が止まると、外側ループのオーケストレーターが介入する。
成果は、Opus 4.8(フロンティアモデル)とgpt-oss-120b(オープンウェイトモデル)という2種類のバックボーンで測定された。以下の数値はOpus 4.8基準である。
| ベンチマーク | MILOの初期ハーネス比の向上 | 既存探索法の最高向上 |
|---|---|---|
| Terminal-Bench 2.1 | +12.0% | +4.5% (GEPA) |
| PaperBench | +28.3% | +18.3% (Meta-Harness) |
| DeepSWE | +10.3% | 0% (向上なし) |
3つのベンチマークすべてでMILOが既存の最高探索法を上回り、とりわけDeepSWEでは、既存方式が初期ハーネス比で一歩も前進できなかったのに対し、MILOは10.3%を引き上げた。
絶対的な成績にも意味がある。Terminal-Bench 2.1でMILOは86.1 ± 2.0%を記録し、公式リーダーボード1位(83.8 ± 2.3%)を上回った。しかも初期ハーネスよりトークンを26%少なく使った。精度とコストが同時に良くなった結果であり、パレート多目的基準で候補を絞り込んだ設計が実際に機能したことの証拠と読める。
MILOは、ハーネスのような戦略レベル(strategy-level)の発見だけでなく、単一の問題を深く掘るインスタンスレベル(instance-level)の探索にも使える。論文は、EinsteinArenaの未解決の数学問題において、既知の最良上界(upper bound)をさらに締めた事例を挙げている。エルデシュの最小重なり(Erdős minimum-overlap)は0.3808586から0.3808568へ、1つ目の自己相関不等式は1.50274365から1.50274360へ、3つ目の自己相関不等式は1.45081から1.44889へと下げた。数値だけ見れば微小だが、開いていた問題の記録を実際に更新したという事実そのものがポイントである。
正直に指摘しておくべき点がある。まずコストだ。ハーネスを1つ採点するのに数時間かかるという前提の上に、複数の島とオーケストレーターまで回す構造なので、MILOを走らせるのにかかる総計算量は決して小さくない。論文がトークン効率(初期ハーネス比26%削減)を語るのは「発見されたハーネスの運用コスト」であって、「MILOの探索そのもののコスト」とは区別して見る必要がある。
2つ目は、結果の範囲だ。上の数値は、特定のベンチマークと特定のモデル(Opus 4.8、gpt-oss-120b)で得られたものである。ハーネスがそもそもモデルごとに再チューニングを要するものである以上、他のモデルや別の課題分布でも同じ幅の利得が再現されるかどうかは、この要約だけでは断定しにくい。
3つ目として、数学の記録更新は値で見ればごく小さい。手法の一般性を示す事例としては説得力があるが、実用的インパクトの大きさとは別の話である。
4つ目は、再現性と運用上の安定性だ。変異器もオーケストレーターもどちらもエージェント(LLM)である以上、探索がどれほど安定して収束するのか、運の悪い実行ではどうなるのかは、本文の詳細をさらに読まなければ判断できない。
ONTLEは、顧客プロジェクトごとにAI PMを派遣し、依頼の受付からサービス公開までを管理する構造だ。そのPMの働き方、すなわち「どの順序で受付・検討・進行し、どのツールをいつ使い、いつ止めて人に判断を委ねるか」を定めたルールの束が、実質的にハーネスに相当する。
ある場面を最後まで追ってみよう。新しい顧客がやって来て、これまでの顧客とはまったく性格の異なる連携作業を任せたとする。今のやり方なら、担当者が既存のPMフローをそのまま載せて回してみて、途中でPMが見当違いなところで止まったりトークンを使いすぎたりするのを見てから、ようやくプロンプトや分岐ルールを手で直す。この修正は、その顧客・そのモデルに合わせた継ぎ接ぎなので、次の顧客ではまた一からやり直しだ。
MILO式のアプローチをこの場面に当てはめると、3つのことが変わる。まず、PMフローのバリエーションをいくつも隔離された島のように同時に回し、うまくいった1つだけを残すのではなく、ゆっくり根づくバリエーションも生かしておく。次に、失敗したフローを消さずに「この分岐で顧客が3回聞き返した」といった失敗トレースをメモリに残し、次の変異が同じ落とし穴を避けられるようにする。最後に、合格基準を精度1つではなく「解決率・トークン・応答遅延」のパレートに置けば、解決率がほぼ互角のフローどうしでは、より安く速いほうが選ばれる。ただし、解決率が明らかに良くなるフローであればコストが余計にかかっても採用されうるので、高いという理由だけで自動的に脱落するわけではない。ONTLEのモデルルーティングは、すでにチャット・受付・実行・修正の各段階でコストと性能を天秤にかける方向にあるが、ハーネスそのものをこの天秤の上で進化させることが次の一手になりうる。人が顧客ごとに繰り返していたフローのチューニングを、失敗を記憶する探索ループに任せる、という絵図だ。
いいえ。プロンプトはハーネスの一部にすぎない。ハーネスはプロンプトに加えて、ツール・コンテキスト・メモリといった足場や、サブエージェント生成・ツール呼び出しへの割り込み・結果検証・中断判断といった制御フローまでを含む。論文は、プロンプトやスキルだけをいじる既存方式(GEPA、A-Evolveなど)が探索空間の大部分を取りこぼすと指摘し、MILOはハーネス全体を書き直す。
むしろ逆の効果を狙った設計だ。島が生存競争をすると、目先の成績が良い少数へと急速に収束し、多様性が崩れてしまう。各島を隔離して育てつつ成功アイデアだけを交換すれば、各変異器の活用偏重が1つの島に閉じ込められ、探索の多様性が保たれる。論文は、このおかげでもっとも弱い種から最高のハーネスが生まれた事例を報告している。
MILOの探索枠組みが、戦略レベル(ハーネス)だけでなく単一問題の最適化(instance-level)にも適用できることを示す事例だ。EinsteinArenaの未解決問題で既知の最良上界を締めた結果(例:エルデシュの最小重なり0.3808586から0.3808568)は、同じ進化構造が別の領域にも一般化することを示唆している。
原理は移植可能だが、まずコストを見積もる必要がある。ハーネスを1つきちんと採点するには実際の課題セットで回してみなければならず、ここに時間と計算がかかる。論文が言うトークン削減(初期ハーネス比26%)は、発見されたハーネスの運用コストであって、探索そのもののコストではない。小さな課題セットと明確な多目的基準(精度・トークン・遅延)から始めて、探索規模を段階的に広げていくアプローチが現実的だ。