PLAIDEngineer Blog
エンジニア積極採用中

DroidKaigi 2025参加レポート｜SDK開発に役立つ5つのセッション

Kento Kaseda

Posted on

KARTE for Appチームのエンジニアの悴田です。

プレイドは、この度DroidKaigi 2025にゴールドスポンサーとして協賛し、ブースの出展も行いました。
この記事では、弊社のブースの内容を紹介するとともに、Mobile SDKエンジニアとしての視点から特に役立つと感じたセッションを5つ紹介します。

ブースの紹介

プレイドでは、モバイルアプリ向けのプロダクトとして「KARTE for App」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。

今回のブース企画・運営は、これら2チームのメンバーを中心に行いました。

ブースのコンテンツ

ブースでは、以下の2つのコンテンツを用意しました。

アプリグロースの課題に関するアンケート

アプリグロースにまつわる課題について、該当するものにシールを貼っていただく形式でアンケートを実施しました。マーケティング寄りの質問でしたが、ほとんどの参加者がアプリグロースに関して何らかの課題を実感していることが分かりました。
アンケートや来場者との会話を通じて得られた知見は、今後の新機能開発に活かしていきたいと考えています。

マーケティングツールの利用に関するWebアンケート

マーケティングツールの利用状況に関するWebアンケートにご回答いただいた方に、抽選で技術書をプレゼントしました。外れてしまった方々にも、ノベルティグッズをお渡ししました。
また、このアンケート自体がKARTEで作成されたものであり、来場者の方々にKARTEの機能を実際に体験していただくきっかけにもなりました。

ブース運営の雑感

結果として、多くの方々にブースへ立ち寄っていただけました。
既にKARTEを利用されている方・過去に利用経験のある方も少なくなかった一方で、「プレイド/KARTEを知らなかった」という方も依然として多く存在しました。
モバイルアプリ領域におけるプレイドの認知度・プレゼンス向上に、引き続き取り組んでいきたいと感じました。

SDK開発に役立つセッション

Mobile SDKエンジニアの視点から、特に役立つと感じたセッションを5つ紹介します。

1. Androidライブラリアンの手引き：堅牢なライブラリとSDKの構築

このセッションでは、Androidアプリ向けに堅牢なライブラリやSDKを提供するために必要なテクニックが体系的に紹介されています。

具体的に触れられていた内容は以下の通りです。

  • APIの可視性コントロール：@JvmSynthetic アノテーションや Explicit API Mode の活用。
  • APIライフサイクル管理と互換性維持：@Deprecated アノテーションやマニュアルへの明示。
  • バイナリ互換性：概念の解説に加え、検証ツール (Binary Compatibility Validator、 Metalava) の使い方と比較。
  • リソース管理：SDKのリソースを非公開にする方法。<public /> タグによる検出、resourcePrefix を使った名前衝突の回避。
  • 推移的依存関係：推移的依存関係による課題。implementation/api の適切な使い分け、Non-transitive R class の活用。

全体を通して、SDK開発に携わる上で押さえておきたい注意点が整理されており、実務に直結する内容でした。
またセッション後には、ブースで発表者の方に直接「SDKのKotlinバージョンをどのように決定・更新しているか」といった技術的な質問をする機会があり、丁寧に答えていただけたのも印象に残りました。

2. そのAPI、誰のため？ Androidライブラリ設計における利用者目線の実践テクニック

発表者が社内ライブラリの開発を通じて得られた学びを紹介するセッションです。
1.のセッションと同様にライブラリ設計を扱っていますが、1.は「堅牢な設計にすること」をテーマとしていたのに対し、本セッションは「ユーザーフレンドリーな設計にすること」にフォーカスしています。

具体的には、以下を意識することが推奨されています。

  • カプセル化を徹底し、利用者が内部実装を意識せずに使えるようにする。
  • 利用者側の技術スタックに、できるだけ非依存にする。例えば、特定のUIフレームワークやDIライブラリの利用を前提としないようにする。
  • 一般にライブラリの機能を増やすと、自由度 (カスタマイズ性) は低下する傾向にある。機能性と自由度を両立する手段として、コアの低レベルなモジュールと、アプリケーション寄りの高レベルなモジュールを、別々のモジュールとして提供する方法がある (e.g. Jetpack Composeの設計)。
  • コードコメントやドキュメントを充実させる。ユーザーフレンドリーなライブラリになるだけでなく、設計の良し悪しに気づくきっかけにもなる。
  • ライブラリの使い勝手を知るには、自分でそのライブラリの利用者になってみるのが良い。サンプルアプリを作ることも有効である。

