LEASH

弱いAIを走らせ、危なくなったら強いAIに引き継ぐ——論文「LEASH」が示す「必要なときだけ強いモデル」の設計

docker agent

• 28 min read
Share

はじめに：コンピュータ操作エージェントは、なぜ「使い続けられない」のか

コンピュータ操作エージェント（CUA＝Computer-Use Agent）とは、自然言語の指示と画面のスクリーンショットを入力に受け取り、クリック・文字入力・アプリケーションの切り替えといった操作を実際のデスクトップ上で実行するAIを指す。従来のRPA（Robotic Process Automation）が「座標と手順をあらかじめ固定する」自動化であるのに対し、CUAは指示の曖昧さや画面レイアウトの変化にその場で適応できる点が特徴である。

しかし実運用に持ち込むと、最初にぶつかる壁は「精度」ではない。コストと安定性のトレードオフである。1つの業務が数十〜数百ステップに及ぶ長距離タスク（long-horizon task）では、フロンティアモデルを毎ステップ呼び出すと費用が積み上がり、逆に小型のオープンウェイトモデルを単体で走らせると途中で手順を見失う。実PC操作のベンチマークであるOSWorld（Ubuntu環境・262タスク、観測はスクリーンショット、1タスクあたり50アクションの操作予算）で測ると、その落差は数字で表れる。

構成 タスク成功率 1タスクあたりコスト
小型モデル単体（Qwen3.5-35B-A3B） 37.40% —
常時フロンティア（Claude Opus 5） 72.90% $0.5094

（コストは記録されたトークン使用量に参照価格を適用した推定値であり、手元のハードウェア実費ではない）

この「成功率の崖」と「費用の壁」の間を埋めるのが、本記事で扱う論文「LEASH（Latent uncertainty for Escalation And SHadow oversight）」の主題である。結論を先に置くと、Qwen3.5-35B-A3B を既定の実行者に据えた構成で成功率73.66%・1タスク$0.4117を達成し、常時Opus級（72.90%）と肩を並べながら推論コストを19.2%削減した。しかも追加学習は一切不要（training-free）である。

以降では、「なぜ弱いモデルで走らせて途中で交代させる発想が有効なのか」「不確実性をどう測るのか」「交代した後の監視をどうするのか」「どこで破綻するのか」を順に解いていく。

「弱→強エスカレーション」とは何か

弱→強エスカレーション（weak-to-strong escalation）とは、小型でオープンウェイトの「弱いエージェント」を既定の実行者に据え、必要になった瞬間だけフロンティアモデルの「強いエージェント」に制御を渡す推論時のアーキテクチャである。ここで重要なのは、これが学習手法ではないという点である。機械学習の文脈で語られる「弱→強汎化」（weak-to-strong generalization、弱い教師の監督から強い生徒が能力を獲得する研究）は訓練時の監督と能力移転の話だが、こちらは訓練を一切変えずに、実行時の計算資源をどこに配分するかという設計の話である。同じ「弱」と「強」という言葉を使いながら、問いの立て方が根本的に異なる。

この発想の直感はシンプルである。1つの業務を完了するまでに数百ステップを要する長距離タスク（long-horizon task）でも、大半のステップは定型作業である。人間も、慣れた手順を毎回ゼロから考え直したりはしない。同じ判断をモデル選択に持ち込み、「普段は安いモデルに任せ、詰まりかけたときだけ高いモデルを呼ぶ」という形にしたのがこの設計である。背景にあるのは成功率の崖と費用の壁である。実PC操作ベンチマークである OSWorld では、小型モデル単体の成功率は37.40%にとどまる。一方で常時フロンティアモデル（Claude Opus 5）は72.90%に達するが、1タスクあたり$0.5094かかる。

既存の選択肢を並べると、この中間領域がどれだけ空いていたかが見えてくる。

方式 強いモデルを呼ぶ条件 成功率の傾向 1タスクのコスト 弱点
常時フロンティア すべてのステップ 高い（72.90%） 高い（$0.5094） 毎ステップ課金で費用が積み上がり、レイテンシも大きい
常時小型 呼ばない 低い（37.40%） 安い 長距離タスクの途中で崩壊する
モデルルーティング／カスケード タスクを事前に振り分け 中程度 中程度 GUI操作が「途中で詰まる」現象には手が届きにくい
弱→強エスカレーション 詰まりかけた瞬間 中〜高 中程度 「いつ交代するか」の判断設計が必須

ルーティングとカスケードは、安いモデルで処理して不十分なら高いモデルに回すという点で発想を共有するが、判定の単位がタスクや応答であり、実行の途中で停滞しているエージェントを救う仕組みではない。

では「いつ交代するか」の何が難しいのか。第一に、判定を毎ステップ行う以上、判定そのものが安くなければ意味がない。追加のモデル呼び出しや専用の監視モジュールの学習を挟んだ時点で、節約したはずのコストが戻ってくる。第二に、強いモデルの内部状態はAPI経由では見えない。「自信がありますか」と尋ねる自己申告型の確信度は、文脈が長く変化し続けるエージェント設定では当てにならない。第三に、交代すれば万事解決ではない。強いモデルも同じ操作ループに陥ることがあり、譲渡後の失敗は現実に起こる。したがって交代は「終わり」ではなく「始まり」として設計する必要がある。

