AIでスマホを自動操作するならどれが強い？MobiAgent、Mobile-Agent、Mobilerun、mobile-useを比較

最近、モバイル向け GUI エージェントのプロジェクトを4つ続けて整理した。MobiAgent、Mobile-Agent、Mobilerun、そして mobile-use だ。どれも「AI にスマホやモバイル App を操作させる」ことに関係しているが、立ち位置はかなり違う。

簡単に言うと、MobiAgent はカスタマイズ可能なスマホエージェント研究システムに近い。Mobile-Agent は Tongyi Lab が GUI agent を軸に展開している一連の研究成果だ。Mobilerun は実運用しやすいローカル/クラウドのモバイルデバイス制御フレームワークに寄っている。mobile-use は実アプリ操作、タスク分解、データ抽出、AndroidWorld 評価を重視している。

基本情報の比較

MobiAgent

MobiAgent は IPADS-SAI のプロジェクトで、カスタマイズ可能なスマホエージェントシステムとして位置づけられている。単なる実行スクリプトではなく、MobiMind モデルファミリー、AgentRR のアクション記録と再生、MobiFlow 評価ベンチマーク、スマホ runner、データ収集、Android app をひとつの体系にまとめている。

特徴は、研究システムとして比較的完整であることだ。MobiAgent は実際のスマホタスクにおける精度、効率、記憶、再利用可能なアクション列に注目している。README にあるユーザープロファイル記憶、経験記憶、アクション記憶、マルチタスク実行は、長期タスクや反復タスクを扱おうとしていることを示している。

一方で、導入のハードルは高い。完整に動かすには、デバイス、ADB、モデルデプロイ、依存環境、任意のベクトルデータベースやグラフデータベース設定が必要になる。一般ユーザー向けの「インストールしてすぐ使える」スマホアシスタントというより、研究やエンジニアリング実験に向いている。

何を解決するのか

スマホ GUI エージェントは、Web やデスクトップの自動化より面倒だ。スクリーンショットを理解し、UI 部品を識別し、次の操作を決め、ADB やモバイル実行環境を通じてタップ、入力、戻る、アプリ切り替えを行う必要がある。実際のタスクは単一 App 内の一回の操作ではなく、検索、買い物、SNS、支払い、地図など複数アプリをまたぐ連続した流れになりやすい。

MobiAgent はこれらを体系化する。

• MobiMind がタスク計画、意思決定、画面上の位置特定を担う。
• runner がスマホに接続し、ADB で定義済みタスクを実行して軌跡を記録する。
• AgentRR が成功したアクション列を再利用し、反復タスクの推論と操作コストを下げる。
• MobiFlow が実際のモバイル場面でのタスク完了を評価する。
• データ収集、アノテーション、処理ツールがモバイル GUI タスクデータの構築コストを下げる。

そのため、単なるデモ用モデルではなく、モバイルエージェントの実験基盤に近い。

最近の更新

README によると、MobiAgent は 2025 年 8 月に公開され、その後モデル、Runner、メモリシステム、端末側実行能力を継続的に補っている。2025 年 12 月からはスマホ上の純粋な端末側推論をサポートし、MobiAgent、UI-TARS、AutoGLM、Qwen-VL、Gemini などを設定できる統一 GUI agent runner も公開した。

2026 年 3 月には GUI-based mobile “claw” MobiClaw と新しい MobiMind-1.5-4B モデルも公開された。論文再現だけでなく、モバイル実行、モデル能力、操作ツールチェーンをよりプロダクトに近い方向へ進めていることがわかる。

メモリシステムが重要

MobiAgent はユーザープロファイル記憶、経験記憶、アクション記憶をサポートする。ユーザープロファイル記憶は計画に好みの文脈を与え、経験記憶は類似タスクの実行経験を検索し、アクション記憶は AgentRR によって成功したアクション列をキャッシュして再利用する。

これは重要だ。スマホタスクには反復性がある。ユーザーは同じ App で商品を検索したり、決まった連絡先を開いたり、特定ページに情報を入力したりする。毎回ゼロから画面を見て、計画し、タップするのは高コストで失敗もしやすい。メモリは「すでに学んだ流れ」を蓄積し、後続タスクを速く安定させる。

ただし、メモリは新しいガバナンス問題も生む。ユーザーの好み、過去タスク、アプリ内の経路、操作軌跡には機密情報が含まれる可能性がある。実運用では、何を記憶に入れるか、どれだけ保存するか、どう削除するか、タスク間で再利用してよいかを明確にする必要がある。

誰が注目すべきか

既製のスマホ自動化 App を探しているだけなら、MobiAgent は現時点では研究・エンジニアリング寄りのフレームワークだ。モデルサービス、モバイルデバイス、ADB、依存環境、タスクファイルの設定が必要で、完整に動かすには一定のハードルがある。

