今年は少し育児が落ち着いたので、DroidKaigi 2025 に参加してきました。

今までは視聴したセッションを手書きで頑張ってメモしていましたが、それだと書くことに集中しすぎて話を集中して聴くことができないため、今回はボイスメモを記録しておき、後でファイルを ChatGPT に渡して要約させてみました。
タイムテーブルの早い順にセッション名と要約した内容を記載していきます。

基礎から学ぶ大画面対応〜「Large screen differentiated」認定アプリの開発知見〜

セッション要約

タイトル： 基礎から学ぶ大画面対応〜「Large screen differentiated」認定アプリの開発知見〜
所要時間： 約35分
登壇者： （後ほど内容から判明すれば追記します）

:compass: セッション概要（目的と背景）

Google Play で新たに導入された「Large screen differentiated」認定を取得するには、タブレットや折りたたみ端末などの大画面に最適化されたUI設計が必須です。本セッションでは、認定を取得するために必要な要件・設計指針・技術的工夫を、実際のアプリ開発事例をもとに紹介します。

主な内容とポイント

大画面対応の意義と背景
- タブレットや折りたたみ端末の利用が増加
- GoogleのUIガイドライン強化：ユーザー体験向上とGoogle Playでの可視性向上
「Large screen differentiated」認定の条件
- リサイズ可能なUI
- 各画面サイズでの最適なレイアウト（例：600dp以上の幅での分割ビュー対応）
- 入力支援（キーボード・タッチパッド・スタイラス）
- Android 12L以降のウィンドウ管理への対応
開発アプローチ
- ConstraintLayoutやBoxWithConstraintsなどで柔軟に対応
- ウィンドウサイズクラスの活用（WindowSizeClass）
- デバイスに応じてナビゲーションUIを切り替える
  - ナビドロワー ⇄ ボトムナビ ⇄ レールナビ
Composeによる大画面最適化
- Modifier.widthIn, BoxWithConstraints を用いたレイアウト調整
- マルチペイン構成：一覧＋詳細表示（Split View）
- 折りたたみ端末での画面分割制御
Tipsと落とし穴

:test_tube: 実際の事例紹介（印象的な部分）

認定取得までのプロセス： 申請 → Google側レビュー → 改善 → 合格
QAチームやデザイナーとの連携が重要（デバイスモックを使った検証）

Takeaways（まとめ）

大画面対応は「ただの見た目対応」ではなく「機能的UX改善」である
Compose + WindowSizeClass + 分割ビュー設計を組み合わせることで効率的に対応可能
認定を取得することで、Google Play上での評価や見つけやすさが向上する

UIだけじゃないComposeの可能性 ━ 宣言的に奏でるメロディ

セッション要約

タイトル： UIだけじゃないComposeの可能性 ━ 宣言的に奏でるメロディ
所要時間： 約38分
登壇者： （判明次第追記予定）

:compass: セッション概要（目的と背景）

Jetpack Compose は「UI構築のための宣言的DSL」として知られていますが、その応用範囲は「UI以外」にも広がります。このセッションでは、Composeの内部構造と状態管理の仕組みを活用し、音楽（メロディ）を宣言的に構築する挑戦を通じて、Composeが持つ柔軟性と抽象力の高さを実証します。

Composeでメロディを作るとは？

ComposeはUIだけじゃない
- 「状態に応じて構造を作る」というコンセプトは音楽にも応用可能
- 再生位置、音階、テンポ、ボリュームなどを「状態」と見なせる
音楽要素をComposableにする
- UIの@Composable関数の様に、Note(...)やTrack(...)といった音楽要素をComposableとして扱う
Jetpack Composeの基礎概念を再利用
- スナップショット状態管理
- Composition → Recomposition（曲の変更への動的対応）
- rememberやderivedStateOfといった仕組みを活用

実装ハイライト

音楽合成エンジンの構築
- Compose Runtime を再利用し、音の構成を記述するためのDSLを実装
- 実行時にはAudioTrackを使って実際に出力

コード例：

@Composable
fun SimpleMelody() {
    Track {
        Note(pitch = "C4", duration = 500.ms)
        Note(pitch = "E4", duration = 500.ms)
        Note(pitch = "G4", duration = 1000.ms)
    }
}

