LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

React Nativeの新アーキテクチャとは — Bridge廃止からJSI・TurboModules・Fabricへ

React Native新アーキテクチャへの移行外注とは、既存のReact NativeアプリをBridge（非同期メッセージキュー）ベースの旧構造から、JSI（JavaScript Interface）を基盤とした新しいアーキテクチャへ書き換える作業を、専門知識を持つ外部パートナーに委託する取り組みです。

React Native公式によると、新アーキテクチャの中心にあるのはJSI（JavaScript Interface）です^*1。旧アーキテクチャではJavaScriptとネイティブ層の通信にBridgeと呼ばれる非同期メッセージキューを使っていました。Bridgeは通信のたびにシリアライズ・デシリアライズが発生するため、頻繁なネイティブ呼び出しを行う画面でパフォーマンスが低下しやすい構造でした。

新アーキテクチャではBridgeを廃止し、JSIを介してJavaScriptからC++のネイティブ関数を直接呼び出せるようになりました。これによって通信のオーバーヘッドが減り、JavaScriptとネイティブ層の同期処理も可能になっています。

TurboModules — 新しいネイティブモジュール方式

TurboModulesは、JSIを基盤とした新しいネイティブモジュールの仕組みです^*1。旧アーキテクチャのNative Modulesがアプリ起動時に全モジュールを初期化していたのに対し、TurboModulesは必要なモジュールのみを遅延ロードします。起動時間の短縮と、使わないモジュールのメモリ消費削減が期待できます。

既存のネイティブモジュールをTurboModules対応に書き換えるには、TypeScriptによる型定義（Codegen）とiOS/Android側のネイティブコード修正が必要です。独自のネイティブモジュールを多数持つアプリでは、この書き換え作業が移行コストの中心となります。

Fabric — 新しいレンダラ

FabricはReact Nativeの新しいUIレンダラです^*1。旧レンダラはJavaScriptスレッドとUIスレッドを非同期で橋渡しする構造でしたが、FabricはC++で実装されたコアを持ち、UIの更新をJavaScriptと同期できるようになりました。スクロール中のアニメーション滑らかさや、ネイティブコンポーネントとReact Nativeビューの組み合わせ時の描画精度向上が見込まれます。

Hermes — デフォルトのJSエンジン

React Native公式はJavaScriptエンジンとしてHermesをデフォルトで採用しています^*1。HermesはReact Native向けに最適化された軽量エンジンで、アプリの起動時間短縮とメモリ使用量の削減に寄与します。新アーキテクチャはHermesと組み合わせることで性能面のメリットをより大きく引き出せます。

なぜ今移行が必要か — デフォルト化・エコシステム対応・サポート動向

React Native公式によると、0.76リリースで新アーキテクチャがデフォルトとなり、0.80系でさらに安定度が増しています^*1。最新の対応状況はReact Native公式サイト（reactnative.dev）でご確認ください。この変化により、移行は将来対応ではなく現在進行中の実務課題となっています。

バージョンアップを続けるには移行が前提

新アーキテクチャがデフォルト化されたことで、React Nativeのバージョンアップを追い続けるうえで旧アーキテクチャのままでは非互換が生じるリスクが高まっています。将来的なOSアップデート対応やセキュリティパッチ適用のためにも、新アーキテクチャへの移行は避けられない対応です。

エコシステムの対応が進んでいる

React Nativeの主要なライブラリやコミュニティも新アーキテクチャへの対応を進めています。新アーキテクチャ対応済みのライブラリが増えるほど、移行後の開発体験が向上します。反対に対応を先送りすると、旧アーキテクチャに依存したライブラリを使い続けるリスクが蓄積します。

新規機能開発への影響

Fabricが提供するConcurrent Mode（Reactの並行レンダリング）との統合や、新しいReact機能（Suspenseなど）を活用するためにも新アーキテクチャが前提となります。新アーキテクチャへの移行は、現在の技術的負債を解消しながら将来の機能拡張の基盤を整える作業でもあります。

移行を外注で進める5つのフェーズ

既存のReact Nativeアプリを新アーキテクチャに移行するにあたっては、段階的なアプローチが推奨されています^*1。外注で進める場合の標準的な5フェーズを整理します。

フェーズ1：現状調査 — 移行コストの見積もり

まず現状アプリのReact Nativeバージョン、使用している依存ライブラリの一覧とバージョン、独自ネイティブモジュール・カスタムネイティブコンポーネントの有無を確認します。この調査結果が移行コスト全体の見積もり根拠となるため、発注前にある程度の情報整理を行っておくか、初期フェーズとして調査を委託することが大切です。

