OTAアップデートを軽量かつ高速に保つ方法
EAS Update を使えば、PR をマージしてから数分で全ユーザーにクリティカルな修正を配信できる――このスピード感は何度味わっても素晴らしいものです。しかし配信（publish）することは仕事の半分にすぎません。ユーザーの端末で実際に動作するまでにダウンロードが完了する必要があり、ダウンロードが速く、かつ更新が小さければユーザー体験はより良くなります。本ガイドでは、アップデートを小さく保つ方法、確信を持って配信するためのロールアウトの使い方、OTA Update の利用を最適化する実践的なテクニックを紹介します。
EAS Update の料金と基本概念
EAS Update を最大限に生かすには、配信と課金に影響する2つの概念を理解しておくと良いです：Monthly Active Users（MAUs）と bandwidth（帯域）。これらを理解し、アップデートを軽量化することでユーザーのダウンロードは速くなり、コストも下がります。
このポストは EAS Update の基本（何に使えるか）を既に知っていることを前提としています。
Monthly Active Users（MAUs）
- MAU は、請求期間内に少なくとも1回 EAS Update 経由でアップデートをダウンロードした「一意のユーザー」を指します。
- 同じ請求期間中に何度ダウンロードしても1人は1 MAU として数えられます。
- 更新のチェックは行ったがダウンロードが発生していない場合はカウントされません。
- アンインストール→再インストールや、同じ人が異なる端末からダウンロードする場合は別の MAU としてカウントされます。
- これらのエッジケースは Play/App Store の指標と差が出ることがありますが、仕組みを知っておくと便利です。
Bandwidth（帯域）
- ユーザーがダウンロードする各アップデートは帯域を消費しますが、プランごとの割当は通常十分に余裕があります。
- 実際の帯域使用量は圧縮などの要因で想像よりも小さくなることが多いです。
- ダウンロードサイズは「何が変更されたか」に依存します。例えば JavaScript のみが更新された場合、ユーザーはその JavaScript だけをダウンロードします。ビルドに含まれているか、以前のアップデートで既に端末にあるアセットは再ダウンロードされません。
- 例：週に 3 回アップデートを公開しても、ユーザーが週内にアプリを一度しか開かなければ、その週は『最新の1回分のアップデートだけ』をダウンロードします。過去のアップデートはスキップされます。
この挙動は配信速度と帯域の両面で好ましく、ユーザーは必要以上にダウンロードせず、利用分だけ支払うことになります。
一つ興奮している点：SDK 55 では Hermes bytecode diffing（現在ベータ）をオプトインできます。フルの JavaScript バンドルをダウンロードする代わりに、クライアントが既にインストールされているものに対してバイナリ差分を適用します。これによりダウンロードサイズが大幅に削減され、ユーザーはより高速に更新を受け取り、より頻繁に配信できるようになります。
なぜアップデートを小さくするべきか
- ダウンロードが速くなる → ユーザーの修正適用が早くなる
- 帯域と通信コストの削減（あなたとユーザー双方）
- ビルドが速くなる
- 起動時に更新を読み込む場合、バンドルが小さいほど起動が速くなる
- 開発時のホットリロード/ライブリロードも大きなバンドルでは遅く感じやすい
以下は有効なテクニックです。
アセットを最適化する
- 画像はアップデートサイズに大きく影響するため、出荷前に圧縮しておくことをおすすめします。多くの場合、目に見える品質劣化がほとんどないままサイズをかなり削減できます。
アセットは“アセット”として扱う
- 画像が適切にアセットファイルとして扱われている場合、そのアセットは一度（ビルド時または更新時に）ダウンロードされ端末に残ります。以降、そのアセットが変更されない限り将来的なアップデートではスキップされます。
- 一方、JavaScript にインライン（例：Base64 埋め込み）されているアセットはバンドルの一部になるため、毎回のアップデートで再配信されます。
- 頻繁に変更される、あるいはバンドル外で管理したい画像は CDN と組み合わせて expo-image で配信するのが有効です。expo-image のデフォルトのキャッシュポリシーは最初の読み込みでディスクに永続化するため、バンドルに重量を追加せずに一度だけダウンロードして再利用できます。
更新に含めるアセットを選ぶ
-
すべてのプロジェクト内アセットを OTA 経由で配信する必要はありません。asset selection を使うと、app config でファイルパターンを指定して、どのアセットをアップデートに含めるかを制御できます。残りはネイティブビルドに含まれ、アップデートサーバからダウンロードされません。
例：app/images 以下の PNG のみをアップデートに含める設定
{
"expo": {
"updates": {
"assetPatternsToBeBundled": [
"app/images/**/*.png"
]
}
}
}
-
パターンを設定したら、公開前に必ず npx expo-updates assets:verify を実行してください。これにより公開時に必要なアセットがすべて含まれることを確認できます。漏れがあると動作不良やクラッシュの原因になります。
ストアへ定期的に提出する
- 新しいビルドをストアに提出すると、そのビルドには最新のアセットがすべて含まれます。つまりビルド後に公開する OTA アップデートは、そのビルド以降に変更されたものだけを含めればよくなり、ユーザーはより少ないデータで更新できます。
- 大きなアセットを追加した直後は新しいバイナリを出すことで次回以降の OTA を軽量化できます。
- 実務的なアプローチ：月次などの定期的なバイナリリリースを行い、その間の細かい変更は OTA で配る（ハイブリッド運用）。これによりユーザーは頻繁に改善を受け取りつつ、各バイナリが次の更新のベースラインをリセットします。
JavaScript バンドルを適切に管理する
効率的な配信
- アップデートの配信方法も重要です。ロールアウト（段階的配信）を使えばユーザーへの到達を細かく制御できます。
本番配信にはロールアウトを使う
- デフォルトでは公開した更新は全ユーザーに対して利用可能になりますが、全員に一斉配信する前に少数のユーザーで様子を見るほうが安全です。
- ロールアウトを使えばまず少数グループに配信し、問題がなければ徐々に対象を拡大できます。帯域や MAU の観点でも効率的です。
内部テストや PR プレビューにアップデートを活用する
- ネイティブコードを伴わない変更であれば、ビルドを作る代わりに OTA アップデートでチームにプレビューを配るだけで十分なことが多く、数秒で変更を端末に反映できます。
- チーム内だけのダウンロードなら MAU や帯域のコストは事実上ゼロに近く、ビルドクレジットを節約できます。レビューや反復を OTA ベースで行うほど、開発サイクルは短くなります。
使用状況の把握
- アップデートを軽くし、ロールアウトを使い、内部テストを増やすことは EAS Update プランの価値を最大化しますが、実際の使用状況を確認できる場所も知っておくと安心です。
ダッシュボードで使用状況を監視する
- Expo のアカウントの Billing と Usage ページで EAS Update の使用状況の概要を確認できます。現在の請求期間（または任意の期間）で何人の MAU がアップデートをダウンロードしたか、どれだけの帯域が消費されたかが表示されます。
プライシング計算機を使って適切なプランを選ぶ
- Expo の料金ページにあるプライシング計算機で、MAU、ビルド数、CI/CD 分の見込みをスライダーで調整すると推奨プランが表示されます。含まれる量を超える場合は超過分の見積もりも出ます。
今日のニーズに合うプランを選ぶ
- すべてを完璧に予測する必要はありません。現在のニーズに合うプランから始めればよく、アプリが成長すればプランを変更できます。EAS Update は無料プランを含む全プランで利用可能なので、まず試してみることができます。
まとめ
EAS Update を使えば、ユーザーに数秒で更新を届け、チームはより速くイテレーションが回せます。アップデートを軽量化し、ロールアウトを活用し、今回紹介したいくつかのテクニックを組み合わせるだけで、ユーザー体験は速く、安価に、スムーズになります。
始める準備はできていますか？プロジェクトに EAS Update をセットアップすれば数分で配信を始められます。さらに掘り下げたいトピックがあれば EAS Update のドキュメントが次の一歩になります。あなたの EAS Update を使った成功体験もぜひ聞かせてください！