1. はじめに
本記事は Timee Product Advent Calendar 2025 シリーズ1 19日目の記事です。
こんにちは。株式会社タイミーでiOSエンジニアをしている hayakawa です。 普段はiOSアプリの開発を担当していますが、弊社では職種の垣根を超えて異なる技術領域に挑戦する「越境」が盛んです。また、開発プロセス全体でAI・LLMを活用する流れも加速しています。
今回は、自身の技術領域を広げるためと、チームのケイパビリティ向上のために、Androidの実装を担当しました。本記事では、その際の実践的な知見やAI活用のポイントについて共有します。
2. 筆者のAndroidに関する前提知識
実装開始時点での私のAndroidに関する知識レベルは以下の通りです。
- 言語: Kotlin（Swiftと似ているという認識程度）
- UI: Jetpack Compose（SwiftUIに近い宣言的UIフレームワークという認識）。また、従来はXML（iOSのXIBやStoryboardのようなもの）を使って構築する手法があることも、知識としては持っている。
- 非同期処理: Coroutines（CombineやSwift Concurrencyの概念で理解）
- 開発環境: Android Studio（基本的な操作方法も不慣れな状態）
「概念は理解しているが、具体的なAPIやIDEの操作は手探り」という状態からのスタートでした。
3. 今回挑戦した実装内容
今回担当したのは、以下の2つの機能実装です。
① 条件に応じた注意書き表示ロジック サーバーレスポンスに含まれる「未来の時間情報」に基づき、UIを出し分ける機能です。
- 現在時刻から指定時間までの「残り時間」をカウントダウン表示する。
- 端末の「通知設定（ON/OFF）」を取得し、文言を切り替える。
② 条件に応じたUI制御とデザインシステムの拡張 サーバーレスポンスに含まれる特定の値に基づき、View内のコンポーネントを制御する実装です。
- デザインシステムに新たなカラーバリエーションを追加定義する。
- 既存のリスト表示（RecyclerView）の一部に、Jetpack Compose化したViewを組み込む。
- 組み込んだView内に追加のコンポーネントを表示する。
なお、同様の機能をiOS版でも私が担当しており、そちらは「実装1日、レビュー・マージまで2日」で完了しています。iOS版の実装時点では、Android版はキャッチアップも含めてその1.5倍ほどの工数で完了すると予想していました。
4. AI活用の勘所：メンタルモデルに合わせた翻訳
実装は Claude Code と協調して進めました。 ここで効果的だったのは、単にコードを書かせるのではなく、「自分の持っているiOSの知識とマッピングさせる」というプロンプトの出し方です。
プロンプトの工夫：「iOSエンジニア向けに説明して」
具体的には、以下のような指示を行いました。（※例なので実際に入力したプロンプトとは異なります）
Prompt: 「{SwiftのAPI名}を使って {やりたいこと} を実装したい。これを {KotlinのAPI名} を使ったコードと、Swiftの概念と比較した実装方針とコードを提示して
このように依頼することで、AIは「StateFlowはSwiftでいうCurrentValueSubjectに近い挙動です」といった補足を加えてくれます。これにより、単なるコピペではなく、挙動を正しく理解しながら実装を進めることができました。
5. ぶつかった技術的・文脈的な壁
AIの支援があっても、スムーズにいかない場面がいくつかありました。
① RecyclerViewとComposeの共存
最も苦戦したのは、既存のRecyclerViewの中にJetpack Composeで作ったViewを組み込む部分です。
SwiftUIであれば UIHostingController 等で比較的直感的にブリッジできますが、Androidの既存実装（ViewHolder）の中に、ComposeViewをライフサイクル的にどのように正しく配置するか
、という点は構文の違い以上に「作法」の違いが大きく、AIの出力したコードをそのまま適用するだけでは、ビルドエラーやレイアウト崩れが発生しました。
② モデル名の不一致（ドメイン知識の欠如）
また、プロジェクト固有の「命名規則」の壁もありました。 例えば、iOSで定義されているモデル名が、Androidでは少し違う名前になっているケースがありました。
例）
- iOS:
ServiceRequest - Android:
RequestedService
私がiOSの感覚で「ServiceRequestを拡張して」とAIに指示すると、AIはプロジェクト内に RequestedService が存在することを知らないため、新しく data class ServiceRequest を定義してしまいました。
これは「AIはプロジェクトの歴史や文脈までは（コンテキストに含めない限り）知らない」という典型的な落とし穴でした。
6. 人間（Androidエンジニア）との協調
AIが出力したコードは「動く」ものの、それが「保守性の高いコード」であるかは別問題です。 そこで、Androidエンジニアのチームメンバーに対して、「同期的な相談」の時間を設けてレビューを依頼しました。 この時、私が意識して聞いたのは「合っていますか？」ではなく、以下の質問です。
「期待通りに動くんですが、Androidの流儀としてもっと良い書き方はありますか？」
AIは汎用的な正解を出しますが、現場のベストプラクティス（例えば、よりモダンなライブラリの選定や、プロジェクト独自の拡張関数の活用など）は、人間の方が詳しいケースが多々あります。このプロセスを経ることで、コードの品質を担保しました。
7. まとめ
今回の挑戦で得られた知見は以下の通りです。
- AIは「言語の壁」を限りなく低くする Swiftの知識があれば、適切なプロンプトでKotlinのコードを生成・理解することは容易です。
- ドメイン知識とアーキテクチャの理解は人間が補う必要がある モデル名の違いや、既存コンポーネント（RecyclerView等）との整合性は、AI任せにせず人間がハンドリングする必要があります。
- 「もっと良い書き方」は人間に聞く AIで「0→80点」まで持っていき、最後の「80→100点（最適化）」を専門家との対話で行うスタイルが非常に効率的でした。
AIという強力なパートナーがいれば、iOSエンジニアにとってAndroid開発（あるいはその逆）は、もはや高いハードルではありません。今後も積極的に技術領域を越境していきたいと思います。
タイミーではiOSエンジニアやその他のポジションを含めて採用活動中です！