処理の流れを整理すると次のようになる。弱いエージェントが既定の実行者として動き、不確実性が閾値を超えた時点で制御が移り、移した後も監視の網は外れない。

flowchart TD
    A[タスク指示を受け取る] --> B[弱いエージェントが既定の実行者として操作]
    B --> C{不確実性が閾値を超えたか}
    C -- いいえ --> B
    C -- はい --> D[強いエージェントへ制御を引き継ぐ]
    D --> E[強いエージェントが残りの操作を実行]
    E --> F[弱いエージェントを実行者から観察者へ切替]
    F --> G{シャドウ監視が停滞を検知したか}
    G -- いいえ --> E
    G -- はい --> H[保留中の操作を破棄し、方針を再検討させて選び直す]
    H --> E

運用の観点では、「いつ交代するか」に加えて「どれくらいの割合で交代するか」も設計変数になる。強いモデルの呼び出し回数がコストの大半を占めるため、クラウド予算やAPI上限から先に交代率を決め、その制約の中で最も失敗しそうなタスクやステップに強いモデルを割り当てる、という組み立てが可能である。LEASH はこの交代率を予算の代理指標として扱い、閾値をスコアの絶対値ではなく順位（分位点）で決めることで、確率の較正を不要にしている。

LEASH の全体像：ひとつの不確実性信号を三つの役割で使う

LEASH を一言で表すなら、「弱いモデルの中に潜む不確実性を、ひとつの共通信号として三つの場面で使い回す」アーキテクチャである。ここでいう潜在不確実性（latent uncertainty）とは、モデルが文章として語る「自信あります」という自己申告ではなく、トークンを生成する直前に内部に現れる隠れ状態（最終層のベクトル）から読み取れる数値のこと。このベクトルが、過去に失敗した事例の分布にどれだけ近いかを距離として測る。同じ1つのスコアが、次の三層すべての判断を駆動する。

flowchart TD
    A["タスク指示文"] --> B["第1層: 初期タスク不確実性<br/>指示文の隠れ状態を評価"]
    B -->|閾値超過| S["強いモデルへ交代<br/>（最初から任せる）"]
    B -->|閾値内| C["弱いモデルが実行開始"]
    C --> D["第2層: ステップ単位の不確実性<br/>各操作後の隠れ状態を評価"]
    D -->|閾値超過| S
    D -->|閾値内| C
    S --> E["第3層: シャドウオブザーバ<br/>弱いモデルを実行者→観察者に転用"]
    E -->|強いモデルの軌跡を外側から評価| F{"閾値超過?"}
    F -->|はい| G["保留中の操作を破棄し<br/>自問チェックポイントで再決定"]
    F -->|いいえ| H["そのまま継続"]
    G --> S

第1層は「最初から渡すべきか」の判断である。タスク指示文を読んだ時点の隠れ状態を評価し、弱いモデルには荷が重いと見れば、1ステップも実行させずに強いモデルへ制御を移す。指示文の曖昧さや能力不足を先回りする層だと捉えるとよい。

第2層は「途中で詰まりかけていないか」の判断である。弱いモデルが残ったタスクの各操作を実行するたびに、同じ信号を評価し、閾値を最初に超えた操作の直後に制御を渡す。強いモデルには指示文・現在の画面・直近の数ステップが引き継がれる。第1層だけでは実行中に現れる難所を捉えきれず、第2層だけでは明らかに手に負えないタスクに無駄なステップを消費するため、両者は補完関係にある。

第3層がこの設計の独自性である。制御を渡した後の強いモデルは、多くの場合ブラックボックスAPIであり、内部状態は見えない。そこで弱いモデルの役割を「実行者」から「観察者」（シャドウオブザーバ）へ切り替える。強いモデルが実行した操作を弱いモデル自身の操作形式で履歴に追記し、一定間隔で現在の観測を与えて候補操作を生成させ、その過程で得られる隠れ状態に第2層と同じ評価を適用する。白箱の内部状態で黒箱を監視する、という逆向きの情報の流れがここで生まれる。候補操作は実行も開示もされず、監視のためだけに使われる。

三層を支える補助役が Manager エージェントである。フロンティアモデルを充て、タスクを順序付きのサブゴールに分解し、各サブゴールにスクリーンショットから検証できる完了条件を付けて進行を判定する。この分解により、実行の各ステップが「タスク全体の成否」だけでなく「サブゴール単位の成否」という細かいラベルを持てるようになり、第2層・第3層で使うスコアの土台が整う。

最後に「追加学習が不要（training-free）」の意味を明確にしておく。必要になるのは、交代を一切使わずに弱いモデルを走らせた小さな参照タスク群と、その成否ラベルだけである。ここから成功側・失敗側それぞれの平均ベクトルと共有共分散を推定し、距離ベースのスコアを計算する。勾配降下による学習も、専用の監視モジュールの訓練も行わない。統計的な当てはめだけで済むため、参照タスクを増やせば同じ手順のまま信号の精度を上げていける。

