DroidKaigi 2025 現地レポート！Android開発の「今」と「未来」がここに

こんにちは、TRUSTDOCKでAndroidエンジニアをしているリキです！
今回はDroidKaigi 2025に参加してきました。

「Kotlin Multiplatform（KMP）とCompose Multiplatform（CMP）」のワークショップへの参加　、興味深かったセッション、その他各企業ブースや懇親会などの情報をお届けします♩

TRUSTDOCKはDroidKaigiのスポンサーをしています♩

レポートの本題に入る前に、少しだけ私たちのお話をさせてください。

会場のどこかでTRUSTDOCKのロゴを見つけてくださった方もいるかもしれませんが、私たちはDroidKaigi 2025にスポンサーとして参加させていただきました！

私たち自身、Androidエンジニアとして毎年多くの学びと刺激をこのカンファレンスから得ています。TRUSTDOCKは「デジタル社会のインフラを創る」という大きなミッションを掲げていますが、その根幹を支えているのは、DroidKaigiで語られるような一つ一つの技術への探求心です。この記事を通して、DroidKaigiの楽しさと学びを皆さんと一緒に分かち合えれば嬉しいです！

実際に手を動かしながら学べるワークショップ

1日目はKotlin MultiplatformとCompose Multiplatformを使ってクロスプラットフォームアプリを作るワークショップに参加しました。

下記の環境を用意して、提供されたコードに対してクロスプラットフォーム対応をしていきます。

• Android Studio
• Android StudioのプラグインであるKotlin Multiplatformを使用
• Android StudioでK2 Modeを有効化設定にする

Kotlin Multiplatform / Compose Multiplatformとはなんぞや？

普段、私たちがAndroidアプリを開発する際には、Kotlinを使ってロジックとUIを構築しています。一方、iOSアプリはSwiftで開発するのが一般的です。

Kotlin Multiplatform（KMP）とCompose Multiplatform（CMP）を活用することでKotlinを使って共通化できます。

Kotlin Multiplatform (KMP)：アプリの 「頭脳」 にあたる部分を共通化する技術です。API通信やデータ処理、ビジネスロジックなど、AndroidとiOSの両方で共通して使える部分をKotlinで記述します。これにより、同じロジックを二度書く手間がなくなり、開発効率が飛躍的に向上します。Google自身もKMPを推奨し、社内プロダクトでも活用している注目の技術です。

Compose Multiplatform（CMP）：アプリの 「顔」 にあたるUIを共通化する技術です。Androidで使われているJetpack Composeをベースにしているため、一度コードを書けば、Android、iOS、デスクトップなど、様々なプラットフォームで動くUIを構築できます。

ワークショップで体験したKMPの仕組み

ワークショップでは各プラットフォームに依存するデータの保存・読み込み処理を実装しました。
KMPのプロジェクトは、commonMainという共通コードの場所と、androidMainやiosMainといったプラットフォームごとのコードを書く場所に分かれています。

ここで登場するのが、KMPの核心技術であるexpect/actualです。
まず、commonMainに「文字列を保存するよ！」という 約束（expect） を定義します。

expect fun persistString(key: String, value: String)

expect fun restoreString(key: String): String

次に、それぞれのプラットフォームで、その約束を 実際に（actual） 守るための具体的なコードを書きます。

actual fun persistString(key: String, value: String) {
    // ここに各プラットフォーム特有処理を書く
}

actual fun restoreString(key: String): String {
    // ここに各プラットフォーム特有処理を書く
}

このように、ロジックの骨格はcommonMainで共通化しつつ、プラットフォーム固有の機能が必要な部分だけは、ネイティブの力を借りて実装できるのがKMPの大きな強みです。

ただ一つだけ気になることが・・・

めちゃくちゃビルドが遅い！

自分と同じテーブルにいた人が皆言っていたのですが、ビルドめっちゃ遅かったです。
iOSが特に遅い印象があり、小さい規模のサンプルアプリ程度でストレス感じるぐらい遅かったので気になりました。

JetBrains社員に聞いた、Flutterとの違い

JetBrains社員と会話する機会があったのでFlutterとの違いを聞きました。

Dartを覚えなくて良い

Dartという新しい言語を覚える必要がなく、すでに慣れ親しんだKotlinで開発できるため、学習コストが低い。

段階的な導入が容易にできる

KMPでは共通モジュールで「expect/actual」を使い、プラットフォーム依存処理だけ残してロジックを段階的に移行できます。

最新APIへの対応が早くできる

新しいiOSのAPIが登場した際も、ネイティブAPIと相互運用できる仕組みがあるため最新APIの対応がやりやすいです。

今回のワークショップを通じて、 Kotlin Multiplatformは「ネイティブ開発者のためのマルチプラットフォーム」 だと確信しました。

各企業ブース

2日目からは企業がブース!がOpenしていて人が多く賑わっていました。

企業ブースをめぐるとスタンプラリー用のハンコもらえたり、なんとお菓子など食べ物やペットボトルホルダーなどグッズがゲットできました！

プロンプトを入力して、AIが自動コーディングする体験を提供していたブースはとても印象深かったです♩

特に興味深かったセッションをご紹介♩

共有と分離の境界線を見極める！Compose Multiplatform本番導入の設計指針

