· Publishing · 6分で読了

App Store Connect と Google Play Console の違い:公開ワークフロー比較

App Store Connect と Google Play Console の違い:公開ワークフロー比較
TL;DR.Apple はビルドとメタデータをまとめたバージョンを審査し、その後は自動・手動・スケジュールのリリース方法に加え、自動アップデートには7日間の段階的ロールアウトが用意されています。Google はトラックへのリリースを審査し、ストア掲載情報の編集は別経路として扱い、公開管理と割合ベースの段階的ロールアウトが用意されています。目的は同じでも仕組みは異なります。以下の表がその見取り図です。

1つのストアだけに配信するなら、そのコンソールの使い方を覚えれば済みます。しかし両方に配信するとなると、同じ言葉が違う意味を持つ、2つの異なる考え方を同時に頭に入れておく必要があります。「リリース」「審査」「ロールアウト」は、App Store Connect と Google Play Console でそれぞれ微妙に意味が異なります。この記事では、両ストアへの公開を計画する際にサプライズが起きないよう、2つのワークフローを段階ごとに並べて整理します。

ワークフローを並べて見る

まずはここから。各行はアップデートを公開するまでの段階を表し、2つの列はそれぞれのコンソールで実際に起きることです。

メタデータのみの編集ほとんどの掲載情報の変更は新しいバージョンとして審査を通る必要があり、即時反映できるフィールドはごく一部。ビルドを配信せずに、ストア掲載情報の変更として提出・審査される。

Apple がバージョンをリリースする仕組み

App Store Connect では、作業の単位は「バージョン」です。ビルドを紐付け、メタデータとスクリーンショットを入力し、まとめて App Review に提出します。Apple はこれを1つのパッケージとして審査するため、スクリーンショットの差し替えや説明文の微調整だけであっても、通常は新しいバージョンとして再度審査を受けることになります。

App Review が承認すると、選んだリリースオプションに応じて処理が決まります。自動を選べばすぐに公開されます。手動を選ぶと「Pending Developer Release(開発者によるリリース待ち)」の状態で止まります。Apple は承認済みですが、ボタンを押すまでは非公開のままです(押してから公開まで最大24時間かかることがあります)。スケジュールを選べば、設定した日時以降に自動で公開されます。これはバージョンごとに選択できるため、アップデートのたびに新しく判断できます。

段階的に展開したい場合はフェーズドリリースを有効にします。これは既存ユーザー向けの自動アップデートに適用され、7日間かけて公開割合を段階的に引き上げます。指標に異常があれば一時停止も可能です。新規アプリには適用されず、手動リリースにも適用されません。これは Google の段階的ロールアウトに相当するもので、リリース全体を保留するものではありません。

Google がトラックにリリースする仕組み

Google は同じ工程をトラックに分けています。ビルドはまずテストトラック(内部、クローズド、オープンのいずれか)から始まり、準備が整った段階で本番へ昇格します。内部テストは信頼できる少人数向け(最大100人)。クローズドテストは招待リストで拡大可能(リストあたり最大2,000人)。オープンテストは上限なしで一般公開の任意参加。本番は選択した国のすべてのユーザーが対象です。

リリースを公開しようとすると、公開管理が Apple の手動保留に相当する役割を果たします。これを有効にすると、承認済みの変更は公開概要画面の「送信準備完了」に集まり、実際に公開ボタンを押すまで反映されません。マーケティングの発表日に合わせるのに便利です。無効にしている場合は、審査を通過すればすぐに公開されます。

段階的に展開したい場合は段階的ロールアウトを使います。ユーザーの一定割合にリリースし、クラッシュ率が急上昇すれば止めながら、割合を引き上げていきます。Apple のフェーズドリリースと同様、これはアップデート向けであり初回リリースには適用されません。新規の本番リリースは全ユーザーに一斉配信されます。

つまずきやすい違い

覚えておくべき分岐点はこれです。Apple はメタデータをバージョンに紐づけ、Google はストア掲載情報とリリースを分離しています。

Apple では、スクリーンショット・説明文・キーワードは審査中のバージョンの一部です。ビルドの合間にスクリーンショットだけ更新したい場合でも、ほとんどのフィールドは新しいバージョンと再審査が必要になります。Google では、ストア掲載情報はそれ自体が独立したオブジェクトです。配信済みのアプリバンドルはそのままに、テキストや画像だけを更新して審査に出せます。「フルリリースなしでこれを変更できるか」という問いに対して、2つのストアはまったく違う答えを持っています。

これが特に重要になるのは、リリースに動くパーツが多いとき、つまりビルド、スクリーンショットセット、数十市場分のローカライズ済みテキストなどが絡む場合です。Apple では、すべてを1つのバージョンにまとめて一緒に審査してもらう形が基本になります。Google では、掲載情報とリリースを個別に準備し、計画に合わせて好きな順序で公開できます。

審査にかかる時間と新規アカウントの落とし穴

Apple の App Review は、2026年時点で通常のアップデートなら24〜48時間程度。新規デベロッパーの初回提出や、より詳しい確認が必要と判断された場合はもっと時間がかかります。Google の審査は多くの場合もっと速く、既存アカウントなら数時間から数日程度ですが、新規参入者には関門があります。

2023年11月中旬以降に作成された個人の Google Play デベロッパーアカウントは、本番アクセスを申請する前に、12人以上のテスターが参加した状態でクローズドテストを14日間連続して実施する必要があります。参加者が12人を下回ると、この連続日数がリセットされることがあります。組織アカウントや、それより前に作成された個人アカウントはこの要件が免除されます。Apple にはこれに直接相当するものがないため、両ストアで初めてアプリをローンチする場合は、Google のテスト期間をあらかじめ見込んでおきましょう。たいていこちらのほうが長くかかります。

Mokbi が役立つ場面

どちらのコンソールも、求めているのは同じ完成された素材です。必要なすべてのサイズで、フレーム付きスクリーンショットと整った翻訳済みコピー。Mokbi はその素材づくりを1回で済ませます。1つのプロジェクトでスクリーンショットをデザインし、ストア用テキストを作成した上で、両方を50の言語に翻訳し、App Store Connect と Google Play Console のサイズ要件に合わせたセットを一度のエクスポートで書き出せます。同じ作業を二度繰り返す代わりに、1回の作業で両方の掲載情報を用意できます。

Mokbi はその公開まで担います。Play Developer API を通じて掲載情報とアセットを Google Play へ直接送信し、App Store Connect ではバージョンを準備して提出できる状態にしておきます。Apple では最終的な提出(送信)のひと押しは自分で行う必要があり、審査そのものは Apple が行います(これは Mokbi の制約ではなく Apple のルールです)。どちらの場合も、1つの場所、1つのサブスクリプションから両コンソールの掲載情報を更新できます。エディタは透かし入りで無料利用でき、Solo(月額€29.99)または Studio(月額€49.99)にアップグレードすれば、契約を続ける限り無制限のエクスポートと公開が使えます。

Mokbi から両方の掲載情報を公開する →