Reval Labsは2026年10月21日、スマートフォンの画面を認識し、タップや文字入力を代行する操作AI「Opposable」について、Android端末上で動作するAIモデルの実装と性能評価の結果を公開した。約20億パラメーターの小型モデルを使用し、外部のAIサービスに接続しなくてもスマートフォンを操作できる仕組みだ。Galaxy S25のNPUでは、画面の画像処理を236ミリ秒で実行できたという。ただし、これは画像処理部分だけの測定値であり、操作全体にかかる時間を示すものではない。スマートフォンの操作をAIに任せるうえでは、画面認識の速度だけでなく、指示された作業を確実に完了できるか、決済などに必要な所有者の承認を適切に保護できるかが重要になる。

AD

約40種類の定型作業はAIを使わずに処理

Opposableは、Androidのユーザー補助サービスを利用して他のアプリの画面を読み取り、ボタンのタップや文字入力を実行する。画面上の要素について、ラベルや位置を番号付きの一覧として取得できるため、外部のAIエージェントは画像からボタンの座標を推測する必要がなく、操作したい要素を直接指定できる。写真や地図など、画面の視覚的な情報が必要な場合には、スクリーンショットも利用する仕組みだ。

Claude CodeやCodexなどのAIエージェントとは、AIと外部ツールを接続する規格「MCP（Model Context Protocol）」を通じて連携する。Android 11以降の端末に対応しており、APK形式のアプリをインストールし、ユーザー補助サービスへのアクセス権限を与える必要がある。スマートフォンとコンピューターを同じWi-FiネットワークやUSBで接続する場合は無料で利用できるが、遠隔リレー機能は14日間の試用期間が終了するとPro契約が必要になる。外部のAIサービスを利用する場合には、そのサービスの利用条件や料金も別途適用される。

ただし、Opposableはすべての操作をAIモデルに判断させるわけではない。開発者によると、アラームの設定、連絡先へのメッセージ送信、Wi-Fiの切り替えなど、約40種類の定型作業はあらかじめ用意されたコードで処理し、最後に画面を確認して実行結果を検証する。また、外部のAIエージェントが一度実行した操作は、画面上の文字情報と結び付けた手順として保存できる。同じ作業を繰り返す際には保存済みの手順を再生するため、毎回AIモデルを呼び出す必要がない。

こうした定型処理や保存済みの手順では対応できない作業を担うのが、端末内で動作する画面認識モデルだ。採用したのは、AlibabaのMobile-Agentチームが開発した「GUI-Owl 1.5 2B」で、llama.cppのマルチモーダル機能を使って実行する。GUI-Owl 1.5 2BはQwen3-VLを追加学習したモデルで、4ビット量子化した言語モデル部分の容量は1.05GB、画像エンコーダーは445MBとなっている。画像エンコーダーは、スクリーンショットを言語モデルが処理できる情報に変換する役割を担う。

この設計の利点は、繰り返し発生する操作を固定コードや保存済みの手順に任せることで、AIモデルの呼び出し回数を減らせる点にある。単発のタイマー設定などでは効果が分かりにくいものの、同じ操作を何度も繰り返す業務や、実機を使ったアプリの動作確認では有用性が高まる可能性がある。公式サイトでも開発者向けの用途として、自作アプリを実際の利用者のように操作し、不具合を発見する使い方を紹介している。

iPhoneへの対応はAndroidとは異なる方式を採用している。ベータ版のMacアプリを介し、BluetoothキーボードとポインターとしてiPhoneに接続する一方、画面情報はUSBまたは現行の公式サイトで案内されているAirPlay経由で取得する。iPhone側でAssistiveTouchを有効にすることで、マウス操作を画面のタップとして伝える仕組みだ。したがって、Android向けの端末内AIモデルがそのままiPhone上で動作するわけではない。また、開発者によると、この方式ではFace IDによる認証を通過できず、Apple Payの承認に必要なサイドボタンの操作にも対応できない。

「16倍高速」は画像処理部分の測定結果

Reval Labsが公開した技術記事では、端末内でのAI実行を高速化するために行った最適化と、その効果が説明されている。Apple M2を搭載したMacでCPUの4スレッドを使用した場合、画面を読み取って一つの操作を出力するまでの時間は、最適化前の10.6秒から7.3秒に短縮された。正解率については、評価対象となった36画面のうち27画面で正しい操作を選択する成績を維持したという。

最適化では、まず画面の上下にある不要な部分を切り取り、モデルが処理する画像データを削減した。さらに、単調な背景部分に対応する画像トークンを減らし、毎回共通する指示文の処理にはキャッシュを活用している。また、モデルが出力した「Filesアプリを押す」といった操作意図が、ユーザー補助サービスから取得した画面要素と一意に対応する場合には、その要素を直接操作して生成を終了する。これにより、モデルが画面上の座標を最後まで生成する処理を省略できる。

Galaxy S25では、処理をさらに高速化するため、画像エンコーダーのみをNPUへ移している。開発者によると、Qualcomm AI Hubを通じた実機ラボでの測定では、416×960ピクセルの画像を半精度浮動小数点（FP16）形式で処理するのに236ミリ秒かかった。比較対象となるM2のCPUでは同じ処理に3.9秒を要しており、画像エンコーダー単体では約16倍の高速化となる。

開発者が公開した主な評価結果を、測定対象ごとに整理すると次のようになる。

