Googleが、Androidアプリの機能をAIエージェントに直接開放するJetpack API「AppFunctions」の早期ベータを公開した。これはAndroidを「エージェントファースト」のOSに転換する、プラットフォームレベルの構造変更だ。
正直、このニュースのインパクトは大きい。これまでAIエージェントがスマホアプリと連携するには、画面操作の自動化かクラウドAPI経由しか手段がなかった。AppFunctionsは、その制約をOSレベルで取り払おうとしている。
この記事では、AppFunctionsの技術的な仕組みから、MCP（Model Context Protocol）との違い、そして開発者がいま何をすべきかまでを整理する。
何が発表されたのか
Googleは2026年2月にAndroid開発者ブログで「The Intelligent OS」と題した記事を公開し、AppFunctionsの構想を発表した。3月にはInfoQなど複数の技術メディアが詳細をレポートしている。
AppFunctionsの核心は単純だ。Androidアプリが自分の機能を「関数」として宣言し、AIエージェント（Gemini等）がそれを発見・実行できるようにする仕組みである。
具体的な流れはこうなる：
- 開発者がアプリ内の機能をAppFunctions Jetpackライブラリで宣言する
- アノテーションプロセッサがXMLスキーマファイルを自動生成する
- Android OSがそのスキーマをインデックスし、利用可能な関数を管理する
- AIエージェントが
AppFunctionManager経由でメタデータを取得し、関数を呼び出す
すべてがオンデバイスで実行される。クラウドを経由しないため、プライバシーとレイテンシの両面で有利だ。
| 項目 | 内容 |
|---|---|
| API名 | AppFunctions（Jetpackライブラリ） |
| 対応OS | Android 16以降（早期ベータ） |
| 実行環境 | 完全オンデバイス |
| 対応エージェント | Gemini Assistant（初期対応） |
| 現在の対応端末 | Galaxy S26シリーズ、Pixel 10の一部 |
| 正式展開 | Android 17で予定 |
| 公開日 | 2026年2月（構想発表）、3月（早期ベータ詳細） |
MCPのモバイル版？ 似て非なる設計思想
開発者なら真っ先に思うだろう。「これ、MCPと何が違うの？」と。
GoogleはAppFunctionsを「MCPのオンデバイス版」と位置づけている。MCPがクラウド上のサーバーサイドツールとAIエージェントをつなぐプロトコルなら、AppFunctionsはそれをAndroidデバイス上で実現するものだ。
| 比較軸 | MCP（Model Context Protocol） | AppFunctions |
|---|---|---|
| 実行場所 | 主にクラウド/サーバーサイド | 完全オンデバイス |
| 対象 | バックエンドサービス、開発ツール | Androidアプリの機能 |
| プライバシー | データがサーバーに送信される | デバイス内で完結 |
| レイテンシ | ネットワーク遅延あり | ネットワーク不要で高速 |
| 開発者の実装 | MCPサーバーの構築が必要 | Jetpackアノテーションで宣言 |
| 標準化状況 | Anthropic主導のオープン仕様 | Google独自のJetpack API |
要するに、MCPが「AIエージェントのためのWeb API」なら、AppFunctionsは「AIエージェントのためのAndroid Intent」に近い。アプリ間連携の概念をAIエージェント時代に再発明した形だ。
UI自動化フォールバックという現実解
ここが面白い。Googleは、すべてのアプリがAppFunctionsに即座に対応できないことを分かっている。
そこで用意されたのがUI自動化プラットフォームだ。AppFunctionsに非対応のアプリに対しても、AIエージェントが画面操作を通じてタスクを実行できる。「複雑なピザの注文」「複数停車地のライドシェア手配」「前回の食料品の再注文」といった例が公式ブログで紹介されている。
開発者の実装ゼロでエージェント連携が実現するのは、エコシステム立ち上げのフェーズでは賢い判断だ。ただし、UI自動化は構造化されたAppFunctionsに比べて不安定になりやすい。画面レイアウトの変更で壊れるリスクは常にある。
プライバシーとセキュリティの設計
エージェントがアプリを操作するとなると、セキュリティは最重要の関心事になる。Googleはこの点について、以下の設計原則を明示している：
- 完全なユーザー可視性 — ライブビューまたは通知で、エージェントが何をしているか常に確認できる
- 手動オーバーライド — ユーザーがいつでもエージェントの動作を上書きできる
- センシティブアクションの確認必須 — 購入などの操作には必ずユーザーの明示的な承認が必要
- オンデバイス実行 — データがクラウドに送信されないため、プライバシーリスクが構造的に低い
これはAnthropicのClaude Computer UseやOpenAIのOperatorが採用している「ユーザー確認ループ」と同じ方向性だ。業界全体で、エージェントの自律性と人間の監視のバランスポイントが収斂しつつある。
開発者が今週やるべきこと
AppFunctionsはまだ早期ベータだ。Android 17での正式展開までは時間がある。だが、今から動き始めるべき理由は3つある。
- 自アプリの「関数化」を設計する — アプリの核心機能のうち、AIエージェントに開放すべきものを洗い出す。「写真検索」「予約作成」「データ取得」など、入出力が明確な機能が候補になる
- 公式ドキュメントを読む — Jetpackライブラリのアノテーション仕様、XMLスキーマの構造、
AppFunctionManagerのAPIを把握しておく - MCP対応と並行して進める — バックエンドのMCP対応とモバイルのAppFunctions対応を並行設計すれば、クラウドとオンデバイスの両方でエージェント連携が可能になる
Galaxy S26やPixel 10を持っているなら、早期ベータを試せる。実機で動作を確認しておくと、正式版リリース時にアドバンテージになる。
この先どうなるか
AppFunctionsの登場で、モバイルOSの競争軸が変わる可能性がある。
Appleは2025年からSiriのAIエージェント化を進めているが、サードパーティアプリへの開放度はGoogleに比べて限定的だ。GoogleがAndroidを「エージェントのためのオープンプラットフォーム」として先にポジションを取れば、開発者エコシステムの囲い込みで大きなリードを得る。
もう一つの注目点は、マルチエージェント連携だ。現在のAppFunctionsはGemini Assistantが主なクライアントだが、将来的にサードパーティのAIエージェントがAppFunctionsを呼べるようになれば、デバイス上で複数のエージェントが協調する世界が見えてくる。
筆者も判断がつかないのは、この仕様がGoogleのエコシステム内に閉じるのか、それともオープンな標準になるのかという点だ。MCPがAnthropicの発案ながらオープン仕様として広がったように、AppFunctionsにも同様の展開があり得る。だが、現時点ではGoogle独自のJetpack APIであり、クロスプラットフォームの議論はまだない。
参考・出典
- The Intelligent OS: Making AI Agents — Android Developers Blog（参照日: 2026-03-30）
- Google Unveils AppFunctions to Connect AI Agents and Android Apps — InfoQ（参照日: 2026-03-30）
- AppFunctions Developer Documentation — Android Developers（参照日: 2026-03-30）
- Android AppFunctions and Gemini Integration — 9to5Google（参照日: 2026-03-30）
- Google Outlines How AI Agents Will Interact with Android Apps — Thurrott（参照日: 2026-03-30）
—
あわせて読みたい：
- A2Aプロトコルとは？MCPとの違いとマルチエージェント連携の新常識 — プロトコルレベルの全体像を把握したい方に
- Claude Coworkとは？PCを自律操作するAIエージェントの全貌と始め方 — デスクトップ側のエージェント動向との比較に
- お問い合わせ — AIエージェント導入のご相談はこちら
この記事はAIgent Lab編集部がお届けしました。
