OpenPhone解説｜スマホを操作する3Bエージェント基盤モデル（HKU・ACL2026）

「OpenPhone」と聞くと、多くの人は米国のビジネス電話サービス（VoIP）を思い浮かべるかもしれません。しかし本記事で扱う OpenPhone は、それとはまったくの別物——香港大学（HKU）のData Intelligence Labが公開した、スマートフォンを操作するAIエージェントの基盤モデルです。ACL 2026に採択された研究（arXiv 2510.22009）で、MITライセンスのオープンソース。名前は衝突していますが、技術的には無関係な研究プロジェクトなので、まずはここを押さえてください。

このOpenPhoneが目指すのは、スマホの画面を「見て」、タップやスワイプで「操作する」AIを、端末の中だけで完結させることです。多くのAIエージェントは高価なクラウドAPIと大規模モデルに頼りますが、それでは端末での実運用に無理がある。プライバシー、遅延、コストの3つが立ちはだかります。OpenPhoneはこれを、わずか3Bパラメータのビジョン言語モデル（VLM）をオンデバイスで動かすことで解こうとします。本記事では、このOpenPhoneが何をするモデルで、なぜ3Bなのか、GUI×CLIハイブリッドのPhoneCLIとは何か、そして性能はどこまで出るのかを、公式リポジトリの一次情報から解説します。

AIエージェント全体の設計・比較は AIエージェントフレームワーク徹底比較2026：主要OSSの選び方 をご覧ください。

1. OpenPhone とは — スマホを操作する3Bエージェント

HKUDS/OpenPhone は、香港大学のData Intelligence Lab（Chao Huang教授のグループ）が公開した、モバイルエージェントの基盤モデルです。冒頭で触れたとおり、同名の商用電話サービスとは無関係で、こちらは「スマホのGUIを見て操作するAI」の研究プロジェクトです。ACL 2026 Findingsに採択され、論文・モデル重み・データセット・学習コード・評価環境まで一式が公開されています。

解こうとしている課題は明確です。ほとんどのAIエージェントは、高価なクラウドAPIと大規模モデルに依存しており、端末上での実運用には不向き——ユーザーは、スマホが何か操作するたびに外部サービスを呼ぶことで、プライバシー・遅延・高コストという3つの問題に直面します。スマホの画面には、メッセージ、写真、位置情報、決済といった機微な情報が映ります。それを操作のたびにクラウドへ送るのは、プライバシー上も好ましくありません。加えて、外部サービスへの往復は遅延を生み、リクエストごとの課金は積み重なればコストになります。OpenPhoneの解は、「初のオープンソース・3Bパラメータのエージェント基盤モデルを、端末上で完結して動かす」こと。これにより、プライバシーの懸念なし・クラウド依存なし・API費用ゼロを狙います。

。ここが、クラウドの巨大モデルに毎回問い合わせる従来型のスマホ自動化との決定的な違いです。

OpenPhone-3Bは、モバイルのGUIタスク向けに設計されたビジョン言語モデルです。画面の視覚的解釈、指示の理解、そして構造化された操作（アクション）の生成を、実際のモバイルタスクで学習しています。エッジネイティブ設計で、民生GPUやモバイルNPUと互換性があり、継続的なクラウド依存を排します。モデル重み・設定・推論スタックがフル公開されているため、コミュニティが自分で展開・開発できるのも特徴です。

このOpenPhoneを出したData Intelligence Labは、動画理解のエージェントなど、AIエージェント分野で継続的に成果を公開しているグループです。当サイトでも同ラボの VideoAgent 解説｜動画を丸ごと扱うオールインワンのAIエージェント を扱っており、「特定のモダリティ（動画・スマホGUIなど）に特化したエージェント基盤を、オープンに整備していく」という一貫した姿勢が見て取れます。OpenPhoneも、単発のデモではなく、モデル・データ・学習・評価・実行ツール（PhoneCLI）まで揃えた「研究基盤」として設計されている点が、その表れです。

読者が当サイトのOSS解説に求める「①結局何ができる／②何を解決する／③何を代替できる」に当てはめれば、OpenPhoneは「①スマホのGUIを見て自律的に操作する／②クラウド依存によるプライバシー・遅延・コストの問題を解決する／③毎回クラウドの大規模VLMに問い合わせる重いスマホ自動化を、端末内の小型モデルで代替する」研究基盤だと言えます。以降のセクションでは、この3点を「なぜ3Bか」「PhoneCLIとは何か」「性能はどこまで出るか」という順で掘り下げていきます。

