原題: Native is now the future of mobile at Shopify
著者: Mustafa Ali
公開日: 2026-09-10
ソースURL: Shopify Engineering
アーカイブ日: 2026-09-11
Shopifyは2020年にReact Nativeへ全面移行し、その判断は大きな成功を収めた。機能を一度だけ作ればよくなり、モバイル経験のない開発者もアプリに貢献でき、プラットフォーム間の機能差を追いかけ続ける負担から解放された。著者は2025年1月にも「React Nativeの未来は明るく、Shopifyは投資を続ける」と書いている。それは当時知り得た事実に基づく正しい判断だったと著者は言う。しかしその後、コーディングモデルが劇的に進歩し、同じ機能をSwiftとKotlinで作ることが、かつてのようなコストを伴わなくなった。
著者が強調するのは判断の姿勢である。過去に成功したという理由だけで決定に固執しない。中核の前提が変わったら、まだ正しい選択なのかを一から問い直す。LLMは2020年の決定を支えていた前提の一つを変えた。だからモバイルスタックを第一原理から再評価し、その結果としてネイティブに戻ることになった。
2020年にReact Nativeを選んだ理由は三つあった。同じ機能を二度作るのをやめること、開発者がスタックをまたいで働けるようにすること、機能差の追従に費やす時間を減らして価値の提供に集中すること。React Nativeはこれらを一貫して実現した。パフォーマンス最適化、フレームワークの基盤領域の改善、フレームワーク更新と外部依存への追従にかなりの時間と資源を使ったが、それは受け入れ可能なトレードオフだった。
Shopifyは2021年、ChatGPTの登場より1年早くからLLMでソフトウェアを作ってきた。最初は機能実装、バグ調査と修正、コードレビューに使い、モデルの改善に伴って任せる仕事の複雑さも上がった。2025年後半には、LLMは単にコードを速く書く助けではなく、「ソフトウェアを二度作ることが本当に二倍の仕事を意味するのか」を問わせる存在になっていた。そこで主要アプリの中核部分をLLMを使ってSwiftとKotlinで作り直すプロトタイプを行い、その出来に驚いたという。エージェントはiOS版を参照してAndroid版の機能を実装でき、その逆もできた。開発者が自分の主戦場でないスタックに立ち上がって貢献する助けになった。共有の仕様、テスト、レビューのチェックポイントを通じて、プラットフォーム間の同等性を維持するコストを劇的に下げた。
著者は誤解を避けるために二点を明言する。第一に、ネイティブは今も二つのプラットフォームでソフトウェアを作り維持することであり、そのコストは消えていない。変わったのは、実装、翻訳、テスト、レビューの仕事の十分な部分をエージェントが担えるようになり、2020年のような決定要因ではなくなったことだ。第二に、React Nativeアプリは速くできるし、Shopifyのアプリも速い。移行の理由は性能ではなく、共有実装の利点をエージェントが縮小させた一方で、各プラットフォーム向けに作る利点はそのまま残ったからである。ネイティブはプラットフォームの能力とファーストパーティのツールに近く、コードとプラットフォームの間にあるフレームワークや依存の層が少ない。
移行の説明に入る前に、著者はオープンソースライブラリの扱いを明確にする。Shopifyは当初からReact Nativeに貢献する意志を持ち、各分野で最有力となったライブラリを公開してきた。React Native Skiaは2026年末までShopifyがスポンサーを続け、その後もWilliam Candillonが開発を続ける。彼は数か月以内にリポジトリをフォークし、新しい名前で公開を始め、移行完了後に元リポジトリはアーカイブされる。FlashListは週約200万ダウンロードを持ち、React Nativeで高性能なリストを描画する既定の手段になっているため、互換性を壊す重大な問題の修正は続け、長期的な管理を引き受ける複数の企業と協議中である。Restyleは利用者が少ないためアーカイブし、2026年末まで動作を保証した後は保守を止め、引き継ぐチームがあれば手助けする。
移行方法については、段階的に置き換えるブラウンフィールドと、一から作り直すグリーンフィールドを比較した。React Nativeへ移行した過去には、書き直しに何年もかかり新機能の出荷を止めざるを得ないため、最大級のアプリでブラウンフィールドを選んだ。今回はグリーンフィールドが明確な勝者となった。LLMはReact Native版を参照してSwiftとKotlinで機能を作るのが得意であること、過去の制約なしに最良の形で作り直せること、プロトタイプがコーディングエージェント以前よりはるかに速く再構築できると示したことが理由である。アプリストアのショッピング部門で常に上位にあるShopアプリが最初の対象となり、AIの支援を受けたチームは概念実証からストア公開済みの完全なネイティブアプリまでをわずか12週間で仕上げた。300以上の画面、ホームとロック画面のウィジェット、Apple Watchアプリ、コンプリケーション、Siriショートカットなどを持つ最大のアプリであるShopifyアプリの移行も進行中で、年内に出荷予定である。
著者が「スロップの防止」と呼ぶ節は、この記事の技術的な核心である。LLMにReact Nativeのコードベースを指し示して同じ機能をネイティブで一発生成させたくなるが、それは機能しない。前もって可能な限り情報を集めさせ、仕様やタスクファイルに凍結してから実装させても、出荷できない保守不能なコードが大量にできあがる。これを解決するためにHelixというシステムを構築した。Helixは最初の出力が正しいことを期待せず、不完全な試みが良い結果になるまで先に進めないループを作る。開発者がHelixに画面を指定すると、HelixはReact Nativeのコードを読み、数分でレビューできる小さく順序づけられた作業単位であるチェックポイントの列を提案する。そしてチェックポイントごとに、テストで振る舞いを証明し、動作中のアプリとの視覚的な照合に合格し、二つの敵対的なコードレビュアーを生き延び、人間の承認を得てからコミットされ、次に進む。すべてのレビューからのフィードバックは記憶されるため、移行が進むほどループは自律的になる。この方法は極めてうまく機能し、従来の何分の一かの時間でアプリを作り直せているという。
もう一つの節は高速なフィードバックループの実現である。エージェントによるシミュレータ制御はボトルネックだった。ビルド、テスト、反復が安定せず、常に付き添う必要があった。バグを再現し修正し検証する自律ツールも作ったが、遅く脆かった。React Nativeのホットリロードは助けにはなるが解決にはならない。原因はアプリの状態取得、操作、結果検証がアクセシビリティツリーやスクリーンショットに依存していることで、エージェントはコード変更を数秒でできるのに、出力のテストに数分かかる。どれほどモデルが良くても、自分の仕事を速くテストできなければ意味がなく、モバイルではそれが特に難しい。
Shopifyはこれを、人間とエージェントの両方のために働くアプリアーキテクチャを設計することで解決している。中核原則は、業務ロジックをUIから完全に切り離し、デスクトップ上でヘッドレスに実行できるようにすることだ。それをCLI経由でエージェントに提供し、シミュレータを介さずに数分ではなくミリ秒単位で反復できるようにする。CLIはアプリの状態を検査し、セクション間を移動し、UIに触れずに操作を実行できる。これによりエージェントは何時間も自律的に働ける。シミュレータ操作が必要な場合も、CLIはリモートモードで接続し、レイアウトやアクセシビリティツリーを検査せずにコマンドでUIを駆動するため、非常に高速なE2Eテストが可能になる。
今後については、すべてのモバイルアプリをAIを全工程で用いてSwiftとKotlinへ移行する。速く動くが基準は下げず、あらゆる再構築は現在期待されている性能、安定性、アクセシビリティ、製品品質を満たすか上回らなければならない。これは同じアプリを別の言語で書き直すことではなく、人間とエージェントの双方が素早く理解し、テストし、変更できるように作り直すことだと著者は言う。移行はゴールではなく、成功とは以前より速くマーチャントと購入者に良い体験を届けられることであり、製品開発の速度、アプリ品質、エージェントが自律的に完了できる仕事の量で測る。Helix、エージェントが扱えるアーキテクチャ、エージェントとのモバイルアプリ構築について、今後さらに詳しく共有する予定である。
記事はMetaのReact Nativeチーム、William Candillon、Software Mansion、Shopifyのエンジニア、React Nativeコミュニティへの謝辞で締めくくられる。ネイティブは今のShopifyにとって正しい選択だが、React Nativeは2020年のShopifyにとって正しい選択だった。過去6年間で築いたツール、教訓、関係はこれからもShopifyのモバイル開発を形作り続けると著者は述べている。
この記事の価値は、結論そのものより「なぜ前提が崩れたか」を当事者が説明している点にある。クロスプラットフォームフレームワークの存在意義は、二つのプラットフォーム向けに同じものを作る人的コストを共有実装で吸収することにあった。著者はそのコストが消えたとは言わない。実装、翻訳、テスト、レビューの十分な部分をエージェントが担うようになった結果、共有実装という利点だけが相対的に薄まり、プラットフォームに近いという利点が残った、という整理である。フレームワーク選定の議論はしばしば性能や生態系の優劣に流れるが、この記事は「何を共有するために抽象層を置いていたのか」を問い直す視点を与える。
技術的な観察も具体的である。React Nativeのコードを一発でネイティブに変換させると保守不能なコードができるという失敗の記述、それに対してチェックポイント単位でテスト、視覚照合、敵対的レビュー、人間の承認を通過しなければ先へ進めないHelixのループ、そして業務ロジックをUIから切り離してデスクトップでヘッドレス実行しCLIでエージェントに触らせるアーキテクチャは、既存アーカイブが論じてきた「環境設計がエージェントの成果を決める」という主張の、大規模かつ実運用の事例になっている。エージェントがコードを数秒で変えられても検証に数分かかれば意味がないという指摘は、モバイルに限らずエージェント時代のアーキテクチャ設計の基準として長く参照されるだろう。
同時に、2025年1月の「React Nativeの未来は明るい」から1年半で全面撤回に至った経緯と、Skia、FlashList、Restyleの引き継ぎ方針を明示した誠実さも、この記事を記録として残す理由である。大企業が自ら育てた生態系から撤退するときに何をどう説明したかは、技術史の資料として残る。一方で、12週間での再構築や「何分の一かの時間」といった成果は著者側の報告であり、品質や長期保守性の検証は今後の続報を待つ必要がある点には留意が要る。
Shopify、React Native、Swift、Kotlin、モバイル開発、コーディングエージェント、アーキテクチャ、オープンソース