UI仕様を「見えるもの」にする 〜 Compose Screenshot Testing とギャラリーで支える、AIエージェント時代のAndroid UI開発 〜
syarihuAndroid Engineer
機能追加やABテストの並行運用が続くプロダクトでは、いつの間にか意図しないUIの変更が紛れ込み、リリース直前のQAやリリース後に気づくケースが少なくありません。近年は、AIエージェントによる実装やレビューを並列で走らせる機会が増え、生成されたUIが意図通りなのかを一つひとつ手元で確認するコストが新たな悩みになりつつあります。一方で、UI仕様もデザイナー・PdM・開発者の間で共通認識を持つことは難しく、「今このアプリにはどんな画面があり、どの状態でどう見えるのか」を誰でも横断的に確認できる場所がないことも、多くのチームに共通する課題ではないでしょうか。 私たちのチームでは、Compose Preview Screenshot Testingを中心にこの課題に取り組んできました。Android Studioの@Previewと同じ仕組みで画像を生成するため、AIエージェントが実装したUIもPR上の差分画像だけでレビュー可能になり、AI時代の「並列実装による確認コストの肥大化」を抑える仕組みとして機能しています。CIではPRに差分画像を自動コメントし、エミュレータを立ち上げなくてもレビュアーがUIの変化を一目で把握できます。さらに、Mac開発者のローカルとUbuntu CIで生成画像が一致しない問題を、永続化Dockerコンテナとlayoutlib向けのx86_64環境統一によって解消し、環境差異起因のflakyテストを大幅に削減しました。 加えて、300枚を超える参照画像をHTMLギャラリーとして集約し、画面単位のグルーピング、ABテストバリアントの並列比較、Light/Dark表示などを通じてUI仕様そのものを可視化しています。配布面ではWebP変換とbase64埋め込みにより、単一HTMLファイルとしてGCS等に置くだけで社内のどのメンバーにも共有できるようにしました。自然言語でシナリオを記述できるAIエージェント型UIテストフレームワーク arbigent も併用し、ピクセル単位の差分検知だけでは拾えない「ユーザー操作の流れ」のリグレッションも担保しています。 本セッションでは、実プロダクトでの運用知見を交えながら、スクリーンショットテストとギャラリーをどう設計・運用すれば、UI仕様の可視化・リグレッション防止・AIエージェント時代のレビュー効率化を両立できるのかを、具体的なスクリプトやCI構成も交えてお話しします。 ■ 発表予定の内容 - スクリーンショットテスト/UIテストの位置づけと使い分け(Compose Preview Screenshot Testing / Roborazzi / arbigent) - Compose Preview Screenshot Testingの導入と、CIによるPRへの差分画像自動投稿 - AIエージェントによる並列実装時代における、PR上でのUI確認コスト削減の仕組みとしての価値 - Dockerによるローカル/CI環境差異の吸収と、永続化コンテナによるGradleキャッシュ最適化 - 300枚超の参照画像を可視化するスクリーンショットギャラリーの設計 - 画面単位グルーピング・ABテストバリアント比較・Light/Dark並列表示と、命名規約からのメタデータ自動導出 - WebP変換とbase64埋め込みによる単一HTML配布で、開発者以外もUI仕様を確認できる環境作り - arbigentによる自然言語UIテストとスクリーンショットテストの併用戦略
対象者
- 意図しないUIリグレッションの検知に課題を感じているAndroidエンジニア - スクリーンショットテストの導入や運用面の壁に悩んでいる方 - デザイナー・PdMを含めてUI仕様を組織横断で共有したいチーム - AIエージェントによる並列実装時代のUIレビュー効率化に興味がある方