仕組み① 潜在不確実性：「失敗に似ているか」を距離で測る

エスカレーションの判定を毎ステップ安く済ませるには、モデルに「自信がありますか」と尋ねる以外の手が要る。そこで着目されるのが、言語モデルがトークンを1つ生成する前の内部表現（隠れ状態）に、その先の成功・失敗の可能性がすでに埋め込まれている、という一連の観察だ。言語化された自己申告の確信度は文脈が長くなるほど崩れやすいのに対し、内部状態のほうが当てになる場面がある。LEASH はこの性質を借りて、「いまの自分の状態が、過去の失敗のときの状態にどれだけ似ているか」を距離として測る。

手順は次の5段階に整理できる。

  1. 評価用とは別の小さな参照タスク群（ホールドアウト）で、交代を一切使わずに弱いモデルを走らせる。
  2. 最終層の隠れ状態を2種類保存する。指示文の末尾トークンの状態 h0（タスクを読んだ直後）と、各ステップで生成した操作トークンの末尾の状態 ht（実際に操作した後）。
  3. それぞれに結果ラベルを付けて「参照バンク」を作る。指示用バンクのラベルはタスク全体の成否、操作用バンクのラベルはサブゴール単位の成否（Manager＝タスクをサブゴールに分解し、スクリーンショットから進行を検証する上位エージェントが付けたもの）を使う。
  4. 各バンクでクラスごとの平均と共有共分散を推定し、マハラノビス距離を「成功側の中心」と「失敗側の中心」の両方について計算する。マハラノビス距離とは、共分散で重みづけした距離であり、ばらつきの大きい方向を割り引いて測る尺度だ。
  5. 不確実性スコアを「失敗までの距離 − 成功までの距離」と定義する。失敗側に近いほど大きくなる相対距離である。

要点は、絶対的な距離ではなく差を取っていることにある。タスクが難しいかどうかではなく、「成功と失敗のどちらに寄っているか」という鋭い信号を取り出せる。

既存の外れ値検出では、クラスに依存しない背景の距離を引く相対マハラノビス距離がよく使われる。ここでは引く相手を「反対の結果」に置き換えており、結果として失敗の対数オッズに近い量が得られる。この性質は、この判定が理論的に正当化される根拠にもなっている。

当てはめの実務的な勘所は3点ある。

論点 内容
使う層 各モデルの最終層。例：Qwen3.5-35B-A3B は40層中39番目
正則化 λ タスク単位の10分割交差検証の AUROC（順位づけの当たり具合を測る指標）で選ぶ
データ分割 タスクをまたいで分割しないと、見かけの AUROC が0.997まで跳ね上がる（同一軌跡内で文脈を共有することによるリーク）

参照バンクを40タスクから99タスクへ増やすと、AUROC は0.701→0.770（Qwen3.5-35B-A3B）へ改善し、標準偏差も約0.10→0.02に縮む。経験を貯めるほど信号が鋭くなる余地がある。

コスト面も見逃せない。実行中のスコア計算は、操作を生成する際にすでに計算済みの活性化を再利用する。追加のフォワードパスも、専用の監視モデルも要らない。

ただし精度は正直に評価しておきたい。不確実性推定の AUROC は初期段階で0.60〜0.75、実行時で0.575〜0.609と「中程度」であり、完璧な故障予測ではない。それでも、閾値をスコアの順位で決める設計にすれば、「どのタスク・どのステップに強いモデルを回すか」という優先順位づけには十分機能する。

flowchart TD
    A["参照タスク群<br/>（交代なしで弱モデルを実行）"] --> B["最終層の隠れ状態を保存<br/>h0＝指示文末尾 / ht＝操作トークン末尾"]
    B --> C["参照バンクを構築<br/>指示用＝タスク成否 / 操作用＝サブゴール成否"]
    C --> D["クラスごとの平均と共有共分散を推定"]
    D --> E["マハラノビス距離を計算<br/>d_pass＝成功中心からの距離<br/>d_fail＝失敗中心からの距離"]
    E --> F["不確実性スコア<br/>u = d_fail − d_pass"]
    F --> G["u が大きいほど失敗側に近い"]

仕組み② いつ引き継ぐか：ゲートの設計と「予算」への合わせ方

不確実性スコアが手に入っても、それだけでは「いつ交代するか」は決まらない。LEASH はこの判断を 2つのゲート に落とし込む。

  • 初期ゲート：指示文を読んだ直後のスコア u_q が閾値を超えたら、そのタスクは最初から強いモデルに渡す。指示の曖昧さや能力不足を、実行を始める前に先回りして検知する。
  • 実行時ゲート：初期ゲートを通過したタスクについて、各操作のスコア u_a を監視し、閾値を超えた最初の操作の直後に制御を移す。強いモデルには指示文・現在の画面・直近の数ステップが引き継がれる。
