ターミナル上で働くAIエージェントには奇妙な癖がある。同じモデル、同じ環境なのに、ある日は課題を解き、ある日は解けない。エージェントは一度の作業で数十個のコマンドを少しずつ変えながら次々に繰り出し、そのコマンド一つひとつが環境を変えてしまうからだ。次の判断は、いつもその変わってしまった環境の上で下される。
ここで本当に厄介なのは、その変化を元に戻しにくいという点だ。スープを煮込んでいて塩を入れすぎたら、鍋ごと捨てるしかない。エージェントが見当違いのパッケージをインストールしたり、誤ったコードを一度でも実行したりすれば、そのコマンドが環境を壊し、以降のすべての進行を妨げてしまう。モデルがより良い一手を知っていたとしても、すでに悪いコマンドが出てしまった後では手遅れだ。
推論時により多くの計算を使う方式（テストタイム計算）でこの問題に手をつけようとする試みは、以前からあった。サンプルをより多く引き、終わった結果を検証して直し、もう一度回す、といった具合だ。その多くは「実行した後」に手直しするアプローチだった。本論文は問いを一歩手前にずらす。実行する前にふるい分けられるなら、成功率が実際に上がる条件は何か。
答えは少し意外だった。候補を多く生成することよりも、その中から良いものを見極める「検証器」の質が成否を分けた。ボトルネックは生成ではなく、選別だったのだ。
本論文が提案する手法の名前はMid-Harnessだ。設計がそのまま名前に込められている。コマンドを生み出すモデル（生成器）と、コマンドを実際に走らせる実行環境（ハーネス）の「間（mid）」に一層を挟む、という意味である。
普通のエージェントは、モデルがコマンドを一つ出すとすぐに実行する。Mid-Harnessはその場で、同じ対話履歴をもとに候補コマンドを複数生成する。それから検証器で一つを選び、選んだものだけをハーネスに渡す。残りの候補は捨てる。次のステップでは、変わった履歴をもとにまた複数生成する。
良いところは、手を入れる箇所がほとんどないことだ。モデルの重みも、サービング構成も、実行環境もそのままにする。モデル呼び出しを包む薄いコード一層に「複数生成して一つ返す」を足す程度である。おかげで候補数、検証方式、検証器の性能を一つずつだけ変えながら、何が効いているのかをきれいに切り分けて見られる。
検証器には一つ落とし穴がある。課題の説明とこれまでの観測履歴、そして候補コマンドは受け取るが、各候補を作るときにモデルが内心で行った推論は受け取れない。つまり「このコマンドがこの環境で何をするか」を、実行してみないまま判断しなければならない。これが検証の本質的な難しさだ。
判断の仕方は三つある。コマンドを二つ例に挙げてみよう。ls -lは今いるフォルダにどんなファイルがあるかを詳しく見せるコマンドで、pwdは今自分がどのフォルダにいるかのパスを表示するコマンドだ。作業が行き詰まったとき、まず状況を把握するか（ls -lで何があるか見る）、場所だけ確認して先へ進むか（pwd）は、その時々でより良い方が変わる。この二つのうち一つを選ぶ三つの方法は、次のとおりだ。
pwdよりls -lの方が良い」のように、差だけに集中する。呼び出し数は最も多い。ここで一つの直観が重要だ。モデルにとっても、複数の選択肢を一度に順位づけしたり各自に絶対点数をつけたりするより、二つだけ並べてどちらが良いかを選ぶ相対評価の方が、はるかに易しく正確な課題なのだ。比較に共通の基準が生まれるからである。その代わり代償を払う。候補が8個なら、リストワイズは1回、ポイントワイズは8回、すべてのペアを比較するペアワイズは28回呼び出さなければならない。
生成器と検証器が同じモデルの場合、これを自己検証と呼ぶ。別のモデルを検証器として付けることもできる。後で見るように、まさにこの選択が結果を大きく分けた。
実験は、ベースとなるエージェントモデルをターミナル課題の上で走らせながら、検証器だけを変えて比較する。性能は二つの指標で見る。課題ごとに3回実行し、Pass@1はその3回の平均成功率（一度でどれだけうまく解くか）、Pass@3は3回のうち一度でも解けた課題の割合（運が良ければどこまで行けるか）だ。
まず検証器だけを非常に強い外部の最新モデル（フロンティアモデル）に替えてみた。結果は一方にはっきり傾いた。検証なしのベースエージェントがPass@1 50.00%だったのに対し、同じ生成器にフロンティア検証器を付けて最も単純なリストワイズで選ぶだけでも、64.63%から68.03%まで上がった。生成器はすでにより良いコマンドを作り出していた、ということだ。詰まっていたのは、それを選ぶ側だった。
ならば候補をもっと多く生成すればいいのでは、と思うかもしれない。違った。生成器と同じモデルで検証する自己検証では、リストワイズの候補数を二倍に増やしてもPass@1は49.32%から51.02%へと、実質的に横ばいだった。弱い検証器では候補をいくら増やしても良いものを選び出せない。候補数を増やすことは、弱い検証を埋め合わせてはくれない。
鍵は「何個生成するか」ではなく「どう選ぶか」にあった。同じ自己検証で比較方式だけをペアワイズに替えると、Pass@1 54.76%、Pass@3 71.43%に達した。検証器のモデルはそのままに、選ぶ方式を「二つずつ突き合わせる」に替えただけで上がったのだ。
もう一段重ねられる。フロンティア検証器の判断を自前のモデルに写し取る蒸留だ。強いモデルが作った11万7千件のペアワイズ応答を、モデル全体を学習し直すのではなく、小さな追加の重みだけを載せる軽量学習（LoRA）で取り込んだ。この重みは検証器にだけオンにし、生成器にはオンにしない。その結果、ペアワイズのPass@1が57.14%、Pass@3が75.51%に上がった。生成器には手をつけず、検証器だけを賢くして成功率を引き上げた形だ。
蒸留が実際に何を運んできたのかは、保存しておいた軌跡を再生するオフライン分析で明らかになる。点数の誤差（MAE）が2.59から1.05に減った。教師モデルと同じ側を選んだ割合も上がり、ペア一つひとつでの一致率は59.01%から74.58%へ、それらの比較を総合した最終選択の一致率は38.52%から57.79%へと上がった。強い検証器の「選ぶ感覚」が、小さな重み一枚に移し込まれたのだ。
良い知らせの後にはコストが付いてくる。ペアワイズは呼び出しが多く、モデルがトークンを吐き出すのにかかる計算が大きくかさむ。緩和策は、推論過程を省いてAとBのどちらが良いかの結論だけを出す「結論のみ」検証だ。ベースモデルではこの方式が、推論版に対して性能を維持または向上させつつ、トークンコストを20.9%、24.1%ずつ下げた。ただし、より小さいモデルとより大きいモデルでは、結論のみ方式は推論版より性能が落ちた。検証に長い推論が必ずしも要るわけではないが、その利点がモデル規模に左右される、という手がかりだ。
この手法は既存の技法を押しのけず、その上に重なる。完成した実行を複数作って選ぶBest-of-N方式のベースラインがPass@1 55.10%だったのに対し、その3本の軌跡をMid-Harnessで生成すると61.22%、蒸留検証器を使うと66.33%まで上がった。環境を回した回数は同じく3回なのに、11.23ポイント多く出たのだ。以前の実行を要約して次を案内する逐次改善と組み合わせたときもPass@1が60.20%となり、Pass@3も併せて上がった。著者らは、ここに逐次改善を一ラウンド足した組み合わせが、Best-of-Nを推定コスト半分以下で上回ったと報告している。
限界も明らかだ。蒸留を経た自己検証も、フロンティア検証器の水準には届かなかった。残る差の正体が興味深い。教師と食い違った判断は「そのコマンドが環境で実際に何をするか」を見極める領域に集中しており、明白な検証失敗の67.4%がここだった。実行してみないままコマンドの効果を予測することが、依然として核心的な難題だということだ。
もう一つ、作業が長くなるほど検証が弱くなる。教師との一致率は、序盤（ターン1-4）の68.13%から終盤（ターン17-32）の54.07%へと下がった。これは論文が観測した事実だ。ここから「だから終盤は人がもっと見るべきだ」という結論へすぐに飛び移るのはやめておこう。それは観測ではなく、運用判断の領域である。
最後に、このすべての選別は、生成器がそもそも多様な候補を出すという前提の上に立つ。生成器が似たり寄ったりのコマンドばかり吐けば、検証器がいくら良くても選ぶものがない。そして課題数が少なければ3回平均の分散が大きくなるので、54.42%と55.44%のような小さなPass@1の差は、慎重に読む必要がある。
具体的な一場面に移してみよう。ある顧客企業が、外部の会計ソフトとの連携を要請した。ONTLEのAI PMは、このプロジェクト専用のデータベースに収集用テーブルを作り、接続に必要な認証情報を保存するコマンドを下さなければならない。モデルが思いついた最初のコマンドがそのまま実行される構造なら、誤ったテーブル設計が一度あるだけで、以降の収集パイプライン全体をこじらせてしまう。ターミナルエージェントの「元に戻せないコマンド」問題が、ここでは「顧客データと連携に触れるアクション」へと翻訳される。
このとき、まずはっきりさせておくべきことがある。本論文が引き上げたのは課題の成功率であって、顧客アクションの安全性ではない。両者は目標が異なる。論文が測ったのは課題の成功率と、教師モデルとの判断一致度までで、顧客データや認証情報、金銭処理の安全性そのものは実験されていない。ただし手段は同じ構造を共有している。「実行する前に候補をふるい分ける関門」だ。成功率を高めたペアワイズ比較と蒸留の技法を、致命的なミスを防ぐ安全フィルターづくりに応用できるかは、論文が検証した範囲の外にある、これから確かめるべき仮説にとどまる。本論文の実務的な使いどころは、安全フィルターを「どう作るか」という設計の手がかりであって、効果の保証ではない。
だからこの場面でやるべきことには順序がある。まず、元に戻せないアクションから選り分ける。テーブル設計の変更、認証情報の書き込み、金額が動く処理のように、失敗のコストが大きいものだ。そのうち最も高くつくテーブル設計の変更にだけ、ペアワイズの関門をかける。実行の直前に候補を二つ突き合わせて「今のこの収集要求により合う設計」を選ばせるのだ。すべてのアクションにではなく、このリストにだけ選択的にオンにして、コストを抑え込む。そのうえで、関門が本当に失敗を減らすかを実際の運用データで測って初めて、効果の有無を語れる。
「選択的だからコストは大丈夫だ」という結論には条件が付く。元に戻せないアクションが全体の中で稀であり、検証器が使えるほど正確なときにだけ成り立つ。自前モデルの自己検証が弱いなら、まずフロンティア検証器を付けて性能の上限から測ってみる。そこで明確な利得が見えたら、その判断を蒸留で自前モデルに内在化する。外部の高性能モデルに常時頼らずとも、検証能力を自分たちのモデルへ移してくる道がまさにこれであり、これはONTLEが使うモデルルーティング標準とも噛み合う。コストが依然として負担なら、推論を省いた結論のみ方式を併せて測るが、モデル規模によって利得が変わったので、実際に使うモデルで直接比較したうえで採用する。
まとめると、ONTLEにとってより差し迫っているのは安全性の方だ。本論文は、その安全の関門を「どう賢く作るか」についての設計の手がかりをくれる。ただし安全性そのものを高める効果は論文が示したものではないので、いますぐ全面導入ではなく、最も高くつくアクション一つに関門をかけて上限を測ってみること — そこから始めればよい。
いいえ。両者が同じなら自己検証、異なれば外部検証器です。論文で最も大きな利得は、強い外部モデルを検証器として付けたときに出ました。蒸留は、その強い検証器の判断を自前モデルへ移し、運用では再び一つのモデルで回しながらも、似た選別力を得ようとする折衷案です。
そうではありません。蒸留に使った11万件あまりの比較データは、フロンティア検証器が自ら作った判断（推論と選好）です。教師モデルがラベラーの役割を代わりに担うので、人の注釈が要らず、その分集めやすくなっています。
そのとおりですが、それでは「実行する前にふるい分ける」という前提が崩れます。実行してみた後で選ぶのは、元に戻せないコマンドではすでに手遅れです。この手法の核心は、実行していない状態で判断することであり、まさにその「実行せずに効果を予測する」ことが、最も難しい部分として残っています。
論文の結果は、ターミナル課題を中心に検証されました。著者らは、この範囲を越えた拡張を今後の課題として挙げています。ただし「元に戻せない行動を実行する前に選び出す」という骨組み自体は、ツールを呼び出す他のエージェントにもそのまま移して考えてみることができます。