BlueLM-GUI 解説——実機数百台を回す「フライホイール」でスマホGUIエージェントを自己改善させる仕組み

はじめに：スマホを自分で操作するAIは、なぜ実用にならないのか

GUIエージェントとは、スマートフォンの画面を画像として認識し、タップ・文字入力・スワイプといった操作を自分で実行して、ユーザーの指示を代わりに遂行するAIのことである。近年、その設計は大きく転換した。Planner（計画）・Executor（実行）・Reflector（反省）・Memory（記憶）を連結する「マルチモジュール型」から、知覚・グラウンディング（画面上の要素と座標の対応づけ）・計画・実行を単一モデルに内包させた「ネイティブ型」へと重心が移っている。

flowchart LR
  subgraph MM["マルチモジュール型"]
    P[Planner] -->|誤差伝播| E[Executor]
    E -->|誤差伝播| R[Reflector]
    R -->|レイテンシ増大| M[Memory]
  end
  subgraph NT["ネイティブ型（単一モデル）"]
    N["1つのモデルが<br/>知覚・グラウンディング・計画・実行を内包"]
  end

結論を先に示す。vivo AI Lab が2026年9月11日に公開した技術レポートでは、総パラメータ35B・活性3B（MoE構成、35B-A3B）のネイティブ型エージェントが、独自ベンチマーク MobileGUI-VBench で87.4、公開ベンチマーク AndroidWorld で84.9を記録した。87.4は、比較対象の中で最も高いクローズドソースモデル（82.3）を5.1ポイント上回る値である。

ただし主役はスコアそのものではない。「なぜ今までのやり方では性能が伸びないのか」を、次の3つの構造的なギャップとして言語化した点にある。

ここでロールアウトとは、モデルの方針（ポリシー）に従って実際にタスクを実行させ、行動と結果の系列を記録する試行のことである。強化学習（RL）における学習信号の源になる。また分布シフトとは、訓練データの統計的な性質と、配備先で観測される性質がずれる現象を指し、ベンチマーク飽和とは固定されたテストの平均点が天井に張り付き、モデル間の差を弁別できなくなる状態を指す。

本記事は、これら3つのギャップを閉じるための、実機数百台を使った「データ生産 → 訓練 → 評価 → 原因特定 → 再生産」のループ設計を、アブレーションの数値とともに解説する。想定読者は、AIエージェントの実装に関わるエンジニア、スマホ×AIの動向を追うプロダクト担当者、強化学習によるエージェント訓練に関心を持つ研究者である。

3つのギャップ：産業実装を止めている正体

スマートフォンを自分で操作するGUIエージェントが研究デモとしては動くのに、実際のサービスに載せると途端に頼りなくなる。この停滞を「モデルの賢さが足りない」とか「アーキテクチャが洗練されていない」という話として捉えると、打ち手を間違える。vivo AI Lab の技術レポート（arXiv:2609.12394）は、原因をモデルの中ではなく学習と評価を取り巻くパイプラインの構造に求め、次の3つのギャップとして整理している。

3つは独立した問題ではなく、連鎖している。分布がずれているから実機で失敗が量産され、その失敗を捨てているから次の改善材料がなく、改善しないからベンチマークも飽和する。したがって対症療法ではなく、3つを同時に閉じるループ設計が要求される。

ギャップ1：サンドボックスと本番の「分布のズレ」

業界の標準的なやり方は、少数の実機と大量のサンドボックス（模擬環境）やモックアプリを併用するものだ。サンドボックスには明確な利点がある。任意のタイミングでリセットでき、内部状態を計装でき、成功判定を自動化できる。データ生産の速度と再現性だけを見れば、実機より優れている。

問題は、本番の障害を支配しているのがロングテール分布だという点にある。リスク管理のチャレンジ、CAPTCHA、アカウントの状態異常、ポップアップ広告、ネットワークのジッタ、スーパーアプリのバージョン分断。これらは頻度は低いが、実際にタスクを失敗させる主因になる。そして模擬環境では原理的に再現しにくい。

flowchart LR
  subgraph SB["サンドボックス環境"]
    A1["リセット可能"]
    A2["計装可能"]
    A3["自動検証可能"]
  end
  subgraph PR["本番実機環境"]
    B1["リスク管理チャレンジ"]
    B2["CAPTCHA"]
    B3["アカウント状態"]
    B4["ポップアップ広告"]
    B5["ネットワークジッタ"]
    B6["アプリのバージョン分断"]
  end
  SB -.->|"訓練分布"| GAP["分布のズレ"]
  PR -.->|"配備分布"| GAP

ここで重要なのは「サンドボックスが劣っている」という評価ではない。訓練分布と配備分布が一致しないまま学習した能力は、配備先で転移しないという設計上の帰結である。模擬環境で100点を取るモデルが実機で崩れるのは、能力の問題ではなく、学習した分布と評価される分布が別物だからだ。

ギャップ2：高コストな「実機の失敗」が捨てられている

実機での軌跡収集は、サンドボックスと比べてあらゆる面で高くつく。タスクごとに端末を初期状態へ戻す必要があり、実行には実時間がかかり、成功判定も脆い。結果として、収集の現場には失敗軌跡と異常軌跡が大量に生まれる。

従来のパイプラインは、ここで粗いフィルタをかける。「きれいに成功した軌跡だけを残し、失敗は捨てる」。教師あり微調整（SFT）のデータ品質を守るという意味では合理的に見えるが、捨てている側にこそ価値がある。失敗の中には、最も希少な訂正信号と探索信号が含まれているからだ。

具体的には、モデルが誤った状態に陥ったあとでどう立て直すか、という監督は成功軌跡には現れない。成功例をいくら並べても「間違えた後の直し方」は学べない。同様に、あるクエリが解けないという事実は「次にどのタスクを訓練すべきか」を直接教えてくれる。失敗と異常を廃棄物ではなく、希少な学習資源として扱うことが2つ目の原則になる。

ギャップ3：ベンチマークが飽和して「次の一手」を指さなくなる

自己改善型のパラダイムでは、モデルが継続的に更新され続ける。ところが固定されたベンチマークは動かない。すると遅かれ早かれ、全モデルが同じように高得点を取る飽和状態に入る。スコアが良い判断と悪い判断を分離できなくなった時点で、その数字は「次に何を直すべきか」を教えてくれなくなる。

ここで必要になるのは「より難しいベンチマークを1つ作る」ことではない。難しいだけのテストは、また飽和すれば同じ袋小路に戻る。求められているのは、モデルと一緒に進化するベンチマークの作り方である。評価軸を多次元のクオータ（割り当て）として記述し、飽和したらそのクオータを意図的にずらして新しい評価を生成すれば、スコアの差分がそのまま「何ができるようになり、何がまだできないか」の説明になる。評価は成績表ではなく、診断装置として設計される必要がある。

3つのギャップを並べると、対策の方向も見えてくる。分布のズレは訓練そのものを配備環境で起こせば縮む（Every Rollout Is Real）。失敗は属性を判定して監督信号へ変換すれば資源になる（Every Sample Matters）。飽和したベンチマークはクオータを動かして更新すれば診断力を保つ（Every Query Evolves）。以下では、この3原則を1つのループに組み上げた実装を順に見ていく。

BlueLM-GUIとは：実機中心のフライホイールという設計思想

BlueLM-GUI は、中国のスマートフォンメーカー vivo の AI Lab が2026年9月11日に公開したモバイルGUIエージェントである（arXiv:2609.12394、49ページ、著者43名、責任著者 Longqiang Luo、監修 Xiaohu Ruan と Xiaoxin Chen）。モデルは総パラメータ35B・活性3B の Mixture-of-Experts（MoE）構成、つまり35B-A3B で、複数の専門家モジュールのうち入力ごとに一部だけを活性化する方式により、総量の割に推論コストを抑える。ベースモデルは Qwen3.5-35B-A3B。性能は独自ベンチマーク MobileGUI-VBench で 87.4、公開ベンチマーク AndroidWorld で 84.9 を記録している。

このシステムを一行でまとめるなら、「データ生産 → 訓練 → 評価 → 帰属（原因の特定）→ 再生産」というループを、数百台の実機の上で回し続けるための仕組みである。設計の中心はモデルのアーキテクチャではなくループそのものだ。

「フライホイール（はずみ車）」という比喩が示すのは、回転が次の回転を生む構造である。実機でのロールアウト（エージェントに実際にタスクを実行させて得られる行動と観測の系列）の結果がデータプールへ戻り、検証済みの成功は次ラウンドの監督信号になり、失敗は「次にどのタスクを突くべきか」という指示に変わる。

flowchart LR
    A["クエリ生成"] --> B["実機ロールアウト"]
    B --> C["評価・ルーティング"]
    C --> D["エラー訂正と派生"]
    D --> A
    D --> E["再訓練"]
    E --> B

3つの設計原則は、産業実装を止めている3つのギャップに1対1で対応する。

訓練環境・データの扱い・評価というループの別区間をそれぞれが担当し、3つが揃って初めてフライホイールは回り続ける。サンドボックスで訓練すれば配備で能力が転移せず、失敗を捨てれば希少な訂正信号を失い、ベンチマークが飽和すれば改善の方向が分からなくなる。

なお MobileGUI-VBench は著者らによる自社ベンチマークであり、他モデルとの比較は同一フレームワークでの著者再評価である点は、数値を読む際の前提として押さえておきたい。

