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

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

FCM v1 HTTP プロトコルによって送信されるメッセージには、2 つのタイプの JSON キーペアを含めることができます。

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

プラットフォーム固有のブロックを使用すると、各種プラットフォームで受信時に正しく処理されるようにメッセージを柔軟にカスタマイズできます。多くのシナリオでは、共通のキーとプラットフォーム固有のキーの両方を特定のメッセージで使用することになります。

共通キーを使用する場合

  • すべてのプラットフォーム(iOS、Android、およびウェブ)上のアプリ インスタンスを対象としているとき(必須)
  • トピックにメッセージを送信するとき

プラットフォームに関係なく、すべてのアプリ インスタンスによって解釈される共通キーは、message.notification.titlemessage.notification.body、および message.data です。

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

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

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

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

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

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

  • Android およびウェブ プラットフォームに対しては長い有効期間を設定し、APN(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 エラーが発生します。

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 で拒否されます。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。