このドキュメントには、Firebase アプリを本番環境にリリースする前に確認すべきベスト プラクティスと考慮事項のチェックリストが記載されています。
リリースに関する一般的なベスト プラクティス
本番環境にデプロイする前に、Firebase Local Emulator Suite(サポートされているプロダクトの場合)ですべての変更をテストしてください。入念なテストを行うことで、コストのかかるミスを防ぐことができます。
Firebase App Check がサポートされているすべてのサービスに対して、この適用を開始します。App Check を使用すると、実際のアプリだけがバックエンド サービスとリソースにアクセスできるようになります。
Firebase の一般的なセキュリティ チェックリストを確認します。
Firebase Remote Config ロールアウトを使用して、新機能やアップデートをアプリに安全かつ段階的にリリースします。
Firebase Crashlytics をまだ設定していない場合は、設定することを検討してください。これは軽量なリアルタイムのクラッシュ レポートツールで、アプリの品質を低下させる安定性の問題を追跡し、優先順位を付け、修正するのに役立ちます。
お支払いプランの上限を確認し、予算アラートを設定する
特に無料の Spark プランをご利用の場合は、本番環境に移行した後に使用量の上限と割り当てに達しないようにしてください。従量課金制の Blaze のお支払いプランへのアップグレードを検討してください。
プロジェクトの予算アラートを設定します。
予算アラートは予算の上限ではありません。構成したしきい値に近づいたときやしきい値を超えたときにアラートが送信されるため、アプリやプロジェクトで適切な対応を取ることができます。
アラートに応じて課金を無効にする関数など、高度なアラートとアクションを設定することを検討してください。
サービス固有のダッシュボード、または Firebase コンソールの中央の[使用量と請求額] ダッシュボードで使用状況をモニタリングします。
Firebase プロジェクトとアプリがベスト プラクティスに準拠していることを確認する
1 人のデベロッパーと大規模なチームのいずれにとっても、Firebase プロジェクト、アプリ、リソースを保護し、安全に保ち、チームの変化に合わせて進化させていくことが重要です。
Firebase プロジェクトは、Firebase のサービスと構成が有効になっている Google Cloud プロジェクトにすぎないことを覚えておくと便利です。つまり、Google Cloud で推奨されている多くのベスト プラクティスは Firebase にも適用できます。
開発、テスト、本番の環境にそれぞれ異なる Firebase プロジェクトを使用します。
本番環境アプリに関連付けられたプロジェクトに予期せずに公開されることがないよう制限してください。詳しくは、開発ワークフローの設定をご覧ください。
重要なプロジェクト(特に本番環境アプリに関連付けられているプロジェクト)を保護します。
プロジェクト リーエンを使用して、プロジェクトが誤って削除されないように保護します。
本番環境を簡単に識別できるように、Firebase コンソールで「Prod」タグを適用します。
Google Cloud 組織をまだ設定していない場合は設定し、そこに Firebase プロジェクトを追加することを検討してください。
Firebase プロジェクトに複数のオーナーを追加します(特に、プロジェクトが Google Cloud 組織に属していない場合)。詳しくは、Firebase プロジェクトのオーナーを割り当てるタイミングと方法をご覧ください。
プロジェクト メンバー(別名「プリンシパル」)を個別に追加するのではなく、Google グループとして追加します。
グループを使用すると、チームメンバーにロールを一括で割り当てたり、Firebase プロジェクトにアクセスできるユーザーを管理したりできます。特に、チームメンバーが交代した場合や、脱退した場合に便利です。
各プロジェクト メンバー(別名「プリンシパル」)に、Firebase プロジェクトとリソースに対する適切なアクセス レベルを付与します。詳しくは、Firebase IAM によるプロジェクトへのアクセス権の管理をご覧ください。
該当する各プロジェクト メンバー(別名「プリンシパル」)が、特定のプロダクトやプロジェクトの状態(お支払いプランの変更や割り当て上限など)に関するアラートを受け取るように設定していることを確認します。詳細については、Firebase アラートを受信するをご覧ください。
Firebase API キーを、キーの API 許可リストに登録する必要がある API のみに制限します。また、Firebase のセキュリティ チェックリストで API キーに関する情報もご確認ください。
アプリで使用する特定のサービスを準備する
アプリで使用している各プロダクトやサービスには、本番環境で使用する場合の具体的な考慮事項がある場合があります。
Google Analytics
アプリの起動時にアナリティクス データの収集を開始するための Google Analytics のオーディエンス条件を定義します。
Google Analytics データから BigQuery へのエクスポートを有効にすることを検討してください。これにより、BigQuery SQL でデータを分析したり、データをエクスポートして独自のツールで使用したりできます。
ユーザー プロパティを、アプリ全体のライフサイクルに関連する情報に限定します。作成できる数には上限があり、アーカイブできません。
Google Analytics プロパティとアカウントの Google Analytics ロールの設定を確認します。これらの権限は、Firebase プロジェクトの IAM 権限およびロールとは別に管理されます。
Firebase コンソールの [プロジェクトの設定] で、App Store ID とチーム ID(必要な場合)が正しいことを確認します。
App Check
Firebase コンソールの [プロジェクトの設定] で、チーム ID が正しいことを確認します。
まだ Firebase App Check をサポートするすべてのサービスに適用していない場合は、適用を開始します。App Check を使用すると、実際のアプリだけがバックエンド サービスとリソースにアクセスできるようになります。
Authentication
使用していないプロバイダ(特に匿名認証)を無効にします。
Google でログインをアプリで使用している場合は、OAuth 同意画面をカスタマイズします。
Authentication メール送信サービスのドメインと送信者をカスタマイズします。
Identity Platform SMS 確認サービスを使用している場合は、Firebase App Check の適用を開始し、SMS の不正使用からアプリを保護するように SMS リージョン ポリシーを構成します。
一般的な Authentication エラーに関するエラー処理を Apple プラットフォームに実装します。
Firebase コンソールの [プロジェクトの設定] で、アプリの署名証明書のリリース SHA-1 ハッシュを追加します。SHA-1 ハッシュは、アプリで電話番号ログインまたは Google でログイン(OAuth クライアントが必要)を使用している場合に必要です。
不正使用を防ぐためのドメインのアクセス制御を追加します。具体的には、Firebase コンソールの Authentication セクションで、本番環境ドメインへのアクセスを許可します(Firebase Security Rules に依存するプロダクトを使用している場合は特に重要です)。
Cloud Firestore
意図しないデータアクセスを防ぐために Cloud Firestore Security Rules を構成します。
リリースビルドでコード縮小用の ProGuard を使用します。ProGuard を使用しないと、Cloud Firestore SDK とその依存関係によって APK サイズが増加する可能性があります。
Cloud Messaging
Cloud Messaging データから BigQuery へのエクスポートを有効にすることを検討してください。これにより、BigQuery SQL でデータを分析したり、データをエクスポートして独自のツールで使用したりできます。
Firebase コンソールで、Apple アプリから Cloud Messaging 用の APNS 認証キーをアップロードします。APNS 証明書を使用する場合は、本番環境の APN 証明書がアップロードされるようにします。
Cloud Storage
- 意図しないデータアクセスを防ぐために Cloud Storage Security Rules を構成します。
Crashlytics
該当する各プロジェクト メンバー(別名「プリンシパル」)が、Crashlytics またはプロジェクトの状態(お支払いプランの変更や割り当て上限など)に関するアラートを受け取るように設定していることを確認します。詳細については、Firebase アラートを受信するをご覧ください。
Crashlytics データから BigQuery へのエクスポートを有効にすることを検討してください。これにより、BigQuery SQL でデータを分析したり、データをエクスポートして独自のツールで使用したりできます。
(ネイティブ Android と iOS のみ)Crashlytics で AI アシスタントを有効にすることを検討してください。これにより、クラッシュが発生した原因と対処方法を把握するのに要する時間を短縮できます。
Crashlytics で使用できるように、リリースビルド向け dSYM ファイルをアップロードします。Xcode が dSYM を自動的に処理してファイルをアップロードできるようにします。
Crashlytics で使用できるように、リリースビルド向け ProGuard マッピングをアップロードします。アップロードは Firebase CLI を使用して行うことができます。
Firebase を Google Play にリンクすると、Android アプリの状態をより詳しく把握できます。たとえば、アプリのクラッシュ レポートを Google Play トラックでフィルタできるため、ダッシュボードで特定のビルドに注目することができます。
Android をターゲットとし、IL2CPP を使用するビルドの場合は、コードや構成に変更があったかどうかにかかわらず、シンボルを取得する個々のビルド実行ごとにネイティブ シンボルをアップロードしてください。
Dynamic Links
- Dynamic Links は非推奨になっているため、このサービスから移行することをおすすめします。詳しくは、サポート終了に関するよくある質問をご覧ください。
Firebase ML
Performance Monitoring
該当する各プロジェクト メンバー(別名「プリンシパル」)が、Performance Monitoring またはプロジェクトの状態(お支払いプランの変更や割り当て上限など)に関するアラートを受け取るように設定していることを確認します。詳細については、Firebase アラートを受信するをご覧ください。
Performance Monitoring データから BigQuery へのエクスポートを有効にすることを検討してください。これにより、BigQuery SQL でデータを分析したり、データをエクスポートして独自のツールで使用したりできます。
Realtime Database
意図しないデータアクセスを防ぐために Realtime Database Security Rules を構成します。
スケーリングの準備が整っていることを確認します。Realtime Database には、ほとんどのアプリケーションに十分対応できるだけのデフォルトの割り当て容量がありますが、アプリによっては追加の容量が必要になる場合もあります。
Proguard Rules を設定して Realtime Database との連携を有効にします。
Remote Config
- 試験運用版の Remote Config ルールがリリース ユーザーに影響しないことと、適切なサーバーおよびアプリ内デフォルト値がアプリで配信されることを確認します。