メリット
- 状態に応じてリアルタイムで音の流れを変化させられる
- PreviewやHot Reloadに近い開発体験が可能
- UIエンジニアがDSLの設計に慣れていれば理解しやすい
難しかった点
- Compose Runtimeを音楽に最適化するための抽象化設計
- 音の再生タイミング制御やレイテンシの考慮
- AndroidのAudioTrack周りのAPI制約

Composeの応用的可能性

UIだけでなく「状態に応じた構造を宣言的に作る」分野全般に応用可能
ゲーム開発、リアクティブなアート生成、IoTデバイス制御などへの展開が期待される
Composeは単なるUIツールキットではなく、リアクティブDSLプラットフォームとして活用できる

Takeaways（まとめ）

Composeの柔軟な構造は、UI以外にも応用可能
宣言的プログラミングのメリット（意図が明確、状態に強い）を活かせる分野は多く存在する
「音楽をComposeで組み立てる」という実践は、Composeの本質を理解する良い訓練になる
今後、Compose Runtimeを活用した「非UI」プロジェクトが増えていく可能性がある

これでもう迷わない！Jetpack Composeの書き方実践ガイド

セッション要約

タイトル： これでもう迷わない！Jetpack Composeの書き方実践ガイド
所要時間： 約36分
登壇者： （内容から特定でき次第追記）

:compass: セッション概要（目的と背景）

Jetpack Composeの導入は増えていますが、「どう書けばいいかわからない」「プロダクション品質にするには？」といった悩みは依然として多いです。本セッションでは、そうした迷いを解消するため、実践的な設計パターン、命名規則、再利用の考え方などをガイドライン形式で紹介します。

主な内容と技術的ポイント

Composeでよくある悩みとその解消法

どこまでをComposableにするか？
- 小さすぎるComposableは、可読性やパフォーマンスの面で逆効果になることがある
- 基本は「状態単位」で切り分け、UI構造単位でまとめるのがおすすめ
関数の命名ルール
- @Composable関数には名詞ベースの名前を推奨（例： UserCard, ArticleListItem）
- 状態管理を行う関数にはremember系のプレフィックスを付与（例： rememberUserCardState()）
ステートの渡し方
- Hoisting（親で状態を保持し、子に渡す）を基本とする
- 必要に応じてrememberを併用し、ローカルに状態を保持

よく使われる設計パターン

「UI階層」＋「ロジック分離」
- UI層（View）とUIステート／ロジック層（ViewModel or Presenter）を明確に分離
イベントハンドラの取り扱い
- イベントはラムダで子Composableに渡す（例： onClick: () -> Unit）
Slot APIの活用
- モーダル、カード、ダイアログなど、共通化しやすい汎用UI部品に適用
- @Composable content: @Composable () -> Unit を使うことで、柔軟なUI構成が可能
デフォルト引数とテーマの活用
- テーマの色やスタイルを直接使わず、引数で注入可能な設計にする

:balance_scale: 再利用と可読性のトレードオフ

再利用性ばかりを優先すると、逆にコードが複雑になることがある
- 初心者がやりがちな罠： すべてのUIを汎用化しようとして、使いにくいAPIを作ってしまう
「1画面内で使い回されるなら、その画面内だけで使える使い捨てComposableでも良い」と考える
見通しのよい構造が最優先
- Composableの階層が3階層以上になる場合は、設計の見直しを検討
- @PreviewでUIの部品単位テストも忘れずに実施

Takeaways（まとめ）

Jetpack Composeは「どう書くか」によって、可読性・保守性が大きく変わる
状態・イベント・UIをしっかり分けることが、最大の設計指針
再利用は目的ではなく、保守性と明確な責務分担を優先して考える
小さな@Composable関数を積み上げるのではなく、構造と役割に応じた適切な粒度でまとめることが大切

Androidエンジニアとしてのキャリア

セッション要約

タイトル： Androidエンジニアとしてのキャリア
所要時間： 約43分
形式： パネルディスカッション形式
登壇者（※一部）： 複数の現役エンジニア・マネージャー（メガベンチャー、スタートアップ、SIer出身者など）

:compass: セッション概要（目的と背景）