一方で、モバイル GUI agent、端末側エージェント、複数モデル runner、タスク軌跡の再利用、エージェント評価に関心があるなら、MobiAgent は追う価値がある。モデル、実行、評価、データパイプラインをまとめているため、研究者や開発者がモバイルエージェントの実際の弱点を観察しやすい。

Mobile-Agent

Mobile-Agent は X-PLUG/Tongyi Lab のプロジェクトだ。このリポジトリは初期のスマホ操作エージェントから、GUI エージェントファミリーへと広がっている。Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl、ToolCUA などが同じ技術ライン上にある。

特徴は守備範囲の広さだ。Mobile-Agent はスマホだけでなく、デスクトップ、ブラウザ、クラウドスマホ、クラウドデスクトップ、GUI 認識、grounding、エラー診断、強化学習、GUI/ツール経路のオーケストレーションも扱う。GUI-Owl 系列のモデルによって、単一のモバイル自動化プロジェクトというより、クロスプラットフォーム GUI 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 のないシステム統合に直接関わる。

Mobilerun

Mobilerun は droidrun のプロジェクトで、よりエンジニアリング寄りだ。LLM agent が自然言語を通じて Android と iOS デバイスを制御できるようにする。CLI、TUI、Docker、Python API、Portal-based control、vision mode、reasoning mode、構造化出力、カスタムツール、app cards、実行トレース、クラウドデバイスサービスを提供している。

もっとも目立つ点は、モデル非依存でデプロイ形態が明確なことだ。開発者は OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter、OpenAI-compatible providers を接続できる。ローカルフレームワークや Mobilerun Cloud も選べる。実際のチームにとって、この「デバイス制御層とモデル層の分離」はかなり重要だ。

もちろん、モバイル自動化でよくあるハードルは残る。Android では開発者オプション、USB デバッグ、Portal app が必要になる。iOS は別のフローが必要だ。複雑なタスクでは権限ポップアップ、画面変化、失敗時のリトライ、ログ調査も扱う必要がある。mobile agent をエンジニアリング部品として取り込む人に向いている。

何を解決するのか

モバイル自動化で最も厄介なのは、自然言語タスクと実デバイス操作の間に多くの層があることだ。モデルは現在どの App が開いているか、ページにどの部品があるか、視覚情報としてスクリーンショットが必要か、次にどこを押すか、失敗後にどう続けるかを知る必要がある。

Mobilerun はこれらをフレームワークとして整理している。

• CLI と TUI で単発の自然言語タスク、デバイス確認、マクロ再生、デバッグフローを実行する。
• Python API でカスタムのモバイル自動化ワークフローを構築する。
• Android と iOS をサポートする。Android は Portal app とアクセシビリティ機能を使い、iOS は別の Portal フローを使う。
• accessibility tree とスクリーンショットを同時に使い、構造化 UI と視覚画面の両方をモデルに渡す。
• --vision、--vision-only、--reasoning などのモードで複雑度の違うタスクに対応する。
• 構造化出力、app cards、カスタムツール、認証情報、実行トレースをサポートする。

そのため Mobilerun は、単にスクリーンショットを大規模モデルへ送りタップを模倣するものではなく、「モバイル agent runtime」に近い。

ローカルフレームワークとクラウドサービス

Mobilerun はローカルフレームワークと Mobilerun Cloud を比較的明確に分けている。ローカルフレームワークは、自分のマシンとデバイスで agent を動かし、コードレベルの制御を得たい開発者に向いている。Cloud はホスト済みデバイス、REST API、SDK、大規模ワークフロー向けだ。

この分離は重要だ。多くのモバイル自動化は最初「スマホでひとつタスクを走らせたい」から始まるが、チーム利用になると、デバイス管理、並行実行、ログ、失敗時リトライ、権限、API 呼び出しの問題が出てくる。Cloud はローカルフレームワークを置き換えるものではなく、デバイス運用とワークフロー接続をバックエンドサービスへ進めるものだ。

README ではクラウドデバイスも、ユーザー所有ハードウェア、ホスト済みクラウドスマホ、ホスト済み実機スマホに分けている。違いはコストだけではない。アプリのリスク制御、ID の信頼性、タスク安定性にも関わる。EC、SNS、金融、ローカルサービス系 App では、実機と仮想デバイスの挙動がまったく違うことがある。

なぜ LLM 非依存が重要か

モバイル GUI agent はまだ急速に変化しており、どのモデルが長期的に最良かは言いにくい。タスクによってモデルへの要求も違う。視覚理解が重要なもの、長い計画が重要なもの、ツール利用が重要なもの、低コストの大量実行が重要なものがある。

