X-PLUG のオープンソース Mobile-Agent は、もはや単なるスマホ自動化プロジェクトではない。現在のリポジトリの位置づけでは、Tongyi Lab が GUI エージェントをめぐって積み重ねてきた一連の仕事に近い。Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl、ToolCUA などが同じ体系で示されている。
この流れは注目に値する。以前の GUI agent の議論では「モデルがスクリーンショットを理解し、正しい場所を押せるか」がよく問われた。Mobile-Agent の進化はさらに進み、エージェントがモバイル、デスクトップ、ブラウザ、ツール利用の間を切り替え、より長く複雑な実タスクを扱う方向へ向かっている。
何を解決するのか
GUI エージェントが向き合うのは標準 API ではなく、アプリケーション画面だ。画面を理解し、部品を見つけ、手順を計画し、タップや入力を行い、失敗したら経路を修正する必要がある。モバイルは特に複雑で、タスクが複数 App をまたぎ、画面状態もログイン、権限、ポップアップ、ネットワーク、個人化推薦によって変化する。
Mobile-Agent シリーズはこの問題をいくつかの方向に分解している。
- Mobile-Agent-v1/v2 でスマホ GUI の視覚認識とマルチエージェント協調を探索する。
- PC-Agent でマルチエージェント操作を PC に拡張する。
- Mobile-Agent-v3 と v3.5 でマルチプラットフォーム GUI エージェントフレームワークを進める。
- GUI-Owl 系列モデルでクロスプラットフォーム GUI 認識、grounding、エンドツーエンド操作を提供する。
- GUI-Critic-R1、UI-S1、ToolCUA などでエラー診断、強化学習、GUI/ツール経路の編成を補う。
そのため、単一のデモというより、「コンピューター使用エージェント」をめぐる研究・エンジニアリング路線に見える。
v3.5 の重点
README によると、Mobile-Agent-v3.5 は ModelScope のオンライン Demo と Alibaba Cloud Bailian のオンライン Demo で試せる。Bailian では v3.5 API も提供されている。2026 年 3 月には v3.5 が Alibaba Cloud Wuying cloud phone にも載り、クラウド Android 環境でモバイル利用体験を提供している。
これは、プロジェクトが「ローカルで実験する」以外の利用形態も補っていることを示す。GUI エージェントにとって、クラウドスマホとクラウドデスクトップは重要だ。より安定し再現可能な実行環境を提供し、ローカルデバイス、OS バージョン、解像度、App 状態の差を減らせる。
この種のエージェントを評価するなら、安定した環境は過小評価されがちだ。制御可能な実行環境がなければ、失敗がモデル能力不足、画面変化、デバイス問題、タスク定義の曖昧さのどれに由来するのか判断しにくい。
GUI-Owl は土台の変化
Mobile-Agent-v3 以降、GUI-Owl はこの路線の重要なモデル層になった。README では GUI-Owl を、GUI 認識、grounding、エンドツーエンド操作能力を備えたマルチモーダルなクロスプラットフォーム GUI VLM と説明している。GUI-Owl-1.5 では、2B、4B、8B、32B、235B までのモデル系列を持ち、デスクトップ、モバイル、ブラウザ自動化をサポートする。
この種のモデルの意味は、「画面に何があるか」を答えるだけではない点にある。自然言語の目標、スクリーンショット内容、UI 要素の位置、次の操作をつなげなければならない。GUI agent には視覚理解、座標 grounding、操作計画、状態記憶のすべてが必要だ。
もちろん、モデルが汎用になるほど、エンジニアリング上の境界も重要になる。実運用では実行器、権限制御、タスクログ、ロールバック、人間の確認が依然として必要だ。特に支払い、アカウント、ファイル、メッセージ送信など高リスク操作では、GUI agent は自動完了だけでなく、何をしようとしているのかを明確に説明できなければならない。
ToolCUA が示す新しい方向
2026 年 5 月、プロジェクトニュースでは ToolCUA が言及された。GUI とツールの最適経路を編成するエンドツーエンド Computer Use Agent と位置づけられている。この方向は興味深い。すべてのタスクを画面クリックで完了すべきではないという現実を認めているからだ。
管理画面へのログイン、複雑なフォーム処理、API のないアプリ状態の読み取りには GUI 操作が向いている。一方で、検索、計算、ファイル解析、構造化インターフェースへのアクセスはツール利用が向いている。本当に使えるコンピューター使用エージェントは、この2つを切り替えられる必要がある。
ここが Mobile-Agent シリーズを初期のスマホ自動化プロジェクトより面白くしている。もはや「エージェントが人のように App をタップできるか」だけでなく、「いつ画面を見るべきか、いつツールを使うべきか、いつ止まって確認すべきか」を問うている。
誰が注目すべきか
すぐ使えるスマホ自動化アシスタントを探しているだけなら、Mobile-Agent はまだ研究・エンジニアリング寄りのフレームワークだ。モデル、実行環境、評価タスク、具体的な実行器が絡み、完整に動かすには設定コストがある。
ただし、次のような問題に関心があるなら追う価値がある。
- モバイル GUI agent がデモから安定実行へどう進むか。
- デスクトップ、ブラウザ、スマホ自動化を同じエージェントフレームワークに統一できるか。
- GUI モデルが grounding、反省、記憶、エラー診断をどう扱うか。
- エージェントが GUI 操作とツール利用の間でどう経路を選ぶか。
- クラウドスマホやクラウドデスクトップが GUI agent の重要な実行環境になるか。
これらは個人アシスタント、企業ワークフロー自動化、リモートデスクトップ操作、アプリテスト、API のないシステム統合に直接関わる。
私の見方
Mobile-Agent の価値は、あるバージョンの指標ではなく、GUI エージェントを「スマホのスクリーンショットを見て押す」段階から、モデル、実行環境、評価、ツール利用、エラー診断、クロスプラットフォームタスクがどう協調するかという大きなシステム問題へ進めた点にある。
短期的には、GUI agent の技術路線を観察したい研究者や開発者に向いている。長期的には、この種のプロジェクトが個人 AI アシスタントや企業自動化ツールの形を変える可能性がある。本当の難しさは、エージェントに画面を操作させることだけではなく、実アプリ内で安定し、制御可能で、追跡可能な形でタスクを完了させることだ。
プロジェクトリンク：X-PLUG/MobileAgent