独自ネイティブモジュールが多いほど移行コストは増加します。ネイティブモジュールが少なくサードパーティのライブラリのみで構成されているアプリは比較的移行しやすく、独自モジュールが多いアプリは移行の難易度が上がります。

フェーズ2：依存ライブラリの棚卸しと対応方針の決定

使用しているすべてのライブラリについて、新アーキテクチャへの対応状況を確認します。React Native Directory（reactnative.directory）では、ライブラリごとの新アーキテクチャ対応状況を確認できます^*2。対応済み・対応予定・未対応・メンテナンス停止の4分類で整理し、未対応ライブラリには「対応版の採用待ち」「代替ライブラリへの切り替え」「独自ラッパーの実装」のいずれかの対応方針を決めます。

この棚卸し作業は移行のスコープと工数の確定に直結します。ライブラリ数が多いアプリでは、外注先に依頼する際に調査対象の優先順位付けを事前に行っておくと効率的です。

フェーズ3：ネイティブモジュール・コンポーネントのTurboModules/Fabric対応

独自のネイティブモジュールをTurboModules方式に書き換えます。TypeScriptによるCodegenの型定義ファイルを用意し、iOS（Objective-C/Swift）とAndroid（Java/Kotlin）のネイティブ実装をJSIに対応した形式に変更します。カスタムネイティブコンポーネントはFabric対応のViewManager実装に書き換えます。

ネイティブ実装の変更はiOSとAndroidの両方が必要です。ReactとJavaScriptの知識だけでは対応できないため、ネイティブ開発の経験を持つエンジニアが必要な工程です。内製チームにネイティブ開発のリソースがない場合は、この工程を外注に委ねることがリスク軽減につながります。

フェーズ4：段階的な有効化と動作検証

React Native公式は新アーキテクチャへの移行を段階的に進めることを推奨しています^*1。アプリ全体を一度に切り替えるのではなく、画面単位・モジュール単位で新アーキテクチャを有効化しながら動作を確認します。Hermesエンジンの有効化から始め、TurboModulesとFabricを順に有効化する流れが一般的です。

この段階では、UIの描画タイミングや非同期処理の挙動が旧アーキテクチャと異なる箇所が見つかることがあります。主要な画面とユーザーフローを対象とした実機テストが欠かせません。

フェーズ5：回帰テスト・QA・リリース

新アーキテクチャへの移行後、全機能・全画面を対象にした回帰テストを行います。特にネイティブモジュールを使う機能、アニメーション・スクロール処理、非同期処理を含む画面は重点的に確認が必要です。自動テスト（Detox等のE2Eフレームワーク）が整備されていれば確認工数を抑えられます。テストを経て問題がないことを確認してからリリースに進みます。

移行の難所と注意点 — 未対応ライブラリ・独自モジュール・回帰テスト

React Native新アーキテクチャへの移行には、一般的なバージョンアップ対応とは異なる固有の難しさがあります。よくつまずくポイントを3点に整理します。

難所1：未対応ライブラリがブロッカーになる

移行の際にすべての依存ライブラリが新アーキテクチャに対応済みとは限りません。移行に取り掛かった後で未対応ライブラリが見つかると、そのライブラリの代替を探すか、独自でラッパーを実装するかの判断が必要になります。代替ライブラリへの切り替えはAPIや挙動が変わるため、呼び出し元コードの修正が連鎖することもあります。

この問題を防ぐには、フェーズ2の依存ライブラリ棚卸しを移行着手前に完了させることが重要です。棚卸し結果によっては移行計画そのものを再検討する必要が生じるため、調査を後回しにするとスケジュールのずれが大きくなります。

難所2：独自ネイティブモジュールの書き換えはiOS/Android両方が必要

独自のNative Modulesをそのまま移行しようとすると、TurboModulesの仕様に合わせてTypeScriptの型定義（Codegenの仕組み）を追加し、iOSとAndroid双方のネイティブ実装を書き換える作業が発生します。これはReactの知識だけでは対応できず、Swift/Objective-CとJava/Kotlinの両方の知識が必要です。

独自モジュールの書き換えを誤ると、特定の機能が動作しなくなる障害に直結します。内製チームにネイティブ実装の経験がない場合、この工程を外注に任せることでリスクを抑えられます。

難所3：回帰テストのカバレッジ確保

