store-publishing は何をしますか？
この手順は、2026-11-08に実際のGoogle Play Consoleと App Store Connectで最終確認されました。両コンソールは予告なく画面、フィールド名、ナビゲーションを変更することがあります。以下の手順が実際の画面と合わない場合は、推測せずにこのリポジトリでIssueを開き、修正を見つけた場合はプルリクエストを送信してください。
0. 現在の状況を確認する
| 状況 | 移動先 |
|---|---|
| アプリが未提出で、いずれのコンソールにもレコードがない | §1、次に§2、§3、§4 |
| アプリがすでに公開されており、新しいビルドをリリースする必要がある | §5（定期リリースパス） |
| アカウント関連の質問（個人 vs 組織、移行、パッケージ名） | §6 |
| レビュアーがログインできない、またはアプリがリジェクトされた | §7 |
すべてに適用されるルール：アップロードごとに、リリースされているすべての言語でリリースノートが必要です。「新機能」ボックスを空のままにしないでください。空のボックスは、レビュアーにとってテストされていないビルドと見なされます。
1. 初回セットアップチェックリスト（両ストア共通）
以下の順序で実行してください。各項目が次の項目の前提条件となります。
- デベロッパーアカウントが存在し、確認済みであること。 アプリは実際に製品を所有するアカウントから公開する必要があります。つまり、記録上の公開者であり、無関係なアプリで使用される共有アカウントや代理店アカウントではありません。特にAppleは、無関係な製品を多数保持するアカウントから提出された、商業化されたテンプレートやアプリ生成サービスに由来するように見えるアプリを拒否します。また（ガイドライン5.2.1）、知的財産権者が提出者であることを期待します。個人 vs 組織の判断については§6を参照してください。
- 法的ページが本番ドメインに存在すること： プライバシーポリシー、利用規約、およびアプリがサインアップを許可する場合はアカウント削除ページ。両ストアはこれらのURLを要求します。Googleのデータセーフティフォームは削除ページに直接リンクします。提出で使用する前に、製品を所有する責任者から法的テキストの承認を得てください。これはビジネス上の決定であり、技術的なものではありません。
- フレームワークのデフォルトではない実際のアプリアイコン-両ストアは、変更されていないデフォルトアイコンを低品質として拒否またはフラグ付けします。必要なアセット：バイナリ内のアダプティブ/フォアグラウンドアイコン、512×512のPlayアイコン、1024×500のPlay機能グラフィック、およびアセットカタログ内の1024×1024のAppleアイコン（透明は不可-Appleは通常黒で平坦化します）。
- レビューデモアカウント：アプリがサインインを必要とする場合。固定の識別子（電話、メール、またはユーザー名）と、その識別子に対してのみ有効な固定のワンタイムコードまたはパスワード、レビュアーが実際に操作できるシードされたデモ状態、および外部への副作用がないこと（実際のSMSや実際の課金は不可）。認証情報はコンソールページの外部に保存します。App Reviewノートにプレーンテキストで貼り付けて永続的で広く読み取り可能な記録にすることは絶対に避けてください。提出するたびに、提出する正確なビルドに対してログインが機能することを毎回確認してください。
- データインベントリ：アプリが収集するすべてのデータタイプ、その理由、および使用するSDKをリストした1つのドキュメント（リポジトリ内、wiki内、チームが仕様を保持する場所）。GoogleのデータセーフティフォームとAppleのアプリプライバシーフォームは、このドキュメントから記入します。メモリから記入することは絶対に避けてください。アプリが新しい権限または新しい分析/診断SDKを追加するたびに、インベントリは同じ変更で変更され、両方のフォームは次の提出前に再作成されます。フォームの内容とバイナリの実際の動作の不一致は、よくある回避可能なリジェクト理由です。
- Google Play-アプリを作成し、「アプリをセットアップ」を上から下へ進めます：プライバシーポリシーURL、アプリアクセス（公開、またはレビューアカウントと指示付きの制限付き）、広告宣言、コンテンツレーティングアンケート（アプリの実際の動作から正直に回答）、ターゲットオーディエンスと年齢、政府アプリ宣言、金融機能宣言、ヘルス宣言、データセーフティ（インベントリから）、広告ID宣言。Play App Signingを受け入れて、Googleがアプリアップキーを保持し、アップロードキーを交換可能にします。メインのストア掲載情報（名前、説明、アイコン、機能グラフィック、少なくとも2枚の電話スクリーンショット）を記入します。次に、本番に触れる前にクローズドテストトラックとリリースを作成します。
- Apple-明示的なApp IDを登録し、App Store Connectにアプリレコードを作成します（名前、SKU、プライマリ言語）。アプリ情報（カテゴリ、コンテンツ権利、年齢レーティング）、アプリプライバシー（インベントリから）、価格と提供状況、バージョンページ（スクリーンショット、説明、キーワード≤100文字、サポートURL、著作権）、App Review情報（必要な場合のサインイン手順、レビュー連絡先、メモ）を記入し、リリースオプションを選択します（手動リリースがより安全なデフォルトです-「公開」の決定を承認後に別の意図的なクリックに分離します）。TestFlightビルドの場合、毎回輸出コンプライアンスの質問に回答するか、該当する場合は
ITSAppUsesNonExemptEncryption=falseをInfo.plistに一度追加して、質問が繰り返されないようにします。 - 両方を早期に提出する。 各ストアでレビューには数時間から数日かかり、最初のレビューで実際の問題が表面化するのが通常です。少なくとも1回のリジェクトと再提出を見込んで予算を立ててください。特にAppleでは。
2. リリースパッケージのビルド
ツールチェーン（Flutter、React Native、Expo、またはネイティブのSwift/Kotlinプロジェクト）に関係なく、リリースされる正確なコミットのクリーンチェックアウトからビルドします。コミットされていない変更があるワーキングディレクトリからは決してビルドしないでください。コミットされていない編集がストアバイナリにリークすると、後で気づくのが非常に困難です。
- Android：署名済みリリースAABを生成します（ストアアップロードの場合はAPKではなく）。ビルド番号（
versionCodeまたは同等のもの）は、最後に出荷されたものよりも厳密に高いものにします。アップロードする前に、バンドルに埋め込まれたパッケージ名がターゲットのPlayアカウントが所有するものと一致することを確認してください。一致しないパッケージ名はアップロードステップで失敗します。 - iOS：アーカイブしてエクスポートします（またはアーカイブステップからApp Store Connectに直接アップロードします）。正しいApple Developer Programメンバーシップ（アプリの証明書とアプリレコードの両方が属する「チーム」）で署名し、ビルド番号は最後に出荷されたものよりも厳密に高く、App Store Connectレコードが作成されたのと同じバンドル識別子を使用します。正しいチームでの自動署名により、ほとんどの証明書の問題を回避できます。
- 両方：ビルドをステージングやローカルではなく、本番API/バックエンドに向けます。これが実際にバイナリに組み込まれていることを確認してください。ビルドフラグとして渡されてデフォルトに静かにフォールスルーする可能性のあるものではありません。製品に共有バージョン文字列がある場合は、iOSとAndroidで同じビルド/バージョン番号を維持します。これにより、「バージョン2.3」に関するサポート会話が両方のプラットフォームで同じ意味になります。
3. スクリーンショット
実際のキャプチャのみ-Appleのガイドライン2.3.3は、モックアップやマーケティング用コンポジットをスクリーンショットとして提示することを明示的に拒否しています。信頼できるパターンは、実際のアプリを実行し、実際の（モックではない）バックエンドに対してレビューアカウントでログインし、各画面に移動してフレームをキャプチャする自動UIテストです。シミュレーターのハンドヘルド電話写真ではありません。
カバーする一般的なデバイスサイズ（これらに依存する前に現在のストア要件を確認してください。変更される可能性があります）：大型の最新iPhone（Appleの現在の「最大」要件）、アプリがiPadをサポートする場合はiPad、およびPlay用の代表的なAndroid電話および/またはタブレット。Appleはほとんどの場合、最大セットから自動的に小さいiPhoneサイズを導出します。
製品のストーリーを順に伝える小さなセット（5〜8枚の画像）を選択します：リストまたはホームビュー、コア構造画面、単一ユニット/詳細ビュー、進行中のメインワークフロー、完了/成功状態、および該当する場合は設定。裸のログイン画面と空の状態はスキップしてください。アプリが何をするかについて何も語っていません。
既知の落とし穴（ツールチェーンに依存しない）：
- デバッグビルドは、多くの場合、目に見えるデバッグリボンやウォーターマークを表示します。キャプチャする前にオフにしてください。
- シミュレーターまたはエミュレーターセッションは、再インストール後も以前のログインを保持できます。テスト内で明示的にログアウトするか、最初にシミュレーター/エミュレーターの状態をワイプします。
- 異なるパラメーターで「同じ」画面に再移動すると、ステートフル画面がきれいに再レンダリングされないことがあります。キャプチャの間に親画面を経由して移動します。
- 同じプロジェクトディレクトリから2つのキャプチャセッションを同時に実行すると、生成されたビルドアーティファクトで競合する傾向があります。並行して実行する場合は、別のワーキングコピーを使用します。
4. 更新フロー（アプリがすでに公開されている場合）
専用の定期リリースチェックリストについては§5を参照してください。短いバージョン：新しいビルドは、最後に出荷されたものよりも厳密に高いビルド番号を取得し、最後のリリース以降のデータインベントリの差分によってプライバシーフォームの更新が必要かどうかが決まり、リリースノートは決してスキップされず、レビューデモアカウントは、提出のたびに新しいバイナリが指す正確な環境で再確認されます。
5. 定期リリースパス-アプリがすでに公開されている場合のリリース
1回のリリース=このリストを上から下へ1回実行します。
前提条件（いずれかが失敗した場合は停止）
- 出荷されるコードが実際に本番環境にデプロイされており、データベースマイグレーションがすでに適用されていること。デプロイとマイグレーションは同じステップではありません。マイグレーション前にデプロイする（またはまったくマイグレーションしない）と、バックエンドと通信するビルドが生成されますが、そのバックエンドは準備ができていません。
- レビューデモアカウントが本番環境に対してログインし、レビュアーが確認する必要があるデモ状態に到達すること。
- 最後に出荷されたビルド以降のデータインベントリの差分がチェックされていること。新しい行がある場合は、リジェクトが指摘する前ではなく、提出前にプライバシーフォームを変更する必要があります。
- Appleのバージョンスロットが空いていること。 以前のバージョンが「保留中-デベロッパーによるリリース」またはレビュー中の場合、App Store Connectは次のバージョン行を作成できません。最初に保留中のバージョンをリリースするかキャンセルしてください。「これを保留し、代わりに新しいビルドを提出する」オプションはありません。
- バージョン文字列とビルド番号が決定されていること：ビルド番号=最後に出荷された番号+1（各プラットフォーム）。バージョン文字列は、ユーザーが実際に気付く変更がある場合にのみバンプします。
リリースノート
実際に出荷されたもの（最後のリリース以降のマージされた変更）から作成し、ユーザーに表示される項目のみ、約4〜8個の箇条書きで、リストがサポートするすべての言語で記述します。複数の言語が必要だと仮定する前に、リストが実際にどの言語を持っているかを確認してください。1つの言語のみ設定されたリストは、その言語に対してリリースノートフィールドを拒否します。Appleでは、リストに新しい言語全体を追加することは独自のプロジェクトです（名前、サブタイトル、説明、キーワード、独自のスクリーンショットセット）。単なるテキストボックスの変更であると想定しないでください。
スクリーンショット
画面が購入者が気付く方法で実際に変更された場合のみ、スクリーンショットをやり直します。それ以外の場合は、既存のセットをそのままにします。置き換える場合は、追加するのではなく、以前と同じ順序でセット全体を置き換えます。ほとんどのコンソールはリストあたりのスクリーンショット数に上限があるため、部分的な置き換えはその上限に達するリスクがあります。
コンソール
Google Play：インベントリが変更された場合は、最初にデータセーフティフォームを更新します。次に：該当するテストまたは本番トラック→新しいリリースを作成→AABをアップロード→設定されたすべての言語でリリースノート→リリースをレビュー→ロールアウトを開始（「ロールアウトを開始」を意図的で確認されたアクションとして扱います。Playフローで元に戻せないクリックです）。本番ロールアウトはパーセンテージで段階的に行い、数パーセント後に何か問題があるように見える場合は一時停止できます。
Apple App Store Connect：最初に新しいビルドをTestFlightに添付します（輸出コンプライアンス、「何をテストするか」）。次に、既存のバージョンページを編集するか（バージョン文字列が変更されておらず、以前のバージョンがまだリリースされていない場合）、新しいバージョンを作成します（現在「提出準備中」のバージョンがない場合のみ可能-上記の前提条件を参照）。App Review情報がまだ正確であることを再確認し、インベントリが変更された場合はApp Privacyを再確認し、新しいビルドを選択し、「新機能」を記入し、レビューのために提出します。「レビューのために提出」をPlayのロールアウトクリックと同じように扱います。意図的で確認されたアクションであり、自動的に起動するものではありません。
記録保持
チームがリリースのためにすでに持っている記録保持（変更ログ、リリースIssue、スプレッドシート）には、出荷されたバージョンとビルド番号、アップロード時間、どのトラック/ステージ、誰がロールアウトまたは提出を確認したか、判明した場合はレビュー結果を含める必要があります。プロジェクト自身のバージョンファイルを実際に出荷されたものと一致するようにバンプします。ここでの不一致は、次のリリースが誤ってビルド番号を再利用する原因になります。
準備されたバージョンを放置しない
App Store Connectで「提出準備中」のバージョンは、利用可能な唯一のバージョンスロットを保持します。その下に新しいバージョンを作成することはできません。したがって、準備されたバージョンが準備されたのと同じセッションでその運命を決定してください。提出するか、まだ行を作成しないかのいずれかです。
準備された古いバージョンがまだ放置されている間に新しいビルドの準備ができた場合は、放置された行を削除したり、スロットを空けるためだけに古いビルドを提出したりしないでください。バージョンが「提出準備中」にある間、そのバージョン文字列はまだ編集可能なフィールドです。その場で前方にロールします：バージョン文字列を新しいものに変更し、新しいビルドを添付し、「新機能」を置き換えます。スクリーンショット、レビューノート、プライバシー回答は引き継がれるため、準備されたものは無駄になりません。
テスタービルド（TestFlight）とパブリック提出は独立した決定です。特にTestFlightの内部テストトラックはレビューもバージョン行も必要としません。したがって、「テスターが今日ビルドを必要としている」ことがパブリック提出を待たせる理由になることは決してなく、保留中のパブリック提出がテスターを待たせる理由になることも決してありません。
6. アカウント、移行、パッケージ名
- ポリシーカットオフ日（この記事の執筆時点では2023年11月13日-現在のポリシーを確認）以降に作成された個人のGoogle Playデベロッパーアカウントは、最低限のテスター数でクローズドテストを完了する必要があります。
…
（翻訳の都合で一部省略）