Android開発者として、どんなキャリアパスがあり得るのか？転職やスキル選択、将来的な展望、チームでの立ち位置、そして技術との向き合い方などを、実体験ベースで語るパネルディスカッションです。「これからどうキャリアを考えていくか悩んでいる人」や「開発以外の道も検討中」の人に向けた示唆に富んだ内容となっています。

主なトピックと発言内容

Androidエンジニアのキャリアの選択肢

アプリ開発一本でいく（技術特化型）
テックリードやアーキテクト（横断的な技術支援や設計支援）
PdM・EM・マネージャーなど「非コード」領域に進む
他プラットフォームやKMPなどの技術に広げる（クロスプラットフォーム）

キャリアの転機と選択

「モバイルだけだとキャリアが狭くなる？」という不安に対する回答
- 実際にはモバイルに特化していることで強みになる場面も多い
- ただし中長期的に市場の変化（AI, Web技術のモバイル進出等）を意識するのも大切
転職理由・悩み
- 「Androidしかできないと不安」
- 「開発は好きだけど、PdM的視点も身につけたい」
- 「技術は得意だけど人とのコミュニケーションが苦手でマネージャーは無理だと思っていた」
対話の中で出てきた視点
- 苦手だと思っていたマネジメントも「スキル」として習得可能
- 経験年数より「なぜその選択をしたのか」の言語化が重要

これからのキャリア形成に必要な視点

目の前の開発だけでなく「隣の職域」も少しだけ意識する
- デザイン・プロダクト・ビジネスとのつながりを持つことで、提案力や裁量も増える
発信することの重要性
- 技術ブログ・登壇・OSS活動は、結果的に転職市場でも強みになる
「コードだけ書いていればいい」は幻想？
- 小さなチームや新規事業では「コード＋チーム設計＋プロダクト志向」が求められることも

Takeaways（まとめ）

Androidエンジニアのキャリアは「一本道」ではなく、広がりがある
自分の得意・苦手を言語化しながら「キャリアの仮説」を立てて進んでいく姿勢が重要
技術に閉じず、他職種との連携やマネジメントへの理解も価値になる
「何者か」になることよりも「どう働きたいか」を考えることがキャリア設計の第一歩

Gemini エージェントで Android Studio 開発を高速化

セッション要約

タイトル： Gemini エージェントで Android Studio 開発を高速化
時間： 約40分
登壇者：
公式概要： DroidKaigi 2025 Timetable (※リンクは仮のものです)

:compass: セッション概要（目的と背景）

本セッションでは、Googleが提供する Gemini in Android Studio の開発支援機能、特にエージェント機能に焦点を当て、Androidアプリ開発の効率をどう上げられるかを実演・解説します。開発者が Gemini をどのように活用し、日々の作業を短縮・効率化できるのかを具体的に紹介します。

Gemini エージェントとは？

Android Studioに統合されたAIベースの開発支援ツール
Chatプロンプト型ではなく、エージェント（Agent）型でコードやUIに深く統合
IntelliJベースのIDEと緊密に連携し、文脈を理解してアクションを提案

主な機能・デモ内容

コードリーディング支援

クラスや関数の目的を説明（例：「このViewModelは何をしている？」）
ソースコードの依存関係を自動で要約
外部ライブラリの使用意図も補足

コード生成

プロンプトベースで Composable 関数や ViewModel の雛形を生成
テストコードの自動作成（JUnit, Espresso など）

リファクタ提案と実行

状態のリフトアップ、Composable 分離、命名の改善などを提案
リファクタを安全に適用できる「ステップ付きワークフロー」

UI設計支援

FigmaファイルやUI要件から Composable UIを自動生成（参考実演あり）
Material3 Design準拠のコードを生成する能力

実演ハイライト

実際の Android Studio を用いたライブデモで以下を実施
- Compose UIの初期構築をGeminiで一瞬で生成
- 「このコードの責務が不明瞭」といったコメントから自動的に改善提案
- テストケース作成を、自然言語から生成
- サンプルアプリに対して、Gradle構成を最適化する提案まで提示

技術的なポイント

Geminiはプロンプトに対するコンテキスト理解が非常に高い
現在のプロジェクト構成や、開いているファイル、直前の操作などを踏まえて回答
Kotlin, Jetpack Composeに特化した提案ができるのが特徴
Android Studio Hedgehog / Iguana 以降に統合される方向で進化中

