Firebase Cloud Messaging（FCM）の通知システムを設計する際、多くの開発者が疑問に感じるのが「FCMのデバイストークン（登録トークン）は誰が生成しているのか」という点です。Firebase公式ドキュメントを見ると、「FCM SDKが生成する」とも「FCMが発行する」とも読める表現があり、混乱することがあります。本記事ではFCMトークン発行の仕組みを整理し、システム設計でどのように理解すべきかを解説します。
FCMデバイストークンとは何か
FCMデバイストークン（登録トークン）は、通知を送信する対象のアプリインスタンスを一意に識別するための識別子です。
サーバー側はこのトークンを保持し、FCM APIへ送信することで特定端末へプッシュ通知を配信できます。
| 項目 | 役割 |
|---|---|
| アプリ | トークンを取得してサーバーへ送信 |
| アプリサーバー | トークンを保存し通知送信時に利用 |
| FCM | トークンに対応する端末へ通知を配信 |
「SDKが生成する」と「FCMが生成する」はどちらが正しいのか
結論から言うと、両方とも正しい表現です。
ただし、視点が異なるため違って見えるだけです。
クライアント視点
アプリ開発者の視点では、FCM SDKを組み込んだアプリが起動時にトークン取得処理を行います。そのため公式ドキュメントでは「FCM SDKによって生成される」と説明されています。
システム内部の視点
実際にはSDKがローカルでランダムなトークンを作っているわけではありません。SDKはFirebaseのサーバーと通信し、FCMインフラ側で登録処理を行った結果としてトークンを受け取ります。
そのためアーキテクチャの説明では「FCMが登録トークンを発行する」と表現されています。
実際のトークン発行フロー
FCMトークン取得時の流れを簡略化すると次のようになります。
- アプリ起動
- FCM SDKがFirebaseへ登録要求
- FCMサービスがアプリインスタンスを登録
- 登録トークンを発行
- SDKがトークンを受信
- アプリが自社サーバーへ送信
つまりSDKはトークン発行の窓口であり、トークン自体はFCMサービスとの通信結果として取得されます。
通知システム設計で意識すべきポイント
実務では「誰が生成したか」よりも「トークンは変更される可能性がある」という点が重要です。
- アプリ再インストール時
- アプリデータ削除時
- 端末変更時
- FCM側のセキュリティ更新時
これらのタイミングでトークンが再発行されることがあります。
そのためサーバー側ではユーザーIDとトークンを紐付け、トークン更新イベントを受け取った際に最新値へ更新する設計が推奨されます。
よくある誤解
「デバイストークン」という名称から端末固有IDのように考えられがちですが、実際にはアプリインスタンス単位の識別子です。
同じスマートフォンでもアプリを再インストールすると別のトークンになる場合があります。また1台の端末で複数アプリを利用している場合、それぞれ異なるトークンが発行されます。
まとめ
FCMデバイストークンについては、「FCM SDKが生成する」と「FCMが生成する」のどちらも間違いではありません。正確には、SDKがFirebaseへ登録処理を行い、その結果としてFCMサービス側が発行した登録トークンをSDKが取得しています。通知システム設計ではトークンの生成主体よりも、トークンが更新・失効する前提で管理することが重要です。ユーザーとトークンの関連付け、トークン更新処理、無効トークンの削除を考慮した設計を行うことで、安定した通知配信システムを構築できます。
コメント