2. なぜ3Bなのか — オンデバイスの現実解

OpenPhoneの設計思想を象徴するのが、「なぜ3Bなのか」という問いです。モバイルAIの未来は、モデルを大きくすることだけにあるのではなく、現実の制約の中で賢く・効率的にすることにある——というのが、このプロジェクトの立場です。

3Bが「スイートスポット」とされる理由を、リポジトリは具体的に挙げています。

・ハードウェア適合：3Bパラメータは、民生GPUのメモリ（8〜12GB）や、台頭するモバイルNPUの計算予算とよく噛み合う
・速度優位：3Bモデルは7B系より3〜5倍速い推論を出しつつ、サブ秒のGUI応答に十分な精度を保つ
・電力効率：小さなフットプリントはバッテリー持ちを延ばす。電力消費が体験に直結するモバイルでは必須
・プライバシー第一：端末内で完結するため、ネットワーク依存を排しながらユーザーのプライバシーを守れる
・コスト削減：ローカル処理により、高価なクラウドAPIとリクエスト毎の課金をなくせる

「大きいほど良い」という前提への、明確なアンチテーゼです。7B〜9Bのモデルに匹敵する性能を、高度な学習によって3Bで達成する——それがOpenPhone-3Bの狙いです。実際、後述する評価では、9B級のモデルに匹敵する性能を、コンパクトなアーキテクチャの展開優位を保ったまま出せると報告されています。エッジ端末で「大きいモデルは動かせない」という現実の前では、動かせる3Bが動かせない9Bに勝る、という価値観がここにあります。

この「動かせるかどうか」という視点は、クラウド前提のベンチマーク競争ではしばしば見落とされます。データセンターに潤沢なGPUがあれば、モデルは大きいほど成功率が上がる。しかしスマホやエッジ端末には、そんな余裕はありません。メモリは限られ、電力は貴重で、通信も常に安定するとは限らない。そうした制約下では、「ベンチマークのスコア」よりも「実際に端末で動いて、許容できる速度で応答するか」のほうが、はるかに実用的な指標になります。OpenPhoneが3Bにこだわるのは、この「実運用の制約から逆算する」視点に立っているからです。研究として面白いだけでなく、実際にポケットの中で動くエージェントを見据えている点に、このプロジェクトの現実志向が表れています。

小型モデルで7〜9B級を狙うために、OpenPhoneは学習に工夫を凝らしています。先進的なマルチモーダルLLMを使って高品質な推論チェーンの学習データを合成し（手作業のアノテーション不足を補う）、2段階の学習——SFTでGUIの基礎知識を注入し、GRPO系の強化学習でタスク完了精度を最適化する——を行います。この構造化された学習によって、3Bモデルが7〜9B級に匹敵するGUIタスク性能に届く、というのがOpenPhoneの主張です。単にモデルを小さくするのではなく、小さいモデルを賢く鍛える——そこにこのプロジェクトの技術的な核があります。

3. PhoneCLI — GUI×CLIハイブリッドという発想

2026年7月に加わった目玉が、PhoneCLI です。これは「CLIの信頼性」と「GUIエージェントの柔軟性」を組み合わせた、GUI×CLIハイブリッドのフォンエージェントで、OpenPhoneの実用性を一段引き上げます。

考えてみれば、私たちがスマホでやっていることの多くは、「Wi-Fiをオンにする」「今日の予定を確認する」「連絡先を検索する」といった、繰り返しの固定シーケンスです。同じアプリの、同じ画面の、同じボタンを、何度も押している。これをVLM駆動のGUI操作でやると、毎回「画面を見て→次にどこを押すか考えて→押す」を繰り返すため、遅く（1ステップ2〜5秒）、高価で（スクショごとにAPI呼び出し）、脆い（VLMが座標を幻覚する）。決まりきった操作のたびに、賢いモデルに「ここはどこ？次はどうする？」と尋ねるのは、明らかに無駄です。PhoneCLIは、ここに別のアプローチを持ち込みます。すべてのタスクを新規のGUI探索として扱うのではなく、アプリごとにナビゲーショングラフ（app map）を事前構築し、定型操作を決定論的なマクロとして再生するのです。VLMが呼ばれるのは、本当に必要なとき——新規タスク、検証、アプリ横断の推論——だけ。

その動作を図にすると、こうなります。

