メインコンテンツへスキップ

Google Playの段階的公開:Play Consoleで100%にするまでの手順

Play ConsoleにおけるGoogle Playの段階的公開の仕組み。パーセンテージを指定して公開を開始し、徐々に拡大、停止、再開、そして100%のフルリリースへと進めます。クラッシュやレビューの監視も可能です。

Google Playの段階的公開におけるPlay Consoleの操作手順 Capgo ブログ用図解

簡単に言うと: ある Google Playの段階的公開 アプリのアップデートを アプリのアップデートを に 対象ユーザーの割合 で プロダクション, オープンテスト、または クローズドテスト 〜に到達する前に フルロールアウト で、シェアは 100%. Google 段階的なリリース(staged rollout)の割合は、アプリのアップデートにのみ、〜ではなく適用されます トラックでの初回リリース (最初のオープンテストまたはクローズドテストの公開を含む)。 開始: 新しいAndroid App Bundleでリリースを作成し、アップデートのレビュー画面でロールアウト率を選択して、以下をクリックします: ロールアウトを開始 (リリースの準備とロールアウト). 増加: リリース タブ → ロールアウトを管理 → ロールアウトを更新 → より高い割合を設定 → アップデートを確認 (パーセンテージが 自動的に上昇することはありません)). 停止: ロールアウトを管理 → ロールアウトを停止 (これ以上新しいユーザーにステージング版は配信されません; すでにアップデート済みのユーザーはそのまま利用可能です)。 再開: ロールアウトを管理 → ロールアウトを再開 → パーセンテージを設定 → アップデートを確認. フルロールアウト: まで増やす 100% を使用して ロールアウトを更新. 詳しくは Capacitor ストアのロールアウトと Capgo チャネルを と 段階的なロールアウト ネイティブリリース間のライブWebアップデートについては、次を参照してください TestFlightとAndroidのテストトラック 本番前の品質管理のために。

2026年のPlay Consoleトラック

Googleは4つのリリースサーフェスについて説明しています:

Play Consoleのトラック ビルドの配信対象 段階的公開の割合
内部テスト 最大100名の招待済みテスター 段階的公開なし(テスターへ全配信)
クローズドテスト 指定したメールリストまたはGoogle Groups はい
オープンテスト ストア掲載情報からアプリをインストールしたすべてのユーザー はい
プロダクション 選択した国の対象ユーザー はい(本番環境で国別ターゲティングが可能)

出典: リリースの準備とロールアウト と オープン、クローズド、内部テストの設定.

一般的なフロー: 内部テスト スモークテスト用 クローズドテスト 信頼できるベータグループ用 オープンテスト より広いフィードバックを得るために、次に プロダクション 段階的なリリース率を指定できます。AndroidのテストトラックとiOSのTestFlightワークフローの比較については、こちらを TestFlightとAndroidのテストトラック.

Playの段階的ロールアウトの仕組み

Googleの 段階的ロールアウトでアプリ更新をリリース ガイドでは、このループについて説明しています:

  1. 開く プロダクション, オープンテスト、または クローズドテスト Play Console で。
  2. リリースを作成または編集し、 Android App Bundle の versionCode そのトラックですでにリリースされているものよりも高いバージョンです。Play ストアは、互換性のある中で最も高いバージョンを提供します。 versionCode が、そのトラックに既に存在するリリースよりも高いバージョンである場合、Play ストアはユーザーがアクセス可能なすべてのトラックの中で最も高い互換性のあるバージョンを提供します。そのため、同じユーザーに対して、より新しい Production ビルドが、テストトラックの低いバージョンを上書きすることが可能です。
  3. アップデートの 審査ステップで、 展開率を (リリースの準備とロールアウト).
  4. クリック ロールアウトを開始.
  5. AndroidのVitals、クラッシュ、および適切なフィードバック(テストトラックのテスターノートや本番環境の公開レビュー)を監視します。
  6. 段階的に 展開率を上げましょう ロールアウトを管理 → ロールアウトを更新 → アップデートを確認.
  7. 停止 または 再開 と ロールアウトを管理 一時停止や再開が必要なときに。
  8. 次の段階へ 100% 〜の 全ユーザーへの公開 メトリクスが良好なときに。

