LASSIC Media らしくメディア

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

React NativeのOTA動的更新とは

React NativeのOTA（Over-The-Air）動的更新とは、アプリのJSバンドルや画像などのアセットを、App StoreやGoogle Playの審査プロセスを経ずにサーバーから配信し、ユーザーの手元で反映させる仕組みを指す^*1。ネイティブのアプリバイナリは変更せず、JavaScriptレイヤーだけを差し替える点が特徴です。

OTA動的更新の対象は、JavaScriptコードとスタイリング・画像などの非ネイティブ資産に限られます^*2。ユーザーは次回のアプリ起動時に新しいバンドルを受け取り、ストアでのアップデート操作は不要です。バグ修正や軽微な機能変更を、通常のストア審査より短いリードタイムで届けられる点が事業側の主なメリットになります。

一方で「動的更新」という言葉から、ネイティブモジュールの追加やアプリ権限の変更まで含めてOTA配信できると誤解されるケースが見られます。この誤解が後の審査リジェクトや配信事故につながるため、対象範囲を正確に理解した上で導入設計を進める必要があります。

CodePush終了の経緯と選ぶべき後継サービス

Microsoft Visual Studio App Centerは2025年3月31日に提供終了となりました^*3。この終了に伴い、App Center上で提供されていたCodePushサービスも同時に利用できなくなっています。Microsoft公式の移行ガイドでは、CodePush機能の後継として2つの選択肢が示されています^*3。

第一の選択肢は、Microsoftが提供する独立版CodePush（GitHubリポジトリで公開されているセルフホスト版のサーバー実装）を自社基盤に組み込み、App Centerに依存せず運用を継続する手立てです^*3。第二の選択肢は、CodePushからExpoのEAS Updateへ移行する道です^*3。Microsoft公式の移行ガイド自体が、EAS Updateへの移行を代替案の一つとして案内している点は、選定時に押さえておくべき事実です。

自社基盤でのセルフホスト運用は、サーバーの保守・監視・セキュリティ対応まで自社（または委託先）が担う前提になります。EAS Updateはクラウドサービスとして提供されるため^*4、インフラ運用の負担を避けたいチームとの相性が良い一方、Expoのビルドパイプライン（EAS Build）との組み合わせが前提になりやすい点は理解しておく必要があります。

EAS Updateの仕組み — チャネル・ランタイムバージョン

EAS Updateは、expo-updatesライブラリを利用するプロジェクト向けに更新を配信するクラウドサービスです^*4。ビルドに含まれるネイティブ部分は変更せず、JSバンドルやアセットといった「アップデートレイヤー」だけを配信対象にする構造を取ります^*5。

運用の中心になる概念が「チャネル（update channel）」です。チャネルは更新の配信先環境を識別する名前で、本番用・検証用のビルドをそれぞれ別チャネルに紐づけて管理します^*6。たとえばproduction・staging・previewのようにチャネルを分け、eas.json内のビルドプロファイルごとに対応するチャネル名を設定するのが基本形です^*6。ここで注意したいのは、各バイナリは常に単一のチャネルを指す仕様になっており、ビルド後にチャネルを動的に切り替えることはできない点です^*6。

もう一つの重要な概念が「ランタイムバージョン」です。ランタイムバージョンは、ビルドに含まれるネイティブコードと配信する更新の互換性を保証するためのプロパティです^*7。ネイティブコードを変更した場合は新しいビルドが必要になり、ランタイムバージョンの管理方法には、変更を検知して自動的に値を更新する運用と、開発者が明示的に指定する運用の2つがあります^*7。同一ランタイムバージョンのまま存在しないネイティブコードを前提にした更新を配信すると、実行時エラーにつながる恐れがあるため、この管理を誤らないことが安定運用の前提になります。

段階的ロールアウトとロールバックの実務

EAS Updateは、新しい更新を全ユーザーへ一度に配信せず、割合を指定して段階的に拡大する仕組みを備えています^*8。コマンド実行時に配信割合を指定するオプションを付けることで、たとえば全ユーザーの10%にのみ最初の配信を行い、問題がないことを確認しながら割合を広げていく運用が可能です^*8。

段階的ロールアウトには制約もあります。同一のブランチ上で同時に進行できるロールアウトは1件のみと定められており^*8、進行中に別の更新を並行して展開することはできません。ロールアウトの状態は専用コマンドで確認でき、全ユーザーへの配信まで進めて完了させるか、途中で前の状態に戻すかを選べる仕組みです^*8。

配信後に不具合が判明した場合に備えるのがロールバック機能です。ロールバックは、以前に公開した更新へ戻すための専用コマンドで実行します^*9。ここで実務上重要なのは、ロールバックの内部動作が「古いバンドルを新しい更新として再公開する」形になっている点です。すでに問題のある更新をキャッシュ済みの端末は、ロールバックを実行しただけでは自動的に古い状態へ戻らず、再公開された更新を新たに受信する必要があります^*9。この挙動を理解せずに運用すると、ロールバックしたはずが一部端末で不具合が残る事態になりかねません。

OTAでは配信できない変更 — ネイティブコードの壁

OTA動的更新には明確な適用範囲があります。ネイティブコードそのものの変更、カメラや位置情報などのアプリ権限の変更、Expo SDKバージョンの更新、そして新しいアプリバイナリの申請を要する変更は、いずれもOTA配信の対象外です^*5。これらの変更が必要な場合は、EAS Buildなどで新しいバイナリを作成し、通常のストア審査プロセスを経る必要があります^*5。

