Firebase Cloud Messaging (FCM)

解決する課題

モバイルやウェブのアプリへプッシュ通知を届けたいとき、各プラットフォームの配信網（Android の通知系・Apple の APNs・ブラウザの Web Push）を個別に実装し、常時接続や再送、デバイス管理まで自前で抱えるのは大きな負担です。FCM はこれらを 1 本の API の裏側に隠し、通知の送信だけに集中できるようにします。

• 端末ごとに異なる通知経路（Android／iOS／Web）を1 つの送信 APIでまとめたい
• サーバーと端末の常時接続やソケットの維持を自前で持ちたくない
• 1 通を多数のユーザーへ同報したい（お知らせ・速報・キャンペーンなど）
• 「スポーツの特定チームを購読した人だけ」のように興味ごとに配信したい
• アプリが裏で動いていない（バックグラウンド）ときでも通知を出したい

対応する AWS のサービスは Amazon SNS のモバイルプッシュや Amazon Pinpoint です。FCM は Firebase の一機能ですが、Google Cloud 上のバックエンドからサーバー側 API（HTTP v1）で送信するのが一般的な使い方です。

主要概念と用語

• 登録トークン（Registration Token）: アプリのインスタンス（端末＋アプリの組）を一意に表す宛先 ID。クライアント SDK が取得し、自前のサーバーへ保存して送信先に使う。再インストールや更新で変わり得るため失効管理が要る
• 通知メッセージ（Notification message）: タイトルや本文を含み、アプリがバックグラウンドのとき OS が自動で通知を表示する形式
• データメッセージ（Data message）: 任意のキーと値だけを運ぶ形式。表示はアプリのコードが自分で制御する。通知とデータを併用することもできる
• トピック（Topic）: 「news」「team-abc」のような購読チャネル。クライアントが購読すると、そのトピック宛ての 1 通が購読者全員へファンアウトされる
• 条件（Condition）: 複数トピックを論理式で組み合わせた宛先指定（例: トピック A を購読しトピック B は購読していない人）
• デバイスグループ: 同一ユーザーの複数端末をまとめて 1 宛先として扱う仕組み
• APNs: Apple のプッシュ通知サービス。FCM は iOS 配信時に内部で APNs を利用するため、Apple の証明書または認証キーの設定が必要
• HTTP v1 API: 現行のサーバー送信 API。OAuth2 のアクセストークンで認証する。古いレガシー API は非推奨

仕様・制限・クォータ

• 配信はベストエフォート。確実な到達や順序は保証されないため、重要な処理は通知の到達に依存させず、アプリ起動時に正の情報源（自前 API）と同期する設計にする
• データメッセージのペイロードは小さい（おおむね数 KB 程度の上限）。大きなデータは本体に載せず、ID だけ送ってアプリ側で取得する
• **TTL（Time To Live）を指定でき、端末がオフラインの間は保持し、期限切れで破棄される。長期オフライン端末向けの折りたたみ（collapse key）**で古い通知を新しい通知へ置き換えられる
• トピック購読の反映には遅延が生じ得る。購読直後の即時配信は前提にしない
• iOS 配信には APNs の認証情報（認証キーまたは証明書）が必須。設定不備は iOS だけ届かない典型原因
• **高優先度（high priority）**メッセージは即時配信を狙うが、端末の省電力制御（Doze など）の影響を受けることがある
• 具体的なペイロード上限・レート・スループットの数値は変動するため、本番設計では公式ドキュメントで最新値を確認すること

内部の仕組み

クライアントの SDK が起動時に FCM へ登録して登録トークンを取得し、それを自前のサーバーへ送って保存します。送信側はそのトークン（またはトピック・条件）を宛先に指定して FCM の HTTP v1 API を呼び、FCM が各プラットフォームの配信網へ橋渡しします。

1. アプリが SDK で FCM に登録し、登録トークンを取得してサーバーへ預ける
2. サーバーが宛先（トークン／トピック／条件）と内容を指定してFCM へ送信
3. FCM が宛先に応じて配信先を解決し、Android はインターネット経由の接続、iOS は APNs 経由、Web は Web Push 経由で端末へ届ける
4. 端末がオフラインならTTL の範囲で保持し、再接続時に配信（期限切れは破棄）
5. アプリが通知メッセージなら OS が表示、データメッセージなら自前コードが処理する