Takeaways（まとめ）

Geminiエージェントは「Chat」ではなく「Context-awareなAIアシスタント」
Android開発における学習・設計・コーディング・リファクタ・テストのすべてに活用可能
導入初期は学習用途に、熟練者には生産性強化用途に最適
今後も Jetpack Compose / Gradle / テスト自動化との連携強化が見込まれる

ComposeではないコードをCompose化する

セッション要約

タイトル： ComposeではないコードをCompose化する
登壇者：
所要時間： 約41分
概要URL： DroidKaigi公式リンク

:compass: セッション概要

このセッションは、既存のXMLベースのAndroidアプリをJetpack Composeへ段階的に移行する際の実践知見を共有するものです。「一気に全部置き換えるのは現実的ではない」という前提のもと、以下の観点で解説が行われました。

どのようにCompose化を進めるか？
UI設計・状態管理・チーム連携で気をつけることは？
移行のベストプラク-ティスと落とし穴は？

Compose化における実践ステップ

移行方針の明確化

全部置き換える？混在させる？
- 多くの現場では「混在型」移行が現実的（Viewベース + Compose）
Compose化の目的を明確に
- パフォーマンス改善か？
- 開発生産性の向上か？
- メンテナンス性の向上か？

UI構造と状態の見直し

Viewベースのコードは、状態と表示が分離しづらい構造が多い
- → Composeにするには、状態の可視化と単方向データフローへの変換が必要
ViewModelを活用したStateのリフトアップが鍵
画面ごとの状態をCompose UIにスムーズに渡せるように設計

互換性を保ちながらの移行テクニック

ComposeView を既存のレイアウトに組み込むことで段階的移行が可能
ViewBinding を活用して既存UIと連携しやすくする

実際の構成例：

binding.someFrameLayout.addView(
    ComposeView(context).apply {
        setContent {
            MyComposableComponent()
        }
    }
)

Compose移行時にハマったこと

スクロールのネスト → LazyColumn + Column の構成ミスによる描画不具合
アニメーション系 → Modifier.animate* の動作仕様理解不足
状態管理の煩雑化 → remember, derivedStateOf の誤用によるバグ

:people_holding_hands: チームとして移行を進めるために

PRは小さく・段階的に出す（レビューしやすく、バグも減らせる）
共通UIパーツは先にComposable化しておくと効率的
@Preview活用やStorybook的運用でUIの設計・レビューを円滑にする

Takeaways（まとめ）

Compose化は「置き換えること」ではなく「設計の見直し」
Compose導入により状態管理・責務分離が明確になり、保守性が高まる
互換手段を活用し、無理なく段階的に導入することが成功のカギ
開発チーム全体で「目的を共有しながら進める」ことが大切

このセッションが役立つ人

既存アプリを徐々にComposeに切り替えたいエンジニア
Viewベースからの移行に悩んでいるチーム
状態管理の設計に課題を感じているプロジェクト

「どこから読む？」コードとカルチャーに最速で馴染むための実践ガイド〜新メンバーを活躍に導くオンボーディング戦略〜

セッション要約

タイトル： どこから読む？コードとカルチャーに最速で馴染むための実践ガイド
副題： 新メンバーを活躍に導くオンボーディング戦略
登壇者： ZOZOテクノロジーズの開発者（@zozotech）
所要時間： 約36分

:compass: 概要（背景と目的）

新しい開発チームやコードベースに参加したとき、「どこから読めばよいのか？」「どうすれば文化に馴染めるのか？」という課題に直面します。このセッションでは、新メンバーがコードとカルチャーを素早く理解し、活躍できるまでのオンボーディング戦略を実例を交えて紹介します。

コードに最速で馴染む方法

読むべきファイルの優先順位

Applicationクラス：アプリの起動ロジックと全体構成の出発点
MainActivity / MainViewModel：初期画面の動作を理解
build.gradle / AndroidManifest.xml / strings.xml：アプリの全体的な構造や依存関係
DI（Hilt / Dagger）設定：プロジェクト全体の依存管理の理解に必須

