公開前のテストとリリース準備

この章で学ぶこと

• 公開前に何をどの環境で確認するか決める
• ストア申告と実際のデータ利用を一致させる
• 1つのビルドを段階的にテスト配布する

1. 自動チェックをそろえる

毎回同じ順で確認します。

dart format --output=none --set-exit-if-changed .
flutter analyze
flutter test

テストは次の層に分けます。

種類	確認すること
Unit test	入力検証、並び順、状態変化
Widget test	ボタン、エラー、読み込み、空表示
Repository test	保存成功、権限拒否、通信失敗
Rules test	未認証・別利用者を拒否する
Integration test	ログインから保存・削除まで
手動実機確認	キーボード、戻る操作、権限、通信切断

生成AIには正常系だけでなく、空文字、長い文字、連打、画面を閉じる、通信が戻る、時刻がずれる、といった失敗条件を挙げてもらいます。

2. 公開候補の接続先を固定する

公開候補を作る前に、次を記録します。

• GitのコミットID
• pubspec.yamlのversion
• FlutterとDartのバージョン
• 接続するFirebase Project ID
• Android applicationId / iOS Bundle ID
• 有効な機能フラグ
• 使用した署名方法

pubspec.yamlの例です。

version: 1.0.0+1

1.0.0は利用者向けの版、1はビルド番号です。AndroidとiOSの各ストアへ再アップロードするときは、必要に応じてビルド番号を増やします。

3. 実機テストの表を作る

少なくとも次を確認します。

項目	Web	Android	iOS
新規登録・ログイン・ログアウト	○	○	○
作成・再読込・削除	○	○	○
入力エラーと通信失敗	○	○	○
小さい画面・文字拡大	○	○	○
外部リンク・問い合わせ先	○	○	○
データ削除手順	○	○	○
広告のテストIDと同意	対象時	対象時	対象時

デバッグ版だけでなく、公開と同じreleaseビルドで確認します。AndroidとiOSのログイン連携では、ストア署名後の証明書やBundle IDが影響することがあります。

4. プライバシーと申告を準備する

次を説明できるようにします。

• 収集するデータ、目的、保存先、保存期間
• 第三者SDKへ送られるデータ
• 利用者がデータとアカウントを削除する方法
• 問い合わせ先
• 広告識別子、解析、クラッシュ情報の利用
• 生成AIへ利用者入力を送る場合の送信先と注意

プライバシーポリシーを書くだけでなく、アプリの実装、Google PlayのData safety、App StoreのApp Privacy、広告の同意画面を一致させます。SDKを追加すると送信データが変わることがあるため、リリースごとに見直します。

5. 段階的に配る

開発者の実機
  ↓
チーム内テスト
  ↓
少人数の外部テスト
  ↓
段階公開
  ↓
全体公開

WebはプレビューURL、AndroidはInternal testing、iOSはTestFlightを使います。テスターには「自由に触って」ではなく、シナリオと報告方法を渡します。

公開判定チェック

• 自動チェックがすべて成功した
• 本番のSecurity Rulesをテストした
• 3プラットフォームのrelease候補を実機確認した
• プライバシー、データ削除、問い合わせ先が公開されている
• ストア画像と説明が実際の画面・機能と一致する
• 管理者が2人以上いて、署名・更新手順を復旧できる
• エラー監視、予算通知、公開停止の担当が決まっている
• 広告はテスト広告で確認し、本番広告を自分でクリックしていない

やってみよう

自分のアプリ用の公開判定表を作り、各項目に「確認者」「確認日」「証拠となるURLやビルド番号」を追加してください。