仕組みを分解すると、3段です。第一に、app mapの構築。BFSクローラがWebDriverAgent経由でアプリの全画面を体系的に探索し、タップ可能な要素・座標・画面間の遷移経路を記録します。各要素は「安定／動的」に分類され、LLMが意味的なメタデータで補強します。この地図は、画面をノード、要素を辺とするグラフとしてYAMLに構造化されます。たとえば「設定のトップ画面には Wi-Fi という要素があり、座標は正規化して[0.50, 0.15]、アプリ更新後も安定していて、タップすると次の画面に遷移する」といった情報が、画面ごとに記録されるわけです。一度この地図を作れば、以降は座標を「幻覚」する余地がありません。第二に、タスクの実行。エージェントは自然言語のタスクを特定のマクロ操作にマッピングし、決定論的に再生し、必要なら1枚のVLMスクショで検証します。多くの定型タスクはVLM呼び出し0〜1回で完了します。第三に、想定外への対応。マクロに合致しないタスク（例：「近くの遅くまで開いてるレストランを探して」）では、純粋なVLM推論にフォールバックし、必要なときだけGUIモードに優雅に切り替わります。

このハイブリッドの巧みさは、「速さ・安さ・確実さ」と「柔軟さ」を、状況に応じて使い分ける点にあります。定型操作は地図とマクロで高速・低コスト・確実に。未知の操作はVLMの推論で柔軟に。GUIエージェントが陥りがちな「毎回すべてをゼロから探索する非効率」と、マクロだけのRPAが陥りがちな「想定外に一切対応できない硬直」の、両方を避けているわけです。アプリの地図を作るのは初回に約10分の一度きりの作業で、あとはその投資が何度でも回収されます。実世界のスマホ操作が「同じ手順の繰り返し」に満ちていることを考えると、この設計が効く場面は非常に多いはずです。

4. デバイス-クラウド協調と、モバイル向けメモリ機構

OpenPhoneは「すべてを端末で」と主張するわけではありません。むしろ現実的に、デバイス-クラウド協調フレームワーク（Device-Cloud Collaboration） を備えています。タスクの複雑さをリアルタイムに評価し、端末モデルとクラウドモデルを動的に切り替える。簡単なものは端末で安く速く、難しいものは選択的にクラウドで補う——という役割分担です。

実測では、この協調がどう働くかも報告されています。クラウドモデルは依然として約65%のステップを担っており、これは小型のオンデバイスモデルが複雑な推論を苦手とする現実を反映しています。一方で、オンデバイス処理を導入することでクラウドAPI呼び出しを約10%削減でき、直接的なコスト削減と遅延低減につながります。興味深いことに、GLM-4.5Vのような高性能なクラウドモデルほど、単独でタスクを完了できるため、クラウド依存の削減幅は小さくなる傾向も観察されています。つまり「端末モデルがどれだけ肩代わりできるか」は、組み合わせるクラウドモデルの賢さにも依存するわけです。

この「約10%削減」という数字を、控えめだと見るか意義深いと見るかは、立場によって分かれるでしょう。現時点ではクラウドが大半を担っており、オンデバイスだけで完結するには小型モデルの推論力がまだ足りない。それでも、簡単なステップを端末で肩代わりできる分だけ、コストと遅延は着実に下がります。重要なのは、この協調が「静的な役割分担」ではなく、タスクの進捗や失敗パターンを見ながら動的に切り替わる点です。実行が順調なら端末に任せ、つまずいたらクラウドに委ねる——という調整が、リアルタイムの複雑さ評価にもとづいて行われます。オンデバイスとクラウドを二者択一で考えるのではなく、両者の良いところを場面ごとに取り込む、という現実的な折衷案がここにあります。

なぜ「協調」が必要なのか。単純に言えば、3Bのオンデバイスモデルだけでは、複雑な推論を要するタスクをこなしきれないからです。かといって、すべてをクラウドの大型モデルに投げれば、プライバシー・遅延・コストの問題が戻ってきてしまう。そこで「基本は端末、難所だけクラウド」という折衷にすることで、両者の弱点を打ち消し合う——これがデバイス-クラウド協調の狙いです。オンデバイスとクラウドは対立する選択肢ではなく、組み合わせて使うべき道具だ、という発想が根底にあります。

もう一つの工夫が、モバイル向けの効率的なメモリ機構です。リソースの限られた環境で長い手順をこなすため、OpenPhoneは次の3つを組み合わせます。

・長期の推論：多段の思考連鎖（chain-of-thought）に、反省的な誤り訂正を加えて意思決定を強化する
・テキストベースの要約：高解像度のスクリーンショットを、コンパクトなテキスト表現に圧縮してメモリを効率化する
・構造化された文脈保持：トークン使用を最適化し、資源制約下でも10〜20ステップの履歴文脈を保つ

