# iOSアプリのアップデート公開方法と段階的リリース

> iOSアップデートは、新バージョンと新ビルドを作り、新機能の説明を書いて審査に出します。公開方法は手動、自動、または7日間の段階的リリースから選べます。

元のページ：[iOSアプリのアップデート公開方法と段階的リリース](https://devoria.fr/ja/blog/ios-app-update-phased-release)
著者：[Mehdi Azizi](https://devoria.fr/ja/mehdi-azizi)
公開日：2026-11-04
内容の最終更新：2026-11-04


iOSアプリのアップデートを公開するには、App Store Connectで前より大きい番号の新しいバージョンを作成します。そこに新しいビルドを添付し、「新機能」のテキストを書いてから、App Reviewに提出します。**新しいバージョンは、ちょっとした修正であっても毎回Appleの審査を通ります。** 提出前に、承認後のリリース方法を選びます。手動、承認後すぐ、指定日以降、または7日間の段階的リリースです。

段階的リリースが対象にするのは自動アップデートだけです。初日はそのユーザーの1％、7日目に全員に届きます。合計30日まで一時停止でき、一気に全員へリリースすることもできます。このガイドは、2026年11月3日に読み直したAppleのヘルプページに沿っています。

私はSolys、TradaZen、NoleraなどのiOSアプリのアップデートを、ExpoとEASで公開しています。以下で紹介する事例は、これらのリリースから来ています。

## iOSアップデートの公開手順

[新しいバージョンに関するApp Store Connectのヘルプ](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version)では、次の流れが示されています。

1. Appsでアプリを選び、プラットフォームの横にある＋ボタンをクリックします。
2. 前回より大きいバージョン番号を入力し、Createをクリックします。
3. メタデータを確認します。公開中のバージョンのメタデータが自動でコピーされています。
4. ビルド番号を上げた新しいビルドをアップロードします。
5. そのビルドを[TestFlight](https://devoria.fr/ja/blog/testflight-iphone-app-beta-testing)でテストし、バージョンに追加してからApp Reviewに提出します。

始める前に条件が2つあります。公開中のバージョンがReady for Distributionのステータスであること。そして、Account Holder、Admin、App Manager、Marketingのいずれかのロールを持っていることです。

**ロールバックはできません。** Appleは同じページで明記しています。あるバージョンに問題があっても、前のバージョンには戻せません。新しいバージョンを作って提出する必要があります。

## バージョン番号とビルド番号

バージョンは、ユーザーがストアページで目にする番号です。ビルドはアップロードごとの識別子です。**バージョンとビルドの組み合わせは一意でなければなりません。** ルールと関連エラーは[バージョンとビルド番号](https://devoria.fr/ja/blog/app-store-connect-build-number-version)にまとめています。

私のやり方は次のとおりです（Appleのルールではありません）。修正なら最後の数字を上げて1.4.0から1.4.1へ。新機能なら真ん中の数字を上げて1.4.1から1.5.0へ。ビルド番号のほうは、バージョンをまたいでもひたすら上げていくだけです。Expoでは、バージョンは`app.json`にあり、EASは本番ビルドのたびにビルド番号を自動で上げられます。設定方法は[EASでExpoアプリを公開する](https://devoria.fr/ja/blog/eas-submit-ios-app-store)で解説しています。

## 「新機能」のテキスト：Appleの要件

[バージョン情報のページ](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information)では、What's New in This Versionのフィールドについて次のように説明しています。

- **最大4,000文字。**
- **最初のバージョンにはなく、2回目以降はすべて必須。**
- **ストアページの各言語に翻訳可能。**

[App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.12)の2.3.12は、さらに要件を加えています。新機能とプロダクトの変更をわかりやすく説明すること。単なるバグ修正、セキュリティやパフォーマンスの改善なら、一般的な表現で足ります。**重要な変更は列挙しなければなりません。** つまり、サブスクリプションやメイン画面が変わるバージョンで「バグ修正と改善」だけでは不十分です。

Appleは[評価とレビューに関するページ](https://developer.apple.com/app-store/ratings-and-reviews/)で、ユーザーがレビューで報告していた問題を修正したら、リリースノートで触れることも勧めています。

バージョンの種類ごとに、使い回せるテンプレートを3つ紹介します。

修正の場合：

```text
修正と安定性の向上。
- [機能]：[動かなかった点]を修正しました。
- [画面]の読み込みが速くなりました。
報告してくださった皆さん、ありがとうございます。
```

新機能の場合：

```text
新機能：[機能を短く]。
[できるようになったことを一文で。]
場所：[タブ] > [ボタン]。

このバージョンではほかにも：
- [目に見える改善]。
- バグ修正。
```

操作の流れが変わる場合：

```text
[画面または操作の流れ]が変わりました。
- 変わる点：[具体的な影響]。
- そのまま残るもの：[データ、設定、購入]。
ご質問は [設定] > [ヘルプ] からどうぞ。
```

修正テンプレートの最後の行は、実際に誰かが問題を報告した場合にだけ使ってください。ビルドに入っていない新機能は絶対に書かないこと。ガイドライン2.3は、アプリに忠実なメタデータを求めています。

## 手動、自動、日付指定のリリース

[リリースオプションに関するヘルプ](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option)には、3つの選択肢があります。

| オプション         | Appleの承認後                                                 |
| ------------------ | ------------------------------------------------------------- |
| 手動               | ステータスがPending Developer Releaseになり、好きなときに公開 |
| 自動               | 承認と同時にリリース                                          |
| 自動（指定日以降） | 選んだ日付まで待ってから自動でリリース                        |

手動リリースでは、Pending Developer Releaseのバージョンを開き、Release This Versionをクリックして確定します。Appleによると、App Storeに表示されるまで最大24時間かかることがあります。バージョンのページに表示されるメッセージからCancel This Releaseを選べば取り消せます。30日以上待機状態のままだと、Appleからリマインドのメールが届きます。

**手動リリースはタイミングを選ぶためのものです。** たとえば発表の日に合わせて公開したいときです。年間サブスクリプションの新バージョンを含むSolys 2.0.0は、2026年9月末に手動リリースで審査に出しました。

定例的なバージョンでは、私は自動リリースにしています。2026年10月12日に承認されたNolera 1.0.2は、iTunesの公開検索APIで見る限り、Appleのメールから1分もしないうちにApp Storeに出ました。ただし1回の観察にすぎないので、余裕を見ておいてください。

## 7日間の段階的リリース

[段階的リリースに関するAppleのヘルプ](https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases)には、正確なスケジュールが載っています。

| 日目 | ユーザーの割合 |
| ---- | -------------- |
| 1    | 1％            |
| 2    | 2％            |
| 3    | 5％            |
| 4    | 10％           |
| 5    | 20％           |
| 6    | 50％           |
| 7    | 100％          |

アップデートは、対応デバイスで自動アップデートを有効にしているユーザーの中から、ランダムに選ばれた人に配信されます。選ばれたことは本人には通知されません。

**段階的リリースが抑えるのは自動アップデートだけです。** Appleによると、誰でもいつでもApp Storeから新バージョンをダウンロードできます。アプリを新しくインストールした人や、ストアページで「Update」をタップした人は、初日から新バージョンを手にできます。ユーザーの1％でテストする仕組みではありません。それ以外の人へのブレーキです。

有効にするには、バージョンを開き、Phased Release for Automatic Updatesのセクションまでスクロールして、「Release update over a 7-day period using phased release」にチェックを入れ、保存します。Account Holder、Admin、App Managerのいずれかのロールが必要です。このオプションはPending Developer Releaseのステータスまで選べます。**つまりAppleの承認後でも、手動リリースを待っている間なら有効にできます。**

バージョンが承認されると、Ready for Distributionのステータスに「Phased Release」と表示されます。7日間が終わると、そのアプリのAdminとApp Managerに通知が届きます。

### 一時停止、再開、全員へのリリース

- **一時停止**：合計30日まで、何回でも可能です。10日停止すると、残りは20日です。
- **再開**：止めた日から配信が再開されます。
- **全員へのリリース**：バージョンの右上にあるRelease to All Usersボタンで、自動アップデートのすべてのデバイスに配信されます。
- **販売停止**：配信は完全に止まります。デベロッパープログラムのメンバーシップが切れた場合も同じです。アプリが販売再開されると、そのバージョンは一気に全員に公開されます。

[変更可能なプロパティの一覧表](https://developer.apple.com/help/app-store-connect/reference/app-information/required-localizable-and-editable-properties)によると、全員へのリリース後は何も調整できません。

Nolera 1.0.2は段階的リリースなしで公開しました。もし使うなら、1週間の間こう運用します。

| 見えた状況                  | 取る行動                 | 結果                                         |
| --------------------------- | ------------------------ | -------------------------------------------- |
| クラッシュや不安なレビュー  | 一時停止                 | 自動アップデートが止まる                     |
| 修正の準備ができた          | 新しいバージョン         | 改めて審査を受け、独自の段階的リリースを持つ |
| 3〜4日たっても異常なし      | Release to All Users     | 全員に届く                                   |
| Appleからの返答を待っている | 一時停止（合計30日まで） | 止めた日から再開                             |

一時停止中も、手動ダウンロードは続きます。**課金や初回起動に関わるバージョンでは、必ず段階的リリースにチェックを入れてください。** そこで不具合が出るのが一番高くつき、しかも元には戻せません。

## 修正が急ぎのとき：審査の迅速化

Appleでは[迅速な審査](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review)をリクエストできます。本当に緊急の場合に限られます。重大なバグの修正や、イベントに合わせたリリースです。

1. まずバージョンを提出します。審査担当者向けのNotes欄にバグの内容を書きます。
2. 迅速な審査のリクエストフォームに記入し、アプリとプラットフォームを選びます。
3. Appleは状況に応じて審査を早めます。保証はありません。

イベントの場合は、その日付と自分との関係をノートに書いてください。通常の審査期間は[App Storeの審査期間](https://devoria.fr/ja/blog/app-store-review-time)にまとめています。

## 審査に出し直すもの、出さなくていいもの

| 変更内容                                       | 必要なこと                                  |
| ---------------------------------------------- | ------------------------------------------- |
| ネイティブコード、権限、SDKのバージョン        | 新しいビルド、新しいバージョン、通常の審査  |
| スクリーンショット、説明文、キーワード、新機能 | 新しいバージョンと一緒に審査                |
| プロモーションテキスト                         | 不要：再提出なしで変更できる                |
| 一時停止、再開、全員へのリリース               | 不要：リリース設定にすぎない                |
| iOS 27のストアページヘッダー                   | Asset Library単体、またはバージョンと一緒に |
| Expoでの JavaScript の修正                     | リモートアップデートが可能                  |

バージョン情報のページによると、[プロモーションテキスト](https://devoria.fr/ja/blog/app-store-promotional-text-170-characters)は再提出なしで変更できます。Expoでは、リモートアップデートでJavaScript、テキスト、画像をApp Storeを通さずに変更できます。[Expoのドキュメント](https://docs.expo.dev/eas-update/introduction/)は制限を2つ挙げています。ネイティブコード、権限、SDKのバージョンには新しいバイナリが必要なこと。そしてアップデートはApp Storeのルールに従わなければならないことです。

### 私の事例：審査担当者が一度も見なかったリモート修正

2026年9月、Noleraのビルドが審査待ちでした。スキャン画面の不具合を直し、待っている間にその修正をリモートアップデートで公開しました。それでもビルドは、すでに直したはずの不具合でリジェクトされました。

理由は[expo-updatesのドキュメント](https://docs.expo.dev/versions/latest/sdk/updates/)にあります。デフォルトでは、アプリは起動時にアップデートをダウンロードし、次の起動時に適用します。審査担当者はアプリをインストールして一度起動し、ビルドに含まれるコードをテストします。**新規ユーザーにも同じルールが当てはまります。最初のセッションはビルドのコードで動きます。**

それ以来、ホーム画面、ペイウォール、メイン機能の変更はすべて新しいビルドで出しています。リモートアップデートは、すでにアプリを持っている人のためだけに使っています。

## バージョンに合わせて評価をリセットする

新しいバージョンには毎回、Reset rating when this version is releasedのオプションがあります。[評価のリセットに関するAppleのヘルプ](https://developer.apple.com/help/app-store-connect/monitor-ratings-and-reviews/reset-an-app-overview-rating)によると、これはすべての国に適用され、書かれたレビューは残り、リリース後に取り消すことはできません。評価数の少ないストアページはユーザーを遠ざけかねないため、Appleは控えめに使うよう勧めています。

## アップデート提出前のチェックリスト

- バージョン番号が上がり、ビルド番号も増えている。
- ビルドをTestFlightで、小さいiPhoneと（対応しているなら）iPadでテストした。
- 新機能のテキストを各言語で書き、重要な変更を列挙した。
- UIが変わったなら、スクリーンショットが現在の画面を映している。
- 審査担当者向けのノートに、何が変わりどこで確認できるかを書いた。
- リリースオプションを選んだ。日付を守る必要があるなら手動。
- 課金や初回起動に関わるバージョンなら、段階的リリースにチェックを入れた。
- 万一の修正をリモートで出せるのか、新しいビルドが必要なのかを把握している。

## アップデートのたびに審査を通過する

アップデートは毎回App Reviewを通り、リジェクトされれば修正が届けられません。[Review Kit](https://devoria.fr/ja/kits/app-review)には、提出前の私のチェックリスト、修正済みのリジェクト事例、そしてプロジェクトとストアページを確認し、Appleにリジェクトされたときの返信を準備するClaude Codeのスキルを2つ収録しています。全体の流れは[App Storeにアプリを公開する](https://devoria.fr/ja/expertise/publish-app-on-app-store)のページにあります。

初めてのリリースを準備しているなら、[無料診断を受けてください](https://devoria.fr/ja/diagnostic)。手順を正しい順番に整理し、Appleのリジェクト対策チェックリストをお送りします。

## よくある質問

### App Storeの段階的リリースはどのくらいの期間ですか？

7日間です。初日は自動アップデートのユーザーの1％、その後2、5、10、20、50％と増え、7日目に100％になります。合計30日まで一時停止でき、Release to All Usersでいつでも終了できます。

### iOSアプリのアップデートもAppleの審査を通りますか？

はい。新しいバージョンは、ビルドとメタデータとともに毎回App Reviewを通ります。一方、プロモーションテキストとリリース設定は再提出なしで変更できます。

### App Storeでアプリを前のバージョンに戻せますか？

いいえ。修正を入れた新しいバージョンを作り、審査に提出する必要があります。だからこそ、段階的リリースとその一時停止が役に立ちます。

### 段階的リリース中、新規ユーザーにもアップデートは届きますか？

はい、App Storeからアプリをダウンロードすれば届きます。段階的リリースが調整するのは自動アップデートだけで、誰でもいつでも新バージョンをダウンロードできます。

### Appleの承認後に段階的リリースを有効にできますか？

はい。バージョンがPending Developer Releaseのステータス、つまり手動リリースでまだ公開していない状態なら可能です。公開してしまったら、そのバージョンでは手遅れです。

### アップデートのリリースノートには何を書けばいいですか？

新機能と重要な変更を、わかりやすく列挙します。これはガイドライン2.3.12のルールです。単なるバグ修正、セキュリティやパフォーマンスの改善なら、一般的な表現で足ります。このフィールドは4,000文字まで入力でき、各言語に翻訳できます。


## あなたのプロジェクト

[Review Kit](https://devoria.fr/ja/kits/app-review)：私のApp Store審査チェックリスト、修正済みのAppleのリジェクト事例、Google Play用チェックリスト、Claude Codeのスキル3つ。￥8,500。

[iOS & Android Kit](https://devoria.fr/ja/kits/ios)：Claude CodeでiPhoneとAndroidのアプリを作りましょう。私のアプリのスターターコード、ストア公開までの手順、すべてのキットが揃っています。￥17,500。

[診断：あなたとiPhoneアプリの間にあるもの](https://devoria.fr/ja/diagnostic)：7つの質問、60秒。iPhoneアプリの公開を本当に妨げているもの、4ステップのロードマップ、あなたに合ったキットがわかります。