南京大学やSenseTimeなど6機関の研究チームが、スマートフォン操作AI「OpenMobile-2」のモデル、学習データ、学習環境を公開した。2026年10月9日に公開されたarXivプレプリントによると、270億パラメータのモデルが、Androidアプリの操作能力を測るベンチマーク「AndroidWorld」で79.9±3.0%の成功率を記録した。OpenMobile-2は画面を認識し、タップや文字入力などの操作を通じて、ユーザーから指示されたタスクを実行するAIだ。一部の評価では商用モデルに匹敵する成績を収めたが、Androidエミュレータと実機では結果に差があり、学習にはブラウザ上で動く模擬アプリも利用している。今回の研究で重要なのはモデルの性能だけでなく、多様なアプリを繰り返し操作できる学習環境や、画面操作とツール呼び出しを組み合わせる手法まで公開された点にある。

AD

商用AIに匹敵する性能も、評価環境によって結果に差

OpenMobile-2の性能を評価するには、ベンチマークごとの実行環境と測定条件を区別する必要がある。「AndroidWorld」は20アプリの116タスク、「MobileWorld」は20アプリの201タスクを対象とし、いずれもAndroidエミュレータ上で実行される。一方、「SPA-Bench」は実際のスマートフォンを使用する評価だ。2026年10月9日公開の論文（v1）のTable 2から、OpenMobile-2とGoogleのGemini-3.1-pro-previewの成績を抜き出すと、次のようになる。AndroidWorldのPass@1は1回の試行でタスクを達成する割合、MobileWorldのGUIは画面操作による成績を表し、SPA-Benchは難易度L3のタスクに限った結果である。

モデル AndroidWorld Pass@1 MobileWorld GUI SPA-Bench L3（実機）
OpenMobile-2-27B +RL 79.9±3.0% 50.4% 59.6%
Gemini-3.1-pro-preview 70.7% 58.1% 70.2%

この比較では、OpenMobile-2-27BはAndroidWorldでGeminiを上回る一方、MobileWorldの画面操作と実機を使ったSPA-Bench L3では下回っている。なお、AndroidWorldの±は評価時の乱数シードによる標準偏差を示しており、SPA-Benchの数値は全340タスクの総合成績ではない。各ベンチマークは対象タスクや評価条件が異なるため、三つの成績を単純に合算してモデルの優劣を判断することはできない。

実機のSPA-Bench L3では、研究チームが再測定したGPT-5.6-Solも68.1%を記録し、OpenMobile-2-27Bの59.6%を上回った。ただし、論文に掲載された商用モデルの成績には過去の報告値も含まれており、再測定したモデルについても、それぞれ異なる評価実行系が使われている。したがって、この表は研究チームが整理した比較結果であり、独立した第三者がすべてのモデルを同一条件で測定したランキングではない。

また、強化学習によってすべての評価成績が改善したわけでもない。画面操作とツール呼び出しを組み合わせた教師あり追加学習の段階では、27BモデルのAndroidWorldでの成功率は80.8±3.5%だったが、強化学習後は79.9±3.0%となった。評価結果にはばらつきがあるため、この差だけで強化学習が性能を悪化させたと断定することはできない。今回の成果は、特定の評価環境で商用モデルに迫る性能を持つ研究用モデルと、その学習方法を第三者が検証できる基盤の公開として捉えるべきだろう。

110以上のアプリを扱い、同じ状態から繰り返し学習できる環境

研究チームが開発した「MobileGym++」は、スマートフォン操作AIの学習環境を拡張するための仕組みだ。35本の商用アプリを新たに再実装し、既存のものを含めて63のアプリクライアントをブラウザ上で動かせるようにした。Androidエミュレータで動作するアプリも合わせると、学習環境全体で扱えるアプリは110本を超える。ただし、35の商用サービスに直接接続しているわけではなく、その機能や操作を模した研究用アプリを用意したという意味だ。

Androidエミュレータによる学習には、環境の初期化や複数インスタンスの並列実行に大きな負荷がかかるという課題がある。また、実際のアプリを操作するとログイン状態が変わったり、注文や予約などの処理が発生したりするため、同じ条件で繰り返し学習することが難しい。MobileGym++では、注文内容や予算、旅程などをアプリ内部のデータとして管理し、その状態を保存・復元できるようにした。さらに、共有クリップボードや共有機能、決済画面への移動、メディアの選択などにも対応し、複数のアプリをまたぐ一連の操作も再現できる。画面の見た目を再現するだけでなく、操作によって内部データが変化する環境を構築した点が特徴だ。

学習データの作成には、教師モデルとしてGemini-3.1-Pro-Previewを利用した。研究チームは、このモデルにタスクの指示と操作履歴を生成させ、成功した事例を選別してデータセットを構築している。公開データカードによると、収録された操作履歴は11,643件、操作ステップは合計118,582件に上る。履歴の内訳は、Androidエミュレータ上で収集した7,725件、模擬環境で画面操作のみを使った2,144件、画面操作とツール呼び出しを併用した1,774件だ。また、強化学習向けには、目標、初期状態、成功判定プログラムを備えた2,475タスクも公開されている。ただし、実際の強化学習に使用したのは、このうち512タスクである。

こうしたデータや環境の公開によって学習手法を再現・検証しやすくなる一方、操作履歴を生成する段階では商用の教師モデルに依存している。この点は、公開されたモデルやデータセットだけで学習工程のすべてを独立して再現できるかを判断する際に重要となる。

