eas-update について
eas-updateは、EAS Updateの設定、公開、テスト、デバッグを支援するスキルです。Expoアプリの更新を管理する開発者向けに、互換性の境界や公開先の確認方法を示します。
主な機能
- 01EAS Updateの設定
- 02更新とネイティブビルドの適用範囲の区別
- 03チャンネル・ブランチ・ランタイムバージョンの解説
- 04公開前の確認とテストの案内
- 05更新が適用されない場合の調査
活用シーン
- 01ExpoプロジェクトでOTA更新を有効化
- 02変更に新しいネイティブビルドが必要か判断
- 03プレビューチャンネルで公開済み更新を検証
- 04アプリが更新を受信しない原因を調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ expo/ skills --skill eas-updateインストール後、Claude Code で/eas-updateを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
EAS Update
EAS サービス — 費用が発生します。 EAS Update は Free プランで利用できます。公開と配信には、アップデート、帯域幅、ストレージの利用枠が適用され、有料プランでは上限が引き上げられます。https://expo.dev/pricing をご覧ください。
EAS Update を使用すると、新しいネイティブバイナリを提出せずに、インストール済みアプリへ互換性のある JavaScript、スタイル、アセットの変更を配信できます。ネイティブコードを変更した場合は、新しいビルドが必要です。
サポートされている設定手順から始める
変更を加える前に、package.json、Expo アプリ設定、存在する場合は eas.json、および ios/ または android/ が追跡対象になっているかを確認します。CLI による変更を確認する際は、確認した内容を反映してください。
- 既存の動的設定やプラットフォーム固有のアプリ設定を維持します。
eas.jsonが存在する場合は、プロファイルと既存のチャネル割り当てを維持します。CLI は、まだチャネルが設定されていないビルドプロファイルにのみ、プロファイル名と一致するチャネルを追加します。eas.jsonが存在しない場合、手動で作成しないでください。CLI は、別途eas build:configureを実行するようユーザーに案内することがあります。- ネイティブプロジェクトが追跡対象になっている場合は、CLI がプラットフォームのネイティブ Update 設定を同期することを想定してください。追跡対象がない場合は、後のビルド時に Continuous Native Generation がネイティブ設定を適用することを想定してください。
パッケージをインストールしたり、バージョン固有の動作を解釈したりする前に、Expo SDK のバージョンを確認します。
expo-updates がインストールされていない場合は、SDK と互換性のあるバージョンをインストールします。
npx expo install expo-updates
プロジェクトのルートで設定します。
npx eas-cli@latest update:configure
updates.url、runtimeVersion、ネイティブメタデータ、ビルドプロファイルのチャネルを手動で作成するのではなく、eas update:configure を使用してください。このコマンドは、EAS プロジェクトへのリンク、Continuous Native Generation、コミット済みのネイティブディレクトリを持つプロジェクトを考慮します。実行結果の差分を確認し、説明してください。
プロジェクトがリンクされていない、または必要なリモート操作をユーザーが許可していないためにコマンドを実行できない場合は、独立して有効なパッケージのインストールだけを行い、そこで中断して、残りの作業を説明してください。ランタイムバージョンポリシー、設定プラグイン、Update URL、チャネルを手動で追加して、update:configure を部分的に再現しないでください。
動的なアプリ設定、EAS 以外のビルド、またはコマンドを自動で完了できない場合は、推測で設定せず、現在のセットアップドキュメントに従ってください:https://docs.expo.dev/eas-update/getting-started.md。
モデルを正しく理解する
- ビルド: インストールされるネイティブアプリです。ネイティブコード、埋め込みアップデート、プラットフォーム、ランタイムバージョン、通常はビルド時に固定されるチャネルを含みます。
- アップデート: 1 つのプラットフォームとランタイムバージョン向けに公開された JavaScript バンドル、アセット、メタデータです。
- ブランチ: アップデートが順序付けられたストリームです。互換性のある最新のアップデートが有効になります。
- チャネル: ビルドに埋め込まれる、安定したデプロイ先です。サーバー上ではブランチを指します。
- ランタイムバージョン: アップデートとビルド内のネイティブコードとの互換性の境界です。
ビルドがアップデートを受け取るのは、プラットフォームとランタイムバージョンが一致し、かつビルドのチャネルがそのアップデートを含むブランチを指している場合に限られます。
installed build (channel: production, runtime: 1.1.1, platform: ios)
-> production channel
-> production branch
-> newest update for runtime 1.1.1 and ios
チャネルとブランチには同じ名前が付けられることがよくありますが、別々のオブジェクトです。eas channel:edit は、そのチャネルに属するすべてのビルドに対して、サーバー側のチャネルとブランチの対応関係を変更します。個々のインストールに埋め込まれたチャネルは変更しません。
このモデルを判断に活用しつつ、毎回モデル全体を説明するのではなく、ユーザーの依頼に必要な概念だけを説明してください。
更新に互換性があるか判断する
インストール済みのネイティブランタイムがすでにサポートしている JavaScript、スタイル、バンドル済みアセットの変更には、更新を使用します。
ネイティブコードまたはネイティブ設定を追加・変更する場合は、新しいネイティブビルドを作成します。これには、ほとんどのネイティブライブラリの追加や SDK のアップグレードが含まれます。ランタイムの不一致を回避したり、公開によって既存ビルドにネイティブ機能を追加できるかのように示したりしないでください。https://docs.expo.dev/eas-update/runtime-versions.md を参照してください。
付随的な修正として、プロジェクトの runtime-version ポリシーを変更しないでください。現在のポリシーが互換性にどう影響するかを説明し、変更すると今後更新を受け取れるインストール済みビルドが変わるため、別個の判断として扱ってください。
慎重に公開する
記憶しているフラグに頼る前に、現在の CLI ヘルプを確認します。
npx eas-cli@latest update --help
一般的なチャンネルベースのフローは次のとおりです。
npx eas-cli@latest update \
--channel <channel> \
--message "<message>" \
--environment <environment>
SDK 55 以降では、公開に EAS 環境が必要です。エクスポートされたコードが意図した変数を受け取るよう、環境を慎重に選択してください。
公開するとリモートの状態が変更され、インストール済みアプリに影響することがあります。実行前に、対象のプロジェクト、チャンネル、環境、プラットフォーム、ランタイムバージョン、メッセージを正確に確認してください。ユーザーが本番環境への公開を明示的に依頼または承認した場合に限り、本番環境に公開してください。承認または対象が曖昧な場合は、コマンドを実行する前に中止して確認してください。現在の Git ブランチだけを根拠に、本番環境への公開先を推測しないでください。
検証にはプレビューまたはステージングのチャンネルを優先してください。テスト済みの更新を昇格する場合は、可能な限り同じアーティファクトを本番環境で受け取れるよう、ドキュメントに記載されたデプロイフローを使用してください:https://docs.expo.dev/eas-update/deployment.md。
ビルドの種類に応じてテストする
開発ビルド
開発ビルドの Extensions UI、EAS ダッシュボード、または Expo Orbit を使って更新をプレビューします。通常の expo-dev-client 開発ビルドは、リリースビルドの自動起動時更新フローと同じようには動作しません。
プレビュー、TestFlight、本番ビルド
リリースビルドでは通常、起動速度が優先されます。デフォルトの起動動作では、新しく公開された更新をバックグラウンドでダウンロードしている間、アプリは現在の埋め込み済みまたはキャッシュ済みの更新で起動することがあります。ダウンロードした更新は、次回以降の再起動時に適用されます。
手動で QA を行う場合は、アプリをバックグラウンドにするのではなく完全に終了してから再度開き、更新のダウンロードを待ちます。変更が表示されない場合は、もう一度完全に終了して再度開いてください。TestFlight 固有の手順ではなく、最大 2 回のコールド起動として説明してください。
- 1 回目の起動で、更新を検出してダウンロードすることがあります。
- 次の起動で、ダウンロード済みの更新を実行できます。
2 回目の起動を避ける目的で、fallbackToCacheTimeout を自動的に変更しないでください。起動時に待機すると、更新の適用が速くなる代わりに、起動時間と信頼性に影響します。アプリに意図的な更新 UX が必要な場合は、更新の確認、取得、ブロックしない再起動操作の提示に expo-updates API を検討してください。プロジェクトで検出された SDK バージョンに対応する expo-updates API リファレンスを使用してください。
更新されなかったビルドをデバッグする
次の順に確認してください。
- 更新が意図した EAS プロジェクト、チャンネルまたはブランチ、プラットフォーム、環境に公開されたことを確認します。
- インストール済みビルドのプラットフォームとランタイムバージョンを、公開済みの更新と比較します。
- ビルドに想定した更新 URL とチャンネルが実際に含まれていることを確認します。アプリ設定の変更が反映されるのは、新たにコンパイルしたビルドのみです。
- チャンネルからブランチへのマッピングと、そのブランチで有効な更新を調べます。
- リリースビルドを完全に終了し、通常のダウンロード後に適用されるライフサイクルを考慮します。
- ネイティブログ、エクスポートの問題、設定の確認には、現在のデバッグガイドを使用します:https://docs.expo.dev/eas-update/debug.md。
更新を表示させるためだけに、互換性やブリック防止のためのセーフガードを回避しないでください。
高度なワークフローと関連ワークフロー
- **チャンネルの切り替え:**個々のリリースビルドでは、
expo-channel-nameリクエストヘッダーを上書きして、互換性のある別のチャンネルをリクエストできます。これは、サーバー側のチャンネルとブランチのマッピングを変更するのとは異なります。https://docs.expo.dev/eas-update/channel-surfing.md に従い、アクセス制御、永続性、復旧、互換性に関する制約を守ってください。 - **アップデートの健全性:**公開後の採用状況、起動失敗、クラッシュ率、ペイロードサイズ、ロールアウトの監視には、
eas-update-insightsを読み込んでください。 - **ストアリリース:**ネイティブの変更により新しい TestFlight、App Store、または Play Store ビルドが必要な場合は、
eas-app-storesを読み込んでください。
公式リファレンス
- セットアップ:https://docs.expo.dev/eas-update/getting-started.md
- 概念とマッチング:https://docs.expo.dev/eas-update/how-it-works.md
- デプロイ:https://docs.expo.dev/eas-update/deployment.md
- デバッグ:https://docs.expo.dev/eas-update/debug.md
- 現行の EAS CLI リファレンス:https://docs.expo.dev/eas/cli.md
フィードバックの送信
このスキルにエラー、誤解を招く情報、または古い情報がある場合は、Expo の改善に役立てるため報告してください:
npx --yes @expo/agent-cli@latest feedback --category skills --subject "eas-update" "<actionable feedback>"
具体的で実行可能な報告内容がある場合にのみ送信してください。関連するコンテキストをできるだけ詳しく含めてください。
エージェントが Expo のタスクを繰り返し失敗する場合、またはユーザーが介入する必要がある場合は、タスク、期待される結果、問題の内容を簡潔に報告し、--category evals と、関連する Expo パッケージまたはコマンドを --subject として指定してください。