flowchart LR
    A[弱いモデルが実行] --> B{初期ゲート<br/>u_q > 閾値?}
    B -- はい --> C[最初から強いモデルへ]
    B -- いいえ --> D[弱いモデルが継続]
    D --> E{実行時ゲート<br/>u_a > 閾値?}
    E -- はい --> F[その操作の直後に交代]
    E -- いいえ --> D

ここで重要なのは、閾値を「スコアの絶対値」ではなく 参照タスク上のスコアの分位点（順位） で決めている点だ。目標は「失敗確率」ではなく「エスカレーション率」、つまり 強いモデルを使う割合 そのもの。初期で25%、全体で50%を目標とし、実行時ゲートは初期ゲートを通過した残りのうち1/3（p_a = (p_esc − p_q)/(1 − p_q)）を担当する。順位だけで切るため、スコアの確率較正は一切不要になる。

この設計の実務的な意味は大きい。クラウド予算やAPI上限に応じて「強いモデルを使う割合」を先に決め、その制約の下で 最も失敗しそうなタスク・ステップだけを選んで渡す という運用ができる。閾値はホールドアウトの外側スコア（out-of-fold）から決め、評価データは当てはめにも較正にも使わない。

実行時ゲートにはもう一つの工夫がある。閾値は「各タスクの最大スコア」の分位点で決める。1ステップでも超えれば交代する仕様なので、ステップ単位の分位点で切ると意図より多く交代してしまうためだ。

ゲート 使うスコア 判定タイミング 目標交代率
初期ゲート u_q（指示文直後） 実行開始前 25%
実行時ゲート u_a（各操作後） 閾値超過の最初の操作直後 残りの1/3（全体で50%）

交代率を横軸、タスク成功率を縦軸に取ると、LEASH は同じ交代率のランダム振り分けより一貫して約9〜12ポイント高い成功率を示す。単に強いモデルを多く呼んだからではなく、呼ぶ先を選べている ことが効いている証拠だ。

仕組み③ 引き継いだ後も「綱」を離さない：シャドウ監視と介入

制御を強いモデルに渡した時点で問題が終わるわけではない。フロンティアモデルはAPI越しに呼ぶことが多く、内部状態は見えない黒箱（ブラックボックス）である。加えて長距離タスクでは、言語化された確信度——「自信がありますか」と尋ねて得られる自己申告——は文脈が長くなるほど当てにならなくなる。実際、強いモデルもまた操作のループに陥ったり、途中で目的を見失ったりする。ここで解くべきは「弱いモデルをいつ強いモデルに交代させるか」だけでなく、「交代した後、誰が強いモデルを見張るのか」という第二の問いである。

発想の転換は、弱いモデルの役割を「実行者」から「観察者」へ切り替えることにある。これをシャドウオブザーバ（shadow observer、影の監視者）と呼ぶ。具体的には、交代後に強いモデルが実行した各操作を、弱いモデル自身の操作フォーマットで履歴に追記していく。そして交代直後の1回と、その後3ステップごとに現在の観測を与え、弱いモデルに「次に何をするか」という候補操作を生成させる。この候補は実行も開示もされない。重要なのは生成された操作そのものではなく、その生成過程で得られる隠れ状態（内部表現）である。

得られた隠れ状態には、成功・失敗それぞれの参照クラスタとの距離で不確実性を測るスコアをそのまま適用する。根拠になっているのは「弱いモデルが迷っているなら、その状況は強いモデルにとっても難しいはずだ」という仮定だ。つまり、白箱である弱いモデルの内部状態を、黒箱である強いモデルの代理の観測面として使う。外からは覗けない相手の詰まりを、逆向きの情報の流れで推定する設計である。

sequenceDiagram
    participant S as 強いモデル（黒箱）
    participant W as 弱いモデル（シャドウ観察者）
    participant G as 不確実性ゲート
    S->>W: 実行した操作を自モデルの形式で履歴に追記
    loop 3ステップごと
        W->>W: 候補操作を生成（実行・開示はしない）
        W->>G: 隠れ状態から不確実性スコアを算出
        alt 閾値以下
            G->>S: 介入せず継続
        else 閾値超え（1タスク最大6回）
            G->>S: 保留中の操作を破棄しチェックポイント文を挿入
            S->>S: 推論努力を上げて操作を選び直す
        end
    end

介入の中身は穏当である。スコアが閾値（参照スコアの90パーセンタイル）を超えたら、強いモデルの保留中の操作を破棄し、ニュートラルなチェックポイント文を差し込む。この文は「現在のタスク状態と直近の行動が実際に変えたものは何か」「今の方針で完了できるか、それとも行き詰まっているか」「続行するか、何を変えるか」の3問を短く自問させたうえで次の行動を選ばせる形式で、停滞を断定せず現行方針の継続も明示的に許している。そのうえで、より高い推論努力で操作を選び直させる。弱いモデルが生成した候補操作はこのプロンプトに混ぜない。混ぜれば、監視のつもりが誘導になってしまうからだ。