Every Rollout Is Real：訓練そのものを配備環境で行う

分布のズレを解消する最も徹底した方法は、事後的に補正することではなく、訓練そのものを配備環境で起こすことである。強化学習（RL：試行錯誤の結果に報酬を与えて方策を改善する手法。エージェントが実際に行動し、その結果から学ぶ）の探索をすべて生きた対話環境で走らせれば、状態遷移・インターフェースの応答・異常イベントのすべてが本番の分布から供給される。その結果、モデルが獲得する能力は自然に配備先へ適合する。これは模擬環境が原理的に提供できないロバスト性の源だ。各ロールアウト（エージェントに実際にタスクを実行させて得られる行動と観測の系列）の後、軌跡はデータプールへ戻る。検証可能な成功は次ラウンドの監督信号になり、失敗は「次にどのタスクをサンプルすべきか」を教える材料になる。

3段階の訓練レシピ（CPT → SFT → RL）

BlueLM-GUI の訓練は、性格の異なる3段階の直列構成になっている。

継続事前訓練（CPT：Continual Pre-Training） は64 GPUで15Bトークン、うち約70%がGUI軌跡データを使う。視覚エンコーダと投影層は凍結し、言語モデルのみを更新する。学習率は1e-5、ウォームアップ0.05、cosine減衰で1e-6、バッチサイズ128、最大系列長10240、1エポック。この段階の役割は見過ごされやすい。ベースモデルは画面要素の理解は得意だが、「軌跡の中で次の行動を予測する」のは苦手である。欠けているのはインターフェースの知識ではなく、逐次決定の事前分布——いまタスクのどの段階にいるのか、直前の行動が効いたのか、進むべきか戻るべきか——である。CPTはこの事前分布をモデルに埋め込む。

教師あり微調整（SFT：Supervised Fine-Tuning） は32 GPUで5Bトークン。実機で収集し専門家が検証した高信頼プールのみを使う。バッチサイズ160、最大系列長10240、1エポック。

エージェント強化学習（RL） は32 GPUに実機数百台とAndroidエミュレータを組み合わせる。訓練指示セットは1,000クエリ超。各反復で8つの指示をサンプルし、1指示あたり8本の軌跡をロールアウトして、その8本を群としてadvantage（相対的な良し悪し）を計算する。学習率1e-6、バッチ512インタラクション窓、最大20ステップ、視覚文脈窓は直近5フレーム、プロンプト上限12288トークン。

flowchart LR
  A["CPT<br/>逐次決定の事前分布<br/>64 GPU / 15Bトークン"] --> B["SFT<br/>検証済み決定と規則遵守<br/>32 GPU / 5Bトークン"]
  B --> C["RL<br/>想定外の障害からの回復<br/>32 GPU / 実機数百台"]

3段階は「何を学ぶか」がそれぞれ異なる。CPTは逐次決定の事前分布とプロトコルの習得、SFTは検証済みの決定と規則の遵守、RLは想定外の障害からの回復を担う。

実機環境の3層アーキテクチャと安全審査

実機環境は3層で抽象化されている。第1層はモデルが行動を出力する層。第2層はスケジューリングサービスが標準的なRLインターフェース（reset / step / close）を公開し、下層の複雑さを隠す層で、訓練側は多数の端末をまとめて並列ロールアウトできる。第3層は異機種のスマホクラスタ（数百台）で、各端末に常駐するランタイムが行動を実行して新しい画面を返す。

端末には最新のアプリ、生きたネットワーク、サインイン済みのアカウントが入っている。つまり訓練中に、リリース後に出会うはずの本物のポップアップや読み込み遅延にそのまま遭遇する。自由探索は危険を伴うため、すべての行動は安全審査システムを通過し、プライベートデータ・金銭・禁止コンテンツに関わる行動はブロックされる。重要なのは、この安全審査が本番の出荷品そのものだという点だ。訓練時に効いていた保護が、リリース後も同じように残る。端末上に常駐するローカルランタイムが複合行動を具体的な操作に展開し、訓練と配備で行動空間を同一に保つ。

flowchart TB
  M["モデル（行動を出力）"] --> S["スケジューラ<br/>RL API: reset / step / close"]
  S --> C["実機クラスタ（数百台）<br/>常駐ランタイムが画面を返す"]
  C --> G["安全審査システム<br/>（本番出荷品と同一）"]
  G -.->|"ブロック"| M

14の行動と「意図レベル」の操作

行動空間は14種類・4グループで構成される。

4グループを1つの空間に置く意味は、モデルが「モードを選ぶ」のではなく、1回の決定として全選択肢を比較できることにある。とくに重要なのが意図レベルの行動だ。アプリの起動を例に取ると、同じニーズを満たすアプリは複数あり、どれがインストールされているかは端末・地域・ユーザー選好で変わる。原始行動だけであれば候補を順に試すしかない。そこで open は固定のアプリ名ではなくニーズの記述を受け取り、端末側がインストール済みアプリへ解決する。モデルが「次に何をすべきか」を決め、端末が「どうやるか」を解決するという分業である。

報酬設計：progress × quality とステップ単位の判定

RLの報酬は難度の中央帯で設計される。全モデルが解けるタスクも全モデルが失敗するタスクも有用な勾配を生まないためだ。軌跡の採点にはLLM審判を使い、ゴール・出力と行動の全系列・各ステップの画面を入力として、複数回クエリした結果の多数決を取る。

軌跡報酬は次の式で与えられる。

R(τ) = α·(N_done / N_nec) + (1−α)·(N_nec / T), α = 0.5

ここで N_nec は審判が必要と判断したサブゴール数、N_done は到達した数、T は実際のステップ数。前半が「どこまで到達したか」を表す progress 項、後半が「必要だったステップの割合」を表す quality 項である。quality 項があることで、遠回りしてゴールに到達する経路が抑制される。

ただし軌跡単位の報酬だけでは「どのステップが悪かったのか」を教えられない。そこで各行動も採点する。r_t = Judge(g, τ, t) ∈ {+1, 0, −1} で、+1 は必要、0 は無害だが無駄、−1 はタスクからの逸脱を意味する。最適化にはGRPO（群内の軌跡を相対比較して方策を更新する手法）を用い、タスクごとにG本の軌跡をサンプルし、2つの報酬を別々に正規化して単一のadvantageへ合成する。軌跡報酬は「タスク群の中で解全体を比較する」スケール、ステップ報酬は「1本の軌跡の中で個々のステップを比較する」スケールであり、この違いを重みλで平衡させる。あわせてSFTモデルへのKL項を加え、探索がプロトコルと安全境界を壊さないよう制限する。ロールアウトのスケジュールも調整し、有用域を外れた成功率の群はコントラストを持たないため破棄する。

アブレーションが示す「実機オンラインRLの必然性」

同一のSFT開始点から2つのRL設定を比較した結果が、この設計の核心を突いている。

オフラインで伸びない理由は明確だ。オフライン軌跡の状態遷移は固定されており、現行ポリシーがその分布から離れた瞬間、advantage推定は現実の帰結に対応しなくなる。RLは「データセットに既にある行動の再重み付け」へ退化してしまう。実機オンライン環境は行動と帰結のループを閉じる。モデルは自分のミスが次の状態をどう変えるかを見て、注釈済み軌跡には一度も現れない有効な経路を見つけ出す。誤りからの回復と多経路解決はここから生まれる。 状態遷移が環境の応答に強く依存する長期タスクでは、オンライン相互作用はRLの任意の改良ではなく前提条件だ。

判定（報酬）の信頼性がRLの上限を決める

オンラインRLでは更新方向が報酬から完全に決まる。ところがモデルベースの審判自身が確率的で、同じ軌跡がパスごとに違う判定を受けることがある。群相対のadvantageはこれを増幅する。誤って高く採点された軌跡の行動が強化され続けてしまうからだ。

対策として判定手続きを組み直した。一括判定（holistic）をやめ、逐次チェック可能な原子的検証条件を書き、各条件を指定フレームに束縛して全条件の成立を要求する。「いずれか1条件を満たせば通過」という選言バイパスを置き換え、各軌跡を5回判定して単一パスのランダム性を抑える。その結果、スコアは72.52から77.42へ、+4.9ポイント改善した。両者は同じ報酬定義であるため、この差は「より良い目的関数」からではなく「同じ目的をより正確に測ったこと」から来ている。

ここから導かれる結論は実務的に重い。オンラインRLは最適化ステップと少なくとも同程度に、判定ステップに律速される。報酬がノイズを含むとき、サンプルを増やしたり訓練を長く続けたりすると、誤った信号をむしろ増幅してしまう。審判の一貫性を高めるほうが、アルゴリズムをいじるより効く場面がある。

Every Sample Matters：失敗を監督信号に変えるデータエンジン

実機でのデータ収集は時間がかかり、端末のリセットも難しく、検証も脆い。その結果として、収集の現場には失敗軌跡と異常軌跡が大量に生まれる。素朴な発想は「きれいな成功だけを残し、失敗は捨てる」だが、失敗の中には最も希少な訂正信号と探索信号が含まれている。モデルが同じ失敗を繰り返すのは、失敗の記録が学習に届いていないからだ。BlueLM-GUI は失敗を廃棄物ではなく監督信号として扱い、それを訓練データに変換するエンジンをループの中核に置いている。ここでは、そのデータエンジンを構成する要素を順に追う。

二重トラック・パイプラインの全体像

