iOS と Android のプッシュ通知: APNs と FCM の比較

比較するポイント（なぜ重要か）

APNs（Apple Push Notification service）と FCM（Firebase Cloud Messaging）は、サーバーから端末へメッセージを届ける配信パイプです。メッセージを受け取った後にアプリが何をするかは決めませんが、メッセージが到達するか、どれくらい早く届くか、どんな形式で送る必要があるかに大きな影響を与えます。

「Android では届くのに iOS では届かない」といった問題は、たいてい単一のバグではありません。iOS と Android はバックグラウンド処理、省電力、権限、メッセージ優先度の扱いが異なります。同じメッセージが遅延したり、古いメッセージに置き換えられたり、音なしで表示されたり、アプリが起動できずに表示されないこともあります。

この比較では実運用で驚きを生む主要点に絞っています：デバイストークンのライフサイクル、ペイロードの上限と構造、現実的な配信期待値、そして通知が「消える」一般的な原因です。

マーケティング戦略やプッシュプロバイダーの UI、フルアナリティクスの構築については扱いません。ここでの目的は信頼性の向上とデバッグの迅速化です。

用語メモ：

• トークン: APNs や FCM が発行する、デバイス固有の送信先アドレス。\n- トピック: （主に FCM で使う）複数デバイスが購読するグループアドレス。\n- チャネル: Android の通知カテゴリで、音や重要度・振る舞いを制御します。\n- Collapse key / collapse identifier: 保留中の古いメッセージを新しいもので置き換える仕組み。\n- TTL（time to live）: 配信のためにメッセージが有効でいられる時間。

これらの基本を押さえるだけで、「単純なプッシュ」がプラットフォームごとに異なる挙動をする際の推測時間を大幅に減らせます。

APNs と FCM の高レベルな仕組み

APNs と FCM はどちらもあなたのサーバーとユーザーの端末の間に入る仲介者です。アプリから直接インターネット経由で端末へ確実に通知を届けることはできないため、信頼された接続を維持している Apple（APNs）や Google（FCM）にその役割を任せます。

大まかな流れは同じです：アプリがトークンを取得し、バックエンドがそのトークンでプッシュサービスにメッセージを送ると、プッシュサービスが端末へ配信します。

APNs をわかりやすく説明すると

iOS ではアプリがリモート通知に登録し（通常はユーザーに許可を求めます）、Apple がデバイストークンを発行します。バックエンド（プロバイダと呼ぶことが多い）はそのトークンとペイロードを含むリクエストを APNs に送信し、APNs が配信可能か判断して端末に転送します。

バックエンドは通常、トークンベースの認証（署名キー）で APNs に認証します。古い構成では証明書を使うこともあります。

FCM をわかりやすく説明すると

Android ではインスタンスが FCM に登録して登録トークンを受け取ります。バックエンドが FCM にメッセージを送り、FCM が適切な端末へルーティングします。アプリの状態やメッセージタイプによっては、FCM が自動的に通知を表示するか、アプリにデータを渡して処理させます。

バックエンドは API キーやサービスアカウントといったサーバー認証情報で FCM に認証します。

あなたがコントロールできるのはアプリコード、許可を求めるタイミング、トークンの保存、バックエンドロジック、送るペイロードです。Apple と Google がコントロールするのは配信ネットワーク、到達性、スロットリングルール、そして省電力やシステムポリシーなどのラストマイル条件です。

トークンのライフサイクル：発行・更新・無効化の仕組み

APNs と FCM の日常的な違いで最も重要なのは、トークンは「一度設定したら永遠に変わらない」ものではないという点です。住所だと考え、変わることを前提に扱ってください。

iOS では APNs のデバイストークンはデバイス、アプリ、Apple の開発設定に紐づきます。アプリの再インストール、デバイスの復元、特定の OS アップデート、開発中の sandbox と production の切替などで変わることがあります。

Android では FCM の登録トークンはアプリの復元、ユーザーがアプリデータを消去したとき、Google によるトークンローテーション、再インストール等で更新され得ます。アプリはリフレッシュイベントを想定し、新しいトークンを速やかにサーバへ送るべきです。

シンプルなルール：トークンは必ず upsert（更新を含む保存）し、決して「一度入れたら忘れる」なかれ。保存時には重複や誤配信を避けるために以下のコンテキストを保持しましょう：

