コンソールへ移動

FCM メッセージについて

Firebase Cloud Messaging(FCM)には、メッセージングに関する幅広いオプションと機能が用意されています。このページの情報は、さまざまなタイプの FCM メッセージについて理解し、そのようなメッセージを何に使用できるかを把握するために提供されています。

メッセージのタイプ

FCM では、次の 2 つのタイプのメッセージをクライアントに送信できます。

  • 通知メッセージ。「表示メッセージ」と見なされることもあります。FCM SDK によって自動的に処理されます。
  • データ メッセージ。クライアント アプリによって処理されます。

通知メッセージには、ユーザーに表示される事前定義キーが含まれます。一方、データ メッセージにはユーザー定義の Key-Value ペアだけが含まれます。通知メッセージには、オプションのデータ ペイロードを含めることができます。どちらのメッセージ タイプも最大ペイロードは 4 KB です。ただし、Firebase コンソールからメッセージを送信する場合は例外で、この場合は 1,024 文字の制限が適用されます。

使用シナリオ 送信方法
通知メッセージ クライアント アプリの代わりに FCM によってエンドユーザーのデバイスにメッセージが自動表示されます。通知メッセージには、ユーザーに表示される事前定義キーと、オプションであるカスタムの Key-Value ペアのデータ ペイロードを含めることができます。
  1. Cloud Functions やアプリサーバーなどの信頼できる環境で、Admin SDK または FCM サーバー プロトコルを使用し、notification キーを設定します。オプションのデータ ペイロードを含めることができます。常に折りたたみ可能です。
  2. Notifications Composer を使用し、メッセージのテキストやタイトルなどを入力して送信します。カスタムデータを指定することで、オプションのデータ ペイロードを追加できます。
データ メッセージ クライアント アプリがデータ メッセージの処理を行います。データ メッセージにはカスタムの Key-Value ペアだけが含まれます。 Cloud Functions やアプリサーバーなどの信頼できる環境で、Admin SDK または FCM サーバー プロトコルを使用し、data キーのみを設定します。

クライアント アプリに代わって FCM で通知の表示を処理する場合は、通知メッセージを使用します。クライアント アプリでメッセージを処理する場合は、データ メッセージを使用します。

FCM は、オプションのデータ ペイロードを含む通知メッセージを送信できます。その場合は、FCM によって通知ペイロードの表示が処理され、クライアント アプリによってデータ ペイロードが処理されます。

通知メッセージ

テストやマーケティング、ユーザーの再エンゲージメントのために、Firebase コンソールを使用して通知メッセージを送信できます。Firebase コンソールは、マーケティング メッセージの改善に役立つ、アナリティクスに基づいた A/B テストを提供します。

Admin SDK または FCM プロトコルを使用して通知メッセージをプログラムで送信するには、notification キーを使って、通知メッセージのユーザー表示部分に対応する事前定義された Key-Value オプションの中から必要なものを設定します。例として、IM アプリで使用する JSON 形式の通知メッセージを以下に示します。ユーザーのデバイスに表示されるメッセージのタイトルは「Portugal vs. Denmark」、テキストは「great match!」です。

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

アプリがバックグラウンドで動作中の場合、通知メッセージは通知トレイに配信されます。アプリがフォアグラウンドで動作中は、コールバック関数によってメッセージが処理されます。

通知メッセージの作成に使用できる事前定義キーの完全な一覧については、リファレンス ドキュメントをご覧ください。

データ メッセージ

データ ペイロードをクライアント アプリに送信するには、適切なキーにカスタム Key-Value ペアを設定します。たとえば、以下は上記と同じ IM アプリ内の JSON 形式のメッセージですが、情報は共通の data キー内にカプセル化されており、クライアント アプリがそのコンテンツを解釈する必要があります。

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

上記の例では、トップレベル、つまり共通の data フィールドが使用されています。このフィールドは、メッセージを受信するすべてのプラットフォーム上でクライアントによって解釈されます。クライアント アプリは、それぞれのプラットフォームのコールバック関数でデータ ペイロードを受信します。

