オープンソースのスマホエージェントフレームワーク3選：Open-AutoGLM、Mobilerun、mobile-useの選び方

目的から3つの候補を選ぶ

オープンソースのスマホエージェントフレームワークを選ぶ時は、最初に「何を作りたいか」と「どの端末を操作するか」を決めます。研究寄りの画面理解、実機を使った自動操作、構造化されたモバイルタスク、クラウド端末を含む運用では、必要な仕組みが変わります。ここではOpen-AutoGLM、Mobilerun、Minitap mobile-useの3つを、性能順位ではなく用途別に整理します。

いずれも、モデル、実行ランタイム、端末接続、操作の安全確認を分けて考える必要があります。オープンソースであることは、モデル呼び出し、クラウド端末、保守、失敗時の調査が無料になるという意味ではありません。更新時も、コードだけでなく接続先と設定ファイルの互換性を確認します。

設定、実行、モデル、ライセンスを比べる

3つの候補はどれもスマホエージェント開発に使えますが、同じ層を担当しているわけではありません。フレームワークは端末を見る、計画する、操作する、結果を記録するための枠組みです。モデル推論は別にAPIや自前サーバーを使うことがあり、スマホ側の操作はADB、アクセシビリティ、WebDriverAgent、クラウド端末などの実行役に依存します。

ライセンスは、採用するコードの版と同梱される条件を確認してください。本体のライセンスだけで、モデル、依存ライブラリ、クラウドサービスの利用条件まで判断できるわけではありません。導入判断では、対応端末、開発PC、モデル費用、ログ確認、保守担当を先に決めます。評価軸は、Androidスマホエージェントの評価指標と再現可能なテスト設計が参考になります。

Open-AutoGLMが合う場面

Open-AutoGLMの公式リポジトリは、視覚情報を使ってスマホを操作するPhone Agentの枠組みです。AndroidではADBを使い、開発者向け設定、USBデバッグ、ADB Keyboardなどの準備が必要です。HarmonyOS向けにはHDCの記述もあります。iOSはAndroidのADB設定を流用するのではなく、別途WebDriverAgentを使うセットアップとして確認します。スマホ画面を見て、操作候補を作り、端末側で実行する流れを検証したい開発者に合います。

モデル推論はフレームワーク本体とは別に考えます。Open-AutoGLMは、第三者のホスト済みモデルAPIを使う方法と、自分の環境で推論サービスを用意する方法を文書化しています。ホスト済みAPIならローカルGPUは必須ではありませんが、API費用、通信、利用条件は別に発生します。自前推論を選ぶ場合は、サーバー、GPU、モデルのライセンス、運用監視を自分で見ます。

ログインやCAPTCHAのような場面では人が引き継ぐ設計が説明され、機微な操作には確認を入れる方向です。これは実用上重要です。画面操作型のエージェントは、一度成功しても、アプリ更新やUI変更で失敗することがあるため、停止、再試行、人間への戻し方を評価項目に入れます。

Mobilerun FrameworkとCloudを分けて選ぶ

Mobilerunの公式リポジトリは、旧DroidRunとして知られる系譜を持つモバイル操作フレームワークです。CLIとPythonからモバイル操作を組み、アクセシビリティツリー、スクリーンショット、モデルプロバイダー選択、構造化された結果を扱える点が特徴です。AndroidではADB、開発者向け設定、USBデバッグ、Portalアクセシビリティサービスの準備が必要です。

Mobilerunで注意したいのは、FrameworkとManaged Cloudを分けることです。Frameworkは自分のマシン上でエージェントを動かす経路です。一方、Cloudは接続したローカル端末やホストされた仮想・物理端末、APIワークフローを扱う別の運用経路です。どちらを使うかで、端末管理、費用、セキュリティ確認、失敗時の調査場所が変わります。

トレースと検査を重視するチームにはMobilerunが検討しやすい候補です。READMEではArize PhoenixやLangfuseによる実行トレース、保存された軌跡が案内されています。成功率を数字で決めつけるより、どの画面で判断を誤ったか、どの操作が不安定か、モデル出力と端末状態がずれていないかを追えることが重要です。

10月14日UTC公開のMobilerun変更履歴では、実行対象の選び方が明確になりました。mobilerun runは、明示した-d、環境変数ANDROID_SERIAL、唯一のオンライン端末の順で対象を決めます。複数端末があり、どちらの指定もなければ、先頭の端末を選ぶのではなくエラーで停止します。実行前にadb devicesで接続一覧を確認し、意図した検証端末を選んでください。

同じ更新で、FastAgentは一つの応答に含まれる最初のfunction_callsブロックだけを実行し、後続ブロックは無視します。また、呼び出しが失敗すると、そのブロックの残りは実行しません。これは一連の操作をまとめて取り消す仕組みではありません。失敗前の操作は反映されている可能性があるため、ログと実際の画面を確認し、原因を直してから未完了部分を再試行します。