• ユーザーまたはアカウント ID（該当する場合）
• アプリのバンドル／パッケージと環境
• プラットフォーム（iOS/Android）
• トークン値と最終確認タイムスタンプ
• オプトイン状態（許可あり/なし）

削除も重要です。トークンが無効になったことは多くの場合、配信エラーから知ります。APNs が Unregistered（多くは 410）、または FCM が NotRegistered/Unregistered を返したら、即座にそのトークンを削除して無駄なリトライをやめましょう。

注意点の一つ：顧客がログアウトして別の人が同じ端末でログインしたときにトークンをクリア／再割当しないと、別人へ通知が行ってしまうことがあります。これも実運用でよくある落とし穴です。

ペイロード制約とメッセージ構造の違い

実務上の大きな違いは、メッセージにどれだけの情報を入れられるか（サイズ）と、到着時に端末がどう扱うかです。

多くのチームが頼る基本フィールドは：

• タイトルと本文\n- バッジ（iOS）\n- サウンド（デフォルトまたはカスタム）\n- カスタムのキーと値（例: order_id, status）

サイズ制限：プッシュは小さく保つ

両方のサービスにペイロードサイズの上限があり、カスタムデータも含めて上限に達すると配信が失敗したり期待どおりに動作しなくなります。

信頼できるパターンは短い通知と識別子だけを送り、詳細はバックエンドから取得することです。

例：フルの注文要約を送る代わりに、{"type": "order_update", "order_id": "123"} のようにして、アプリ側で最新情報を API から取得させます。

データオンリー vs 通知の挙動

Android では “notification” ペイロードが含まれると、アプリがバックグラウンドにいる場合にシステムが自動で表示することが多いです。データオンリーはアプリコードへ渡されますが、背景制限やバッテリー設定で遅延やブロックを受ける可能性があります。

iOS ではアラート（タイトル/本文）は直接的ですが、バックグラウンド更新はより厳格です。バックグラウンドプッシュでアプリコードが即時に実行される保証はありません。あくまでリフレッシュのヒントと考えてください。

信頼性が必要なら、ペイロードを最小限にして安定した識別子を含め、アプリが開いたときや再開時に状態を照合する設計にしましょう。

配信期待値と通知を止める要因

APNs も FCM も配信はベストエフォートです。プロバイダはメッセージを届けようとしますが、端末が必ず表示することを保証しません。

到達性（端末がオンラインか）は最初の制限です。あなたが送るときに TTL や有効期限を設定します。端末がそのウィンドウ外でオンラインになれば、プッシュは破棄されます。TTL を長くしすぎると古いアラートが後で表示されてバグに見えることがあります。

優先度はタイミングに影響しますが、無制限に高優先を使えるわけではありません。ハイプライオリティは端末がスリープしている時の即時配信に有効ですが、乱用するとスロットリング、バッテリー消費、OS の扱いで不利になります。

両システムとも collapsing をサポートしており、古いメッセージを新しいもので置き換えることができます。APNs は collapse identifier、FCM は collapse key を使います。order_status のように collapse を使うと、ユーザーはすべてのステップを見るのではなく最新の状態だけを見ることになります。

プロバイダが正常に配信しても、端末側でユーザーが見られないことがあります：

• Do Not Disturb / Focus モードでサイレント化や非表示になる\n- アプリの通知設定でオフまたは静かな配信にされている\n- Android の通知チャネルがオフになっている\n- バックグラウンド制限やバッテリーセーバーが配信や処理を遅延させる\n- 類似のアラートを多数出していて OS が抑制する

プッシュは信頼性の低い輸送手段だと割り切り、重要な状態はバックエンドに保持しておき、通知が一度も表示されなくてもアプリを開けば最新が取れるようにしておきましょう。

配信に影響する権限と端末設定

多くの「配信問題」は実際には権限や設定の問題です。

iOS では最初の権限プロンプトが重要です。ユーザーが「許可しない」を選ぶと、設定で変えるまで通知は表示されません。許可後でもロック画面、通知センター、バナー、音、バッジなどを個別にオフにできます。Focus モードや Scheduled Summary も通知を隠したり遅らせたりします。

Android では OS バージョンにより要件が変わります。新しいバージョンではランタイム通知権限が必要になり、アプリのアップデートで通知が表示されなくなることがあります。表示の可視性は通知チャネルに依存します。チャネルがミュートや低重要度だと通知は届いても割り込みません。