データは2本の並行するトラックで生産される。

トラック1（SFT生産ライン、4リングの主鎖） は、クエリ生成 → 実機軌跡収集 → 軌跡評価 → データルーティングと自己修復という4段のリングで構成される。ここで検証済みの軌跡はSFTプールへ、失敗は後述するECDM（Error Correction & Derivation Module、失敗を監督に変換する修復モジュール）へ流れる。

トラック2（RL自己進化ライン） は、中難度のクエリを最新のSFTモデルで実機ロールアウトし、群内の成功・失敗分布によってクエリ自体を取捨する。2つのトラックをつなぐ自己修復の核がECDMであり、失敗軌跡を属性判定して新しい監督に変換する3つの修復パスを持つ。

flowchart TB
  subgraph T1["トラック1：SFT生産ライン"]
    Q["クエリ生成"] --> R["実機軌跡収集"]
    R --> J["HTSCによる軌跡評価"]
    J --> RT["データルーティングと自己修復"]
  end
  RT -->|"検証済み"| P1["SFTプール"]
  RT -->|"失敗"| E["ECDM（橋）"]
  subgraph T2["トラック2：RL自己進化ライン"]
    Q2["中難度クエリ"] --> R2["実機ロールアウト"]
    R2 --> D["成功/失敗分布でルーティング"]
  end
  E --> P2["RLクエリプール"]
  E --> Q

CPTプールとSFTプールを分ける理由（CPT/SFTデカップリング）

CPT（継続事前訓練）とSFT（教師あり微調整）のプールを同じゲートに通さない設計には、2つの非対称性がある。

1つ目は生産速度だ。SFTデータは実機でエンドツーエンドに走らせ、長い収集–評価チェーンを通過しないと使えないため遅い。一方CPTデータは各収集ステップで生まれ、ルールベースのクリーニング後すぐプールに入るので速い。両者が同じゲートを共有すると、速い流れが遅い流れの後ろで待たされ、モデルが新しいデータに飢える。

2つ目は能力基盤だ。モデルがGUIタスクを計画するには、その前段としてより汎用的な低次能力が必要になる。画面を読む（OCRや要素の位置特定）、基本操作、ツール呼び出し（API呼び出し、パラメータ構築、結果解析、エラー処理）といった能力である。これらは長期タスクの成否に依存しないため、CPTプールに一定の比率を確保できる。単一ステップのスクリーンショット–行動ペアは、それを含む軌跡が最終的に失敗していても有効だ。 CPTで汎用能力を先に入れておけば、SFTは希少な監督をGUI計画そのものへ集中できる。これは将来の「GUI + API + CLI」融合パラダイムに向けた基礎能力の予約でもある。

クエリ生成：機能カバレッジ × 指示の多様性 × 複雑度

クエリは3つの次元で設計される。機能カバレッジ（Function Tree）が「何をするか」、指示の多様性（Instruction Tiers + User Personas）が「どう言うか」、タスク複雑度（Capability Profile）が「どれだけ難しいか」を担う。

Function Tree（機能ツリー） は、実商用アプリの機能を階層構造として表現する。半自動のパイプラインで構築する。まず探索エージェントがアプリを巡回して各ページ階層をスクリーンショットし、レイアウトスキーマを抽出する。次に強いVLMがUI操作要素・コピー・潜在機能を識別してJSONツリーを自動生成する。人間が矛盾や冗長なノードを剪定し、同じ機能に複数経路で到達できる場合は再利用関係をタグ付けして重複展開を避ける。このツリーはパイプライン全体の統一インデックスになる。クエリ生成は葉ノードを展開し、収集はそこを目標に航行し、カバレッジ計測は「実行済み葉ノードの割合」を計算する。「機能を網羅している」という曖昧な状態を、測定可能な量に変える仕組みである。

Instruction Tiers（指示の3階層） は、表現の明確さに対する適応力を訓練する。

User Personas（8種） は、一般・初心者、大学生・Gen-Z、プログラマ、ビジネスパーソン、高齢者、配達員、旅行ブロガー、専業主婦という役割である。同じ機能点でも口調・語彙・癖が違う。LLMにロールプレイさせ、スタイルフィルタをかけることで合成データ特有の「機械アクセント」を抑える。

Capability Profile（6つの能力次元） は、前半3つが単一ページ内の判断難度、後半3つがページとアプリをまたぐ構造を表す。

Global Environment Memory：実行不能な指示を防ぐ

クロスアプリのタスクを生成するLLMは、対象端末の実状態にアクセスできない。そのため「小紅書で追跡番号を読んで菜鳥に貼り付け、荷物を照会する」といった指示を平気で捏造する。しかし小紅書のページがリスク管理でスクリーンショットをブロックしていたり、菜鳥にそもそもログインしていなかったりする。物理的に実行不能な指示を量産すれば、収集資源が無駄に消費される。

解決策が GEM（Global Environment Memory） である。実機上の到達可能性知識を構造化したトポロジカルなグラフDBだ。知識源は2つある。1つは実機探索から得るページナビゲーショングラフで、能動的探索（アイドル時に探索エージェントが非破壊で巡回し、スクリーンショットとレイアウトXMLを記録）、知覚的重複排除（pHashとレイアウト類似度で重複ページを除去し、機能的に一意なスケルトンだけを残す）、ナビゲーショングラフ構築（アプリ内エッジに加え、Homeキー・履歴パネル・共有シート・クリップボード経由のクロスアプリエッジ）、VLMによる入出力互換性抽出（「淘宝の商品詳細」の出力はテキスト:商品名、「JDの検索ページ」の入力はテキスト:検索語で、型が互換）という流れで作られる。もう1つはデバイス・システムレベルの状態知識——機種やOSバージョン間の機能差、システム設定への正確な経路、プリインストールアプリの能力境界である。

クロスアプリのクエリ生成は、Function Treeから出発点をランダムにサンプルし、GEMで入出力互換の終点を探索し、「淘宝 → ランチャー → JD」という物理経路が存在して通行可能かを検証し、VLMが両アプリの実ページ文脈を組み合わせて接地されたクエリを生成する、という手順を踏む。実機で Env_ERROR が出た場合は破損経路を「一時到達不能」にマークし、その経路での生成を止め、更新後のグラフで到達可能な代替経路へ再ルーティングする。GEMは変化し続ける実機環境と同期し続ける。

クエリの入場処理：品質ゲートと事後タグ付け

新規の合成クエリは3つのゲートを通る。

Gate 1 はLLM審判による3軸評価だ。Realism（人間の表現習慣に合うか）と Completability（現行の主要アプリの機能で物理的に実行可能か）は硬フィルタで、後者を満たさないクエリは即座に破棄される。Complexity（操作ステップ数と推論の深さ）は硬フィルタではなくメタデータラベルとして保存し、混合比率の調整とRLプール候補の選別に使う。

Gate 2 は自然言語の研磨である。軽量な書き換えモデルが「LLMプロンプト臭」の強い文を、自然な言い淀み・口語ノイズ・略語を持つ慣用表現へ変える。

Gate 3 はFunction Treeノードへのバックタグ付けだ。承認されたクエリを対応する葉または部分木ノードに自動で錨付けし、カバレッジのリアルタイム監視とノード重み付きの訓練混合を可能にする。

外部から取り込んだクエリ（厳選した外部ソース、ビジネス側の BadCase、オープンソースデータセット）は、このパイプラインが作ったものではなく本番ラベルを持たないため、LLMによる4次元の事後タグ付けを行う。次元は、ステップ深度、曖昧性グレード（L1〜L3に整列）、リスクグレード（金銭支払い、プライバシー露出、機微なアカウント情報の変更）、前提条件（「銀行カードを紐付け済み」「アカウントがログイン済み」など）である。前提条件は、実機ファームが実行前に環境を自動プリセットするために使われる。

実機軌跡の収集：4つのチャネルと物理レベルの工夫

軌跡は精度・コスト・スループットのトレードオフが異なる4つのチャネルで並行収集される。

スキーマ誘導ラインには2つのモードがある。完全な経路を注入する tap-operation mode と、検索語と機能位置説明を注入する search-operation mode だ。視覚や文言のわずかな違いで盲目的探索の成功率が崩壊する領域を確実に攻略するために用意されている。

自動ラインでは物理レベルの自己清掃と安全隔離が行われる。各タスクの前に am force-stop（バックグラウンドプロセスの強制停止）と pm clear（対象アプリのデータ消去）を低レベルADBコマンドで実行し、毎回クリーンな初期状態から起動する。デバイスは独立したセルラーネットワーク上の専用物理SIMカードにバインドする。さらに、遷移軌跡のない座標タップではなく、現実的な物理加速度を持つタッチ軌跡信号を注入して、商用アプリの端末リスク管理エンジンを回避する。この設計は実データを取得するための工学的必要性である一方、プラットフォームの保護機構をすり抜ける行為でもあり、技術的にも倫理的にも議論の余地がある。技術的必要性と倫理的論点の両面を並べる記述にとどめる。

半自動ラインの意義も明確だ。人間が各ステップで外科的な検証を行うため、幻覚を含む軌跡がデータに入るのを防ぎ、それまでの成功ステップに費やした端末時間を保全できる。推奨行動が正確ならワンクリックで確認し、数十ピクセルずれている、スライダーのドラッグをタップと誤判定したといった場合はタップボックスを直接ドラッグして微調整する。

