論文解説: PILOT in the Loop — 走っている最中に直す「ライブ自己改善」

エージェントの自己改善は、実行が終わってからでは遅い。監督役と作業役を分け、走行中に軌道修正しながらスキルを貯める PILOT を、比喩から仕組み・実測値・限界まで1から解説する。

PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents

事故ってからドライブレコーダーを見ても遅い

この記事で読む論文の原題は "PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents" です（arXiv:2608.26530、2026年8月27日公開、AllSpark Team）。

アブストラクトの主張を日本語でまとめておきます。長い工程のエージェント実行は、いま走っている作業と将来の作業の両方を良くできる経験を生む。ところが既存の自己改善手法はその経験を実行が終わってから処理するので、進行中の作業の軌道を変えることも、そこで得た教訓をその場で適用して検証することもできない。だから自己改善はライブであるべきだ、というのが著者らの主張です。既存アーキテクチャはこれを支えられていない。単一エージェントの自己修正はタスク実行と軌道の診断を同じコンテキストに詰め込むし、サブエージェント委譲は実行を分離できても走行中のサブエージェントを普通は方向転換できない。そこで提案されるのが PILOT——監督役(supervisor)と作業役(worker)を分けたハーネスで、2つの機構を噛み合わせます。(1) live steering: 独立した監督役が実行中の作業役を方向転換したり中断したりできる。(2) live self-evolution: 実行中に判明した手順や失敗パターンを、再利用可能なスキルと記憶へ蒸留する。2つの凍結バックボーンと3つのベンチマークで、6構成中5構成で1位。Terminal-Bench 2.0 では他ハーネスを最大9.8ポイント上回り、自己改善設定では GLM-5.1 で14.6ポイント、Kimi-K2.6 で12.4ポイント向上。平均出力トークンは42.9%／47.4%減り、出力100万トークンあたりの成功評価数は110.3%／134.0%増えた、というのが論文の要約です。

「ハーネス(harness)」という言葉が繰り返し出てきます。ここではモデルの重みの外側にある一切——プロンプト、スキル置き場、記憶ファイル、ツール定義、実行ループ——を指します。論文が言う自己改善とは、モデルパラメータ $\theta$ の更新ではなく、このハーネス $H$ の進化のことです（§2）。重みは最初から最後まで凍結されています。

比喩: 助手席の教官と、事故後の反省会

自動車教習を思い浮かべてください。

やり方A（従来の自己改善）は、生徒に一人で走らせて、帰ってきてからドライブレコーダーを一緒に見る方式です。「あそこで曲がるべきだったね」と学べますが、その走行そのものはもう終わっています。しかも学んだことが本当に役に立つかは、次に走るまで分かりません。これが reflection や judge ベース評価、事後のハーネス更新がやっていることです（§1）。

やり方B（単一エージェントの自己修正）は、生徒に自分で自分を採点させます。ただし生徒の頭の中はクラッチ操作と車間距離でいっぱいです。論文の言い方では、実行の詳細が診断に必要なコンテキストを占領してしまい、うまくいっていない戦略を認識して直すのが難しくなる（§1）。

やり方C（PILOT）は、助手席に教官を座らせます。教官はハンドルを握りません——運転の責任は最後まで生徒にあります。教官がやるのは、外から見て「その道は行き止まりだ」と気づいたときに口を出すことと、「この駐車手順は今後も使える」とメモに残すことだけです。生徒の頭は運転で埋まっていていいし、教官の頭は目的地と直近の出来事だけで埋まっていていい。この役割の分離が PILOT の設計思想です。

なぜ長い作業ほど壊れるのか

長い工程のタスクが難しい理由は、単純な掛け算で見えます。1手あたりの成功確率を $p$、必要な手数を $n$ とすると、途中で誰も直さない場合に最後まで無事に着く確率は次のようになります。

読み下すと「1手ごとの成功率を、手数の回数だけ掛け算したもの」です。$p=0.99$ でも $n=300$ なら約5%まで落ちます。手数が増えるほど、成功率は線形ではなく指数的に削れていく。これが「長い作業ほど、途中で1回でも軌道を直せるかどうかで結果が変わる」ことの理由です。

