こんにちは。LINEでAndroidアプリの開発を担当しているMoriです。この記事では、DroidKaigi 2026で発表した「デバイス操作はAIエージェントの時代へ。mobile-mcpを活用し...

はじめに こんにちは。プロダクトエンジニアリング部でAndroidエンジニアをしている住谷です。 2026年9月1日(火)から9月3日(木)の3日間、ベルサール渋谷ガーデンで開催されたDroidKaigi 2026に現地参加してきました。 本記事では、会場で聴講したセッションの中から特に印象に残ったいくつかのセッションを中心にレポートします。 はじめに DroidKaigi 2026 について 特に印象に残ったセッション 1. デバイス操作はAIエージェントの時代へ。mobile-mcpを活用したAndroid UI/E2Eテストの挑戦 資料 セッション概要 特に学びになった点・感想 2. 行政アプリ全画面TalkBack対応を、デザイナー協業とAIエージェントで自動化していく実体験 資料 セッション概要 特に学びになった点・感想 3. UI仕様を「見えるもの」にする 〜 Compose Screenshot Testing とギャラリーで支える、AIエージェント時代のUI開発 資料 セッション概要 特に学びになった点・感想 4. AIがレビューする時代に、Androidエンジニアは何をレビューするのか 〜土台づくりとレビュー再設計〜 資料 セッション概要 特に学びになった点・感想 おわりに DroidKaigi 2026 について DroidKaigiは、Android技術を中心に扱う国内最大級のカンファレンスです。国内外のAndroidエンジニアが最新の技術動向や実践知を共有する場として毎年開催されており、企業や個人開発者が現場で得た知見を発表するセッションが数多く並びます。 DroidKaigi 2026は2026年9月1日(火)から9月3日(木)までの3日間、東京都渋谷区南平台町のベルサール渋谷ガーデンで開催されました。各セッションの動画は YouTubeのプレイリスト で公開されており、参加できなかったセッションも後から視聴できます。 私自身、技術カンファレンスへの参加は今回が初めてだったので規模とその熱量に驚きました。セッションを聴講するだけでなく、企業ブースやポスターセッションを回る中で、企業の垣根を越えてAndroidアプリケーション開発を盛り上げていこうという熱意を肌で感じ、非常に有意義な時間になりました。 特に印象に残ったセッション 1. デバイス操作はAIエージェントの時代へ。mobile-mcpを活用したAndroid UI/E2Eテストの挑戦 資料 セッション概要 AIエージェントにエミュレータや実機の操作を委ね、E2Eテストほど厳格でない軽量な動作確認を自動化できるかを検証したセッションでした。セッション内では、OpenAIのCodexと mobile-mcp を用いて、楽譜の新規作成や音符入力をAIに指示するデモが実演されました。 動作確認が向くケースと向かないケースの切り分けから、UI取得の実践的なTipsまで語られて、 mobile-mcp 導入を検討する上で必要な知識が得られる、内容の濃いセッションでした。 特に学びになった点・感想 画面ごとのリファレンスmdをSkillとして蓄積し、主要なコードと合わせて与えると検索精度が上がるという点が印象的でした。 contentDescription や testTag の整備も具体的に紹介されました。頻出操作をBroadcastReceiverでADB（Android Debug Bridge）をラップする運用まで組み立てられていた点も印象的でした。自社のプロダクトでも画面マップを整備することでAIエージェントの動作確認の精度向上につながりそうです。コード設計自体が、今後のテスト自動化の前提になると感じました。 AIにテストを実施させた後も人間のレビューは必要という結論は、AIエージェント活用の期待値を整理する上で押さえておきたいポイントだと思いました。 2. 行政アプリ全画面TalkBack対応を、デザイナー協業とAIエージェントで自動化していく実体験 資料 セッション概要 行政アプリケーションで35のdesign systemコンポーネントと約30画面を対象に、WCAG 2.2 A/AA準拠のTalkBack対応を進めた実体験が語られました。実装工数の大きさとデザイナーの読み上げ内容整理の負荷という2つの課題に対し、Figma MCPとClaude Codeを組み合わせたワークフローで対応したとのことでした。 Figmaのノードツリーの取得から指示文の生成、デザイナーによる確認までを一貫して支えるしくみが具体的に紹介されました。Figmaの Code Connect 対応状況による精度差や3分類による実装方法まで踏み込んだ、実践知の詰まったセッションでした。 特に学びになった点・感想 Code Connect 対応の有無で指示文生成の精度が変わる点は、Figmaの運用ルール整備状況が後続のAIエージェント活用の精度を左右する課題として押さえておきたいと感じました。対象を共通コンポーネントのみに絞り小さく始め、失敗時のリカバリーをしやすくする進め方も、全画面横断の対応を進める際の一般的な戦略としてほかの取り組みに応用できそうだと感じました。 clearAndSetSemantics でリスト内の複数コンポーネントを1つの読み上げに統合する実装方針がありました。TalkBack対応の具体的な設計パターンとして自社実装にも参考にできると感じました。 3. UI仕様を「見えるもの」にする 〜 Compose Screenshot Testing とギャラリーで支える、AIエージェント時代のUI開発 資料 セッション概要 AIエージェントによる並列実装が進む一方でUI確認が直列のボトルネックになっているという課題に対する内容でした。Google公式の Compose Screenshot Testing をalpha08のころから本番プロダクトに導入し、参照画像をPNG形式でコミットする運用を構築した経緯が説明されました。 macOS・Linux間の画像差分の解消やGitHub上での差分表示の工夫、共通コンポーザブルへの集約設計まで、運用を安定させるための試行錯誤が具体的に語られました。550枚超の参照画像を検索できるHTMLギャラリーとして活用する取り組みも紹介され、実運用に根ざした内容の濃いセッションでした。 特に学びになった点・感想 PR上でUIの確認ができるしくみは、AIエージェントによる並列実装が進む開発フローにおいて確認コストを下げる有効な手段だと感じました。 動作確認のシナリオ生成部分に mobile-mcp を利用して自動化し、スクリーンショットテストと動的な動作確認を組み合わせる発展的な運用イメージを持つことができました。 4. AIがレビューする時代に、Androidエンジニアは何をレビューするのか 〜土台づくりとレビュー再設計〜 資料 セッション概要 開発歴10年以上・モジュール数42・コード20万行のpixivコミックAndroidにGemini Code Assistを導入した際、的外れな指摘が多発したという経験が共有されました。この経験を踏まえ、 AGENTS.md を約30行に絞り込み、モジュール構成・依存方向・状態管理方針・UTルールを記述する対応を行ったとのことでした。 振る舞いの変更か構造の変更かを判定し、観点別にサブエージェントへレビューを振り分けるマルチパースペクティブコードレビューという独自Skillが紹介されました。 Compose Preview Screenshot Testing によるAI指摘の機械的な検証も紹介されました。Kent Beckの「Tidy First?」に基づく人間レビュー必須範囲の切り分けなど、AIレビュー時代の実践知が詰まったセッションでした。 特に学びになった点・感想 AGENTS.md を約30行に絞り込んだことでレビュー精度が上がったという事実は、AIエージェントに渡すコンテキストは量より質を優先すべきという設計指針として持っておきたいと感じました。構造変更はAIレビュー+テスト通過でマージ可、振る舞い変更は人間レビュー必須という切り分けも、自社のレビュー基準を見直す際の具体的な判断材料になりそうです。 Konsist によるアーキテクチャ違反の機械的検知や、 Compose Preview Screenshot Testing によるビジュアルリグレッション確認がありました。AIの指摘を人間が判断するのではなくテストで機械的に検証可能にする発想は、レビュー負荷を下げる上で重要な視点だと感じました。 おわりに DroidKaigi 2026で聴講した12セッションを通じて、AIエージェントを開発フローに組み込む動きが多方面で進んでいることを実感しました。 mobile-mcp を使ったUI/E2Eテストの自動化やTalkBack対応の指示文生成、Compose Screenshot Testingとの組み合わせによるコードレビューの再設計についても、異なる文脈でAIエージェントの活用が語られていました。共通していたのは「AIに何を任せ、何を人間が判断するか」という責任分担の設計を丁寧に行っている点でした。 今後もAIの進歩に合わせて常にAIとの責任分担の設計をアップデートしていくべきなのだと実感しました。 アクセシビリティに関するセッションも複数あり、TalkBack対応のしくみ化や認知症支援ガイドをComposeのルールへ翻訳する取り組みが紹介されました。AccessibilityServiceの悪用手口とその防衛策など、多角的な視点でアクセシビリティが扱われていたのも印象的でした。誰もが使えるアプリケーションを作るという視点を、あらためて見直すよい機会になりました。 DroidKaigi 2026を通して、社外のAndroidエンジニアの取り組みや考え方に直接触れられたことは、非常に学びになる良い機会でした。 LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULL HOME'Sでネイティブアプリケーションエンジニアをしている久野です。 LIFULL HOME'Sでは、 以前の記事 で紹介したKotlin Multiplatform（KMP）の導入に続き、現在はCompose Multiplatform（CMP）を用いて、AndroidとiOSで共通のUIを実装する取り組みにも挑戦しています。 そんな中、デザイナーから「特定の要素を指し示す『吹き出しUI』を作りたい」と相談を受けました。従来のAndroid開発では画像アセットで対応する場面ですが、画像ベースの実装には保守性の面で課題があります。 そこで今回は技術的な挑戦として「画像アセットではなく、Composeの Shape と Path を使い、座標計算によって吹き出しを動的に描画する」手法で共通コンポーネント化に取り組みました。 この記事では、画像アセットに依存しない実装への移行を決めた背景と、実装時に最も苦労した「矢印付きの複雑な輪郭に、影をきれいに沿わせる方法」について紹介します。 相談の内容と9-patch画像の限界 ShapeとPathで輪郭を実行時に組み立てる 吹き出しUIの実装とComposeのレイアウトフェーズ 同じ手法で矢印の向きや位置を変える 複雑な形状に影を付ける際の課題 Modifier の適用順と影を描画する余白 まとめ 相談の内容と9-patch画像の限界 デザイナーからの要望は、「特定の要素を指し示すために、下や上に矢印が付いた吹き出しを表示したい」というものでした。文字量によってサイズは変わり、画面の右寄りに配置されることもあれば、中央に配置されることもあります。 最初に検討したのは、Androidアプリケーション開発で以前からよく使われている「9-patch（ナインパッチ）画像」を用意する方法です。 9-patchとは、画像の一部だけを伸縮させても、角丸などの形状を保持できるAndroid向けの画像形式です。通常のPNG画像の周囲に、「引き伸ばしてよい領域（伸縮領域）」と「コンテンツを配置する領域」を指定して使用します。 これにより、中のテキストがどれだけ長くなっても、角丸や矢印の形を崩さずに背景画像をきれいに拡大・縮小できます。 実際、LIFULL HOME'Sの既存のAndroidネイティブ画面では、この9-patch画像を使って吹き出しを描画していました。 しかし、今回の「CMPによる共通コンポーネント化」という文脈では、9-patch画像には運用コストやOS依存の仕様という課題がありました。 アセット数の増加： 矢印の位置（右寄り、中央）、向き（上、下）、色を変えたい場合、それらの組み合わせごとに画像を用意する必要があります。 解像度ごとの管理： Androidでは、解像度ごとの画像を個別に書き出して管理する必要があります。角丸のサイズを少し変えたいだけでも、すべての画像を差し替える作業が発生します。 OS間の非互換性： 今回はCMPでAndroidとiOSに同じUIを提供する前提ですが、9-patchはAndroid固有のリソース形式です。iOSには resizableImage などの別のしくみがあり、共通のコードだけで扱うことはできません。 従来の「9-patch画像による実装」と、今回の「Compose（ Shape と Path ）による実装」の違いを整理すると、以下のようになります。 比較項目 9-patch画像による実装 Compose（ Shape と Path ）による実装 アセット管理 矢印の位置、向き、色、さらに解像度ごとの組み合わせ分だけ画像が必要になり、アセット数が増加する 吹き出しの形状を表す画像は不要。パラメータの変更だけで、さまざまなバリエーションに対応できる マルチプラットフォーム Android固有のリソース仕様。iOSでは別アプローチ（ resizableImage など）と別アセットによる個別実装が必要 commonMain に一度描画ロジックを書くだけで、AndroidとiOSで共通の描画ロジックを利用できる メンテナンス性 角丸や矢印のサイズ、色の微調整のたびに、デザインツールでの再書き出しと、エンジニアによる差し替え作業が発生する コード上の数値や計算式を書き換えるだけで、変更を反映できる アプリケーション容量 バリエーションの数だけ画像アセットを持つため、アプリケーション容量が増加する 複数の形状画像を持つ必要がなく、アプリケーション容量の増加を抑えられる ShapeとPathで輪郭を実行時に組み立てる この運用コストを解決するため、吹き出しを「画像」として持つのではなく、「コードで表現した輪郭」として描くことにしました。 Composeには Shape インタフェースがあります。このインタフェースの createOutline メソッドを実装すると、任意の Path （線や形状を定義するしくみ）を描画し、それを Outline.Generic(path) としてComposeに渡せます。 この自作した Shape を Modifier.clip(shape) や Modifier.background(color, shape) に渡せば、角丸矩形に矢印が付いた複雑な形状でも、きれいに切り抜いたり塗りつぶしたりできます。 Shape と Path は、いずれもCompose Multiplatformが共通APIとして提供している型です。そのため、KMPの commonMain （AndroidやiOSなど、複数のプラットフォームで共有するコードを置く領域）に一度実装すれば、AndroidとiOSで共通の描画ロジックを利用できます。 このアプローチでは、コンポーネントのサイズを入力として、描画する輪郭を計算できます。 そのため、矢印の位置や向き、角丸の大きさを、変数や座標計算によって柔軟に調整できます。色を変える場合は background の引数を変更し、矢印の位置を変える場合は座標の計算式を変更するだけです。画像を作り直す必要はありません。 吹き出しUIの実装とComposeのレイアウトフェーズ ここでは、下向き矢印の吹き出し（検索条件を案内するヒントなどに使用）の実装について説明します。 構造はシンプルで、「角丸矩形」と「三角形」の2つの要素を1つの輪郭として描画しています。ここで重要な役割を果たしているのが、 createOutline メソッドの引数として渡される size: Size です。 Composeは、画面上の大きさを決める測定（Measure）フェーズで、テキストや余白を含めたコンポーザブルの最終的なサイズを算出します。そして、そのサイズを size として createOutline に渡します。 矢印の水平位置は、「全体の幅からの引き算」で定義しています。これにより、テキストが長くなって吹き出しの幅が広がっても、矢印は常に「右端から一定の距離」を保ったまま追従します。 ユーザーがOSのシステム設定などでフォントサイズを変更した場合でも、レイアウトを崩すことなく、フォントサイズに応じてコンポーネントのサイズも調整されます。 同じ手法で矢印の向きや位置を変える この Shape と Path を使った手法を一度確立すれば、さまざまな形状に応用できます。 頂点のY座標を 0f （上辺）にすれば上向き矢印になります。また、水平位置を size.width / 2 のように幅の比率で指定すれば、常に中央に矢印が来るツールチップも作れます。 実際、地図画面の価格ピン（下向き・中央矢印）なども、 createOutline 内の座標式を少し変更するだけで展開できました。新しいバリエーションが必要になっても、解像度ごとのアセット作成をデザイナーに都度依頼する必要はありません。 複雑な形状に影を付ける際の課題 ここまでの実装で形状はきれいに作れましたが、デザイナーから「コンポーネントが浮いているように見せるため、影も追加したい」という要望を受けました。今回、実装上の主な課題となったのが、この「影」の扱いです。 角丸矩形に影を付けるのは簡単ですが、今回は「角丸矩形＋下に突き出るとんがり（矢印）」という特殊な形状です。単純に実装すると、以下のような問題が発生しました。 影のずれ： デフォルトの影は矩形の外形を基準に描画されるため、下へ突き出したとんがり部分に影が乗らず、不自然に浮いて見えてしまいます。 影の欠け（クリップ）： とんがり部分はコンポーネント本来の矩形領域の下端まで伸びています。そのため、そこから発生する影はさらに外側に広がります。今回はスクロールするコンテナの中にこの吹き出しを置いていたため、コンテナの範囲からはみ出した影が切り取られてしまいました。 形状は思いどおりに作れても、影を付けたときにとんがり部分の表示が崩れてしまいます。これは、Composeの描画仕様を理解したうえで実装する必要があるポイントでした。 Modifier の適用順と影を描画する余白 この問題を解決し、とんがりの先まできれいに影を沿わせるためには、Composeの Modifier の適用順と描画領域のしくみを理解し、以下の3つをそろえる必要があります。 影の Modifier に自作の Shape を明示的に渡す Modifier.shadow(elevation, shape) は任意の Shape を受け取れます。ここにデフォルトの矩形ではなく、自作した Shape を渡すことで、この形状の輪郭に沿って影を描画するよう指定します。 Modifier の適用順を padding → shadow → clip → background にする Composeの Modifier は、記述した順番によってレイアウトや描画への適用順が変わります。 影を clip より前に置くことで、切り抜く前の「とんがりを含む輪郭」に対して影を計算できます。逆に、 clip の後に shadow を置くと、輪郭の外側に広がる影が切り取られてしまい、ほとんど見えなくなります。 Modifier .padding(bottom = shadowPadding) // 影を描く余白を確保 .shadow(elevation, shape = sampleShape) // 自作Shapeに沿って影を描画 .clip(sampleShape) // 影を計算したあとに切り抜く .background(color, shape = sampleShape) 矢印の方向に厚めの padding を取り、影を描画する余白を確保する とんがり部分は矩形の外側にはみ出すため、そこから発生する影はさらに外側に広がります。これが自身の描画領域からはみ出してクリップされないよう、矢印がある側（今回であれば bottom ）に多めの padding を設定し、影が描画されるための余白を事前に確保します。 まとめ アプリケーション共通の「吹き出しUI」のコンポーネント化を起点に、従来の9-patch画像運用から、画像アセットに依存しない実装へ移行しました。その手段として、Composeの Shape と Path を使って輪郭を動的に組み立てる方式を採用しています。 createOutline が受け取る size を活用してコンテンツの大きさに追従させつつ、実装上の主な課題であった「特殊な形状への影の付与」についても、 Modifier の適用順（ padding → shadow → clip → background ）と、影を描画する余白の確保によって解決できました。 また、今回はUIをCompose Multiplatformの commonMain に配置したことで、この座標計算と描画ロジックを一度書くだけで、AndroidとiOSで共通のUIを提供しています。アセット管理の複雑さを抑え、OS間のUI差異を吸収できるCMPの有用性をあらためて実感する実装となりました。 最後に、LIFULLではともに挑戦していける仲間を募集しています。ご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co ※ 今回、紹介した LIFULL HOME'S アプリケーションは こちら になります。