はじめに
こんにちは。先日開催されたDroidKaigi 2026に参加してきました。
DroidKaigiは、Android技術情報の共有とコミュニケーションを目的とした、Androidエンジニアが主役のカンファレンスです。
2026年は9月1日から3日まで、ベルサール渋谷ガーデンで開催されました。
droidkaigi.jp
1日目のワークショップには参加せず、2日目から参加しました。
本記事では、DroidKaigi 2026に参加して印象に残ったことや、会場で感じたことを書いてみたいと思います。
お馴染みの大看板
参加賞Tシャツ
参加した理由
今回参加した理由は、ほかのエンジニアがどのような課題を持ち、どのように開発を進めているのかを知りたいと思ったためです。（最近はAndroid開発から少し離れ気味ではありますが…）
普段から技術記事や動画で情報を見ることはできますが、カンファレンスでは、実際に開発している方の経験や試行錯誤を直接聞けます。
新しい技術を知るだけでなく、今の自分の開発を見直すきっかけにもなればと思い、参加しました。また、自分のAndroid開発に対するモチベーションも高めたいという気持ちも、密かにありました。
ちなみに、DroidKaigiへの参加は今回で2回目です。前回参加したときとは自分の担当業務や興味のある分野も変わっているため、今回はまた違った視点でセッションを聞くことができました。
印象に残ったセッション
今回もさまざまなテーマのセッションがありました。
これまでは自分が興味のあるセッションを中心に聴講していましたが、今回は少し選び方を変え、次の観点で参加するセッションを決めました。
- チームに共有できそうな内容
- 実際の業務や今後の開発に活かせそうな内容
- 現在の自分の知識で、ある程度理解できそうな内容
自分の理解度から大きく離れたセッションは、せっかく聴講しても内容を十分に持ち帰れないことがあります。そのため今回は、自分が理解できることを前提に、その後の開発につなげられそうなセッションを選びました。
同じ時間帯に4つのセッションが並行して行われていましたが、上記の観点に合うものがない場合は、無理にすべての時間でセッションを聴講せず、スポンサーブースを回るなど、ほかのことに時間を使いました。
以下では、特に印象に残ったセッションについて取り上げてみたいと思います。
デバイス操作はAIエージェントの時代へ。mobile-mcpを活用したAndroid UI/E2Eテストの挑戦
2026.droidkaigi.jp
Mori Atsushiさんのこちらのセッションを聴講しました。
このセッションでは、mobile-mcpを使ってAIエージェントにエミュレーターや実機を操作させ、アプリの動作確認やテストを行わせる方法について紹介されていました。
AIにコードを書かせた後、意図した画面になっているか、既存の動作が壊れていないかについては、手元でアプリを起動し、人が目で確認するのが当たり前だと思っていました。
特に印象に残ったのは、AIによるデバイス操作を、従来のE2Eテストの単純な置き換えとして使うのではなく、実装後の軽量な動作確認やバグ調査などに使うという考え方です。
たとえば、実装した機能がひとまず動いているか確認する、ログを監視しながら不具合を再現する、古い実装と新しい実装を切り替えて挙動を比較するといった使い方が紹介されていました。
一方で、AIによるデバイス操作には時間やコストがかかります。また、AIが操作の手順を飛ばしたり、期待した状態になっていないにもかかわらず、テストに成功したと判断したりする可能性もあります。
そのため、繰り返し実行する回帰テストは従来の自動テストを使い、開発中の軽い確認や調査にはAIによるデバイス操作を使うなど、目的に応じた使い分けが必要だと感じました。
また、AIにただ「この画面をテストして」と依頼するだけではなく、画面の開き方や期待する状態をまとめたリファレンスファイルを用意するなど、AIが迷わず操作できる仕組みを作ることも重要でした。
コードを書かせるときと同じように、デバイスを操作させる場合も、AIが理解しやすい情報を人間側で準備する必要があるのだと思います。
mobile-mcpは聞いたことがありましたが、まだ使ったことはありません。まずは個人開発のアプリで、実装後の簡単な動作確認を任せるところから試してみたいと思います。
あなたのANRはどこから？ — 発生する仕組みを診断し、症状別に処方する
2026.droidkaigi.jp
次に印象に残ったのは、chomiさんのこちらのセッションです。
ANR（Application Not Responding）が発生する仕組みや原因の調べ方について、実際の事例を交えながら紹介されていました。
自分もAndroid開発をしていると、ANRに遭遇することがあります。
ただ、クラッシュと比べると原因を示す情報が分かりにくく、アプリがその後も動作する場合もあるため、これまでは対応の優先度をあまり上げられていませんでした。
しかし、操作しても画面が反応しない状態は、ユーザーから見るとアプリが壊れているのとほとんど変わりません。
さらに、ユーザーが認識できるANRの発生率は、Android vitalsのコア指標のひとつです。基準を超えると、Google Play上でアプリが見つかりにくくなったり、ストアの掲載ページに警告が表示されたりする可能性があることを知りました。
全デバイスを対象とした基準では、1日のアクティブユーザーのうち0.47%以上がユーザー認識ANRを経験すると、Google Playが定める全体の基準値を超えます。端末モデルごとにも8%という基準があるそうです。
個人的には、想像していたよりもシビアな数値だと感じました。
セッションでは、メインスレッドでのI/O、アプリ起動時の重い初期化、Binder呼び出し、ロックの競合など、ANRにつながる複数の原因が紹介されていました。
ANRというと、単純にメインスレッドで重い処理をしている状態を想像していました。しかし実際には、メインスレッド自身が働きすぎている場合だけでなく、ほかの処理やロックを待たされている場合もあります。
同じANRでも原因によって確認する場所や対処方法が異なるため、まずはスタックトレースを見て、メインスレッドが何をしているのかを整理することが大事だと学びました。
今後はANRを後回しにせず、Play ConsoleのAndroid vitalsを定期的に確認したいと思います。また、メインスレッドでI/Oを行っていないか、起動時に不要な初期化をしていないかについても、実装やレビューの際に注意していきたいです。
こちらのセッションも、普段の開発に直接持ち帰れる学びが多かったです。
AI に Inclusive UI を書かせよう — Design Rules Skill で Compose UI を作り直す
2026.droidkaigi.jp
bamiさんのこちらのセッションも印象に残りました。
独自のDesign Rules Skillを整備し、AIにInclusive UIを実装させるアプローチについてのお話でした。
自分は今回、Inclusive UIという言葉を初めて知りました。
これまでUIを実装するとき、画面の見た目や使いやすさを考えることはあっても、それを使う人の視力や身体の状態、認知特性まで具体的に想像することは、あまりできていなかった気がします。
視力が低下している人、手を自由に動かしにくい人、認知症の人など、さまざまな人がいます。
自分にとって分かりやすいUIであっても、誰かにとっては意味を理解しにくかったり、操作できなかったりするかもしれません。
セッションでは、トイレのピクトグラムを例に、アイコンだけでは意味を推測しづらい人もいることが紹介されていました。
記号だけに頼るのではなく言葉を添える、色だけで状態を表現せず、文字やアイコンも組み合わせるといった工夫は、特定の人だけでなく、多くのユーザーにとって分かりやすいUIにつながります。
また、AIに「アクセシビリティを考慮して」「使いやすいUIにして」と伝えるだけでは、必要な対応がすべて実装されるとは限りません。
コントラスト、文字サイズ、ボタンの文言、エラーの表示方法などについて、何をどのように実装するのかを具体的なルールにし、AIが参照できるSkillとして渡すという考え方が印象に残りました。
AIが良いUIを考えてくれることを期待するのではなく、人間が考えた「誰も取りこぼさないためのルール」を、AIが実装できる粒度まで明文化する必要があるのだと思います。
一方で、AIがルールに沿って実装したからといって、それだけでInclusive UIが完成するわけではありません。
TalkBackや文字サイズを大きくした状態、Accessibility Scannerなどを使って確認し、最終的には当事者と一緒に、本当に情報が届くかを確かめることも必要だと紹介されていました。
AIに実装を任せる範囲が広がるほど、人間側には、何を大切にするのかを言葉やルールとして定義する役割が求められるのだと感じました。
まずは普段実装している画面について、アイコンだけで意味を伝えようとしていないか、色だけに頼っていないか、エラーを見たユーザーが次に何をすればよいか分かるか、といった観点で見直してみたいと思います。
参加して良かったこと
今回参加して良かったのは、新しい技術を知ることができただけでなく、普段の開発について考え直すきっかけをもらえたことです。
セッションを聞いていると、「この考え方は今のプロジェクトでも使えそう」「この部分はもう少し学び直したい」と思う場面が何度もありました。
今回知ったことの中から、まずは次のことに取り組んでみたいと思います。
- Play ConsoleのAndroid vitalsを定期的に確認し、ANRの傾向を把握する
- mobile-mcpを使い、AIからデバイスを操作できる環境を整える
- 普段実装しているUIが、色やアイコンだけに頼ったものになっていないか見直す
すべてを一度に始めるのではなく、現在の開発に取り入れやすいものから少しずつ試していきたいです。
終わりに
今回は、DroidKaigi 2026に参加して感じたことを書きました。
技術的な学びはもちろんですが、さまざまなエンジニアの考え方や経験に触れられたことも、良い刺激になりました。参加した目的のひとつだった、Android開発へのモチベーションを高めることもできたように思います。
日々の開発だけでは、どうしても目の前のタスクに集中してしまいます。今回のようなカンファレンスに参加して、一度立ち止まり、普段とは違う視点から開発について考える時間も大事だと感じました。
今回得た知識をそのままにせず、まずは小さく試しながら、今後の開発に活かしていきたいと思います。
運営スタッフ、登壇者、スポンサー、参加者の皆さん、ありがとうございました！
