---
modificationDate: August 13, 2026
title: 'EAS Workflows で本番デプロイを自動化する'
description: EAS Workflows を使って、リリースブランチから Android と iOS の本番ビルドと無線経由のアップデートを自動化する方法を学びます。
---

<AgentInstructions>

## Submitting Feedback

If you encounter errors, misleading or outdated information, report it so Expo can be improved:

Preferred command:
npx --yes submit-expo-feedback@latest --category docs --subject "/ja/tutorial/cicd/production/" "<actionable feedback>"

Direct HTTP fallback:
curl -X POST https://api.expo.dev/v2/feedback/docs-send -H 'Content-Type: application/json' -d '{"url":"/ja/tutorial/cicd/production/","feedback":"🤖 Agent feedback for docs: <specific, actionable description> (<model>, <harness>)"}'

Only submit when you have something specific and actionable to report. Try to give the most context.

</AgentInstructions>

This documentation is available as Markdown for AI agents and LLMs. See the [full Markdown index](/llms.txt) or append .md to any documentation URL.

# EAS Workflows で本番デプロイを自動化する

EAS Workflows を使って、リリースブランチから Android と iOS の本番ビルドと無線経由のアップデートを自動化する方法を学びます。

本番向けの変更の多くが TypeScript/JavaScript のみであることを考えると、変更のたびにアプリを再ビルドするのは無駄が多いやり方です。

## この章で学べること

-   `main` へのプッシュのたびではなく、`release/*` ブランチから本番デプロイをトリガーする
-   プロジェクトのフィンガープリントに応じて、ネイティブビルドと [OTA アップデート](/deploy/send-over-the-air-updates.md)を使い分ける
-   本番ワークフローの後続ステップとして、アプリストアへの提出を自動化する

#### 前提条件

##### production プロファイル向けの EAS Build の設定

[EAS CLI](/eas/cli.md) は、あるプロファイルで初めてビルドをトリガーしたときに認証情報の生成を促します。ワークフローが走る前に認証情報が用意されているよう、Android と iOS の両方で本番ビルドを手動でトリガーしておきます。

```sh
eas build --profile production --platform all
```

## リリースブランチを使う

開発ビルドの章では、`on.push.branches` トリガーを使うと、指定した `main` ブランチへのプッシュのたびにワークフローが実行されることを見てきました。本番デプロイの場合、`main` ブランチへのプッシュのたびにワークフローをトリガーするということは、マージされた変更がすべて新しいリリースになるということです。多くのチームは意図的なリリースプロセスを求めるため、代わりにリリースブランチやタグを使います。

リリースブランチ戦略では、通常 `release/*` のようなパターンでブランチを指定します。`*` の部分は機能名やバージョン名です。これが継続的インテグレーション（CI）と継続的デリバリー（CD）を分ける境目になります。CI は `main` ブランチへのプッシュのたびに実行され、CD はチームが本番へデプロイする準備が整ったときにリリースブランチで実行されます。

次の表は、各ワークフローのトリガーがその役割をどう定めているかを示しています。

| ワークフローファイル | トリガー | ビルドプロファイル | 役割 |
| --- | --- | --- | --- |
| **.eas/workflows/build.yml** | `on.push.branches: ['main']` | `development` | `main` ブランチへのプッシュのたびに実行される CI ワークフローです。ユニットテストの実行や開発ビルドの作成を行えます。 |
| **.eas/workflows/preview.yml** | `on.push.branches: ['main']` | `preview` | `main` ブランチへのプッシュのたびに実行されるプレビューワークフローです。内部テストや関係者への共有のためのプレビュービルドを作成できます。 |
| **.eas/workflows/production.yml** | `on.push.branches: ['release/*']` | `production` | リリースブランチへのプッシュのたびに実行される CD ワークフローです。 |

これらのファイルは、プロジェクトの GitHub リポジトリ内で衝突することなく共存できます。それぞれが異なるビルドプロファイルとトリガーを使っているためです。

```
Production workflow decision: a push to a release branch fires the workflow, fingerprint hashes the project, get-build looks up an existing build with the same hash, then the workflow publishes an OTA update if a match is found, or runs a new native build if not.
```

