プッシュ通知の仕組みとは？アプリ・Webへの配信経路と対応条件を解説

プッシュ通知が届く仕組みとは？

配信側のサーバーが作った通知は、端末へ直接は届きません。Apple、Google、ブラウザの提供元が運営する配信基盤がいったん受け取り、端末へ届けます。

通知が画面に表示されるまでには、許可・宛先の発行・送信・配信と表示という4つの段階を踏みます。

1. 許可：利用者が、アプリやサイトからの通知の受信を許可する

2. 宛先の発行：アプリやブラウザが配信基盤に登録すると、デバイストークン（iOS）、登録トークン（Android）、エンドポイント（Web）と呼ばれる宛先が発行される。配信側のサーバーはその宛先を保存する

3. 送信：配信側のサーバーが、宛先と通知の内容を配信基盤に送る

4. 配信と表示：配信基盤が端末へ通知を届け、OSやブラウザが画面に表示する

送信に成功しても、利用者の画面に表示されたとは限りません。端末の設定で通知が止められていたり、購読の宛先が無効になっていたりすれば、表示まで至らないためです。配信基盤が送信を受け付けた件数と、端末で表示・開封された件数は、別の数字として記録しましょう。

プッシュ通知の種類はどう分かれる？

プッシュ通知の種類を表すリモート・ローカル・リッチ・Webは、それぞれ別の観点で通知を分けた呼び名です。そのため、1つの通知が複数の呼び名に当てはまることがあります。

たとえば、サーバーから送られた画像付きの通知は、発する元で見ればリモート通知、表示の形式で見ればリッチ通知に当たります。仕様書や見積書にこれらの用語があれば、どの観点で使った言葉なのかを作成元に聞いておきましょう。なお、ローカル通知は端末の中で完結するため、次の章で解説する配信基盤は通りません。

【iOS・Android・Web別】プッシュ通知の配信経路（APNs・FCM）

プッシュ通知の配信経路は、iOSアプリやAndroidアプリ、Webなどの環境で異なります。

環境ごとに違うのは、配信基盤と端末側の受け取り方です。アプリはOSの提供元（Apple・Google）が運営する配信基盤（APNs・FCM）を、Webはブラウザの提供元のプッシュサービスを使うため、対応する環境ごとに開発の作業が分かれます。

iOSアプリ：APNsを経由して端末へ届ける

iOSアプリの配信基盤は、Appleが運営するAPNsです。アプリはAPNsに登録すると、端末とアプリを識別するデバイストークンを受け取ります。通知を送るときは、自社のサーバーがこのトークンと通知の内容をAPNsに送ります。端末まで届けるのはAPNsです。

Androidと共通の仕組みで配信するためにFCMを使う場合も、iOS端末への配信はAPNsを経由します。FCMでiOSに配信するには、AppleのAPNsの認証情報（認証キーまたは証明書）をFirebaseに登録しておかなければなりません。

※参考：Apple Developer「Registering your app with APNs」

※参考：Firebase「Apple プラットフォーム アプリで Firebase Cloud Messaging を使ってみる」

Androidアプリ：FCMを通じてメッセージを届ける

Androidアプリの配信基盤には、Googleが提供するFCMを使います。アプリがFCMから受け取る登録トークンが宛先で、自社のサーバーはそのトークンにあててメッセージを送る流れです。

FCMのメッセージには、アプリがバックグラウンドにあるときにFCMのSDKが表示を処理する「通知メッセージ」と、アプリ側で処理する「データメッセージ」があります。画面に出す内容をアプリ側で組み立てたいなら、データメッセージを選びます。

Android 13以降では、利用者から通知の権限を得ないとアプリは通知を表示できません。新しくインストールしたアプリは初期状態で通知がオフのため、権限を求める画面をどの場面で出すかを先に決めてください。

なお、OSのアップデートでAndroid 13以降になった端末では、通知チャンネルを持つ既存のアプリに通知の権限が自動で付与されます（アップデート前に、利用者がそのアプリの通知をオフにしていた場合を除く）。

※参考：Firebase「Firebase Cloud Messaging のメッセージ タイプ」

※参考：Android Developers「通知に関する実行時の権限」

Webプッシュ：ブラウザのプッシュサービスとService Workerで受信する

従来のWebプッシュは、ブラウザに備わったPush API、Service Worker、Notifications APIといった3つの仕組みを使って届きます。

サイトはService Workerを登録したうえで、Push APIで購読を申し込みます。このとき発行されるエンドポイントは、ブラウザの提供元が運営するプッシュサービスのURLです。自社のサーバーがここへ通知を送ると、ブラウザが受け取って表示します。