トピック宛ての送信は、FCM 側がそのトピックの購読者リストへファンアウトするため、送信側は 1 回呼ぶだけで多数の端末へ届けられます。

設計パターン / ベストプラクティス

• トークンは自前サーバーで一元管理: 取得・更新・失効を記録し、無効トークンは送信エラーを機に削除して常に最新に保つ
• 同報はトピックで: 「全ユーザー」「特定カテゴリ」などはトピック購読にし、個別トークンの大量ループ送信を避ける
• 通知は引き金、真実はサーバー: 通知の到達を業務処理の正にしない。端末側はアプリ起動時に自前 API と同期し、取りこぼしを吸収する
• ペイロードは軽く: 本文を詰め込まず ID や種別だけ送り、詳細はアプリが API で取得する
• TTL と折りたたみキーを設定: 鮮度が大事な通知は短い TTL と collapse key で、古い通知を新しい通知へ置き換える
• プラットフォーム別の上書き: 共通本文に加え、Android／iOS（APNs）／Web ごとの細かな表示設定を必要な分だけ個別指定する
• 送信側はサービスアカウントで認証: HTTP v1 API は OAuth2 トークンで呼ぶ。鍵のハードコードを避ける

運用・監視

• Firebase コンソールの配信レポートで、送信数・受信（到達）・表示・開封などの傾向を確認できる
• 送信 API のレスポンスを必ず確認し、無効トークンや APNs 設定エラーなどの失敗を分類して対処する
• iOS が届かないときは、まず APNs 認証情報（認証キー／証明書）の有効期限と設定を疑う（最頻出の原因）
• 大量同報時のスループットを監視し、必要ならトピック配信へ寄せて個別送信の失敗・遅延を減らす
• TTL の効きすぎ・効かなさ（届かない／古い通知が残る）を、collapse key と TTL の設定で調整する
• BigQuery への配信データのエクスポートを有効化すると、配信ログを詳細に分析できる

コスト

FCM のメッセージ送信自体は無料で利用できるのが大きな特徴です。Android・iOS・Web へのプッシュ通知の配信に対して、通常は FCM 側の従量課金は発生しません。一方で、周辺サービスを使う部分にはコストが生じます。

セキュリティ

• 送信は信頼できるサーバーから: HTTP v1 API はサービスアカウントの OAuth2 トークンで認証する。クライアントに送信用の権限を持たせない
• 登録トークンを秘密として扱う: トークンは宛先 ID であり、漏えいすると第三者が通知を送れる恐れがある。安全な経路でサーバーへ送り、保護して保管する
• ペイロードに機密を載せない: 通知本文やデータに個人情報や秘密を含めず、ID だけ送って詳細は認証付き API で取得する
• iOS の認証情報を保護: APNs 認証キー／証明書を安全に管理し、期限切れを監視して更新する
• 最小権限: 送信に使うサービスアカウントには必要な権限のみ付与し、鍵をコードへ埋め込まない

関連サービス・比較

関連が深いのは、Google Cloud のメッセージング基盤である Pub/Sub です。両者は名前が似ていますが対象が異なり、Pub/Sub はサーバー間（バックエンド同士）の非同期連携、FCM はサーバーからエンドユーザーの端末への通知に向きます。

ハンズオン / CLI例

FCM の送信は通常 HTTP v1 API（サービスアカウント認証）で行います。下記は、送信に使うサービスアカウントを用意し、必要な API を有効化するまでの gcloud 例です。

# プロジェクトで Firebase Cloud Messaging API を有効化
gcloud services enable fcm.googleapis.com --project=my-project

# 送信用のサービスアカウントを作成
gcloud iam service-accounts create fcm-sender \
  --display-name="FCM message sender" \
  --project=my-project

# メッセージ送信に必要なロールを付与（最小権限の例）
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:fcm-sender@my-project.iam.gserviceaccount.com" \
  --role="roles/firebasecloudmessaging.admin"

# サーバーが OAuth2 トークン取得に使う鍵を発行（安全に保管すること）
gcloud iam service-accounts keys create fcm-sender-key.json \
  --iam-account=fcm-sender@my-project.iam.gserviceaccount.com