Structured CoT：行動の前に「何を」と「なぜ」を書かせる

GUIタスクは長期の逐次決定であり、行動系列だけで訓練したモデルは未見ページへの推論を一般化できない。そこで全ての収集軌跡に、各行動の前の構造化推論チェーン（Structured CoT）を要求する。推論時にも同じスキーマをシステムプロンプトに書き込み、SFT段階のプロセス監督のデータ基盤にする。タグは5つだ。

• [Observation] — 現在のページ状態の記述（例: 淘宝の検索結果ページ。上部に検索ボックス、下部に商品リスト）
• [Reflection] — 前ステップのレビューと訂正。観測が前ステップの計画と矛盾する場合のみ発火（例: 前のステップでフィルタボタンをタップしたがページが変わっていない）
• [Plan] — 次ステップの計画（例: 検索ボックスをタップして「Sony XM5」と入力して検索）
• [Decision] — 具体的な行動（例: 座標 (540, 200) の検索ボックスをタップ）
• [Memory] — ステップをまたいで記憶すべき情報（例: 比較中の商品はSony XM5、価格1,999元）

ここで肝となるのが双方向一貫性制約である。行動を先に生成し、それに合わせて尤もらしい推論を後から組み立てる「事後合理化」を防ぐため、プールへ再入する前に双方向の検証ゲートを通す。Forward derivability（前向き導出可能性）は、[Observation] と [Plan] が与えられたとき [Decision] が唯一合理的な行動でなければならないとする。異なる行動がどれも「辻褄が合う」ようでは不十分だ。Label consistency（ラベル一貫性）は、[Decision] の行動が実行された軌跡の行動と完全一致すること、[Observation] のページ状態がスクリーンショットと一致すること、[Memory] の項目が後続ステップで実際に参照されることを要求する。違反した場合は再生成し、全てを通過させる。

Horizontal Enrichment：軌跡を壊さずに頑健さを注入する

新しいタスクを作らずに、既存軌跡を再編成・洗練して収集時に介入するパイプラインが Horizontal Enrichment である。処理は3種類ある。

ステップ単位の文脈曖昧性解消は、異なるアプリが極めて似た視覚構造を持つ問題（各種スーパーのほぼ同じ「ショッピングカート」ページなど）に対処する。各ステップのメタデータに、収集時にADBで取得したシステムレベルの状態（フォアグラウンドアプリのパッケージ名 com.taobao.taobao やActivityスタック）を明示的に書き込み、VLMに曖昧さのない物理的識別子を与える。純粋に視覚的な推論のドリフトを減らす効果がある。

異常状態の注入は、多様な条件でも機能し続けるエージェントを訓練するために行う。収集時に2クラスの予期しない妨害を注入する。システム割り込み（操作中のプッシュ通知、低バッテリー警告、事前設定した権限ダイアログ「位置情報へのアクセスを許可しますか」）とネットワーク変動（人為的な遅延や切断で「ネットワークに接続できません。再試行してください」を出す）である。妨害下での成功した自己回復経路（ダイアログで「許可」をタップする、あるいは「更新」をタップする）を捕捉し、防御のプレイブックを作る。注入できない異常状態（ログインセッション切れ、CAPTCHA、支払検証）については、14クラス・約5,000件の的を絞ったサンプルを別途収集する。モデルは人間の介入が必要な場面（CAPTCHAなど）では停止して制御を返すこと、安全にスキップ可能なページ（広告、重要でないポップアップ）は閉じるか回避することを学ぶ。

反復→反省の変換は、実機ロールアウト特有の失敗モードに対処する。軌跡には「単一の行動や小さな行動群が連続して繰り返される」区間がしばしば現れる（局所的な失敗モードやページの遅延・ネットワークのジッタが原因）。そのまま訓練ラベルにすると「詰まったら繰り返す」ことを教えてしまう。そこで繰り返しステップを訓練ラベルから除去しつつ、軌跡履歴には残す（「詰まっている可能性」の証として）。後続ステップで停滞から脱出した場合（戻る、別の入口に切り替える、再計画する）、その訂正ステップはラベルとして残り、以前の失敗試行がその文脈に入っている。こうして有害なラベルパターンを、反省とエラー回復志向の監督信号に変える。

HTSC：3つの異種システムによる合議で軌跡を評価する

単一の評価器は、どれほど高性能でもマルチモーダル幻覚と単一視点の盲点に陥る。訓練プールの純度を1つの審判に委ねるべきではない。そこで HTSC（Heterogeneous Triple-System Consensus） が3段階で軌跡を評価する。

Stage 1 安全拒否権（事前スクリーニング）: 3システムが正しさの評価と並行して共有の安全チェックリストを実行する（直接支払、機微な権限、プライバシーデータへのアクセス、不可逆な危険操作）。1つでも違反を検出したら一票否決であり、軌跡は合議投票をバイパスして即 False 判定となりECDMへ送られる。安全レッドラインは多数決に参加せず、「多くのシステムが問題なしと見た」で覆せる経路が存在しない。

Stage 2 3つの異種評価器: 異なる技術スタックで共倒れのリスクを減らす。

Stage 3 合議投票: 結果は {True, False, Env_ERROR, Undetermined} の4つに集約される。各システムは {True, False, Env_ERROR, 棄権} のラベル空間で投票する。System Aは終端状態を読めないとき棄権し、Env_ERRORはポップアップ遮断・ネットワーク異常・権限欠落・アプリクラッシュの検出時に立てる。優先規則は明確だ。System Aが終端状態を読める場合、Aの物理的断言が高信頼の事実として決定を支配する。Aの失敗断言はB・Cに関わらずFalse（Aが環境要因を特定したならEnv_ERROR）、Aの成功断言はB・Cが満場一致で反対しない限りTrue、反対ならUndetermined。Aが棄権した場合はBとCが投票し、満場一致通過はTrue、満場一致失敗はFalse、不一致はUndeterminedとなる。

flowchart TB
  S["軌跡"] --> SAF{"安全チェックリスト"}
  SAF -->|"違反あり（一票否決）"| F["False → ECDM"]
  SAF -->|"問題なし"| A{"System A：終端状態を読める？"}
  A -->|"Yes・失敗断言"| F
  A -->|"Yes・成功断言"| BC{"B と C が満場一致で反対？"}
  BC -->|"No"| T["True → SFTプール"]
  BC -->|"Yes"| U["Undetermined → 人間裁定"]
  A -->|"No（棄権）"| BC2{"B と C の投票"}
  BC2 -->|"満場一致通過"| T
  BC2 -->|"満場一致失敗"| F
  BC2 -->|"不一致"| U

4つの結果はそれぞれ異なる経路へ流れる。TrueはSFTプールへ。FalseはECDMへ（アルゴリズム的な実行失敗であり、ステップ単位修復または事後整列を経て高品質なSFTデータになる）。Env_ERRORはECDMと環境自己修復・再収集へ（モデルの誤りではないため、ポップアップを閉じて再開する修復ステップを合成して使える監督を回復する）。Undeterminedは人間の裁定へ。

Undeterminedの人間裁定は重要である。うかつにゴールドスタンダードプールへ入れてSFTを汚染してもいけないし、うかつに失敗として訂正に回してもいけない。人間が「正しい」と裁定すればSFTプールへ、「誤り」ならECDMへ、「環境問題」ならEnv_ERROR分岐へ送る。そしてこのループは複利的に効く。不一致サンプルは評価体系にとって最も価値のあるストレステストであり、単一モダリティ審判の盲点を集中的に露呈させる。人間の裁定は同時に評価システムの閾値とプロンプトの較正に使われ、反復ごとに合議の一致率が上がっていく。判定の不一致はノイズではなく、それ自体が監督信号である。

3つのプールの代謝：静的に積むものと、動的に交換するもの

3つのプールの違いは「何を保存するか」よりも、モデル M(t) が進化するにつれてサンプルの価値が持続するか、移り変わるかにある。

CPTプールとSFTプールは、入場ゲートの厳しさが違うだけで時間的な振る舞いは同じだ。両者に共通するのは「正しさがモデルの進化に依存しない」という性質であり、だから単調に蓄積できる。対照的にRLクエリプールは、クエリのRLとしての価値がクエリそのものではなく現在のモデルが解けるかどうかで決まる。モデルが強くなれば昨日の境界事例が今日の簡単な勝利になり、プールはそれに応じて代謝しなければならない。そうしなければ、RLの計算が既に習得済みのクエリに浪費される。

代謝は2フェーズで進む。Phase 0（ブートストラップ） では難度の物差しになるポリシーが存在しないため、ポリシー非依存の客観的特徴が代役を務める。指示階層L2/L3、大きいステップ深度、クロスアプリ連携、複数機能の組み合わせといった特徴で、自然に難しいクエリを事前に選別して蓄え、M(0) の訓練後に活性化する。Phase 1（自己進化） では、各RL訓練ラウンドの後に M(t) がプールのクエリに対して複数回ロールアウトし、群内の成功・失敗分布がクエリ単位の3方向代謝を駆動する。全Trueは引退（習得済みで学習信号が残らない）、混合は保持（能力境界にあり勾配情報の利得が最大）、全FalseはRLプールを離脱して失敗軌跡をECDMへ送る（境界の外にあり、修復されてSFTコーパスになり境界を広げるのを助ける）。

