Shopifyのネイティブ回帰、AIで2回移植した

Ryo｜WEBエンジニア

2026年9月12日 22:52

9月10日、Shopifyが「モバイルアプリをReact NativeからSwiftとKotlinに戻す」と発表しました。

つまり、iPhoneとAndroidで共通にしていたアプリのコードを、それぞれ専用のコードで書き分ける方式に戻す、という決断です。6年前とちょうど逆向きです。

理由をひと言でいうと「AIのおかげで、同じアプリをiOS用とAndroid用に2回作るのが、前ほど高くつかなくなったから」。

ただ同じ記事の中で、Shopifyは「React NativeのコードをAIに渡して一発で移植させるやり方は、うまくいかない」とも書いています。

そこで、ShopifyのOSSにあるReact Nativeのサンプル画面を1枚選び、AIに2回、SwiftUIへ移植させてみました。

先に結論を3行で。

・Shopifyがネイティブに戻す理由は、React Nativeが遅いからではなく、AIで「2回作る」コストが決め手でなくなったからです
・第1弾のShopアプリは12週間で出荷されました。ただしShopifyが紹介しているのは人の承認を挟む検証の仕組みで、「AIが全自動で移植した」話ではありません
・サンプル画面をAIに2回移植させると、型チェック（macOS向け設定）は2回とも一発で通りました。ただし元のバグっぽい挙動15件のどれを残すかは、指定していないのにAIが自分で線を引いていました

エンジニア6年目のぼくが、公式発表で確認できたことと、手元で試してわかったことを分けて書きます。

確認できたこと、まだわからないことの一覧

Shopifyの2本の公式記事（方針の記事と、Shopアプリ移行の記事）を読んで、主な主張を仕分けました。

・主張｜根拠｜判定
・全モバイルアプリをSwiftとKotlinへ移す｜方針の記事｜方針は確認。完了したのはShopアプリだけ
・Shopアプリは試作からストア公開まで12週間｜Shopアプリ移行の記事｜確認（自己申告）。中核6人に加え、途中から機能チームが参加
・起動がiOSで23%、Androidで50%短縮｜同記事の自己計測｜数字同士の計算は合う。ただし移行時に画面の廃止・簡素化も行っている
・クラッシュするセッションが10分の1｜同記事の自己計測｜99.5%超→99.95%超という記載と整合
・最大のShopifyアプリ（300画面超）の移行｜方針の記事｜進行中。出荷は今年後半の予定
・使ったAIモデル｜記載なし｜不明
・誰にとってもネイティブが得になる｜Shopify自身が「私たちのアプリとチームにとって」と限定｜一般化できない

「12週間」と「300画面超」は別のアプリの数字なので、混ぜないのが安全です。

何が起きたか。6年前の判断を前提から問い直した

発表記事（見出しは「Native is now the future of mobile at Shopify」）はまず、React Nativeを選んだ理由を振り返っています。筆頭は「同じ機能を2回作らない」。そのうえで、核心の一文がこれです。

「LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.」（LLMは2020年の決定を支えていた中核の前提の一つを変えた。だからモバイルの技術構成を第一原理から見直した）

大事なのは、続く一文です。

「Native still means building and maintaining software on two platforms, that cost has not disappeared.」（ネイティブは今も2つのプラットフォーム向けに作って保守することを意味する。そのコストは消えていない）

変わったのは、実装・翻訳・テスト・レビューの十分な部分をエージェントが担えるようになり、「2回作るコスト」が2020年ほどの決め手ではなくなったことだ、と書いています。

React Nativeを悪く言ってもいません。「React Native apps can be fast. Ours are.」（React Nativeのアプリは速くできる。うちのアプリは速い）とまで書いています。

ネイティブを選ぶ理由として挙げているのは、OSの機能や純正ツールに近いこと、コードとOSの間に挟まるフレームワークや依存の層が少ないことです。

なぜ重要か。React Nativeが悪くなったのではなく、代わりが安くなった

React Nativeをやめた大企業は前にもありました。2018年のAirbnbです。Airbnbは技術と組織の課題を挙げていて、その一つが、アプリの一部だけをReact Nativeにした結果、2つではなく3つのプラットフォームのコードを支えることになった点でした。使い続ける側のコストの話です。

