結論から書きます。AIがスマホやSaaSの画面を人間の代わりに操作する技術は、整えられたテスト環境では82.6%のタスクを完遂しますが、実機の本物アプリでは42%まで落ちます。10回頼んで4回しか終わりません。今の中小企業にとっての現実解は「AIが操作し、人が承認する」半自動です。
何が測られたのか：82.6%と42%という二つの数字
2026年7月16日、Hy Vision Teamが「HyMobileAgent: Data-Environment Co-Scaling for Efficient GUI Agents」という論文を公開しました（出典：arXiv:2607.14548、2026年7月16日（arXiv:2607.14548v1）、https://arxiv.org/abs/2607.14548v1）。
この論文が挑んでいるのは、シンプルな問いです。モデルそのものを巨大化させる代わりに、「学習データ」と「練習する環境」の両方を同時に増やせば、小さめのAIでも画面操作エージェントとして実用水準に届くのか。
結果として報告されている主要な数字が、次の二つです。
- Android仮想環境ベンチマーク AndroidWorld でのタスク完遂成功率：82.6%（比較対象として Gemini 3.1 が80.2%、Seed 2.0 Pro が71.5%。タスク数の記載はなし）
- 実デバイス上の実アプリで評価する HyMobileWorld でのタスク成功率：42%（Seed 2.0 Pro は44.7%、UI-Venus 1.5 A3B は9.7%、MAI-UI 8B は12.3%）
同じモデルで、環境が変わると40.6ポイント下がります（本文の数値から算出）。論文自身も、グラウンディング系の高スコアと、はるかに低いエンドツーエンド成功率の間にギャップがあることを認めています。分布シフト、つまり「練習した環境と本番の環境が違う」という問題です。
| 評価軸 | ベンチマーク／指標 | HyMobileAgent | 比較対象 |
|---|---|---|---|
| タスク完遂（仮想環境） | AndroidWorld | 82.6% | Gemini 3.1: 80.2% / Seed 2.0 Pro: 71.5% |
| タスク完遂（実機・実アプリ） | HyMobileWorld | 42% | Seed 2.0 Pro: 44.7% / UI-Venus 1.5 A3B: 9.7% / MAI-UI 8B: 12.3% |
| 要素の指し示し精度 | ScreenSpot V2 | 96.2 | — |
| 要素の指し示し精度 | HyMobileGrounding | 93.1 | — |
| 要素の指し示し精度 | MMBench-GUI L2 | 89.3 | Gemini 3.1: 90.3 |
| 高解像度・デスクトップ画面 | ScreenSpot-Pro | 66.5 | UI-Venus 1.5 A3B: 69.6 / MobileAgent 3.5: 71.1 |
| 画面内容の理解Q&A | MMBench-GUI L1 | 93.7 | — |
| 画面内容の理解Q&A | HyMobileQA | 87.0 | Seed 2.0 Pro: 89.4 |
表を見ると、性格がはっきりします。「画面のどこを押すか」を当てる精度は96.2、93.1、89.3と高い。「画面に何が書いてあるか」を読む力も93.7、87.0と高い。それなのに、一連の作業を最後までやり切る力は実機で42%にとどまる。部品は優秀なのに、通し運転で落ちるということです。
なぜ落ちるのか：位置ではなく「意味」を間違えている
論文が挙げている失敗の中身が、実務者には一番刺さります。アイコン認識の失敗の大半は、位置ずれではなく意味の取り違え（semantic gap）に起因すると明記されています。
つまり、こういうことです。AIは「この四角い図形がボタンである」ことは正確に見つけられる。しかし「そのボタンが保存なのか、送信なのか、削除なのか」を誤る。押す場所は当たっているのに、押す意味を外している。
自社の業務システムを思い浮かべてください。似た形のアイコンが並び、そのアプリを使い慣れた人だけが意味を知っている画面。あの手の画面こそ、この失敗が起きやすい構造をしています。見た目からは意味が読めず、社内の暗黙知でしか判別できないボタンが並んでいるからです。
論文はもう一つ、決定論的な安全弁も入れています。同一操作が3回連続で続いたら無限ループとみなして検知し、リフレクション工程に回す、というルールです。裏を返せば、こうしたルールを明示的に組み込まないと、画面操作AIは同じところをぐるぐる回るということでもあります。
学習データと環境をどこまで積んだのか
この論文の主張は「データと環境の同時スケーリング」です。投入量は次のとおり報告されています。
- 中間学習（mid-training）で、操作データ約50Bトークンと言語データ約300Bトークン。教師ありファインチューニング（SFT）段階は別途8.6Bトークン
- 操作データ収集に使ったサンドボックスおよび実デバイスのインスタンスは2,000台以上。内訳はAndroidWorld系が約500、実アプリ実機が約1,200、モックアプリVMが約1,000
- 自前で用意した模擬スマホ環境 PhoneWorld は34アプリ／34,000超タスク。実アプリのログイン制約を回避するためのモック環境
- 基盤モデル Hy3.0-VL-A3B のコンテキスト長は32Kトークンで、操作履歴をここに保持する
そしてここに、日本の中小企業にそのまま当てはまる制約が書かれています。オンライン強化学習に実際に使えた本物のアプリは、30本のみ。理由も明記されていて、アカウントログイン・SMS認証・実名認証が障壁になったためです。
2,000台以上のデバイスを用意できるチームでも、認証の壁の内側にあるアプリは30本しか練習台にできなかった。これは技術力の問題ではなく、環境の構造の問題です。AIエージェントの基本的な仕組みについてはAIエージェントとは何かも併せてご覧ください。
中小企業にとって、これは何を意味するのか
三点に整理します。
第一に、「RPAの代わりに画面操作AIを入れる」判断は、まだ早いということです。実機42%という数字は、10回頼んで6回は完遂しないことを意味します。受発注や経理の画面操作を人の確認なしに任せる段階ではありません。現時点で成立するのは、AIが操作して人が承認する半自動の形です。承認を挟めば、失敗の58%は「業務事故」ではなく「やり直し」に変わります。
第二に、自社システムほど不利だという構造の話です。論文でオンライン強化学習に使えた実アプリが30本にとどまった理由は、ログイン・SMS認証・実名認証でした。日本の業務システムの多くは、まさにその内側にあります。世に出回る画面操作AIは、あなたの会社の基幹画面を一度も見たことがないまま出荷されている。だから「有名なAIだから自社でも動くはず」という期待は、この論文の記述と噛み合いません。
第三に、それでも前向きな示唆があります。A3B級、つまり自前サーバでも動く規模のモデルで、AndroidWorld 82.6%という数字を出し、Gemini 3.1の80.2%を上回っている。画面操作AIが将来、クラウド課金なしに社内で回せる方向へ進む示唆です。手元で動かす選択肢の考え方はローカルLLMという選択肢で整理しています。あわせて、どこを自動化して良いかの線引きは業務自動化の進め方が参考になります。
この論文が書いていないこと
誠実に書きます。この論文には、判断材料として足りない部分があります。
- レイテンシ、ステップ数、トークンコストといった運用コスト指標が本文に一切示されていません。「効率的なGUIエージェント」を掲げる論文としては、ここが空いているのは不都合です。1タスクにいくらかかるのかが分からなければ、投資判断はできません
- ScreenSpot-Proでは66.5で、UI-Venus 1.5 A3Bの69.6、MobileAgent 3.5の71.1に負けています。モバイル特化の裏返しで、高解像度のデスクトップ画面は弱い。PC画面の自動化を期待するなら、この数字を先に見るべきです
- HyMobileQAでは87.0で、プロプライエタリのSeed 2.0 Proの89.4に届いていません。画面内容の理解では追いついていない領域があります
- MMBench-GUI L2の89.3も、Gemini 3.1の90.3にわずかに届きません
- 独立した限界（Limitations）節が設けられておらず、今後の課題の記述にとどまっています。何ができないかを体系的に列挙した箇所がない
- AndroidWorldのタスク数の記載がありません。82.6%という比率の母数が本文からは読み取れません
数字が良い論文ほど、書かれていない列を探す必要があります。評価の見方そのものについては自社の評価基準を持つも参考にしてください。
TOEの読み筋
はじめに明記します。TOEでは HyMobileAgent を未実施です。モデルの検証も、実機での再現も行っていません。以下は論文の数値と記述から立てた読みです。
読み筋は三つあります。
一つ目。画面操作AIの導入判断は「成功率」ではなく「失敗したときの回復コスト」で決めるべきだと考えています。42%という成功率でも、失敗が即座に検知できて、やり直しが数秒で済む業務なら成立します。逆に成功率が90%あっても、失敗が外部に出てしまう業務、たとえば発注確定や請求書送付には向きません。切り分ける軸は精度ではなく可逆性です。
二つ目。意味の取り違え（semantic gap）が主要な失敗要因だという記述から、社内でやるべき準備が見えます。画面のボタンやラベルに、人間の暗黙知でしか読めない表記が残っているほど、この種のAIは誤ります。UIの文言を明示的にする、操作手順を文章で残す、といった地味な整備が、そのまま将来の自動化率に効いてくる可能性があります。これはAI導入というより業務の言語化の話です。
三つ目。認証の壁が学習を妨げるという構造は、当面変わらないと見ています。ログイン・SMS認証・実名認証がある限り、汎用モデルは自社画面を学習できません。だとすれば、中小企業側でできることは「AIに学ばせる」より「AIが迷わない画面を選んで任せる」ことです。認証の内側にある基幹システムではなく、認証が軽く、失敗しても戻せる領域から試す。順序としてはそちらが先だと読んでいます。
いずれも論文からの推論であり、TOEでの実測ではありません。実運用で検証した際は、コスト指標も含めて改めて報告します。
まとめ
- HyMobileAgentは、整備済みベンチマークAndroidWorldで82.6%、実機の実アプリ環境HyMobileWorldで42%という二つの成功率を報告している（出典：arXiv:2607.14548、2026年7月16日（arXiv:2607.14548v1）、https://arxiv.org/abs/2607.14548v1）
- 差は40.6ポイント。論文自身がグラウンディング系の高スコアとエンドツーエンド成功率のギャップを認めている
- 失敗の大半は押す位置のずれではなく、そのボタンが何なのかを誤る意味の取り違え（semantic gap）に起因すると明記されている
- オンライン強化学習に使えた実アプリは30本のみ。理由はアカウントログイン・SMS認証・実名認証の壁で、日本の業務システムが学習対象になりにくい構造をそのまま説明している
- レイテンシ・ステップ数・トークンコストといった運用コスト指標が本文になく、独立した限界節も設けられていない。導入判断にはこの空白を自社で埋める必要がある
- 中小企業の現実解は「AIが操作し、人が承認する」半自動。TOEでは未実施であり、上記は論文記述からの読み筋である