ソフトウェアを一度もインストールせずに、そのソフトウェアを操作するAIを教えられるだろうか。AutoGUIWorldは「できる」と答える。
核心は、画像生成モデルを一風変わった使い方をした点にある。ふつう画像生成モデルは絵を描くために使う。この研究はそれを「ある操作をすると画面がどう変わるかを描き出す道具」として転用した。そこに作業手順を組み立てる設計者(プランナー)を組み合わせ、実際のプログラムを動かさずとも「画面を見てクリック・入力する」練習記録をまるごと作り出す。こうして合成した疑似的な練習データでAIを追加学習させたところ、本物のコンピュータ操作と科学タスクの成績が目に見えて上がった。
GUIエージェントとは、人間のように画面(スクリーンショット)を見てマウスを動かし、キーボードを打ってソフトウェア操作を自動化するAIだ。ところが、ボタンの位置を覚えるだけでは足りない。「このボタンを押すと画面がどう変わるか」「何が残り、何が消えるか」「前の手順が後の手順をどう制約するか」といった感覚を身につけなければならない。この感覚は、成功した操作の記録 — スクリーンショットから行動へ、そして変化したスクリーンショットへとつながる「軌跡」 — を大量に見ることで養われる。
問題は、この軌跡を「いま動いているソフトウェア」からしか集められない点だ。エージェントが遭遇しうる画面状態や作業フローは、インストールされているソフトウェアが何かに完全に縛られる。カバレッジを広げようとすれば、結局は新しいソフトウェアをインストールし、設定し、作業環境を整え、毎回同じように再現できるよう維持しなければならない。CADや科学計算、電子設計(EDA)のような専門ソフトウェアほど、インストール依存関係や実行要件がまちまちで、ライセンスやアカウントの制約まで付いて回る。環境を一つひとつ構築して維持するコスト、それ自体が学習の本当のボトルネックだ。AutoGUIWorldの出発点は、このコストをまるごと飛ばしてしまおうというものだ。
この論文の巧みさは、データ作りを二つの層に分けた点にある。「何が起きるべきか」(計画)と「ではその結果、画面がどう見えるべきか」(描画)を切り分けた。映画にたとえるなら、脚本を手にした監督がシーンの展開を決め、撮影チームがそのシーンを一コマずつ撮るのだが、各コマが直前のコマを受け継いで撮られる、という構造だ。
表計算ソフトで特定のセルの文字色を変える、という作業ひとつで流れを追ってみよう。
こうしたやり方で、4つのプラットフォーム(Ubuntu・Windows・macOS・Chrome)にわたって79,266個のステップ単位の学習サンプルを生み出した。
ここで最も重要な概念が「インタラクション忠実度(相互作用の忠実さ)」だ。もっともらしく見える画面と、実際のシステムが本当に生成するであろう画面は違う。書式ダイアログを開いたなら、その背後の表はそのまま保存されていなければならないし、B2の一セルの色だけを変えたなら、残りのセルは手つかずのままでなければならない。画像生成器が、単に見栄えのいい絵を出すのではなく、レイアウト・スタイル・背景・見えている内容を保ったまま、指定された変化だけを反映する「行動に応じて状態を変えるモデル」として機能しなければならない、ということだ。そうしてこそ、生成された記録が互いに無関係なスクリーンショットの寄せ集めではなく、前後の辻褄が合う「画面-行動-画面」の連鎖になる。
このアプローチの根底には、一つの賢い割り切りがある。論文は、エージェントがシステムの本当の状態をすべて見られるわけではなく一部しか観測できない、という枠組み、すなわち部分観測モデル(POMDP)でこの状況を説明する。かみ砕けば、霧の中で運転する人に近い。ドライバーは道路全体の設計図も、エンジンの内部も見えないまま、目の前の車線と標識だけで次の行動を決めなければならない。コンピュータも同じだ。本当の状態は、OSの中、アプリの中、ファイルシステム、目に見えない内部の値まですべてなのに、エージェントはそのうち「画面」一枚しか見ない。この論文の要点は、霧を払って本当の状態を復元しようと苦労する代わりに、「見える画面」が次の「見える画面」へどう変わるかだけをもっともらしく描き出すことに集中した、という点にある。おかげで、作られた記録は一ステップずつ切り出して学習データに使え、学習の際に生成器を傍らに置いておく必要もない。
いちばん気になるのはこれだ。本物のソフトウェアを一度も動かさずに作ったデータで、エージェントは実際に仕事をうまくこなせるようになるのか。
研究チームは、合成した記録である大規模言語モデルをファインチューニング(すでに出来上がったモデルを特定のタスクに合わせてさらに訓練すること)したうえで、実環境で動かした。選んだモデルはQwen3.5-35B-A3Bだ。4つのベンチマークすべてで成績が上がり、そのうち2つに具体的な数値が示されている。クロスプラットフォームのデスクトップ操作を測るOSWorldでは平均タスクスコアが33.0%から40.8%に上がり、科学ワークフローを測るScienceBoardではタスク成功率が14.0%から32.2%へと2倍以上に跳ね上がった。
この二つの数値を一緒くたにしてはいけない。OSWorldは「平均タスクスコア」、ScienceBoardは「タスク成功率」で、指標そのものが違う。「平均で何ポイント向上」といった形でまとめると、誤りになる。それでも方向性ははっきりしている。実際のソフトウェアなしで合成した練習データが、本物のデスクトップ・科学タスクの実測性能を引き上げた。
ただし、この数値が証明できないこともある。合成された画面は「見えるもの」(ウィンドウ配置、内容、スタイル)しか収めず、ファイルシステムの中身やアプリ内部、ブラウザ内部の構造といった「見えない状態」は収められない。見える画面だけをモデリングすると決めた設計の代償だ。そのため本物のバックエンドがなく、「クリックが実際に請求書を正しく登録したか」といった機能的な正解を確かめる術がない。実行可能な環境に検査装置(verifier=結果が正しいかを検証する仕掛け)を組み込む方式と袂を分かつのが、まさにここだ。その方式は正解かどうかを検証できる代わりに、環境を配備・設定するコストをすべて支払わねばならず、AutoGUIWorldは検証可能な正解の一部を手放す代わりに、広いカバレッジを安く手に入れる。両者は競合というより、互いを補い合う関係だ。
もう一つ。このパイプラインは「設計者の計画は正しい」という前提の上に成り立っている。計画が誤った順序を組めば、画像生成器はその誤った計画さえ滑らかに、もっともらしく描き出してしまう。間違っているのに、見た目には完璧な記録が出来上がるわけだ。品質管理は、おかしく描かれたシーンは取り除くものの、計画そのものの体系的な誤りまで捕まえられるという保証ははっきりしない。性能の数値もまた、特定の一モデルから得られた結果であり、別の規模・系統のモデルでも同じになるかは、この研究だけでは断定しにくい。
性能とは別に、研究チームは「合成データが実データと分布のうえでどれだけ近いか」も複数の角度から測った。結論から言えば、かなり近かった。ただし近いことが性能を保証するわけではない — だからこそ、先の性能数値と以下の分布数値は分けて見る必要がある。
比較の基準となった「本物」のデータは、実際のGUIから集めた6つのまとまり(ScaleCUA, AgentNet, aria_ui, WebSTAR, Mind2Web, OS-Atlas)で、そのうち解像度が合成データに最も近いScaleCUAが主な比較相手だ。測定には4つのものさしを用いた。
弱点も数値に表れる。最も見劣りするのはUbuntuだ。同じ内容の領域どうしをそろえて比較したとき、広い単色の背景では見分けテストのAUCが0.65と、生成の痕跡が最もはっきり出た。逆に、文字やアイコンの断片はUbuntu・WindowsでAUC 0.44~0.57と、ほとんど見分けられなかった。小さな文字やアイコンは実物と区別がつかないのに、広い背景では生成モデルの素性が残ってしまう、というわけだ。
ONTLEのAI PMが、顧客企業でよく出くわす場面がある。ある顧客が、社内ERPや専用の管理コンソールの繰り返し作業を自動化してほしいと言う。ところが、そのコンソールを扱えるエージェントの学習データは、世の中に存在しない。かといって顧客企業のERPをまるごと複製してサンドボックスを立てるのは、ライセンス・個人情報・運用リスクが一度にのしかかる。まさにここが、先に述べた「環境コストのボトルネック」だ。
この研究は、そのボトルネックを攻略する新しい選択肢を与えてくれる。ONTLEはこの技術で、顧客企業のコンソールの安価な「デジタルツイン(実物を模した仮想の複製)」を作れる。実際のコンソールのスクリーンショット数枚から出発し、その画面のテーマ・レイアウト・状態をシードとして取り出し、その上で筋の通った作業を生成し、設計者がクリック・入力の順序を敷き、画像生成器が次の画面を描き、グラウンディングが押す座標を打つ。こうして集めた合成記録でエージェントをあらかじめ訓練すれば、実際のシステムに手を付ける前に「画面を読み、どこを押すか」という基礎力を、かなりの部分まで養っておける。本物のシステムへのアクセスと、実データでのファインチューニングは、最後に残った隔たりを埋める段階になる。高価な実環境をまるごと立てる代わりに、投入前に練習させる「模擬訓練所」を安く建てる、というわけだ。
もちろん、線引きははっきりさせておかねばならない。この模擬訓練所には、本物のバックエンドがない。顧客の実際のDBで、お金がきちんと振り込まれたか、伝票が正しく登録されたかを、この中では確認できない。見える画面は、システムの真の値ではないからだ。だからこの技術は「知覚と操作の基礎力」を前もって底上げするのには強いが、決済やデータ変更のような取り返しのつかない実行を、これだけに任せてはならない。基礎力は合成データで素早く引き上げつつ、本番の実行は実環境での検証と冪等設計(同じ操作を何度押しても、結果が一度押したのと同じになるようにする安全装置)で支えなければならない。まとめると、この研究はONTLEに「安くて速い模擬訓練所」を手渡してくれるのであって、実戦の承認ゲートをなくしてくれるわけではない。
本記事が参照した公開資料の範囲では、データ公開の有無は確認できていません。正確な点は、以下の参考資料のarXiv・HuggingFaceページをご確認ください。
論文では画像生成モデルのgpt-image-2を使います。現在のスクリーンショットを下絵として次の画面を描き出す方式(image-to-image)で、その役割は「行動に応じて画面の状態を変えるモデル」です。
画面一枚には、スクロール位置、開いているダイアログ、入力途中の文字、動的に変わるページ内容といった文脈がすべて収まりきらないからです。次の行動を適切に選ぶには、過去の画面と行動の履歴にまで条件を課す必要があります。