Shopifyの理由は種類が違います。ここからは事実と意見を分けて書きます。

事実として、Shopifyは2025年1月の時点で「React Nativeの未来は明るい」と書き、全アプリの移行を終えていました。デバッグの不安定さや更新の重さといった弱点も認めたうえで、続けると判断していました。

今回Shopifyが決め手に挙げたのは、React Native側の変化ではなく、ネイティブで2回作るという「代わりの選択肢」の値段が下がったことです（Shopアプリについては、React Nativeの新アーキテクチャ対応という大きな投資の時期と重なった、とも書いています）。

意見として、ぼくはここがこのニュースの一番おもしろいところだと思っています。技術選定はたいてい「どれが優れているか」で語られます。でも実際には「どのコストを払いたくないか」で決まっていることが多い。

「2回書きたくない」という理由で選んだ技術は、書くコストが下がった瞬間に、選んだ理由の一部を失います。フレームワークが何も悪くなっていなくても、です。

Shopifyが「一発移植はうまくいかない」と書いた理由

では、AIに任せれば移植は簡単なのか。Shopify自身の答えは「そのままでは無理」です。

記事にはこうあります。React NativeのコードをLLMに渡して一発で同じ機能を作らせたくなるが、うまくいかない。事前に情報を集めて仕様やタスクに固めてから実装させても、出荷できない保守不能なコードが大量にできる。

そこでShopifyが組んだ仕組みを、2つの公式記事から表にまとめました。最大のShopifyアプリでは「Helix」、先に移行したShopアプリでは「Pi」というコーディングエージェントの拡張と「Tardis」という道具が紹介されています。

・Helix（Shopifyアプリで紹介）｜Shopアプリの移行
・進め方｜画面を、数分でレビューできる小さなチェックポイントに分けて1つずつ作る｜専用のサブエージェントが、挙動の文書化・計画・実装・元と同じかのレビューを分担
・確かめ方｜テストで挙動を証明し、動いているアプリと見た目を比べ、2つの敵対的なコードレビューを通す｜Tardisで新旧アプリの画面と分析イベントを同じ地点で比べる。リント・テスト・静的解析・性能チェック・コードレビューも併用
・人の関与｜各チェックポイントを人が承認してからコミット｜実装前に要件と計画をレビュー。承認は計画の内容に紐づき、計画を変えると無効

Shopアプリの記事は「ネイティブの専門知識は依然として不可欠だった」とも明記しています。Shopifyの投資は、書く部分より「元と同じか確かめる」部分に集中しているように見えます。

Hacker Newsのスレッド（9月11日夜の時点で1,000ポイント超、コメント750件超）でも、上位には「15〜20画面のアプリを一晩でCodexに9割移植でき、数日で仕上げた」という趣旨の体験談（atonse氏の本人申告）がありました。一方で「AIで書くコストは劇的に下がったが、読むことと手でテストすることはそこまで下がらない」という趣旨の指摘（zhyder氏）も出ています。

ぼくが試したかったのは、この「確かめる」の中身です。

手元で実験。ShopifyのOSSのサンプル画面をAIに2回移植させた

題材は、ShopifyのOSS「FlashList」のリポジトリにある、React Nativeのサンプル画面「Reminders」です（269行、MITライセンス）。リマインダーを追加して文字を打ち、チェックすると1秒後に消える小さな画面です。

手元のClaude Code（Opus 5）で、役割ごとに別々のサブエージェントを立てました。

・挙動リスト係: 移植版を見ずに、元のコードだけから「ユーザーに見える挙動」を書き出す
・移植係（2回）: 同じ指示で、別々にSwiftUIへ移植する。主な指示は「元の画面と挙動を同じにして」「型チェックを通して」「判断したこと、特に元の挙動が曖昧・不自然な箇所をどう扱ったかを報告して」の3つ（ほかに画像の代替可・対象OSの指定・時間の記録など）で、どれを残すか直すかは指定していない
・突き合わせ係（2回）: 移植係の報告は読まず（コード中のコメントは目に入る）、コードを見て挙動リストと1項目ずつ照合する

