Shopifyがネイティブ回帰 費用構造変化の教訓

2026年9月、Shopify Engineeringはモバイル開発の将来方針を示す記事を公開した。表題は次の通りである。

Native is now the future of mobile at Shopify

同社は2020年にモバイル開発をReact Nativeへ寄せる方針を打ち出した。外部の開発共同体への投資も続けてきた。その同社がSwiftとKotlinによる自前開発へ戻ると表明した。業界への波及は大きい。

Zenn の Nkzn の報道では、この動きを「React Nativeの失敗」と受け止める見方への注意が示された。Shopify自身は過去の選択を否定していない。費用構造の変化が判断を動かしたという整理である。本稿ではその論点を掘り下げる。

Shopify Engineeringの公式ブログでは、開発体制の変遷と現状の判断が説明されている。単なる枠組みの優劣ではない。実装費と維持費の所在が論点である。

Shopifyが示した開発方針転換

Shopifyは2020年当時、iOSとAndroidで同一機能を二重に実装していた。仕様の同期にも時間を要した。Webを主戦場とする技術者が参画しにくい課題もあった。

React Nativeの採用は、この重複を減らす手段だった。一度の実装で両方式に対応できる。Web技術の知見を転用できる。開発速度の向上が見込めた。

2026年の記事は、その前提が変わったことを示した。符号の自動生成と審査基盤が整備された。自前開発を二系統維持する負担が相対的に下がった。一方で枠組み利用に伴う負担は残った。比較の結果が逆転したのである。

この転換は、特定技術の断罪ではない。条件が変われば結論も変わるという事例である。技術選定は静的な正解探しではない。費用の所在を見直す作業である。

React Native選択は当時正しい判断

Zenn の Nkzn の報道では、2020年の選択は当時として正しかったと整理されている。Shopifyも同様の振り返りを示している。過去の判断を覆す話ではない。

当時の利点は明確だった。二重実装の削減である。機能追加の到達速度が上がった。Web担当者の参加余地が広がった。組織全体の生産性に寄与した。

同時に負担も存在した。枠組み自体の更新対応である。自前層との境界管理である。外部蔵書への依存である。性能面の調整である。これらは当初から認識されていた。

それでも二系統開発の削減効果が上回った。だから採用されたのである。判断基準は一貫している。得られる削減と支払う負担の比較である。2020年と2026年で数式の項が変わったに過ぎない。

天秤を動かした符号化支援の台頭

変化の中心はコーディングエージェントの実用化である。Shopifyは開発工程へ深く組み込んだ。片方の実装を参照して他方を生成する。試験と審査で挙動をそろえる。視覚的な確認も組み合わせる。

自前開発二本の費用が消えたわけではない。負担は依然として残る。しかし2020年時点よりは低い。生成の手間が下がった。雛形の作成が速くなった。反復作業の自動化が進んだ。

一方でReact Native側の費用は残存した。枠組みの追従は続く。境界問題の調査は残る。外部依存の管理も残る。性能調整の必要も消えない。片側だけが軽くなったため、天秤が傾いた。

重要なのは、道具の導入だけで効果が出たのではない点である。Shopifyは基盤に投資した。検査点の設定である。自動試験の整備である。複数系統の符号審査である。人間による承認である。運用全体の設計が前提にある。

実装費と同期費と品質保証の構造

自前開発二本の負担は符号の重複だけではない。仕様変更の反映が二重になる。挙動の一致確認が必要になる。欠陥修正の同期も求められる。運用面の負担も増える。

例えば操作方法が方式ごとに異なる場合を考える。案内文書を別々に用意する。支援担当への教育も二重になる。利用者からの問い合わせ対応も複雑になる。符号以外の費用が積み上がる。

共通符号化は実装費を下げる。同一の業務 logic を一度だけ書く。重複の削減効果は分かりやすい。自動生成の得意領域とも重なる。片方の実装から他方を作れるようになれば、相対的な利点は縮む。

同期費の削減効果も大きい。二つの符号基盤があれば一致維持が必要になる。片方だけ修正漏れが生じる。解釈のずれも起こり得る。共通化した範囲ではこの危険が減る。品質保証費への波及もある。共通の業務 logic が同一に動くなら、試験の重点配分がしやすくなる。方式固有の領域へ資源を寄せられる。品質管理の偏りが利用者不信を招く構図は、中古プラットフォームの品質管理格差、若者の合理的消費に潜むリスクで取り上げられた事例と重なる部分がある。試験設計の重要性は分野を問わない。

抽象化の境界に残る対応負担の実態

共通化ですべてが解決するわけではない。自前APIへの対応は残る。OS更新への追従も残る。枠組み自体の更新作業が新たに加わる。境界からの漏れも起こる。

漏れが生じれば低層の調査が必要になる。SwiftやKotlinの世界へ降りる作業である。端末差の確認も残る。寿命周期や画面表示の差異もある。片方の試験だけで済ませることはできない。

言語と基盤を一体で整える動きは、Modularプラットフォーム公開、Mojo言語とMAXフレームワークの統合構想が示す方向性と共通する問題意識がある。抽象層の効率と低層の制御性の均衡が問われる。低層への降下を前提に言語を選ぶ視点は、ZigでGBAゲーム開発、レトロ組込みに最適な理由における評価とも通じる。境界の費用を見積もる姿勢が重要である。

費用は消滅しない。支払う場所が移るだけである。この理解が選定の出発点になる。共有率だけを見ても実態は見えない。更新、依存、調査、試験を含めて比較する必要がある。

開発基盤への投資が前提条件となる

Shopifyの事例を自組織へ直接適用はできない。基盤投資の有無が条件を分ける。自動生成、試験、審査、承認の連鎖が必要になる。単体の道具導入では同期費は下がらない。

二系統維持の費用を下げるには体制が要る。検査点の設計である。視覚審査の導入である。複数系統による審査である。運用規則の整備である。これらへの投資なしに転換は難しい。

中小規模の組織では事情が異なる。人員に限りがある。試験資源も限られる。共通符号による削減が依然として有効な場合が多い。方式固有の作り込みが少ない製品では利点が残る。逆に高度な端末連携が多い製品では負担が増す。製品特性による見極めが要る。

技術は道具である。有用なら使えばよい。割に合わなくなればやめればよい。その判断には費用構造の把握が欠かせない。Shopifyの記事は、その思考法を示す教材と評価できる。

編集部の見解

今後3〜6か月では、共通化継続の是非を再点検する組織が増えると見る。特に自動生成を導入済みの組織では、二重実装の実測費を算定する動きが進むと見る。枠組み更新費と人材構成を比較する検討が定例化すると評価する。

1〜3年では、共通化の単位が画面全体から検証 logic や設計基盤へ移ると見る。言語間の変換精度が上がっても、保守責任の所在は残ると評価する。利用者体験の均一性と運用費の均衡を設計する能力が競争力になると見る。

編集部としては、同期費を誰が負担するのかという論点が問われていると考える。機械生成の符号が増えるほど、審査と試験の設計が重要になるのではないだろうか。削減した実装費を基盤投資へ振り向けられるかが分岐点になるのではないだろうか。

参考

• 「クロスプラットフォーム開発が解決するコスト、解決しないコスト」, by Nkzn — Zenn, 2026-09-12T14:05:10.000Z (ARR)
• 元記事URL: https://zenn.dev/nkzn/articles/cross-platform-development-costs-2026