暴走を防ぐ上限も設けている。介入は1タスクあたり最大6回、かつ2回の介入で操作が実際に変わった時点で以後の介入を打ち切る。3ステップ間隔でしか発火しないため、連続するチェックポイントは最低3ステップ離れる。

効果はアブレーション（構成要素を一つずつ足して測る比較）で確認できる。Qwen3.5-35B-A3B での結果は次のとおりだ。

構成 成功率 コスト（$/タスク）
弱エージェント単体 37.40% –
＋Manager 41.15% 0.1372
＋Manager＋エスカレーション 67.94% 0.4050
＋シャドウ監視（LEASH） 73.66% 0.4117

最大の伸びは不確実性に導かれたエスカレーション（41.15%→67.94%）が生むが、シャドウ監視とチェックポイント介入がさらに5.7ポイントを上乗せし、追加コストは$0.4050→$0.4117とごくわずかで済む。シャドウが発火した31タスクはもともと難しい領域で、常時 Opus 5 でも51.6%しか解けない。その部分集合での成功率は48.4%から64.5%へ改善しており、監視が「簡単なタスクを拾っている」わけではないことがわかる。

実験結果：OSWorld での成功率とコスト

評価は OSWorld で行われた。OSWorld は Ubuntu の実環境で GUI を操作するベンチマークで、262 タスク、観測はスクリーンショット、1 タスクあたり 50 アクションの操作予算という条件が共通で課される。既定の実行者（弱い側）には EvoCUA-8B、Qwen3.5-35B-A3B、Nemotron-3-Nano-Omni（30B-A3B）、Qwen3.8-27B の 4 種類、引き継ぎ先の強い側と、タスクをサブゴールに分解して進捗を検証する Manager には Claude Opus 5 が使われた。コストは記録されたトークン使用量に固定の参照単価を掛けた推定値であり、手元の GPU で動かした場合の実測ハードウェア費ではない点は先に断っておく。比較用の「ランダム交代」は、LEASH と同じ交代率になるよう無作為にタスクを選んで最初から強いモデルに渡す方式で、公平な基準線として置かれている。

既定の実行者（弱モデル） 単体成功率 ランダム交代 LEASH LEASH の交代率 LEASH のコスト($/タスク)
EvoCUA-8B 42.37% 59.98% 67.18% 45.4% 0.3627
Qwen3.5-35B-A3B 37.40% 61.72% 73.66% 64.1% 0.4117
Nemotron-3（30B-A3B） 45.04% 55.41% 66.03% 43.1% 0.3500
Qwen3.8-27B 51.91% 63.30% 69.85% 51.1% 0.3622
参照：常時 Claude Opus 5 72.90% — — 100% 0.5094
参照：常時 Claude Sonnet 4.5 59.16% — — 100% 0.4038

4 つの弱モデルすべてで成功率が大きく伸びている。とくに Qwen3.5-35B-A3B は単体の 37.40% から 73.66% へ上がり、毎ステップ Opus 5 を呼び続けた 72.90% をわずかに上回りつつ、コストは $0.4117 対 $0.5094 で 19.2% 安い。弱モデル単体と常時 Opus 5 の間にある差のうち、LEASH は 75〜102% を回収している（ランダム交代は 37〜69%）。コストは常時 Opus 5 の 69〜81% に収まる。ただし Nemotron-3 のように単体が $0.0132 と極端に安いモデルでは、$0.3500 への増加は相対的には大きな出費になる。成功率 45.04%→66.03% という伸びと天秤にかけて読むべき数字だ。

同じ交代率でランダムに割り当てた場合との差は 6.55〜11.94 ポイントに達する。単に強いモデルを多く呼べばよくなったのではなく、呼ぶ先を選べていることが効いている。既存のエスカレーション手法との比較（EvoCUA-8B、強い実行者はいずれも Opus 5）でも、専用の監視モジュールを学習せずにこの水準へ届いている。

手法 交代率 成功率 コスト($/タスク)
StepWise 49.6% 58.40% 0.2824
Progress Advantage 46.9% 62.98% 0.3533
LEASH 45.4% 67.18% 0.3627

見落とされがちだが重要なのが「いつ渡すか」の効果である。交代が頻発するタスク群だけを取り出し、交代のタイミングをシャッフルすると成功率 60.4%・$0.79、LEASH では 64.6%・$0.67 だった。同じタスクを同じ強いモデルに渡しても、渡す時点を選ぶだけで +4.2 ポイント、コストは約 15% 下がる。誰に任せるかと、どの時点で任せるかは別の設計変数だということが数字で示されている。

xychart-beta
    title "OSWorld 成功率（Qwen3.5-35B-A3B を既定の実行者にした場合）"
    x-axis ["弱単体", "ランダム交代", "LEASH", "常時Opus 5"]
    y-axis "成功率(%)" 0 --> 100
    bar [37.40, 61.72, 73.66, 72.90]