評価対象 環境と結果 評価結果から分かること
画面から一つの操作を出力する処理 M2 CPU・4スレッドで10.6秒から7.3秒に短縮。36画面中27画面で正解 CPU上での一操作あたりの処理時間。作業全体の完遂率ではない
画像エンコーダー単体 Galaxy S25のNPUで236ミリ秒、比較対象のM2 CPUで3.9秒 画像処理部分は約16倍高速。指示の読み込みや回答生成は含まない
未調整の8課題を完了する評価 Androidエミュレーターで各方式を2回実行。一括指示では4件と3件、作業の分割と結果確認を組み合わせた方式では両方とも6件成功 小目標への分割と結果確認の効果を示す小規模な評価。実機全般の成功率には当てはめられない

注意すべきなのは、画像エンコーダー単体で測定された約16倍という速度差が、スマートフォン操作全体の高速化率を意味するわけではないことだ。実際の操作では、画像処理に加えて言語モデルによる入力の読み込みや回答生成も必要になる。開発者も別の技術記事で、実機における全工程を通した処理時間はまだ測定していないと説明している。また、NPU向けの実装は現時点でSnapdragonに限られ、GoogleのTensorやMediaTek、Exynosを搭載する端末ではGPUまたはCPUを使用する。

公式サイトで公開されているデモ動画も、端末内モデルの性能とは区別して評価する必要がある。Claude CodeをMCP経由で接続し、ダークテーマへの切り替えと5分間のタイマー設定を行う例では、処理に50秒かかり、ツールの呼び出し回数は17回だった。別のWikipedia検索のデモでは118秒を要し、外部AIの利用料金は0.44ドルとなっている。これらはいずれも外部AIを使用した個別の実行記録であり、端末内モデル単体の処理速度や、固定コードによる定型作業の所要時間を測定したものではない。現行版のすべての操作に適用できる性能指標でもない。

一方、Androidエミュレーターで実施した8課題の評価では、モデルの推論速度よりも、作業を小さな目標に分けて結果を確認する方法が効果を発揮した。モデルに一度の指示ですべてを完了させるのではなく、段階的に小目標を与え、成功したというモデル自身の申告をユーザー補助ツリーの情報と照合する方式に変更したところ、2回の試行でいずれも6課題を完了できた。ユーザー補助ツリーとは、画面上のボタンやテキストなどの構造を表す情報であり、操作後の画面状態を確認するために利用できる。今回の結果は、AIが素早く操作を出力できることと、指示された作業が実際に完了していることを、別々に評価する必要があると示唆している。

AD

決済や認証の最終承認をAIから切り離せるか

スマートフォンの操作をAIに任せるうえで、処理性能と並んで重要になるのが権限管理だ。開発者は、Opposableに組み込まれた決済保護機能の検証中に見つかった不具合についても公表している。当初はタップ対象となるボタンの文言だけで決済操作を判定していたため、金額表示の下にある単なる「Confirm」ボタンや、ラベルのないボタンなどを検出できなかったという。この問題を受け、現在はボタンの文言だけでなく、画面全体の内容やアプリの情報も考慮するよう変更した。

さらに、この修正を検証する過程で、承認処理に関する三つの問題が見つかった。一つ目は、AI自身が通知パネルを開き、自ら実行した支払いに対する「Approve」ボタンを押せてしまう問題だ。二つ目は、自動ポップアップ処理が、保留中の承認要求に表示された「Deny」ボタンを誤って押すケースである。三つ目は、USB接続時にデバッグ用の操作経路へ切り替わり、本来必要な承認確認を経ずに送金テストを実行できてしまう問題だった。

開発者は、これら三つの問題をすべて修正したと説明している。バージョン0.4.3以降では、承認要求が表示されている間、AIエージェントによる該当画面へのタップを拒否する仕組みを導入したという。ただし、これは開発者自身による修正報告であり、第三者によるセキュリティ監査で安全性が確認されたことを意味しない。

これらの不具合が浮き彫りにしたのは、AIが指示に忠実に動作することと、所有者の承認を適切に保護できることは別の問題だという点である。決済時に確認画面を表示する仕組みがあっても、AIが通知パネルや別の操作経路から承認ボタンを押せるのであれば、本人確認の役割を果たせない。また、通常の操作経路で制限が機能していても、USBデバッグなど別の経路から同じ操作を実行できるなら、保護を回避される可能性が残る。所有者による最終承認を確実に守るには、AIが利用できるすべての操作経路を対象に権限を制限する必要がある。

権限の強さについては、Opposableの公式FAQでも注意が促されている。開発元は、アクセストークンを持つ人が端末を操作できるため、パスワードと同様に厳重に管理するよう求めている。画面を読み取り、アプリをまたいでタップや文字入力を実行できる権限は、それだけ広範な操作を許すことになる。AIにどこまで操作を任せるかだけでなく、その操作権限を誰が利用できるのかも重要な管理対象だ。

また、端末内でAIモデルを動かすことと、すべての画面情報が端末内にとどまることも同じではない。開発元のプライバシーに関する説明によると、端末内モデルによる推論では画面データを外部へ送信しない。一方、遠隔リレー機能を使用すると、画面内容を含む可能性のある要求と応答がサーバーを経由する。開発元はリレーサーバーに画面内容を保存しないと説明しているが、外部AIに操作を任せる構成まで含めて、すべての処理が端末内で完結すると捉えるのは正確ではない。

Opposableの特徴は、約20億パラメーターの小型モデルをスマートフォン上で動かすことだけではない。定型処理や保存済みの操作手順を組み合わせ、AIモデルを必要な場面に限定することで、処理時間や外部サービスへの依存を減らそうとしている点にもある。ただし、現時点で公開されている性能評価は限定的であり、実機で複雑な作業をどれだけ確実に完了できるかは、今後の検証が必要だ。同時に、通知やデバッグ機能を含むあらゆる操作経路で、AIが所有者の承認を代行できないことも確認しなければならない。反復作業の効率化と最終的な決定権の保護を両立できるかが、こうしたスマートフォン操作AIの実用性を左右することになる。