ShopアプリでShopifyが分けた役割（挙動の文書化、実装、元と同じかのレビュー）を、1画面の規模でなぞった形です。違うのは、途中で人が承認せず、一発で移植させたことです。

条件も書いておきます。このMacにはXcodeもiOS用のSDKもないので、シミュレータで動かせず、型チェック（コンパイラによる検査）もmacOS向けの設定で行いました。iOS向けにビルドが通るかは未確認です。確かめられたのは、型チェックとコードを読んでの突き合わせまでです。

結果はこうなりました。

・移植1回目｜移植2回目
・移植にかかった時間｜約32分（報告の執筆を含む）｜約25分
・行数（元は269行）｜385行｜299行
・型チェック｜1回目で通過｜1回目で通過
・58項目のうち元と同じ（コード読解の判定）｜46｜48
・元のクセ15件のうち残したもの｜10｜10

型チェックは移植係の自己申告に頼らず、まとめ役のClaude Code本体でもう一度流して、2回とも通ることを確かめています（わざと型エラーを入れた対照ファイルは、ちゃんと失敗しました）。

挙動リスト係が書き出したのは58項目。そのうち15項目に「バグの可能性あり」の印がつきました。たとえばこんなものです。

・削除がIDではなくタイトルの一致で行われるので、同じ名前のリマインダーは全部いっしょに消える
・チェックして1秒以内に外しても、削除は止まらない
・貼り付けた文字の改行は、最初の1つしか消えない

実験からわかったこと。どのクセを残すかをAIが決めていた

いちばん意外だったのは、移植係が2回とも、同じ10件のクセを残し、同じ5件を再現しなかったことです。

線の引き方も同じでした。コードに書いてあるとおりに毎回起きるクセは、バグっぽくても残す。Reactの描画タイミングや、FlashListのセルの使い回しから生まれる、条件しだいで起きるクセは再現しない。2回とも、この方針を最後の報告に書いていました（報告にはこの点を書くよう頼んでいました）。

なお、再現されなかった5件は、元のコードを動かして確かめたわけではなく、挙動リスト係が「推定」と印を付けていたものが中心です。

どのクセを残すかは、指定していません。この線引きを決めたのは、AIでした。

線引き自体には理由があります。毎回決まって起きる挙動はSwiftUIでも素直に再現できますが、Reactの描画タイミングやセルの使い回しから生まれる挙動は、SwiftUIには同じ仕組みがないので、わざと作り込まない限り起きません。

気になったのは、この線引きが型チェックの結果には一切出てこないことです。今回見えたのは、判断を報告させたのと、元の挙動リストと1項目ずつ突き合わせたからでした。

たとえば「同じ名前の項目が全部消える」は、ユーザーから見ればバグです。移植のついでに直すか、まず元と同じにしてから別に直すか。これは移植の技術ではなく、プロダクトの判断です。

Shopifyも、Shopアプリの移行を機に一部の画面を意図的に廃止し、ほかを簡素化したと書いています。Helixが各チェックポイントに人の承認を置いているのは、こういう判断のためだと、ぼくは読んでいます。

細部の判断は割れました（リストの行を必要な分だけ作るか全部作るか、遅れて届いた削除タイマーの扱いなど）。

58項目のリストにも漏れがありました。1回目の突き合わせ係だけが、リストの外で「文字サイズの設定（Dynamic Type）に追従しない」ことに気づいています。コード上は、2回とも文字の大きさを固定値で指定していて、iPhoneの設定で文字を大きくしても変わらない指定です。元のReact Nativeは、既定で設定に合わせて拡大します。

なお突き合わせ係どうしでも、同じ結果に「直した」「仕組みごと消えた」と別の名前を付けていました。上の「同じ10件・同じ5件」は、2つの結果を並べて、まとめ役のClaude Code本体がそろえ直した数字です。

この実験で、書く作業そのものは25〜32分で終わりました。確かめる側は、挙動リストづくり約25分と1回分の突き合わせ約26〜27分で、合わせて約50分。残ったのは、元と同じか確かめ、違いを残すか決める作業です。AIの作業時間だけで見ても、確かめる側のほうが長くかかっています。

