スマートフォンアプリの見積もりを取ると、ほぼ必ず出てくる説明があります。「iOS と Android を1つのコードで作れるので、別々に作るより安く済みます」。この一文が、ここ10年ほど発注側の判断を支えてきました。
2026年9月10日、Shopify が主力の Shop アプリを React Native から Swift と Kotlin のネイティブ実装に戻したと発表しました。React Native を5年以上使い、その経験を公開してきた会社です。
注意すべきなのは、理由が「React Native がうまくいかなかったから」ではないことです。Shopify 自身、移行前のアプリは速く安定していたと説明しています。変わったのは技術の優劣ではなく、見積もりの前提のほうです。
発表された数字
公開されている内容から、判断に効くものを拾います。
- 検証段階からアプリストアでの公開まで、12週間（中核の6名のエンジニアに加え、途中から各機能チームも参加）
- セッションの安定性は 99.5%以上から99.95%以上へ。クラッシュするセッションが10分の1になったと説明されています
- 移行を可能にしたのはコーディングエージェントの性能向上。既存の React Native 実装を参照として、Swift と Kotlin それぞれの実装、テスト、レビューまでを回せるようになったことが理由に挙げられています
12週間という数字だけが独り歩きしやすいところですが、これは既に動いている完成品が手元にある状態からの再実装です。仕様が確定していて、参照実装があって、テストの正解も分かっている。ゼロから作る場合とは条件が違います。
こちらは同社が公開したShopifyアプリの移行デモです。12週間で公開されたShopアプリとは別のアプリで、画面を小さな確認単位に分けて実装する工程を示しています。 出典：Shopify Engineering「Back to Native」。
共有コードの利点と、2系統を維持する費用
そもそも、なぜ1つのコードで作る方式が選ばれてきたのか。主な理由のひとつが、実装を共有できることです。
同じ機能を2回作らなくて済むから。
画面を1つ作れば両方に出る。修正も1回で済む。エンジニアも1つの言語で足りる。この「2回作るコスト」を消せることが、当時の Shopify では、フレームワークの維持にかかる負担を上回っていました。
Shopify の発表が言っているのは、AI がこの前提の分母を小さくした、ということです。参照実装があれば、もう一方の言語への実装をエージェントが担える。すると「2回作るコスト」が、以前ほど大きくなくなります。
崩れていないものを、一緒に崩さない
ここが発注側にとっていちばん重要なところです。エージェントが安くしたのは実装の部分であって、アプリ開発の費用はそれだけではありません。
安くなっていないものを並べます。
- 仕様を決める作業。 何を作るかを決めるのは人です。2つ作るなら、プラットフォームごとの挙動の違いも決める必要があります
- 設計とレビュー。 生成されたコードを読んで妥当かを判断する人は要ります。むしろ量が増える分、見る仕事は増えます
- 審査と公開。 ストアの審査、証明書の管理、リリースの手順。プラットフォームごとに別作業です
- 公開後の運用。 不具合の報告が2系統から来ます。どちらで起きているかの切り分けが増えます
- 人の確保。 Swift と Kotlin の両方を見られる体制が要ります。エージェントが書いても、レビューする人は必要です
つまり、2つ作るコストがゼロになったわけではなく、内訳の中で実装の比率が下がったという変化です。実装が費用の大半を占めていた案件ほど効きますし、そうでない案件では効き方が小さくなります。
規模ごとに、判断の向きが違う
Shopify の判断をそのまま自社に当てはめられるかは、規模で変わります。
画面数が少なく、更新も年に数回の業務アプリ。 クロスプラットフォームのままで問題ありません。2つに分ける理由が、実装コスト以外にほとんど無いためです。むしろ運用の系統が増えるぶん不利になります。
社外向けで、動きの質が体験に直結するアプリ。 ネイティブを検討する意味が出ます。ただし判断材料は「AI で安くなったから」ではなく、具体的に何が実現できていないかであるべきです。実現できていないものが挙げられないなら、それは作り直す理由になりません。
そもそもアプリである必要があるか。 Web で足りるものをアプリにしている場合、選ぶべきは言語ではありません。WebView で包んだアプリの落とし穴はWebViewで作るアプリの見落としと合意範囲で扱っています。発注前に読む順番としては、こちらが先です。
外注する場合の全体的な進め方は業務用モバイルアプリを外注するときのガイドに、クロスプラットフォームの技術選定そのものはFlutterでフルスタックに作る場合の範囲にまとめています。
見積もりを読むときに聞く3つ
方式の話が出たら、次を確認してください。技術に詳しくなくても聞ける形にしてあります。
- 「その方式を選ぶ理由は、費用ですか、実現したい体験ですか」。 費用が理由なら、2つ作る案の金額も並べて出してもらいます。差額が思ったほど無いことがあります
- 「公開後の修正は、片方だけ直す場面がありますか」。 ある、と答えるなら、それはもう1つのコードで済んでいません。運用の実態を先に聞けます
- 「AI で工数を圧縮している場合、レビューは誰がしますか」。 実装が速い前提の見積もりなら、その分レビューの体制が明記されているはずです。書かれていなければ、そこは誰の仕事にもなっていません
次にやること
いま検討中のアプリについて、画面の数と、公開後1年間で何回更新する見込みかを書き出してください。
画面が少なく更新も少ない場合でも、端末機能への依存と保守できる人材で費用が変わります。まず既存の方式で要件を満たせるかを確認し、移行の追加費用と比較します。
逆に画面が多く継続的に更新していく前提なら、そこは実装方式より誰が更新し続けるかの設計のほうが効きます。ニュースで見た大手の判断を持ち込むより、自社の更新頻度を数字にするほうが、見積もりの比較には役立ちます。
アプリの方式選定、既存アプリを作り直すかどうかの判断、AI を組み込んだ開発体制の設計については、グリームハブの開発・AI・自動化のご相談で承っています。対象の規模と運用の体制によって進め方が変わるため、お問い合わせからご相談ください。
Sources
- Native is now the future of mobile at Shopify (2026) — Shopify Engineering
- Migrating Shop app from React Native to native (2026) — Shopify Engineering
- Shopify spent years on React Native — then rebuilt everything in 12 weeks — The New Stack
- Five years of React Native at Shopify (2025) — Shopify Engineering