事例も方向性を裏づける。スライド整形のタスクでは、反応しないマクロ UI を操作し続けた弱モデルから 11 ステップ目で交代し、強いモデルはターミナル経由の python-pptx へ戦略を切り替えて完了した。写真を開いて確認して閉じるループに陥ったタスクは 8 ステップ目で交代し、キーボードによる複数選択に置き換わった。拡張機能のインストールは 23 ステップを検索と閲覧に費やした末、24 ステップ目で交代してターミナル経由の導入に成功している。いずれも共通するのは、強いモデルが同じ作業を高速に続けるのではなく、作業のやり方そのものを変えている点である。

なぜ効くのか：理論的な裏付け

ここまで「失敗までの距離 − 成功までの距離」というスコアが、経験的にうまく交代先を選べることを見てきた。では、なぜこの単純な距離差が「誰に任せるか」の判断材料として正当化できるのか。LEASH はこの問いに、古典的な統計手法である線形判別分析（LDA）を使って答えている。

LDA は「2つの集団を最もよく分ける方向」を見つける手法で、1936年にフィッシャーが定式化した。両クラスが共分散の等しいガウス分布に従うと仮定すると、この判別方向への射影は「失敗する確率の対数オッズ」と一致する。つまり「成功と失敗を分ける軸」に沿ってどちら側にいるかを測ることは、そのまま「失敗しやすさ」を測ることになる。

論文の補題は、この関係を提案スコアにそのまま当てはめる。共有共分散のガウスモデルのもとでは、スコア u(z) は次のように展開できる。

u(z) = 2 (μ_Fail − μ_Pass)^T Σ⁻¹ z + 定数

これは「失敗側の中心と成功側の中心を結ぶ方向」への変位にほかならず、フィッシャーの LDA 恒等式そのものだ。したがってスコアは、定数差を除いて「弱いモデルが失敗する確率の対数オッズ」の2倍に等しい。スコアが高い＝失敗しやすい、という直感が理論的に裏付けられる。

さらに命題として、初期ゲートの最適性が示される。同一の交代率という条件下では、このゲートは「弱いモデルが失敗するタスク」を最も多く拾い上げる。これはネイマン–ピアソン型の閾値交換の議論で、ランダム割り当てが失敗タスクのちょうど p 割しか渡せないのに対し、スコア順に切るゲートは厳密にそれ以上を渡せる。加えて「交代による利益がスコアに対して単調」という条件が成り立てば、タスク成功率そのものも最大化される。

理論的結果 内容 意味
補題（距離スコア＝対数オッズ） 共有共分散ガウス下で u(z) は失敗の対数オッズの2倍（定数差を除く） スコアが高い＝失敗しやすい、が保証される
命題（初期ゲートの最適性） 同一交代率で失敗タスクの捕捉率を最大化 予算内で最も見返りのあるタスクを選べる
留保（実行時ゲート） 最適停止問題として未解決 途中交代の理論的最適性は未証明

ただし、この最適性は万能ではない。前提となる「利益の単調性」は、弱いモデルと強いモデルが同じタスクで同時に苦戦する状況では崩れうる。両者に共通の難所では、交代しても利益が出ないからだ。したがって LEASH の理論は「予算内での合理的な優先順位付け」を保証するものであって、あらゆる状況での最適解を主張するものではない。実行時ゲートの理論解析も最適停止問題として未解決であり、論文はこの点を正直に留保として記している。

flowchart LR
    A["隠れ状態 z"] --> B["LDA 判別方向への射影"]
    B --> C["スコア u(z) = 失敗までの距離 − 成功までの距離"]
    C --> D["失敗の対数オッズの2倍（補題）"]
    D --> E["スコア順に切る初期ゲート"]
    E --> F["同一交代率で失敗タスクを最大捕捉（命題）"]

実運用への示唆：自前GPU／自宅サーバーでどこまで使えるか

この設計の実務的な魅力は、「弱い側」を手元で動かせるモデルに置ける点にある。既定の実行者が自分のマシン上で完結していれば、ステップごとの課金は発生せず、内部状態（最終層の隠れ状態）も読み放題になる。例として論文が使う Qwen3.5-35B-A3B は、総パラメータ35B・活性パラメータ3Bの MoE（Mixture-of-Experts：複数の専門家ネットワークのうち毎トークンで一部だけを使う方式）、Apache-2.0、262Kコンテキストという構成で、ライセンス面でもローカル運用に向く。

ただし16GB VRAM での実測は報告が分かれている。4ビット量子化と KV キャッシュ量子化を組み合わせて実用速度に届いたという報告がある一方、23GB 級の量子化重みを16GBに載せると GPU 搭載率が6割程度に落ち、PCIe とメモリ帯域がボトルネックになって毎秒1.5トークン程度に留まるという報告もある。MoE は「活性3B＝計算量が3B相当」であって「メモリ使用量が3B相当」ではないため、速度が欲しい場面では重み全体をどこに置くかが支配的になる。

コストを下げる発想は、大きく3つの路線に整理できる。