スクリーンショットをそのまま溜め込めば、すぐにメモリもトークンも溢れます。それを「テキストに圧縮して要点だけ持つ」ことで、限られた端末資源でも長い操作手順を追えるようにする——このあたりの割り切りが、オンデバイスで動かすための現実的な工夫です。エージェントに「状態を持たせる」設計は、モバイルに限らずAIエージェント全般の中心課題であり、その考え方は everOS 解説｜AIエージェントに永続メモリを与える仕組み でも掘り下げています。OpenPhoneのメモリ機構は、それを「端末の資源制約」という厳しい条件下で成立させようとしている点に特徴があります。

ここで効いてくるのが、高解像度スクショをそのまま文脈に積むのではなく、テキスト要約に落として保持するという判断です。画像はトークン消費が大きく、10〜20ステップも積めば端末のメモリでは到底さばけません。要点をテキスト化して圧縮すれば、同じ履歴長でも桁違いに軽く保てる。長期の推論（多段の思考連鎖＋反省的な誤り訂正）と組み合わせることで、資源の限られた端末でも「前の画面で何をしたか」を踏まえた一貫した操作が可能になります。派手さはありませんが、オンデバイスという制約を成立させるための、地に足のついた設計だと言えます。

5. 性能と評価 — 小さくても戦えるのか

「3Bで本当に使えるのか」——ここが最大の関心事でしょう。OpenPhoneは、AndroidLabベンチマーク（138タスク）に加え、人気アプリでの25以上の追加タスクで評価されています。評価はAndroidLabのルールベース判定をLLMによる判定に置き換え、より正確なタスク完了評価を行っています。ルールベースの判定は「特定の文字列が出たか」といった機械的なチェックになりがちで、タスクが実質的に達成できているかを取りこぼすことがあります。LLMによる判定に置き換えることで、より人間の感覚に近い「本当にできたか」の評価ができる、という工夫です。

とりわけ説得力があるのが、推論速度の比較です。vLLMを使い、GPU構成を変えてステップあたりの平均推論時間を計測した結果が公開されています。

この表から読み取れることは、公平に見れば2つあります。第一に、OpenPhone-3Bは同条件（単一3090）で7BのQwen2.5-VLより成功率が高く（15.2 vs 10.1）、かつ速い（4171ms vs 6289ms）。第二に、9BのGLM-4.1V-9B-Thinkingは成功率こそ高い（24.6）が、2枚のGPUを要し、1ステップに約14.6秒もかかる。しかも単一の3090では動かせません。OpenPhoneは単一3090の3Bが、2枚の3090の9Bより約3.5倍速いと報告しています。

リポジトリは、評価から得られた知見も率直に整理しています。小さくても大きな性能——OpenPhone-3Bは9B級に匹敵する性能を、コンパクトなアーキテクチャの展開優位を保ったまま出せる。「大きいほど良い」という前提に挑む「小さな実力者」だとしています。競争力ある性能——独自モデルの軽量版と比べても遜色ない結果を標準ベンチマークで示し、コンパクトなオープンソースのアプローチが有望であることを裏づけます。デバイス-クラウドの協調が機能する——ハイブリッド構成が、クラウド利用を大きく減らしながら、ほぼ最適な性能を出せることを実証しています。そして長いプロンプトが常に効くとは限らない——拡張的なプロンプト戦略は、十分に高性能なクラウドモデルと組んだときにだけ効果を発揮する、という観察も加えています。推論の複雑さをモデルの能力に見合わせることの重要性を示す、地に足のついた知見です。

この正直な立ち位置は、むしろ好感が持てます。多くのプロジェクトが「最高性能」を謳いたがる中で、OpenPhoneは「絶対性能では大型に譲るが、動かせて速いことに価値がある」と、トレードオフを率直に認めています。評価の知見でも「長いプロンプトが常に効くわけではない」「クラウドが依然65%を担う」といった、都合の悪いデータまで開示している。研究として誠実であり、読む側も「どこまでできて、どこからが伸びしろか」を正しく把握できます。過大な期待をせず、しかしその方向性の意義は正当に評価する——そういう距離感で見るのが、このプロジェクトには合っています。

6. OpenPhone は何を代替し、誰に向くか

OpenPhoneが代替しようとしているのは、「毎回クラウドの巨大VLMに問い合わせる、重くて高価なスマホ自動化」です。プライバシーを気にせず、遅延を抑え、API費用をかけずに、スマホ操作をエージェントに任せたい——そういうニーズに、オンデバイスの3Bという解で応えます。