購読を申し込むときは、サイト側の公開鍵（VAPIDの鍵。Push APIではapplicationServerKeyとして渡す）を指定します。プッシュサービスはこの鍵を使って、購読させたサイトと通知を送ってきたサーバーが同じかを確かめます。通知の中身は暗号化して送るため、途中のプッシュサービスからは読めず、復号できるのは受け取ったブラウザだけです。

また、AppleのSafariには「Declarative Web Push」という方式があります。決められた形式で送られた通知を、Service Workerを使わずにブラウザがそのまま表示する仕組みです。

対応していない古いブラウザでは従来どおりService Workerが通知を処理するため、両方に対応した形で配信することもできます。

※参考：MDN Web Docs「プッシュ API」

※参考：WebKit「Meet Declarative Web Push」

※参考：web.dev「The Web Push Protocol」

Webプッシュの対応環境｜iPhone・iPadはPWA（ホーム画面のWebアプリ）が条件

Webプッシュを受け取れる条件は、端末とブラウザによって異なり、とりわけiPhoneとiPadには固有の条件があります。

※各ブラウザの提供元が公開している情報によります（2026年10月時点）

iPhoneとiPadで従来のWebプッシュを受け取れるのは、サイトをホーム画面に追加し、Webアプリ（PWA）として開いた場合に限られます。サイト側では、Webアプリマニフェスト（displayをstandaloneまたはfullscreenにしたもの）を用意しておく必要があります。また、許可を求める処理は、利用者がボタンをタップしたときなど、直接の操作を受けて呼び出す必要があり、ページを開いた直後に確認画面を出す実装は動きません。

AndroidやPCではホーム画面への追加が要らないため、購読までの手順はiPhone・iPadのほうが多くなります。アクセス解析で端末の内訳を確かめ、iPhone・iPadの割合が高ければ、マニフェストの用意や追加手順の案内ページまで実装の範囲に含めておきましょう。

※参考：WebKit「Web Push for Web Apps on iOS and iPadOS」

※参考：WebKit「WebKit Features in Safari 18.5」

プッシュ通知とメールは何が違う？

プッシュ通知は、許可した端末の画面に短い知らせを届ける手段で、メールは受信箱に記録として残る手段です。

プッシュ通知は、配信基盤を通して短いデータ（APNs・FCMでは1件あたり最大4KB）を届ける仕組みのため、長い本文や添付ファイルを送る用途には向きません。契約の内容や長い案内のように記録として残したい情報はメールで送り、プッシュ通知は新しい情報があることを知らせて、アプリやサイトの該当ページを開いてもらう入口として使い分けましょう。

※参考：総務省「迷惑メール対策」

※参考：Firebase「Firebase Cloud Messaging のメッセージ タイプ」

※参考：Apple Developer「Sending notification requests to APNs」

プッシュ通知で期待できる効果

プッシュ通知に期待できる効果は、アプリやサイトを閉じていても知らせられること、通知の内容しだいで再訪につながること、状況に合った案内を届けられることです。ただし、通知が表示される条件がそろわなければ、どの効果も得られません。

アプリやサイトを閉じていても知らせられる

プッシュ通知は配信基盤を通じて端末へ届くため、利用者がアプリやサイトを開いていなくても新しい情報を表示できます。在庫の入荷や申し込みの締め切りのように、早く知らせるほど価値が高い情報に向いています。

通知の内容しだいで再訪につながる

一度訪れた人に、新しい記事や商品の情報を通知で知らせれば、検索や広告を経由せずに再訪してもらうきっかけを作れます。

再訪につながるかどうかは、通知の中身に大きく左右されます。利用者にとって関係のない通知が続くと、通知の許可を取り消されるおそれがあるため、配信の頻度と内容を絞りましょう。

状況に合った案内を届けられる

購読情報と利用者の行動を結びつけて管理すれば、カートに商品を残したまま離れた人や、特定のページを読んだ人に絞って通知を送れます。

そのためには、購読情報を会員の情報やアクセスの記録とつなげて管理する仕組みが必要です。配信サービスを使うなら、絞り込みの機能が備わっているかを比べてください。

自社実装と配信サービスはどう選ぶ？

自社実装が向いているのは、開発・保守の担当者を社内に確保でき、必要な配信機能を自社で作れるときです。どちらかが難しいなら、配信サービスの活用をおすすめします。

APNsが提供するのは送信の仕組みです。FCMの管理画面では予約や絞り込み、簡単な分析ができますが、会員情報を使った細かな絞り込みや売上と結びつけた分析は、自社で作らなければなりません。自社実装なら、その工数まで見込んでおきましょう。

開発と保守の担当者を確保できるか