オプションのデータ ペイロードを含む通知メッセージ

プログラムと Firebase コンソールのどちらからでも、カスタムの Key-Value ペアのオプション ペイロードを含む通知メッセージを送信できます。Notifications Composer では、[詳細オプション] の [カスタムデータ] フィールドを使用します。

通知ペイロードとデータ ペイロードの両方を含むメッセージを受信したときのアプリの動作は、そのアプリがバックグラウンドとフォアグラウンドのどちらで動作しているか、つまり実質的に、メッセージの受信時にそのアプリがアクティブであるかどうかによって異なります。

  • バックグラウンドにある場合、アプリは、通知トレイで通知ペイロードを受け取り、ユーザーが通知をタップしたときにのみデータ ペイロードを処理します。
  • フォアグラウンドにある場合、アプリは、どちらのペイロードも取得できる状態でメッセージ オブジェクトを受け取ります。

以下に notification キーと data キーの両方を含む JSON 形式のメッセージを示します。

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

プラットフォーム間でのメッセージのカスタマイズ

Firebase Admin SDK と FCM v1 HTTP プロトコルの両方を使用すると、メッセージ リクエストで message オブジェクト内のすべてのフィールドを設定できます。これには以下のフィールドが含まれます。

  • メッセージを受け取るすべてのアプリ インスタンスによって解釈される共通のフィールド セット。
  • AndroidConfigWebpushConfig など、プラットフォーム固有のフィールド セット。指定されたプラットフォームで実行されているアプリ インスタンスによってのみ解釈されます。

プラットフォーム固有のブロックを使用すると、各種プラットフォームで受信時に正しく処理されるようにメッセージを柔軟にカスタマイズできます。FCM バックエンドは、指定されたすべてのパラメータを考慮に入れて、プラットフォームごとにメッセージをカスタマイズします。

共通フィールドを使用する場合

次の場合は共通フィールドを使用します。

  • iOS、Android、ウェブのすべてのプラットフォームのアプリ インスタンスをターゲットにする
  • トピックにメッセージを送信する

プラットフォームに関係なく、すべてのアプリ インスタンスは次の共通フィールドを解釈できます。

プラットフォーム固有のフィールドを使用する場合

次の場合はプラットフォーム固有のフィールドを使用します。

  • 特定のプラットフォームにのみフィールドを送信する
  • 共通フィールドに加えてプラットフォーム固有のフィールドを送信する

特定のプラットフォームだけに値を送信する場合は、共通フィールドを使用せずにプラットフォーム固有のフィールドを使用してください。たとえば、Android を除いて iOS とウェブのみに通知を送信するには、2 つの異なるフィールド セット(iOS 用とウェブ用に 1 つずつ)を使用する必要があります。

特定の配信オプションを持つメッセージを送信する場合は、プラットフォーム固有のフィールドを使用してそれらのオプションを設定します。必要に応じてプラットフォームごとに異なる値を指定できます。ただし、プラットフォーム間で基本的に同じ値を設定したい場合でも、プラットフォーム固有のフィールドを使用する必要があります。これは、プラットフォームごとに値の解釈が若干異なる可能性があるためです。たとえば、有効期間は Android では秒単位で設定されますが、iOS では有効期日として設定されます。

例: プラットフォーム固有の配信オプションを使用した通知メッセージ

