モバイル on KnightLiブログ

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

Fri, 29 May 2026 21:47:24 +0800

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

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

基本情報の比較

プロジェクト	サイト内記事	GitHub	主な位置づけ	デバイス/プラットフォーム	ライセンス	向いている人
MobiAgent	サイト内紹介	IPADS-SAI/MobiAgent	モデル、runner、メモリ、加速、評価を含むカスタマイズ可能なスマホ GUI エージェントシステム	主に Android/Harmony スマホ	Apache-2.0	研究者、モバイルエージェント実験チーム
Mobile-Agent	サイト内紹介	X-PLUG/MobileAgent	Tongyi Lab の GUI エージェントファミリー。モバイル、デスクトップ、ブラウザ、ツール利用をカバー	スマホ、PC、Web、クラウドスマホ/クラウドデスクトップ	MIT	GUI agent の技術路線を追いたい人
Mobilerun	サイト内紹介	droidrun/mobilerun	CLI、Python API、クラウドデバイスワークフローを備えた LLM 非依存のモバイルデバイス agent フレームワーク	Android、iOS、ローカルデバイス、クラウドデバイス	MIT	開発者、QA、自動化ワークフローチーム
mobile-use	サイト内紹介	minitap-ai/mobile-use	自然言語で実際のモバイル App を操作し、タスク分解、構造化抽出、AndroidWorld を重視	Android 実機/エミュレーター、iOS シミュレーター	Apache-2.0	モバイル App agent、データ抽出、評価を扱う人

MobiAgent

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

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

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

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 の基盤モデル路線に見える。

弱点もこの広さから来る。リポジトリは研究成果の集合に近く、利用者はまず、どのサブプロジェクト、どのモデル、どのシナリオを走らせるのかを判断する必要がある。技術の進化を追い、実験を再現するには向いているが、業務フローへ最速で組み込む選択肢とは限らない。

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 をエンジニアリング部品として取り込む人に向いている。

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 シナリオが現在の実行経路でカバーできるかを先に確認したい。

機能比較

機能軸	MobiAgent	Mobile-Agent	Mobilerun	mobile-use
自然言語タスク	対応	対応	対応	対応
実スマホ操作	強い。Android/Harmony 寄り	強い。モバイルとクラウドスマホを含む	強い。Android/iOS	強い。Android、iOS はシミュレーター寄り
デスクトップ/ブラウザ拡張	主眼ではない	強い。PC-Agent、GUI-Owl、ToolCUA を含む	主な位置づけではない	主な位置づけではない
モデル層	MobiMind 系列を内包	GUI-Owl、Mobile-Agent 系列	LLM 非依存。複数モデルに接続	複数 LLM を設定可能
実行器/runner	強い。ADB runner、マルチタスク runner を含む	サブプロジェクトごとに提供	強い。CLI/TUI/Python API/Docker	ソースコード、Docker、プラットフォーム入口あり
記憶能力	ユーザープロファイル、経験、アクション記憶	v3/v3.5 で記憶と反省を強調	トレース、ログ、エンジニアリングデバッグ寄り	タスク分解と状態つき実行寄り
評価	MobiFlow	複数の論文/ベンチマーク方向	benchmark 結果入口あり	AndroidWorld で目立つ
クラウドデバイス	主な売りではない	クラウドスマホ/クラウドデスクトップ体験に対応	Mobilerun Cloud が重点	プラットフォーム入口あり
構造化出力	エンジニアリングフローで実現可能	サブプロジェクト次第	明確に対応	明確に対応

長所と短所

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 アシスタントに近づく。

mobile-useの見どころ：AIが実アプリを操作し、データも抽出できる

Fri, 29 May 2026 21:43:46 +0800

mobile-use は minitap-ai が公開したモバイル AI agent フレームワークだ。エージェントが人のように実際の Android と iOS App を使えるようにすることを目指している。ユーザーは自然言語でタスクを説明し、フレームワークが画面を理解し、App を操作し、結果を呼び出し側へ返す。

README を見ると、mobile-use の重点は「スマホをタップできる」だけではない。UI-aware automation、データ抽出、設定可能なモデル、AndroidWorld ベンチマークでの性能も強調している。クラウドプラットフォーム、ドキュメント、論文への入口もあり、オープンソースフレームワークであると同時に、モバイルエージェントをめぐるプロダクトと研究の体系でもある。

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

従来のスマホ自動化は、スクリプト、座標、コントロール 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 の実現可能性を検証したいなら、かなり具体的なオープンソースの出発点になる。

私の見方

mobile-use の魅力は、実アプリ操作、構造化データ抽出、ベンチマーク評価を同じプロジェクトに置いていることだ。単なる「自然言語でスマホをタップする」包装ではなく、モバイルタスクを実行可能、評価可能、再現可能なエージェントフローへ分解しようとしている。

モバイルは GUI agent の重要な領域になる。多くの個人タスクや業務タスクは Web ページや API ではなく App の中で発生するからだ。mobile-use のようなプロジェクトは、エージェントをチャット画面から実際のアプリケーション画面へ移す意味を持つ。デバイス、権限、リスクの問題をすべて消したわけではないが、開発者に十分具体的な実験基盤を提供している。

