LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

段階的ロールアウトとは — 一斉配信との違いと使われる理由

段階的ロールアウト（staged rollout）とは、モバイルアプリの更新バージョンを全ユーザーへ一斉に配信するのではなく、一部のユーザーから始めて徐々に配信範囲を広げていく手法です^*1。Google Play ConsoleとApp Store Connectの両プラットフォームがこの仕組みを標準機能として提供しています。

従来の一斉配信では、更新を公開した瞬間にすべてのユーザーへ新バージョンが届きます。不具合があれば即座に全体へ影響が及ぶため、リリース後の取り消しが難しい状況になります。段階的ロールアウトは、配信割合を絞ることで問題の影響範囲を限定し、異常が確認されたタイミングで配信を止められる点が大きな違いです。

一斉配信で全ユーザーに不具合が届くリスク

テスト環境で問題が検出されなかった不具合が、本番ユーザーの実機・ネットワーク・データ状態の組み合わせで初めて顕在化するケースがあります。一斉配信では公開直後からすべてのユーザーがその不具合に直面するため、クラッシュやデータ消失が大規模に発生した場合の影響は大きくなります。

ストアレビューでの低評価が急増すると、アプリの評価スコアが下がります。評価スコアの低下は検索露出にも影響するため、ビジネス面での損失につながります。一斉配信後に問題が発覚しても、旧バージョンへの「ロールバック」はストア上では直接できない仕組みのため、修正版を迅速に作成・審査通過させる必要があります。

段階的ロールアウトはこのリスクを「影響を受けるユーザーの範囲を絞る」ことで低減する手法です。不具合が出ても影響は限定的で、配信を止めることで被害の拡大を防げます。

Google Playの「段階的な公開」：割合指定・一時停止・停止の仕組み

Google Play Consoleでは、アプリのリリースを作成する際に「段階的な公開」^*1のオプションを選択できます。配信するユーザーの割合をパーセンテージで指定して公開を開始し、その後手動で割合を引き上げていく仕組みです。

割合の指定と変更

公開時に配信割合を任意のパーセンテージで設定します。初期値を小さくして様子を見ながら引き上げていく運用が可能です。引き上げるタイミングや上げ幅は開発チームが決めることができ、問題がなければ最終的にほぼ全量まで引き上げて全ユーザーへの配信を完了させます。

一時停止と停止

クラッシュ率の上昇やANR（Application Not Responding：アプリが応答しない状態）の急増を検知した場合、段階的な公開を「一時停止」できます^*1。一時停止中は新たなユーザーへの配信が止まります。修正版を準備して問題が解消されれば再開できますが、より重大な問題と判断した場合は「停止」（公開停止）を選択できます。

ステージド・ロールアウト対象外のユーザー

段階的な公開では、手動でアップデートをリクエストしたユーザーや、特定のデバイスに対しては配信割合に関わらず更新が届く場合があります。Google Play Consoleのヘルプで詳細な挙動を確認しておくことをお勧めします。

iOS App Storeの「段階的リリース」：7日間かけて自動配信する仕組み

Apple App Store Connectでは「段階的リリース（Phased Release）」^*2として、自動アップデートが有効なユーザーに対して7日間かけて段階的に配信する仕組みが提供されています。Google Playと異なり、割合は自動的にAppleが管理するスケジュールで引き上げられます。

7日間の自動スケジュール

段階的リリースを有効にすると、自動アップデートをオンにしているユーザーに対して7日間かけて順次配信が広がっていきます^*2。開発者側でパーセンテージを手動で変更することはできません。7日経過後は自動アップデートを使用するすべてのユーザーに配信が完了します。

一時停止と再開

段階的リリース中に問題が発生した場合、App Store Connectで配信を30日間まで一時停止できます。一時停止すると自動アップデートによる新規配信が止まります。問題が解消されれば再開でき、停止前のスケジュールから続けて配信が進みます。

手動アップデートへの注意

段階的リリースの対象は自動アップデートのユーザーです。App Storeで手動で「アップデート」をタップしたユーザーには、配信スケジュールに関わらず最新バージョンが届きます。重大な不具合がある場合はすみやかに一時停止することが大切です。

運用フロー：指標監視→割合引き上げ→異常時停止

段階的ロールアウトを機能させるには、配信割合を広げながら指標を継続的に監視し、問題があれば配信を止めるサイクルを回すことが必要です。

監視すべき主要指標

段階的ロールアウト中に確認すべき主な指標は次の通りです。

• クラッシュ率：セッション数に対するクラッシュ発生数の割合。旧バージョンと比較して急上昇していないかを確認します
• ANR率（Android）：アプリが一定時間応答しない事象の発生率。クラッシュと同様にGoogle Play Consoleで確認できます
• レビュー・評価の変化：低評価レビューが急増していないかをモニタリングします
• 主要機能のエラーログ：Firebase Crashlyticsや独自ログ基盤で収集したエラーを確認します

割合引き上げの判断タイミング

配信割合を引き上げるタイミングは、チームの判断によって決まります。例えば1日ごとに指標を確認して問題がなければ割合を上げていく例もあります。ただし具体的な日数や上げ幅はプラットフォーム仕様で固定されているわけではなく、アプリの特性やユーザー規模、リリースの重要度に応じてチームが設定するものです。

異常時の対応手順

クラッシュ率やANR率が旧バージョンと比べて著しく上昇した場合は、段階的な公開を一時停止します。その後エンジニアが問題の原因を調査し、修正版を準備します。修正が完了したら新バージョンを再公開するか、一時停止を解除して配信を再開するかを判断します。