ネイティブライブラリを追加・更新する開発では、ランタイムバージョンの不一致に起因する実行時エラーが典型的な失敗パターンです。ネイティブ変更を行ったにもかかわらずランタイムバージョンを更新しないまま同一チャネルへOTA更新を配信すると、旧バイナリ上で存在しないコードを呼び出す状態になり、アプリ側のエラー回復処理が作動する可能性があります^*7。このリスクを避けるには、ネイティブ変更の有無を検知してランタイムバージョンを自動管理する仕組みを、CI/CDパイプラインに組み込む設計が実務上の対策になります。

OTA更新の適用範囲を正確に切り分けられず、本来ストア審査が必要な変更を無理にOTAで配信しようとする設計ミスは、後述するストア規約違反のリスクにも直結します。導入初期の設計段階で、どの変更がOTA対象でどの変更がバイナリ更新対象かを明文化しておくことが欠かせません。

ストア規約上の留意点

OTA動的更新を導入する際は、Apple App Store Review Guidelinesの規定も踏まえる必要があります。ガイドライン2.5.2では、アプリはバンドル内で自己完結していなければならず、アプリの機能を変更・追加するコードをダウンロード・インストール・実行してはならないと定められています^*10。教育目的のアプリなど限定的な例外はありますが、一般的な商用アプリには適用されません^*10。

この規定と、JavaScriptコードを配信するOTA更新の関係は、開発者の間でも解釈が分かれてきた論点です。実務上の整理としては、既存機能のバグ修正やUI調整の範囲に留め、レビュー時に申請した内容から外れる新機能の追加やアプリの目的そのものを変える改変をOTAで配信しないことが、規約に抵触しない運用の目安とされています。判断に迷う変更は、OTA配信ではなく通常のバイナリ更新として申請する方が無難です。

Google Playにも同様にコードの完全性に関するポリシーが存在するため、両ストアの規約を継続的に確認しながら運用する体制が必要になります。規約の解釈や運用範囲の線引きは、ストア審査の傾向を継続的に追っている委託先の知見が生きる領域と言えます。

外注と内製の判断軸

OTA動的更新の導入・運用を内製する場合、チャネル設計・ランタイムバージョン管理・CI/CD連携・段階配信の監視体制まで、複数領域の知識が必要になります。CodePushからの移行作業も加わる場合は、既存の配信ロジックの棚卸しと新サービスへの設定移行が追加の工数として発生します。

必要スキルを具体的に見ると、EAS Updateの設定・運用にはExpo/EAS Buildの利用経験、CI/CDパイプラインの構築経験、ネイティブビルドとJSバンドルの互換性管理の理解が求められます。これらを兼ね備えた人材を確保できない場合、設計を誤ったまま本番配信を始めてしまうリスクがあります。

専門パートナーに依頼した場合との違いは、移行方針の設計段階で表れます。CodePushの利用状況を棚卸しし、セルフホスト継続かEAS Update移行かを技術的な制約とコストの両面から判定した上で、チャネル構成・ロールアウト運用・監視体制まで一括して設計できるかどうかが、内製との差になります。ストア規約の解釈やランタイムバージョン管理のような、事故が起きた後に気づきやすい落とし穴を、導入前に潰せる点も委託の価値です。

導入を外注する際の進め方

React Native OTA動的更新の導入を外注する際は、まず現状のOTA配信基盤（CodePush利用状況を含む）を棚卸しし、移行が必要な範囲を特定する調査フェーズから始めるのが実務的な進め方です。次に、EAS Updateなどの後継サービスを前提としたチャネル構成とランタイムバージョン管理方針を設計し、CI/CDパイプラインへの組み込みを実装します。

導入後は、段階的ロールアウトの運用ルール（初回配信割合・拡大タイミング・ロールバック判断基準）を運用手順として文書化し、実際の配信を通じて検証する工程が続きます。ここまでを一括して任せられる委託先であれば、CodePush終了という制約下でも配信の停止期間を最小限に抑えて移行を進められます。

まとめ：React Native OTA動的更新導入で押さえる3つの判断軸

本稿では、React NativeのOTA動的更新をCodePush終了後に外注で導入する際の要点を整理した。要点を3つに集約すると次の通りである。第一に、CodePushはApp Center本体の終了に伴い利用できなくなり、セルフホスト継続かEAS Update移行かの選定が最初の判断になる。第二に、チャネル・ランタイムバージョン・段階的ロールアウト・ロールバックの仕組みを正確に理解し、運用ルールとして落とし込む必要がある。第三に、OTA配信の対象外となるネイティブコード変更やストア規約上の線引きを誤ると、配信事故や審査リジェクトにつながるため、実務経験のある委託先の知見を活用する価値がある。

よくある質問

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

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

1. *1　出典：Expo「EAS Update」docs.expo.dev/eas-update/introduction/
2. *2　出典：Expo「EAS Update」docs.expo.dev/eas-update/introduction/
3. *3　出典：Microsoft Learn「Visual Studio App Center Retirement」learn.microsoft.com/en-us/appcenter/retirement
4. *4　出典：Expo「EAS Update」docs.expo.dev/eas-update/introduction/
5. *5　出典：Expo「EAS Update」docs.expo.dev/eas-update/introduction/
6. *6　出典：Expo「Create a deployment for updates」docs.expo.dev/eas-update/deployment/
7. *7　出典：Expo「Runtime versions」docs.expo.dev/eas-update/runtime-versions/
8. *8　出典：Expo「Rollouts」docs.expo.dev/eas-update/rollouts/
9. *9　出典：Expo「Rollbacks」docs.expo.dev/eas-update/rollbacks/
10. *10　出典：Apple Developer「App Review Guidelines」2.5.2developer.apple.com/app-store/review/guidelines/

Tweet