Google PlayとApp Storeで「アップロード」を押した後に何が起こるか
ビルドが成功し、テストが全てパスした。リリースブランチもクリーンだ。チームの誰かが「ストアにアップロードしてレビューを待とう」と言う。実際のモバイルリリースを経験したことがある人なら、その言葉の裏に多くの複雑さが隠れていることを知っている。
Google Play ConsoleやApp Store Connectへのアップロードは、単なるファイル送信ではない。メタデータ、スクリーンショット、変更履歴、レビューキュー、そして非常に現実的なリジェクトの可能性が関わる複数ステップのプロセスだ。そして、パイプラインがアップロードを最終ステップとして扱っているなら、レビューがリジェクト通知と共に返ってきたときに深夜のパニックに陥る準備をしているようなものだ。
アップロードは単なるファイル転送ではない
Android App Bundle（AAB）やiOS IPAファイルをアップロードするとき、ストアが期待するのはバイナリだけではない。以下も提供する必要がある：
- 新しいバージョンのアプリタイトルと説明
- このリリースでの変更点（変更履歴）
- 複数のデバイスサイズに対応したスクリーンショット
- アプリカテゴリとコンテンツレーティングの更新
- アップデートを受け取る国または地域
Google Play ConsoleとApp Store Connectはどちらも、パイプラインがこれらすべてをプログラムで処理できるAPIを公開している。CI/CDシステムはアーティファクトをプッシュし、メタデータを入力し、適切なスクリーンショットを添付し、リリーストラックを設定できる。Androidの場合、プロダクションを考える前に、内部テスト、クローズドテスト、またはオープンテストにアップロードできる。iOSの場合は、まずTestFlightにアップロードする。
以下のシーケンス図は、パイプラインからリリースまでの典型的なフローを示している：
ここで重要なのは、アップロードステップがパイプラインの終わりであってはならないということだ。それは、制御されたリリースプロセスの始まりであるべきだ。
プロダクションに直接アップロードすべきでない理由
「テストが通ったらすぐにストアに公開する」というパイプラインを構築したくなるのは理解できる。しかし、モバイルストアにはウェブやバックエンドのデプロイにはないゲート、すなわち人間によるレビューが存在する。
AppleはすべてのアプリとアップデートをApp Storeレビューガイドラインに照らしてレビューする。Googleもレビューを実施するが、一般的にプロセスはより迅速で厳格さは低い。パイプラインがプロダクションに直接アップロードし、レビューで問題が見つかった場合、修正して再アップロードし、再び待たなければならない。これによりリリースが数日遅れる可能性がある。
より良いアプローチは、まずテストトラックにアップロードすることだ。Androidでは内部テストトラックを、iOSではTestFlightを使用できる。これにより、チームと少数のテスターが、公開レビューを受ける前に実際のストア向けビルドを試す機会を得られる。何か問題があれば、早期に発見して修正し、プロダクション提出がリジェクトされるプレッシャーなしに再アップロードできる。
メタデータとスクリーンショットはビルドと一致しなければならない
リジェクトの最も一般的な理由の一つは、アプリの動作とストアの掲載情報との間の不一致だ。新しいバージョンで機能を追加したのに、スクリーンショットが古いインターフェースのままの場合、AppleやGoogleは誤解を招くとしてリジェクトする可能性がある。
パイプラインがここで役立つ。各バージョンのスクリーンショットとメタデータをコードと一緒に保存する。リリースをトリガーするとき、パイプラインはバージョン番号やリリースタグに基づいて正しいアセットを選択する。これにより、ストアにアップロードするものがバイナリに実際に含まれているものと一致することが保証される。
変更履歴については、簡潔で事実に基づいたものにすること。毎回のリリースで「バグを修正し、パフォーマンスを改善しました」と書いてはいけない。ユーザーはこれらを読む。さらに重要なことに、ストアのレビュアーも読む。変更履歴に「ダークモードを追加」と書いてあるのに、アプリにダークモードがなければ、それは問題だ。
リリーススケジュールにレビュー時間を組み込む
モバイルストアのレビューには時間がかかる。Appleは通常、アプリのアップデートに24〜48時間、新規アプリにはさらに長い時間を要する。Googleは通常より速く、時には数時間しかかからないが、常にキューが存在する。固定のリリース日がある場合、レビュー時間と再提出の可能性を考慮して、十分早くアップロードする必要がある。
最初のレビューが通ると想定してはいけない。経験豊富なチームでも、以下のような理由でリジェクトされることがある：
- 理由を説明せずにパーミッションを要求する
- プライベートAPIを使用する
- 不完全または不正確なメタデータ
- スクリーンショットと一致しないUI要素
- ストア固有のポリシー違反（Appleのアプリ内課金に関するルールなど）
リリース計画にバッファ時間を組み込むこと。金曜日までにアプリを公開する必要があるなら、遅くとも火曜日か水曜日までに提出することを目指す。そうすれば、問題を修正して再提出する余裕ができる。
レビュー通過後に何が起こるか
レビューがビルドを承認すると、リリースフェーズに入る。これはオール・オア・ナッシングの決定ではない。両方のストアが段階的ロールアウトをサポートしている。
Androidでは、段階的ロールアウトを使用して、ユーザーの10％や25％など、一定の割合にアップデートをリリースできる。iOSでは、フェーズドリリースを使用して、数日かけて徐々にアップデートをロールアウトできる。これにより、全員に展開する前に、クラッシュ率、ユーザーフィードバック、主要なメトリクスを監視できる。
パイプラインはこれをサポートする必要がある。レビュー通過後、パイプラインは初期ロールアウト率を設定し、監視期間を待ち、その後率を上げるかフルリリースに移行できる。何か問題が発生した場合、全ユーザーに影響を与えることなくロールアウトを停止できる。
ストアアップロードの実践的チェックリスト
- 公開レビューに提出する前に、内部またはクローズドテストトラックにアップロードする
- メタデータとスクリーンショットをコードと一緒にバージョン管理されたディレクトリに保存する
- バイナリアップロードだけでなく、メタデータ提出も自動化するためにストアAPIを使用する
- このバージョンで何が変更されたかを正確に説明する変更履歴を含める
- 目標リリース日の前に少なくとも48時間のバッファ時間を計画する
- デフォルトをフルリリースではなく、段階的ロールアウトまたはフェーズドリリースに設定する
- ロールバック計画を用意する：公開を停止する方法、または以前のバージョンに戻す方法を知っておく
まとめ
モバイルストアへのアップロードはゴールではない。レビュー、リジェクトの可能性、段階的ロールアウト、監視を含むプロセスの始まりだ。パイプラインがアップロードを最終ステップとして扱うなら、リジェクトやリリースの遅延に驚かされ続けるだろう。レビュープロセスをパイプライン設計に組み込み、まずテストトラックにアップロードし、常に再試行の余地を残しておくこと。それがモバイルリリースをストレスの多いイベントから日常業務に変える方法だ。