Googleのドキュメントにある重要な制約:

  • 段階的な公開(staged rollouts)では、Googleが対象トラックのユーザーの中からランダムにアップデートを割り当てます。Play Console上で、どのユーザーに段階的なビルドを配信するかを選択することはできません。クローズドテストのテスターへの招待は、段階的な公開の割り当てとは別の仕組みです。
  • 別のロールアウトを開始する前に、対象トラックにある競合するドラフト版リリースを完了または破棄してください。未公開の変更を削除するか、進行中の段階的なリリースを解決する必要があります(リリースの準備とロールアウト).
  • ユーザーに即時インストールを強制することはできません。Playがリリースを配信したタイミングで更新されます。
  • 本番環境の段階的ロールアウトで対象にできるもの: 特定の国や地域。テストトラックは、そのトラックのテスター規則に従います。
  • を実行すると、 停止 と 再開、Googleは以下に影響を与えることを記録します: 同じユーザー層 に対して行われます。

この Google Play Developer API のトラックID(production, beta 公開テスト用、 qa 内部テスト用、および名前付きのクローズドテスト用)を、リリースを自動化する場合に指定します。

一般的なロールアウトスケジュールと監視すべき項目

Googleは必須のパーセンテージ階層を公開していません。通常、チームは スモールスタートから始め、, 状況を確認します。、次に 段階的に増やし を使用して ロールアウトを更新 最終的に 100%全ユーザーに到達させます。一般的な運用パターンとしては、最初は低い割合から開始し、Vitalsに問題がなければ段階的に引き上げ、最終的にフルロールアウトへと進めます。ユーザーベースやリスク許容度に合わせてタイミングを調整してください。

指標 確認すべき項目
クラッシュ率(インストール後) Play Console Android vitals
ANR(ユーザーインストール後) Play Console Android vitals
リリース前チェック(全ユーザー展開前) テストデバイスでのPlay Consoleリリース前レポート
ユーザーレビュー(本番環境の段階的公開) 該当バージョンのストア掲載情報の評価とレビュー
テスターからのフィードバック(公開または非公開テスト) テストトラックのフィードバック、メール、またはグループチャネル
バックエンドエラー バージョンヘッダーと紐付けた API ダッシュボード

Googleの 段階的公開のヒント 密接なモニタリングを推奨 クラッシュレポート と ユーザーからのフィードバック ロールアウト中は、リリース率を上げる前に十分な時間を置いてシグナルを収集してください。多くのチームでは、初期のリリース率の段階で少なくとも1日は様子を見ます。

ネイティブのバグが混入した場合、 停止 Playのロールアウトを停止し、修正済みバンドルをより高いバージョンで公開してください versionCodePlay ストアはバイナリの自動ロールバックを行いません。ネイティブの修正が必要な場合と、ウェブレイヤーのアップデートで済む場合の違いについては、以下を参照してください。 GoogleはLive Updateを許可しているのか? および Capacitor OTAのApp Store/Play Store審査ガイド.

ロールアウトの中止と、既にアップデート済みのユーザーについて

ロールアウトを停止 を行うと、Play ストアはそのステージング版の提供を停止します。 まだ受け取っていない 追加の全ユーザーに すでにステージング版を受け取ったユーザーは、そのバージョンを維持します. 「停止(halt)」操作だけでは、自動的にロールバックされることはありません。

ウェブコンソールでの手順: トラックを開く → リリース → ロールアウトを管理 → ロールアウトを停止.

停止後に再開するには: ロールアウトを管理 → ロールアウトを再開 → ロールアウトの割合を設定 → アップデートを確認.

もしバンドル自体に問題がある場合は、 新しいリリースを 修正済みのAndroid App Bundleと、より高いバージョン番号で作成し、 versionCodeそれをロールアウト(段階的、または100%のいずれかを選択)してください。

Capgo チャネルとパーセンテージロールアウト(ライブアップデート)

ストアのロールアウトが変更するのは ネイティブシェル ユーザーが Play からダウンロードするもの。 Capgo 処理します ライブ web bundle アップデート インストール済みの Capacitor アプリ内で。

  • チャンネル デバイスをアップデートストリームに紐付けます(production, betaカスタム名も可)。デバッグ時には、特定のデバイスIDをチャネルに強制割り当てできます。
  • 段階的なロールアウト 特定の 安定版フォールバックを提供します bundle をチャンネルに保持しつつ、 ロールアウト対象 設定した 割合 のデバイスに配信します。Webレイヤーの修正のために、新しい Play ビルドをリリースすることなく、配信率の増加、減少、一時停止、完了、またはロールバックが可能です。

