AIでAndroid→iOS アプリ移植をやってみた

Transcript

2. 梶原 睦 / かじはら むつみ 株式会社 シスマック DX ソリューション事業部 部長 Twitter（現 X）: @Mutsumix_dev 最近の執筆: 技術書典: データ菜園入門 Findyメディア: エンジニアが自宅野菜サーバーを運用して得られたIoTの「収穫」 普段は受託開発の提案やったり営業やったり研修講師やったり総務やったり 自己紹介 2
3. 「片側ネイティブ開発 + AI移植」がどの程度成立するかを検証してみた結果の共有 今日のゴール 3
4. 業務や個人開発で React Native + Expo を中心に開発 クロスプラットフォームの手段としては、Flutter / Kotlin Multiplatform も世に存 在 課題 UIやCRUDの実装は速いが、込み入った機能でネイティブ依存が強くなる 例: Bluetooth, バックグラウンド処理, 音声制御, 端末ファイルアクセス, 権限制 御 結果として「JavaScript/TypeScript + Android + iOS」の3層知識が必要になる or人が必要になる 背景（これまでの開発スタイル）など 4
5. React Native/Expoでも、最終的に以下が必要になりがち Android: Kotlin, Gradle, AndroidManifest, Activity/Service iOS: Swift, Xcode, Info.plist, Capability/Signing たとえば BLE Android: BluetoothGatt , ScanCallback , BLUETOOTH_SCAN/CONNECT iOS: CoreBluetooth(CBCentralManager/CBPeripheral) 抽象化レイヤを使っていても、デバッグでは結局ネイティブコードを見ることになる 問題意識 5
6. 片側（今回は Android）をネイティブで先に完成させる もう片側（iOS）は AIに移植支援させる これにより 学習・実装の対象言語を1つへ集中 もう片側は「移植 + 差分吸収」に限定 成否は感覚でなく、指標で判断することに 仮説 6
7. 発車ベルシミュレータ 電車好きの息子のために作っ たAndroidアプリ ON/OFFで音声再生 発車ベルの音声を選択して再生 ユーザー音声ファイルの追加 / 削 除 選択状態・追加音源の保存/復元 ストア公開はしていない（実機で の確認まで） 今回対象としたアプリ 7
8. ファイル選択 Android: ActivityResultContracts.OpenMultipleDocuments() iOS: UIDocumentPickerViewController + UTType.audio 音声再生 Android: MediaPlayer or ExoPlayer iOS: AVAudioPlayer / AVPlayer 状態保持 Android: DataStore iOS: UserDefaults + Codable / FileManager 込み入った実装の例 8
9. パーミッションの差 を最初に吸収する Android 13+: READ_MEDIA_AUDIO Android 12+: BLUETOOTH_SCAN , BLUETOOTH_CONNECT （BLE時） iOS: Info.plist の Usage Description（例: Bluetooth, Microphone等） 同じ要件でも「許可の取得タイミング」がOSで違う 「一度選べたファイルが再起動後に読めない」問題はよくある 移植時は API置換よりも 権限とライフサイクル整合 を重点的に確認 実装上の注意点 9
10. Kotlin と Swift はどちらも型安全・null安全寄り asyncモデルも対応可能 Kotlin: Coroutines / Flow Swift: async/await / Combine ただし差が出るのは言語より プラットフォームAPIの設計思想 致命的なのは「言語差」より「OSの責務の違い（権限・ライフサイクル・I/O） 」 言語レベルの違いは致命的か？ 10
11. 宣言的UI: Jetpack Compose / SwiftUI パターン: MVVM （ViewModel中心で状態管理） 状態は単一方向データフローで管理（State + Event） ドメインモデル（AudioItem等）を先に固定してからUIを移植 ベストプラクティス（移植前提） 11
12. ※ 実装支援ツールは Claude Code を利用 1. Androidを正しい仕様として固定 2. 機能単位でiOSへClaude Codeで移植 3. 各機能で 実装 -> ビルド -> 実機確認 -> 修正 4. 自動レポート（Markdown）で結果を保存 実験手順 12
13. ON/OFFで音声再生 選択ファイルが変更できる オリジナルの音声ファイル追加と再生ができる 削除後、選択中IDが無効ならフォールバックする 再起動後に選択状態・追加音源が維持される 再生不可ファイル時にエラー表示される 連打時に二重再生・クラッシュしない チェック内容 13
14. 結果 14
15. 実施内容 Androidアプリを仕様として iOSへ移 植 Phase 1: ON/OFF再生・音源選択・永 続化 Phase 2: ファイル追加・録音・音声管 理 機能対応 主要機能はすべて移植完了 ON/OFF再生、選択即時反映、追加/削 除/改名、録音、復元 測定指標と結果 15
16. 移植時間: 約33分 手修正時間: なし テスト合格率（自動）: 11 / 11（100%） テスト合格率（手動）: 6 / 6（100%） 起動時間: 体感的には即時起動 測定指標と結果 16
17. 発生した不具合 ビルドエラー4件（AppIcon不足、Info.plist設定、xcodegen再生成漏れなど） テスト失敗2件（UserDefaults残留、@MainActor境界） すべてClaudeCodeが自動で解消済みで、レポートを見るまでそんなことが起こって たのは知らなかった 測定指標と結果 17
18. 「Android先行 + AIでiOS移植」は、今回の規模では実用的に成立 その逆（iOS→Android）については検証していない 主要機能移植 + テスト完了まで、約33分（実測ベース） 注意すべき点は、言語差より iOSプロジェクト設定とOS責務の差分 実装面では、宣言的UI（Jetpack Compose / SwiftUI）を土台にMVVMで責務を 分離し、状態は単一方向データフローで管理する構成が有効だったと思う 実務で効かせるコツは、先に「正しい仕様」を固定し、AIにはOS間の差異を吸収さ せる まとめ（今回の結論） 18
19. AIってすごいね 最後に 19