※本記事は、Don Turner氏とJose Alcérreca氏による動画「Make your UI adaptive with Android Studio's AI agent」の内容を基に作成されています。動画はGoogle I/O 2026のAndroidセッションの一つとして公開されており、詳細情報は https://goo.gle/Android-at-IO2026 でご覧いただけます。また、Android Developersのチャンネル登録は https://goo.gle/AndroidDevs から可能です。本記事では、動画の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
Don Turner氏とJose Alcérreca氏は、Android Studioの新しいAIエージェント機能について本セッションで登壇し、Navigation 3への移行、実験的なデバイスケイパビリティAPI、そしてWebにインスパイアされたFlexBoxやGridといったアダプティブレイアウトAPIを活用し、デスクトップやタブレット、折りたたみ端末など多様なフォームファクターに対応するUIを構築する手法を紹介しています。
1. 導入:フォームファクターという概念の限界とUI capabilitiesへの転換
1.1 フォームファクター定義の曖昧さを示す挙手アンケート実験
Don Turner: 今日は皆さんに、モバイルとラージスクリーン、両方のフォームファクターに向けたアダプティブUIの構築についてお話しします。一般的に、アダプティブUIを構築しようと考えるとき、まず異なるフォームファクターでの見え方から考え始めることが多いと思います。電話から始まり、タブレット、折りたたみ端末、ノートパソコン、デスクトップ、テレビ、車など、さまざまなフォームファクターを検討していくことになります。フォームファクターとは、デバイスのサイズと機能性を抽象化したものであり、あるクラスのデバイス群についてアプリがどのように見えるべきかを議論するための共通の語彙を私たちに与えてくれます。結局のところ、私たちは皆、タブレットが何であるかを知っていますよね。それでは、実際に試してみましょう。これがタブレットだと思う方は手を挙げてください。
Don Turner: はい、だいたい75%から80%ですね。ここではおおむね意見が一致しているようです。では次はどうでしょうか。これは同じデバイスを、充電ドックにキーボードとマウスを接続した状態にしたものです。これをタブレットだと思いますか。今回は約50%程度でした。では最後にもう一つ、これはどうでしょうか。今度は20%ほどでしょうか。つまり、私たちはタブレットが何であるかについて、実は意見が一致していないということです。
Don Turner: これはなかなか面白いので、もう一つ試してみましょう。これは電話でしょうか。モニターに接続されていない状態であれば、間違いなく電話です。しかし、モニターに接続されると、何か別のものになるのでしょうか。ここで私が伝えたいのは、私たちはフォームファクターが何であるかについて、実は意見が一致していないということです。デバイスは複数のフォームファクターを持ちうりますし、それらの間を瞬時に切り替えることができますし、時にはどのフォームファクターのカテゴリーにもきれいに当てはまらないこともあります。
1.2 フォームファクター別設計の限界とUI capabilitiesへの転換提案
Don Turner: つまり、これが意味するのは、フォームファクターというものは、私たちがかつて考えていたほどには、UI設計にとって有用ではないということです。また、フォームファクター固有のUIを作成することは、コードの分岐や、重複コードを多く含む複数のコードベース、そして多くの保守作業の必要性につながりかねません。そこで、より良いアプローチとして、ウィンドウサイズやポインタの種類といったUIケイパビリティに向けて設計・開発を行うという考え方があります。
Don Turner: このアプローチによって、フォームファクターが何であるかにかかわらず、最適なUIを作成することができます。そして今日ご紹介するAPIやツールを使えば、それは高コストな投資である必要はありません。もしかしたら、案外楽しい作業になるかもしれません。
Jose Alcérreca: それでは、このセッションでは、Donがアダプティブ APIに焦点を当ててお話しし、私からはAIエージェントを使ってどのように変更を実装できるかをお見せします。
2. AIエージェント時代の新リソース群
2.1 AIエージェントによる適応化支援と新API対応の課題
Jose Alcérreca: 良いニュースとしては、AIエージェントを使うことで、この作業がずっと簡単に、そしてずっと速くできるようになるということです。レイアウトを適応させたり、リグレッションテストを作成したり、コードをリファクタリングしたり、最新のAPIへ移行したりすることができます。そして今回のセッションでは、新しいAPIについても多く取り上げます。問題は、モデルがまだそれらのAPIについて知らない可能性があるということです。だからこそ、私たちは大規模言語モデルを、最新の知識で補完する必要があります。
Jose Alcérreca: これを行えば、精度が大幅に向上します。そのために、私たちはAndroid開発者の皆さんに知っておいていただきたい、そして使っていただきたい、2つの重要なリソースを公開しました。
2.2 Knowledge Base・公式スキル・Android CLI・新発表のAdaptive Skill
Jose Alcérreca: まず1つ目がKnowledge Baseです。これは、主にAndroidの公式ドキュメントから、Firebase、Google Play、Kotlin、Google Developersなどを含む、数千件に及ぶ最新の記事を集めたコレクションです。
Jose Alcérreca: そして、もう1つ公開したのが、Android公式スキルです。スキルとは、LLMがベストプラクティスを理解し、特定のワークフローを実行できるようにするための、モジュール化された指示のことです。これらは通常のドキュメントよりもずっと意見が明確で、エージェント向けの具体的な指示を含んでいます。Knowledge Baseとスキルは、Android StudioとAndroid CLIの両方で利用可能ですので、どのエージェントからでも使うことができます。
Jose Alcérreca: もしAndroid CLIをご存じない方のために説明しますと、これはエージェント向けのツール群であり、SDKやエミュレータの管理、アプリのデプロイができます。また、Knowledge Baseを検索したり、スキルをインストールしたりすることも可能です。そして本日、私たちはアダプティブスキルを発表します。これは、皆さんのUIをアダプティブにするための、意見の明確なガイドです。
Jose Alcérreca: このスキルはGitHubから、またはAndroid CLIを使ってダウンロードすることができます。さて、これだけのリソースが揃った今、一つのプロンプトだけでアプリ全体を適応化できるのでしょうか。エージェントに対して、単に「私のアプリをアダプティブにして」とお願いするだけで済むのでしょうか。それはアプリの内容に大きく依存しますが、一つだけ明らかなことがあります。段階を踏んで進め、明確な計画を持って取り組むほうが、変更の質は良くなりますし、長期的にはより速く進められるということです。
3. デモアプリ「Pawparazzi」と単一プロンプトによる適応化の限界
3.1 デモアプリの紹介と初期状態でのレイアウト崩れ
Don Turner: そうですね、まさにその通りです。ツールやAPIについて知れば知るほど、プロンプトの質も、計画の質も、コードレビューの質も向上していきます。それに、エージェントもミスをすることがありますから、生成されたコードは必ずレビューできるようにしておく必要があります。このセッションでは、AIエージェントから高品質なコードを引き出すために必要なガイダンスとAPI情報をお伝えしていきます。
Jose Alcérreca: それでは、ノートパソコンに切り替えましょう。今回のセッションでは、私がバイブコーディングで作成したこのアプリを使っていきます。名前はPawparazziといいます。ペットの写真を表示するアプリです。他のユーザーとやり取りできるMessagesタブもあります。
Don Turner: Google I/Oで新しいチャットアプリが登場しないなんてことは、ありえませんよね。
Jose Alcérreca: その通りです。それから、Pet of the Monthという機能もあり、今はシンプルなリストになっています。
Don Turner: ちなみに、はっきりさせておきたいのですが、私たちはすべてのペットが最高だと思っています。これはあくまでデモアプリです。
Jose Alcérreca: その通りです。このアプリは見た目としては問題なく、シンプルなUIアーキテクチャで手早く作られたサンプルアプリです。しかし、まず折りたたみ端末で展開してみましょう。おそらく皆さんもすでに問題に気づかれていると思います。ちなみに、この折りたたみエミュレータは本当に便利で、一つのエミュレータだけで回転させたり展開したりして、複数の画面サイズを確認できます。しかし、実際に回転させてみるとどうなるか見てみましょう。あまり良くありませんね。ただ、これが多くのアプリの現実です。そして今、ポートレート固定の制限が解除されつつある中で、私たちはこの点の改善に本当に注力すべき段階に来ています。
Jose Alcérreca: ご存じない方のために補足しますと、Android 16では、もはやアプリをポートレートに固定することができなくなっています。
3.2 「make my app adaptive」プロンプトの実演と結果評価
Jose Alcérreca: では、ここでエージェントを開いて、スキルがどのように起動するのかをお見せするために、プロンプトを送ってみます。ひとまず「私のアプリをアダプティブにして」と入力してみます。ここで重要なのは、私が事前にアダプティブスキルをインストールしていたという点です。ここに表示されているのがそれです。
Jose Alcérreca: そして、すぐにエージェント、つまりモデルが、そのスキルを起動することを決定しました。ここに表示されているのがそれです。開いてみると、こちらにあります。今回は、エージェントがタスク全体を実行する様子はお見せしません。それはペンキが乾くのを眺めているようなものですから。ただし、このセッションでお見せするすべてのプロンプトは、常に同じ結果が得られることを確認するため、自動化された形で複数回実行済みのものです。
Jose Alcérreca: また、これらはすべてAndroid Studio上のGemini 3 Flashで実行されています。それでは、スライドに戻りましょう。実際のアプリでこのようなプロンプトを試すことは推奨しませんが、試しにサンプルアプリで「私のアプリをアダプティブにして」というプロンプトを実行してみます。実行が完了すると、モバイル版は元々の見た目のままで、これは問題ありません。
Jose Alcérreca: 折りたたみ端末では、少し良くなりました。ボトムナビゲーションバーの代わりにナビゲーションレールが表示されるようになり、Messagesタブにはリスト詳細レイアウトまで作成されました。より大きなウィンドウでは、利用可能なスペースをうまく活用するようになっています。
Don Turner: ええ、なかなか良い出来ですよね。しかも、これがたった一つのプロンプトで実現されているのです。
3.3 vibe-codingの幻想と段階的アプローチの必要性
Jose Alcérreca: これで完了でしょうか。
Don Turner: ええ、もう帰りましょう。
Jose Alcérreca: いえ、これは典型的なバイブコーディングの幻想です。このようなシンプルなアプリをゼロから、あるいは簡単なアプリに手を加えるだけであれば、モデルにとってはずっと簡単な作業です。汎用的な判断をするだけで済むからです。しかし、より複雑なアプリになると、画面数も多く、レイアウトも異なり、カスタマイズも増え、皆さんやUXチームが判断すべき決定事項が出てきます。
Jose Alcérreca: 例えば、このアプリをモバイルの横向きで開いてみると、写真を表示するためのスペースがほとんどないことがわかります。スキルは確かに役立ちますが、エージェントに「アプリをアダプティブにして」と依頼するだけではなく、段階を踏んで進めるためのサポートとして使う方が、はるかに良い結果が得られます。
Don Turner: そうですね。つまり、一つのプロンプトを使ってAIエージェントが正しく処理してくれることを期待するのではなく、私たちには計画が必要だということです。
4. 適応化のための計画立案と準備作業
4.1 3段階の準備(Compose移行・Nav3移行・テスト整備)とUI変更の3階層モデル
Don Turner: そして実際のところ、アダプティブスキルをエージェントと一緒に使うことで、この計画自体を作成することができます。まず最初にやるべきことは、コードベースが適応化に対応できる状態になっていることを確認することです。つまり、すべてのビューをComposeに移行するということです。私たちは、AndroidがこれからはCompose-firstになると発表しました。つまり今後、すべてのUI開発はComposeで行われるべきであり、Viewsシステムのライブラリはメンテナンスモードに入るということです。それに、今日ご紹介するAPIのほぼすべてがComposeのものです。ですから、基本的にはComposeを使ってください、ということになります。
Don Turner: 次に、ナビゲート、ではなく、マイグレートしていただきたいのが、Navigation 3への移行です。Nav3の強みは、バックスタックの状態を変えることなく、マルチペインレイアウトをネイティブにサポートしている点にあり、これがアダプティブレイアウトに最適な理由です。
Don Turner: 次に、まだテストをお持ちでない場合は、異なるフォームファクターでアプリがどのように見えるかを検証するためのテストを追加してください。これらがあれば、UIの変更を簡単に検証できるようになります。また、この過程で何も壊れていないことを確認するための、いくつかの挙動テストも必要になるでしょう。ここまでの準備が整えば、いよいよアプリをアダプティブにする準備が整ったということになります。
Don Turner: そのためには、このプロセスを理解しておくことが役立ちます。まず、UIケイパビリティを使ってUIに関する判断を行います。UIケイパビリティには、ウィンドウサイズや、マウス・タッチ・スタイラスといったポインタの種類などが含まれます。また、使用されているキーボードの種類など、その他多くのケイパビリティも含まれます。そして、これらのケイパビリティは、異なるレベルでUIを変更するために使うことができます。
Don Turner: アプリレベルでは、コンパクトなウィンドウ幅ではボトムナビゲーションバーを表示し、より広い画面のデバイスではナビゲーションレールを表示するといった形で、全体的なレイアウトを変更することができます。また、メインコンテンツのレイアウトを、シングルペインからマルチペインへと適応させることもできます。そして最後に、リストやグリッド、ボタンといった、より低いレベルのUIコンポーネントをアダプティブにすることもできます。例えば、写真のグリッドやカードにおいて、列数を可変にするといった方法です。
Don Turner: ただし、これらは厳格な境界ではありません。適切だと思われるレベルであれば、どのレベルでも適応化を行ってかまいませんし、そうすべきです。さて、計画ができましたので、実際に作業を始めましょう。まだViewsを使っている場合は、画面をComposeに移行してください。全面的な移行を望まない場合は、Compose コンポーネントの中にViewsをラップすることもできます。ただし、前のセッションでも触れられていたように、ViewsからComposeへの移行のためのスキルがありますので、移行を検討する価値は十分にあります。
4.2 各種移行・テストスキルの詳細
Don Turner: このスキルは、計画の作成、依存関係の設定、テーマ対応、レイアウトの移行にも役立ちます。そして、モデルは実際にこの作業が非常に得意ですので、このスキルを使うことで多くの時間を節約できます。画面をComposeに移行し終えたら、次はNav3への移行に取りかかることができます。
Jose Alcérreca: そして、お察しの通り、そのためのスキルもあります。Nav3スキルには、Nav2アプリをNav3に変換するための移行ガイドが含まれています。複数のバックスタック、条件付きナビゲーション、依存性注入を含む、さまざまなコードレシピも用意されています。ですので、Nav3を使っている場合には、非常に有用なスキルです。
Don Turner: さて、これで移行作業はすべて終わりました。次の段階はテストになりますね。
Jose Alcérreca: ええ、聞いてくださってうれしいです。どのような大きな変更であっても、実際にはどんな変更であっても、しっかりとしたテスト戦略が必要です。既に動作していたものを壊さないようにすることが重要です。そしてせっかくですから、新機能がすべてのフォームファクターで正しく動作することを確認するためのテストも追加していきます。
Jose Alcérreca: まず、良いテスト戦略を用意することにしましょう。そして、お察しの通り、そのためのスキルもあります。testing-setupスキルは、アプリに複数の種類のテストを追加するための意見の明確な方法であり、始めるにはとても良い方法です。テスト戦略をまったく持っていない場合でも、このスキルを使ってテストを追加することができます。
Jose Alcérreca: このスキルには私たちが推奨する良いデフォルト設定が含まれています。ただ、今回は多くのUI変更を行うため、特にスクリーンショットテストを有効にすることに焦点を当てます。もちろん、UIの挙動テストやユニットテストなども併せて用意すべきです。私たちのサンプルアプリでは、Composeプレビュー・スクリーンショットテストを使用しています。これは、たった一つのアノテーションだけで複数のウィンドウサイズを非常に素早く比較できるため、便利です。
Jose Alcérreca: 今回使用している仕様は、phone、横向きのphone、折りたたみ端末、デスクトップの4種類です。もちろん、これはカスタマイズすることも可能です。プレビューテストの作成は非常に簡単で、Android Studio上でコンポーザブルを右クリックすることで、エージェントにそのプレビューを生成させることができ、モックデータの用意なども含めてすべて処理してもらえます。
Jose Alcérreca: ですので、まだお持ちでない場合は、変更を加える前にスクリーンショットテストを追加してください。そうすることで、進捗を追跡できるようになりますし、将来的にすべてのフォームファクターにわたる問題を発見できるようにもなります。よし、これで下準備の作業はすべて完了です。
Don Turner: はい、いいですね。それでは、いよいよ楽しい部分、実際にアプリをアダプティブにしていく作業に取りかかりましょう。まずはアダプティブレイアウトからです。
5. 適応的ナビゲーションとマルチペインレイアウトの実装
5.1 ナビゲーションエリアの適応化(NavigationSuiteScaffoldとScene Decorators)
Don Turner: まず最初にお伝えしたいのは、私たちが皆さん開発者のことをどう考えているか、ということです。信じられないかもしれませんが、私たちは皆さんのこと、そして皆さんがAPIに何を求めているかについて、本当に多くの時間をかけて考えています。皆さんの中には、既存のコードベースにそのまま組み込める、すぐに使える解決策を求めている方もいれば、カスタマイズや拡張のための良い出発点を求めている方もいますし、ゼロから何かを構築したいという方もいらっしゃると理解しています。私たちの意図は、これらすべてのアプローチに対応するAPIとガイダンスを提供することです。現時点で完全なカバレッジがあるわけではないかもしれませんが、今後どのような方向で考えているかを知っていただくために、まずはお伝えしておきたいと思います。それでは、アダプティブなナビゲーションエリアのために私たちが用意しているAPIについて、具体的にお話ししましょう。
Don Turner: すぐに使える解決策としては、Material の NavigationSuiteScaffoldを使うことができます。カスタマイズやアプリレベルのレイアウトをゼロから構築したい場合には、Nav3の新しいScene Decorators機能を使うことができます。これは、ナビゲーションレールやバーといった他のコンテンツで、メインコンテンツをラップすることを可能にするものです。既存のデコレータをカスタマイズするためには、Nav3のレシピリポジトリにレシピを用意しています。
Don Turner: そして、Scene Decorator Strategyインターフェースを実装することで、独自のものを構築することもできます。これについては、豊富な最新のドキュメントを用意しています。
Jose Alcérreca: それでは、いよいよアプリに実際の変更を加えていきましょう。「ナビゲーションエリアをアダプティブにして」というプロンプトを試してみます。このスキルには、カスタマイズが不要な場合に使うべきnavigation with scaffoldに関するセクションが含まれています。
Jose Alcérreca: そして、これがプロンプトの実行結果です。より大きな画面では、ボトムナビゲーションバーがナビゲーションレールに置き換わっています。そして、これで関連するAPIについて理解が深まったところで、それらが正しく使われているかどうかを確認することができます。
5.2 マルチペインレイアウトの実装(Scenes機能とMessages画面の実演)
Don Turner: さて、話を進めましょう。より大きな画面では、関連するコンテンツを並べて表示することができ、これは画面を行き来するよりも、ユーザーにとってずっと便利になり得ます。
Jose Alcérreca: これら両方とも、Nav3ではScenesという仕組みを通じてサポートされています。すぐに使える解決策としてMaterial Scenesを使うことができますし、カスタマイズのための出発点として私たちのレシピリポジトリからレシピを使うこともできます。そして最後に、SceneStrategyインターフェースを実装することで、ゼロから構築することもできます。BenとClaraによるNav3専門セッションが昨日公開されており、そこではディープリンク機能を含む、Nav3の最新機能がすべて解説されています。これは多くの方が待ち望んでいた機能だと承知しています。
Jose Alcérreca: それでは、私たちのアプリにはリスト詳細の関係がいくつか存在することがわかっていますので、これをエージェントに実装させてみましょう。最初の候補としては写真フィードが考えられますが、ここではリスト詳細レイアウトが適しているとは思いません。大きな画面では、画面の実空間を使ってより多くの写真を同時に閲覧できるようにしたいところです。そして写真を選択したときには、できるだけ大きく表示したいはずです。しかし、これは製品としての判断であり、100%ユースケース次第です。もちろん、そちらを望む場合もあるでしょう。ですから、私たちが何を求めているかを明確にして、段階を踏んで進めていきましょう。「Messages画面をリスト詳細レイアウトに変換して」というプロンプトを試します。また、AIに任せきりにするのではなく、プロンプトの中で具体的に指定しておくほうが良いです。
Jose Alcérreca: ですので、会話がまだ選択されていない場合に、最初の会話を表示するのか、それともプレースホルダーを表示するのかを、この時点で決めておく必要があります。ここでは、「会話を選択してください」というプレースホルダーを表示する方針にしましょう。そして、これが生成されたコードです。ListDetailSceneStrategyにはプレースホルダーの詳細が含まれているため、スキルのおかげでモデルはそれを使用しています。
Jose Alcérreca: そして、これが結果です。期待通りに動作しています。ただ、これだけではありません。時間を節約するために、大きな変更の後には、エージェントにビルドを依頼したり、スクリーンショットテストを生成させたり、あるいはエミュレータにアプリをデプロイして操作させたりすることを、私はよく行っています。しかし、皆さんのエージェントにはエミュレータを管理するスキルがあるでしょうか。もちろん、そのためのスキルも用意しています。
Jose Alcérreca: Android CLIにはエミュレータマネージャーが含まれています。このスキルがあれば、「エミュレータにデプロイして」といった指示をするだけで、モデルがその方法を理解して実行してくれます。Android CLIについてもっと知りたい方は、developer toolsのセッションをご覧ください。
Don Turner: はい、これでアプリのレイアウトがアダプティブになりました。素晴らしいですね。それでは次に、個々のUIコンポーネントをどのようにアダプティブにしていくかを見ていきましょう。
6. 個別UIコンポーネントの適応化:グリッドとエッジツーエッジ対応
6.1 GridCells.Adaptiveによるフィード画面の列数自動調整
Don Turner: それでは、まず最初にお話ししたいのは、固定の列数や行数を持つリストやグリッドを使っている箇所については、アダプティブな列数を検討すべきだということです。これには、任意のLazyGridレイアウトを使うことができます。そして列数を指定する際には、GridCells.Adaptiveを使うことができます。
Don Turner: これは、最小の列幅を受け取り、利用可能なスペースの中でできるだけ多くの列を作成し、余ったスペースがあれば、それを各列に均等に分配してくれるというものです。私たちのフィード画面は、まさにこのAPIの絶好の候補です。現在は常に1行あたり2枚の写真を表示していますが、これはモバイルの縦向きでは問題ありませんが、ご覧の通り、折りたたみ端末ではあまりうまくスケールしません。
Jose Alcérreca: そうですね、これはスキルでカバーされている内容です。LazyListをアダプティブにするというセクションがあります。では、これを実現するにはどのようなプロンプトを使えばよいでしょうか。「このレイアウトをアダプティブにして」でしょうか。ええ、これでもうまくいくかもしれませんが、何を求めているのかを具体的に指定するほうが、はるかに良い結果が得られます。「縦向きのモバイルでは2列、折りたたみ端末では3列、より大きな画面では4列以上を表示して」という指示です。
Jose Alcérreca: ただし、GridCells APIを使うようにと指示する必要はありません。しかし、何が可能なのかを知っておくことは重要です。そうすれば、このようなプロンプトが最初から正しく動作することがわかるからです。モデルは、これらの制約に合致するために必要な最小サイズが180dpsであることを、十分賢く計算することができます。そして、これで随分良くなりました。今では、利用可能なスペースに応じて、異なる列数を表示する形で適応するようになっています。
Don Turner: ええ、確かにずっと良くなりましたね。ただ、その電話を横向きに回転させると、最初の行の画像がほとんど見えなくなってしまいます。この場合、ユーザーがスクロールしたときにボトムナビゲーションバーを隠して、コンテンツのためのスペースをもっと確保するべきですね。
6.2 スクロール連動UIとエッジツーエッジ対応の試行錯誤
Jose Alcérreca: わかりました、では早速やってみましょう。「高さがコンパクトなときにスクロールするとボトムバーが折りたたまれるようにして」という指示です。これは非常によくあるパターンなので、モデルがそれをこなせるかどうか見てみましょう。だいぶ良くなってきましたが、ここで何が起きたのでしょうか。上部のパディングが多すぎますし、カメラの裏側にコンテンツが描画されてしまっています。そして、なぜかボトムナビゲーションが透明になってしまいました。まるで、モデルが新しいAPIを使ってエッジツーエッジにするためのスキルを持っていなかったかのようですね。
Jose Alcérreca: そして信じられないかもしれませんが、実はエッジツーエッジ用のスキルというものが存在します。このスキルとアダプティブスキルを組み合わせることで、折りたたみ可能なトップバーとボトムバーを実装できるようになります。もちろん、これにはエッジツーエッジの基本、トラブルシューティングやアンチパターンも含まれています。それでは、このスキルをインストールして、エッジツーエッジに対応させましょう。
Jose Alcérreca: 「リストをエッジツーエッジにして、スクロール時にトップアプリバーを折りたたみ、ユーザーが一番上までスクロールしたら再表示するようにして」というプロンプトです。ここが重要なのですが、これには2つのモードがあります。「高さがコンパクトなときに、ユーザーがスクロールしたら、ナビゲーションバーを折りたたんで」ということです。私は、関連するタスクは一つのプロンプトにまとめて含めることを好みます。
Jose Alcérreca: そうすることで実際に時間とトークンの両方を節約できます。エージェントが文脈を二度解釈し直す必要がなくなるからです。もちろん、望むのであれば2つに分けることもできます。この情報があれば、モデルはこれをすべて機能させるために必要な、比較的複雑なCompose コードを組み立てることができます。そして、もちろん正しく動作させることができました。今では、横向きの画面にいるユーザーが、画面のスペースをすべて使って、2行分の写真を丸ごと見ることができるようになっています。
Jose Alcérreca: ここには専用の横向きレイアウトは存在しません。あるのは、同じレイアウトを異なる構成に適応させるためのコードだけです。それでは、次に進みましょう。
7. UI CapabilitiesとMediaQuery API
7.1 ウィンドウサイズ・ポインタ精度等のUI capabilities解説
Don Turner: さて、先ほどのプロンプトでは、UIケイパビリティの一つであるウィンドウの高さを使って、ボトムナビゲーションバーを折りたたむというUI上の判断を行うという考え方を紹介しました。これは非常によくあるパターンで、実は先ほど見たアダプティブレイアウトAPIの内部でも使われています。例えば、Materialのlist-detail SceneStrategyは、ウィンドウサイズを使って、リスト詳細シーンを作成するのに十分なスペースがあるかどうかを判定しています。しかし、もし皆さんご自身でこれらのケイパビリティにアクセスして、UIに関する判断を自分でコントロールしたいという場合には、どうすればよいのでしょうか。その方法をご紹介します。
Don Turner: まず、皆さんが最もアクセスしたいと思うであろう重要なプロパティは、ウィンドウサイズです。これはLocalWindowInfoを使って直接アクセスすることができます。ただ、多くの場合は、ウィンドウサイズクラスを使って扱うほうが便利です。これらは、典型的なシナリオに向けてアプリレベルのレイアウトを設計するのに役立つ、意見の明確なビューポートのブレークポイントです。Materialが定義済みのウィンドウサイズクラスを使うこともできますし、WindowSizeClassを使って独自のものを定義することもできます。
Don Turner: また、もう一つ重要なケイパビリティが、ユーザーがUI要素をどのようにポイントしているかということです。これが重要なのは、マウスポインタのほうが指よりもずっと精度が高いからです。ですので、マウスを使用している場合には、UI要素のターゲット領域を小さくすることができ、より密度の高いUIを作成することができます。また、他にも折りたたみ端末やノートパソコンにおけるデバイスの姿勢や、物理キーボードが接続されているかどうかなど、まだまだ多くのUIケイパビリティが存在します。
Don Turner: これらすべてのケイパビリティに対応するAPIは、長い間Android APIの中に点在してきました。その多くはCompose以前から存在するものであり、Composeとうまく連携させるためには、少し手を加える必要がある場合があります。だからこそ、私たちはMediaQueryという新しい実験的なAPIを導入しています。
7.2 新API「MediaQuery」の紹介と実装例
Don Turner: これは、CSSのMediaQuery APIから着想を得たものです。もし、なぜMediaという名前なのか、動画や音声再生のことなのかと疑問に思われた方がいらっしゃるかもしれませんが、ここでのMediaとは、UIが描画されるデバイスの種類を指しています。このAPIは現在、ウィンドウサイズ、ポインタの精度、デバイスにマイク・カメラ・キーボードが搭載されているかどうか、そしてユーザーが画面をどれくらいの距離から見ているかといったケイパビリティに対応しています。
Don Turner: それでは、実際に試す方法をご紹介します。mediaQuery関数は、pointerPrecisionのようなUIケイパビリティにアクセスできるラムダを受け取り、そのラムダと同じ型を返します。mediaQuery関数は、このラムダの内部でアクセスされている基となるUIケイパビリティのいずれかが変化するたびに、再コンポーズを行います。
Don Turner: つまり、依存するコンポーザブルを再コンポーズさせるために、MediaQueryに頼ることができるということです。ここで便利なパターンとして、ラムダにBoolean型を返させるという方法があります。例えば、このコードサンプルでは、プライマリのポインタが高精度である場合にTrueを返しています。これを使って、UI要素を小さくすることができます。逆に、タッチスクリーンのような精度の低いポインタが使われている場合には、UI要素を大きくすることができます。
Don Turner: これは通常、UI要素のスタイルをカスタマイズすることで行いますが、実はこれを行うための新しいAPIとして、Style APIというものがあります。もしこれについてもっと知りたい方は、このまま会場にいてください。というのも、私たちの次のセッションが、まさにこのAPIについて詳しく取り上げるからです。それでは、MediaQueryの話に戻りましょう。ウィンドウサイズのように急速に変化する値については、derivedMediaQueryを使うことになります。これは、デスクトップでアプリを実行していて、ユーザーがウィンドウをドラッグしてリサイズしているときなど、急速に変化する場合に該当します。
Don Turner: これを使うことで、「自分の状態が急速に変化する値に依存していることは理解しているが、派生した状態が変化したときにのみ再コンポーズしたい」ということを表現できます。MediaQueryはまだ非常に実験的なAPIです。ぜひ試していただき、Issueを提出して、皆さんが何を必要としているかを私たちに教えてください。
Jose Alcérreca: それでは、実験的なAPIではありますが、MediaQueryのドキュメントはアダプティブスキルとKnowledge Baseの両方で入手可能です。ですので、エージェントにこれを使うようお願いすれば、その情報を取得してくれます。それでは、実際に試してみましょう。エージェントに対して、「ポインタの精度がfineのときは、PetFilterChipのパディングを2dpsに減らして」と伝えてみます。すると、必要なときにだけ更新される正しいmediaQuery構文が使われます。そして、パディングを設定することができます。これが、マウスやトラックパッドを備えたデバイス、例えばノートパソコンでの結果です。
Jose Alcérreca: フィルターが少し小さくなります。
8. FlexBoxとGridレイアウトAPI
8.1 FlexBoxの基本機能とフィルターチップ実装例
Don Turner: いいですね。それでは、アダプティブUIを作成するうえで非常に役立つ、実験的なレイアウトAPIをもう少しご紹介しましょう。まず一つ目はFlexBoxです。FlexBoxは、アイテムを一方向にレイアウトし、利用可能なスペースを埋めるように子要素のサイズを変更することができます。
Don Turner: flexモディファイアを使うことで、Flexのプロパティにアクセスできます。ここでは、growプロパティを使って、余分なスペースがあるときに中央の子要素を伸長させています。これは、一つの要素だけを伸長させ、それ以外は固定のままにしておきたい、トップアプリバーのような場所で特に役立ちます。また、FlexBoxはスペースが足りないときにアイテムを新しい行に折り返すこともでき、コンテナの挙動を設定するためのconfigパラメータを使って、この折り返しのような設定を行うことができます。
Don Turner: これは、サイズの異なる子アイテムがあり、それらを新しい行に折り返したい場合に非常に便利です。これはFlexBoxの機能のほんの表面をなぞったに過ぎませんので、ぜひ実際に試して、どのように使えるか確かめてみてください。それでは続けて、UIコンポーネントをアダプティブにしていきましょう。私たちのデザイナーは、十分なスペースがあるときには、フィード画面ですべてのフィルターを表示したいと考えていました。
Don Turner: そのため現在は、単一のスクロール可能な行として表示しています。実際には、これらのフィルターの一部が画面からはみ出してしまっています。これは非常に都合よく、まさにFlexBoxの出番のような案件です。
Jose Alcérreca: 問題ありません。エージェントに聞いてみましょう。「フィードでは、フィルターはスクロール可能な1行で表示するが、幅600dpsからは複数行に折り返して表示するようにして」というプロンプトです。ここでウィンドウサイズではなく600dpsを使っているのは、私が話しているのがコンテナのサイズだからだという点に注意してください。そして、これが結果です。今回はコードが少し複雑になっていますが、私たちが求めた通りのことを正確に行っています。幅が広いかどうかに応じて、折り返すか、水平スクロールを適用するかが決まります。そして、これが結果です。
Jose Alcérreca: 大きな画面では折り返すFlexBoxが実現できています。
8.2 Gridの基本機能とトップペット画面実装例
Don Turner: いいですね。FlexBoxは1次元のレイアウトには優れていますが、行と列の両方にまたがるアイテムを含む複雑な2次元レイアウトについては、Gridというもう一つの実験的なAPIがあります。設定方法はFlexBoxと同様で、コンテナ用のconfigブロックを使います。この例では、column関数とrow関数を使って、セルサイズ100dpの3×3グリッドを定義しています。
Don Turner: また、行と列の間の間隔を指定することもできます。Grid itemモディファイアを使うことで、複数のセルにまたがるといった、Gridの機能にアクセスすることができます。ここでは、rowSpanとcolumnSpanを使って、緑色のボックスを幅2セル、高さ2セルに収まるようにしています。Gridは、重要なアイテムをより大きく表示したい場合に適していますが、それでもすべての要素がグリッドに揃っている必要がある、という状況に向いています。
Don Turner: そして、ちょうどよいことに、私たちのアプリにはGridにぴったりの機能があります。それがtop petの画面です。現在はすべてのペットを同じサイズで表示していますが、私が面白いと思うのは、1位のペットが他のペットの4倍のスペースを占めるようにすることです。これが私のビジョンです。
Don Turner: モバイルの縦向きでは2×4のグリッドにして、より大きな画面のデバイスでは4×2のグリッドに切り替えることができます。
Jose Alcérreca: 素晴らしいですね。
Don Turner: どうなるか見てみましょう。
Jose Alcérreca: わかりました、それでは今回もモデルに対して、APIをどう使うべきかを正確に伝える必要はありません。私たちが求めているものを説明するだけで十分です。「top pet画面をさまざまなウィンドウサイズに適応させて。常にペット1番を2×2のグリッドセルで表示し、それ以外は1×1で表示するようにして。そしてグリッドセルは、利用可能なスペースに応じて2×4、または4×2にして」というプロンプトです。これがそのコードです。今回も、理解しやすいいくつかのif文が使われているだけです。そして、セルサイズを計算し、こちらが結果です。
Jose Alcérreca: 私が意図していた「利用可能なスペース」という部分を、正しく解釈できています。
Don Turner: ええ、まあ、悪くない出来ですね。これは私が考えたデザインであって、私はデザイナーではなくエンジニアです。ですので、実際に有能なデザイナーの手にかかれば、これがどれほど良く見えるか、想像してみてください。
9. まとめとクロージング
9.1 適応化ジャーニーの推奨ステップとスキルリポジトリ
Don Turner: さて、これで完了です。これらの新しいAPIの威力と、アプリをアダプティブにすることが大変な作業である必要はないということが、皆さんに伝わっていれば嬉しく思います。もし皆さんが、モバイルのポートレートから、あるいは現在アダプティブ化の旅路のどの段階にいるとしても、興味を持っていただけたのであれば、ここが出発点になります。私たちがこれまでご紹介してきたすべてのスキルが、皆さんのアプリをアダプティブの世界へと導く助けになります。まずはComposeへの画面移行から始めてください。
Don Turner: そして、たとえビューをラップする必要があったとしても、Navigation 3スキルを使うことでNav2からNav3への移行が可能です。テストも追加すべきですし、そのうえでエージェントに対してレイアウトをアダプティブにするよう依頼していくことができます。できれば一つずつ、そして詳細なプロンプトを使い、UXチームやプロダクトチームが用意したモックも活用しながら進めることが望ましいです。最後に、必ずスキルのリポジトリを確認してください。私たちは常に新しいスキルを追加しており、現在ではAndroid Gradle Plugin、カメラ関連のパフォーマンスなど、Android開発に非常に役立つさまざまなスキルが揃っています。
Don Turner: これらのスキルをどのように活用すればよいかについてもっと知りたい方は、Develop With Android Studioというセッションをご覧ください。これは実は、私たちのセッションの直前に行われたセッションです。
9.2 AIエージェント時代における「品質」の再定義
Jose Alcérreca: それでは、このセッションを締めくくるにあたって、私たちがお伝えしたいのは、まったくの初心者であっても、わずか2分でプロトタイプアプリを作成できるということが、本当に素晴らしいことだということです。しかし、ユーザーが本当に気にかけているのは品質です。ユーザーを喜ばせるアプリ、必要がないのに毎回ログインを求めてこないアプリ、ダークモードに対応しているアプリ、エッジツーエッジに対応しているアプリ、そしてもちろん、さまざまな構成の複数のデバイスで使えるアプリです。それこそが品質です。私はただ、フォームに入力している最中に電話を回転させても、最初からやり直しにならずに済むようにしてほしいだけなのです。
Jose Alcérreca: それもまた品質の一つです。そして、AIエージェントやLLMは、皆さんが何を求めるべきかさえ理解していれば、高品質なアプリを作るうえで非常に大きな助けになり得ます。つまり、AIを使うことで、良い開発者は良いアプリを作り、優れた開発者は優れたアプリを作る、ということです。この点は変わりません。ですから、今こそ皆さんのアプリをアダプティブにするときです。
Jose Alcérreca: 私たちも、まだ皆さんにはもう少し多くのQAが必要であり、もう少し多くのコードのメンテナンスが必要であるということは理解しています。しかし、その投資は今や、かなり小さくて済むようになっていますし、そのリターンは日々大きくなり続けています。ですので、一つのプロンプトだけでそこにたどり着けるわけではありませんが、状況は以前よりもずっと良くなっています。もしかしたら、案外楽しい作業になるかもしれません。ありがとうございました。