入場チャネルは複数ある。コールドスタートの客観特徴選別、データパイプラインのルーティング、ビジネス側の補完、オンラインや評価で露呈した BadCase の的を絞った補完である。Phase 1では全チャネルが統一ゲートを通る。すなわち「現在のポリシーの成功率でソートし、全Trueと全Falseを除去する」。これにより入場する全クエリが現在のポリシーの中成功帯に落ちる。2つの静的プールが土台になり、1つの動的プールが境界を探る——この構造によって、データシステムは「蓄積する（正しさは持続する）」と「追随する（難度はモデルと動く）」を同時に満たす。

Cascaded Failure Attribution：失敗の原因を「工学側から」順に切り分ける

失敗軌跡がFalseまたはEnv_ERRORの分岐に流れたとき、ECDMの最初の仕事はカスケード帰属である。工学側を先、アルゴリズム側を最後という固定順序で原因をレベルごとに判定し、各レベルの結論が軌跡のその後の処理経路を直接決める。

カスケードが必要な理由は、環境干渉とモデルの欠陥が、軌跡レベルではしばしば同型に見えることにある。ネットワーク切断によるタスク中断と、状態追跡を失ったことによる中断は、Action-Observation履歴上ほとんど区別できない。客観的な環境要因を先に排除しないと、環境ノイズが能力ギャップに誤帰属され、ECDMが誤った標的への修復方向を作り出してしまう。

判定は3レベルで行う。

Level 1 環境失敗チェック（客観的、端末側の事実）: システムポップアップの遮断、ネットワーク異常、権限欠落、アプリクラッシュといった観測可能な環境干渉が軌跡に含まれるかを調べる。該当すれば Env_ERROR ラベルを付け、モデルの誤りとして数えない。構造化した干渉特徴（ポップアップの種類、発生タイミング、ネットワーク状態）を抽出して環境保守モジュールへフィードバックし、実機環境の自動自己修復と再収集を起動する。

Level 2 タスク・検証器の欠陥チェック（データ生産側）: 環境要因を除外したうえで、失敗がモデルではなくデータ生産側に由来しないかを調べ、所有者別に2つに分ける。タスク仕様の欠陥（曖昧・自己矛盾・書かれたとおりでは検証不能な指示）はクエリ生成の欠陥なので、タスク記述をクエリ生成へ差し戻して修正する。検証ルールの欠陥（正しく完了した軌跡を不合格にしたルール）は評価の欠陥なので、ルールを修正し誤判定された軌跡を評価キューへ戻す。どちらもモデルの責任にはしない。 なお、適切に定式化されたタスクが現在のモデルの能力を超えているだけの場合は Level 2 の欠陥ではなく、Level 3 で扱う。

Level 3 モデル失敗の帰属（アルゴリズム側）: 最初の2レベルを除外した後に初めて、失敗をモデル自身に帰属させ、構造化された原因に細分する。知覚ドリフト（VLMがUI要素を誤認・見落とす）、状態追跡エラー（ページ遷移で文脈を失いループ挙動を起こす）、制約違反（クエリ内の特定の制限を守らない）の3つである。

このカスケードが「評価信号」を「実行可能な最適化目標」に変える。各レベルの結論には明確な下流の行き先がある。環境特徴は環境自己修復へ、タスク仕様欠陥はクエリ生成の改訂へ、検証ルール欠陥は評価の改訂へ、モデル失敗の原因はECDMの修復と次ラウンドの指向性データ生産へ。全ての診断信号にオーナーがいる状態を作るのが狙いである。

ECDMの3つの修復パス：失敗をデータに変える具体手順

ECDMは各ラウンドのロールアウトと評価ルーティングが生む全ての失敗軌跡を受け取る。処理は完全にオフラインの純粋なデータ工学であり、実機の収集資源を消費しない。入場時に各失敗軌跡はカスケード帰属の結論を直接消費して3パスのいずれかへ振り分けられる（帰属エンジンが既に「どのレベルで失敗したか」を決めているので、ECDMは再判定しない）。

パス1: ステップ単位訂正（Step-Level Correction） — 偶発的な単一ステップの滑りを修復する。条件は、軌跡のプレフィックスが完全に正しく、1ステップだけ誤った（要素を間違えてタップした、ポップアップを誤って起動した）ケースであり、そのステップの正しい行動が後続の実機状態に依存せずオフラインで決定できること。手順は、先頭 N−1 ステップを「プレフィックス成功状態」として切り取り、N番目を二段構えで修復する。一次トラックは、誤ったステップの文脈（スクリーンショット、ゴール、行動履歴）をより強いオフラインTeacherモデルに渡し、そのステップの正しい行動を書き換えさせる。フォールバックは、Teacherの信頼度が低いケースや難しいシナリオ（リスク管理、複雑なアカウント状態、深刻なUI変形）を人間の修復へ回す。生成されるのは「完全な回復後軌跡」ではなく「プレフィックス軌跡＋単一ステップ訂正ラベル」である。実機状態は復元できないので、修復後の行動を元の軌跡上で再実行して検証することはできない。それでも監督としての価値は、すでに道を外れた実際の誤り状態の文脈の中で正しい行動を学ばせる点にある。多段の「逸脱–診断–回復」軌跡はオフラインでは構築できず、次ラウンドのロールアウトで実機から再取得するしかない、という限界も明示されている。

パス2: 遡及クエリ整列（RQA / Retroactive Query Alignment） — 過大スコープのタスクをプレフィックスの正解に降格する。条件は、プレフィックスは完全に正しいのに、失敗の根本原因が「1ステップの誤り」ではないケースである。元のクエリが過大スコープで、現在のモデルの能力を超えているか、到達不能なサブゴールを含む。プレフィックスは間違っておらず、間違っているのはそれが仕えるゴールだ。手順は「引き算のみ、やり直しなし」のオフライン抽出戦略を取る。軌跡がゴールから逸脱するか環境エラーに当たったステップ t を検出したら、a_t 以降を捨て、完全に正しい系列 a_1…a_{t−1} を「ゴールデン・プレフィックス部分軌跡」として保持する。エラー直前の最後のフレームのスクリーンショットとレイアウトツリーを抽出して実際のページ状態を解析し、オフラインTeacherモデルが元の指示 Q を、s_{t−1} の終端状態の意味に正確に合う新しい指示 Q′ へ書き換える。再構成されたペア (Q′, [a_1…a_{t−1}]) を完全に正しい短鎖サンプルとしてSFTプールへ注入する。再サンプリングのコストはゼロだ。

具体例で見ると分かりやすい。元の指示 Q が「淘宝でSony XM5を検索し、JD.comも開いて価格比較し、安い方のプラットフォームで発注する」だったとする。モデルは淘宝検索・JD検索・価格比較まで完了したが、支払方法が未登録のため最終決済で失敗した。RQAは決済の区間を切り捨て、「両プラットフォーム検索＋価格比較」のプレフィックスを保持し、Q を Q′「淘宝とJD.comでそれぞれSony XM5を検索し、2つのプラットフォームの価格を比較し、どちらが安いか記録する」に書き換える。ここでパス1との対比が重要だ。ステップ単位訂正は「タスクは正しいが1ステップが間違っている」と仮定するので行動を変える。RQAは「行動は全て正しいがタスクが過大スコープだった」と仮定するのでタスクを変える。

パス3: 反事実的クエリ派生（Counterfactual Query Derivation） — 失敗のクラスを標的型訓練タスクに変える。最初の2パスは個々の軌跡を一件ずつ扱うが、能力ギャップは一件ずつの修復では直らない。条件は、失敗軌跡を構造化帰属でクラスタリングした結果、同一のエラー・クラスが複数の軌跡・複数のクエリで再発しているケースである。具体例としては「多重制約フィルタリングで一部条件だけ満たして早く確定してしまう」「前のページで抽出した情報をページをまたいだ後に忘れる」「システム確認ダイアログでキャンセルをタップしてしまう」などがあり、これはモデルの能力欠陥を指し、Capability Profileの次元に対応する。体系的に強化する必要がある。手順は、まず失敗クラスの構造的特徴（引き金となるシナリオ、目標の操作フロー、欠けている相互作用の勘所）を誘導する。次にTeacherモデルが失敗パターンに基づいて、ギャップを正確に突く敵対的な新クエリをバッチ合成する。「多重制約フィルタリングの条件漏れ」に対しては「評価4.5以上、一人当たり100元以下、配送対応の3条件すべてが必須のレストランを探す」、「クロスページの忘却」に対しては「1軒目の店舗の価格を覚えておき、3軒目で比較し、最も安い店で発注する」といったクエリが生まれる。この敵対クエリ群は次ラウンドのRLクエリプールへ注入されると同時に、クエリ生成にもフィードバックされ、モデルが脆弱な能力境界で繰り返し探索して正しいポリシーに収束するまで強制する。

3パスの役割分担を整理する。ステップ単位訂正とRQAは失敗軌跡から使える監督を回復するが、それは既存能力の範囲に限られる。反事実的派生は失敗パターンを武器に変え、ギャップを攻撃する新しいタスクを生む。前者はデータを修復し、後者は方向を生む。

flowchart TB
  F["失敗軌跡"] --> C1{"プレフィックスは正しい？"}
  C1 -->|"No"| X["環境/データ生産の欠陥として別経路へ"]
  C1 -->|"Yes"| C2{"1ステップだけ誤り？"}
  C2 -->|"Yes"| P1["パス1：ステップ単位訂正 → SFTプール"]
  C2 -->|"No"| C3{"同一のエラー・クラスが再発？"}
  C3 -->|"No（過大スコープ）"| P2["パス2：RQA → SFTプール"]
  C3 -->|"Yes"| P3["パス3：反事実的派生 → RLプール＋クエリ生成"]

