OTAアップデートを軽量で高速に保つ方法

Product • Development • React Native • 2026年4月14日 • 12分で読める

Jacob Clausen Engineering

より小さなバンドル、スマートなロールアウト、実践的な最適化テクニックでReact Nativeユーザーへのより高速なOTAアップデートを配信しましょう。

PRをマージしてから数分以内に重大な修正を全ユーザーベースに配信したことはありますか？修正から直接ユーザーの手元へ、官僚的な手続きもなく、ユーザー体験の中断もない、まさに高速道路のような流れです。その感覚は何度経験しても素晴らしいものです。

EAS Updateはこれを可能にし、一度経験すると、それなしで仕事をすることは想像しがたくなります。しかし、修正を公開することはストーリーの半分に過ぎません。ユーザーがそれをデバイスで実行するまで、ユーザーは利益を得られません。ダウンロードが完了するのが早いほど、修正がユーザーの手に渡るのも早くなります。アップデートが軽量であるほど、すべての人の体験が向上します。

ダウンロード速度の向上、コストの削減、チームとユーザーベースが成長する中でのスムーズな運用。このガイドでは、アップデートを小さく保ち、自信を持って配信し、すべてのプッシュから最大限の価値を得る方法を説明します。

EAS Updateの価格設定の概要

EAS Updateを最大限に活用するには、アップデートの配信方法と課金方法を形作る2つの概念を理解することが役立ちます：月間アクティブユーザー（MAU）と帯域幅です。これらがどのように機能するか、またアップデートを軽量に保つために実行できることを知ることで、ユーザーのダウンロード速度が向上し、コストが削減されます。

このブログ投稿は、EAS Updateが何であるか、どのシナリオで有用であるかについて既に理解していることを前提としています。

月間アクティブユーザー（MAU）

月間アクティブユーザー（MAU）は、単一の請求期間内にEAS Update経由で少なくとも1つのアップデートをダウンロードする一意のユーザーです。その月にダウンロードするアップデートの数がいくつであっても、彼らは1つのMAUとしてカウントされます。ユーザーがアップデートをチェックしても新しいものが利用できない場合（ダウンロードが発生しない場合）、彼らはカウントされません。

アプリをアンインストールして再インストールすると、次回アップデートをダウンロードするときに別のMAUとしてカウントされます。同様に、同じ人が2つの異なるデバイスを使用している場合は、2つのMAUとしてカウントされます。

これらのエッジケースはおそらく数値を劇的に変えることはありませんが、実際のMAUカウントがPlayストアやApp Storeのカウント、またはユーザーの一意のアイデンティティについてより多くのコンテキストを考慮するメトリクスと完全に一致しない場合に注意する価値があります。

帯域幅

ユーザーがダウンロードするすべてのアップデートは帯域幅を消費しますが、各プランのクォータは寛容であり、ほとんどのチームはプランの割り当て内に快適に留まります。実際の帯域幅使用量は、圧縮などの要因のおかげで、予想より大幅に低い傾向があります。

そのダウンロードのサイズは、何が変更されたかによって異なります。たとえば、JavaScriptのみが更新された場合、ユーザーがダウンロードするのはそれだけです。元のビルド（または以前のアップデート）からデバイスに既にあるアセットは再ダウンロードされません。

その数は予想より小さいことが多いです：1週間に3つのアップデートを公開し、ユーザーがその週にアプリを1回だけ開く場合、ユーザーは3つではなく1つのアップデートをダウンロードします。最新のアップデートのみがダウンロードされ、残りはスキップされます。

速度と帯域幅の両方の観点から、これは素晴らしいことです。ユーザーは必要以上にダウンロードしていないため、アップデートがより高速に配信され、実際に使用されているものに対してのみ支払います。

とはいえ、請求以外の多くの理由でアップデートを軽量に保つ価値があります：ダウンロード速度の向上、ユーザーのデータ使用量の削減、全体的なスナッピーな体験。

本当に興奮していることの1つ：SDK 55では、Hermes bytecodeディフィング（現在ベータ版、ぜひお試しください！）にオプトインできます。完全なJavaScriptバンドルをダウンロードする代わりに、クライアントは既にインストールされているものにバイナリディフを適用します。これはダウンロードサイズを大幅に削減でき、ユーザーがより高速にアップデートを取得し、より頻繁に配信できることを意味します。これは、アップデートの配信をより安価にし、ユーザーにとってより良いものにするために積極的に取り組んでいる方法の1つです。

