【ITニュース解説】Shopify Is Moving Its Mobile Apps Back to Native. Coding Agents Made It Cheaper to Build Twice Than to Share One Codebase.

Shopifyがモバイルアプリ開発の戦略を大きく転換するというニュースが発表された。以前はReact Nativeという技術で開発を進めていたが、今後はiOSアプリはSwift、AndroidアプリはKotlinといった、それぞれのOSに特化した「ネイティブ」な技術へと移行していくというものだ。

Shopifyは2020年に、モバイルアプリ開発の未来はReact Nativeにあると表明し、2025年時点でもその技術への投資を続けると述べていた。しかし、2026年9月には、その方針を撤回し、すべてのモバイルアプリをネイティブに移行すると発表した。この急な方針転換は一見するとReact Nativeの失敗に見えるかもしれないが、そうではないとShopify自身が明確に述べている。ShopifyのReact Nativeアプリは、高速で安定しており、期待通りの成果を出していたのだ。

では、何が変わったのか。それは、技術の良し悪しではなく、「代替手段のコスト」が変わったためだ。

2020年当時、ShopifyがReact Nativeを選んだ主な理由は三つあった。一つは、iOSとAndroidで同じ機能をそれぞれSwiftとKotlinで二度開発する手間をなくすこと。二つ目は、開発者が特定のOSプラットフォームに限定されず、幅広い技術スタックに貢献できるようにすること。三つ目は、両プラットフォーム間で機能の差がないようにする（機能パリティを維持する）作業にかかる時間を減らし、新機能開発に集中できるようにすることだ。これらの目標はReact Nativeによって見事に達成され、Shopifyのアプリは高速で安定稼働していた。

しかし、2025年後半にかけて、LLM（大規模言語モデル）の進化が開発のあり方を根本から変え始めた。LLMは単にコードを書くのを速くするだけでなく、「ソフトウェアを二度作ることが本当に二度分の作業になるのか」という、これまでの開発の経済性の前提そのものを問い直す力を持っていたのだ。

LLMが開発コストに与えた影響は大きい。まず、プラットフォーム間のコード変換が非常に安価になった。たとえば、iOS版のコードをLLMに参照させれば、それを元にAndroid版のコードを効率的に生成できるようになった。次に、開発者が自分の専門外の技術スタック（例えばiOSエンジニアがKotlin）に貢献する際も、LLMが知識を補完してくれるため、そのコストが下がった。さらに、両プラットフォーム間での機能パリティを維持する作業も、共有された仕様やテスト、レビュープロセスを通じてLLMが大部分を担えるようになった。

これらの変化により、「一度コードを書けば両プラットフォームで動く」というクロスプラットフォーム開発の最大のメリットが、もはや決定的な要因ではなくなった。その結果、ネイティブ開発が持つ「OSの最新機能やパフォーマンスに直接アクセスできる」という本質的な利点や、「OS提供の優れた開発ツールを活用できる」というメリットが相対的に重要になったのである。

Shopifyが下したもう一つの大きな決断は、既存のReact Nativeアプリを「グリーンフィールド」、つまり完全にゼロからネイティブで再構築することだった。通常、稼働中の大規模なアプリをゼロから作り直すのは、リスクが高く、避けるべき「ブラウンフィールド移行」という選択肢が選ばれることが多い。しかし、LLMの助けがあれば、既存のReact Native版を参考にして、新しいネイティブアプリを素早く構築できることがプロトタイプで示された。これにより、古いコードが持つ制約から解放され、よりクリーンで効率的なアプリ開発が可能になったのだ。実際に、Shopアプリはわずか6人のエンジニアで12週間という短期間で完全にネイティブアプリとして再構築され、ストアに公開された。

この移行プロセスにおいて、Shopifyは「Helix」という独自のシステムを開発した。LLMに「React Nativeのコードをすべてネイティブに変換して」と一発で指示しても、保守性の低いコードが生成されてしまうことがわかったからだ。Helixは、アプリの画面を小さな作業単位（チェックポイント）に分割し、それぞれのチェックポイントでLLMが生成したコードに対して厳密なテストと人間やAIによるビジュアルレビューを必須とする。不完全な結果は次に進めず、合格するまで修正を繰り返す。これは「最初の出力は完璧でなくてよいが、最終的な結果は高品質でなければならない」という重要な原則に基づいている。

また、開発のボトルネックがLLMの「賢さ」ではなく、「コード変更後のテストにかかる時間」であることも明らかになった。以前は、LLMがコードを修正した後、シミュレーターを使って結果を確認するのに数分かかっていた。そこでShopifyは、アプリのビジネスロジックをUI（ユーザーインターフェース）から完全に分離し、LLMがCLI（コマンドラインインターフェース）を通じてUIなしでアプリの状態を検査したり、操作したりできるようにした。これにより、テストが数分からミリ秒単位に短縮され、LLMが自律的に何時間も作業できるようになった。これは、どんなAIエージェントを活用する開発においても、「高速なフィードバックループ」を実現するための極めて重要な教訓となる。

今回のShopifyの決定は、React Nativeという技術が悪いという話ではない。Shopify自身も、React Nativeコミュニティへの貢献を続け、主要なオープンソースライブラリの長期的な維持管理についても責任を持って対応しようとしている。

今回の件から学ぶべきは、「技術選択の根拠となる経済的・技術的な前提が、LLMのような新しい技術の登場によって変化したとき、過去の成功体験に固執せず、大胆にその前提を問い直し、再評価する柔軟な姿勢が重要である」ということだ。各チームの規模、採用市場、必要なプラットフォーム機能、LLMの活用度など、状況は様々であり、必ずしもすべてのチームがネイティブに移行すべきという結論にはならない。しかし、Shopifyが実践した「Helix」のような段階的なリファクタリング手法や、「ビジネスロジックとUIを分離し、CLIで高速に操作・テストする」というアーキテクチャは、モバイル開発にとどまらず、あらゆるソフトウェア開発におけるAI活用において非常に価値のある教訓となるだろう。Shopifyは、かつて「一度構築すればよい」という思想にモバイル開発の未来を賭けたが、今は「LLMが二度構築するコストを十分に安価にする」という考えにその未来を賭けている。この変化が、今後ウェブやバックエンド、インフラ開発にもどのような影響を与えるか注目すべきだ。