Firebase で AI 搭載アプリを構築して実行する方法のデモを、2024 年の Demo Day でご覧ください。ぜひご覧ください。

FCM メッセージについて

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

メッセージのタイプ

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

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

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

	使用シナリオ	送信方法
通知メッセージ	クライアントアプリがバックグラウンドで実行されている場合、FCM SDK は、クライアントアプリに代わってエンドユーザーのデバイスにメッセージを表示します。そうではなく、通知を受信しているときにアプリがフォアグラウンドで実行されている場合、アプリのコードによってアプリの動作が決定されます。通知メッセージでは、いくつかのユーザー表示用キーが事前定義されており、カスタムの Key-Value ペアのデータペイロードを任意に指定できます。	Cloud Functions やアプリサーバーなどの信頼できる環境で、Admin SDK または HTTP v1 API を使用します。`notification` キーを設定します。データペイロードを任意で指定できます。常に折りたたみ可能になります。表示通知の例を参照して、リクエストのペイロードを送信します。 Notifications Composer を使用し、メッセージのテキストやタイトルなどを入力して送信します。カスタムデータを指定することで、オプションのデータペイロードを追加できます。
データメッセージ	クライアントアプリがデータメッセージの処理を行います。データメッセージには、予約済みのキー名のないカスタム Key-Value ペアのみが含まれます（以下を参照）。	Cloud Functions やアプリサーバーなどの信頼できる環境で、Admin SDK または FCM サーバープロトコルを使用します。送信リクエストで、`data` キーを設定します。

アプリがバックグラウンドで実行されているときに、FCM SDK で通知の表示を自動的に処理する場合は、通知メッセージを使用します。独自のクライアントアプリコードでメッセージを処理する場合は、データメッセージを使用します。

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!"
    }
  }
}

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

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

データメッセージ

データペイロードをクライアントアプリに送信するには、適切なキーにカスタム 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 バックエンドにより、指定されたすべてのパラメータに従って、メッセージがプラットフォームごとにカスタマイズされます。

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

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

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

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

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

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

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

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

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

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

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

Android およびウェブプラットフォームに対しては長い有効期間を設定し、APNs（Apple プラットフォーム）メッセージには低い優先順位を設定します。
Android および Apple でユーザーが通知をタップしたときの結果を定義するために、それぞれ適切なキー（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 デバイスに送信されるメッセージ用の特定の配信オプションが提供されており、Apple プラットフォームとウェブで同様のオプションを使用できます。たとえば、「折りたたみできる」メッセージの動作は、Android、Apple、JavaScript / ウェブで、それぞれ FCM の collapse_key、apns-collapse-id、Topic によってサポートされています。詳細については、このセクションの説明と関連するリファレンスドキュメントをご覧ください。

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

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

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

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

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

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

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

ペイロードのないトピックメッセージは、デフォルトで折りたたみ可能です。通知メッセージは常に折りたたみ可能で、collapse_key パラメータを無視します。

選択基準

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

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

メッセージの優先度の設定

ダウンストリームメッセージに配信の優先度を割り当てるオプションとして、標準（normal）と高（high）の 2 つの優先度があります。動作はプラットフォームによって若干異なりますが、標準の優先度と高い優先度のメッセージ配信は次のような仕組みで行われます。

優先度: 標準。アプリがフォアグラウンドで動作中の場合、優先度が標準のメッセージはすぐに配信されます。アプリがバックグラウンドで動作している場合は、配信が延期されることがあります。新着メールの通知、UI の同期の維持の通知、バックグラウンドでのアプリデータの同期の通知など、緊急度の低いメッセージでは、標準の配信優先度を選択します。
優先度: 高。デバイスが Doze モードになっている場合であっても、優先度の高いメッセージは即時配信が試みられます。高い優先度のメッセージは、なるべく早くユーザーに確認してもらう必要のあるコンテンツ向けです。

Apple デバイスにデータメッセージを送信する場合は、優先度を 5（標準の優先度）に設定する必要があります。高優先度でメッセージを送信するとエラー FCM が発生し、FCM バックエンドで拒否されます。INVALID_ARGUMENT

以下に優先度が標準のメッセージの例を示します。マガジンの購読者に新しいコンテンツがダウンロード可能になったことを通知するために、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 API は、緊急速報メールや、API の使用または障害が死亡、人身傷害、環境破壊につながる可能性があるその他の危険度の高い活動（核関連施設、航空管制、生命維持装置の運用など）を対象として設計されていません。このような使用は、第 4. a. 7 条に違反しているため、明示的に禁止されています。アプリの利用規約への準拠と、準拠しなかったことに起因する損害については、お客様が単独で責任を負うものとします。Google は API を「現状のまま」提供します。Google は、お客様またはお客様のユーザーに対して責任やその他の義務を負うことなく、理由の如何を問わずいつでも、API またはその一部、機能、お客様からのアクセスを中止する権限を有します。

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

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

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

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

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

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

Android または Apple プラットフォームでのメッセージ配信の詳細については、FCM レポートダッシュボードをご覧ください。このダッシュボードには、Android アプリの「インプレッション」（ユーザーが表示した通知）のデータとともに、Apple デバイスと Android デバイスで送信および開封されたメッセージの数が記録されています。

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

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

スロットリングと割り当て

Google の目標は、すべてのメッセージを常に FCM 経由で配信することです。ただし、すべてのメッセージを配信すると、結果として全体的なユーザーエクスペリエンスが低下する場合があります。また、FCM がすべての送信者にスケーラブルなサービスを提供できるようにするには、境界を設定する必要がある場合もあります。このセクションで説明する上限と割り当ての種類は、これらの重要な要素のバランスを取るのに役立ちます。