自己進化ループのライフサイクル：初期・中期・後期で質が変わる

自己進化ループは終わりのない機械的な反復ではない。反復が進むにつれて質的に区別できる段階を示し、モデル能力とコーパス品質が一緒に上がっていく。

初期段階（行動クローニングと規範の確立） はSFTが支配する。HTSCが生成した高純度のゴールドスタンダードデータを通じて、レイアウト、要素の位置特定、基本的な相互作用の規範といったGUIの基礎を急速に吸収し、タスク実行の基本的な直感を築く。

中期段階（探索境界の拡大とロバスト性の強化） ではRLの比率が大幅に上がる。大規模な実機ロールアウトが動的報酬を通じて故障耐性を形作る。ECDMが失敗軌跡をバッチで蘇生させ（ステップ単位訂正とRQA）、高頻度で敵対的な派生クエリを生成してクエリ生成へフィードバックし、モデルを可変でノイズの多い実機環境で自己較正させる。妨害耐性と異常自己回復能力はこの段階で著しく改善する。

後期段階（動的均衡と自己洗練） では、簡単なタスクに対応するクエリが、高い pass@K や報酬を維持し続けた結果として習得済みサンプルとみなされ、RLのアクティブセットから順次除去される。RLクエリプールは自動的にモデルの最も難しい能力境界へ集中する。モデルが高難度のロングテール事例を1つ征服するたびに、コーパス全体の難度が一段上がる。これが「強いモデル → より深い境界の発見 → より難しい派生コーパス → さらに強いモデル」という自己進化ループを形成する。失敗を捨てずに監督へ変換するデータエンジンは、この循環を止めないための土台になっている。

Every Query Evolves：モデルと一緒に進化するベンチマーク

自己改善ループを回し続けると、モデルは改善し続ける。すると固定されたベンチマークはいずれ飽和し、スコアが良い判断と悪い判断を分離しなくなる。その時点でスコアは「次に何を直すべきか」を教えてくれない。これが3つ目のギャップ、帰属ギャップである。必要なのは「より難しいベンチマーク」ではなく、モデルと一緒に進化するベンチマークの作り方だ。BlueLM-GUI は、3つの直交軸（シナリオ / 複雑度 / 相互作用とリスク）を安定した座標系として使い、1つのベンチマークが飽和したら一部の次元のクオータ（各次元に何件を配分するかの目標値）をずらす。新旧のベンチマークは明示された差分だけが異なるものになるため、スコアの変化を正確に帰属できる。

構築は5ステップで進む。①注釈次元を定義し、「何をテストするか」を「どうクオータを配分するか」の問題へ変換する。②新しいベンチマークの目的を、それらの次元上の目標クオータとして記述する。③LLMがクオータに沿ってクエリを生成する。④専門家が出荷前に全クエリを検証・洗練する。⑤独立したマルチ審判の投票で各軌跡を採点する。

flowchart LR
  A["固定ベンチマーク<br/>スコアが天井に張り付く"] --> B["飽和を検知"]
  B --> C["一部次元のクオータを変更<br/>（差分を仕様として記述）"]
  C --> D["新しいベンチマーク<br/>スコア変化が全て帰属可能"]

3直交軸のメトリック体系

クオータで大量生産できるよう、注釈次元はすべて離散値になっている。これらが「タスクはどこで起きるか」「実行はどれだけ難しいか」「相互作用の形式は何か」という3つの直交軸を成す。

Complexity軸には注意すべき制約がある。ステップ数は指示の文言から導出できない。「チケットを予約して」は4語だが、実機では10ステップ以上かかる。そこでLLMに各クエリの想定経路を辿らせ、専門家の洗練時に推定を修正する。また Intent dependency の A→B は、あるサブタスクの出力を次の入力にしなければならない構造で、クエリが長い必要はない。Interaction & risk軸の refusal and safety は、アプリがサポートできない要求や高感度な操作を扱う。これらがなければ、要求に関係なく行動するモデルが、自分の限界を知るモデルより高得点になってしまう。

2つのベンチマークとクオータの偏らせ方

BlueLM-GUI は同じ次元で2つのベンチマークを構築する。MobileGUI-VBench-Basic は「モデルがそもそも使えるか」を問い、シナリオクオータをアプリの人気度に従わせる（43アプリ、最も多くインストールされている50タイトルのうち36をカバー、11カテゴリ）。MobileGUI-VBench は「どこでまだ不足するか」を問い、150クエリ・39〜40アプリでサードパーティアプリのみを対象に他モデルと公平に比較する。

VBench では構造的な変更を加えている。複雑度は moderate を主体に simple を削減し、難度の追加を経路長よりも intent dependency から得る（dependent multi-intent の比率を大幅に引き上げる）。相互作用では agent-user interactive クエリをほぼ40% にし、成功の基準を「操作が完了したか」から「適切な瞬間に適切に応答したか」へ書き換える。リスクシナリオは比例配分ではなく「必ず存在」ルールを採り、金銭・プライベートデータ・不可逆な変更に触れるクエリは比率が小さくても必ず入れる。これらのクオータは発明したものではなく、自モデルの失敗事例を収集・一般化したもので、偏りが実際の弱点を指す。

評価プロトコル：単一指標と満場一致判定

実機での評価は実際に起きる1本の軌跡なので、報告する指標は成功率（SR）の1つだけである。審判は二値判定を返し、部分点は与えない。実機では「ほとんど到達した」はユーザーにとって価値がないからだ。agent–user interactive クエリで金銭やプライベートデータを含む判断点を call_user せず通過したモデルは、タスクが完了したように見えても失敗となる。拒否クエリで正しく拒否・確認できれば成功であり、単一指標が実行と相互作用の両方を拘束する。

判定には、異なるルールセットを持つ複数のVLM審判を独立に走らせ、全員が一致したときだけ成功と数える満場一致方式を採る。判定が割れた軌跡は自動判定の信頼できる範囲の外という信号であり、専門家が手動で採点し、その裁定を曖昧だった判定ルールの修正に使う。環境起因の失敗（ログイン期限切れ、UI再設計、ネットワークエラー）は帰属処理の後に採点せず、デバイスをリセットして再収集する。こうしてベンチマークは静的な成績表ではなく、次に何を直すべきかを示す診断機器になる。

実験結果：スコアの「形」が何を語るか

実験結果で押さえるべきは単一スコアの高さではなく、複数ベンチマーク上でスコアが描く「形」である。BlueLM-GUI は総35B・活性3B（総パラメータのうち推論時に実際に働くのが3BというMoE構成）で、独自ベンチマーク MobileGUI-VBench に 87.4、公開ベンチマーク AndroidWorld に 84.9 を記録した。前者は最高のクローズドソースAPIモデル（82.3）を5.1ポイント上回る。

2つの指標は逆相関に近い動きをする。AndroidWorld で83.2を出す PhoneBuddy は、ここでは39.0に落ちる。MobileGUI-VBench のクエリの多くは、あるサブタスクの結果を次に渡す dependent multi-intent 構造を持つか、判断点で止まってユーザーに確認することを求めるか、そもそも拒否すべきもので、素直な実行に最適化されたモデルには得点源がない。強い実行能力は相互作用・拒否行動に持ち越されないが、後者で訓練されたモデルは実行能力を保つ——この非対称性がスコアの形として現れる。

quadrantChart
    title ベンチマーク間の性能分布
    x-axis "MobileGUI-VBench 低" --> "MobileGUI-VBench 高"
    y-axis "AndroidWorld 低" --> "AndroidWorld 高"
    quadrant-1 "相互作用対応型・実行も高い"
    quadrant-2 "実行特化型"
    quadrant-3 "両軸で低い"
    quadrant-4 "相互作用対応型・実行は中位"
    "BlueLM-GUI": [0.87, 0.85]
    "Seed2.1-Pro": [0.82, 0.72]
    "Qwen3.8-Max": [0.64, 0.85]
    "PhoneBuddy": [0.39, 0.83]

アブレーションは設計判断ごとの効き方を切り分ける。

CPTの有無による差は特に示唆的だ。画面理解スコアは95前後で横ばいのまま、軌跡成功率だけが36.6から70.8へ上がる。ベースモデルは画面を読めるのに、行動空間の概念・連続ステップ間の因果リンク・進捗追跡を持たない。同一SFTデータで6.7ポイント動く以上、この差はCPTが植え付ける事前分布に由来する。

実機オンラインRLの比較は、RLを適用すれば上がるという直感を裏切る。オフラインのリプレイは73.9でSFT単体74.9を下回る。状態遷移が固定されたオフライン軌跡では、現行ポリシーがその分布から離れた瞬間に advantage 推定が現実の帰結に対応しなくなり、RLは既存行動の再重み付けに退化する。出力を実際に実行し本物の次の画面を受け取る構成だけが、行動と帰結のループを閉じる。

報酬の測り方も同じ重みを持つ。同じ報酬定義のまま、一括判定を原子的条件＋指定フレーム束縛＋5回判定に置き換えると+4.9ポイント。この差はより良い目的関数からではなく、同じ目的をより正確に測ったことから来る。オンラインRLは最適化ステップと少なくとも同程度に、判定ステップに律速される。