モジュール・ディレクトリ構成を観察

feature/, core/, data/ などの命名に注目し、責務と依存関係を把握
UI起点に画面をたどることで、自然に処理の流れが見えるようになる

UI起点の探索方法

ホーム画面やランチャー画面から遷移先をたどる
BottomNavigation や DrawerNavigation で主要な画面構成が分かる

カルチャーに馴染むための観察ポイント

チームの言葉・空気感を読む

PRの書き方・レビューコメントのトーン
- → 敬語が多いか・絵文字を使うか・軽いツッコミがあるか
SlackやNotion、社内ドキュメントの「雑談」と「知識の粒度」
- → 社風やメンバー間の距離感をつかむ手がかり

開発フローやCI/CDの理解

Git flow か trunk-based か
テスト自動化・Lint・CI設定の粒度と品質文化の反映

実践Tips（即使えるオンボーディング戦略）

1週間目にやること

コードリーディング会を依頼 or 自主開催
「最初のPR」は小さく・安全に（文字修正・コメント追加など）
Mentorを見つけて「質問しやすい人」を確保
Slackでの会話にゆるく混ざって文化を感じ取る

継続的なキャッチアップの工夫

PR一覧を毎日観察して習慣化
Techブログや社内ナレッジの読み合わせをチームで行う
コードレビューコメントをログとして読む

Takeaways（まとめ）

新メンバーが早期に戦力化するためには、「どこを見るか」を明示することが最重要
コードと文化の両方に観察ポイントがあり、それぞれに合わせた読み方がある
一人でがんばらず、チームと一緒に「キャッチアップの土台」を築く工夫が重要
良いオンボーディングは、最終的にチームの生産性と安心感を底上げする

この内容が活かせる場面

新人や中途入社のオンボーディング設計
OSS参加時や他チームのコードを読むとき
開発文化の見直しやナレッジ共有施策を考える時

Metro で学ぶ依存性注入のナビゲーション

セッション要約

タイトル： Metro で学ぶ依存性注入のナビゲーション
登壇者：
所要時間： 約40分
概要URL： DroidKaigi公式リンク

:compass: セッション概要

このセッションは、メルカリのUIアーキテクチャ「Metro」をベースに、依存性注入（DI）とナビゲーションの設計手法を具体的に解説します。特に、Jetpack Compose と Navigation Compose を使った最新アーキテクチャにおける、画面間の依存やデータ渡しの扱い方に焦点を当てています。

「Metro」とは？

メルカリが採用しているUIアーキテクチャのコードネーム
画面単位での独立性・責務分離・再利用性を重視
「一方向データフロー」＋「状態とロジックの分離」に基づく構造

本セッションの主な目的

画面遷移時の依存関係注入をどうシンプルにするか
Navigation ComposeとDIの整合性をどう取るか
状態と責務を明確に保ちながらスケーラブルに設計する方法

技術的構成と実装戦略

Compose Navigationの基本構造（Metroでの例）

NavHost(...) {
    composable("home") {
        val viewModel = hiltViewModel<HomeViewModel>()
        HomeScreen(viewModel)
    }
    composable("detail/{itemId}") {
        val viewModel = rememberItemViewModel(itemId)
        DetailScreen(viewModel)
    }
}

依存性注入は各Composableで行うのではなく、NavGraphで集約
SavedStateHandle や HiltViewModelFactory を活用して、安全にViewModelへ引き継ぎ

Metro流 DI設計のポイント

Feature単位でのスコープ管理
各画面は自身に必要な依存だけを知っていればよい（Low Coupling）
Factoryを用いたViewModel生成
- Hiltの制約を回避するためにカスタムFactoryを導入するケースも

画面間でのデータの受け渡し

ナビゲーション引数で itemId 等を渡す際も、できる限り型安全 + スコープ安全に設計
Navigation Arguments → SavedStateHandle → ViewModel の順で接続
「引数の数が多い」「型が複雑」な場合は、NavGraphで定義するのではなくDIでまとめて渡す方が保守性が高い

開発現場で得た知見

DIとNavigationを無理に1つのコンポーネントに押し込めると、責務が肥大化しがち
Navigationは「移動の責任」、ViewModelは「状態とロジックの責任」と役割を分離すべき
Composeでは「画面＝関数」なので、画面ごとにDIを明確に定義することが重要

