Shopify が React Native から Swift / Kotlin へ回帰 — AI が「2回作るコスト」を消した理由

はじめに

2026年9月10日、Shopify が全モバイルアプリを React Native から Swift / Kotlin のネイティブ実装に戻すと発表した。Hacker News では500ポイントを超え、370件以上のコメントが付いている。

Shopify は2020年に「React Native is the Future of Mobile at Shopify」と宣言し、React Native を大規模に採用した代表的な企業だった。2025年1月にも「React Native の5年間」を振り返る記事で New Architecture の採用を約束している。その会社が、約1年8か月後に方針を反転させた。理由は React Native の欠陥ではなく、AI コーディングエージェントの進化だという。この記事では、発表の中身、Shop アプリで出た実測値、そして「クロスプラットフォームを選ぶ根拠」がどう変わったのかを整理する。

何が発表されたのか

発表は2本の記事で構成されている。方針を示す「Native is now the future of mobile at Shopify」と、先行事例である Shop アプリの移行記録だ。

方針記事の核心は次の一文にある。

Agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain. （エージェントによって実装を共有する利点は小さくなったが、プラットフォームごとに作る利点は残っている）

2020年の判断は「iOS と Android で同じ機能を2回作るのは高い」という前提に立っていた。当時の Shopify は、Shop アプリ（当時の Arrive）で95%、Compass で約99%のコードを両 OS で共有していると公表していた。ところが、iOS 版を参照して Android 版を書く（その逆も）といった実装・移植・テスト・レビューの作業を、エージェントが十分に担えるようになった。記事は「2つのプラットフォームを保守するコストが消えたわけではない」と認めたうえで、それが2020年のような決定要因ではなくなったと述べている。

移行方式は段階的な置き換え（Brownfield）ではなく、全面的な作り直し（Greenfield）だ。既存の React Native コードは共有ロジックとして残すのではなく、エージェントが読む「参照資料」として使う。Shop アプリは概念実証から公開まで12週間で終わり、300画面以上ある Shopify アプリは2026年後半に出荷予定。OSS については FlashList の保守を続け、Restyle はアーカイブ、React Native Skia は William Candillon 氏に引き継ぐ。

移行を支えた仕組みと実測値

注目すべきは「AI に書かせた」ことではなく、AI の出力を通すための検証基盤を先に作った点だ。

Helix（チェックポイント型の移行基盤）: 方針記事で紹介された、Shopify が構築した移行の仕組み（Shopify アプリの作り直しで使用中）。React Native の画面を指定すると、Helix がコードを解析し、数分でレビューできる小さな作業単位（チェックポイント）に分割する。各チェックポイントは、自動テストで振る舞いを証明し、動いているアプリと画面を突き合わせ、2回の敵対的コードレビューを通過し、最後に人間が承認しないと先に進めない。

It doesn’t expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result. （最初の出力が正しいとは期待しない。不完全な試みは良い結果になるまで先に進めないループを作る）

エージェントが操作できるアーキテクチャ: ビジネスロジックを UI から完全に切り離し、デスクトップ上でヘッドレスに動かせるようにした。エージェントは CLI 経由でアプリの状態を調べ、画面遷移や操作を実行できる。シミュレータの起動を待たずにミリ秒単位でフィードバックが返るため、試行回数を稼げる。

Shop アプリで使われた仕組み: 先行した Shop チームの移行記事には Helix の名前は出てこない。Shop チームは Pi コーディングエージェントの拡張として再利用可能な移行ワークフローを作り、React Native のソース調査、振る舞いの文書化、プラットフォーム別の計画、実装、パリティのレビューをそれぞれ専用のサブエージェントに割り当てた。さらに、ライブのイベント・ログ・状態をエージェントに渡すデバッグツール「Tardis」を作り、React Native 版とネイティブ版のイベント列を比較してパリティを検証している。

Shop アプリの移行記事が公表した数値は次のとおり。

指標	React Native	ネイティブ
起動時間（iOS）	3,200 ms	2,466 ms（23%短縮）
起動時間（Android）	4,433 ms	2,233 ms（50%短縮）
セッション安定性	99.5%+	99.95%+（クラッシュするセッションが1/10）
アプリサイズ（Android）	293 MB	184 MB（−109 MB）
アプリサイズ（iOS）	67 MB	68 MB（+1 MB）