Mobilerun がモデル非依存の路線を選ぶ価値は、デバイス制御、タスク実行、ログ追跡、モデル選択を分離できることにある。開発者はまずデバイス側フローを安定させ、その後でコスト、精度、遅延に応じてモデルを切り替えられる。

これは実運用に役立つ。企業は、あるモデルのデモが良いからといってデバイス制御層を作り直したくはない。統一した実行フレームワークを保ち、モデルを交換可能な部品として扱う方が合理的だ。

向いている場面

Mobilerun は現時点で次の用途に向いている。

• モバイル App の QA と回帰テスト。
• ネイティブ App からデータを抽出し、構造化結果を返す。
• 反復的なスマホタスクを自動実行する。
• 非技術ユーザー向けに自然言語のモバイル操作フローを包装する。
• 複数デバイス上で自動化タスクを実行する。
• スケジュール、通知、カスタムトリガーをモバイルワークフローに接続する。

ただし、「インストールしたらすぐスマホを任せられる」消費者向け助手ではない。Android 側では ADB、開発者オプション、USB デバッグ、Portal app が必要だ。iOS 側にも独自の接続フローがある。安定して動かすには、モデル設定、デバイス状態、権限ポップアップ、失敗時の復旧も扱う必要がある。

mobile-use

mobile-use は minitap-ai のプロジェクトで、AI agent に実際の Android と iOS App を使わせることを目標にしている。自然言語制御、UI-aware automation、データ抽出、複数の LLM 設定をサポートし、AndroidWorld ベンチマークでの性能を強調している。README では、AndroidWorld benchmark で 100% を達成した最初の agentic framework だとも説明されている。

強みはタスク分解と構造化抽出だ。たとえば Gmail で未読メールを探し、指定された JSON 形式で送信者と件名を返すようなタスクは、「設定を開いて電池残量を見る」よりも実際の生産ニーズに近い。mobile-use はモバイル GUI agent を「操作できる」段階から「App 内の情報を整理して取り出せる」段階へ進めている。

制約は主にデバイス対応と実行環境にある。Android は実機またはエミュレーターを使える。iOS は現時点では主に macOS 上のシミュレーター対応で、物理 iOS デバイスはまだ対応していない。Docker のクイックスタートも主に Android 向けだ。評価する際は、対象デバイスと App シナリオが現在の実行経路でカバーできるかを先に確認したい。

普通のスマホ自動化との違い

従来のスマホ自動化は、スクリプト、座標、コントロール ID、固定フローに依存することが多い。安定したページには向いているが、画面変化、ポップアップ、検索結果、リストスクロール、アプリ横断操作があると壊れやすい。

mobile-use の路線は、AI agent に自然言語目標と UI 状態を直接扱わせることだ。

• ユーザーは自然言語でタスクを説明し、各ステップを事前に固定しなくてよい。
• フレームワークがモバイル画面を読み、モデルと組み合わせて次の操作を判断する。
• App から情報を抽出し、JSON など指定形式で返せる。
• OpenAI API compatible providers を含む複数の LLM 設定をサポートする。
• Android は実機またはエミュレーターで動かせる。iOS は現時点では主に macOS 上のシミュレーター向けだ。

この種のフレームワークは「半構造化」されたモバイルタスクに向く。目標は明確だが、毎回ページ状態、データ内容、経路が完全には同じでないタスクだ。

AndroidWorld の結果に注目

mobile-use の README では、AndroidWorld benchmark で 100% の完了性能を達成したと述べ、対応する論文にもリンクしている。具体的な評価詳細はともかく、チームが「タスク分解」と「評価可能な実行」を重視していることはわかる。

これは単なるデモより重要だ。GUI agent では、動画では賢く見えても、タスク、デバイス、初期状態が変わると不安定になることがよくある。ベンチマークは実利用を完全には表さないが、標準化されたタスク群に向き合わせ、計画、定位、復旧、状態理解の能力を露出させる。

README にある論文タイトルも方向性を示している。タスク分解によって AndroidWorld の精度を高めるというものだ。モバイルエージェントでは、複雑なタスクをひとつの大きなプロンプトで直接完了することは難しく、実行可能なサブタスクへ分解し、各ステップで状態を確認する必要がある。

データ抽出が実用的な入口

mobile-use の現実的な用途のひとつは、ネイティブ App からデータを抽出することだ。多くの情報は API では公開されず、App 画面でしか見られない。メール一覧、注文状態、SNS コンテンツ、管理画面、通知などがそうだ。

README の例では Gmail を開き、未読メールを見つけ、送信者と件名を JSON に整理する。この方向は実用的だ。モバイル GUI agent を「操作を手伝う」段階から、「App 内の情報を構造化して取り出す」段階へ進めるからだ。

