FCM メッセージについて

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

メッセージのタイプ

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

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

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

アプリがバックグラウンドで実行されているときに、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、ウェブのすべてのプラットフォームのアプリ インスタンスをターゲットにする
• トピックにメッセージを送信する

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

• message.notification.title
• message.notification.body
• message.data

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

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

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

特定のプラットフォームだけに値を送信する場合は、共通フィールドを使用せずにプラットフォーム固有のフィールドを使用してください。たとえば、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 つまでという制限があるので注意してください。この上限を超えると予測できない事態を招く可能性があるので、上限内に収まるようにしてください。

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

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

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

• 優先度: 高。デバイスが Doze モードになっている場合であっても、優先度の高いメッセージは即時配信が試みられます。高い優先度のメッセージは、なるべく早くユーザーに確認してもらう必要のあるコンテンツ向けです。

以下に優先度が標準のメッセージの例を示します。マガジンの購読者に新しいコンテンツがダウンロード可能になったことを通知するために、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"
      }
    }
  }
}

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

• APNs のドキュメント
• メッセージの優先度を設定、管理する（Android）
• ウェブの push メッセージの緊急性

重要なユースケース

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 コンソールで確認できます。

1. Google Cloudコンソールに移動
2. [API とサービス] を選択します。
3. テーブルのリストから [Firebase Cloud Messaging API] を選択します。
4. [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 件が差し替えられます。

デバイス 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 プロジェクトから次の認証情報の取得が必要になる場合があります。