この実験には限界があります。試したのは1画面を2回だけで、実機では動かしていません。挙動リスト係・移植係・突き合わせ係に加え、結果をまとめた本体も、すべて同じClaude（Opus 5）です。別の系統のモデルにも、人の手にも、まだ確かめさせていません。

判断の報告を求めたこと自体が、線引きを意識させた可能性もあります。Shopifyが問題にしている「300画面規模での保守しやすさ」も、この規模では確かめようがありません。

1画面・269行なら、コードを読んだ判定では、一発移植でも58項目中46〜48項目が元と同じでした。それでも、残りの10〜12項目（違いが出たものに加え、コードを読むだけでは判定できなかったものを含む）とリストの外の漏れを見つけて、どれを直すか決める仕事は残ります。Shopifyが一発移植をやめ、確かめる工程に投資した理由は、この小さな規模でも感じ取れました。

今日からできること

React Nativeを使っている人は、依存ライブラリの予定を確認する。 Shopify製の3つのOSSは扱いが分かれます。

・ライブラリ｜Shopifyの発表
・FlashList｜互換性を壊す重大な問題の修正は続ける。長期の引き継ぎ先を複数社と協議中
・React Native Skia｜2026年末までスポンサー継続。作者が新しい名前でフォークして開発を続ける
・Restyle｜アーカイブ予定。2026年末までは動く状態を保つ

9月11日時点で、3つともGitHub上ではまだアーカイブされていません。慌てて乗り換える段階ではなく、年内に方針を決めておけば間に合う段階だと、ぼくは見ています。

技術選定の「前提」を書き出す。 いま使っている技術を選んだ理由を3つ書き、そのうち「人が書く手間」「人が2回やる手間」に依存している理由に印をつけてみてください。印がついた理由は、Shopifyと同じく、AIで前提が動く可能性がある理由です。

AIに移植や書き直しを頼む前に、元の挙動のリストを別に作る。 移植させるAIとは別に、元のコードだけから挙動を書き出させておくと、あとで1項目ずつ照合できます。そのうえで「バグっぽい挙動は残すのか、直すのか」を先に決めて、指示に書いてください。残すか直すかを指定しないと、今回のように線引きをAIが決めます。判断したことを報告させる一文も入れておくと、その線引きが見えやすくなります。

これはコードに限りません。AIに資料やExcelの作り直しを頼むときも、「変えてほしくない動き」を先に書き出しておけば、できあがりを確かめる物差しになります。

おわりに

Shopifyの最大のアプリ（300画面超）は今年後半に出る予定です。出たら今回と同じく、発表された数字と検証の工程を分けて確かめます。一次ソースと実験による続報を読みたい方は、フォローしてもらえるとすぐ届きます。

コメントで、次にどれを試してほしいか教えてください。記号ひとつで十分です。

・A: 同じ画面をAndroid（Kotlin）にも移植して、iOS版とのズレを比べる
・B: Shopifyのように小さなチェックポイントに分けて移植し、一発移植と比べる
・C: もっと大きな画面（数百行以上）で同じ突き合わせをする

参考リンク（一次ソース）

Shopify Engineering「Native is now the future of mobile at Shopify」（2026-09-10）:
https://shopify.engineering/back-to-native

Shopify Engineering「Migrating Shop app from React Native to native」（2026-09-10）:
https://shopify.engineering/shop-app-migration

Shopify Engineering「Five years of React Native at Shopify」（2025-01-13）:
https://shopify.engineering/five-years-of-react-native-at-shopify

Shopify Engineering「React Native is the Future of Mobile at Shopify」（2020-01-29）:
https://shopify.engineering/react-native-future-mobile-shopify

Airbnb Engineering「Sunsetting React Native」（2018-06-19）:
https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a

実験に使った元コード（Shopify/flash-list の fixture/react-native/src/Reminders.tsx、MIT）:
https://github.com/Shopify/flash-list

Hacker News「Shopify is moving from React Native back to Swift and Kotlin」:
https://news.ycombinator.com/item?id=49643982

※Shopアプリの数値はShopifyの自己計測です。実験は筆者の手元での小規模な試行で、実機・シミュレータでの動作確認はしていません。

#shopify

#shopify