version: "1.0.0" name: mobile-app-release description: App Store / Google Play へのストア申請・審査対応・リリース運用をカバーするスキル。新規アプリの初回申請から、リジェクト対応・段階的ロールアウト・アップデート管理まで必要なときに参照する。

モバイルアプリ ストア申請・リリース

目的

• App Store / Google Play の審査を通過し、確実にアプリを公開する
• 審査リジェクトを事前に防ぎ、リリース計画を安全なスケジュールで組む
• 公開後の段階的ロールアウト・クラッシュ監視・アップデート誘導を初期から設計する

使うタイミング

• 新規アプリを初めてストアに申請するとき
• リジェクトされた理由を分析して再申請方針を立てるとき
• 掲載文・スクリーンショットを最適化したいとき
• アプリ内課金・サブスクリプションを新規導入するとき
• メジャーバージョンアップのリリース計画を立てるとき

進め方

1. リリース計画の策定

審査期間は平均1〜3日だが、初回・大規模変更・連休前後は1週間以上かかる場合がある。 固定日リリースの約束は厳禁。「審査通過後にリリース」を前提とした日程を [[project-management]] と連携して組む。

1. ストア掲載物の準備

• アプリ名・サブタイトル: 検索キーワードを含め30文字以内に収める
• 説明文: 最初の3行で価値を伝える(「続きを読む」の前が勝負)
• スクリーンショット: 最初の2枚でコアユースケースを訴求。テキストオーバーレイでメリットを明示
• プレビュー動画: オプションだが高CVR。15〜30秒で実際の操作を見せる
• アイコン: 1024×1024px(iOS) / 512×512px(Android)、透過なし

1. プライバシー申告

Apple プライバシーラベル・Google データセーフティを正確に埋める。 自社コード以外に導入している SDK(アナリティクス・広告・クラッシュレポート)が収集するデータも申告対象。 見落としは審査リジェクトおよびコンプライアンスリスクになる([[legal-compliance]])。

1. 審査用情報の整備

• デモアカウント: ログイン必須アプリは必ず用意。審査者が機能に辿り着けないとリジェクト
• レビューノート: 審査者向けに操作手順・特殊条件・外部サービス依存を日本語/英語で記載
• アプリ内課金: デジタルコンテンツはストア課金必須。手数料15〜30%を収益計画に織り込む([[monetization]])

1. テスト配信

• iOS: TestFlight 内部テスト(最大100名) → 外部テスト(最大1万名・簡易審査あり)
• Android: 内部テスト → クローズドテスト → オープンテスト → 製品版、の順に段階拡大

1. リリース

• 段階的ロールアウト(Android: 1% → 5% → 20% → 100%)を活用し、障害時の影響範囲を限定
• iOS は段階公開(Phased Release)を有効化。異常検知時は一時停止可能

1. リリース後の運用

• クラッシュ率・ANRをリリース直後24時間は集中監視([[monitoring-operations]])
• 強制/推奨アップデート誘導の仕組みを初期から組み込む(後付けは困難)
• ストアレビューには48時間以内に返信。低評価ユーザーへの誠実な対応は評価向上につながる

1. リジェクト対応

理由を正確に読む → 該当ガイドライン条項を確認 → 修正 or レビューノートで誤解を解く → 再申請。 理不尽な判断には App Review Board への異議申し立てが可能。感情的な反論は禁止。

審査ガイドラインの地雷

成果物テンプレート

# ストア申請チェックリスト
 
## 掲載物
-[ ] アプリ名・サブタイトル(検索キーワード含む、iOS30文字/Android50文字以内)
-[ ] 説明文(最初の3行でコアバリューを訴求)
-[ ] スクリーンショット(全対応サイズ: iOS 6.7"/5.5", Android phone/tablet)
-[ ] スクリーンショット1〜2枚目でコアユースケースを表現済み
-[ ] アイコン(iOS 1024px / Android 512px、透過なし)
-[ ] プレビュー動画(任意)
 
## プライバシー申告
-[ ] 自社コードの収集データを洗い出し済み
-[ ] 導入 SDK 一覧とそれぞれの収集データを確認済み
-[ ] Apple プライバシーラベル / Google データセーフティ を記入・提出済み
-[ ] プライバシーポリシー URL が有効
 
## 審査用情報
-[ ] デモアカウント(ID / パスワード)を ReviewNotes に記載
-[ ] ロック機能・特殊条件の操作手順を ReviewNotes に記載
-[ ] 外部サービス依存(API・ハードウェア等)がある場合は説明を追加
-[ ] アプリ内課金アイテムをすべて登録済み
 
## テスト配信
-[ ] TestFlight(iOS) / 内部テスト(Android)で社内確認済み
-[ ] クローズドβ で想定外クラッシュなし
 
## リリース計画
-[ ] 段階的ロールアウト設定(Android: 初期 1〜5%)
-[ ] iOS Phased Release を有効化
-[ ] クラッシュ監視アラート設定済み([[monitoring-operations]])
-[ ] 強制/推奨アップデート誘導ロジック実装済み
-[ ] ストアレビュー返信担当者・フロー確認済み

チェックリスト

• [ ] 審査通過後リリースを前提としたスケジュールになっている
• [ ] プライバシーラベル / データセーフティに SDK の収集データを含めた
• [ ] Sign in with Apple を実装済み(サードパーティログインを実装している場合)
• [ ] UGC 機能に通報・モデレーション・ブロックがある
• [ ] デモアカウントを ReviewNotes に記載した
• [ ] 年齢レーティングがコンテンツと一致している
• [ ] 強制アップデート誘導の仕組みが初期実装に含まれている
• [ ] 段階的ロールアウトとクラッシュ監視の設定が完了している

アンチパターン

• 審査期間を見込まないスケジュール: 「審査通過 = リリース日」で顧客に約束するのは危険
• 初回申請に全機能を盛り込む: リジェクト箇所の特定が困難になる。MVPで申請し機能追加はアップデートで
• 権限を起動時に一括要求: ユーザーが拒否しやすくなり機能不全のリスク。利用直前に個別要求する
• レビューノート空欄: 審査者が機能に辿り着けずリジェクト。操作手順を具体的に書く
• リジェクトに感情的に反論: 審査者との関係を悪化させる。事実と対応策を冷静に記述する
• 外部課金リンクを規約変動前の情報で実装: App Store の外部課金規約は頻繁に変わるため公式ドキュメントを必ず確認
• プライバシー申告の後回し: 申請直前に調査すると SDK 置き換えが必要になる場合がある

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

関連スキル

• [[project-management]] — 審査を見込んだリリーススケジュール管理
• [[legal-compliance]] — プライバシーポリシー・データ収集申告の法的要件
• [[monetization]] — アプリ内課金・サブスクリプション設計と手数料計算
• [[monitoring-operations]] — リリース後のクラッシュ監視・アラート設定
• [[growth-launch]] — リリース後のASO・ユーザー獲得施策
• [[testing]] — TestFlight / クローズドβ でのテスト設計
• [[cicd-deployment]] — ビルド自動化・ストアへの自動アップロード(Fastlane等)
• [[i18n-localization]] — 多言語対応とローカライズされた掲載文管理
• [[orchestration]] — モデル委譲の基本原則