Kotlin Multiplatform (KMP) / Compose Multiplatform (CMP) を実際のプロジェクトに導入する際に、 「どこまでコードを共通化でき、どこから分離すべきか」 という、多くの開発者が抱えるであろう課題に光を当てる、非常に実践的な内容でした。

セッションで学んだ内容を元に、KMP/CMP導入の鍵となる設計指針を整理してお伝えします。

KMPにおける共通化の基本ルール

まず、KMPでコードを共通化できる範囲は、以下の2つの原則に基づいています。

Kotlin標準ライブラリで実現できること：
Kotlinの基本的な機能やAPIは、プラットフォームを問わず共通で利用できます。

KMP対応ライブラリで実現できること:
データベースライブラリのRoomのように、KMPに対応したライブラリを使えば、Android/iOS間で実装を共通化できます。

この2つに当てはまらない機能は、原則として共通化できない、つまりプラットフォーム固有の実装が必要になります。

どんな時にCMPを導入すべきか？

ネイティブらしいUIを作りたい場合はCMPは向いていません。iOS/Androidそれぞれの「標準的なUI表現」をそのまま活かしたい場合にはネイティブUI実装（SwiftUI / Jetpack Compose）が望ましいです。

今回のセッションで紹介された事例は業務アプリでした。コンシューマー向けアプリほどネイティブらしいリッチなUIへの期待値が高くないため、CMPの導入に踏み切ったそうです。

WebViewなどのOS特有UIは共通化が難しいですが、ブリッジしてネイティブコードを呼び出せば利用可能です。今後はマルチプラットフォーム対応コンポーネントの拡充で改善される可能性があります。

ネイティブ実装を呼び出すときの壁

KotlinからSwiftのAPIを直接呼び出すことはできません。基本的には Objective-Cを介した相互運用 が必要になります。そのため、Swift専用のAPIや、Swift Package Manager経由で提供されるライブラリをそのまま利用することは現状難しいです。

cinterop というツールを使うことで、Objective-Cにエクスポートされたクラスやメソッド（@objcを付与したもの）をKotlinから呼び出すことは可能です。ただし、この場合もCocoaPodsを利用したり、ブリジッするためのファイルを用意したりといった追加作業が必要になります。

セッションではcinteropだとCocoaPodsの利用やブリジッするためのファイルが増えるというデメリットがあるため使用せず、Dependency Injection (DI) ライブラリ であるKoinを使用したとの紹介がありました。DIフレームワークを使えば、実行時に適切なネイティブ実装を注入し、共通モジュールからSDKを間接的に利用できます。

テストコードがもう書かない：JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成

こちらのセッションではAIにテストコードを生成するときの具体的なプロンプトと、その実行結果を見ることができました。また、結果を評価軸ごとに分析して解説することも行っていただけてとてもわかりやすかったです！

弊社ではClaude Code、Github Copilot、GeminiなどAI導入に積極的に取り組んでいます。手動でテストコードを書くことはもはや時代遅れだと感じており、テスト生成の自動化は必須のステップだと認識しています。

AIによるテストコード生成の最大のメリットは、単に効率を高めるだけではありません。人間の手で書くよりも短期間で多くのテストケースを網羅的に生成することができます。また、非同期処理や複雑な依存関係を持つコードにも適応できるため、手作業では見逃しがちな部分もカバーすることが可能です。

今後は、この技術をさらに活用して、より高品質なコードを迅速に提供できるような環境を構築していく予定です！

Compose MultiplatformとSwift UIで作るハイブリットモバイルアプリ：コード共有とUI融合の実践

このセッションでは、Kotlin Multiplatform (KMP) と Compose Multiplatform (CMP) を活用した理想的な開発体験だけでなく、実際にプロジェクトを進める中で直面した「プラットフォーム間の差異」という現実的な問題が共有され、非常に参考になりました。

• OSごとで正規表現の振る舞いが異なる
• CMPを使ってUIの共通化を行ったがOSごとで微妙にfont/typographyが異なる
• スクロールの見え方が違う、スクロールできるUIの中にスクロールできるUIを組み込むとスクロールできなくなる

今回のセッションは、KMP/CMPが決して魔法の杖ではなく、その強力な恩恵を受けるためにはプラットフォーム固有の「クセ」を理解し、適切に対処する必要があることを教えてくれました。

リアルな課題を知ることで技術選定の際にリスクを予見することができます。KMP/CMPの導入を検討しているチームにとって、非常に価値のある知見が詰まったセッションでした！

懇親会

2日目の最後には懇親会がありました！
立食パーティーのようなイメージです。バイキング形式で料理を持ってきて好きなテーブルで食べて、周りの方とお話ししました。チーズリゾットとビーフシチューが美味しかったです♩

最後に

最後に、私たちはより良いサービスを提供するため共に切磋琢磨できるエンジニアを積極的に募集しています！

→応募はこちらから

まずは少し話を聞いてみたいという方向けに、カジュアル面談（オンライン）も随時受付しています。

→カジュアル面談はこちら

TRUSTDOCKの開発環境やこれから目指すところ、チームの雰囲気などざっくばらんにお話しできたらと思います！カジュアル面談応募から気軽にお声がけください♩