はじめに
Google I/O 26にて、Android開発者向けのアップデートがいくつか発表されていました。
公式ブログでは「17 Things to know for Android developers at Google I/O!」として、Android開発者が押さえておきたい内容がまとめられています。
今回はすべての内容を細かく紹介するというよりも、日々のAndroid開発に関係しそうなものを中心に自分なりに気になったポイントをまとめてみます。
Google I/O 26でAndroid開発者向けに発表されたこと
今回の発表では、Android開発に関するさまざまなアップデートが紹介されていました。
大きく見ると、以下のような方向性があるように感じました。
- AIエージェントを活用した開発ワークフロー
- Compose Firstを前提としたUI開発
- スマートフォン以外も含めたAdaptive対応
- Android 17に向けた対応
- Google Playやアプリの発見導線の変化
- メディア、パフォーマンス、品質改善に関するアップデート
こうして見ると単に新しいAPIが追加されたというよりも、Androidアプリ開発そのものの前提が少しずつ変わってきている印象があります。
気になったポイント
1. AIエージェントを前提にした開発ワークフロー
今回の発表で特に気になったのは、AIエージェントを活用した開発ワークフローです。
Android CLIやAndroid Studio関連のアップデートにより、AIエージェントがAndroid開発に関わる作業をより扱いやすくなる方向性が示されています。
たとえば、以下のような作業です。
- 警告やエラーの解析
- Compose Previewの確認
- UIテストの実行
- 既存コードの理解
- 実装補助やリファクタリング
これまでもAIを使ってコードを書くこと自体はできましたが、今後はIDEや開発ツールとより深く連携しながら開発フローの中に自然に入り込んでくるのだと思います。
個人的にはAIを単なるコード生成ツールとして見るのではなく、調査、実装、確認、修正のサイクルを一緒に回す存在として捉える必要がありそうだと感じました。
一方でAIに任せる範囲が広がるほど、最終的に何が正しいのかを判断するエンジニア側の理解も重要になります。
AIが便利になるほど設計意図や仕様理解、レビュー観点の重要性はむしろ上がっていきそうです。
2. AndroidはCompose Firstへ
次に気になったのは、Compose Firstという方向性です。
Googleは、AndroidのUI開発においてJetpack Composeを標準的な選択肢として位置づけています。
もちろん、既存のViewベースの実装がすぐになくなるわけではありません。
ただ、新規開発や今後のライブラリ、ガイダンスの方向性としては、Composeを前提にしたものが中心になっていくと考えてよさそうです。
これは実務でもかなり影響がありそうです。
たとえば、既存プロジェクトでは以下のような判断が必要になります。
- 新規画面をViewで作るのかComposeで作るのか
- 既存画面をどこまでCompose化するのか
- ViewとComposeを混在させる場合の設計をどうするのか
- Previewやテストをどう整備するのか
- チーム内でComposeの書き方をどう揃えるのか
Composeは便利ですが、自由度が高い分書き方が散らかりやすい側面もあります。
そのため、単にComposeを使うだけではなく、状態管理、画面分割、Preview、テスト、デザインシステムとの関係まで含めて考える必要がありそうです。
今後のAndroid開発では、Composeを前提にした設計力がより重要になっていくのではないかと思います。
3. Adaptive対応がより重要になっている
今回の発表ではAndroidがスマートフォンだけではなく、さまざまなデバイスに広がっていることも強く感じました。
タブレット、折りたたみ端末、車載、XR、外部ディスプレイなど、Androidアプリが動作する環境はどんどん広がっています。
これまでは、Androidアプリといえばスマートフォンを中心に考えることが多かったと思います。
しかし今後は画面サイズや入力方法、利用シーンの違いを前提にした設計がより重要になりそうです。
たとえば、以下のような観点です。
- 大画面でレイアウトが破綻しないか
- 折りたたみ端末で自然に表示できるか
- 横画面や分割表示に対応できるか
- タッチ以外の入力でも操作しやすいか
- 画面サイズごとに適切な情報量になっているか
特に業務アプリや長く使われるアプリでは、このあたりの対応が後から効いてきそうです。
最初からすべてのデバイスに完璧に対応する必要はないと思いますが、少なくともスマホの縦画面だけを前提にしすぎないことは、今後より意識していきたいポイントです。
4. Android 17に向けたパフォーマンスと挙動変更
Android 17に関する情報も紹介されていました。
具体的にはパフォーマンス改善やメモリ、権限、画面サイズ対応など、アプリ側でも確認が必要になりそうな変更が含まれています。
Androidのバージョンアップ対応は、毎年の恒例作業のように見えることもあります。
しかしtargetSdkVersionを上げるだけで終わるものではなく、挙動変更や権限まわり、バックグラウンド処理、画面表示などをきちんと確認する必要があります。
OSアップデート対応は地味に見えますが、ユーザー影響が大きい部分でもあります。
新機能を追うだけではなく、既存のアプリを安定して動かし続けるための確認もAndroid開発者にとって重要な仕事だと改めて感じました。
5. Google Playやアプリ発見導線の変化
Google Playに関するアップデートも気になりました。
アプリの品質やストア上での見え方、ユーザーとの接点は、開発者にとっても無視できない要素です。
アプリは作って終わりではなく、ユーザーに見つけてもらい使い続けてもらう必要があります。
そのためにはアプリ内の品質だけでなく、ストア掲載情報、レビュー、リリース運用、ユーザー体験全体を見ていく必要があります。
特に最近は、技術的な品質とプロダクトとしての見せ方がより近づいてきている印象があります。
クラッシュが少ないこと、パフォーマンスが良いこと、対応デバイスが広いこと、ストア上で魅力が伝わること。
これらは別々の話ではなく、アプリ全体の価値としてつながっているのだと思います。
実務で意識したいこと
今回の発表を見て、実務で意識したいと感じたことは大きく3つあります。
AIを使う前提で開発フローを考える
AIを使うこと自体は、すでに珍しいことではなくなってきました。
今後はAIをどう使うかだけではなく、チーム開発の中でどう取り入れるかが重要になりそうです。
たとえば、以下のような使い方が考えられます。
- 実装前の調査
- 既存コードの把握
- テストケースの洗い出し
- コードレビュー前のセルフチェック
- エラー調査
- ドキュメント整理
ただしAIの出力をそのまま信じるのではなく、最終的には人間が仕様や設計意図と照らし合わせて判断する必要があります。
AIをうまく使える人ほど、基礎的な理解やレビュー力がより問われるようになるのではないかと思います。
Composeを前提にした設計を考える
Compose Firstの流れを考えると、今後はComposeを前提にした設計を避けて通るのは難しくなりそうです。
既存プロジェクトでは、いきなり全面移行するのではなく、新規画面や一部コンポーネントから段階的に導入する形が現実的だと思います。
その際には、以下のような方針をチームで揃えておくとよさそうです。
- Composableの分割単位
- UI Stateの持ち方
- ViewModelとの責務分担
- Previewの書き方
- デザインコンポーネントの共通化
- テスト方針
Composeは書き始めやすい一方で、設計方針がないと画面ごとに書き方がばらつきやすいです。
そのため導入そのものよりも、継続的に保守できる形に整えることが重要になりそうです。
スマホ以外の体験も少しずつ考える
Adaptive対応についても、今後はより意識していきたいところです。
すべてのアプリが最初からタブレットや折りたたみ端末、車載、XRまで対応する必要はないと思います。
ただ、スマートフォンの縦画面だけを前提に作り続けると、後から対応が難しくなる可能性があります。
Adaptive対応は特別な機能というより、これからのAndroidアプリ品質の一部になっていくのかもしれません。
さいごに
この時期の技術トレンドの移り変わりは、見逃せないものがありますね。
新しい技術をただ追いかけるだけでなく、それをプロダクトにどう活かせるかまで考えることで、より良い開発につなげられるのではないかと思います。
今後もAndroid開発を取り巻く変化に注目しながら、自分たちの開発やプロダクトに取り入れられる部分を検討していきたいですね。