FCM メッセージについて

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

メッセージのタイプ

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

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

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

	使用シナリオ	送信方法
通知メッセージ	FCM は、クライアントアプリに代わってエンドユーザーのデバイスにメッセージを自動的に表示します。通知メッセージには、ユーザーに表示される事前定義キーのセットと、カスタム Key-Value ペアのデータペイロード（オプション）を含めることができます。	Cloud Functions やアプリサーバーなどの信頼できる環境で、Admin SDK または FCM サーバープロトコルを使用し、`notification` キーを設定します。オプションのデータペイロードを指定できます。常に折りたたみ可能になります。表示通知の例を参照して、リクエストのペイロードを送信します。 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 フィールドが使用されています。このフィールドは、メッセージを受信するすべてのプラットフォーム上でクライアントによって解釈されます。クライアントアプリは、それぞれのプラットフォームのコールバック関数でデータペイロードを受信します。

データメッセージの暗号化

Android トランスポートレイヤ（FCM アーキテクチャを参照）は、ポイントツーポイント暗号化を使用します。必要に応じて、エンドツーエンドの暗号化をデータメッセージに追加できます。FCM はエンドツーエンドのソリューションを提供していません。ただし、Capillary や DTLS などの外部ソリューションを利用できます。

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

プログラムと 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 オブジェクト内のすべてのフィールドをメッセージリクエストで設定できるようにします。以下に例を示します。

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

プラットフォーム固有のブロックを使用すると、受信時に各種プラットフォームで正しく処理されるように、メッセージを柔軟にカスタマイズできます。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_key、apns-collapse-id、Topic によってサポートされています。詳細については、このセクションの説明と関連するリファレンスドキュメントをご覧ください。

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

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

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

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

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

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

Android でメッセージを折りたたみ可能としてマークするには、メッセージペイロードに collapse_key パラメータを含めます。折りたたみキーのデフォルト値は、Firebase コンソールに登録されているアプリのパッケージ名です。FCM サーバーはデバイスあたり 4 つの折りたたみ可能なメッセージを、それぞれ異なる折りたたみキーで同時に保存できます。この上限を超えた場合は、引き続き 4 つの折りたたみキーが保存されますが、どのキーが保存されるかは保証されません。

デフォルトでは、ペイロードのないトピックメッセージは折りたたみ可能です。

どちらを使うべきか

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

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

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

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

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

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

iOS デバイスにデータメッセージを送信する場合は、優先度を 5（標準の優先度）に設定する必要があります。高優先度でメッセージを送信するとエラー INVALID_ARGUMENT が発生し、FCM バックエンドで拒否されます。
Android モバイルユーザーのごく一部はレイテンシの高いネットワークを利用しているので、通知の表示前にサーバーへの接続を開かないようにしてください。許容処理時間が経過しないうちにサーバーへのコールバックを行うことは、遅延の大きいネットワーク上のユーザーにとってリスクとなる場合があります。代わりに、通知コンテンツを FCM メッセージに含めて、すぐに表示されるようにします。Android で追加のアプリ内コンテンツを同期する必要がある場合は、WorkManager を使用してタスクのスケジュールを設定し、バックグラウンドでこの処理を行うことができます。

以下に優先度が標準のメッセージの例を示します。マガジンの購読者に新しいコンテンツがダウンロード可能になったことを通知するために、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 はその都度異なり、以下に示す特定のプラットフォーム用のトークン取得メソッドが使用されます。

iOS（Swift）- token(completion:)
Android - FirebaseMessaging.getInstance().getToken()

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

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

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

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

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

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

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

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

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

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

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

FCM は、プロジェクトあたり 2, 500 件の同時接続を許可します。

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

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

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

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

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

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

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

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

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

メッセージのファンアウトは、複数のデバイスにメッセージを送信するプロセスです。トピックとグループをターゲットにする場合や、Notifications Composer を使用してオーディエンスまたはユーザーセグメントをターゲットにする場合に使用されます。

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

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

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

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

FCM は発信接続に対して特定の IP を提供しません。これは、Google の IP 範囲が頻繁に変化し、ファイアウォールのルールが古くなってユーザーエクスペリエンスに悪影響を及ぼす可能性があるためです。理想としては、ポート 5228～5230 を IP 制限なしでホワイトリストに登録することをおすすめします。ただし、IP 制限が必要な場合は、goog.json にリストされている IP アドレスをすべてホワイトリストに登録する必要があります。この長大なリストは定期的に更新されます。使用しているルールを月次ベースで更新することをおすすめします。ファイアウォールの IP 制限に起因する問題は、多くの場合断続的であり、診断が困難です。

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

5228
5229
5230
443

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

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

IP 制限なし
デフォルトドメインのすべての IP アドレス。

これらのアドレスの最新のリストを取得するには、デフォルトドメインの IP アドレスに記載されている手順を実施します。

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

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

認証情報

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

プロジェクト ID	FCM v1 HTTP エンドポイントへのリクエストで使用される Firebase プロジェクトの一意の識別子。この値は、Firebase コンソールの [設定] ペインで確認できます。
登録トークン	各クライアントアプリインスタンスを識別する一意のトークン文字列。単一のデバイスとデバイスグループへのメッセージングに必要になります。登録トークンは非公開にしなければならないことに注意してください。
送信者 ID	Firebase プロジェクトの作成時に作成される一意の数値。Firebase コンソールの [設定] ペインにある [Cloud Messaging] タブで確認できます。送信者 ID は、クライアントアプリにメッセージを送信できる各送信者を識別するために使用されます。
アクセストークン	HTTP v1 API へのリクエストを承認する短命な OAuth 2.0 トークン。このトークンは、Firebase プロジェクトに属するサービスアカウントと関連付けられています。アクセストークンの作成およびローテーションを行うには、送信リクエストを承認するに記されている手順に沿って操作します。
サーバーキー（レガシープロトコル用）	アプリサーバーによる Google サービスへのアクセス（以前の Firebase Cloud Messaging プロトコル経由でのメッセージの送信など）を承認するサーバーキー。サーバーキーは Firebase プロジェクトの作成時に取得します。サーバーキーを確認するには、Firebase コンソールの [設定] ペインにある [クラウドメッセージング] タブに移動します。重要: クライアントコードにはサーバーキーを含めないでください。また、アプリサーバーの承認には、必ずサーバーキーのみを使用してください。Android、iOS、ブラウザのキーは、FCM で拒否されます。