プッシュ通知のアーキテクチャ

アプリサーバーは端末に直接送れない

プッシュ通知の出発点は単純な制約です。端末はキャリア回線やWi-Fiの背後でNAT越しにあり、グローバルにルーティング可能なアドレスを持ちません。さらに常時起動していないアプリのプロセスに、外部から直接ソケットを開くことも不可能です。そこでAppleとGoogleは、端末側にOSレベルで常時接続を1本だけ維持し、あらゆるアプリ宛ての通知をそこに多重化するという設計を取りました。これがAPNs（Apple Push Notification service）とFCM（Firebase Cloud Messaging）です。

配信経路は次の順で固定されています。

アプリサーバー → (HTTP/2 + 認証) → APNs/FCMゲートウェイ
                                        ↓
                              端末との永続TLSコネクション（OS管理・全アプリ共有）
                                        ↓
                                   OS側デーモンが受信
                                        ↓
                              対象アプリへローカルにディスパッチ

アプリサーバーが持つのは「このゲートウェイに、この宛先identifierで投げる」権限だけで、端末までの物理的な経路や再送のタイミングはOSベンダーが完全に握っています。この非対称性が、後述する到達保証の限界に直結します。

デバイストークン：宛先の実体と失効

デバイストークンは、アプリのBundle ID/パッケージ名 + 端末 + OSインスタンスの組み合わせに対してAPNs/FCMが発行する不透明なidentifierです。中身に端末のハードウェア識別子は含まれず、あくまで「このゲートウェイ内でこの宛先を指す鍵」に過ぎません。重要なのはトークンが恒久的ではない点です。

サイレント通知とバックグラウンド起床

通常のプッシュはユーザーに見えるバナー・音・バッジを伴いますが、content-available（APNs）や高優先度データメッセージ（FCM）を使うサイレント通知は、UIを出さずにアプリのバックグラウンド処理だけを短時間起動させる仕組みです。用途はメールの事前フェッチ、コンテンツの差分同期、設定の反映など多岐にわたります。

ただしサイレント通知は「起動を要求する」だけであり、「必ず起動する」わけではありません。OSはバッテリー残量、直近のアプリ使用頻度、サーマル状態、低電力モードの有無などを見て、サイレント通知を間引く、遅延させる、あるいは複数をまとめて一度に処理するといった調整を行います。これは仕様上の抜け穴ではなく、電力管理を最優先事項とするOSの設計方針そのものです。

到達保証の限界：ベストエフォートの意味

APNs/FCMはベストエフォート配信であり、メッセージキューが持つような厳密な到達保証（at-least-once／exactly-once）はどちらも提供しません。到達しない経路（at-most-once的な欠落）と、再送によって二重に届く経路（at-least-once的な重複）の両方が起こりうるため、「どちらか一方に近い」と単純化はできない点に注意が必要です。具体的には次の性質を前提に設計する必要があります。

• 到達しないことがある。端末がオフライン、ストレージ逼迫、OS側の間引きなどにより通知が消える経路が複数存在する。
• 順序は保証されない。複数の通知がネットワークの揺らぎで逆順に届くことがある。
• 重複配信が起こりうる。ゲートウェイの再送ロジックにより同一通知が二重に届く場合があるため、受信側でidentifierによる冪等な重複排除が必要。
• 同一宛先に対する通知の上書き。同じcollapse key（FCM）／apns-collapse-id（APNs）を使うと、未読の古い通知を新しい通知が置き換える設計にできるが、これは信頼性の担保ではなく表示制御の機能。

これらの性質から導かれる実務上の結論は明確です。プッシュ通知は「同期が必要になったことをアプリに知らせるトリガー」であって、データそのものの配送チャネルではないという位置づけで設計します。通知本文に業務データを直接載せず、通知を受けたらサーバーへ問い合わせて最新状態をプルする、あるいはアプリ起動時に独立したバックグラウンド同期（定期フェッチやWebSocketの再接続）で状態を補完する、という二段構えが定石です。

バッテリーへの配慮という設計原則

常時接続チャネルとバックグラウンド起床という仕組みそのものが電力コストを伴うため、OS側もアプリ側も省電力を前提に設計されています。OSは全アプリの通知を1本の共有コネクションに集約することで、アプリごとに個別の常時接続を張るより無線モジュールのウェイクアップ回数を大幅に減らしています。アプリ側が取れる対策は、通知の送信頻度を業務上必要な最小限に絞ること、サイレント通知を多用しすぎないこと、バックグラウンド処理の実行時間を切り詰めることです。バッテリーへの配慮を欠いた設計は、OSの省電力制御によって通知そのものが間引かれるという形で跳ね返ってくるため、電力効率と到達性は表裏一体の関係にあります。

まとめ

プッシュ通知は、アプリサーバーとAPNs/FCMゲートウェイ、そしてOSが管理する端末との常時接続という3層構造の上に成り立ちます。デバイストークンは恒久的な宛先ではなく再登録を前提とした可変のidentifierであり、サイレント通知によるバックグラウンド起床はOSの省電力判断に常に従属します。何より、配信全体がベストエフォートである以上、到達・順序・重複排除のいずれも保証されないという限界を前提に、通知をトリガーとしたプル型の同期で補完する設計が不可欠です。基盤となる常時接続やバックグラウンド実行のスケジューリングは、/os/ が扱うプロセス管理・電力制御の話題とも地続きです。