ネイティブの code や権限を変更する場合は、Playの段階的公開を利用してください。 targetSdkVersion修正内容がHTML、CSS、JavaScriptのみで、コンプライアンス審査でOTA配信が許可されている場合は、Capgo によるパーセンテージ公開が適しています。

推奨される組み合わせ戦略

  1. ネイティブの変更は以下を通じてリリースします: 内部テスト、次に クローズド または オープンテスト、その後に プロダクション 段階的公開
  2. 日々のWeb修正には、本番デバイスを安定した Capgo チャンネルに向けましょう。
  3. 実行: 段階的なロールアウト チャンネルで、自動の安定版フォールバック付きカナリアWeb bundleが必要なときに使います。
  4. Vitalsが悪化した場合はPlayのロールアウトを停止し、Webメトリクスが悪化した場合は Capgo の段階的ロールアウトをロールバックしてください。

ルールと要件の再確認

  • 新しいbundleには、重複するすべてのトラックでユーザーが既に受信できるビルドより高い versionCode バージョン番号が必要です。
  • Play App Signingを使用しているアプリは、以下の手順に従って署名済みAABをアップロードする必要があります: Google Play App Signing.
  • 同じトラックで競合するリリースを開始する前に、未完了の段階的リリースを完了させるか、下書きを破棄してください。リリースの準備とロールアウト).

よくある質問

Google Play Consoleでの段階的公開の仕組みと、公開割合を増やす方法は?
一部のユーザーにのみアップデートを配信します。まず リリースを選択し、 ロールアウトを管理、次に ロールアウトを更新、より高いパーセンテージを入力し、 アップデートを確認をクリックします。パーセンテージは自動では増えません。

Androidの段階的公開は、どのようにして少人数から100%へ拡大されるのか?
まず、任意の割合から開始し、 ロールアウトを開始メトリクスやレビューを監視しながら、 ロールアウトを更新 問題がないことを確認するまで、 100% 段階的に繰り返します。

Google Playの「ロールアウトの中止」とは?
新しいユーザーへの段階的な配信を停止します。すでにアップデート済みのユーザーは、次に新しいバージョンを公開するまで、現在のバージョンをそのまま使い続けます。

中止したロールアウトを再開するには?
使用する ロールアウトを管理 → ロールアウトを再開、パーセンテージを設定し、 アップデートを確認。Googleは同じユーザー層に対して停止と再開を適用します。

モバイルアプリの段階的ロールアウト中に監視すべき項目は何ですか?
クラッシュレポート、Android VitalsのANR、リリース前テストの結果、公開・非公開テストのテスターからのフィードバック、および本番環境での段階的ロールアウト中の公開レビューです。

フルロールアウトとは何ですか?
リリースは、対象国のそのトラックのユーザーの 100% に対して配信されます。通常、段階的ロールアウトのパーセンテージを 100% を使用して ロールアウトを更新.

Google Play Staged Rollouts: How It Works から続きを読む

使用している場合 Google Playの段階的ロールアウト:その仕組み ストアの承認と配信を計画するには、これを次と連携させてください: @capgo/capacitor-in-app-review @capgo/capacitor-in-app-review での実装の詳細については、 @capgo/capacitor-in-app-review の使い方 「@capgo/capacitor-in-app-review の使い方」のネイティブ機能については、 @capgo/capacitor-native-market @capgo/capacitor-native-market の実装詳細については、 @capgo/capacitor-native-market の使用 @capgo/capacitor-native-market の使用におけるネイティブ機能については、および Capacitor OTAアップデート: App Store審査ガイド Capacitor OTA Updates: App Store Approval Guide の実践的な文脈については。

Capacitor アプリ向けの Live Updates

Web レイヤーのバグが本番で発生したら、App Store の審査を何日も待たずに Capgo で修正を配信しましょう。ネイティブの変更は通常の審査フローに残したまま、ユーザーはバックグラウンドでアップデートを受け取れます。

最新のブログ記事

Capgoは、真にプロフェッショナルなモバイルアプリを作るために必要な最高のインサイトを提供します。