バックグラウンド制限も期待を壊します。iOS の Low Power Mode や Android のバッテリー最適化はバックグラウンド処理を遅延させたり、データ処理を止めたりして、データオンリーのメッセージが処理されない原因になります。

何が起きているか確認するには、サーバーが送った内容だけでなく端末側で見えているものをログに残してください：

• アプリ内ログ: “permission granted”, “token registered”, “notification received”, “notification displayed”\n- OS の指標: 通知設定の状態（有効/ミュート/チャネル重要度）、バッテリーモード\n- プッシュコールバック: フォアグラウンド／バックグラウンドでアプリがメッセージを受け取ったかどうか

バックエンドがノーコードツールでも、クライアント側ログが「メッセージ未受信」と「受信したが抑制された」を分けるポイントになります。

手順：通知が来ない時のトラブルシューティング

プッシュが見つからないときはチェーン（トークン → プロバイダ → ペイロード → アプリ挙動）として扱ってください。症状は iOS と Android で似るので、順序立てて同じ点を確認します。

• 現在のトークンに送っているか確認する。 サーバーに保存しているトークンとアプリが最後に報告したトークンを比較し、各トークンの最終受信時刻をログに残します。\n- 送信前にペイロードを検証する。 プラットフォーム上限を超えていないか、必須フィールドがあるか、JSON が壊れていないか。データオンリーを送るならアプリがそれを処理するビルドか確認します。\n- プロバイダの資格情報と環境を確認する。 APNs ならキー/証明書、チーム、バンドル ID、sandbox と production のターゲットが合っているか。FCM なら正しいプロジェクトの資格情報かを確認します。

次に、メッセージ内容か端末/アプリの挙動かを切り分けます：

• 最小のテスト通知を送る。 タイトル/本文だけの小さなペイロードで輸送が機能するか確認します。\n- アプリ側ハンドラとフォアグラウンド挙動を検証する。 多くの「 missing 」は受信済みだが表示されていないだけです。フォアグラウンドでバナーを抑制する設計もよくあります。\n- 変数は一つずつ変える。 別の端末、異なる OS バージョン、Wi‑Fi とモバイル、別アカウントなどで試し、もし一つのアカウントだけ失敗するなら古いトークンやサーバー側のターゲティングが怪しいです。

実践的パターン：iOS ユーザーが見逃しを報告するが Android は問題ない場合、まず iOS に最小のアラートを送ってみてください。成功すればペイロード構造やアプリ側の処理を見直し、失敗すればトークンと APNs の資格情報／環境に注目します。

無音で失敗する一般的な間違い

ほとんどのプッシュ問題は障害ではなく、アプリが期待することと APNs / FCM が受け入れること、あるいは端末が許すことの小さな不一致です。

最も多いのは無効なトークンに送信しているケースです。トークンは再インストールや復元、リフレッシュで変わります。サーバーが古い値を使い続けると通知はどこにも届きません。

もう一つは配信が保証されると考えることです。ベストエフォート配信では端末がオフラインだったり省電力下だと遅れたり欠落したりするのは普通です。重要なイベント（注文更新やセキュリティ通知）はアプリ内のフォールバック（開いたときに最新状態を取得するなど）を用意してください。

よくある欠落原因：

• 再インストールやリフレッシュ後に残った古い iOS/Android トークン\n- ペイロード上限を超えている（カスタムデータが多すぎる、画像が大きすぎる、文字列が長すぎる）\n- サイレント更新を背景配信に頼っていて OS によってスロットルされる\n- iOS の環境（development vs production）を混在させてトークンと APNs エンドポイントが一致しない\n- ユーザーのオプトアウト、Focus/Do Not Disturb、無効化された通知チャネル（Android）、アプリ側の通知権限を無視している

例：小売アプリが「注文出荷」通知に追跡履歴の巨大な JSON を詰めて送ると、送信は成功ログに見えてもペイロードが拒否または切り詰められ、ユーザーには何も表示されません。プッシュは小さくし、詳細は API に置きましょう。

まずプロバイダのせいにする前のクイックチェックリスト

プロバイダが問題だと決めつける前に次を確認してください：