Android のリリースビルド時間も約75%短くなった。中核チームはエンジニア6人で、UI は SwiftUI と Jetpack Compose。学習コストは想定より小さく、React Native で培った宣言的 UI の経験が SwiftUI / Jetpack Compose での生産性につながったという。

エンジニアへの影響

最初に押さえておきたいのは、この発表が「React Native はダメだった」という話ではないことだ。Shopify 自身が「2020年の Shopify にとって React Native は正しい選択だった」と明記している。変わったのは技術の優劣ではなく、クロスプラットフォームを選ぶ理由の重みだ。

「コードを1回書けば両 OS で動く」は、React Native にも Flutter にも共通する最大の売りだった。Shopify の主張は特定のフレームワークではなく、この「共有による節約」という前提そのものに向いている。Flutter は独自描画でブリッジを持たないなど React Native と構造は違うが、技術選定の場で「AI があるなら両方ネイティブで書けばよいのでは」と問われる場面は増えるはずだ。そのとき「開発工数が半分になる」だけでは答えとして弱くなる。

一方で、Shopify の条件をそのまま自社に当てはめるのも危険だ。今回の移行は、ヘッドレスで動くコア層、CLI で操作できるアプリ、テスト・画面比較・二重レビュー・人間の承認を強制する Helix、Shop チームが作ったサブエージェント型の移行ワークフローと Tardis という、相当な投資の上に成り立っている。移行記事自身も「生成コードは要件を満たしつつ、重複・アーキテクチャの逸脱・性能問題を持ち込むことがある」と書き、ネイティブの専門知識は依然として必要だと結論づけている。

Hacker News の議論でも論点は同じところに集まった。2つのアプリを常に同じ仕様に保つ組織的なコストは、コードを誰が書くかとは別に残る。React Native の OTA 更新（ストア審査を待たずにホットフィックスを配る仕組み）を失うことを痛手と見る声もある。人員に余裕のない小さなチームでは、クロスプラットフォームの利点は依然として大きい。

実務で持ち帰るべき問いは、「どのフレームワークを使うか」から「AI の出力を検証する仕組みを持っているか」に移りつつある、ということだ。テストで振る舞いを固定し、画面を機械的に比較し、レビューを通らない限りマージされない。この基盤があれば、Greenfield の作り直しもフレームワーク移行も現実的な選択肢になる。逆にそれがなければ、どの技術を選んでも AI の出力はレビュー待ちの山になる。

まとめ

Shopify が全モバイルアプリを React Native から Swift / Kotlin（SwiftUI / Jetpack Compose）へ戻すと発表した
理由は「AI エージェントが、2つのプラットフォームで作るコストを決定要因でなくした」こと
Shop アプリは12週間で作り直し、起動時間は iOS で23%、Android で50%短縮、クラッシュするセッションは1/10になった
土台は AI そのものではなく検証の仕組み。Shopify 全体ではチェックポイント・テスト・二重レビュー・人間の承認を強制する Helix とヘッドレス構成、Shop アプリではサブエージェント型の移行ワークフローとパリティ検証ツール Tardis
2つのアプリを揃え続ける組織コストや OTA 更新の喪失は残るため、小規模チームにそのまま当てはまる結論ではない

クロスプラットフォームの価値は「コード共有による節約」から、別の何かで説明し直す段階に入った。次に問われるのは、各フレームワークがその「別の何か」を示せるかどうかだ。

今日のその他のニュース

Cognition がコーディングモデル SWE-2 を発表（Cognition）— Kimi K3（2.8T パラメータ）をベースに強化学習をかけたモデル。FrontierCode 1.1 で 50.0% と Fable 5.1 との差は1ポイント以内で、コストは64%安い。報酬にコストのペナルティを入れており、FrontierCode 1.1 では medium 設定のステップ数が SWE-1.7 より58%少ない。

Microsoft が Rust を Tier-1 言語に（Rust Foundation）— C++ / C# / TypeScript と同格の扱いになる。新しいバックエンド rustc_codegen_utc で Rust を MSVC に統合し、C++ と同じコード生成基盤・セキュリティ機能・デバッグツールを共有する。

Python の dict / set が二次時間に悪化するケース（Daniel Lemire）— i * M のようにハッシュが衝突しやすい値を挿入すると、n=16000 で約1秒、n を2倍にすると約4倍の時間がかかる。読み取り専用の大きなマップなら専用ライブラリ fastconstmap が有効。