路線 発想 代表例 報告されている値
割り当てを変える どこで強いモデルを使うかを選ぶ 弱→強エスカレーション、モデルルーティング、カスケード OSWorld で 37.40%→73.66%、$0.4117/タスク（常時 Opus 5 比で19.2%減）
実行そのものを安くする 1トークンあたりの単価と速度を下げる 量子化、MoE、SSDオフロード、推論専用ハードウェア 35B MoE を SSD からストリーミングし、Mac mini M4 Pro で約20.4トークン/秒
実行を繰り返さない 一度成功した手順を再利用する 成功手順のコード化・記憶 300タスクで小型モデル＋記憶が93.3%・$0.016/タスク（フロンティア単体は93%・$1.57）

3路線はどれも「精度を上げる」よりも「毎回同じように成功して安い」を狙っている点で共通する。業務自動化の現場では、k回のうち1回でも成功すればよい pass@k よりも、k回連続で成功する pass^k の方が価値を持つ。稀に成功する高性能モデルより、地味でも安定して繰り返せる構成の方が運用に乗る、という判断である。

自環境で試すなら、次の4点を順に確認したい。第一に、弱いモデルの最終層の隠れ状態を取得できるか（＝オープンウェイトか）。第二に、評価用とは別の参照タスク群をどれだけ確保できるか。40件でも仕組みは動くが、99件まで増やすと不確実性推定の精度と安定性が改善する。第三に、目標とする交代率（＝予算）を先に決め、その下で閾値を較正できるか。第四に、交代後も監視するかどうかで、両モデルがともに苦手な難所をどこまで拾えるかが変わる。

現実的な第一歩は、小さめのモデルで参照タスクの収集と閾値較正の流れを一通り検証することだ。35B級 MoE を16GB VRAMで回すのはメモリ帯域に当たりやすく、いきなりそこから始めるのは過剰である。仕組みの妥当性は8B級でも確認でき、伸び幅はむしろ小さいモデルほど大きく出る。

限界と注意点

LEASH の数字は魅力的だが、導入前に押さえておくべき留保がいくつかある。ここでは論文が自ら明記している限界と、読者が誤読しやすい点を整理する。

評価範囲は OSWorld のコンピュータ操作に限られる。 本論文の検証はすべて OSWorld（Ubuntu 実環境での GUI 操作）という単一ベンチマーク上で行われており、コーディングや検索、対話など他領域への一般性は未検証である。さらに OSWorld にも世代があり、本論文は 1.0（分単位のタスク）を対象としている。後続の OSWorld 2.x では人間の熟練者でも 1 時間超かかる長距離タスクが評価され、1 タスクあたりのコストは $14〜26 に跳ね上がる。$0.41/タスクという数字は、あくまで「短時間タスク」の相場として読む必要がある。

スコアが測っているのは「失敗リスク」であって「交代の利益」ではない。 潜在不確実性スコアは「弱いモデルが失敗しそうか」を推定するもので、交代した結果どれだけ得をするか（期待利益）そのものではない。理論的な最適性は「交代による利益がスコアに対して単調に増える」という条件に依存しており、弱いモデルと強いモデルが同じタスクで同時に苦戦するような場面ではこの条件が崩れ、判断を誤りうる。万能の最適解ではなく、予算内での合理的な優先順位付けと位置づけるのが正確だ。

シャドウ監視は分布シフトの影響を受ける。 譲渡後の監視は、弱いモデル自身の軌跡から作った参照バンクを、分布の異なる強いモデルの軌道に適用する。この分布シフトが監視精度にどう響くかは十分に検証されておらず、介入の因果効果（介入が本当に成功率を上げたのか）も本評価では分離されていない。

不確実性推定の精度は中程度である。 AUROC は初期段階 0.60〜0.75、実行時 0.575〜0.609 と、完璧な故障予測には遠い。また閾値は有限の参照集合から決まる離散的な分位点のため、実際の交代率は目標（全体 50%）からずれ、実測では 43〜64% にばらついた。この点は「予算を厳密に守れる」と誤解しないよう注意したい。

コストは推定値である。 表に示したコストはトークン使用量に固定価格を掛けた推定値であり、自前 GPU の実測コストではない。比較の公平性のため、ランダム交代は同一交代率に揃えてある点も添えておく。

最後に、論文の公開時点で公式の実装リポジトリは確認できていない。再現するには参照タスクの収集から始める必要があり、モデルカード上の OSWorld-Verified スコア（Qwen3.5-35B-A3B で 54.5）も本論文の評価条件とは異なるため、単純比較はできない。

論点 内容
評価範囲 OSWorld 1.0（短時間タスク）に限定、他領域・OSWorld 2.x への一般性は未検証
スコアの意味 弱モデルの失敗リスクであり、交代の期待利益そのものではない
シャドウ監視 分布シフト下で動作、介入の因果効果は未分離
不確実性精度 AUROC 0.58〜0.75（中程度）、実測交代率 43〜64% と目標からずれる
コスト トークン量×固定価格の推定値、自前 GPU の実測ではない
再現性 公式実装リポジトリ未確認、参照タスク収集から始める必要がある

よくある質問

LEASH は「新しいモデルを学習させる」手法なのか？

