2026-09-03·★ 会員·論文·19分で読めます

論文解説: UI-Venus-2 — 画面を見て操作するAIを、ベンチマークから実運用へ

スマホ・ブラウザ・デスクトップを画面だけ見て操作するGUIエージェント UI-Venus-2 の技術報告書を、前提知識ゼロから解説。環境・タスク・検証を同時に広げる設計と、その限界までを論文本文だけを根拠に読む。

#gui-agent #agents #reinforcement-learning #distillation #multimodal

対象imageタスクagents

UI-Venus-2 Technical Report

一次資料 — この記事の根拠

論文の発表 2026-08-27→この解説の公開 2026-09-03同月

UI-Venus-2 Technical ReportVenus Team, Zhuohan Cai, Haoxing Chen ほか · 2026-08-27 · v1arXiv:2609.00028論文ページ·PDF

原文の要旨（Abstract）を読む

Multimodal GUI agents have emerged as a promising paradigm for digital task automation, yet transitioning from benchmark-oriented models to dependable real-world applications remains challenging due to limited environment coverage, brittle task construction, and unreliable reward verification. In this work, we present UI-Venus-2, a general-purpose foundation GUI agent designed to operate across mobile, web, and desktop environments through a unified closed-loop reasoning-action framework. To bridge the gap toward practical deployment, we jointly scale three critical dimensions: (1) Environments, expanding coverage to more than 170 multilingual mobile apps and native desktop operating systems; (2) Tasks, employing a deep-research pipeline for function-grounded instruction generation; and (3) Verification, adopting trace-level and sample-level evaluators with visual keypoints and multi-model voting to ensure reliable RL signals for training. Furthermore, we integrate safety-aware mechanisms to ensure controlled execution of consequential actions. By offering a capable, efficient, and open-source foundation, UI-Venus-2 advances the field toward more generalizable, verifiable, and self-reflective agents for real-world applications.

この記事で読む論文

原題は "UI-Venus-2 Technical Report"（Venus Team, Ant Group、arXiv:2609.00028、2026年8月27日公開）。検索・引用はこの英語の原題で行ってください。

要旨を日本語でまとめます。画面を見て操作するマルチモーダルGUIエージェントはデジタル作業の自動化として有望だが、ベンチマーク向けモデルから「実際に頼れるアプリケーション」へ移るのは難しい。理由は3つ、環境のカバー範囲の狭さ、タスクの作り方のもろさ、報酬検証の当てにならなさである。そこで本論文は、モバイル・Web・デスクトップを一つの「観察→推論→行動」の閉ループで扱う汎用基盤GUIエージェント UI-Venus-2 を提示する。実運用との差を埋めるため、(1) 環境を170以上の多言語モバイルアプリとネイティブなデスクトップOSまで拡張し、(2) タスクをdeep-researchパイプラインでアプリの実機能に紐づけて生成し、(3) 検証をトレース単位とサンプル単位の評価器＋視覚的キーポイント＋複数モデルの投票で行う、という3方向を同時にスケールさせた。さらに影響の大きい操作を制御する安全機構を組み込み、モデルをオープンソースとして公開する。

たとえ話: 新人オペレーターを本番に出すまで

事務作業を代行する新人を育てる場面を考えてください。育てる側の仕事は3つです。触らせる環境を増やす（1つの業務システムしか知らない人は別のシステムの前で固まる）。実在する機能に紐づいた課題を作る（「適当にやってみて」では育たない）。そして正しく採点する。最後が一番地味で一番重要です。採点がいい加減だと、新人は業務ではなく「採点者に丸をもらう方法」を覚えます。

論文の主張はまさにこれで、環境・タスク・検証を別々ではなく同時に広げないと、ベンチマークの点数は上がっても実運用には届かない、というものです（§1）。

なぜ「次の1手の精度」では足りないのか

GUIエージェントはAPIではなく描画された画面を見て、クリック・入力・スクロールという人間と同じ操作で動きます。APIが用意されていないアプリも自動化できるのが強みです（§1）。

論文は行き詰まる理由をこう整理します。第一に、環境は「少数のアプリ」から多言語モバイル・動的なWeb・フルのデスクトップOSまで広げる必要がある。第二に、環境を増やせばタスクの自動生成が要るが、生成された指示がそのアプリで本当に実行可能でなければ意味がない。第三に、強化学習は検証器の質を超えられない。粗い検証器は途中まで進んだだけの軌跡を「完了」と誤認し、方策につけ込まれる報酬信号を露出させます（§1）。この現象は報酬ハッキングで扱っています。