• トークンが正しいか（ユーザーと端末に合っているか）。 存在し、最近更新され、正しいセッションに紐づいているか。\n- プロバイダの資格情報が今も有効か。 APNs のキー/証明書と FCM の資格情報が適切なアプリ／プロジェクトを指しているか。\n- ペイロードの形とサイズを検証する。 上限内で正しいフィールドを使っているか。\n- TTL、優先度、collapse を意図的に設定しているか。 短い TTL は端末がオンラインになる前に期限切れになる可能性があります。低優先度は遅延を招きます。collapse は古いメッセージを置き換えます。\n- “サーバーが受け付けた”と“端末が表示した”を分ける。 サーバーログ（リクエスト/レスポンス/メッセージID）とクライアントログ（使用されたトークン、ハンドラが呼ばれたか）を照合してください。

その後は端末チェック：アプリの通知が許可されているか、Android のチャネル設定が正しいか（チャネルがよく落とし穴になります）、Focus や DND、バックグラウンド制限の有無などを確認してください。

例：注文更新通知が届かないときの診断

サポート担当が注文 #1842 の「注文更新を送る」をタップしました。バックエンドログは「notification sent」と出ていますが、顧客の iPhone も Android も何も表示しません。

まずバックエンドから始めます。多くの「消えた」通知は、プッシュサービスに受け入れられていないか、受け入れられたが後で端末が表示できないために破棄されたかのどちらかです。

まずバックエンドで確認すること

送信がトレースできる単一の試行かを確認してください（1 回の注文更新は 1 回のプッシュリクエストであるべきです）。その上で：

• そのユーザー／端末に保存されている最新のトークンを使っているか。\n- プッシュプロバイダのレスポンスが成功で、エラーコードを保存しているか。\n- ペイロードがプラットフォームのルールに合っているか（サイズ上限、必須フィールド、有効な JSON）。\n- 認証が有効か（APNs のキー/証明書とチーム/バンドル ID、または FCM の資格情報）。\n- iOS の場合、正しい環境（sandbox vs production）をターゲットにしているか。

ログに "unregistered/invalid token" のような拒否があればトークンライフサイクルの問題です。プロバイダがメッセージを受け入れているのに届かないなら、ペイロードタイプや OS の挙動に注目します。

端末側で確認すること

端末がアラートを表示できる状態かを検証します：

• アプリの通知が有効（ロック画面／バナーで表示される設定になっている）か。\n- Focus/Do Not Disturb や通知サマリーで隠されていないか。\n- バッテリーセーバーがバックグラウンド処理を制限していないか（Android で多い）。\n- メッセージタイプとアプリ状態が合っているか（フォアグラウンドではアラートを抑制する設計もある）。

よくある結論：トークンは最新だがメッセージがデータオンリー（Android）か、iOS での背景処理の設定が不足しており OS がアラートを表示していないことがあります。解決策は表示したいなら可視化するペイロードを送る、背景更新なら適切な iOS 設定を整える、そしてトークン更新とプロバイダ応答をちゃんとログに残すことです。

次のステップ：プロダクトでのプッシュ信頼性向上

プッシュはコア機能になるまではシンプルに見えますが、信頼性を保つにはあなたがコントロールできる部分（トークン管理、ペイロード設計、フォールバック経路）を整えることが重要です。

欠落を前提に設計してください。プッシュは「今見てほしい」場面に向いていますが、重要なイベントだけに頼ってはいけません。アプリ内の受信箱を用意してユーザーが後から追えるようにしたり、パスワードリセットや支払い問題など重要な通知はメールや SMS を併用するのが安全です。

ペイロードは軽く保ち、プッシュは完全なメッセージではなく促しとして扱ってください。イベントタイプと ID を送り、アプリが開いたときにバックエンド API から詳細を取得する流れにすると良いです。

チームで使える短いランブック（トラブルシューティング手順）を作っておくと、デバッグが一貫して速くなります：オプトイン状態、トークンの鮮度、プロバイダ応答コード、ペイロードサイズ/形、環境／資格情報などをチェック項目に含めましょう。

もし AppMaster (appmaster.io) を使って構築しているなら、トークン保存、監査ログ、プッシュトリガーのビジネスロジックを一つのバックエンドにまとめることで扱いやすくなります。一方でネイティブの iOS/Android アプリは APNs と FCM を正しく扱う形で配布してください。