既存環境では、10月5日のアプリカード移行案内も確認します。カードはapp_cards_dir/android/app_cards.jsonとapp_cards_dir/ios/app_cards.jsonへ分けます。app_cards_dir直下に置いた従来のapp_cards.jsonは読み込まれません。単にファイルを移すだけでなく、Android用の識別子とiOSのバンドルIDを混在させていないかも見てください。セットアップはフレームワークに対応するPortalを導入し、すでに新しいPortalがある場合はそれを維持するため、独自判断で固定の互換番号を割り当てないようにします。

Portalには、実行中にオフになったアクセシビリティサービスを再び有効にし、Portalキーボードを復元する動作があります。意図的に権限を取り消したい場合は、まずエージェントを停止し、その後に端末上のサービスと入力方式を確認してください。Play Protectなどの保護機能を無効化して対処する手順ではありません。Cloud側のUIツリー互換性や、タップ・入力呼び出しを再試行しない変更も、依存関係と失敗処理の点検事項です。すべてのアプリで成功する保証とは分けて考えます。

Minitap mobile-useが合う場面

Minitap mobile-useの公式リポジトリは、自然言語でモバイルUI操作を指示し、構造化抽出も扱うフレームワークです。Androidの物理端末やエミュレーターではADBを使います。DockerのクイックスタートはAndroid向けで、LLMプロバイダーを設定して使う形です。

iOS対応は慎重に読みます。READMEの手動デバイス設定では、macOS上のiOSシミュレーターが挙げられ、物理iOS端末はまだ対応していないと明記されています。広い説明だけを見てAndroidとiOSが同じ条件で使えると判断せず、実際に使う端末、OS、シミュレーター、開発環境を照合してください。

mobile-useは、フォーム入力、画面からの情報抽出、一定の手順を自然言語で表すタスクに向きます。ただし、ゲームのようにアクセシビリティツリーの情報が乏しい画面では制限があるとREADMEに記載されています。画面が読めること、操作できること、結果を検証できることは別なので、対象アプリごとに確認します。

戻せる作業で評価する

評価は、危険な作業ではなく、戻せる作業から始めます。これは実施済みのベンチマーク結果ではなく、公式の接続・実行条件を踏まえて、自分の環境で行うための確認手順です。同じ端末、同じアプリ、同じネットワークを使い、モデル条件も記録します。共通のモデルを利用できない場合は、その違いを残し、結果をフレームワーク単独の差と決めつけないようにします。

1. 自分が管理する検証用スマホを用意し、接続一覧と端末の識別情報を照合します。Mobilerunでは-dまたはANDROID_SERIALで対象を指定します。
2. 各フレームワークの公式手順に沿ってモデル、接続、必要なサービスを設定します。Mobilerunの既存環境ではアプリカードの配置も確認します。
3. 端末にある電卓など、送信・購入を伴わないアプリを一つ選び、「このアプリを開くだけ」という同じ作業を依頼します。
4. 意図した端末で、目的のアプリが実際に表示されたかを確認します。別端末が動いた場合や途中の操作に失敗した場合は、続行せず停止します。
5. 実行ログと画面を照合し、接続、権限、モデル判断のどこに原因があるかを調べてから再試行します。停止しただけで元の状態へ戻るとは考えません。

比較では、モデルの賢さだけを見ません。端末接続が安定しているか、ログから失敗地点を追えるか、UI変更に弱すぎないか、モデル呼び出し費用を予測できるか、クラウド端末や自前サーバーの運用担当を置けるかを確認します。モデル選定そのものは、Android操作に使うAIエージェント向けモデルの選び方で別に整理しています。

フレームワークを運用しない選択肢

フレームワークを選ぶべき読者は、端末接続、モデルAPI、ログ、失敗時の復旧、ライセンス確認、保守を自分で引き受けられる人です。日常のAndroid作業をすぐ使いたいだけなら、オープンソースフレームワークを組むより、製品として整った経路を選ぶほうが現実的な場合があります。

FoneClawはオープンソースのスマホエージェントフレームワークではありません。私たちが提供するAndroidアプリとして、設定したモデルが依頼を理解して手順を計画し、有効なツールが対応するAndroid操作を実行します。利用できる範囲は、実際の端末権限、対象アプリの状態、適用されるツールの承認設定によって決まります。すべての操作で確認画面が出るわけではなく、どのアプリでも自由に操作できるものでもありません。

端末上で操作することと、すべての推論が端末内で完結することは別です。モデルの通信先と渡す情報も確認してください。現在の対応範囲はFoneClawの機能ページで確認できます。ここで紹介したフレームワークとの専用連携を前提にする製品ではありません。

スマホエージェントの全体像を先に理解したい場合は、AIエージェントでAndroidを操作する仕組み：意図、確認、実行、検証までの完全ガイドが、モデルの判断と端末上の実行を分けて考える助けになります。フレームワークを自分で運用するか、対応操作を備えたアプリを使うかは、必要な制御範囲と引き受けられる保守負担で選んでください。