より小さなアップデートが重要な理由

アップデートが小さいほど、ユーザーのダウンロード速度が速くなり、各アップデートが消費する帯域幅が少なくなります。これはEAS Updateの使用量とセルラーまたは限定的なデータプランのユーザーの両方に当てはまります。より小さなバンドルはより高速なビルドも意味し、アプリが起動時にアップデートをロードするとき、軽量なバンドルはスナッピーなスタートアップを意味します。

バンドルが十分に大きくなると、開発中にそれに気付くかもしれません。ライブリロードは、すべての変更で大きなバンドルを処理する必要があるとき、遅く感じ始めることができます。

知る価値のあるいくつかのテクニックがあります。

アセットを最適化する

画像はアップデートサイズに素早く追加できるため、配信前に最適化されていることを確認する価値があります。可能な限り画像を圧縮することで、意味のある違いを生み出すことができます。多くの場合、目に見える品質の低下はほとんどまたはまったくありません。画像が小さいほど、アップデートのダウンロードが速く、ユーザーが消費するデータが少なくなります。

アセットをアセットのままにする

画像が適切なアセットファイルである場合、それは1回（ビルドまたはアップデート経由）ダウンロードされ、デバイスに留まります。将来のアップデートは、変更されていない場合、それを完全にスキップします。しかし、アセットがJavaScriptにインライン化されている場合（たとえば、base64エンコードされた画像）、それはバンドル自体の一部であるため、すべてのアップデートで一緒に来ます。

頻繁に変更される画像またはバンドルの外側に完全に存在する画像の場合、expo-imageと組み合わせたCDNからの提供を検討する価値があります。デフォルトのキャッシングポリシーは、最初のロード時に画像をディスクに永続化するため、その後はバンドルされたアセットと同じように動作します（1回ダウンロードされ、アプリの再起動全体で再利用されます）。アップデートに重みを追加することなく。

アップデートに含めるアセットを選択する

プロジェクト内のすべてのアセットをアップデート経由で配信する必要はありません。アセット選択を使用すると、アプリ設定でファイルパターンを使用して、含める正確なアセットを指定できます。その他すべてはネイティブビルドに留まり、アップデートサーバーからダウンロードされることはありません。

たとえば、リリース間でapp/imagesディレクトリ内の画像のみが変更される場合、アップデートをそれらだけに制限できます：

{
  "expo": {
    "updates": {
      "assetPatternsToBeBundled": ["app/images/**/*.png"]
    }
  }
}

パターンを設定したら、公開する前にnpx expo-updates assets:verifyを実行してください。これにより、アップデートを公開するときにすべての必要なアセットが含まれることが保証されます。落ちたアセットは利用できず、予期しない動作またはクラッシュを引き起こす可能性があります。詳細はドキュメントを確認してください。

アプリストアに定期的に送信する

新しいビルドをアプリストアに送信すると、最新のすべてのアセットが含まれます。つまり、そのビルド後に公開するOTAアップデートは、ビルド以降に変更されたものだけを含める必要があるため、ユーザーはより少なくダウンロードします。最近大きなまたは複数の新しいアセットを追加した場合、新しいビルドを配信することは、次のアップデートを軽量に保つ良い方法です。

うまく機能するアプローチの1つは、定期的なバイナリリリースケーデンス（たとえば、月次）をその間の変更のためのOTAアップデートと組み合わせることです。ユーザーはより頻繁に改善を取得し、各新しいバイナリは後続のアップデートのアセットベースラインをリセットします。

JavaScriptバンドルをチェックする

JavaScriptバンドルは、公開するすべてのアップデートの一部です。Expo Atlasのようなツールは、バンドルの視覚的な内訳を提供し、各依存関係が占める正確なスペースを示します。それは本当に目を開かせることができます。単一のユーティリティ関数のためにインポートしたライブラリが予想より大幅に多くを引き込んでいることを発見したり、使用を停止したが削除しなかった依存関係を見つけたりするかもしれません。

ローカル開発サーバーで今すぐ試すことができます。Atlasを有効にしてアプリを起動します：