自社実装なら、ブラウザやOSの仕様変更を追い続けられる担当者を確保してください。開発のあとは仕様が変わるたびに対応が要り、Declarative Web Pushのような新しい方式が加わることもあるためです。たとえばAndroidでは、Android 13から通知の表示に利用者の許可（実行時の権限）が必要になり、アプリに許可を求める画面を組み込む対応が生じました。

必要な配信機能を用意できるか

配信の予約、対象の絞り込み、配信の上限の設定など、運用に必要な機能を書き出してみましょう。自社で作る機能が多いほど、配信サービスの月額と比べて開発費が高くつくことがあります。

配信結果を継続して確認できるか

送信の件数、開封の件数、購読の解除の件数を継続して記録しておくと、配信の効果を判断できます。配信サービスを選ぶときは、配信結果の画面で何がわかるかを確認しておきましょう。

まとめ：プッシュ通知は配信経路と対応環境を確認して導入しよう

プッシュ通知は、配信側の通知をAPNsやFCM、ブラウザのプッシュサービスなどの配信基盤経由で端末へ届ける仕組みです。Webプッシュは、端末やブラウザによって受け取れる条件が変わります。なかでもiPhoneとiPadは、ホーム画面に追加したWebアプリでしかWebプッシュを受信できないため注意してください。

対応端末と必要な配信機能が定まれば、自社実装か配信サービスかを判断できます。配信サービスの候補は、プッシュ通知サービスの比較記事や、BIZNAVIのWebプッシュ通知サービスのサービス一覧から探してみてください。

プッシュ通知の仕組みに関するよくある質問

プッシュ通知の仕組みについて、よくある質問にお答えします。

同じ通知が重複して届くのはなぜ？

主な原因は、同じ端末への購読の二重登録と、配信側による同じ通知の再送の2つです。このほか、アプリとWebの両方で購読している人には、同じ内容の通知が別々の経路で届くことがあります。

原因を探すときは、配信側の送信記録で同じ宛先に何回送っているかと、購読の登録が重複していないかを確認しましょう。送信が1回なのに2回表示されるなら、受信側のアプリやブラウザの処理を疑ってください。

端末を買い替えても通知は引き継がれる？

引き継がれない場合があります。通知の宛先は端末やブラウザごとに発行されるため、新しい端末では、アプリの通知の登録やWebの購読をやり直すのが基本です。

新しい端末でログインしたときに、通知の許可を改めて求める画面を出す設計にしておくと、配信の対象から外れる人を減らせます。

通信できない間の通知は後から届く？

届くかどうかは、通知に設定した有効期限と、配信基盤の条件によって異なります。有効期限の間に端末が通信できる状態に戻れば、配信基盤に保管された通知が届く仕組みです。APNsの場合、通知を保管する期限は最長30日の範囲で配信側が指定し、Webプッシュでは送信時にTTL（保管する秒数）で指定します。ただし、APNsが保管するのはアプリごとに1件だけで、多くの場合は最新の通知が残ります。届くことも保証されていません。

セール終了の知らせのように、時間が過ぎると意味のない通知には、短い期限を設定しておくと、期限切れの知らせが届くのを防げます。

※参考：Apple Developer「Sending notification requests to APNs」

※参考：web.dev「The Web Push Protocol」

プッシュ通知は無料で送れる？

配信基盤の利用料と、配信の運用にかかる費用は分けて考えましょう。Firebaseの料金ページでは、FCM（Cloud Messaging）は「無料」と記載されています。ただし、iOSアプリでAPNsを使うプッシュ通知は、Appleの公式ではApple Developer Program（年間登録料99米ドル、または現地通貨の同等額）のメンバーシップに含まれる機能として案内されています。なお、iPhone・iPadのWebプッシュもAPNsを使う仕組みですが、WebKitの公式ブログでは、Apple Developer Programの会員でなくても利用できると案内されています。

一方で、配信サービスを使えばその利用料が、自社実装なら開発と保守の費用がかかります。導入の費用を比べるときは、配信サービスの料金と、自社で作る場合の工数を見比べてください。

※参考：Firebase「Firebase 料金」

※参考：Apple Developer「メンバーシップの詳細 - Apple Developer Program」

※参考：WebKit「Web Push for Web Apps on iOS and iPadOS」

PWAでもプッシュ通知は届く？

届きます。PWA（アプリのように使えるWebサイト）の通知も、仕組みは通常のWebプッシュと同じで、Service WorkerとPush APIで受け取ります。ただし、iPhone・iPadで受け取れるのは、iOS・iPadOS 16.4以降で、サイトをホーム画面に追加し、そのWebアプリから通知を許可した場合です。

※参考：WebKit「Web Push for Web Apps on iOS and iPadOS」