スマートフォンの画面を見ながら音声指示を聞き、動画のある瞬間を待ってからボタンを押すAIを思い浮かべてみよう。このように画面を見て人間の代わりにアプリを操作して仕事をこなすAIをGUIエージェントと呼ぶ。最近、この種のエージェントは、スクリーンショット・音声・動画・操作履歴が一度に流れ込んでくる環境で動いている。複数種類の情報が同時に入ってくるこうした環境をオムニモーダルと呼ぶ。
これまでの定石は、毎ステップこのすべての入力を一度にモデルへ投入し、何が重要かはモデルに任せて選り分けさせることだった。FocusGUIは入力を減らさない。その代わり、基盤モデルは固定したまま、各段階でどの情報にまず注目すべきかを学習する小さな補助部品を一つ載せる。南洋理工大学(NTU)とアリババグループの研究チームは、従来の定石が長い作業でなぜ崩れるのかを実測で示し、この部品を提案した。
次の行動の手がかりが、必ずしも今の画面の中にあるとは限らない。突然の通知音が瞬時に文脈を変えることもあれば、ライブ映像の切り替わる瞬間がクリックのタイミングを決めることもあり、音声指示は画面の変化とずっと結びつけ続けなければならない。これらすべてを毎ステップ一律に流し込むやり方が、問題の根っこにある。
著者らはこれを実際に測った。Qwen2.5-Omniという基盤モデルで情報の種類を一つずつ抜いていきながら、正解行動に対するモデルの対数尤度(正解をどれだけもっともらしいと見なすかを表すスコア)がどう変わるかを見た。ある情報を抜いたときスコアが下がれば、それは役に立っていたということであり、逆に上がればそれは邪魔者だったという意味になる。
| 観察 | 数値 | 意味 |
|---|---|---|
| 最も重要な情報源が直前のステップから入れ替わる割合 | 45.3% | 重要なものはステップごとに変わる |
| そうした入れ替わりを一度以上経験した作業 | 94.0% | ほぼすべての作業が経験する |
| 邪魔になる情報が一つ以上混ざったステップ | 90.1% | 毎ステップに余計なものが混じる |
| 押すべき対象が占める画面面積(中央値) | 0.87% | 重要なものはごく一部に集中している |
| 1ステップで動画が実際に変化する量(中央値) | 7.41% | 動画もほとんどはノイズである |
数値は一つの方向を指している。「今重要な情報」は観察に固定された性質ではなく、ステップごとに変わり、しかも一つのステップの中でもごく一部にだけ集中している。ところがモデルは、毎ステップ何の案内もないまま、観察全体から何が重要かを自力で改めて探さなければならない。
ここにもう一つ、構造的な要因が加わる。GUIエージェントは閉ループ、つまり実行した行動が環境を変え、その変わった環境が再び次のステップの入力として戻ってくる構造になっている。一度の小さな読み違いがそのステップで終わらず、時間をかけて積み重なる。ナビゲーションが一度道を間違えると、以後すべての案内が狂った現在地を基準に計算されるのと同じだ。著者らはこの累積を「逐次的注意散漫(Sequential Distraction)」と呼ぶ。
最も直感的な処方は入力を減らすことだ。実際、既存の研究は画面から関心領域だけを残して切り抜く(cropping)方式を使っていた。この「減らして与える」は二つの場所でつまずく。第一に、決定的な信号は音声・動画・デバイス状態のように、画面の切り抜きが届かない場所からも飛び出してくる。第二に、信号が画面の中にあったとしても、乱暴に切り捨てられた背景には、まさに正確な座標や入力値を押さえるのに必要な文脈が入っている場合が多い。モデルが迷うのは与えすぎたからではなく、何をまず見るべきかの案内がないからだ。
そこでFocusGUIは、入力をそのままにしておき、各段階でどの情報に注目するかの比重だけを調整する。スライド全体を覆い隠す代わりに、レーザーポインターで今見るべき一点だけを照らす発表者を思い浮かべればいい。聴衆はスライド全体を依然として見ているが、視線はポインターが指す場所へ向かう。これは入力の順序を入れ替えることではなく、毎ステップどの情報を強調するかを調整する作業だ。
このポインターの役割を果たすのがアダプターだ。基盤モデルには手を付けず、その外側に付け足す小さな部品で、基盤モデルを固定したまま100万個ほどの値(パラメータ)だけを学習する。動作は三段階だ。先ほどのスマホの状況、つまり通知音が鳴って今すぐ送信ボタンを押すべき瞬間に当てはめるとこうなる。
技術的な読者への注記 — 1段階目のスコアはソフトマックス(複数のスコアを合計1の比率に変える計算)で正規化され、分けられたチャンネルには基盤モデルの統合隠れ状態(観察全体を一塊に要約した内部表現)まで含まれる。3段階目の「足し算」は元の信号をそのまま残して上に重ねる残差注入だ。別個の予測ヘッドも、出力語彙の修正も、プロンプトに差し込むテキストヒントもない。
学習は軽い。どの情報が重要かを一つひとつラベル付けしたりはしない。ただ「次に取る行動」一つだけを正解として与える。その正解をより正しく当てるよう補助部品だけを学習する過程で、何を強調するか・どう要約するか・その要約をモデルの表現へどう移すかが、一つの目標のもとで一緒に学ばれる。
その学習された優先順位は、作業一件(エピソード)の中で実際に並べ替わる。チャンネルが七つなら均等配分はそれぞれ14.3%だ。ところがインタラクション状態チャンネルは、開始ステップで30.9%と二倍以上を受け取りながら、仕上げの段階では7.7%まで下がる。逆に音声・動画はそれぞれ13.4%・11.3%から18.8%・18.3%へと上がる。どんな固定の重みも、この両極端を同時に作り出すことはできない。段階ごとに重み付けし直す方式だけがそれを作る。
この順序は「どの情報が重要だ」というラベルなしに、ただ行動の正解だけから生まれた。人間が重要度を指定したわけではないのに、モデルが正解をより正しく当てようと努める過程で、「いつ何にまず注目するか」が一緒に決まったのだ。
評価はOmniGUIベンチマークで行われた。29個のアプリにまたがるスマートフォン操作の集まりで、各ステップのスクリーンショットに音声・動画・行動履歴が組み合わされている。
指標を見る前に前提を一つ釘を刺しておこう。以下の数値はすべてオフライン評価(teacher-forced)だ。正解の履歴をそのまま入力として与え、その次の1ステップの正解行動を当てられるかだけを見る。エージェントが実環境で自分の予測を実行しながら軌跡を自ら作っていくときのオンライン成功率は別問題であり、この数値からは分からない。
指標は三つある。
主要な結果は、アーキテクチャの異なる四つの基盤モデル(Qwen2.5-Omni、VITA-1.5、MiniCPM-o 4.5、Baichuan-Omni-1.5)で一貫していた。
| 指標(4モデル平均) | 固定モデルの直接推論 | FocusGUI |
|---|---|---|
| 行動の種類(TM) | 31.0% | 64.2% |
| 正確な行動(EM) | 11.2% | 33.5% |
| 目標の進行(GP) | 基準 | +6.6点 |
観察。TMが31.0%から64.2%へ上がった。画面を切り抜いて入力を減らす切り抜き系(DRS-GUI・OmniParser・RegionFocus)は反対の方向を指している。これらはTMではほぼ中立だったが、EMは相対的に28%、GPは35%低く、12事例すべてでそうだった。
仮説。画面を狭めれば行動の種類ははっきりし、TMは持ちこたえる。しかし座標と入力値を固定してくれていた周辺の文脈まで一緒に消えてしまい、EMが崩れる。重要なものが特定の領域ではなく段階にかかった問題であるなら、領域をどれだけうまく整えても、その損失は取り戻せない。
切り分けにくい要因。この利得が「学習する対象が一つ増えたから」なのか、それとも毎段階で優先順位を付け直す構造のためなのかは、TMの数字だけでは分けられない。近い比較対象がGUI-Actorだ。GUI-ActorもFocusGUIと同様に基盤モデルを固定したまま追加パラメータだけを学習する。ただし二つの手法の違いを「毎段階で再優先順位付けをするかどうか」だけに絞って見ることはできない。行動を取り出す行動ヘッドと、信号を足す残差アダプターという構造も互いに異なる。再優先順位付けの効果だけを切り出すにはパラメータ数を揃えた統制比較が必要だが、著者らはこれを付録C.3・表5で行っている。そこで再優先順位付けが上乗せした分はTM +0.98点、EM +3.54点、GP +3.44点だ。再優先順位付けが寄与するという側を支えてはいるが、それは向上幅の一部であって、向上のすべてが再優先順位付けのおかげという意味ではない。
観察。EMは11.2%から33.5%へと約3倍になった。改善幅よりも目を引くのは、二つの指標の間の隔たりだ。TMの64.2%とEMの33.5%の間には、依然として大きな溝が残っている。
スマホの状況に戻ろう。通知音で文脈が変わる瞬間に「今取る行動はタップだ」と安定して選べるようになったのがTMが押さえてくれた部分だ。しかし、そのタップを送信ボタンの位置に正確に落とす、あるいは入力欄に合った値を入れる、という作業はまだしばしばずれる。このずれがEMに捉えられる。
仮説。どこで隔たりが縮まるかは分離実験が指し示している。「足す残差」を「プロンプト埋め込みを上書きする方式」に変えると、EMが5.30点、GPが5.38点下がるのに対し、TMの変化は1.20点にとどまる。元の入力を覆わずそのまま保存する設計が、選んだ行動を正確な対象・値に合わせるうえで特に重要だという意味だ。
実務に移すと、33.5%は無人の自動化にそのまま任せるには早い水準だ。繊細なステップには、人が結果を確認する検証段階を挟んでおく側に近い。
観察。GPは平均で+6.6点上がった。平均よりも「どこで」開くかが肝心だ。インタラクションが深くなるほど、つまり後半のステップへ進むほど差が大きくなった。代表例として、固定したQwen2.5-Omniは最初のステップのTM 64.79から、四番目のステップ以降(インデックス3+)で32.79と半分を失うのに対し、FocusGUIは同じ区間で最初のステップの精度の86.8%を保つ。詳細な数値は下の表にまとめた。
| 後半の段階(四番目のステップ以降、インデックス3+) | 基盤モデル(固定) | FocusGUI |
|---|---|---|
| TM維持 — Qwen2.5-Omni(最初のステップ64.79) | 32.79へ低下 | 最初のステップの精度の86.8%を維持 |
| EM — Qwen2.5-Omniの推移 | — | 38.73 → 46.72 |
| EM — 時間推論の課題 | 0.00 | 39.39 |
仮説。利得が「累積が積み重なる深さ」でのみ開くという点が、説明を絞ってくれる。この仕掛けが一律に強い予測器だったなら、深さと無関係に一定の差を保っていたはずだ。深さに比例して開くということは、これが先に述べた逐次的注意散漫を狙った仕掛けだという側を裏づける。逆に累積履歴がほとんどないInstant課題の最初の二ステップでは、両者は統計的に区別されなかった。
切り分けにくい要因。ただしこれはオフラインの観察だ。エージェントが自ら軌跡を作っていくときにも失敗の累積が実際に減るのかは、この範囲を超える問いとして残る。
課題の性格も同じ筋を補う。手がかりが複数のフレームにまたがって続くTemporalでTMの向上が37.3点と最も大きく、たいてい現在の画面に答えがあるInstantで27.8点と最も小さかった。基盤モデル間のTM格差も35.6点から13.0点へと縮まった。観察をうまく組織すれば、正しい行動の種類を選ぶことが基盤モデルの性能に左右されにくくなる、という意味に読める。
著者らが自ら線を引いている。上の優先順位の図は「基盤モデルが内部的に各情報をどう使っているか」の説明ではない。FocusGUIが自身の補助経路の中で証拠を組織する戦略としてのみ読むべきだ。理論分析でも、この残差は行動の「種類」は選べるが、正確な引数の校正は限られた形でしかできないと区別している。結果の二つで見たTM–EMの隔たりとかみ合う点だ。
残る問いは二つだ。検証はOmniGUIというスマートフォンのベンチマーク一つ(708個の作業・2,572個のステップ)でのみ行われた。画面構造と情報分布が異なるデスクトップ・ウェブへそのまま移っていけるかは、この結果だけでは分からない。また、インタラクション状態のような特定チャンネルに優先順位が大きく偏る様相が、このベンチマークの課題構成のせいなのか、より一般的なパターンなのかも追加検証が必要だ。論文が間違っているというのではなく、他のドメインでそのまま成り立つと仮定するな、という戒めだ。
ONTLEは、人を増やしにくい小規模企業や一人起業家の反復業務を、AI PMを派遣するように代わりに処理してくれるサービスだ。
毎週金曜日、顧客企業のSlack・メール・シートに散らばった資料を集めて一つのレポートにまとめ、指定フォルダへアップロードする業務を思い浮かべてみよう。自動化が滑る地点はたいてい決まっている。まとめの段階で鳴り続ける新しい通知を資料と取り違えて引き込むと、その汚染された中間稿が公開の段階へ渡り、見当違いの最終稿がアップされる。最後になって「なぜ成果物が変なんだ?」となる場所だ。
ここでこの論文から持ってくるのは結論ではなく、一つの実験仮説だ。段階ごとに「今見るべき資料」の優先順位が異なり、その優先順位を明示してやれば中間汚染が減りうる、という仮説。
注意すべき制約が一つある。FocusGUIのアダプターは基盤モデルの内部表現を読み、行動の直前の位置に信号を足す。つまりモデルの内部にアクセスできて初めて動作する。ONTLEの業務自動化はたいてい、そうした内部アクセスなしにプロンプトと業務指針のレベルで行われる。だから、論文のアダプターをそのまま移植することと、「段階別の優先順位」というアイデアだけを業務指針に移して試すことは、まったく別の作業だ。我々にできるのは後者だ。
その仮説を検証するには、二つを別々に切り離して試すほうがよい。一つは段階別の情報優先順位、つまり各段階で「今見るべき資料」を明示すること。もう一つは中間結果の検証、つまり段階ごとに中間稿を確認するゲートを置くことだ。それぞれを別々にオンにしてみて、最終成果物の誤り率と、手戻りとして戻ってくる回数がどう変わるかを見る。二つを混ぜると、どちらが失敗を減らしたのか切り分けられない。
我々はまだこの方法をONTLEの課題に適用したことがない。だからこれは論文が証明した結論ではなく、診断から引き出した仮説であり、導入する前に我々の課題・我々のツールの分布で小さな標本でまず測ってみるのが順序だ。
この論文の比較対象は、基盤モデルを固定した四手法(DRS-GUI、OmniParser、RegionFocus、GUI-Actor)だ。全体ファインチューニングとの直接比較の数値はこの抜粋の範囲にないので断定はしない。設計思想だけは明確だ。元のパラメータを変えず、読み方だけを条件づける非侵襲(non-intrusive)なアプローチを志向している。
設定によって異なる。境界ウィンドウはKを1から16まで16倍に広げても指標が2〜3点の範囲ではっきりした傾向なく動く程度で、ゆったり取っても敏感ではない。一方、圧縮次元は事情が違う。32〜256の8倍の範囲で小さく絞りすぎると性能が折れ、64から32へ減らすとEMが6.9点、GPが6.5点下がる(表3・§3.4)。境界ウィンドウは大きく手間をかける必要はないが、圧縮次元は小さく取りすぎないほうが安全だ。
本文で触れたとおり、この方式は基盤モデルの統合隠れ状態を読み、行動を作る直前の埋め込みの位置に信号を足す。だから「重みを変えられない制約」と「内部をまったく見られないブラックボックスAPI」は別の話だ。重みは固定していても内部表現にアクセスさえできれば動作するが、後者にはこの構造をそのまま載せるのは難しい。