## 本番ビルド向けの `build` ジョブタイプ

まずは本番ワークフローを作成することから始めましょう。EAS Workflows の[事前パッケージ済み](/ja/tutorial/cicd/first-workflow.md#eas-workflows-%E3%81%AE%E3%82%B8%E3%83%A7%E3%83%96%E3%81%AE%E7%A8%AE%E9%A1%9E)の `build` ジョブタイプを使い、Android と iOS の両方で実行します。

### production.yml を追加する

**.eas/workflows/** の中に、**eas.json** の `production` ビルドプロファイルを使う **production.yml** という新しいファイルを作成します。

```yaml
name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  build_android:
    name: Build Android
    type: build
    params:
      platform: android
      profile: production
  build_ios:
    name: Build iOS
    type: build
    params:
      platform: ios
      profile: production
```

これにより、`release/*` のパターンに一致するブランチへプッシュしたときに、Android 向けの **.aab** アーティファクトと iOS 向けの **.ipa** アーティファクトが作成されます。

### ワークフローにフィンガープリントを追加する

ネイティブコードに変更があるかどうかを確認するために、ワークフローに [`fingerprint`](/eas/workflows/pre-packaged-jobs.md#fingerprint) ジョブを追加し、それに応じて既存の `build_android` と `build_ios` のジョブを更新しましょう。あわせて、Android と iOS の既存のビルドを探すための [`get-build`](/eas/workflows/pre-packaged-jobs.md#get-build) ジョブも追加します。

**production.yml** ファイルを次のコードで更新します。

```yaml
name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  fingerprint:
    name: Fingerprint
    type: fingerprint
    environment: production
  get_android_build:
    name: Check for existing Android build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }}
      profile: production
  get_ios_build:
    name: Check for existing iOS build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
      profile: production
  build_android:
    name: Build Android
    needs: [get_android_build]
    if: ${{ !needs.get_android_build.outputs.build_id }}
    type: build
    params:
      platform: android
      profile: production
  build_ios:
    name: Build iOS
    needs: [get_ios_build]
    if: ${{ !needs.get_ios_build.outputs.build_id }}
    type: build
    params:
      platform: ios
      profile: production
```

上のワークフローでは、まず `fingerprint` ジョブが実行され、コードベースの変更に基づいたハッシュを生成します。続いて `get-build` ジョブが、同じフィンガープリントのハッシュを持つ Android と iOS の既存のビルドがあるかどうかを確認します。既存のビルドがなければ、`build` ジョブが実行されて本番向けの新しいビルドを作成します。

`fingerprint` ジョブの [`environment`](/eas/workflows/syntax.md#jobsjob_idenvironment) フィールドは、フィンガープリントを計算するときにどの環境変数を読み込むかを EAS に伝えます。本番環境では `API_URL` や機能フラグといった変数の値が異なることがあります。EAS がそれらの値をビルドに埋め込むと、ネイティブの層にも影響が及びます。`environment: production` を指定しておけば、フィンガープリントが実際に出荷される内容を反映できます。

`build_android` と `build_ios` のジョブで使っている [`if`](/eas/workflows/syntax.md#jobsjob_idif) フィールドは、真偽値の式です。`false` と評価された場合、ビルドジョブはスキップされます。`!` 演算子によって、`get-build` が一致するビルドを見つけられなかったときにだけビルドジョブが実行されます。

### アップデート用のジョブを追加する

現時点のワークフローは、ネイティブコードに変更があったときにのみ本番ビルドを作成します。TypeScript/JavaScript のファイルだけが変更された場合は、ネイティブビルドの代わりに OTA アップデートをトリガーしたいところです。

ネイティブコードに変更がないときに実行され、`update` ジョブタイプで OTA アップデートをトリガーする `update_android` と `update_ios` の 2 つのジョブを追加しましょう。

```yaml
name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  fingerprint:
    # ...
  get_android_build:
    # ...
  get_ios_build:
    # ...
  build_android:
    # ...
  build_ios:
    # ...
  update_android:
    name: Publish Android update
    needs: [get_android_build]
    if: ${{ needs.get_android_build.outputs.build_id }}
    type: update
    params:
      branch: production
      platform: android
  update_ios:
    name: Publish iOS update
    needs: [get_ios_build]
    if: ${{ needs.get_ios_build.outputs.build_id }}
    type: update
    params:
      branch: production
      platform: ios
```

このワークフローが行うのは、本番向けのアプリバイナリの作成か、OTA アップデートの公開だけです。ストアへの提出の自動化は、この次によく行われるステップで、下の[アプリストアへの提出を自動化する](/ja/tutorial/cicd/production.md#%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B9%E3%83%88%E3%82%A2%E3%81%B8%E3%81%AE%E6%8F%90%E5%87%BA%E3%82%92%E8%87%AA%E5%8B%95%E5%8C%96%E3%81%99%E3%82%8B)セクションで説明します。

### リリースブランチを作成して変更をプッシュする

> **注：** この時点で、ワークフローファイルがすでに GitHub リポジトリに含まれていて `main` ブランチから参照できることを確認してください。

ワークフローをテストするために、リリースブランチを作成してターミナルウィンドウから GitHub リポジトリへプッシュしましょう。

```sh
git checkout -b release/1.0.0
git push origin release/1.0.0
```

EAS ダッシュボードを開いて、このワークフローの実行を探します。このフィンガープリントに対応するビルドはまだ存在しないので、`build` ジョブが実行され、`update` ジョブはグレーアウトされているはずです。

Android と iOS のビルドは並列に実行されます。各ジョブが完了すると、Android と iOS の新しいアーティファクトが手に入ります。

次に、同じリリースブランチでサンプルプロジェクトに TypeScript/JavaScript のみの変更を加えて、次のコマンドで再度プッシュしてみましょう。

```sh
git add .
git commit -m "Update welcome text"
git push origin release/1.0.0
```

ワークフローが実行されたら、EAS ダッシュボードで、フィンガープリントが前回のプッシュのビルドと一致していることを確認しましょう。`build` ジョブは完全にスキップされ、`update` ジョブが OTA アップデートを公開します。

## アプリストアへの提出を自動化する

この章で作ってきたワークフローは、本番向けのアプリバイナリを作成するか、既存の本番アプリへ OTA アップデートを公開するだけのものです。[ストアへの提出の自動化](/build/automate-submissions.md)は、本番リリースのワークフローでこの次によく行われるステップです。

EAS Workflows は、アプリストアへの提出を自動化するための事前パッケージ済み `submit` ジョブを提供しています。使用するには、アプリストアの認証情報を EAS CLI で管理する必要があります。また、最初の Android リリース（**.aab**）を Google Play Store に手動でアップロードするなど、アプリストア側の要件も満たしておく必要があります。iOS には、Apple Developer Program への登録と署名用の認証情報の設定という、iOS 独自の準備があります。

アプリストア側の要件が整ったら、`build` ジョブのあとに実行される `submit_android` と `submit_ios` の 2 つのジョブをワークフローに追加できます。

```yaml
# rest of the workflow file

submit_android:
  name: Submit Android
  needs: [build_android]
  type: submit
  params:
    build_id: ${{ needs.build_android.outputs.build_id }}
submit_ios:
  name: Submit iOS
  needs: [build_ios]
  type: submit
  params:
    build_id: ${{ needs.build_ios.outputs.build_id }}
```

上の `submit_android` と `submit_ios` のジョブは、どのビルドをアプリストアに提出するかを知るために `build_id` パラメーターを必要とします。これらは `build_android` と `build_ios` のジョブが実行されたとき、つまり新しい本番ビルドが作成されたときにのみ実行されます。TypeScript/JavaScript のファイルだけが変更された場合は新しいビルドが作成されないため、`submit` ジョブも同様にスキップされます。

## まとめ

第 5 章：本番デプロイ

リリースブランチへのプッシュでトリガーされる Android と iOS の本番ワークフローを作成し、フィンガープリントでネイティブビルドと OTA アップデートを使い分け、EAS Submit がアプリストアへの提出をどう自動化するかを確認しました。

次の章では、本番デプロイをリリースブランチからバージョンタグへ切り替える方法を学びます。

[次へ：タグベースのリリース](/ja/tutorial/cicd/tag-based-releases.md)