Google I/O 2026 速報：Compose First 宣言と AppFunctions が示す、Android 開発の次のかたち（Android エンジニア視点）

エクストーンで Android エンジニアをしている石原です。日本時間の早朝に Google I/O 2026 の Keynote が終わったので、Android エンジニア視点で気になった発表を速報的にまとめます。Day 2 やオンデマンドコンテンツの内容は反映していないので、最新情報は公式ブログをご確認ください。

日本時間 5/20 早朝、Google I/O 2026 の Keynote が終わりました。例年通り Keynote 本体は Gemini と AI 一色で、Android そのものへの言及は最小限です。Android の本体は Developer Keynote と「What's new in Android」セッションに移されており、ここを追わないと開発者視点の話は何も拾えない構造になっています。

Android デベロッパーブログには「17 Things to know for Android developers at Google I/O」がアップされ、関連記事が一斉に公開されました。読んでみて、自分はこれは「ちょっとした年次アップデート」ではないなと感じました。Compose First の戦略宣言と、エージェント前提のツールチェーン整備が二段構えで来ています。

全体の見立て

今回の I/O で Google が踏み込んだのは、Android 開発を「人間が書く Android」と「エージェントが書く Android」の両方を、同じ Compose + Kotlin スタックに集約する方向です。Compose First が公式に宣言され、View 系のフレームワークが保守モードに入った一方で、Android CLI が 1.0 で安定化し、AI Studio から直接 Android ネイティブアプリを生成できるようになりました。AppFunctions API でアプリをエージェントから呼び出せるようにする仕組みも降りてきています。

つまり「Compose に寄せる」と「エージェントが書きやすい・呼びやすい状態に寄せる」が同じ方向を向いて進んでいます。これは設計判断のレベルで効いてくる話で、既存プロジェクトの Compose 化遅延や View 依存は、これまでとは違う意味の技術負債になり始めています。

Compose First 宣言と Compose 1.11

「Android UI development is Compose first」というタイトルの公式ブログで、android.widget、Fragment、RecyclerView、ViewPager はメンテナンスモードに入ったと明言されました。重大バグ修正のみが提供され、新規 UI は Compose で書くことが推奨されます。

Compose 1.11 の主な追加は以下です。

Styles API（experimental）：状態ベースの動的スタイル。pressed {} のような宣言で書ける
MediaQuery API（experimental）：UiMediaScope でウィンドウサイズやポインター精度を取得
Adaptive Grid / FlexBox（experimental）：CSS 風の 2D/1D レイアウトプリミティブ
Jetpack Navigation 3.1：マルチデバイス対応、Scene Decorators
Material 3 Expressive：MaterialExpressiveTheme が正式昇格、FAB Menu が Experimental 卒業
トラックパッド対応：TrackpadInjectionScope、組み込みフォーカスリング
Compose Test v2 API：StandardTestDispatcher がデフォルト

Widget も同じスタックに統一されました。Jetpack Glance が RemoteCompose ベースになり、モバイル・Wear・Auto のすべての Widget を Compose で書ける単一モデルになります。「Create My Widget」（自然言語からの Widget 生成）はユーザー向け機能ですが、その裏側はこの統一モデルです。

自分が関わっているプロジェクトは既に Compose 100% で書かれているので、ここは追い風として受け取っています。ただ、Glance への移行はまだ済んでいないので、中期的に検討する必要が出てきました。

エージェント前提のツールチェーン

ここが今回の I/O の本丸じゃないかと思っています。「Compose First」だけなら数年前から見えていた方向で、新しさはありません。ただ、それと並んでエージェント開発前提のツールが一斉に組み上がったことで、Android 開発のワークフロー自体が変わり始めています。

主要な発表を整理すると以下の通りです。

Android 開発エージェント関連の I/O 2026 発表

ツール	何ができるか
Android CLI 1.0（安定版）	Claude Code、Codex、Gemini から Android Studio の機能（semantic 解析、Compose プレビュー、SDK ダウンロード、実機実行）を叩ける
Google AI Studio で Android アプリ生成	プロンプトから Kotlin + Compose のネイティブアプリを生成、エミュレータ・実機デプロイ・Play 内部テスト連携まで完結
Migration Assistant	iOS / React Native / Web のアプリを Kotlin + Compose に変換（プレビュー）
Android Bench	Android 開発タスク用の LLM リーダーボード
Android Skills	Compose 移行・Navigation 3 移行などのスキルをオープンソース化
AppFunctions API（EAP）	アプリを MCP サーバ化、Gemini エージェントから呼び出し可能