ただし、境界も生まれる。データ抽出はアカウント、プライバシー、プラットフォーム規約、アクセス権限に関わる。実際に使うなら、デバイス所有、タスク承認、データ保存方法、出力範囲を明確にするべきだ。スマホ画面を無制限のデータソースとして扱ってはいけない。

デプロイのハードルと制限

mobile-use はプラットフォームからのクイックスタートとソースコードからの実行をサポートする。ソース方式では .env、LLM 設定、依存環境が必要だ。Android は実機またはエミュレーターを使え、Docker クイックスタートは現在主に Android 向けだ。iOS では macOS、Xcode、Facebook の iOS Development Bridge が必要で、README でも物理 iOS デバイスはまだサポートされないとしている。

これらの制約は意外ではない。モバイル自動化はブラウザ自動化よりもデバイス、システム権限、デバッグ経路に依存する。特に iOS は閉鎖性が高く、シミュレーターに安定して接続できるだけでも価値があるが、「任意の実 iPhone 自動化」にはまだ距離がある。

したがって mobile-use を評価するときは、モデル効果だけでなく、対象デバイス、App の種類、実行環境、コンプライアンス境界が合うかも見る必要がある。

誰が注目すべきか

mobile-use は次の人に向いている。

• AndroidWorld、モバイル GUI agent、タスク分解手法を研究したい研究者。
• 自然言語のモバイル操作を内部ツールに接続したい開発者。
• ネイティブ App から構造化データを抽出したいチーム。
• モバイル App の QA、回帰テスト、探索的テストを行う人。
• mobile-use、Mobilerun、Mobile-Agent など異なるモバイルエージェント路線を比較したい人。

一般ユーザー向けスマホアシスタントが目標なら、現時点ではまだエンジニアリングと研究寄りのフレームワークだ。モバイル agent の実現可能性を検証したいなら、かなり具体的なオープンソースの出発点になる。

機能比較

長所と短所

MobiAgent の長所はシステムが完整なことだ。スマホ GUI agent のモデル、記憶、加速、評価の閉ループを研究するのに向いている。短所はデプロイの経路が長く、エンジニアリング設定が重く、一般的な開発者には導入コストが高いことだ。

Mobile-Agent の長所は技術路線がもっとも広いことだ。GUI agent がスマホからデスクトップ、ブラウザ、ツール利用、基盤モデルへ進化していく様子を見られる。短所はプロジェクト群が複雑で、特定シナリオをすぐに実装したい場合は、先にかなり選別する必要があることだ。

Mobilerun の長所はエンジニアリングインターフェースが明確で、モデル非依存で、ローカルフレームワークとクラウドサービスの分離がはっきりしていることだ。モバイルデバイス自動化を製品や内部ツールに接続する用途に向いている。短所は、モバイルデバイスの権限、環境、App 状態、クラウドコストの問題に引き続き向き合う必要があることだ。

mobile-use の長所は、実アプリ利用、タスク分解、構造化データ抽出に集中していることだ。AndroidWorld という方向性も評価しやすい。短所は物理 iOS デバイスの対応が限られ、完整に使うにはモデル、デバイス、実行環境の設定が必要なことだ。

適用範囲の提案

モバイルエージェント研究をしたいなら、まず MobiAgent と Mobile-Agent を見るとよい。前者はスマホ側システムの閉ループにより集中し、後者は GUI agent のクロスプラットフォームな進化を観察するのに向いている。

モバイル App 自動化、QA、データ抽出、内部ワークフローを作りたいなら、まず Mobilerun と mobile-use を見るとよい。Mobilerun はエンジニアリングシステムに接続できる実行フレームワークに近く、mobile-use は自然言語による App 操作と構造化抽出の検証に向いている。

将来の個人アシスタント形態に関心があるなら、4つとも追う価値がある。MobiAgent はスマホ agent の体系的研究、Mobile-Agent はクロスプラットフォーム GUI agent 路線、Mobilerun はデバイス制御インフラ、mobile-use は実アプリのタスク分解と評価駆動の路線を代表している。

私の見方

この4つのプロジェクトの違いは、モバイル GUI agent がもはや「モデルにスクリーンショットを見せてボタンをタップさせる」だけではないことを示している。本当の課題は、モデルがどう画面を理解するか、実行器がどう安定してデバイスを制御するか、タスクをどう分解し評価するか、クラウドデバイスをどう管理するか、結果をどう構造化して返すか、リスクをどう制限するかになっている。

短期的にもっとも現実的な導入シーンは、QA、データ抽出、内部フロー自動化、制御されたデバイスプールだ。長期的には、デバイス制御、モデル能力、権限境界、ログ追跡、ユーザー確認メカニズムを安定させられるプロジェクトほど、本当に使えるモバイル AI アシスタントに近づく。