論文自身も同じ直感を、実測の形で裏づけています。難しいタスクほど「より長く、より壊れやすい実行チェーン」を必要とし、そこではエラーが積み重なるので、監督役が救出できる余地が大きくなる（§4.2）。

監督役と作業役: 何が永続し、何が凍結されるのか

論文の設定を記号で押さえます（§2）。長い工程のタスク $\tau$ は、作業によって状態が変わる環境 $\mathcal{E}$ の中で、1エピソードで試みられます。モデルパラメータ $\theta$ は凍結されたまま。一方、永続ハーネス $H$ はスキルライブラリ $\mathcal{K}$ と記憶 $\mathcal{M}$ を含み、エピソードをまたいで生き残ります。

エピソード中、監督役は作業役を1体以上生成できます。

「$j$ 番目の作業役は、凍結モデル $\theta$ と、割り当てられた目標 $\tau_j$ と、その時点のハーネス $H$ から作られる」という意味です。作業役は並行に走らせても、先行する作業役が片付いてから順に生成しても構いません。各作業役は現在の $H$ を読み込み、隔離されたコンテキストで動き、環境 $\mathcal{E}$ の中で行動と観測の軌跡 $\xi_j$ を残します。

ここが効いています。作業役の探索・行き止まり・冗長なツール出力は、既定では作業役の隔離コンテキストに留まる（§2）。監督役がその軌跡を読むのは、診断が必要なときに関連部分だけ。おかげで監督役のコンテキストは、目的・直近の出来事・繰り返し起きている失敗パターンのために空けておけます。単一エージェントの自己修正が抱えていた「診断用の脳みそが実行ログで埋まる」問題への、構造的な答えです。

そして重要な線引きを論文は明示しています。本論文で自己改善と言うとき、それは永続ハーネス $H$ の進化であって、モデルパラメータ $\theta$ の更新ではない（§2）。

5つの操作でできた双方向チャネル

live steering の実体は、驚くほど小さなインターフェースです。エピソード中、監督役は各アクティブな作業役と双方向のライブチャネルで接続され続けます。作業役セッションごとに、作業役→監督役の3イベントと、監督役→作業役の2アクションだけがあります（§2）。

1. Notification（通知）: 作業役が自分の判断で進捗・中間結果・リスクを報告する。送信後も実行は続く。
2. Question（質問）: 作業役が自分の判断で「次の一手には監督の入力が要る」と決め、返答が来るまで停止する。
3. Result（結果）: 作業役が終了すると、ランタイムが最終結果と作業役インデックス $j$ を自動で監督役へ届ける。
4. Steer（操舵）: 進路を変えるべきだとライブの証拠が示したとき、監督役は $\xi_j$ の関連部分を検査し、その作業役の次のターンに向けたガイダンスを積む。現在のターンは先に終わる。
5. Abort（中断）: その作業役セッションを続ける意味がなくなったとき、監督役がアクティブな作業役 $W_j$ を割り込みで止める。

付録A.2の擬似コードを縮めると、監督ループはこうなります。

repeat
  必要なら W_j ← Spawn(θ, τ_j, H)
  任意のアクティブな W_j からイベント (j, e) を受け取る
  e が質問なら → W_j に返答する
  W_j の方向転換が妥当なら → ξ_j の関連部分を検査 → Steer
  そうでなく続行が無意味なら          → Abort
  ξ_j に再利用可能な知識があれば → H ← Update(H, ξ_j)
  e が結果・エラー・中断なら → W_j を settled とマークする
until タスクが解決するか、これ以上作業役が要らなくなる

Steer が「次のターンに積まれる」（現在のターンを中断しない）点は、実装上の地味だが重要な性質です。即座に止めたいなら Steer ではなく Abort を使う、という使い分けになります。

実装は Pi コーディングエージェント・ランタイムの拡張として作られており、監督役はエージェントセッション、作業役はプロセス内で別セッションとして生成されます。実験では、実運用のシナリオに合わせて同じ凍結モデルが監督役と作業役の両方を務めます（§2）。役割の性能差ではなく、監督役—作業役という編成そのものの効果を切り出すためです（§3.1）。