ダウンストリームメッセージのスロットリング

HTTP v1 API では、ダウンストリームメッセージングに対する各プロジェクトの 1 分あたりの割り当てが導入されました。デフォルトの割り当て（1 分あたり 60 万件のメッセージ）は、システムの安定性を確保して急増するプロジェクトの影響を最小限に抑えながら、FCM デベロッパーの 99% 以上をカバーします。

トラフィックパターンが急増することにより、割り当て超過エラーが発生する可能性があります。割り当て超過のシナリオでは、次の 1 分間に割り当てが再び利用可能になるまで、HTTP ステータスコード 429（QUOTA_EXCEEDED）が返されます。429 レスポンスは、過負荷の状況でも返される可能性があるため、公開されている推奨事項に沿って 429 を処理することを強くおすすめします。

次のことに注意してください。

ダウンストリームの割り当ては、リクエストではなくメッセージを測定します。
クライアントエラー（HTTP ステータスコード 400～499）がカウントされます（429 は除く）。
割り当ては分単位ですが、この分単位は時計と連動したものではありません。

割り当てのモニタリング

割り当て、使用量、エラーは Google Cloud コンソールで確認できます。

Google Cloudコンソールに移動
[API とサービス] を選択します。
テーブルのリストから [Firebase Cloud Messaging API] を選択します。
[QUOTA & SYSTEM LIMITS] を選択します。

注: これらのグラフは、割り当ての分数と正確に時間的に調整されているわけではありません。つまり、トラフィックが割り当てを下回っているように見える場合でも、429 が配信されることがあります。

割り当ての増加リクエスト

割り当ての増加をリクエストする前に、次の点を確認してください。

1 日に 5 分間以上連続して、使用量が割り当ての 80% 以上になる。
クライアントエラー率が 5% 未満である（特にトラフィックのピーク時）。
大規模なメッセージ送信のベストプラクティスを遵守している。

これらの条件を満たしている場合は、最大 25% の割り当て増加リクエストを送信できます。FCM はリクエストを満たすためにあらゆる実用的な努力を払いますが、増加を保証するものではありません。

間近に迫ったリリースや一時的なイベントのためにダウンストリームメッセージの割り当てを増やす必要がある場合は、リクエストに対応するのに十分な時間を確保できるように、少なくとも 15 日前までに割り当てをリクエストしてください。大規模なリクエスト（1 分あたり 1,800 万件を超えるメッセージ）の場合は、少なくとも 30 日前までにお知らせください。リリースや特別なイベントリクエストには、引き続きクライアントエラー率とベストプラクティスの要件が適用されます。

FCM 割り当てに関するよくある質問もご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XMPP を使用したアップストリームメッセージングの場合、FCM ではアップストリームの宛先サーバーが過負荷にならないように、アップストリームメッセージはプロジェクトごとに 1,500,000 件/分に制限されています。

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

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

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

iOS の場合、レートが APNs の制限を超えるとエラーが返されます。

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

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

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

Google では、IP アドレスの代わりに、許可リストに登録可能な一連のドメイン名を提供しています。ホスト名は以下のとおりです。Google で追加のホスト名が使用されるようになると、こちらのリストが更新されます。ファイアウォールルールにドメイン名を使用すると、ファイアウォールデバイスで機能しない場合があります。

開く TCP ポート:

5228
5229
5230
443

開くホスト名:

mtalk.google.com
mtalk4.google.com
mtalk-staging.google.com
mtalk-dev.google.com
alt1-mtalk.google.com
alt2-mtalk.google.com
alt3-mtalk.google.com
alt4-mtalk.google.com
alt5-mtalk.google.com
alt6-mtalk.google.com
alt7-mtalk.google.com
alt8-mtalk.google.com
android.apis.google.com
device-provisioning.googleapis.com
firebaseinstallations.googleapis.com

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

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

VPN との相互作用とバイパス可能性

Firebase Cloud Messaging は、スマートフォンからサーバーへのプッシュメッセージ接続が信頼性が高く、可能な限り頻繁に利用できるようにさまざまな手順を踏んでいます。VPN を使用するとこの処理が複雑になります。

VPN は、FCM が信頼性とバッテリー寿命を最大化するために接続を調整するのに必要となる基本的な情報をマスクします。場合によっては、VPN が長時間接続を積極的に切断し、メッセージの欠落や遅延、バッテリーの消耗が原因でユーザーエクスペリエンスが低下することがあります。VPN の構成上可能であれば、信頼性が高くバッテリーに優しいエクスペリエンスを実現するため、暗号化された接続（ベースネットワークの Wi-Fi または LTE 経由）を使用して VPN をバイパスします。FCM によるバイパス可能な VPN の使用は、FCM プッシュ通知チャネルに固有のものです。登録トラフィックなどの他の FCM トラフィックは、VPN がアクティブな場合に VPN を使用します。FCM 接続が VPN をバイパスすると、IP マスキングなどの VPN が提供する追加のメリットが失われます。

VPN によって、バイパスできるかどうかを制御する方法が異なります。手順については、該当する VPN のドキュメントをご覧ください。

VPN がバイパス可能に構成されていない場合、Firebase Cloud Messaging はサーバーに接続するために VPN ネットワークを使用してします。これにより、メッセージが遅延する期間が発生する可能性があります。また、Cloud Messaging が VPN 接続経由で接続を維持するために、バッテリーの使用量が増加する可能性があります。

認証情報

実装する 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 プロトコル経由でのメッセージの送信など）を承認するサーバーキー。重要: クライアントコードにはサーバーキーを含めないでください。また、アプリサーバーの承認には、必ずサーバーキーのみを使用してください。Android、Apple プラットフォーム、ブラウザのキーは、FCM で拒否されます。