オープンソースのスマホエージェントフレームワーク3選：Open-AutoGLM、Mobilerun、mobile-useの選び方
Open-AutoGLM、Mobilerun、Minitap mobile-useを、端末条件、実行方式、モデル設定、ライセンス、トレース、保守コストで比較。フレームワークを運用したい人と、すぐ使えるAndroid製品を選びたい人の違いも整理します。
- オープンソースのスマホエージェントフレームワークは、実機制御、モデル推論、端末接続、ログ確認、保守を自分で管理できる人向けです。順位ではなく目的で選びます。
- Open-AutoGLMはAndroidをADBで操作する視覚系Phone Agentの研究・検証に向き、iOSは別途WebDriverAgentの設定が必要です。MobilerunはCLIやPythonからの実行、構造化結果、トレース確認を重視する開発に向いています。
- Minitap mobile-useは自然言語で構造化されたモバイルUIタスクを扱いたい時の候補です。iOSはREADME上の具体的な対応範囲を見て判断し、物理iOS端末まで同じように扱えるとは考えません。
- FoneClawはオープンソースフレームワークではなく、すぐ使えるAndroidアプリの経路です。モデル、権限、承認、対応ツールの範囲を確認しながら、日常のスマホ作業へ使います。
目的から3つの候補を選ぶ
オープンソースのスマホエージェントフレームワークを選ぶ時は、最初に「何を作りたいか」を決めます。研究寄りの画面理解、実機を使った自動操作、構造化されたモバイルタスク、クラウド端末を含む運用では、必要な仕組みが変わります。ここではOpen-AutoGLM、Mobilerun、Minitap mobile-useの3つを、性能順位ではなく用途別に整理します。
| 候補 | 向いている使い方 | 最初に確認すること |
|---|---|---|
| Open-AutoGLM | Android画面を見て操作するPhone Agentの研究、実機ADB操作、モデルサーバー連携 | ADB、USBデバッグ、入力方式、利用するモデルAPIまたは推論環境。iOSはAndroidのADB設定ではなくWebDriverAgent経路を確認 |
| Mobilerun Framework | CLIやPythonでモバイル操作を組み、結果や軌跡を確認する開発 | Portalアクセシビリティサービス、モデルプロバイダー、トレース保存 |
| Minitap mobile-use | 自然言語から構造化されたモバイルUIタスクを実行・抽出する用途 | Androidまたは対応するiOSシミュレーター環境、LLM設定、対象アプリのUI情報 |
いずれも、モデル、実行ランタイム、端末接続、操作の安全確認を分けて考える必要があります。オープンソースであることは、モデル呼び出し、クラウド端末、保守、失敗時の調査が無料になるという意味ではありません。
設定、実行、モデル、ライセンスを比べる
3つの候補はどれもスマホエージェント開発に使えますが、同じ層を担当しているわけではありません。フレームワークは端末を見る、計画する、操作する、結果を記録するための枠組みです。モデル推論は別にAPIや自前サーバーを使うことがあり、スマホ側の操作はADB、アクセシビリティ、WebDriverAgent、クラウド端末などの実行役に依存します。
| 項目 | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| 主な端末経路 | AndroidはADB、HarmonyOS向けのHDCも文書化。iOSは別途WebDriverAgent設定 | AndroidはADBとPortalアクセシビリティサービス、iOSは別のPortal手順 | Android実機・エミュレーターはADB、iOSはmacOS上のシミュレーター中心 |
| モデル | ホストされたモデルAPIまたは自前推論を利用 | モデルプロバイダーを選択 | 設定可能なLLMプロバイダーを利用 |
| 検査とログ | 人による引き継ぎや確認を含む設計 | Arize Phoenix、Langfuse、保存された軌跡をREADMEで案内 | 構造化抽出とタスク実行の設計を確認 |
| ライセンス | Apache-2.0 | MIT | Apache-2.0 |
| 注意点 | モデルや依存先の条件はリポジトリのライセンスとは別 | FrameworkとManaged Cloudを混同しない | 物理iOS端末はREADME上で未対応と明記 |
導入判断では、対応端末、開発PC、モデル費用、ログ確認、保守担当を先に決めます。Android操作でどの評価軸を見るかは、Androidスマホエージェント ベンチマーク：2026年の評価指標と再現可能なテスト設計が参考になります。
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による実行トレース、保存された軌跡が案内されています。成功率を数字で決めつけるより、どの画面で判断を誤ったか、どの操作が不安定か、モデル出力と端末状態がずれていないかを追えることが重要です。
Minitap mobile-useが合う場面
Minitap mobile-useの公式リポジトリは、自然言語でモバイルUI操作を指示し、構造化抽出も扱うフレームワークです。Androidの物理端末やエミュレーターではADBを使います。DockerのクイックスタートはAndroid向けで、LLMプロバイダーを設定して使う形です。
iOS対応は慎重に読みます。READMEの手動デバイス設定では、macOS上のiOSシミュレーターが挙げられ、物理iOS端末はまだ対応していないと明記されています。広い説明だけを見てAndroidとiOSが同じ条件で使えると判断せず、実際に使う端末、OS、シミュレーター、開発環境を照合してください。
mobile-useは、フォーム入力、画面からの情報抽出、一定の手順を自然言語で表すタスクに向きます。ただし、ゲームのようにアクセシビリティツリーの情報が乏しい画面では制限があるとREADMEに記載されています。画面が読めること、操作できること、結果を検証できることは別なので、対象アプリごとに確認します。
戻せる作業で評価する
評価は、危険な作業ではなく、戻せる作業から始めます。これは実施済みのベンチマーク結果ではなく、導入前に読者が自分の環境で行うための確認手順です。同じ端末、同じアプリ、同じモデル、同じネットワークで比較し、1回の成功ではなく失敗時の観察を残します。
| テスト | 見ること | 失敗時の戻し方 |
|---|---|---|
| アプリを開いて画面を説明する | 画面取得、UI理解、モデル応答 | 手動でアプリを閉じ、ログを保存する |
| 検索欄に短い文字を入力する | 入力経路、キーボード、対象欄の選択 | 文字を削除し、入力対象の誤認を記録する |
| メモの下書きを作る | 本文、保存先、確認画面 | 保存前に破棄するか、テスト用メモを削除する |
| 権限が必要な操作を止める | 確認、停止、説明、再開可否 | 権限を付与せず終了し、状態を確認する |
比較では、モデルの賢さだけを見ません。端末接続が安定しているか、ログから失敗地点を追えるか、UI変更に弱すぎないか、モデル呼び出し費用を予測できるか、クラウド端末や自前サーバーの運用担当を置けるかを確認します。モデル選定そのものは、AIエージェント向けモデルの選び方：Android操作に合う6候補で別に整理しています。
フレームワークを運用しない選択肢
フレームワークを選ぶべき読者は、端末接続、モデルAPI、ログ、失敗時の復旧、ライセンス確認、保守を自分で引き受けられる人です。日常のAndroid作業をすぐ使いたいだけなら、オープンソースフレームワークを組むより、製品として整った経路を選ぶほうが現実的な場合があります。
FoneClawはオープンソースのスマホエージェントフレームワークではありません。私たちが提供するAndroidアプリとして、無料の標準モデルから始め、必要に応じて互換性のあるモデル経路を設定し、権限と承認に沿って対応するAndroid操作を進めます。端末内で作業を進めることと、すべての推論が端末内で完結することは別です。利用できる範囲はFoneClawの機能ページで確認できます。
スマホエージェントの全体像を先に理解したい場合は、AIエージェントでAndroidを操作する仕組み：意図、確認、実行、検証までの完全ガイドが、意図、確認、実行、検証を分けて考える助けになります。開発者はフレームワーク、一般利用者は製品経路というように、目的に合う負担を選ぶのが堅実です。