実装と再現：公開されているもの

この研究の成果物は、大きく分けて「報告書」「評価フレームワーク」「ベンチマークデータセット」の3つが公開されている。逆に、実機数百台のフライホイールそのものは公開されていない。何が手元で再現でき、何ができないのかを切り分けておくことが、実装者にとって最も実用的な情報になる。

公開リポジトリの中身

GitHub の vivo-ai-lab/BlueLM-GUI は Apache-2.0 で公開されている。2026年9月の時点では公開直後で、コミット数23、Star 1・Fork 0 という立ち上がったばかりの状態だ。同梱されているのは技術レポートのPDF、MobileGUI-VBench/ ディレクトリ（評価フレームワークの解説PDF、150タスクを収録した MobileGUI-VBench.jsonl、スプレッドシート、英語・中国語の対話的ドキュメントHTML、全比較表のMarkdown）、そして AndroidWorld/ ディレクトリ（評価エントリポイントの main.py、エージェント対話ロジックの agent.py、config.yaml、vLLM APIクライアント、Androidエミュレータクライアント、タスクデータクライアント、GUI行動空間を記述したプロンプトファイル、起動・実行用のシェルスクリプト、上流の android_world ソース）である。

評価を回す最短経路は単純だ。vLLM でモデルをサービングし、Android エミュレータを設定ポートで動かし、タスクデータAPIに到達できる状態にしてから、start_vllm.sh → run_eval.sh config.yaml の順に実行する。

flowchart LR
    A["vLLM でモデルをサービング"] --> B["Android エミュレータを設定ポートで起動"]
    B --> C["タスクデータAPIに到達可能にする"]
    C --> D["start_vllm.sh でサービス起動"]
    D --> E["run_eval.sh config.yaml で評価実行"]
    E --> F["MobileGUI-VBench スコア / AndroidWorld スコア"]

ベンチマークデータセットの構造

Hugging Face の vivo-ai/MobileGUI-VBench は Apache-2.0 で、150の実世界タスクを40の実アプリにまたがって収録する。8つのシナリオカテゴリの内訳は次のとおり。

内訳は単一アプリのタスクが142、クロスアプリのタスクが8。設計意図を最もよく表すのは、65タスクが環境前提条件を持ち、52タスクが確認要求行動を必要とする点だ。77の機能点に対して13の注釈次元が付いている。

タスクレコードは task_id / query / scenario / involved_apps / precondition / clarification_requirement の6フィールドで構成される。例えば {"task_id":1,"query":"好久没上QQ了，看看朋友们最近都在发些什么动态","scenario":"社交通訊","involved_apps":"QQ","precondition":"","clarification_requirement":""} は、QQを久しぶりに開いて友人の近況を見るというタスクだ。precondition が空でないこと、clarification_requirement が設定されていることが、環境前提と確認要求を第一級の評価対象にしている設計をそのまま示している。

比較対象としての AndroidWorld

公開ベンチマーク側の参照点は Google Research の android_world（Apache-2.0、Star 900・Fork 186、論文 arXiv:2405.14573）である。ライブなAndroidエミュレータ上で動作し、20アプリにわたる116の手作りタスクを収録する。パラメータをランダム生成して数百万のユニークな変種を動的に作る仕組みと、頑健な報酬信号による検証を特徴とする。MiniWoB++ のWebベンチマークも統合されている。

ここは対比として押さえておきたい。AndroidWorld はエミュレータ上でプログラム的に検証する「サンドボックス系」の代表であり、実アプリのアカウント状態・ページ動態・ビジネスロジックを捉えきれないという問題の当事者でもある。それでも84.9というスコアは、外部と比較可能な唯一の指標として意味を持つ。

再現できない部分を正直に書く

公開物は評価側とデータ側が中心である。実機数百台、専用SIMと独立セルラーネットワーク、常駐ランタイム、低レベルADBによる状態リセットを前提とする実機フライホイールは、スマートフォンメーカーという立場があって初めて成立するもので、第三者が同じ構成を再現することは現実的でない。

また、モデル重みの公開状況はリポジトリの記述からは明確に読み取れない。技術レポート・ベンチマークデータ・評価フレームワークの公開は明記されているが、重みについては断定できない。したがって現時点で再現できるのは、公開データセット上での評価手順と、他モデルとのスコア比較の追試までだと考えておくのが妥当である。

この研究がもたらす意味と、残っている課題

この研究の価値は、単一のモデルスコアではなく、「訓練・データ・評価をどういう順序で組み立てるか」という設計図を提示した点にある。ここでは、なぜ実機に賭けることが技術的に筋が通るのか、他分野に持ち帰れる原則は何か、そして何がまだ解けていないのかを整理する。

なぜ「実機」に賭けることが技術的に正しいのか

本論文の核心は、訓練分布と配備分布のズレ（分布シフト）を「データ拡張やドメイン適応で埋めるもの」としてではなく、そもそも訓練そのものを配備環境で起こすものとして扱った点にある。この徹底は、シミュレータが提供する再現性・計装・自動検証という利点を捨てることを意味する。代わりに得られるのは、訓練中に出会う障害がリリース後に出会う障害と同一であるという保証だ。

この保証がどれほど決定的かは、アブレーションが数字で示している。同一のSFTモデルから出発した2つの設定で、事前収集した軌跡をリプレイするオフラインRLは73.9（SFT単体の74.9を下回る）にとどまり、実機で実際に行動を実行するオンラインRLは82.0に達した。差は8ポイントを超える。つまりここでの主張は「実機のほうが現実的でよい」という規範論ではなく、強化学習の勾配が現実の帰結に接地しているかどうかが性能そのものを決めるという機械学習上の論点である。

一般的な設計原則として持ち帰れるもの

エージェント訓練に限らず、データ駆動のシステム設計に転用できる原則が6つある。それぞれに対応する根拠となる数値を添える。

flowchart LR
    A["失敗軌跡"] --> B["原因の帰属"]
    B --> C["行動を直す"]
    B --> D["タスクを直す"]
    B --> E["新タスクを生む"]
    C --> F["SFTプール"]
    D --> F
    E --> G["RLクエリプール"]
    F --> H["次ラウンドの訓練"]
    G --> H
    H --> A

このループが示しているのは、失敗を廃棄物ではなく次ラウンドの探索方向へ変換する仕組みの具体形である。

現実的な制約と限界

意義の大きさに対して、制約も明確である。

• 人間の関与がまだ多い。 判定不能サンプルの裁定、半自動ラインでの各ステップ検証、修復の人間フォールバック、クエリの専門家検証など、ループの各所に人間が前提として組み込まれている。著者自身が今後の最重要方向として「ループが必要とする人間の関与を減らし、より自律的にする」ことを挙げている。
• 実機ファームは誰でも持てるものではない。 数百台の実機、専用SIMと独立セルラーネットワーク、各端末の常駐ランタイム、低レベルADBによる状態リセットは、スマートフォンメーカーという立場があって初めて成立する。デバイス・システムレベルの知識を事前知識として注入できるのも同じ理由だ。
• リスク管理エンジンの回避は議論の余地がある。 タッチ軌跡に現実的な物理加速度を注入してプラットフォームの保護機構を避ける設計は、実データを取るための工学的必要である一方、保護機構をすり抜ける行為でもある。技術的必要性と倫理的論点の両面を押さえておくべき領域だ。
• 独自ベンチマークのスコアは設計意図を含む。 MobileGUI-VBench は dependent multi-intent・停止して確認する判断・拒否すべき要求に意図的に偏らせたベンチマークであり、他モデルとの比較は同一フレームワーク上での再評価である。したがって87.4という値は「その設計意図にどれだけ適合したか」を含む。外部との比較可能性が高いのはAndroidWorldの84.9のほうだ。
• ベンチマーク飽和問題は、解決されたのではなく対処法が用意されただけ。 クオータをずらせば新しいベンチマークが得られるという設計は強力だが、クオータ設計と専門家検証のコストは人間側に残り続ける。
• 安全性の評価は限定的。 安全審査による行動ブロック、評価時の安全拒否権、拒否・確認要求のクオータは設計に組み込まれているが、長期的な悪用耐性やプロンプトインジェクション耐性の定量評価は本論文の範囲外である。

今後の方向性

著者が示す次の一手は3つに整理できる。第一に、フライホイールをより広いデバイスと分布へ拡張すること。第二に、対話パラダイムをGUI・API・CLIの融合へ広げること（CPTプールにツール利用データの比率を確保しているのはこの布石である）。第三に、そして自己進化というテーゼに最も忠実な方向として、ループがいまだ必要とする人間の関与を減らし、より自律的にすることだ。

flowchart TD
    A["クエリ生成"] --> B["実機ロールアウト"]
    B --> C["評価とルーティング"]
    C --> D["帰属と修復"]
    D --> A
    U1["人間: 判定不能の裁定"] -.-> C
    U2["人間: ステップ検証"] -.-> B
    U3["人間: 修復フォールバック"] -.-> D

上のループ図で、点線でつながる人間の関与が、自動化の余地として残っている部分にあたる。この矢印をどこまで減らせるかが、自己進化するエージェントという構想がどこまで本物になるかの試金石になる。

よくある質問

GUIエージェントとは何ですか？普通のチャットAIとどう違いますか？

