概要
Expo の CI/CD（Workflows）、開発ビルド、そして OTA（EAS Update）を組み合わせることで、各プルリクエストを QR コードで開けるインストール準備済みのプレビューに変える方法を説明します。ブランチを切り替えたりアプリを手動で再ビルドしたりすることなく、新機能をレビューできるワークフローを目指します。
互換性のある開発ビルドがすでに端末にインストールされている場合、各プルリクエストはアプリ内で QR コードや Dev Client の選択から直接読み込めるプレビューになります。ネイティブ変更があれば最初に新しいビルドが作成され（そのビルドに対して更新が適用され）、レビュー方法は変わりません。開発サーバーは不要、特別なセットアップも不要で、デザイナー、QA、プロダクトが早期にフィードバックループに参加できます。
ワークフローの責務
ワークフローで自動化すべき主要な責務は次の通りです。
- Android、iOS、iOS Simulator 用の互換性のある開発ビルドが存在するか判定する。
- 互換性がない場合は必要に応じて新しい開発ビルドを生成する。
- 互換性のあるビルドが既に存在する場合はビルドステップを省略して既存ビルドを再利用する。
- 既存ビルドがあっても新しく作成した場合でも、開発ビルドをターゲットとした OTA アップデートを公開する。
- プルリクエストにコメントを投稿し、次を含める：
- 互換性のあるビルドへのリンク
- 既に互換性のある開発ビルドを持っていれば即実行できるアップデートへの直接アクセス（QR コードでスキャン、または Dev Client から選択）
新しい Expo プロジェクトで EAS Workflows を始める
前提としていくつかの準備が必要です。チュートリアルでは新規プロジェクトから始めます。
このコマンドはプロジェクトルートに eas.json を生成し、一般的なビルドプロファイルを設定します。また、プロジェクトを Expo にリンクして expo.extra.projectId を app.json に追加します（詳しくは EAS Build のドキュメント参照）。
iOS シミュレータ用の専用ビルドプロファイルを追加
例として development-simulator プロファイルを eas.json に追加します（既存の設定の一部）：
{
"cli": { "version": ">= 16.28.0", "appVersionSource": "remote" },
"build": {
"development": {
"developmentClient": true,
"distribution": "internal",
},
"development-simulator": {
"extends": "development",
"ios": {
"simulator": true
}
},
"preview": { "distribution": "internal", },
"production": { "autoIncrement": true, }
},
"submit": { "production": {} }
}
（上の JSON は抜粋例です）
開発ビルドの設定
このワークフローを最大限活用し、開発者や QA にとって良い体験にするには、開発ビルド（development builds）を使う必要があります。プロジェクトに expo-dev-client がインストールされていることを確認してください：
`npx expo install expo-dev-client`
expo-dev-client はデバッグビルドに便利な開発ツールやカスタマイズ可能なランチャー UI を追加します。この UI により、プルリクエストから作成された機能プレビューをアプリ内で直接読み込めます。更新が公開されれば、チームはローカルでプロジェクトを起動したり開発サーバーに接続したりすることなく、新機能をレビューできます。QR スキャンまたは開発ビルド内の選択から更新を読み込むだけです。
GitHub と連携してワークフローを自動化する
Workflows はターミナルから手動で起動できますが、GitHub に統合すると毎日の開発プロセスに自然に溶け込みます。例えば、コミットやプルリクエストを作成したときに自動でワークフローをトリガーできます。GitHub リポジトリと EAS プロジェクトをリンクする手順：
- アプリの GitHub リポジトリを用意する
- GitHub のプロジェクト設定に移動する
- プロンプトに従って GitHub アプリをインストールする
- Expo プロジェクトに該当するリポジトリを選択して接続する
EAS Update を内部リリース向けに設定する
EAS Update を設定すると、重要な修正や改善、新機能を即座にプッシュできます。また、開発者と QA の内部イテレーションを高速化するのにも最適です。まず次を実行します：
`eas update:configure`
このコマンドは次を行います：
expo-updates を依存関係としてインストールeas.json のビルドプロファイルにチャンネル（channel）を追加app.json に updates オブジェクトを追加
例：eas.json の抜粋（チャンネルを追加）
{
"cli": { "version": ">= 16.28.0", "appVersionSource": "remote" },
"build": {
"development": { "developmentClient": true, "distribution": "internal", "channel": "development" },
"development-simulator": { "extends": "development", "ios": { "simulator": true } },
"preview": { "distribution": "internal", "channel": "preview" },
"production": { "autoIncrement": true, "channel": "production" }
},
"submit": { "production": {} }
}
channel プロパティは EAS Update がどこにアップデートを公開するかを決めるために使われます。上記では development-simulator のチャンネルを削除して development を継承させています。詳細はドキュメントを参照してください。
互換性のあるビルド vs 互換性がないビルド
なぜ一部のアップデートが即適用でき、他は新しい開発ビルドが必要になるのかを理解することが重要です。これが高速イテレーションを可能にする理由です。
- 各ネイティブビルドには「ネイティブフィンガープリント（native fingerprint）」があります。これはネイティブ層に影響するプロジェクトの部分のスナップショットです。
- ワークフローではフィンガープリントを比較して、既存の開発ビルドが互換性を持つかどうかを判断します。
定義：
- 互換性のあるビルド（Compatible build）＝ アップデートを即公開できる。再インストールや再ビルド、待ち時間なしで QA やチームメンバーが数分で機能を試せる。
- 互換性がないビルド（Incompatible build）＝ 新しい開発ビルドが必要。ネイティブコードを持つライブラリを追加したり、アプリ設定を変更した場合に発生する。
ネイティブ層に変更がなければ既存の開発ビルドでプレビュー可能です。変更がある場合はワークフローが新しい開発ビルドを作成してからアップデートを公開し、同一プルリクエストの一部としてプレビューを継続できるようにします。
これが EAS Update がコラボレーションに強力な理由の一つです。多くの機能開発（UI の磨き込み、ロジック調整、文言、スタイリング、ナビゲーション変更）はネイティブビルドを必要としないため、ビルド待ち時間をほぼ無視して視覚的かつ対話的に反復できます。
ワークフローが互換性をチェックしてアップデートを公開する流れ
作成するワークフローは次の手順で自動的に判断します：
- Android、iOS、iOS シミュレータのフィンガープリントをチェック
- 最速のパスを選択する：
- 互換性があれば既存の開発ビルドを再利用
- 必要な場合のみ新しい開発ビルドを生成
- 常にプレビュー用のアップデートを配信
これにより、チームは可能な限り即座にワーク・イン・プログレス（WIP）をテストでき、必要なら自動的に再ビルドされます。
EAS Workflow ファイルを作成してビルドを生成またはアップデートを公開する
EAS のワークフローはすべて .eas/workflows ディレクトリに置きます。これによりワークフロー定義をコードと一緒にバージョン管理できます。
例のディレクトリ構成：
/
└── .eas/
└── workflows/
└── create-dev-build-or-update.yml
├── app/
├── eas.json
└── .. (他のファイル)
この例では create-dev-build-or-update.yml というワークフローを作成します。ローカルでディレクトリとファイルを手動作成するか、プロジェクトルートから次のコマンドで生成できます。
ワークフローファイルは YAML で記述します。GitHub Actions を使ったことがあるなら構文に馴染みがあるはずです。EAS Workflows は完全にカスタムなジョブを定義できますが、一般的なタスクをカバーする事前作成ジョブ（pre-packaged jobs）も多数用意されています。
このワークフローで使う主なジョブ：
- Fingerprint
- Get Build
- Build
- Update
- GitHub Comment
以下はワークフローの例（抜粋）。YAML 構造は GitHub Actions に似ていますが、EAS 固有のジョブを使っています。
name : Create development builds or update
on :
pull_request :
branches : [ "*" ]
jobs :
fingerprint :
name : Fingerprint
type : fingerprint
environment : development
get_android_build :
name : Check for existing android build
needs : [ fingerprint ]
type : get-build
environment : development
params :
fingerprint_hash : ${{ needs.fingerprint.outputs.android_fingerprint_hash }}
profile : development
get_ios_build :
name : Check for existing ios build
needs : [ fingerprint ]
type : get-build
environment : development
params :
fingerprint_hash : ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
profile : development
get_ios_simulator_build :
name : Check for existing ios simulator build
needs : [ fingerprint ]
type : get-build
environment : development
params :
fingerprint_hash :
(ここでソースは途中まで示されていますが、この後は各 get_* ジョブの出力を評価して、既存ビルドを再利用するか新規に build ジョブを実行するかを分岐させ、最終的に update ジョブで OTA を公開し、github-comment ジョブで PR にビルド/アップデート情報と QR コードやリンクを投稿する流れになります。)
このガイドは、チームがプルリクエストごとに迅速にプレビューを提供し、デザイナー、QA、プロダクトとのフィードバックループを早めるための実践的な手順を示しました。必要であれば、ワークフロー YAML の詳細サンプルや、update／build ジョブの具体的な設定例を追加で提供できます。