Takeaways（まとめ）

Metroアーキテクチャは、DIとNavigationを明確に分離して設計する思想がベース
Composableごとに責任を分離することで、スケーラブルかつテスト可能な構造が作れる
Navigation引数やDIスコープの適切な設計は、将来の保守性・可読性を大きく左右する
Jetpack Compose時代のナビゲーション設計は「コードの見通しの良さ」と「スコープの明示」が鍵

このセッションが役立つ人

Jetpack Composeベースの新規アプリを設計中の開発者
DIとNavigationの整合性に悩んでいるアーキテクト
Hilt + Compose環境でのスケーラブルな画面設計を学びたい人

Cache Me If You Can

セッション要約

タイトル： Cache Me If You Can
登壇者： @ryunen344
所要時間： 約42分
形式： スライド＋実体験に基づく技術的プレゼンテーション

:compass: セッション概要

本セッションでは、Androidアプリにおけるキャッシュ設計とその信頼性確保をテーマに、「なぜキャッシュが必要なのか？」「どのように安全かつ有用にキャッシュを設計するか？」について、技術的知見と実装例を交えながら深掘りします。

なぜキャッシュが必要か？

モバイルネットワークは不安定なため、即時表示やオフライン対応が重要
APIレスポンスの頻度や信頼性を上げるにはローカルキャッシュが効果的
ユーザー体験の向上（例：ニュース一覧、画像読み込み、設定情報の保存）

キャッシュの種類と特徴

種類	特徴	主な用途例
Memory Cache	非常に高速だが一時的	`Coil` / `Glide` など画像系
Disk Cache	永続性あり・中速	`Retrofit` / `OkHttp` のレスポンス
Database（Roomなど）	検索・整形しやすい	ローカル保存された一覧データ
Preference / Proto DataStore	Key-Value 型に強い	設定値 / 最終取得時間など

キャッシュ設計のベストプラクティス

信頼できるキャッシュ設計とは

明示的に「いつ作られたか・いつまで有効か」を管理する
キャッシュ破棄（invalidate）を自動化／制御可能にする

よくある失敗例

期限管理なしで「無限に使われるキャッシュ」
複数ソース（Remote/Cache）間の不整合でバグを生む
キャッシュの更新がUIに反映されない（Flow未活用など）

実装方針と構成例

Repositoryパターンで「Remote」「Cache」層を統合
- API成功時： Cache更新＋UI更新
- API失敗時： Cacheから取得（但し、使用可否のロジックを明示する）
技術構成
- Retrofit + OkHttp + Room + DataStore
- Flow によるリアルタイムUI更新

Tips（経験に基づく実用的な工夫）

ETag や Last-Modified を用いた差分取得戦略
キャッシュ更新時刻を DataStore に保存して比較
開発中は「キャッシュバスティング」（強制クリア）機能が役立つ
ユーザー行動に応じた invalidate も設計に含める（例：ログアウト時）

Takeaways（まとめ）

キャッシュは「UXの裏方」だが、設計次第で信頼性と快適さが大きく変わる
明確な責務分離（Repository + DataSource）がメンテナンス性を高める
「どの情報をどこに保存するか？」をコードで説明できる状態が理想
テスト性・再現性・切り替えやすさを考慮し、実装と設計のバランスを取ることが重要

想定読者と活用シーン

モバイルアプリでネットワーク遅延や再取得がUX問題になっている開発者
キャッシュ戦略をチームで再検討している設計担当者
Repository パターンの責務設計に悩んでいる人

所感

ボイスメモだけでもある程度きちんと要約してくれるが、欲しい情報が全て得られるわけではない
モバイルアプリ経由だとボイスメモのファイルがアップロードできなかった（Wi-Fi があるとうまくいくかも）
スライドやタイムテーブルのリンクを予め渡しておくとより精度が上がると感じた
なぜか登壇者名が全然違う人になっていたりする（実名が入っているためその部分は手動で削除しました）
Markdown 形式にしたい場合はその旨もプロンプトで伝えておく必要がある
発表終了後に YouTube でアップロードされるので、それを要約させる方がもっと高い精度が出るかもしれない