土台のモデルと、推論時の設定

UI-Venus-2 はオープンな基盤モデル Qwen3.5-9B と Qwen3.6-27B から初期化された9B版・27B版の2サイズです。学習は Grounding（画面上の要素を正確に指す）・CAPTCHA・Mobile・Web・Computer の混合で、論文はこれを意図的な補完関係だと説明します。Groundingが細かい空間認識を、CAPTCHAが検証可能な相互作用の教師信号を、Mobile/Web/Computerが実環境のナビゲーション経験を供給する分担です（§2.1）。

推論設定も実務的に重要です。一般のエージェント課題ではサンプリング温度1.0、思考（think）モード有効、推論履歴を文脈に戻して多段の一貫性を保つ。一方、GUI grounding では思考モードを切り温度を0にする——位置を当てるだけなら迷わず一発で出すほうがいいからです（§4.1.1）。温度が分布に何をするかは、下の図を触ってみてください。

FIG 1温度を0に近づけると出力は決め打ちになり、上げるほど候補が散らばる。UI-Venus-2はgrounding時に温度0、一般のエージェント課題では1.0を使う（§4.1.1）

3段階の学習パイプライン

学習レシピは3段階です（§2.2〜§2.4）。

第1段階: マルチモーダル中間学習。 Mobile / Web / OS のナビゲーションを中心に、合成データと相互作用データの大規模な混合で学習します。集めた軌跡は人間の検査と自動評価を組み合わせた協調的な検証にかけ、無効・曖昧・低品質なものを落とします（§2.2）。

第2段階: オフライン強化学習。 Mobile / OS / Web はステップ単位のRL軌跡を大規模に作り、1手ごとの教師信号で状態を踏まえた行動選択・多段ナビゲーション・遷移の一貫性を最適化します。CAPTCHA と Grounding は実データではなくプログラム合成を使い、正解が確定した課題を現実的なページやアプリの背景に埋め込む。合成なので行動レベルの正誤が確実に取れ、難易度も制御できる——自然収集では得にくい密なRL信号が作れる、というのが論文の論理です（§2.3）。

第3段階: マルチ教師オンポリシー蒸留（MOPD）。 ドメインごとの専門モデルを1つの方策に統合します。独立に学習した専門家をそのまま合成すると干渉が起きるため、学生自身がサンプリングした軌跡を教師が採点するオンポリシー蒸留の形をとります（§2.4）。手法自体はオンポリシー蒸留にまとめてあります。

「行動トークンだけを強く直す」という工夫

素朴なオンポリシー蒸留は応答全体に一様な教師信号をかけます。しかしGUIエージェントで環境に触れて状態を変えるのは行動（action）だけ。応答の大半は推論の文章で、行動は短い。トークン頻度に比例して信号を配ると、肝心の行動が薄い監督しか受けません（§2.4）。

しかも行動には内部構造があります。行動タイプがパラメータの意味を決める——Click なら座標に意味があり、Scroll を誤って選んだ時点でその座標には意味がない。論文はこの非対称性に合わせ、蒸留信号を学生の行動の正しさで条件付けます（§2.4）。

w_t=\begin{cases} 0 & \text{行動が完全に正しい}\\ \uparrow\ (\text{行動スパンを強調}) & \text{タイプは正しく、パラメータが誤り}\\ \uparrow\ (\text{タイプを強調})+\text{パラメータをマスク} & \text{タイプが誤り} \end{cases}

(1)

この式が言っているのは要するに、「学生の行動がどう外れたかによって、直す場所と強さを変える」ということです。トークンの数に比例して均等に直すのではなく、行動が外れた種類に応じて重みを付け替えます。

式(1)は論文が文章で述べる3つの場合分けを重み $w_t$ に書き直したものです。 $w_t$ は $t$ 番目のトークンにかける蒸留信号の強さを表します。正しければ直さない、タイプは合っていて座標だけずれているなら行動の部分を強く直す、タイプ自体が違うならタイプを直しパラメータは無視する——この3行が本質です。

教師側にもう一工夫あります。教師のプロンプトにだけ正しい行動タイプのヒント $h(z^{*})$ を付ける。ヒントは学生のプロンプトには決して入らず推論時にも使えません。教師は自分で応答を作らず、学生が出したトークンの採点の仕方を調整するためだけにこれを使います（§2.4）。