次の v1 send リクエストは、すべてのプラットフォームに共通の通知タイトルとコンテンツを送信しますが、プラットフォーム固有のオーバーライドも送信します。リクエストの詳細は次のとおりです。

  • Android およびウェブ プラットフォームに対しては長い有効期間を設定し、APNs(iOS)メッセージには低い優先順位を設定します。
  • Android および iOS でユーザーが通知をタップしたときの結果を定義するために、それぞれ適切なキー(click_action および category)を設定します。
{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

メッセージ本文のプラットフォーム固有のブロックで使用できるキーの詳細については、HTTP v1 のリファレンス ドキュメントをご覧ください。メッセージ本文が含まれる送信リクエストの作成方法の詳細については、送信リクエストを構築するをご覧ください。

配信オプション

FCM では、Android デバイスに送信されるメッセージ用の特定の配信オプションが提供されており、iOS とウェブで同様のオプションを使用できます。たとえば、「折りたたみできる」メッセージの動作は、Android、iOS、JavaScript/ウェブで、それぞれ FCM の collapse_keyapns-collapse-idTopic によってサポートされています。詳細については、このセクションの説明と関連するリファレンス ドキュメントをご覧ください。

折りたたみできないメッセージと折りたたみできるメッセージ

折りたたみできないメッセージとは、デバイスへの配信が個別に行われるメッセージです。折りたたみできないメッセージは、モバイルアプリにサーバーからデータをフェッチさせるための単なる合図ではなく、実際に意味のあるコンテンツを配信します。

折りたたみできないメッセージは、チャット メッセージや重要なメッセージでよく使用されます。たとえば、IM アプリでは、メッセージごとにコンテンツが異なるため、すべてのメッセージを配信する必要があります。

Android の場合、折りたたむことなく保存できるメッセージ数の上限が 100 件になっています。上限に達した場合は、保存されているすべてのメッセージが破棄されます。デバイスがオンラインに戻ったとき、メッセージ数の上限に達したことを示す特別なメッセージが届きます。この場合、通常はアプリサーバーとの完全な同期をリクエストすることで、アプリは状況に適切に対処できます。

折りたたみできるメッセージとは、まだデバイスに配信されていない場合に新しいメッセージで置き換えることができるメッセージです。

折りたたみできるメッセージがよく使用されるのは、サーバーとのデータの同期をモバイルアプリに指示するような場合です。たとえば、ユーザーに最新スコアを知らせるスポーツアプリなどで使われます。こうした場合は、最新のメッセージのみが重要になります。

Android でメッセージを折りたたみ可能としてマークするには、メッセージ ペイロードに collapse_key パラメータを含めます。FCM では、Android デバイス 1 台につき最大 4 種類の折りたたみキーをアプリサーバーが常に使用できます。つまり、FCM サーバーは、デバイス 1 台につき 4 種類の折りたたみ可能な送信後同期メッセージを、それぞれ異なる折りたたみキーで同時に保存できます。この上限を超えた場合は、引き続き 4 つの折りたたみキーが保存されますが、どのキーが保存されるかは保証されません。

どちらを使うべきか

パフォーマンス面から見ると、アプリで折りたたみできないメッセージを使用する必要がなければ、折りたたみできるメッセージを選択するのが適切です。ただし、折りたたみできるメッセージを使用する場合、FCM 接続サーバーで使用できる異なる折りたたみキーは、任意の時点で登録トークンごとに最大 4 つまでという制限があるので注意してください。この上限を超えると予測できない事態を招く可能性があるので、上限内に収まるようにしてください。

使用シナリオ 送信方法
折りたたみできない どのメッセージもクライアント アプリにとって重要で、配信する必要がある。 通知メッセージを除き、デフォルトではすべてのメッセージが折りたたみできないものです。
折りたたみできる 古い関連メッセージをクライアント アプリにとって無意味にするような新しいメッセージがある場合、FCM によって古いメッセージが置き換えられる。例: データ同期を促すメッセージまたは期限切れ通知メッセージ。 メッセージ リクエストに適切なパラメータを設定します。
  • collapseKey(Android の場合)
  • apns-collapse-id(iOS の場合)
  • Topic(ウェブの場合)
  • collapse_key(プラットフォームを問わず、以前のプロトコルの場合)

メッセージの優先順位の設定

Android では、ダウンストリーム メッセージに配信の優先順位を割り当てるオプションとして、標準(normal)と高(high)の 2 つの優先度があります。標準の優先度と高い優先度のメッセージの配信は、次のように行われます。

  • 優先度: 標準。 データ メッセージのデフォルトの優先度です。アプリがフォアグラウンドで動作中の場合、優先度が標準のメッセージはすぐに配信されます。デバイスが Doze 状態である場合は、バッテリー節約のために配信が遅延することがあります。新着メールや UI の同期の維持、バックグラウンドでのアプリデータの同期に関する通知など、緊急度の低いメッセージでは、標準の配信優先度を選択します。

    バックグラウンドでのデータ同期をアプリにリクエストする、優先度が標準のメッセージを Android で受け取った場合は、ネットワークが使用可能なときにこの処理を行うように FJD ジョブまたは JobIntentService をスケジューリングする必要があります。

  • 優先度: 高。FCM では、優先度の高いメッセージの即時配信を試み、FCM サービスによってスリープ状態のデバイスを必要に応じてアクティブにしたり、限られた処理(ごく限定的なネットワーク アクセスなど)を実行したりできるようにします。通常、優先度の高いメッセージが配信されると、ユーザーによるアプリの操作やその通知の操作が行われることになります。ユーザーによる操作がなかったことを示すパターンが FCM によって検出された場合は、そのメッセージの優先度が下げられることがあります。Android P ではアプリ スタンバイ バケットが導入され、これによりアプリに送信できる優先度の高い FCM メッセージ(ただしユーザーがアプリの操作や通知の表示を行わないメッセージ)の数が制限されます。優先度の高いメッセージに応答して、ユーザーの目に入るように通知が表示された場合、アプリ スタンバイ バケットの割り当てはそのメッセージで消費されません。

    Android モバイル ユーザーのごく一部は遅延の大きいネットワークを利用しているので、通知の表示前にサーバーへの接続を開かないようにしてください。許容処理時間が経過しないうちにサーバーへのコールバックを行うことは、遅延の大きいネットワーク上のユーザーにとってリスクとなる場合があります。代わりに、通知コンテンツを FCM メッセージに含めて、すぐに表示されるようにします。Android で追加のアプリ内コンテンツを同期する必要がある場合は、そうした同期をバックグラウンドで処理するように FJD ジョブまたは JobIntentService をスケジューリングできます。

以下に優先度が標準のメッセージの例を示します。マガジンの購読者に新しいコンテンツがダウンロード可能になったことを通知するために、FCM の HTTP v1 プロトコル経由で送信されることを想定しています。

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

メッセージ優先度の設定に関するプラットフォーム固有の詳細情報については、以下をご覧ください。

メッセージの有効期間の設定

FCM では通常、メッセージが送信されるとすぐに配信されます。しかし、常にそれが可能であるとは限りません。たとえば、プラットフォームが Android の場合、デバイスが電源オフまたはオフライン、あるいは利用できない状態になっている可能性があります。また、アプリによる過剰なリソースの消費やバッテリー寿命への悪影響を防ぐために FCM が意図的にメッセージの配信を遅らせることもあります。

こうした場合、FCM はメッセージを保存しておき、配信に適した状態になり次第メッセージを配信します。ほとんどの場合は、これで問題ないのですが、アプリによってはメッセージ配信の遅れが許されないことがあります。たとえば、通話着信またはビデオチャット通知のメッセージは、呼び出しが終わってから配信されたのでは意味がありません。また、イベントへの招待メッセージは、イベント終了後に届いても役に立ちません。

Android およびウェブ / JavaScript では、メッセージの最大有効期間を指定できます。その値は 0~2,419,200 秒(28 日)の間で設定する必要があります。28 日は FCM が配信を試みるまでにメッセージを保存できる最大期間です。このフィールドがないリクエストには、有効期間として最長の 4 週間(28 日)がデフォルトで設定されます。

この機能には以下のような用途が考えられます。

  • ビデオチャットの通話着信
  • 期限が近づいている招待イベント
  • カレンダーの予定

メッセージの有効期間を指定するもう 1 つの利点として、FCM では有効期間の値が 0 秒のメッセージに対してスロットリングが行われないことが挙げられます。つまり、FCM では「今すぐに」配信する必要があるメッセージに対するベストエフォートが保証されます。time_to_live の値を 0 したメッセージは、即時配信ができなければ破棄されることに注意してください。ただし、こうしたメッセージは保存されることがないため、通知メッセージの送信については遅延が最小になります。

以下に、TTL を含むリクエストの例を示します。

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

複数送信者からのメッセージの受信

FCM では、複数のユーザーが同じクライアント アプリにメッセージを送信できます。たとえば、複数の寄稿者から集約した記事をユーザーに配信するクライアント アプリがあるとします。各寄稿者が新しい記事を公開する際にはクライアント アプリ向けにメッセージを送信できなければいけません。このメッセージには、クライアント アプリが記事をダウンロードするための URL が含まれる場合があります。FCM では、送信に関するすべてのアクティビティを 1 か所で集中管理する代わりに、各寄稿者による独自メッセージの送信を許可することができます。

この機能を有効にするには、各送信者の送信者 ID を生成できるようにします。登録をリクエストする際、クライアント アプリは、トークンのフェッチを複数回にわたって行います。このとき、対象デバイスフィールド内の送信者 ID は毎回異なり、以下に示す特定のプラットフォーム用のトークン取得メソッドが使用されます。

1 つのトークン リクエストに複数の送信者 ID を追加しないでください。予期しない結果が生じる可能性があります。送信者 ID ごとに 1 回ずつ、個別に呼び出しを行います。

最後に、登録トークンを対応する送信者と共有します。これで、送信者は独自の認証キーを使用してクライアント アプリにメッセージを送信できるようになります。

なお、送信者の数には 100 名までという上限があります。

メッセージの有効期間

アプリサーバーが FCM にメッセージを送信し、メッセージ ID を受け取っても、メッセージがすでにデバイスに配信されたことを意味するわけではありません。これは、単にメッセージが配信のために受理されたことを意味します。その後のメッセージの処理は、多くの要因に依存します。

デバイスが FCM に接続済みで、画面がオンになっていて、スロットリングの制限がないという最善のシナリオでは、メッセージがすぐに配信されます。

デバイスが FCM に接続されていても Doze モードになっている場合、優先度の低いメッセージはデバイスが Doze 状態でなくなるまで FCM で保管されます。こうした場合は collapse_key が役立ちます。同じ折りたたみキー(および登録トークン)を持つメッセージがすでに保存されていて、配信待ちになっている場合、古いメッセージは破棄され、新しいメッセージが設定されます(つまり古いメッセージが新しいメッセージによって折りたたまれます)。しかし、折りたたみキーが設定されていない場合は、新しいメッセージも古いメッセージも今後の配信のために保存されます。

デバイスが FCM に接続されていない場合、メッセージは(ここでも折りたたみキーのルールに従って)接続が確立されるまで保存されます。接続が確立されると、保留中のすべてのメッセージが FCM によってデバイスに配信されます。そのデバイスの再接続が一度も行われなかった場合(工場出荷時の状態にリセットされた場合など)、メッセージは最終的にタイムアウトし、FCM ストレージから破棄されます。time_to_live フラグが設定されていない場合、デフォルトのタイムアウトは 4 週間になっています。

メッセージの配信の詳細を把握するには:

  • Android と iOS の場合: FCM レポート ダッシュボードをご覧ください。このダッシュボードには、Android アプリの「インプレッション」(ユーザーが表示した通知)のデータとともに、iOS デバイスと Android デバイスで送信および開封されたメッセージの数が記録されています。
  • Android の場合: アプリでメッセージが正常に受信されたときに通知を受け取りたい場合は、delivery_receipt_requested の機能をガイドラインに沿って使用します。これには、XMPP サーバーをセットアップする必要があります。
  • Android、iOS、ウェブの場合: InstanceID API を使用すると、FCM 登録トークンを通じて宛先としているデバイスが FCM との接続を確立した直近の日付を確認できます。

デバイスが 1 か月以上 FCM に接続されていない場合、FCM は引き続きメッセージを受理しますが、すぐに破棄します。最後のデータ メッセージの送信から 4 週間以内にデバイスが接続した場合、クライアントは onDeletedMessages() コールバックを受け取ります。この場合、通常はアプリサーバーとの完全な同期をリクエストすることで、アプリは状況に適切に対処できます。

さらに、FCM がデバイスへのメッセージ配信を試みても、アプリがアンインストールされていた場合、FCM はそのメッセージをすぐに破棄し、登録トークンを無効にします。それ以降、そのデバイスにメッセージを送信しようとすると NotRegistered エラーが発生します。

スロットル処理とスケーリング

Google の目標は、すべてのメッセージを常に FCM 経由で配信することです。ただし、すべてのメッセージを配信すると、結果として全体的なユーザー エクスペリエンスが低下する場合があります。また、FCM がすべての送信者にスケーラブルなサービスを提供できるようにするには、境界を設定する必要がある場合もあります。

折りたたみできるメッセージのスロットル処理

前述したように、折りたたみできるメッセージとは、前のメッセージを置き換えるように設計された、コンテンツを含まない通知です。同じメッセージがアプリに頻繁に繰り返し送信されている場合、ユーザーの電池の消耗を抑えるためにメッセージを遅延(スロットル)させます。

たとえば、1 つのデバイスに大量の新しいメール同期リクエストを送信した場合、デバイスが同期する平均頻度を下げられるように次のメール同期リクエストを数分遅延させることがあります。このスロットル処理は、ユーザーの電池への影響を抑えるために厳重に行われています。

ユースケースで高いバースト送信パターンを必要とする場合は、折りたたみできないメッセージを選択するのが適切な場合があります。このようなメッセージでは、電池コストを削減するためにメッセージにコンテンツを含めるようにしてください。

折りたたみできるメッセージでは、メッセージのバーストは 1 デバイスにつき 1 アプリあたり 20 件に制限され、3 分ごとにメッセージ 1 件が差し替えられます。

XMPP サーバーのスロットル処理

FCM XMPP サーバーに接続できる頻度は、プロジェクトごとに 1 分あたり 400 回に制限されています。これはメッセージ配信では問題になりませんが、システムの安定性確保には重要です。

デバイス 1 台に対する最大メッセージ レート

1 台のデバイスに送信できるメッセージは、1 分あたり最大 240 件、1 時間あたり最大 5,000 件です。このしきい値が高いのは、ユーザーがチャットで高速にやりとりしている場合など、短期間のトラフィックのバーストを許容するためです。この制限により、送信ロジックのエラーによって誤ってデバイスの電池が消耗されるのを防ぐことができます。

アップストリーム メッセージの制限

アップストリームの送信先サーバーが過負荷にならないように、プロジェクトごとのアップストリーム メッセージは 15,000 件/分に制限されています。

アプリの不適切な動作による電池の消耗を防ぐために、デバイスあたりのアップストリームメッセージは 1,000 件/分に制限されています。

トピック メッセージの制限

トピック登録の追加 / 解除レートは、プロジェクトごとに 3,000 QPS に制限されています。

メッセージ送信レートについては、ファンアウトのスロットル処理をご覧ください。

ファンアウトのスロットル処理

メッセージのファンアウトとは、複数のデバイスにメッセージを送信するプロセスです。これは、トピックやグループをターゲットにする場合などに使用されます。また、Firebase コンソールで Notifications Composer を使用して実行することもできます。

プロジェクトごとの進行中のメッセージのファンアウト数は 1,000 に制限されています。1,000 に達すると、一部のファンアウトが完了するまで、追加のファンアウト リクエストは拒否される場合があります。

実際に到達可能なファンアウト レートは、同時にファンアウトをリクエストするプロジェクトの数に影響されます。個々のプロジェクトに対するファンアウト数 10,000 QPS は一般的なレートですが、その数は保証されたものではなく、システム全体の負荷によって異なります。利用可能なファンアウト容量は、ファンアウト要求間ではなくプロジェクト間で分割される点に注意してください。そのため、プロジェクトで 2 つのファンアウトが進行中の場合、各ファンアウトには使用可能なファンアウト レートの半分しか表示されません。ファンアウト速度を最大化するには、進行中のアクティブなファンアウトを一度に 1 つのみにすることをおすすめします。

FCM ポートとファイアウォール

組織がファイアウォールによってインターネットとの間のトラフィックを制限している場合は、ネットワーク上のデバイスがメッセージを受信できるようにモバイルデバイスと FCM の接続を許可する構成を行う必要があります。通常、FCM はポート 5228 を使用しますが、5229 や 5230 を使用することもあります。

FCM は送信用の接続に対して特定の IP を提供しません。これは、IP 範囲が頻繁に変化し、ファイアウォールのルールが古くなってユーザー エクスペリエンスに影響を及ぼす可能性があるためです。ポート 5228~5230 を IP 制限なしでホワイトリストに登録するのが理想的です。ただし、IP 制限が必要な場合は、Google の ASN 15169 のリストに記されている IPv4 および IPv6 ブロック内のすべての IP アドレスをホワイトリストに登録する必要があります。これは長大なリストであり、毎月のルール更新を計画する必要があります。ファイアウォールの IP 制限に起因する問題は、多くの場合、断続的なもので診断は困難です。

受信メッセージ用に開くポート:

  • 5228
  • 5229
  • 5230

発信接続を許可するポート:

以下のうちいずれか(オプション 1 がより好ましい):

  1. IP 制限なし
  2. Google の ASN 15169 に記載の IP ブロックに含まれているすべての IP アドレス。少なくとも 1 か月に一度は必ず更新してください。

ネットワーク アドレス変換およびステートフル パケット インスペクション用のファイアウォール:

ネットワーク アドレス変換(NAT)またはステートフル パケット インスペクション(SPI)をネットワークで実装している場合は、ポート 5228~5230 での接続に 30 分以上のタイムアウトを設定してください。これにより、信頼性の高い接続性を提供しつつ、ユーザーのモバイル デバイスの電池消費量を削減できます。

認証情報

実装する FCM 機能によっては、Firebase プロジェクトから次の認証情報の取得が必要になる場合があります。

プロジェクト ID FCM v1 HTTP エンドポイントへのリクエストで使用される Firebase プロジェクトの一意の識別子。この値は、Firebase コンソールの [設定] ペインで確認できます。
登録トークン

各クライアント アプリ インスタンスを識別する一意のトークン文字列。単一のデバイスとデバイス グループへのメッセージングに必要になります。登録トークンは非公開にしなければならないことに注意してください。

送信者 ID Firebase プロジェクトの作成時に作成される一意の数値。Firebase コンソールの [設定] ペインにある [クラウド メッセージング] タブで確認できます。送信者 ID は、クライアント アプリにメッセージを送信できる各送信者を識別するために使用されます。
アクセス トークン HTTP v1 API へのリクエストを承認する短命の OAuth 2.0 トークン。このトークンは、Firebase プロジェクトに属するサービス アカウントと関連付けられています。アクセス トークンの作成およびローテーションを行うには、送信リクエストを承認するに記されている手順に沿って操作します。
サーバーキー(以前のプロトコル用)

アプリサーバーによる Google サービスへのアクセス(以前の Firebase Cloud Messaging プロトコル経由でのメッセージの送信など)を承認するサーバーキー。サーバーキーは Firebase プロジェクトの作成時に取得します。サーバーキーは、Firebase コンソールの [設定] ペインにある [クラウド メッセージング] タブで確認できます。

重要: クライアント コードにはサーバーキーを含めないでください。また、アプリサーバーの承認には、必ずサーバーキーのみを使用してください。Android、iOS、ブラウザのキーは、FCM で拒否されます。