特に AppFunctions API は読み方を変えるべきポイントだと感じました。これは「自社アプリをエージェントから呼ばれる対象として設計する」観点が、これからの Android 設計レビューの新しい論点になることを意味しています。弊社で開発しているアプリで言えば、記事取得・通知操作・マイリスト操作を AppFunctions として公開するかどうかが論点になります。公開する場合、関数公開境界の切り方、権限プロンプトの出し方、課金や送信のような高リスク操作の確認フローをどう設計するか、設計レビューで掘り下げるべきテーマがいくつも出てきそうです。

Spark Agent（クラウド常駐エージェント、ロック中もアプリ操作）まで含めて考えると、Google は「ユーザーが手で操作する Android」と「エージェントが代わりに操作する Android」を同じ OS の上で両立させようとしています。アプリ側の設計責任が一段増えた、というのが正直な感想です。

Android 17（API 37）の開発者影響

Android 17（API 37）で開発者に直接効いてくる変更を整理します。

大画面の resizability 強制：sw>600dp で UNIVERSAL_RESIZABLE_BY_DEFAULT が強制され、開発者オプトアウトが廃止
SMS OTP 保護拡張：targetSdk=37 のアプリは OTP メッセージへの programmatic アクセスが 3 時間遅延
ACCESS_LOCAL_NETWORK：LAN 内デバイス検出に新ランタイム権限が必須
Contact Picker：システムレベルピッカーで選択された連絡先のみ一時アクセス
EyeDropper API：画面キャプチャ権限なしで任意ピクセルの色取得
Lock-free MessageQueue 実装、GC 改善：パフォーマンス系の地味な底上げ
Continue On：タスクをデバイス間で移動（Apple の Handoff 相当）

resizability 強制は自分の関わるアプリにとって最も実害が出る変更です。Foldable や大画面でレイアウトが崩れないか、targetSdk=37 にする前に確認テストが要ります。Continue On は API 公開範囲と Push 連携の余地が読めないので、続報を待ちたいところです。

XR / Form Factor

Android XR SDK Developer Preview 4 が出て、SceneCore と ARCore for Jetpack XR がBeta 移行しました。SpatialGltfModel でネイティブ glTF、KhronosPbrMaterial、Geospatial API（Wired XR Glasses 向け）など、API レイヤが固まってきています。Keynote では Intelligent Eyewear（Gentle Monster / Warby Parker）が披露され、ハードウェアパートナーの存在が初めて示されました。

Googlebook 向けには Android Studio Canary に Desktop Emulator が追加されました。ChromeOS と Android の統合はずっと言われてきましたが、ここに来てようやく開発者側の現実的なターゲットになり始めた印象です。

自分の現場感覚で言えば、XR と Googlebook はまだ様子見で、Auto と Foldable のほうが先に効きます。Auto は Car App Library の拡張で駐車時の動画再生に対応するなど、メディア系アプリ寄りの強化が入っていますが、弊社で開発しているアプリの優先度はそこまで高くない、というのが今のところの自分の判断です。

弊社の Android チーム視点で何が効くか

弊社の Android チームから見て、今回の I/O で直近に効くものと中期で効くものを分けて整理します。

直近で対応を考えるもの

Android 17（API 37）への targetSdk 引き上げ準備：特に resizability 強制と SMS OTP 保護
Compose 1.11 の Adaptive Grid / FlexBox の導入検討：レイアウトコードが整理できる箇所がいくつかあるはず
Jetpack Glance への Widget 移行検討

中期で論点化しうるもの

AppFunctions API でのアプリ機能公開：エージェント時代の弊社アプリの立ち位置をどう取るか
Android CLI + Claude Code を社内開発フローに組み込むか
Migration Assistant は既に Compose 100% なので、社内では使わない

締め

正直、Compose First の宣言は予想していました。ただ、AppFunctions と Android CLI、AI Studio での Android アプリ生成が同時に出てきたことで、「Android 開発のワークフローが今ここで分岐する」感覚を持ったのは予想外でした。Compose 100% のプロジェクトですら、エージェント時代のアプリ設計をどう取るかは別問題で、ここからの 1 年で答えを作る必要がありそうです。

本記事の評価は筆者の経験と観測に基づくものです。技術選択はプロジェクトや企業により大きく異なります。技術動向は日々変化するため、最新情報の確認をお勧めします。

参考リンク