React Nativeからネイティブへ：Shopifyが方針を変えた背景
2026年9月10日、Shopify Engineeringはモバイルアプリ開発の方針転換を公表しました。これまで同社は、iOSとAndroidのコードを一元化しやすい「React Native」を広く採用してきました。これに対し、各OS専用の言語（iOSはSwift、AndroidはKotlin）で個別に画面や機能を構築する「ネイティブ開発」へと再び舵を切ることを明らかにしています。
この転換の背景にあるのが、AIによるコード生成技術の進展です。かつては2つのプラットフォーム向けに別々のコードを書き、機能の同等性を維持し続ける負担が大きな課題でした。そのため、コードや開発者を共通化できるクロスプラットフォーム開発には確かな利点がありました。2025年1月に公開された記録ShopifyにおけるReact Nativeの5年間を振り返る記事でも、領域をまたいで開発に参加できる体制が高く評価されていました。
しかしShopifyによれば、AIエージェントの活用によって両OS向けの実装や機能同等性を保つコストが大きく変わり、ネイティブ回帰という選択が現実味を帯びてきたと説明されています。両プラットフォームを保守する負担そのものが消えたわけではありませんが、かつてのように採用判断を縛る決定打ではなくなったという見立てです。同社の詳しい方針と判断の経緯は、Shopifyのネイティブ回帰に関する公式発表にまとめられています。
なお、今回の発表時点で移行が完了しているのは一般消費者向けアプリ「Shop」です。事業者向けの「Shopify」アプリについては段階的な移行が進められている段階であり、全社すべてのアプリが一斉に置き換わったわけではない点に注意が必要です。
1人の1週間実証から、6人中心の移行チームへ
Shopアプリの移行は、最初から全社規模の体制で始まったわけではありませんでした。発端となったのは、1人のエンジニアが1週間かけて行った小規模な技術実証（PoC）です。この時点では本番運用に耐えうる品質ではありませんでしたが、すでに稼働している既存アプリを「動く仕様書」として参照しながら、AIとともにネイティブ実装を立ち上げられる感触を掴みました。
手応えを得たチームは本格的な移行へ進み、中核となる6人のエンジニアに各機能チームが合流する体制で、実証から約12週間でストア公開に至ったと報告されています。チームが実践した具体的な工夫については、Shopify Engineeringの実践記録であるShopアプリの移行プロセスに関する記事で公開されています。
この移行で重視されたのは、単に画面の見た目を真似ることではありませんでした。ユーザーのログイン状態を途切れさせないこと、プッシュ通知を正しく届けること、アプリ操作時に推薦などの後続システムへ必要な分析イベントが従来どおり正しく送られることなど、業務と利用体験の土台を支える連続性が強く意識されました。また、全画面を一対一で忠実に再現したわけではなく、使われなくなった画面の廃止や仕様の簡略化も同時に行われています。
この迅速な検証を支えたのが、工程の分担と新旧アプリの比較環境です。Shopアプリの移行現場では、「Pi」と呼ばれるコーディングエージェントの拡張として作業工程を実装し、「仕様の把握」「作業計画の立案」「実装」「動作の比較」という役割を分担させました。さらに「Tardis」という仕組みを活用し、実行中のイベントログや内部状態を取得して、新旧アプリで画面の見た目だけでなく内部挙動の食い違いまで素早く突き合わせられるようにしたと報告されています。
自社の業務アプリ改修に活かせる「参照実装」と比較検証の視点
Shopifyの取り組みから学べるのは、AIにゼロから作らせるだけでなく、「すでに動いている既存の実装」を参照先に据え、動作の差分を確かめる環境を整えるという考え方です。もちろん既存アプリの不具合まで正解として引き継ぐ必要はありませんが、残すべき振る舞いと変更したい部分を切り分ける上で、動く現物は手掛かりになります。
この考え方は、自社の業務システムを改善していく上での一つの提案となります。たとえば説明用の仮定例として、現場の点検作業員が使うタブレットアプリの画面を改善したい場面を考えてみます。入力しづらい帳票画面をモダンなレイアウトに見直すとしても、既存の顧客台帳へのデータ連携や利用者の認証基盤は、これまでの安全な動作をそのまま維持しなければなりません。
このような改修を検討する際は、まず現場で現在使われている画面、見直したい入力項目、裏側で連携している他システムを整理することから始めるのが現実的です。その上で、利用中のパッケージやクラウドサービスの設定変更、標準機能の範囲だけで目的が満たせないかを確かめます。利用製品の仕様やAPIによって対応可否は異なるため、既存機能だけで対応が難しいと分かった段階で、個別のAPI連携や画面改修、そして改修前後のデータ整合性を確かめる検証範囲の検討へ進むという進め方が考えられます。
既存の業務アプリを活かした改修のご相談
デノフでは、業務システムの企画・設計から開発、運用保守まで、企業の状況に合わせたシステム改善を支援しています。支援の範囲や進め方は、デノフのサービス案内でご紹介しています。
「現在の基幹連携を維持しながら現場アプリの操作性を改善したい」「設定や標準機能で対応できる範囲と、個別開発が必要な境界を整理したい」といった検討がありましたら、残す機能や連携要件の棚卸し、小さな検証の設計からお手伝いいたします。具体的なご相談は、デノフへのお問い合わせよりお気軽にご連絡ください。
