【エグゼクティブ・サマリー】
GoogleはAndroidを「アプリを開いて操作する」パラダイムから「AIエージェントが代わりにタスクを実行する」エージェント・ファーストOSへと根本的に再設計し始めた。その中核をなす新Jetpackライブラリ「AppFunctions」は、アプリ側が機能をAIエージェントに宣言的に公開するための標準インターフェースであり、クラウドにおけるMCPサーバーのオンデバイス版と位置づけられる。この仕組みが普及すれば、アプリの価値評価軸は「DAU（デイリーアクティブユーザー）」から「エージェントによるタスク完遂率」へと移行し、モバイルエコシステムのビジネスモデルと開発者のアーキテクチャ設計思想が同時に塗り替えられる。
既存テクノロジーの限界と課題
現在のモバイルOSのパラダイムは、1990年代に確立されたデスクトップGUIの哲学を引き継いでいる。ユーザーがアプリアイコンをタップし、目的のアプリを起動し、その中のUIをナビゲートしながら段階的に操作を積み重ねる——この「アプリ中心モデル」は、人間がUIを直接操作することを大前提として設計されている。
しかしこのモデルには、AIエージェント時代における深刻な構造的欠陥がある。
まずインターオペラビリティの欠如が挙げられる。AndroidのInten機構やContent Providerは、アプリ間の連携を可能にしているが、それらは「データの受け渡し」に特化した仕組みであり、「特定の処理能力（Capability）をエージェントに宣言し、自然言語経由で呼び出せるようにする」という用途には根本的に対応していない。例えば「Samsung Galleryの写真検索機能」をGeminiが利用したいと思っても、現状のAPIやContentResolverではその「意図の橋渡し」が不可能だ。
次にクラウド依存の遅延とプライバシーリスクがある。現状のAIアシスタント（Siri、旧Google Assistant等）は、アプリの操作を実現しようとする際、多くのコンテキストをクラウドに送信して処理する必要がある。ネットワーク遅延（RTT）が発生するうえ、ユーザーのローカルデータがクラウドに送出されるプライバシーリスクも生じる。これは特に写真・メッセージ・位置情報といったセンシティブデータを含むタスクにおいて許容しがたいトレードオフだ。
さらにUI自動化の脆弱性も問題だ。従来のアクセシビリティAPI経由でUIを操作するアプローチ（画面上の要素を読み取って自動クリックする方式）は機能するが、アプリのUIが更新されるたびに壊れるリスクがあり、セマンティックな意図の伝達ではなく画面座標への依存度が高い。構造的に脆弱であり、スケールしない。
これらの課題を根本から解決するために、GoogleはOSレイヤーでの新しい抽象化レイヤーの必要性に至った。
ニュースの核心とアーキテクチャの優位性
Android Developers BlogにおいてプロダクトマネジメントVPのMatthew McCullough氏が発表した内容によると、GoogleはAndroidを「エージェント・ファーストOS」へと変革するための初期ベータ機能を公開した。その中核となるのが、Jetpackライブラリとして提供されるAppFunctionsだ。
Mirroring how backend capabilities are declared via MCP cloud servers, AppFunctions provides an on-device solution for Android apps. Much like WebMCP, it executes these functions locally on the device rather than on a server.
（訳：バックエンドの機能がMCPクラウドサーバーを通じて宣言されるのと同様に、AppFunctionsはAndroidアプリに向けたオンデバイスのソリューションを提供する。WebMCPと同様に、これらの関数はサーバーではなくデバイス上でローカルに実行される。）
この引用が示すように、AppFunctionsのアーキテクチャ上の本質は「MCPのオンデバイス実装」である。MCPとはAnthropic主導で策定が進むModel Context Protocol——AIエージェントが外部ツールや機能を呼び出すための標準プロトコルだ。クラウドMCPサーバーがLLMにバックエンドAPIを宣言的に公開するのと同じ思想を、端末内のアプリ機能に対して適用したのがAppFunctionsの本質的な位置づけと言える。
技術的な仕組みを整理すると次のようになる。
開発者はJetpackのAppFunctionsライブラリとplatform APIsを用いて、アプリ内の機能を「セルフ・ディスクライビング（自己記述型）な関数」として定義・公開する。この関数はGeminiなどのエージェントアプリがAndroidのOSレイヤーを通じて**ディスカバリー（発見）でき、自然言語からのリクエストをトリガーとして実行（Execute）**できる。実行はすべてデバイス内で完結するため、センシティブなデータがクラウドに送出されない。
また、AppFunctionsに対応していないアプリへの対応として、Googleは並行してUIオートメーションプラットフォームも提供している。これはアクセシビリティレイヤーをより高度に活用し、開発者側のコード変更ゼロでエージェントがアプリのUIを操作できる仕組みだ。Google Developerの公式ブログにはこう述べられている。
This is the platform doing the heavy lifting, so developers can get agentic reach with zero code. It’s a low-effort way to extend their reach without a major engineering lift right now.
（訳：これはプラットフォーム側が重労働を担う仕組みであり、開発者はコードなしでエージェント対応が可能になる。今すぐ大きなエンジニアリング投資をせずとも、リーチを拡大できる低コストな方法だ。）
InfoQの報道によると、AppFunctionsは現在Galaxy S26シリーズでの早期ベータとして展開されており、Android 17での広範なロールアウトが計画されている。具体的なユースケースとしてはGeminiへの「Samsung Galleryから猫の写真を見せて」というリクエストに対し、GeminiがAppFunctionを呼び出してSamsung Galleryから写真を取得しGemini画面上に表示するというシナリオが示されており、ユーザーはSamsung Galleryアプリを開く必要がない。返された写真はそのままGeminiのコンテキスト内で継続利用でき、「これを友人にテキストで送って」といったフォローアップ操作も連続して実行可能だ。
【図解】技術アーキテクチャ・関係図
【エンジニア視点】ITエコシステム・業界へのインパクト
1. アプリの価値評価軸の根本的な転換
現在のモバイルアプリビジネスは「いかにユーザーをアプリ内に引き込み、滞在時間を延ばすか」というエンゲージメント最大化モデルに依拠している。AppFunctionsが普及した世界では、ユーザーはアプリを「開かない」まま機能を消費する。
これはアプリ開発者にとって二律背反を突きつける。AppFunctionsを実装すればGemini経由でのタスク完遂率は上がるが、アプリ起動数・広告表示数は減る。つまりDAUや広告インプレッション数ベースの収益モデルとの根本的な非互換が発生する。今後のモバイルエコシステムでは、「エージェントに機能を提供した対価として収益を得るAPI課金モデル」や「タスク完遂単位でのサブスクリプション」への移行を迫られると推論される。
2. MCPエコシステムとの統合加速
AppFunctionsのアーキテクチャが「オンデバイスMCP」と位置づけられる以上、将来的にはMCP仕様との相互運用性の強化が期待される。バックエンドMCPサーバーで動くクラウドAPIと、AppFunctionsで公開されたオンデバイス機能を、同一のエージェントオーケストレーション層から呼び出せるようになれば、クラウドとエッジの機能を横断するマルチモーダルなエージェントワークフローが標準的なアーキテクチャパターンになる。
3. Appleのポジションへの圧力
iOS/macOSにおいてAppleはApple Intelligenceを発表し、Siri経由でアプリ操作を実現する仕組みを整備しつつある。しかしAppleのアプローチはApp Intentsという既存の仕組みを拡張するものであり、GoogleのAppFunctionsのように「MCPという業界標準プロトコルに明示的に接続する」姿勢は取っていない。オープンスタンダードへの接続を明言したGoogleのアプローチは、エコシステムの多様性という観点でAppleに対する差別化となり得る。
4. インフラエンジニアへの示唆：オンデバイス推論とデータ局所性
AppFunctionsがオンデバイス実行を原則とすることは、インフラアーキテクチャに直接影響する。すべてのFunction呼び出しと結果返却がデバイス内で完結するならば、従来型のモバイルバックエンド（APIゲートウェイ→マイクロサービス→DB）はエージェントとの直接通信パスとしての役割が相対的に低下する。一方で「エージェントが複数のAppFunctionを連鎖的に呼び出す際のオーケストレーション」をどこで実行するかという問題は残る。Gemini（クラウドLLM）がオーケストレーターとなる場合、Function定義のスキーマ情報はクラウドに送出される設計になるため、スキーマ情報のプライバシー管理（どこまでローカルで保持するか）が今後の実装詳細の焦点になると考えられる。
5. Android 17に向けた開発者の準備
現時点ではGalaxy S26とPixel 10の一部デバイスでのベータ展開にとどまるが、Android 17での一般公開を見据えれば、今から自社アプリのどの機能をAppFunctionとして公開すべきかを検討しておくことが、競合に対するアドバンテージになる。UI自動化フォールバックはゼロコードで対応できるため、まずはGemini側からのUI操作を受け入れる体験の確認を優先し、並行してAppFunctions実装の設計を進めるというアプローチが現実的だ。
まとめ
GoogleのAppFunctionsは単なる新しいAPIではない。「アプリを起動して操作する」というモバイルコンピューティングの30年来のパラダイムそのものを問い直す、OSアーキテクチャレベルの構造転換の宣言だ。オンデバイスMCPとも言うべきこの仕組みは、プライバシーを守りながらAIエージェントとアプリの橋渡しを実現し、クラウド側のMCPエコシステムとも思想的に接続している。
開発者にとってはビジネスモデルと設計思想の両面でのアップデートが求められる。アプリの「開かれ方」が問われる時代から、アプリの「使われ方」が問われる時代へ——AppFunctionsはその転換点を象徴するテクノロジーとして、2026年以降のモバイル開発のスタンダードを塗り替えていくだろう。
引用元記事
Google Unveils AppFunctions to Connect AI Agents and Android Apps
The Intelligent OS: Making AI agents more helpful for Android apps
コメント