チャットAIはテキストの回答を返して終わりますが、GUIエージェントは画面を読み取り、タップ・入力・スワイプといった操作を実際に実行してアプリ上のタスクを完了させます。BlueLM-GUIは14の行動（タップ系、ジェスチャー系、意図レベルの複合行動、待機・終了・確認・制御返却）をひとつの行動空間にまとめて扱い、1ステップごとに「実行する行動」と「その根拠となる構造化された推論」を出力します。

「フライホイール（はずみ車）」とは結局何を指しているのですか？

「データ生産 → 訓練 → 評価 → 原因の帰属 → 再生産」というループのことです。実機でのロールアウト結果がデータプールへ戻り、検証済みの成功は次の教師信号に、失敗は「次にどこを突くべきか」という指示に変わります。回転そのものが次の回転を生む構造なのでフライホイールと呼ばれ、回転を止めない鍵は、失敗軌跡を捨てずに監督信号へ変換する仕組み（ECDM）にあります。

実機で訓練するのとエミュレータで訓練するのは、そんなに違うのですか？

違います。同一のSFTモデルから出発した比較では、事前に収集した軌跡をリプレイするオフラインRLが73.9（SFT単体の74.9を下回る）にとどまったのに対し、実機で行動を実行するオンラインRLは82.0に達しました。オフラインでは状態遷移が固定されるため、現行ポリシーがその分布から離れた瞬間にadvantage推定が現実の帰結を表さなくなり、RLは既存行動の再重み付けへ退化します。状態遷移が環境の応答に強く依存する長期タスクでは、実機でのオンライン相互作用は任意の改良ではなく前提条件です。

35B（活性3B）という規模で、巨大なクローズドモデルに勝てるのはなぜですか？

理由は2つあります。ひとつは訓練データの分布が配備環境と一致していること、もうひとつはベンチマークの設計意図です。MobileGUI-VBenchは、依存関係を持つ複数意図のタスク、停止してユーザーに確認する判断、拒否すべき要求に意図的に偏らせており、素直な実行に最適化されたモデルには得点源がありません。実際、AndroidWorldで83.2を出す4Bのモデルがこのベンチでは39.0まで落ちる一方、BlueLM-GUIは87.4を記録し、AndroidWorldでも84.9と、桁違いに多くのパラメータを活性化するモデルと2ポイント以内に位置しています。

失敗した軌跡は、どうやって訓練データに変わるのですか？

3つのパスに分岐します。①タスクは正しく1ステップだけ誤った場合は、正しいプレフィックスを保持したままTeacherモデル（信頼度が低い場合は人間）がその1ステップを書き換え、「間違えた後にどう直すか」を学ばせます。②プレフィックスは完全に正しいのにタスクが過大スコープだった場合は、クエリの側を完了済みの区間に合わせて降格し、完全に正しい短いサンプルとして教師あり微調整のプールへ加えます。③同じエラークラスが複数の軌跡で再発する場合は、的を絞った敵対的クエリを合成してRLプールとクエリ生成へ注入します。前2つは既存データを修復し、3つ目は新しい探索方向を生み出します。

ベンチマークが飽和する問題は、どう解決しているのですか？

「より難しいベンチマークを作る」のではなく「ベンチマークの作り方」を定義しています。シナリオ・複雑度・相互作用とリスクという3つの直交軸を、離散値のメトリック体系として固定し、個々のベンチマークをその上のクオータ配分として表す設計です。飽和したら、経路の複雑度・意図の依存関係・指示の明示性といった次元に沿ってクオータをずらします。すると新旧のベンチマークは明示された差分だけが異なるものになり、スコアの変化をすべて帰属可能になります。

安全性はどう担保されていますか？

3層で組み込まれています。第一に、訓練時のすべての行動が安全審査システムを通過し、プライベートデータ・金銭・禁止コンテンツに関わる行動をブロックします（この審査系は本番出荷品と同じものです）。第二に、軌跡評価には安全チェックリストの一票否決があり、1つのシステムでも違反を検出すれば合議をバイパスして不合格になります。第三に、ベンチマークには拒否・確認要求のクオータがあり、比率が小さくても必ず含めることで、「要求内容に関係なく実行するモデル」が高得点にならないようにしています。

自分で試すことはできますか？

評価側は試せます。GitHub（https://github.com/vivo-ai-lab/BlueLM-GUI、Apache-2.0）に技術レポート、MobileGUI-VBenchのデータセット（JSONL/Excel）、評価フレームワーク、AndroidWorld用の評価スクリプトが公開されており、手順は vLLM サービスの起動（bash start_vllm.sh）と評価の実行（bash run_eval.sh config.yaml）の2ステップです。前提としてAndroidエミュレータとタスクデータAPIが必要で、データセット単体は Hugging Face（vivo-ai/MobileGUI-VBench）から取得できます。ただし実機数百台のフライホイールそのものを再現するには端末・ネットワーク・アカウントを揃える必要があり、個人には現実的ではありません。

まとめ

BlueLM-GUIは、モバイルGUIエージェントの産業実装を止めている3つのギャップ——訓練分布と配備分布のズレ（分布）、実機で生まれた失敗軌跡が捨てられること（活用）、固定ベンチマークが飽和して次の一手を指さなくなること（帰属）——を、3つの原則で1つずつ閉じた実例である。Every Rollout Is Real は訓練そのものを実機で起こし、Every Sample Matters は失敗を監督信号へ変換し、Every Query Evolves はモデルと一緒に進むベンチマークを作る。性能面では、総パラメータ35B・活性3B（MoE構成、35B-A3B）という規模で、独自ベンチマーク MobileGUI-VBench 87.4、公開ベンチマーク AndroidWorld 84.9を記録し、桁違いに大きいモデルと競合する水準に達した。

技術的に最も重要な発見は3点に集約できる。第一に、実機でのオンライン強化学習はRLの前提条件である。同一のSFTモデルからの比較で、事前収集した軌跡をリプレイするオフラインRLは73.9（SFT単体の74.9を下回る）にとどまり、実機で行動を実行するオンラインRLは82.0に達した。状態遷移が環境の応答に依存する長期タスクでは、行動と帰結のループを閉じることが不可欠になる。

第二に、報酬を正確に測ることは、アルゴリズムを改善することと同じくらい効く。一括判定をやめて原子的な検証条件に分解し、各軌跡を5回判定する手続きへ変えただけで、72.52から77.42へ+4.9ポイント改善した。目的関数は同じままで、測定精度だけを上げた結果である。

第三に、失敗を捨てない設計が、最も希少な学習信号を回収する。失敗は「行動を直す／タスクを直す／新タスクを生む」の3パスに分岐し、原因の帰属から修復までが一貫したループとして回る。

設計面で最も重要なのは、指標を固定して課題を可変にするというベンチマークの作り方だ。飽和は「より難しいベンチマークを作る」ことではなく、離散的なメトリック体系の上でクオータをずらすことで対処する。これにより新旧ベンチマークの差分が明示され、スコアの変化をすべて帰属できるようになる。

flowchart LR
    A["クエリ生成"] --> B["実機ロールアウト"]
    B --> C["評価とルーティング"]
    C --> D["失敗の帰属と修復"]
    D --> A
    C --> E["SFTプール（静的）"]
    D --> E
    D --> F["RLクエリプール（動的）"]

制約も明確である。ループの各所には判定不能サンプルの裁定やステップ検証といった人間の関与がまだ多く、実機数百台・専用SIM・独立回線からなるファームはスマートフォンメーカーという立場でなければ持てない。リスク管理機構を回避するタッチ軌跡の注入は倫理的に議論の余地があり、独自ベンチマークの87.4という値はその設計意図への適合度を含む。外部との比較可能性が高いのはAndroidWorldの84.9のほうである。

それでも「訓練・失敗データの救済・評価のループ全体を実機に接地させることが、能力の配備への転移を可能にする」という主張は、アブレーションの数字で裏付けられている。次に注目すべきは、著者自身が挙げる次の一手——ループから人間の関与をどこまで減らせるか、である。

参考資料

• 論文（arXiv）: https://arxiv.org/abs/2609.12394
• 論文 HTML 全文: https://arxiv.org/html/2609.12394v1
• プロジェクト GitHub（vivo-ai-lab/BlueLM-GUI）: https://github.com/vivo-ai-lab/BlueLM-GUI
• ベンチマークデータセット（vivo-ai/MobileGUI-VBench）: https://huggingface.co/datasets/vivo-ai/MobileGUI-VBench
• AndroidWorld（Google Research）: https://github.com/google-research/android_world
• MetaのパーソナルAIエージェント「Muse」解体新書: https://gotosocial.chinng-lab-srv.dev/meta-muse-personal-ai-agent-sentinel-security-architecture/
• LLMエージェントを「重み」ではなく「状態」で進化させる——AutoFyn: https://gotosocial.chinng-lab-srv.dev/llmezientowo-zhong-mi-dehanaku-zhuang-tai-dejin-hua-saseru-autofyngashi-sufei-parametoritukuexpert-iteration/
• Armが描くエージェント型AI時代の全貌: https://gotosocial.chinng-lab-srv.dev/arm-agentic-ai-css-mobile2-neoverse-n4-physical-ai/
• Hacker News「Show HN: Cua-Bench」: https://news.ycombinator.com/item?id=46768906

関連記事

• Armが描くエージェント型AI時代の全貌：モバイル・クラウド・ロボティクスを貫く3大新基盤と半導体エコシステムの地殻変動