6年前の正しい選定を
AIを理由に捨てました

過去の技術選定を見直すか迷っている方へ

数年前に決めた開発の方針が今も正しいのか、AIの進化を前に判断しかねている方に向けて書いています。

大きな会社が方針を変えたという話ではありません。どの前提が崩れたら決め直すのか、そして決め直したあと何で品質を担保するのかという話です。今回の公表は、その両方が書かれています。

何が公表されたのか

React Nativeとは、ひとつのコードからiPhone用とAndroid用のアプリを作る仕組みです。同じ機能を二度作らずに済むことが最大の利点で、その代わりに各プラットフォーム固有の機能へは層をひとつ挟んで触れることになります。

Shopifyは2026年9月10日、モバイルアプリをReact NativeからSwiftとKotlinへ戻すと公表しました。同社は2020年に全面移行を決め、2025年1月の時点でも投資を続けると書いていた会社です。

公表された内容を並べます。

「React Nativeは今も優れた枠組みだ」と本文に書かれています。撤退の理由は品質でも性能でもありません。

崩れたのは前提のひとつです

2020年の判断には3つの理由がありました。同じ機能を二度作らない、開発者が領域をまたいで働ける、機能の差を埋める時間を減らす。

このうち一つ目だけが、AIによって変わりました。本文の言い方では、エージェントはiOS版を参照してAndroid版を実装でき、その逆もできる。仕様とテストとレビューの節目を共有することで、二つのプラットフォームの差を埋める費用が大きく下がった。

残り二つは消えていません。二つのプラットフォームで作り、保守する費用そのものは無くなっていないとも明記されています。変わったのは、その費用が決め手ではなくなったことです。

「一度で作り直させる」は失敗します

ここからが実務の話です。本文には、やってみて駄目だった方法がはっきり書かれています。

LLMに既存のコードを指して同じ機能を一度で作らせようとしても、うまくいかない。前もって情報を集めさせ、仕様書と作業ファイルに凍結してから実装させても、出荷できない保守不能なコードが大量に出てくる。

この記述は、AIで速く書けた後に判断が上流へ移るという話と同じ地点を、別の角度から言っています。仕様を先に固める方式そのものが効かないのではなく、固めた仕様を一気に実装させる形が効かないという指摘です。

通過条件を積み上げる仕組み

同社はHelixという仕組みを作りました。開発者が画面を指定すると、既存コードを読んで、数分で確認できる小さな工程の列を提案します。そして工程ごとに、次の全部を通らないと先へ進めません。

• テストで挙動を証明する
• 動作中のアプリと見た目を突き合わせる
• 2つの敵対的なコードレビューを通る
• 人がうなずく

4つ目が最後に来ています。自動の検査を3つ重ねたうえで、人の承認を外していない。しかも各レビューの指摘は記憶され、移行が進むほど自律的に回るようになる、と書かれています。

私たちが承認の仕組みは実装で確かめると書いてきた話の、良い実例です。承認があると謳うだけでなく、通らなければ次の工程が始まらない構造になっています。

速く試せないと、モデルの良さは効きません

もうひとつ実務的な指摘があります。エージェントはコードを数秒で変えられるのに、スマートフォンの模擬環境での確認に数分かかる。これが最大の詰まりでした。

そこで業務ロジックを画面から完全に切り離し、机上のパソコンで画面なしに動かせるようにしました。エージェントは専用のコマンドから状態を調べ、画面を移動し、操作を実行します。数分だった反復が数ミリ秒になりました。

どれだけモデルが良くても、自分の仕事を速く検証できなければ意味がないと本文は書いています。AIを前提にするとは、モデルを選ぶことではなく、検証を速くする設計に作り替えることだという主張です。

公開ライブラリの畳み方も書いてあります

方針転換の公表で見落とされやすいのが、周囲への影響です。同社はReact Native向けに公開してきたライブラリの扱いを個別に明示しました。

自社の都合で方針を変えるとき、依存している相手に何をいつまで保証するかを先に書く。受託開発でも、使っていた枠組みを変えるときに同じ整理が要ります。移行の検収でテストの分母をどちら側に置くかと同じで、境界を先に決めておくと後で揉めません。

自社に置き換えるとどうなるか

この事例をそのまま真似する話ではありません。Shopifyには数百人規模の開発者と、2021年からLLMを使ってきた蓄積があります。

同じ発表に載る2種類の数字を分けて読む必要があるのと同じで、事例は自社の条件に置き換えてから使います。発注側が持ち帰れるのは、見直しを始める条件のほうです。技術選定をやり直す理由は「前の判断が間違っていた」ではなく、「決め手だった前提が変わった」。この形で書けないなら、まだ見直す時期ではありません。

そして作り直すと決めたなら、AIに任せる範囲より先に、通過条件をどこに置くかを決めます。AIが読んでいない範囲を報告しない以上、人が確かめる場所を工程の中に固定しないと、出来上がってから気づくことになります。

数字の出どころと限界

この記事の内容は、Shopifyが2026年9月10日に公開した技術ブログ「Native is now the future of mobile at Shopify」に基づきます。2020年の移行理由3点、コーディングエージェントによる前提の変化、作り直しを選んだ判断、Shopアプリの12週間、Shopifyアプリの300以上の画面と年内出荷、Helixの通過条件、業務ロジックを画面から切り離した経緯、3つのライブラリの扱いは、すべて同記事の記載です。

移行にかかった総工数、関わった人数、費用、移行後の不具合率は公開されていません。12週間はShopアプリ1本の実績で、他のアプリで同じ期間になる根拠は示されていません。この記事の5つの確認項目は、公開された判断の順序から発注側の論点として整理したもので、同社が示した手順ではありません。

技術の選定そのものについてはエージェント基盤を選ぶ4つの基準に、仕様を先に固める開発の見方は予測可能性の回に書いています。自社の開発方針をAI前提で見直すご相談は、お問い合わせからお送りください。