なお、KARTE for AppのMobile SDKにおいても、ここで挙げられているような「SDKの依存ライブラリを減らす」や「マルチモジュール方式でcoreライブラリと機能ごとのモジュールに分けて提供する」といった工夫がなされています。

3. 厄介な依存関係：サードパーティライブラリのバグを乗り切り修正する方法

このセッションでは、Androidアプリ開発において避けて通れない「サードパーティライブラリ起因のバグ」への対処法が体系的に紹介されています。

具体的には、以下のようなテクニックが解説されています。

  • ローカル環境での修正・動作確認
    • Gradle Assemble、Composite Build、Git Submodule、Local Maven Repository、Remote Maven Repositoryなどの各種方法を比較する。
  • 修正版ライブラリの利用方法
    • オープンソースライブラリの場合：upstreamにバグ修正を反映する方法。
    • クローズドソースライブラリの場合：リフレクションやバイナリ操作ツール (Recaf) を用いてパッチを当てる方法。

アプリ開発者にとって有用なのはもちろんですが、SDK開発者の立場から見ても「依存ライブラリに起因する問題をどう扱うか」は避けて通れないテーマです。ライブラリの仕組みを理解し、場合によっては自ら修正・回避できる能力の重要性を改めて感じました。

4. 例外のその先へ：セーフティクリティカル原則に基づき堅牢なAndroidアプリを構築する

Kotlinにおけるエラーハンドリングのベストプラクティスを紹介したセッションです。

メインとなる主張は「ドメインロジックのエラーを例外 (Exception) で表現しない」という点です。例外を網羅的にハンドリングするには、内部実装の知識を前提となります。また、スタックトレース取得のオーバーヘッドも大きいです。

一方で、Kotlin組み込みの Result 型を使う方針には、以下のような課題があるとされています。

  • 不要な例外クラス生成を伴う。
  • 網羅的ハンドリングができない。
  • Result.runCatching が Kotlin CoroutinesのCancellationException を補足してしまう。

また、Kotlin公式側でも、Result型はDomain Specificなエラーのハンドリングには使うべきでないとされています。
https://github.com/Kotlin/KEEP/blob/main/proposals/stdlib/KEEP-0127-result.md#error-handling-style-and-exceptions

適切なエラーの表現手段としては、軽量に済ませたい場合は null、丁寧に扱う場合は sealed interface などを用いたカスタムクラスの定義が推奨されています。
さらに、将来的な選択肢として、Kotlin 2.4で導入予定の「Rich Errors」というUnion型のような言語機能も紹介されています。
参考：Rich Errors in Kotlin | Michail Zarečenskij

タイトルには「Androidアプリ」とありますが、ライブラリやサーバーサイドにおけるKotlinの利用も含めた、幅広い領域で役立つ内容でした。

5. プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える

このセッションでは、Property Based Testing (PBT) の概要と、Jetpack ComposeベースのAndroidアプリにおけるUIテストへの応用が紹介されています。

一般に使われるExample Based Testing (EBT) では、事前に用意したテストケースに沿ってテストを行いますが、PBTは入力や状態をランダムに生成してより網羅的にテストできる点が特徴です。もっとも、EBTと対立するわけではなく、相互に補完し合うアプローチとして位置づけられます。

発展的な内容として、ステートフルなシステムに対するPBTの適用方法や、LLMを活用してプロパティ定義を自動抽出する試みも紹介されています。

PBTは学習・導入コストが高く、私自身もまだ実際のプロダクトで活用した経験はありません。
一方で、テスト自動化はSDK開発においても重要なトピックの一つであり、網羅的な検証が要求される場面で使えるよう、PBTの実装方法と特性を把握しておかねばと思いました。

最後に

今回、私は初めてDroidKaigiに参加しましたが、ブースでの会話やセッションを通じて多くの学びを得られ、とても有意義で、何より楽しい時間を過ごすことができました。来場者の方々からいただいたユーザー目線でのフィードバックや、各セッションで得られた技術的な知見は、今後のプロダクト開発に活かしていきたいと考えています。

プレイドのKARTE for Appチームおよび新規プロダクト開発チームでは、現在モバイルエンジニアを募集しています。あらゆるモバイルアプリにおける顧客体験やデータ分析、開発生産性向上の基盤となるSDK開発にご興味のある方は、ぜひカジュアルにお話ししましょう！

最後に、カンファレンスの運営に携わってくださった皆様、そしてブースに立ち寄ってくださった皆様に、心より感謝申し上げます。