学習環境に含まれるアプリの多様性が性能に与える影響も、実験で確かめられている。論文の第5.3節では、基盤モデルと最適化条件、エミュレータで収集した操作履歴の総数2,000件を固定したまま、学習対象のアプリを15本から53本に増やして比較した。その結果、学習時に使用していないアプリでのPass@1は60.7%から67.5%に上昇した。一方、もともとの15アプリでの成績は73.7%から71.4%となり、研究チームは概ね安定した性能を維持していると評価した。

この実験で変えたのは学習データの総量ではなく、操作経験を収集するアプリの種類と配分だ。つまり、同じ数の操作履歴でも、より多様なアプリから収集することで、未知のアプリへの対応力が改善する可能性がある。ただし、研究用の評価環境で得られた結果であり、あらゆる実サービスで同じ効果が得られるとは限らない。状態を保存・復元できるMobileGym++の公開は、開発者がこうした学習データの配分や環境の多様性を検証するうえでも意味がある。

AD

画面操作とツール呼び出しを組み合わせてタスクを効率化

MobileGym++のもう一つの特徴は、AIが画面を直接操作する方法と、アプリの機能をツールとして呼び出す方法を、同じタスクの中で使い分けられることだ。研究チームは50を超えるアプリに、300以上のアプリ内機能を呼び出すツールを用意した。例えば、商品をカートに追加するadd_to_cartを実行すると、画面操作で開いた場合と同じカートの内容が更新される。これは、画面操作とツール呼び出しが別々の環境で動作するのではなく、同じアプリ内部のデータを共有しているためだ。OpenMobile-2の公式サイトでも、この共通の状態管理を使った設計が説明されている。

モデルに提示されるのは、現在操作しているアプリで利用可能なツールだけだ。ツールには引数の形式が定義されており、実行すると結果やエラーが返される。一方、画面操作ではスクリーンショットの画像情報を使い、アクセシビリティツリーやアプリの内部状態をモデルが直接読み取る仕組みにはしていない。これにより、画面を見てタップや入力を行う方法と、ツールを使ってアプリの機能を直接実行する方法を、一連のタスクの中で組み合わせられる。

両者を比較するため、研究チームは215タスクを用意し、画面操作のみの場合とツールを併用する場合で、同じ初期状態と成功条件を使用できるようにした。215タスクのうち109タスクは単一アプリ内で完結し、残りは複数のアプリをまたぐ操作を必要とする。タスクの成否はAI自身の判断に任せず、アプリ内部のデータの変化などを成功判定プログラムで検査する仕組みだ。これにより、操作方法が異なっても、同じ目標を達成できたかを比較できる。

ただし、利用可能なツールを与えるだけで、AIが適切に使い分けられるようになるわけではない。研究チームは、画面操作とツール呼び出しの両方を学習しなければ、ツールを使うべきタイミングを十分に判断できないと報告している。実際に、両方の操作方法を学習した同じ27BモデルをMobileGym++で評価したところ、画面操作のみの場合は成功率55.3%だったのに対し、ツール併用時には65.6%に上昇した。成功率の差は10.3ポイントで、タスク完了までの操作ステップ数も平均5.8ステップ減少している。

この結果は、異なる学習方法で作られた二つのモデルを比較したものではなく、同じ学習済みモデルに対して操作方法を変えた実験によるものだ。画面操作とツール呼び出しを組み合わせることで、模擬環境ではタスクの成功率と実行効率を改善できることが分かる。一方、実際のスマートフォンアプリが同じツールを提供しているとは限らない。こうした仕組みを実サービスに導入するには、画面操作とツール呼び出しの双方が同じアプリの状態を扱えるよう、個別に連携機能を整備する必要がある。

モデルと学習環境で異なるライセンス条件に注意

公開された「OpenMobile-2-27B」は、Qwen3.6-27Bを基盤とするモデルだ。Hugging FaceのモデルカードにはライセンスとしてApache License 2.0が記載され、vLLMを使って推論サーバーを起動する手順も紹介されている。ただし、今回公開されたのはスマートフォン操作を目的とするAIモデルであり、一般的なスマートフォン上で270億パラメータのモデル全体を動作させる消費者向けアプリではない。

また、モデルと学習環境では、利用する資産によってライセンス条件が異なる。MobileGym++のコード、ドキュメント、ビルドスクリプトなどにはApache License 2.0が適用される一方、LICENSE-DATAではapps/*/data/、apps/*/assets/、public/*.jsonなどのデータスナップショットを別に扱っている。このうち、管理者が作成したデータの編成物や生成物には、非商用条件を含むCC BY-NC 4.0が適用される。さらに、第三者が提供するデータについては元の権利やプラットフォームの利用条件も残るため、MobileGym++のコードがApache License 2.0で公開されているからといって、含まれるデータをすべて同じ条件で利用できるわけではない。なお、このライセンス文書だけで、OpenMobile-Data-v2全体の利用条件まで判断することもできない。

今回のOpenMobile-2の公開によって、スマートフォン操作AIの性能だけでなく、どのアプリから学習データを収集し、画面操作とツール呼び出しをどのように使い分けるべきかについても、第三者が検証しやすくなった。特に、アプリの状態を保存・復元できる環境と、操作結果をプログラムで判定できる仕組みは、学習手法を比較するうえで重要な基盤となる。ただし、実際の開発に導入するには、対象アプリの初期状態と成功条件を統一し、使用するモデルやデータのライセンス条件を確認したうえで、実機でも性能を検証する必要がある。今後は、研究用ベンチマークでの高得点にとどまらず、現実のアプリでユーザーの指示をどこまで確実に完了できるかが、OpenMobile-2の実用性を判断する鍵となる。