プロジェクトリンク：minitap-ai/mobile-use

AIにスマホを自動タップさせたい？MobilerunはAndroidとiOSに対応

Fri, 29 May 2026 21:43:45 +0800

Mobilerun は droidrun が公開したモバイルデバイス自動化フレームワークだ。LLM agent が自然言語で Android と iOS デバイスを制御できるようにすることを目標にしている。モバイル向けネイティブツールを提供し、エージェントが UI 状態を確認し、スクリーンショットを理解し、タップ、スワイプ、入力、複数ステップの計画を行い、CLI または Python API で結果を返せる。

このプロジェクトの位置づけは明確だ。特定のモデルに縛られず、モバイルデバイスとエージェントの間の実行層を担う。README に挙げられているモデルソースには OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter、OpenAI-compatible providers が含まれる。開発者にとって、これは「ひとつのモデルだけをサポートするデモ」より実用的だ。

何を解決するのか

モバイル自動化で最も厄介なのは、自然言語タスクと実デバイス操作の間に多くの層があることだ。モデルは現在どの 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 側にも独自の接続フローがある。安定して動かすには、モデル設定、デバイス状態、権限ポップアップ、失敗時の復旧も扱う必要がある。

私の見方

Mobilerun の価値は、モバイルデバイス制御をプログラム可能で、観測可能で、モデル交換可能な agent フレームワークにしたことだ。モバイル自動化は単なるモデル問題ではなく、モデル、デバイス、実行器、ログ、ツール、クラウド基盤から成るシステム問題だと認めている。

短期的には、開発者がモバイル自動化プロトタイプや内部ツールを作るのに向いている。長期的には、この種のフレームワークが「スマホ上の AI ワークフローエンジン」になる可能性がある。GUI agent が実業務に入るなら、ローカル実行、クラウドデバイス、構造化出力、追跡性をまとめる Mobilerun のようなプロジェクトはますます重要になる。

プロジェクトリンク：droidrun/mobilerun

AIは自分でスマホをタップし、PCを使えるのか？Mobile-Agentプロジェクトを読む

Fri, 29 May 2026 21:42:41 +0800

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

MobiAgentとは？スマホ App を操作できるオープンソース AI エージェント

Fri, 29 May 2026 21:36:58 +0800

IPADS-SAI は MobiAgent をオープンソース化した。これはスマホ GUI 向けのカスタマイズ可能なエージェントフレームワークだ。単一のモデルリポジトリではなく、モデル、実行器、加速機構、評価ベンチマーク、モバイルアプリを同じ体系に置き、実際のスマホ環境でクロスアプリの多段階タスクを完了させることを目指している。

プロジェクト構造を見ると、MobiAgent は主に MobiMind 系列のエージェントモデル、AgentRR の記録・再生加速フレームワーク、MobiFlow 評価ベンチマークから構成される。論文概要でも、既存のモバイルエージェントでは実タスクでの精度と効率が主なボトルネックだと強調されており、MobiAgent の設計はこの2点を中心にしている。

何を解決するのか

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

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

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

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

メモリシステムが重要

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

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

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

誰が注目すべきか

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

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

私の見方

MobiAgent の意味は、単にもうひとつ GUI agent を出したことではない。スマホエージェントを「スクリーンショットを見てボタンを押す」単発能力から、訓練、実行、評価、加速ができるシステムフレームワークへ進めたことにある。

モバイルはエージェントが避けにくい領域だ。多くの個人タスクは標準化された Web や API ではなく App 内で起きる。スマホ画面を安定して理解し、アプリをまたいでタスクを実行し、経験を再利用し、プライバシーリスクを制御できるものが、本当に使える個人エージェントに近づく。

MobiAgent はまだすべてを解決していないが、かなり完整なオープンソースの出発点を提供している。短期的にはモバイルエージェント研究と実験に向いており、長期的にはスマホ OS、個人アシスタント、自動化ツールをつなぐ重要な層になる可能性がある。

プロジェクトリンク：IPADS-SAI/MobiAgent
論文リンク：MobiAgent: A Systematic Framework for Customizable Mobile Agents

モバイル on KnightLiブログ

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

基本情報の比較

MobiAgent

Mobile-Agent

Mobilerun

mobile-use

機能比較

長所と短所

適用範囲の提案

私の見方

mobile-useの見どころ：AIが実アプリを操作し、データも抽出できる

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

AndroidWorld の結果に注目

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

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

誰が注目すべきか

私の見方

AIにスマホを自動タップさせたい？MobilerunはAndroidとiOSに対応

何を解決するのか

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

なぜ LLM 非依存が重要か

向いている場面

私の見方

AIは自分でスマホをタップし、PCを使えるのか？Mobile-Agentプロジェクトを読む

何を解決するのか

v3.5 の重点

GUI-Owl は土台の変化

ToolCUA が示す新しい方向

誰が注目すべきか

私の見方

MobiAgentとは？スマホ App を操作できるオープンソース AI エージェント

何を解決するのか

最近の更新

メモリシステムが重要

誰が注目すべきか

私の見方