Fabricへの移行はレンダリングエンジン自体が変わるため、旧アーキテクチャでは問題なかったUIの描画タイミングや状態管理の挙動が変化することがあります。自動テストが少ないアプリでは、変更後の全画面・全機能を手動で確認する工数が膨らみます。

移行作業と並行してE2Eテスト（Detox等）を整備しておくと、移行後の品質確認を効率化できます。回帰テストのカバレッジが不十分なままリリースすると、本番環境で予期しない動作が発生するリスクがあります。

外注の使いどころ — 調査・実装・検証の委託判断軸

React Native新アーキテクチャへの移行を外注で進める場合、どの工程を委託するかの判断が費用対効果に直結します。内製チームのスキルセットと移行の難所を照らし合わせて、委託スコープを決めることが大切です。

外注が効果的な工程：ネイティブモジュール実装

TurboModules/Fabric対応の実装は、React Native・iOS・Androidの三つの技術領域にまたがる作業です。内製チームがJavaScript/Reactのみでネイティブコードのスキルがない場合、この工程を外注に委ねることでリスクを大きく下げられます。

移行実装を誤るとアプリ全体のクラッシュや特定機能の停止につながるため、実績のある外部パートナーへの委託は品質確保の手段として有効です。

外注が効果的な工程：初期調査・現状把握

移行コストの見積もりに必要な現状調査（依存ライブラリの棚卸し・独自モジュールの洗い出し・移行可否の判断）を外注として切り出す方法があります。調査結果を踏まえて社内で移行のGo/No-Go判断を行い、移行実装に進む場合は改めて委託範囲を決める流れです。

調査フェーズは要件が不確定なため、準委任（SES）形態で柔軟に進める選択肢が向いています。調査完了後に作業スコープが固まれば、実装フェーズは請負（固定スコープ）での委託も選べます。

外注が効果的な工程：回帰テスト・QA支援

移行後の回帰テストは、Detox等のE2Eテストフレームワークの知識とモバイルアプリのQAノウハウが必要です。テスト計画の設計から実機での検証実施まで外注に委ねることで、内製チームは通常の機能開発業務と並行して移行を進めやすくなります。

委託先を選ぶ3つの確認ポイント

• React Native経験とネイティブ実装の両立：TurboModules/Fabric対応にはiOS（Swift/Objective-C）とAndroid（Kotlin/Java）のネイティブ実装経験が必須です。React Nativeのみでネイティブ実装の実績がない会社では対応が困難です。
• 新アーキテクチャ対応の実績：実際に新アーキテクチャへの移行を手がけたプロジェクト実績があるかを確認します。提案書や技術ヒアリングでCodegen・JSIへの言及があるかどうかが指標になります。
• 移行後の継続保守体制：移行フェーズが終わった後も、React Nativeのバージョンアップ追従やOSアップデート対応を継続的にサポートできる体制を持つ会社を選ぶと、リリース後のリスクを抑えられます。

依頼前の技術ヒアリングでは「独自ネイティブモジュールをTurboModules対応に書き換えた経験があるか」「移行中に未対応ライブラリが見つかった場合の対処方針はどうするか」を具体的に確認することで、技術力と問題解決力を見極めやすくなります。

まとめ：React Native新アーキテクチャ移行外注で押さえる3つの判断軸

本稿では、React Native新アーキテクチャ（JSI/TurboModules/Fabric）への移行を外注で進める際の仕組み・フェーズ・難所・委託判断軸を整理しました。要点を3点に集約します。

第一に、移行の難易度は依存ライブラリの対応状況と独自ネイティブモジュールの数で決まります。着手前に現状調査と棚卸しを完了させ、ブロッカーを早期特定することが計画の精度を高めます。

第二に、TurboModules/Fabric対応の実装はReact Native・iOS・Androidの三領域にまたがるため、内製チームにネイティブ実装のスキルがない場合は外注に委ねることがリスク軽減につながります。

第三に、委託先を選ぶ際はReact Native経験だけでなくネイティブ実装の実績と新アーキテクチャ対応経験を確認し、移行後の継続保守まで対応できる体制があるかを確かめることが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：React Native「The New Architecture」（https://reactnative.dev/docs/the-new-architecture/landing-page）— React Native公式による新アーキテクチャ（JSI・TurboModules・Fabric・Hermes）の概要・移行ガイド
2. *2　出典：React Native Directory「reactnative.directory」（https://reactnative.directory/）— ライブラリごとの新アーキテクチャ対応状況を確認できるコミュニティ公式ディレクトリ

Tweet