Gemini Intelligenceが示す「OS内エージェント」の現実味

過去24時間の生成AI・LLM関連発表で注目したいのは、Googleが2026年5月12日に発表したAndroid向けの「Gemini Intelligence」です。これは単なるGeminiアプリの機能追加ではなく、Androidを「操作されるOS」から「ユーザーの意図を受けて複数アプリを動かす知能システム」へ寄せていく発表です。Googleは、Gemini Intelligenceを最新のSamsung GalaxyおよびGoogle Pixel端末から今夏段階的に展開し、その後ウォッチ、車、グラス、ラップトップにも広げるとしています。(blog.google)

今回の核心は、モデル性能そのものではなく「LLMがどこに接続されるか」です。従来のスマホAIは、質問に答える、文章を要約する、画像を説明する、といった“アプリ内の補助機能”に近いものでした。Gemini Intelligenceでは、食品注文、配車、買い物カート作成、フォーム入力、Web上の比較・要約、音声メモの整形、自然言語によるウィジェット生成など、複数のUI操作をまたぐタスクが前面に出ています。特に、画面や画像の文脈をGeminiに渡し、ユーザーの指示に基づいて別アプリ上の行動へ変換する点は、スマートフォン上のエージェント化として重要です。(blog.google)

技術的に面白いのは、Googleが2つの経路を並べていることです。ひとつは、アプリ側の大きな実装変更なしにGeminiがUIを操作する「タスク自動化」。もうひとつは、開発者がアプリの機能を明示的にOSへ登録する「AppFunctions」です。Android Developers Blogでは、Geminiが選択されたアプリ上で複雑な複数ステップのタスクを実行できるようにしつつ、開発者にはAppFunctionsによってサービス、データ、アクションをOSやエージェントへ提供する道を用意すると説明されています。(android-developers.googleblog.com)

AppFunctionsは、今回の発表の中でも実装面で最も注目すべき部分です。Googleの開発者ドキュメントでは、AppFunctionsをAndroidプラットフォームAPIとJetpackライブラリの組み合わせと位置づけ、アプリをオンデバイスのMCPサーバーのように振る舞わせる仕組みだと説明しています。つまり、アプリは「メッセージを送る」「ノートを作る」「リマインダーを登録する」といった機能を、エージェントが発見・実行できるツールとして公開できるわけです。現時点ではGeminiとの統合は信頼されたテスター向けのプライベートプレビューで、Android 16以降が対象とされています。(developer.android.com)

これはMCP的な発想をモバイルOSに持ち込む動きです。ただし、サーバーサイドのMCPと違い、AppFunctionsはAndroid上のローカルなOSレベルのフックとして設計されており、既存アプリの状態を直接使えること、外部サービスを別途維持しなくてよいことが強調されています。一方で、関数の発見・実行にはEXECUTE_APP_FUNCTIONS権限が関係し、実験段階では限られたアプリとシステムエージェントのみがパイプライン全体へアクセスできるとされています。(developer.android.com)

この発表が重要なのは、LLMエージェントの競争軸が「チャット画面の賢さ」から「日常的なソフトウェア環境にどれだけ安全に接続できるか」へ移っていることを示しているからです。スマートフォンは、予定、連絡先、決済、移動、写真、メッセージ、ブラウザ、業務アプリが集まる最も密度の高い個人コンピューティング環境です。そこにLLMが深く入ると、便利さは大きく増しますが、誤操作、過剰な権限、意図しないデータ参照、責任境界の曖昧さも同時に増えます。

Googleは発表の中で、Gemini Intelligenceはユーザーの指示で動き、作業中の進行状況は通知で追跡でき、最終確認はユーザーが行うという制御の考え方を示しています。また、Autofill with GoogleとGeminiの接続はオプトインで、設定からオン・オフできると説明されています。これらは重要な設計ですが、実際の使いやすさと安全性は、確認UI、失敗時の巻き戻し、アプリごとの権限粒度、第三者アプリが公開するAppFunctionsの品質管理に左右されます。(blog.google)

開発者にとっては、SEOやアプリ内検索最適化に似た新しい課題が生まれます。これまでは、人間が画面を見てボタンを押し、アプリの導線をたどっていました。今後は、エージェントがアプリの機能を「ツール」として理解し、ユーザー意図に合うものを選ぶ場面が増えます。すると、アプリはUIだけでなく、機能の意味、入力パラメータ、失敗条件、確認手順を機械に分かる形で表現する必要があります。AppFunctionsは、そのための初期的な標準化レイヤーと見られます。

ただし、現段階で「スマホが完全自律エージェントになる」と見るのは早いでしょう。対象端末、対応アプリ、地域、権限、実行可能なタスク範囲はいずれも段階的です。UI操作型の自動化は、アプリ側の画面変更やログイン状態、確認ダイアログに弱くなりがちです。一方、AppFunctions型は堅牢ですが、開発者側の実装と審査、OSとの連携が必要です。Googleが両方を併用しているのは、短期的には既存アプリを動かす必要があり、長期的には明示的なツールAPIへ移したいからだと読めます。

今後の注目点は3つです。第一に、AppFunctionsがどれだけ広く一般開発者へ開放されるか。第二に、ユーザーが「何を許可したか」を理解し続けられるUIが作れるか。第三に、Android以外のエコシステム、特にブラウザ、デスクトップOS、業務SaaSとの間で、エージェント向けツール記述がどこまで標準化されるかです。

今回のGemini Intelligenceは、派手な新モデル発表ではありません。しかし、生成AIが実際の生活や業務に入っていくうえでは、モデル単体の賢さよりも、OS、権限、アプリ、UI、確認フローの設計のほうが重要になる局面が増えています。LLMの次の主戦場は、会話欄の中ではなく、ユーザーの環境全体をどう安全に動かすかに移りつつあります。

出典: Google公式ブログ、Android Developers Blog、Android Developers AppFunctionsドキュメント。(blog.google)