fastlane等で自動化する方法

段階的ロールアウトの操作はGoogle Play ConsoleやApp Store Connectのウェブ画面から手動でも行えますが、CI/CDパイプラインに組み込むことで自動化できます。

fastlaneを使った自動化

fastlane（ファストレーン）はモバイルアプリのビルド・テスト・デプロイを自動化するオープンソースツールです。Google Play向けには「supply」、iOS向けには「deliver」というアクションが用意されており、段階的リリースの割合設定や更新をコマンドで実行できます。

CI/CDツール（GitHub ActionsやBitriseなど）と組み合わせることで、特定ブランチへのマージをトリガーにビルド→ストア提出→段階的ロールアウト開始までの一連の流れを自動化できます。割合の引き上げ操作もfastlaneのコマンドで行えるため、ヒューマンエラーを減らせます。

自動化に必要なスキル

fastlaneの導入と維持には、iOS・AndroidのCI/CD設定・Rubyの基礎知識・ストアの認証情報の管理に関する理解が必要です。初期設定には時間がかかることもあるため、モバイル開発経験のあるエンジニアが担当することが望ましいです。社内にそのスキルがない場合は、設定ごと外注するという進め方もあります。

外注で段階的ロールアウト運用を担う場合の進め方

アプリ開発を外注している場合、段階的ロールアウトの運用も合わせて委託するケースがあります。開発フェーズと運用フェーズの体制が異なる場合は、契約や業務範囲の定義に注意が必要です。

外注前に整理しておくこと

外注先に依頼する前に、以下の点を整理しておくと業務範囲の認識ずれを防ぎやすくなります。

• ストアアカウント（Google Play Console / App Store Connect）のアクセス権限を外注先に付与するか、発注側で操作するかの役割分担
• クラッシュ率などの指標閾値（しきい値）と、一時停止・停止の判断基準の合意
• 異常検知から発注側への連絡・承認・対応完了までのフロー（エスカレーションルート）
• 段階的ロールアウト中の監視時間帯と対応SLA（サービスレベル合意）

発注時に確認すべきこと

外注先に確認すべき主要なポイントは3点です。第一に、Google Play・iOSの段階的リリース運用の実務経験があるか。第二に、監視ツール（Firebase Crashlyticsや類似のもの）の設定・活用経験があるか。第三に、問題発生時の連絡・対応フローを明文化した運用規程を提供してもらえるかです。

内製と外注の比較：監視体制・スキル要件・コスト

段階的ロールアウトの運用を内製で担うか外注するかは、社内のモバイルエンジニアの経験・監視体制の整備状況・リリース頻度によって判断が変わります。以下の比較表を参考にしてください。

内製と外注を組み合わせる選択肢もあります。例えばCI/CDと段階的ロールアウトの初期設定だけを外注し、日常の監視・割合引き上げは社内で担当するという進め方もあります。

注意点：監視体制・ロールバック・停止判断の基準

段階的ロールアウトを有効に機能させるには、技術的な設定だけでなく運用上のルールを整備することが大切です。見落としやすい3つの注意点を整理します。

監視体制：リリース直後の手薄を避ける

段階的ロールアウト中に問題が発生しやすい時間帯は、配信開始直後です。金曜夜や連休前にリリースすると、問題が起きても発見・対応が遅れるリスクがあります。監視できる体制が整っている時間帯にリリースを合わせることが、影響の拡大を防ぐ手段のひとつです。

ロールバック：ストアでの直接的な取り消しはできない

モバイルアプリのストア公開では、旧バージョンに戻す「ロールバック」をストア機能で直接実行することはできません。段階的ロールアウトを一時停止・停止しても、すでに新バージョンに自動アップデートされたユーザーの端末に旧バージョンを強制的に戻すことは原則としてできません。問題が大きい場合は修正版を迅速に準備してストアに再提出することが現実的な対処になります。

停止判断の基準：事前に閾値を合意しておく

クラッシュ率がどの水準に達したら一時停止するかを事前に定めておかないと、担当者によって判断が変わり対応が遅れることがあります。チームまたは外注先と「クラッシュ率が旧バージョン比で〇%以上上昇した場合は一時停止する」といった閾値を合意し、ルールとして明文化しておくことが大切です。

まとめ：段階的ロールアウト運用を成功させる3つの判断軸

本稿では一斉配信のリスクからはじまり、Google Play・iOSそれぞれの段階的ロールアウトの仕組み・運用フロー・自動化・外注の進め方・内製との比較・注意点までを整理しました。要点を3つに集約します。

第一に、段階的ロールアウトの効果は「配信割合を絞ることで影響範囲を限定し、異常を検知したら止められる」点にあることです。止められる状態を作るには、クラッシュ率・ANR率などの指標を監視できる体制を事前に整えておく必要があります。

第二に、Google PlayとiOSでは仕組みが異なるという点です。Google Playは割合を開発者が手動で設定・変更する方式で、iOSは自動アップデートのユーザーに対して7日間かけて自動的に広がる方式です^*2。両プラットフォームで運用する場合はそれぞれの仕様を踏まえた手順が必要になります。

第三に、外注で運用を委託する場合は、停止判断の閾値・エスカレーションフロー・監視時間帯を契約段階で合意しておくことが手戻りを防ぐ土台になります。曖昧なままスタートすると、問題発生時に対応が遅れるリスクがあります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google Play Console ヘルプ「段階的な公開 — Google Play Console ヘルプ」
2. *2　出典：Apple「Release a version update in phases — App Store Connect Help」

Tweet