EXPO_ATLAS=true npx expo start

その後、開発サーバーを実行しているターミナルでshift + mを押して、開発ツールプラグインメニューを開き、Atlasを起動します。

アップデートを効率的に配信する

これまで、アップデートを軽量に保つ方法について説明しました。しかし、アップデートを配信する方法も重要です。ロールアウトはアップデートがユーザーに到達する方法をより詳細に制御でき、内部テストにアップデートを使用することで時間とビルドクレジットを節約できます。

本番環境アップデートにロールアウトを使用する

アップデートを公開すると、デフォルトではユーザーベース全体で利用可能になります。ユーザーがダウンロードするすべてのアップデートは帯域幅使用量にカウントされるため、ロールアウトは効率的な自然な方法です：小さなグループから始め、すべてが良く見えることを確認してから、すべてにロールアウトします。

内部テストとPRプレビューにアップデートを使用する

開発中、チームのレビューのために変更を前に出すことは、多くの場合、新しいビルドを作成することを意味します。しかし、ネイティブコードを含まない変更の場合、OTAアップデートは同じジョブを実行します。わずか数秒で実行されます。チームは、既にインストールされている開発ビルドで直接変更をプレビューしたり、自動的に生成されるプルリクエストプレビューからでもプレビューできます。

レビューと反復サイクルの多くがビルドではなくアップデート経由で発生するほど、誰かが変更を見ることができるようになるまで待つ時間が少なくなります。チームは数秒でデバイスに最新バージョンを持つことができます。つまり、フィードバックループはプロセスの早い段階で開きます。

これは機能を反復するときに素早く追加され、その過程でビルドクレジットを節約しています。そしてそれはあなたのチームだけがこれらのアップデートをダウンロードしているため、MAUと帯域幅のコストはほぼゼロであり、それはあなたのプランで最高の価値対努力の勝利の1つです。

使用状況を追跡する

これまで説明したすべて（アップデートを軽量に保つ、ロールアウトを使用する、内部テストにアップデートを活用する）は、EAS Updateプランからより多くの価値を得ることに貢献します。しかし、物事がどのように進んでいるかを見ることができる場所を知ることも素晴らしいです。

ダッシュボードで使用状況を監視する

Expoは、アカウントの請求と使用状況ページで使用状況の概要を提供します。そこには、EAS Updateの使用状況の概要があります：アップデートをダウンロードしたMAU数と、現在の請求期間（または指定された期間）中に消費された帯域幅。これは、特に大きなリリース後に数値がどのように見えるかに興味がある場合に、情報を得るための便利な方法です。

価格計算機を使用して適切なプランを見つける

ニーズに合ったサブスクリプションプランを把握しようとしている場合、Expoウェブサイトの価格計算機が役立ちます。予想されるMAUカウント、ビルド、CI/CDの分のスライダーを調整すると、プランが推奨されます。数値がそのプランに含まれるものを超える場合、その追加使用量の推定コストも表示されます。

今日のニーズに合ったプランを選択する

プランを選択する前に、すべてを把握する必要はありません。現在のニーズに合ったもので始めてください。アプリが予想より速く成長した場合、壁にぶつかることはありません。すべてのプランは使用状況に応じて自然にスケーリングされ、ニーズが変わるにつれてプラン間を移動できます。Expoの価格設定は、邪魔にならず、あなたと一緒に成長するように設計されています。

EAS Updateは無料プランを含むすべてのプランで利用可能であるため、コミットメントなしで試すことができます。

まとめ

結局のところ、EAS Updateはあなたに非常に素晴らしい取引を与えます：数秒でユーザーにアップデートを配信し、チームとより高速に反復し、自分のペースでスケーリングします。軽量なアップデート、ロールアウト、および説明したいくつかのテクニックは、ユーザーにより高速な体験を提供しながらプランからより多くの価値を得るために必要なすべてです。

始める準備はできていますか？プロジェクトでEAS Updateをセットアップしてください。セットアップには数分しかかからず、すぐにアップデートの配信を開始できます。説明したトピックのいずれかについてさらに詳しく知りたい場合は、EAS Updateドキュメントが次の素晴らしいステップです。EAS Updateでの成功ストーリーについても聞きたいです！