「スマホを操作するAI」というと、音声アシスタントの延長を思い浮かべるかもしれません。しかしOpenPhoneが扱うのは、もっと汎用的な「画面を見て、任意のアプリを操作する」能力です。特定のアプリがAPIを公開していなくても、画面さえ見えれば操作できる——これがGUIエージェントの強みです。OpenPhoneは、その汎用性を保ちながら、PhoneCLIのマクロで定型部分を高速化し、オンデバイスで動かすことでプライバシーとコストを両立させようとしています。まだ研究段階であり、絶対的な成功率には伸びしろがありますが、「端末の中で完結するモバイルエージェント」という方向性を、動くモデルと再現可能なレシピで示した意義は小さくありません。

このプロジェクトが向くのは、次のような人・チームです。

・オンデバイスのモバイルエージェントを研究・開発したい人：重み・データ・学習コード・評価環境が一式そろい、再現・拡張ができる
・プライバシーやコストの制約でクラウド前提のエージェントを避けたい人：端末内完結という選択肢を検討できる
・小型モデルの限界と可能性を見極めたい人：3Bで7〜9B級を狙う設計と、その正直なトレードオフが学べる
・スマホ操作の自動化基盤を自作したい人：PhoneCLIのapp map＋マクロという発想が、実装の設計指針になる

導入面では、モデル重みとデータセットがHugging Faceで公開され、vLLM向けの推論スクリプトが同梱されています。評価はAndroidLab（AVD on Macを推奨環境として検証）で行え、PhoneCLIはiOS端末上でapp mapを構築して自律タスクを実行できます。学習は2段階（GUIの基礎を注入するSFTと、タスク完了精度を最適化するGRPO系の強化学習）で、合成GUIデータを用いる再現可能なレシピとして文書化されています。研究基盤としての完成度が高く、モバイルエージェントに取り組む人にとって、貴重な足場になるはずです。

具体的な始め方としては、まずAndroidLabの環境を整え、Hugging Faceからモデル重みを取得してvLLMでサービング、評価パイプラインに接続する、という流れになります。単一タスクのテストからバッチ評価まで、スクリプトが用意されています。PhoneCLIを試すなら、対象アプリのマップを一度構築（約10分）してから、自然言語でタスクを与える形です。同梱の8アプリ（微博・foodpanda・カレンダーなど）は最初から使えるので、自分でマップを作る前に挙動を確かめられます。もちろん、これは研究用のセットアップであり、一般ユーザーがすぐスマホに入れて使える完成品ではありません。あくまで「オンデバイスのモバイルエージェントを、自分で動かし・改造し・評価するための基盤」として捉えるのが正確です。とはいえ、モデル・データ・学習・評価・実行ツールがここまで揃ったオープンソースは貴重で、この分野に踏み込む研究者や開発者にとって、出発点として申し分ありません。

まとめ

本記事では、香港大学が公開したスマホ操作エージェントの基盤モデル、OpenPhoneを、公式リポジトリと論文の一次情報にもとづいて解説しました（商用の同名VoIPサービスとは別物です）。

その核心は、「クラウドの巨大モデルに毎回頼るのではなく、端末内で完結する小さな3Bモデルでスマホを操作する」という発想にあります。3Bという現実的なサイズ選択、PhoneCLIのapp map＋マクロ再生によるVLM呼び出しの激減、デバイス-クラウド協調による動的な役割分担、そしてスクショをテキストに圧縮するメモリ機構——いずれも「エッジで実際に動かす」制約から逆算された工夫です。ベンチマークのスコアを最大化するのではなく、限られた端末資源の中で実用に足る性能を出す、という方向に一貫して振り切っている点が、このプロジェクトの個性です。絶対的なタスク成功率では大型モデルに及ばない場面もありますが、速度・プライバシー・コストを重視するオンデバイス用途では、動かせて速い3Bの価値が際立ちます。モデル重み・データ・学習コードまで公開されており、モバイルエージェントの研究・実装に取り組むなら、まず押さえておきたい一本です。スマホの中で完結するエージェントという方向性が、今後どこまで実用に近づくのか——その最前線を、一次情報として追う価値があります。

参照ソース

・OpenPhone（HKUDS 公式リポジトリ） — 本記事が解説した一次情報。モデル・PhoneCLI・評価・学習コードのすべて
・OpenPhone: Mobile Agentic Foundation Models for AI Phone（arXiv 2510.22009） — ACL 2026採択の論文
・AndroidLab（ベンチマーク・THUDM） — OpenPhoneが評価に用いるモバイルエージェント・ベンチマーク