Shopifyが、モバイルアプリの土台をReact NativeからSwiftとKotlinへ戻すと明らかにした。しかも理由は「React Nativeがダメになったから」ではない。むしろ、コードを実際に書くコストそのものが、AIエージェントの進化で大きく下がったからだという。モバイル開発の分業や効率化を支えてきた前提が変わり、同社はもう一度、最初から技術選定を見直した。モバイル開発とAIの関係が、実務レベルでどこまで変わったのかを示す、かなり象徴的な話だ。
Shopifyは2020年に、モバイル開発をReact Nativeに寄せる判断をした。当時の狙いは明快で、同じ機能をiOSとAndroidで二重に作らずに済むこと、モバイル専任でない開発者も貢献しやすくなること、そして各プラットフォームで仕様の差を追いかける手間を減らして、価値のある機能を早く出すことだった。実際、その選択はかなり成功したと同社は振り返っている。
ただしReact Nativeを使う以上、性能の調整や基盤部分の改善、依存ライブラリやフレームワークの更新対応には手間がかかる。Shopifyにとっては受け入れ可能なコストだったが、2025年後半になると状況が変わる。Shopifyは2021年からLLMをソフトウェア開発に使っており、当初は機能実装、バグ調査、コードレビューが中心だった。モデルが良くなるにつれて任せられる仕事も増え、ついには「SwiftとKotlinで同じ機能を作るのは、以前ほど二重労働ではないのではないか」というところまで来た。
そこで同社はモバイル技術を改めて検討し、主要アプリの一部をSwiftとKotlinで試作した。その結果、LLMがあればiOS版を参考にAndroid版を作る、その逆もできる、開発者が自分の専門外のスタックにも入りやすい、プラットフォーム間の整合性を保つコストが shared specifications、tests、review checkpoints によってかなり下がる、と判断した。React Nativeアプリは十分速く作れるし、今後もそうだろうと認めつつ、それでもネイティブのほうがプラットフォーム機能や純正ツールに近く、余計な層が少ない。そこでShopifyは「2020年の前提はAIで崩れた」と見て、ネイティブ回帰を決めたわけだ。
移行の方法もかなり具体的だ。ShopifyはShop、Shopify、Point of Sale、Inboxのような大規模アプリを抱えているが、今回は段階移行ではなく再構築を選んだ。LLMがあれば、React Native版を参照しながらSwiftとKotlinでより速く作り直せるうえ、制約のない新しい設計にできるからだという。先行したShopアプリは、AIの支援を受けて、PoCからアプリストア公開まで12週間で完了した。現在はShopify本体のアプリも進行中で、300以上の画面に加えてウィジェット、Apple Watchアプリ、complications、Siri Shortcutsまで含む大きな案件だ。
一方で、単にLLMにReact Nativeコードを投げれば済むわけではない、ともShopifyは強調する。そこで同社はHelixという仕組みを作った。画面を指定すると、React Nativeの実装を読み取り、短い作業単位のcheckpointに分ける。各checkpointはテスト、画面比較、二人の敵対的なレビュー、人間の承認を通らないと次へ進めない。雑な出力をそのまま積み上げず、少しずつ良い結果に育てる設計だ。
さらに、モバイルでボトルネックになりやすいのが simulator の操作だと指摘する。AIはコードをすぐ変えられても、テストや検証に数分かかると反復が遅すぎる。そこでShopifyは、ビジネスロジックをUIから切り離し、デスクトップ上で headless に動かせるようにし、CLI経由でエージェントが状態確認や画面遷移、操作をミリ秒単位で回せるようにした。必要ならCLIが simulator に接続してUIを直接動かす。こうして、エージェントが何時間も自律的に作業できる環境を整えた、というのが記事の骨子だ。
この話で面白いのは、ShopifyがReact Nativeを「失敗」として切り捨てていないところだ。むしろ、2020年の判断は当時として合理的で、実際にうまくいったと明言している。そのうえで、AIによってコスト構造が変わったから見直す、という順番になっている。ここは重要で、技術選定が永遠の正解になるわけではない、という当たり前の事実をかなり率直に示している。
ただ、ここで本当に変わったのは「コードを書く速さ」だけではないと思う。記事を読む限り、Shopifyが重視しているのは実装そのものより、プラットフォーム差を埋める作業の安さだ。以前はReact Nativeがその差を吸収してくれた。今は逆に、SwiftとKotlinで別々に作っても、AIが翻訳、実装、テスト、レビューをかなり肩代わりできる。つまり、二重開発の“二重”が、もはや人間の労力として重くない。これはフレームワークの優劣というより、開発労務の配分が変わった話だと思う。
Helixの説明は、かなりShopifyらしい現実感がある。大きな画面を一気に再実装するのではなく、checkpointに分け、テストと視覚確認と複数のレビューを通す。これは、LLMが生みやすい「それっぽいけど保守しにくいコード」を止めるための装置だ。ここに私はかなり納得した。AIで作る時代は、出力速度よりも、間違った方向に進まない仕組みのほうが価値を持つからだ。
同時に、これはAIで開発が楽になるというより、開発工程の統制がより厳しくなることも意味している。人間が手で雑に書いたコードなら多少の無理も通るが、エージェントに大量の変更を任せるなら、レビュー基準や仕様の粒度が粗いとすぐ崩れる。Shopifyが「slop」を避けると言っているのは象徴的で、AI時代の生産性は、自由度を上げることではなく、自由に暴れない枠を作れるかで決まるのだと思う。
Shopifyの判断は筋が通っているが、そのまま他社に一般化するのは危ない。Shopifyは巨大なモバイル群を持ち、しかも社内にAI活用の経験がある。Shop、Shopify本体、Point of Sale、Inboxのような大規模アプリを抱え、しかもアプリごとに長期運用が必要だ。こうした条件なら、ネイティブで機能に近づき、純正ツールを使い、エージェントで開発速度を補うほうが合理的になりやすい。
一方、普通のチームにとっては、React Nativeのような共有基盤が依然として強い場面は多いはずだ。人手も少なく、iOSとAndroidを別々に深く保守する余力がないなら、まだ「一度作って両方に届ける」価値は大きい。だから今回の話は、React Nativeの終わりというより、AIを前提にした場合の大企業向けモバイル戦略の変化として読むのが正しいと思う。
記事全体を通して見えるのは、モバイル開発の主戦場が「どのUIフレームワークを使うか」から「どうやって速く、確実に反復するか」に移ったことだ。React Nativeは、以前はその反復をかなり助けた。今は、AIエージェントとCLI、headlessなビジネスロジック、強いテストとレビューのほうが、反復速度を支える中心になりつつある。すると、フレームワークの抽象化がもたらす利点より、プラットフォームそのものに近いほうが得、という判断が出てきても不思議ではない。
私はこの動きを、AIが「開発者を置き換える」というより、開発の面倒な往復作業を別の場所へ押し出している現象として見ている。コードを書くのは速くなる。でも速くなった分だけ、設計、検証、統制の重みが増す。Shopifyの転換は、その新しいバランスをかなり早く掴んだ会社の判断として読むと、いちばん腑に落ちる。
参考: Native is now the future of mobile at Shopify (2026) - Shopify
