AI駆動でネイティブiOS/Android二刀流開発を実現した半年間
カウシェ Advent Calendar 2025/12/19
はじめまして、カウシェでiOS/AndroidエンジニアをしているOmura(@uiy_0319)です！
カウシェでは約半年前から、クロスプラットフォームを使わずにネイティブ二刀流開発にコミットするという、なかなかに尖った取り組みをしています。
FlutterでもReact Nativeでもなく、SwiftとKotlinを両方書きながら、4人のモバイルエンジニア全員が二刀流で新機能をガンガン開発している感じです。
一見非効率に思えると思いますし、実際僕たちもやる前は二刀流で開発サイクルが機能するのか少し半信半疑でした。
ですが、実際に半年ほど取り組んだ上で、今では、
AIと環境構築がしっかり整っていれば、ネイティブ二刀流は全然非効率ではない
と感じています。
この記事では、僕たちがどんな環境づくりをして、どうやってAI中心の二刀流開発を成立させてきたのか、この半年間の取り組みをご紹介できればと思います！
なぜネイティブ二刀流が成立したのか
まず最初に結論から言うと、
AIが正確に動ける土台をチームで作り切ったから
というのが二刀流を推進できた要因として大きかったと思っています。
AIが世に出てから様々な組織や個人で活用の取り組みが進んでいますが、「AIを導入しただけでは期待した効果が出ない」というケースは意外と少なくありません。
実際、AIは適当に投げれば勝手に賢く動くわけではなく、前提となる情報や構造が曖昧だと誤解もしますし、出力の質も不安定になります。
そして、その前提や文脈を整えてあげることこそが、人間側の重要な役割であり、そこに本気で取り組んだことが二刀流実現の大きな転換点でした。
片OSの実装をもう片OSに“転写”しやすくするための構造づくり
半年ほど前にiOS/Androidをひとつのモノレポに統合しました。
app/mobile/配下にios/とandroid/が並んで存在する構成です。
app/
└── mobile/
├── ios/
│ ├── FeatureA/
│ ├── FeatureB/
│ └── ...
└── android/
├── FeatureA/
├── FeatureB/
└── ...
これが本当に効いたなと実感しています。
- 片方のOSの実装をAIに丸ごと参照させられる
- 「iOSのこの機能を参考にAndroid側を作って」である程度自然に転写できる
- Diffの読み合わせがOS間でしやすい
- チームの共通言語が生まれる
AIにとっても、人間にとっても優しい構造になった実感です。
アーキテクチャを揃えて“AIが読みやすいコード”へ
Androidは元々Domain/Data/Presentationの三層＋Feature群で綺麗に分かれていましたが、iOSはモノリシック寄りの構成でした。
二刀流開発を進める上で、ここがボトルネックになると判断し、iOSをAndroidに寄せる形でパッケージ分割を開始。
1ヶ月ほどかけてiOSを15パッケージほどに分割しました（現在も進行中）。
この結果、
片方のOS構造を理解すれば、もう片方のOSも自然と読める
という状態になり、AIがOS間の文脈を読み取りやすくなっただけでなく、人間にとっても理解しやすい構成になりました。
結果的に、
「iOSのDomain層の実装を見て、Android側のData層の対応する部分を作って」
のような割と雑な指示でも大きくズレることなく通るようになった実感です。
開発の“流れ”をAIに最適化する
AI駆動開発を回すうえで、人の開発フローをかなり変えたのも両OS開発に効いたと思っています。
PRは1機能あたり5〜7個に細分化
カウシェのモバイルチームでは、当初、Feature単位で大きめのPRをまとめて開発するスタイルをとっていました。
しかし、このやり方にはいくつか課題感があり、例えば、
- PRが大きくなりがちで、レビューの認知負荷が高い
- 実装の粒度がバラバラで、メンバー間で「どこからレビューすべきか」が揃わない
- AndroidとiOSの並列開発時にコンテキストが追いにくい
- AIにPRを読ませても意図を正しく汲み取りにくい
- 実装途中の差分が見えづらく、仕様ズレや手戻りが発生しやすい
などなど...
結果として、問題が積み重なり、徐々に「開発速度が出てきた今こそ、フロー自体を見直すフェーズだよね」という流れになりました。
そこで、
開発フローそのものをAIが扱いやすい単位に再構成する
という意図もあって、Trunk-based Developmentへの移行に踏み切る判断に至ります。
結果的に、PRを細かく分ける習慣が徹底されたことで、人のレビューという点で見るべきスコープも狭まったので、非常にスピード感を持ってマージする体制が整いました。
ex:新機能実装
1. Domain層の追加 → PR #1
2. Repository実装 → PR #2
3. DataSource/API → PR #3
4. ViewModel → PR #4
5. UI実装 → PR #5
6. 細かい修正 / 統合 → PR #6
また一方で、これはAIにとっても良い副作用が多く、
- コンテキストが明確でAIが誤解しにくい
- レビュー対象が小さくなりAIレビューのこぼしも少ない
- 依存関係を可視化することでAI計画が立てやすい
といった恩恵があったと実感しています。
特にCursorのplanモードと組み合わせたときの相性は抜群で、
AIに“プランナー”として働いてもらう
という1つのスタイルが定着しました。
定型作業の自動化で“AIが働きやすい環境”を作る
開発面以外にも力を入れていたのが、自動化の領域です。
カウシェではClaudeのcustom commandをフル活用しており、例えば、
- commit メッセージ生成
- push & PR 作成
- AIによるPRレビュー（Bugbot/Claude Code）
など、定型的な作業は極力自動化するようにしています。
また、iOS/Androidにおける審査出し周りについては、CI/CDパイプラインを充実させることで、
- リグレッションアプリ配布→ワンクリック
- 審査出し・リリースフロー→ワンクリック
といった運用ができるようになりました。
[ commit ] (custom command)
↓
[ push ] (custom command)
↓
[ PR作成 ] (custom command)
↓
[ レビュー ] （AI+人）
↓
[ merge ] （人）
↓
[ QA配布 ] （ワンクリック）
↓
[ 審査出し ] （ワンクリック）
こういった“地味だけど時間を食う作業”をAI駆動とは別文脈でどんどん進めた結果、
人間は実装と判断だけに集中できる
という状態にかなり近づいてきた感触があり、生産性向上にかなり寄与した部分だと思っています。
リリースフローを自動化した具体的な話については、弊社モバイルエンジニアが具体的にまとめているので、こちらをご覧になってみてください！
メンバーのAI環境は統一しない方がうまくいった
そんなAI開発をバリバリ推進しているチームですが、とはいえ、メンバー全員のAI環境は割とバラバラだったりもします。
- Cursor派
- Claude Code派
- Codex派
- etc...
ここに関しては、あえて統一していません。
むしろ「好きな環境でいい」という方針にしています。
重要なのは
“AIを活用したいとき、すぐ自然に使える状態”
になっていることで、各々の生産性が向上するなら基本どのAIを使ってもOKというスタンスです。
AI駆動開発そのものもまだ発展途上ですし、AI業界の進化も激しいため、今の段階でツール等を固定化するのは逆にリスクにもなり得ます。
そのため、メンバー同士で日々知見を共有しながら、それぞれが最適だと思うツールを選ぶくらいがベストだと思っています。
足元のボトルネックはQA
開発生産性が上がった一方で、新たに生まれた課題ももちろんあったりします。
その代表例の1つが、QAが追いつかないという問題です。
開発速度（AI二刀流） → → → → → → → 🚀
↓
QAライン（現状） → → → → → → → 📦📦📦💥
今は週1リリース → 週2リリースへ移行中ですが、AIで二刀流の開発速度が上がった結果、QAが完全に逼迫してしまっている状況にあります。
プロダクトとしてはPoC的な改善を高速に回したいフェーズなので、多少のバグは許容しつつ、
「当たり前品質を担保するQAライン」
を整えることが当面のテーマなので、一旦足元はリグレッション項目や頻度を減らすなどの対応をしている感じです。
AIがコードを書く速度は異常に速いので、
“人間が確認する速度”をどれだけ仕組み化できるか
が今後はより重要だと感じています。
今でこそQA Automationツールの導入は進めていますが、それでもまだまだ足りません。
今後の方向性としては、QAエンジニアの採用を厚くするか、それ以外のアプローチで現状の課題を打開できないかを、まさに今検討しています。
半年間で見えてきた“AI駆動二刀流の本質”
ここまで振り返って強く思うのは、ネイティブ二刀流の本質は、
「AIが書くコード量」ではなく「AIが迷わない環境づくり」
にあるということです。
- モノレポ
- アーキテクチャ統一
- READMEで責務を明確化
- PR分割
- 自動化
- AIと会話しやすい開発ルール
- 並列開発に最適化されたフロー
これらの積み上げが、AIの性能を最大まで引き出し、結果として、
“クロスプラットフォームを使わない二刀流”
が成立すると思っています。
FlutterもReact Nativeも全然否定はしていません。
会社の状況次第では、クロスプラットフォームを採用することも全然あり得たと思います。
ただ、AIがここまで強くなると、ネイティブ二刀流という選択肢も十分に現実的になるという話を、この記事で伝えたかった限りです。
カウシェでは今も毎週のように新しい取り組みを試し、改善し続けています。
この記事が、同じように、
「AIを前提にモバイル開発を再設計したい」
と考えるチームの参考になれば嬉しいです！
また、具体的な数値の変化などは弊社EMが別記事で詳細にまとめています。
よろしければこちらもご覧ください！
カウシェは採用強化中です！
現在、エンジニア・デザイナー・QAエンジニア・PdMなど、プロダクト開発に関わる方中心に様々なポジションで募集しております。
▼募集ポジションはこちら
▼採用ページはこちら
▼カジュアル面談希望はこちら
技術の力で大きなインパクトを生みたい方、プロダクト系の職種はほぼ全方位で採用中なので、ぜひカジュアルにお話ししましょう！
Discussion