モバイルアプリの新しいバージョンを本番環境にロールアウトすることは、アプリ開発の最も楽しみな部分の一つですが、最もストレスの多い作業でもあります。チームは、バージョンの取り込み、新しいバグとそのバグの影響、以前のリリースとの比較などを追跡する必要があります。
このページでは、モバイルアプリ リリースについて確信を持つために必要なデータをモニタリングするために Firebase が提供するいくつかのツールについて説明します。
リリース モニタリング ダッシュボードを使用して、リリース関連データを確認します。
Firebase コンソールのリリース モニタリング ダッシュボードでは、Firebase Crashlytics が提供されています。これは、最新の本番環境リリースをモニタリングする単一のダッシュボードです。ダッシュボードはほぼリアルタイムで更新され、クラッシュの影響を受けていない指標、バージョンの取り込み、以前のリリースとの比較、リリースの新しい問題など、最も重要なリリース指標の概要が表示されます。
この新しいダッシュボードは、コンソールの [最新リリース] ページを改善したものです。このページと比較すると、[Release Monitoring] ダッシュボードのほうが情報が追加され、Google アナリティクスを必要とせずに有用なデータが表示され、より高速に読み込まれます。
ダッシュボードの機能
リアルタイム レポート
すべてのグラフはほぼリアルタイムで更新されます。最新バージョンをデプロイするとすぐに、ユーザーがそのリリースを利用し始めるのを確認できます。一部のユーザーでクラッシュが発生した場合、クラッシュの影響を受けていない指標のグラフでその影響をすぐに確認できます。以前のリリースに基づく比較とベンチマーク
最新リリースの安定性を以前のリリースと比較して確認できます。ダッシュボードでは、最新のリリースと以前にリリースされたビルドから最大 2 つのライブ指標を比較できます。主な新しい問題
最新リリースの新しいクラッシュが表示されます。[主な新しい問題] の表では、最新リリースで最初に検出された問題の影響をモニタリングでき、リリースを中止するかロールバックするかを迅速に判断できます。
ダッシュボードの要件
[Release Monitoring] ダッシュボードで最新リリースを表示する方法は次のとおりです。
アプリで少なくとも次のバージョンの Crashlytics SDK を使用していることを確認します。
Apple プラットフォーム: v10.8.0 以降 | Android: v18.6.0 以降（BoM v32.6.0 以降） | Flutter: v3.4.5 以降 | Unity: 11.7.0 以降アプリの新しいバージョンを製品版に公開して、最新のリリースで十分な数のエンゲージメント ユーザーを獲得できるようにします。
ダッシュボードに関するよくある質問
アクティブ ユーザー数のグラフに表示される値はどのように決定または計算されるのですか？
まず、アクティブ ユーザー数グラフに関連する用語をいくつか理解しておくと役立ちます。
セッションとは、ユーザーがアプリを操作している連続した期間です。新しいセッションは、アプリをコールド スタートしたときに開始するか、少なくとも 30 分間バックグラウンドで実行した後にフォアグラウンドで実行したときに開始されます。
特定のビルドのアクティブ ユーザー数は、そのビルドを使用してセッションを開始したユーザーの数で、時間別にグループ化されます。
合計（アクティブ）ユーザー数: セッション対応 SDK バージョンを使用するアプリの任意のビルドでセッションを開始したユーザーの数（時間別）です。
[アクティブ ユーザー] グラフのグラフに常に表示されるアクティブ ユーザーの割合と数は、過去 60 分間のものです（過去 60 分間にアクティブ ユーザーがいなかった場合は、過去 1 時間にデータが存在していた時間）。たとえば、次のスクリーンショットの例では、過去 60 分間に 6.0.0 (600) ビルドのアクティブ ユーザーが 90 人いました。これは、アプリの総（アクティブ）ユーザー数の 22.1% を占めています。
![[<i>リリース モニタリング</i>] ダッシュボードの [アクティブ ユーザー数] グラフの例のスクリーンショット](/static/docs/release/images/release-monitoring_active-users-chart.png)
[アクティブ ユーザー] グラフの線にカーソルを合わせると、アクティブ ユーザーの割合が、カーソルを置いた時間のアクティブ ユーザー数から計算されます。
アクティブ ユーザーの割合を表示するには、よくある質問の「リリース モニタリング ダッシュボードに表示されるビルドはどれですか？」で説明されている要件を満たす少なくとも 2 つのビルドをリリースしている必要があります。
アラートを設定する
Crashlytics を含むいくつかの Firebase プロダクトでは、プロダクト固有のさまざまな理由でアラートを送信できます。アラートを受信するには、必要な権限が必要です。
最新リリースの安定性をモニタリングするには、Performance Monitoring と Crashlytics の両方でアラートを設定します。特に Crashlytics では、次のアラートを設定できます。
ベロシティ アラートを使用すると、アプリ内の個々の問題が Firebase コンソールで定義したしきい値を超えた場合に、チームに通知できます。
新しい問題や回帰する問題に関するアラートを、任意の通知チャンネルに送信します。
Cloud Functions for Firebase を使用して、サードパーティ サービスへの高度なアラートを設定します。
リリース前にスムーズにリリースできるようにする
最新バージョンをリリースする前に、リリースをスムーズに行うために、次のサービスと機能の使用を検討してください。
プレリリース版のテストサービスを使用する
Firebase には、プレリリース テストに役立つ 2 つのプロダクト（Test Lab と App Distribution）が用意されています。これらのサービスはどちらも CI/CD フローに統合できます。
Firebase Test Lab は、クラウドベースのアプリテスト インフラストラクチャです。さまざまなデバイスと構成でアプリをテストできるため、実際のユーザーの環境でアプリがどのように動作するかを早期に把握できます。
信頼できるテスターに最新のビルドを配布する準備ができたら、Firebase App Distribution を使用します。Apple プラットフォームと Android のプレリリース版ディストリビューションの両方を同じ場所から管理できます。
ロールアウト サービスと限定テストサービスを使用する
Firebase Remote Config を使用して、パーセンテージ ロールアウト メカニズムで新機能をリリースするか、制限付きのテストグループでこれらの機能をテストします。
Firebase では A/B Testing も提供しているため、アプリの UI、機能、エンゲージメント キャンペーンに対する変更をテストし、主要な指標（収益や維持率など）に対する変更を広範囲にロールアウトする前にテストできます。