【Kotlin fest2026登壇】ローカルデータベースをRoomで統⼀ ⼤規模求⼈アプリのKotlin Multiplatform実践

1. ローカルデータベースをRoomで統⼀ ⼤規模求⼈アプリのKotlin Multiplatform実践
2. 宮川 昌⾼ ディップ株式会社 Ø iOSエンジニアとしてモバイルア プリ開発を担当 Ø KMPやバックエンド開発で Kotlin(Ktor)も触っています Ø Kotlin Festは初参加‧初登壇 Zenn： zenn.dev/masa38 X： @matthew3880 趣味：タコス🌮を作ること
3. 今⽇話すこと 1. Roomの基本構成 2. Room KMPの採⽤とDB設計の共通化 3. OS固有の技術課題 4. まとめ
4. 今回の事例：バイトルのアプリリニューアル アルバイト‧パートの求⼈情報を掲載 する求⼈サービス l モバイルアプリのリニューアルで Kotlin Multiplatform(KMP)を採⽤ l ローカルDBにもRoom KMPを導⼊ l Android/iOSのDB設計を共通化し、配 置‧更新‧データ保護まで設計 l 現在、リリースに向けて準備中
5. Roomの基本構成
6. Roomの概要 l SQLiteをKotlinコードから型安全に扱うデータベース ライブラリ l KMP対応によりAndroidだけではなく、iOSからも利⽤ 可能
7. Room KMPにおけるDatabase 構築フロー ビルド時 (KSP / Room Compiler) @Database / @Dao / @Entity (KMPで定義) ⾃動⽣成 Database / DAO実装 DB定義の共通化 l Entity / DAO / DatabaseをKMPで共通定義 l KSP / Room Compilerが実装コードを⽣成 Builder⽣成と共通設定 実⾏時 l OSごとにDBの保存先を指定してBuilderを⽣成 (各OSごと)Builder生成 l KMP側でSQLiteDriverなどの共通設定を適⽤ l build() でDatabaseインスタンスを構築 (KMP)Builderへの共通設定 build() Room Databaseインスタンス ※Builderとは、Room Databaseの設定(保存先やDriverなど) を含むオブジェクト
8. DB定義の共通化 Database 使用するEntityを登録し、DAOを呼び出し側へ公開する Entity DAO SQLiteのテーブル構造を データの取得・追加・ Kotlinの型として定義する 更新・削除を定義する
9. Kotlinで定義するEntityとDAO テーブル構造と主キー の定義 (@Insert / @Query) DB操作とKotlin関数 を対応付ける
10. KMPコードでのRoom共通設定 l SQLiteDriver : 利⽤するSQLite実装を指定 l CoroutineContext : DB処理の実⾏コンテキストの指定 l Downgrade : ダウングレード時のDB再構築⽅針
11. SQLiteDriverについて Room KMPで、利⽤するSQLiteへの接続⽅法を指定する仕組み Driverの種類 BundledSQLiteDriver NativeSQLiteDriver SQLite本体 同梱される 同梱されない 呼び出し先 sqlite-bundled内のSQLite ビルド時にリンクされたSQLiteラ イブラリ OS間の⼀貫性 ⾼い ホストOS環境‧リンク構成に依存 選択理由 OS間でSQLiteのバージョン‧機 能を揃えたい OS提供 またはリンク指定した SQLite実装を利⽤したい
12. Room KMPの採⽤とDB設計の共通化
13. Room KMPの進化と採⽤タイミング Room Android ライブラリとして 利用実績を蓄積 2025年4⽉ 2026年7⽉ Room 2.7.0 Room 3.0 KMP対応がStableへ 2025年 リニューアル プロジェクト開始 正式リリース Room KMPを 採用 現在 Room 2.8.5 を利用
14. Roomの選定理由 ü Android開発で培ったRoomの知⾒を活かせる ü 旧アプリでOSごとに分かれていたスキーマ定義とデー タアクセスの設計を共通化したかった
15. リニューアルアプリでのDB設計 旧アプリのDBを棚卸しし、新アプリに必要なデータを共通Entityと して再設計しました。 旧アプリ iOS: Realm DB Android: Room DB 主キー‧型/状態の表現‧モ デルの責務がOS間で異なる 再設計 新アプリ ü 旧DBの保存データから新アプ リでも必要なものを選別 KMP 共通Entity ü 重複やOS間の違いを整理し、 共通の責務と構造を決定 共通Entityとして KMPへ集約
16. Roomを共有するアーキテクチャ iOSアプリ Androidアプリ KMP UseCase／Repository DataSource ネイティブ実装との境界 データの取得・更新ルール Room Database (テーブル構成とデータ操作)
17. 2つのRoom DBと異なるライフサイクル データの内容 検索用 マスター データDB 求人検索に利用 初期データを 同梱 端末へ配置 差分更新 するデータ データの内容 ユーザー データDB 新規作成∕ 旧DBからの引 き継ぎ ユーザーの 利⽤とともに 蓄積 ユーザーのアプリ データ保護 利⽤に伴って蓄積 されるデータ
18. OS固有の技術課題
19. ユーザーデータDBで直⾯した２つの技術課題 l OSごとに異なる旧DBからのデータ引き継ぎ l Room DBに保存するユーザーデータの保護
20. 旧アプリからのユーザーデータ引き継ぎ l ユーザーデータDBには⾮会員向けやオフライン利⽤時のサーバー に同期されていないデータを含むことがある l リニューアルアプリへのアップデート時に、必要なデータを旧DB から新しいRoom DBへ引き継ぐ必要があった
21. OSごとの旧DBを共通Entityに引き継ぐ OSごとに異なる旧DBのモデル定義を共通Entityにマッピング OS別の実装 iOS LegacyMigrationModule 旧Realm DB 旧DBの 読み取り Android LegacyMigrationModule 旧Room DB 旧DBの 読み取り 旧アプリの実装を移植 KMP実装 共通Entityへ 変換・保存 新Room DB
22. ユーザーデータDBの保護 l ユーザーデータDBは、⼀部に機微な情報を含む l バックアップの流出や、不正アクセスでDBファイルが 取得され、内容を参照されるリスクに対処したい
23. Roomと暗号化 l Room 2.8∕3.0ともに、現時点ではDBを暗号化する標 準APIを提供していない l 外部ライブラリやOSの暗号機能と組み合わせて実現す る
24. Room DBに追加する暗号化のアプローチ DBレイヤー DB全体を暗号化 OS標準の保護 アプリケーションレイヤー 機微なフィールドを暗号化 OS標準の保護 暗号化 SQLite DB ID コード 101 A01 102 B07 103 C12 氏名
25. 両OSでDB全体暗号化を検証 l 当初は、Android∕iOSともにSQLCipher(*)を採⽤し、 DBファイル全体を暗号化する⽅式を検討した l AndroidとiOSの両⽅で技術検証を実施 (*) SQLiteをベースに、DBファイルの暗号化機能を追加したフォーク https://www.zetetic.net/sqlcipher/
26. Android: SQLCipher⽤FactoryでのDB暗号化 AndroidのユーザーデータDB暗号化 l KMP対応のSQLiteDriver経路を使わない l SQLCipherが提供するFactoryをBuilderへ設定 l Android固有の接続経路でSQLCipherを利⽤ 参考：SQLCipher for Android
27. iOS: SQLCipherによるDB暗号化の検証 Room KMP導⼊時 SQLCipher検証時 Room Room PRAGMA keyを設定 BundledSQLiteDriver NativeSQLiteDriver 呼び出すsqlite3_*APIを SQLCipherへリンク 通常のSQLite SQLCipher 平文DB 暗号化DB
28. iOS: DB全体暗号化の運⽤課題 l Xcode‧SQLCipherなどのバージョン更新に伴う、iOS 向けバイナリの継続的なビルド‧検証 l SQLiteライブラリのリンク構成の課題（次スライドで補⾜）
29. iOS: 通常のSQLiteもリンク対象に含まれた場合 Room NativeSQLiteDriver 通常のSQLite 同じsqlite3_*APIを提供 SQLCipher PRAGMA keyを無視 通常のSQLiteへ解決されると PRAGMA keyを適用 エラーにならず平⽂DBとして 平文DB 動作してしまう 暗号化DB
30. iOSで採⽤した暗号化のアプローチ DBレイヤー アプリケーションレイヤー DB全体を暗号化 機微なフィールドを暗号化 SQLCipher CryptoKit／AES-GCM OS標準の保護 暗号化 ドライバ構成を変更せず、機微なフィール SQLite DB ドをアプリケーション層で明⽰的に暗号化 するほうが、保護範囲と運⽤コストのバラ ンスがよいと判断 OS標準の保護 ID コード 101 A01 102 B07 103 C12 氏名
31. iOS: フィールド暗号化の処理フロー 保存時 → Room DB 暗号化 平文データ DAO DataSource 復号 読み出し時 ← 機微なフィールド： 暗号文 自前の暗号化I/F FieldCipher 機微性と検索への影響を考慮し、 iOS / Swift CryptoKitFieldCipher ・CryptoKit / AES-GCM ・鍵はKeychainに保管 暗号化するフィールドを選定 実装
32. データ保護‧暗号化対応のまとめ データ設計は共通化し、暗号化⽅式はOSごとに選択 OS Android iOS 実装レイヤー DBレイヤー アプリケーションレイヤー 保護範囲 DBファイル全体 機微なフィールド 利⽤技術 SQLCipher CryptoKit（AES-GCM）
33. まとめ
34. Room KMPを採⽤する際の判断材料 得られた効果 l DB定義とデータアクセスをKMPに集約でき、OS間の設計‧実装 のズレを防ぎやすくなった 導⼊時に設計‧検証が必要だったこと l OSごとのDB定義を、共通Entityへどう統合していくか l 旧DBのデータを、共通Entityへどう変換‧移⾏するか l データの性質に応じて、DB内のデータをどう保護するか
35. ご清聴ありがとうございました!!