いいえ。追加学習を行わない training-free な枠組みである。必要なのは、交代を一切使わずに弱いモデルを走らせた小さな参照タスク群と、その成功／失敗ラベルだけ。ここからクラスごとの平均と共有共分散を推定し、マハラノビス距離ベースのスコアを計算する。勾配降下による学習も、専用の監視モジュールの訓練も不要である。

「弱いモデル」はどれくらい小さくても成立するのか？

論文では8Bクラス（EvoCUA-8B）から27B・35Bクラスまで4種類のバックボーンを検証し、いずれも単体性能を大きく上回った。小さいモデルほど単体の成功率は低いものの、改善幅は大きい方向に出ている。重要なのはパラメータ数そのものより、最終層の隠れ状態を読めること（オープンウェイトであること）と、評価用とは別の参照タスクを用意できることである。

不確実性スコアは結局どのくらい当たるのか？

過大評価は禁物である。AUROC（陽性と陰性をどれだけうまく順位付けできるかを示す指標で、0.5はランダムに相当）は、初期段階が0.60〜0.75、実行時が0.575〜0.609で、完璧な失敗予測ではなく中程度の信号である。ただし閾値をスコアの絶対値ではなく順位（分位点）で決め、交代率という予算を先に固定する設計なので、確度が中程度でも「どのタスク・どのステップに強いモデルを回すか」の優先順位付けには十分機能する。

交代した後、強いモデルの暴走はどう防ぐのか？

弱いモデルを実行者から観察者（シャドウオブザーバ）に切り替え、強いモデルが実行した操作を弱いモデル自身の形式で履歴に追記しながら、3ステップごとに現在の観測を与えて隠れ状態を評価する。閾値を超えたら、強いモデルの保留中の操作を破棄し、現状と方針の継続可否を自問させる中立のチェックポイント文を差し込んで、より高い推論努力で選び直させる。介入は1タスク最大6回、かつ2回続けて操作が変わった時点で以後を打ち切る上限付きの設計である。弱いモデルの候補操作はプロンプトに混ぜず、誘導を避けている。

自宅サーバーや手持ちのGPUでそのまま試せるのか？

構造としては可能だが、条件がある。弱い側にオープンウェイトモデルを置き、最終層の隠れ状態を取得できるようにすること。評価用とは別の参照タスク群を用意し、目標とする交代率に合わせて閾値を較正すること。強い側はAPIでもローカルでも構わないが、その分のトークン費用をあらかじめ見積もっておくこと。この3点である。35B級のMoE（Mixture-of-Experts、入力ごとに一部のパラメータだけを活性化する構造）を16GB VRAMで動かすとメモリ帯域がボトルネックになり、速度が伸びないという報告もあるため、まずは小さめのモデルで参照バンクの構築と閾値較正の流れを検証するのが現実的である。

まとめ

コンピュータ操作エージェント（CUA＝自然言語の指示とスクリーンショットを入力に、クリックや入力を実行するAI）の実運用で最も厄介なのは、精度そのものよりも「精度とコストのトレードオフ」である。1つの業務が数十〜数百ステップに及ぶ長距離タスクでは、フロンティアモデルを毎ステップ呼べば費用が積み上がり、小型のオープンウェイトモデルだけに任せると途中で崩れる。この谷間を埋める発想が「弱いモデルを既定の実行者、強いモデルを非常手段」と位置づける推論時の資源配分であり、LEASH（Latent uncertainty for Escalation And SHadow oversight）はその判断材料を、弱いモデル自身の隠れ状態から取り出す。

設計上の貢献は、初期ルーティング・実行時エスカレーション・譲渡後のシャドウ監視という三層を、単一の潜在不確実性信号で駆動した点にある。層ごとに別の監視モジュールを用意せず、勾配降下による追加学習も行わない（training-free）。必要になるのは、交代を使わずに弱いモデルを走らせた小さな参照タスク群と、その成功・失敗ラベルだけである。

指標 弱モデル単体（Qwen3.5-35B-A3B） 常時 Claude Opus 5 LEASH
タスク成功率 37.40% 72.90% 73.66%
1タスクあたり推論コスト — $0.5094 $0.4117

OSWorld（Ubuntu実環境でのGUI操作、262タスク、1タスク50アクション予算）では、検証した4つの弱モデル構成すべてで単体性能を上回り、同一の交代率で比較したランダム割り当てに対しては6.55〜11.94ポイント高かった。Qwen3.5-35B-A3B では成功率73.66%・1タスク$0.4117となり、常時Opus 5の72.90%・$0.5094に対して推論コストを19.2%削減している。ただしコストはトークン使用量に固定価格を掛けた推定値であり、実測のハードウェア費ではない点は前提として押さえておきたい。

次に考えるべきことはシンプルである。自分の業務のうち「毎回同じように成功してほしい定型作業」は何か。それを数十件ぶん記録して参照タスクにし、強いモデルに渡してよい割合（予算）を先に決める。この2つが用意できれば、精度を上げるのではなく「毎回安く成功させる」ための設計として、この仕組みは手元の環境から試し始められる。

参考資料