AIエージェントが促すモバイル開発の「ネイティブ回帰」
モバイル開発の「ネイティブ回帰」と聞いて、2012年のFacebookを思い出す人もいるでしょう。同社はHTML5を多用していたiOSアプリをネイティブコードで全面的に作り直しました。CEOのマーク・ザッカーバーグ氏が「企業としてHTML5に賭けすぎたことが最大の過ち」と語ったこの転換は、当時の「Web対ネイティブ」論争を象徴する出来事となりました。
ただし、今回は事情が異なります。
Facebookの転換は、性能やユーザ体験の問題が背景にありました。これに対してShopifyは、2020年のReact Native移行を大成功と評価しており、現在も優れたフレームワークと位置づけています。それでもなお、開発基盤を切り替えるのはなぜでしょうか。
背景にあるのは、AIコーディングエージェントの進化による「開発コストの構造変化」です。
「コード共有が最適解」という前提が揺らぐ
この10年、多くの企業がモバイルアプリ開発にReact Nativeなどのクロスプラットフォーム技術を選んできました。大きな理由の一つが、開発と運用の効率化です。
iOSとAndroidをネイティブで開発する場合、それぞれ異なるコードベースを維持する必要があります。同じ機能でも各OS向けに実装してテストし、仕様変更に追従しなければなりません。さらに、リリース時期や挙動に差が出ないよう「機能パリティ（等価性）」を保つ調整も必要です。
コードの多くを一本化できるクロスプラットフォーム技術は、こうした重複作業を減らせます。JavaScriptやTypeScriptに通じた既存の人材や知見を生かしやすいことも、企業にとって大きな魅力でした。
ところが、コーディングエージェントの急速な進化によって、実装、移植、テスト、レビューをAIが支援できるようになりました。それにより、iOSとAndroidを別々に開発すれば、それだけ大きな追加コストが発生するという従来の前提が揺らぎ始めました。
Shopアプリを12週間でネイティブ再構築
Shopifyが最初に移行させたのは、消費者向けの「Shop」アプリです。同アプリは、React Nativeの新アーキテクチャ採用という次の大型投資を控えていました。その作業ではネイティブモジュールの連携、レンダリング、共有コードとプラットフォーム固有コードの境界を見直す必要があります。そこで投資を決める前に、エージェントを使ってSwiftUIとJetpack Composeで直接作れるかを検証しました。
まず1人のエンジニアが1週間、コーディングエージェントを使って既存のReact NativeアプリをSwiftUIベースのiOSアプリへ移植する概念実証を実施。この結果に手応えを得て、全面移行を決定しました。6人の中核エンジニアがネイティブ基盤と主要な利用動線を構築し、途中から各機能チームが合流。概念実証からApp StoreとGoogle Playでの公開までに要した期間は12週間でした。
移行では、既存のReact Native版を参照しながらSwiftおよびKotlinで機能を再構築しました。エージェントは、画面フレーム、データ接続、アニメーションやレイアウトの再現まで担い、2つのプラットフォームの間で仕様やテスト、レビューの基準を共有して機能差を管理します。
もちろん、SwiftとKotlinという2つのコードベースを持つ以上、保守の手間がなくなるわけではありません。Shopify自身も、別々に開発するコストは依然として存在すると認めています。それでも、エージェントによってその差が縮まり、コードを共有することが以前ほど決定的な条件ではなくなったと判断しました。
移行前後を比べると、コールドスタート時間はiOSで23％、Androidで50％短くなりました。セッション安定性は99.5％超から99.95％超に向上し、クラッシュするセッションはおよそ10分の1に減っています。
ただし、Shopifyは移行に合わせて一部画面の廃止やアプリ構成の整理も行っており、これらの向上すべてがネイティブ移行による効果というわけではありません。
それでも、大規模アプリをネイティブで全面的に作り直すという、従来なら長期化しやすかったプロジェクトを、AIエージェントを組み込んだ体制で短期間に実行できた意味は大きいでしょう。
同社は「Shop」に続き、300を超える画面やウィジェット、Apple Watchアプリなどを抱える主力の「Shopify」アプリの移行も進めており、2026年中の公開を予定しています。
コード共有と引き換えに失っていたもの
実装を共通化するメリットが薄れ、ネイティブコードを維持するハードルが下がると、これまでコード共有と引き換えに受け入れてきたトレードオフが改めて問い直されることになります。
ShopifyはReact Nativeを使う中で、パフォーマンス最適化や基盤部分の改善、フレームワーク更新、外部依存関係への追従などに相応のリソースを投じてきました。同社はこれまでは許容できるトレードオフであり、React Nativeを使う利点のほうが上回っていたと振り返っています。
ネイティブ開発の大きなメリットの一つは、各プラットフォームのツールチェーンやAPIを直接使えることです。iOSアプリをSwiftやSwiftUIで開発する場合、App Intents、WidgetKit、Live Activities、watchOSアプリなど、Appleが提供する機能をネイティブ環境から活用できます。
クロスプラットフォーム環境では、OS固有の機能への追従が複雑化する場合があります。これまでは開発コストの削減効果が勝っていたため容認されていましたが、その優位性が小さくなれば、プラットフォームの新機能や純正ツールを直接活用しやすいネイティブ開発の価値が際立ってきます。
とりわけ、モバイルアプリが主要な顧客接点になっている企業にとっては、OSの新機能を迅速に製品体験へ反映できることが、事業上の差別化につながる可能性があります。
AIが書き換える技術投資の「計算式」
生成AIの企業導入をめぐる議論は、開発者1人当たりの生産性に集中しがちです。しかし、Shopifyの事例が示しているのは、その先にある変化です。
AI投資の効果は「同じ仕事をより短い時間でこなす」ことにとどまりません。これまでコスト面で選びにくかった技術構成が選択肢に加わり、企業が選べる技術戦略の幅そのものが広がります。
もっとも、Shopifyの事例をそのまま一般化するのは早計です。同社によれば、AIが生成したコードは機能要件を満たしていても、処理の重複やアーキテクチャからの逸脱、性能上の問題を持ち込むことがあり、ネイティブ開発の専門知識は依然として欠かせません。
実際、Shopアプリの移行ではデバッグツール「Tardis」を開発し、主力Shopifyアプリの移行ではさらに「Helix」という仕組みを導入しています。
こうした開発基盤を自ら整備できる企業だからこそ、ネイティブ回帰を実現できた面もあります。一方でクロスプラットフォーム開発がその利点を失ったわけではなく、React NativeやFlutterが適する企業やプロジェクトも今後数多く残るでしょう。
それでも、CIOやCTOにとってShopifyの方針転換は、数年前に決めたモバイル開発戦略をこのまま前提にしてよいのかを問い直すきっかけになります。
企業システムでは、一度採用した技術を簡単には変更できません。移行には開発費だけでなく、人材育成、採用、テスト、運用体制の変更など、多くのコストが伴います。その移行コストまでAIが引き下げるなら、「今の技術を使い続けるほうが安い」という判断に再検討の余地が出てきます。
AIが変えつつあるのは、コードの書き方だけではありません。企業がどの技術基盤に投資するかを決める「計算式」そのものも、書き換わり始めているのです。
