LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Web Push通知とは、ブラウザが仲介するサーバー発の通知配信

Web Push通知とは、ネイティブアプリを介さずにWebサイトからブラウザ経由でユーザーの端末へ通知を届ける仕組みを指します。ユーザーがサイトを閉じていても、Service Worker(ブラウザがバックグラウンドで動かす制御スクリプト)がメッセージを受け取り、OS標準の通知として表示します^*3*1。

この配信の三者関係は、Web Pushの標準仕様であるIETF RFC 8030に定義されています。関与するのはメッセージの送信元である「アプリケーションサーバー」、配信を仲介する「プッシュサービス」、受信者である「ユーザーエージェント(ブラウザ)」の3者です^*7。プッシュサービスはユーザーのブラウザベンダーが運営するWebサービスで、Chrome/EdgeはFirebase Cloud Messaging(FCM)、FirefoxはMozilla Autopush、SafariはApple Push Notification service(APNs)がそれぞれ担っています^*4*8。

アプリ配信で使われるネイティブプッシュ通知(FCM/APNsを直接組み込む方式)とは別の仕組みです。Web Pushはブラウザの標準API(Push API・Notifications API・Service Worker)だけで成立するため、専用のモバイルアプリを開発・配布しなくても、Webサイトからの通知配信をユーザーへ届けられます^*1*2。

Web Pushを支える3つの仕組み——Service Worker・Push API・Notifications API

Service Worker——ページを閉じても動くバックグラウンド処理の基盤

Service Workerは、Webアプリとブラウザ、ネットワークの間に立つプロキシとして動作するJavaScriptファイルです^*3。ダウンロード・インストール・アクティベートという3段階のライフサイクルを経て有効化され、以降はページを閉じた状態でもバックグラウンドでイベントを受け取れます^*3。Service Workerの実行にはHTTPS(セキュアコンテキスト)が必須で、これは通信の途中でのなりすましを防ぐための制約です^*3。

Push API——Service Worker経由でメッセージを受信する仕組み

Push APIは、Webアプリがサーバーからのプッシュメッセージを受信するための仕組みです^*1。ユーザーの同意後、PushManager.subscribeを呼び出すとPushSubscription(配信先のエンドポイントURLと暗号化用の鍵情報を含むオブジェクト)が生成されます^*1。このエンドポイントをアプリケーションサーバー側のデータベースに保存しておき、配信のたびに利用します^*1。メッセージが届くとService Worker内でpushイベントが発火し、通知表示などの処理を実行できます^*1。

Notifications API——OS標準の通知として画面に表示する仕組み

Notifications APIは、通知の表示そのものを制御するAPIです^*2。Push APIが「メッセージの受信」を担うのに対し、Notifications APIは「通知の表示」を担う点で役割が異なります^*2。Service Workerから呼び出すServiceWorkerRegistration.showNotificationは、ページを閉じた後も保持される永続的通知を生成でき、モバイル端末ではこの方式が前提になります^*2。

通知を表示するには、事前にユーザーから許可を得る必要があります。Notification.requestPermissionを呼び出すと許可ダイアログが表示され、ユーザーの選択(許可・拒否)はブラウザ側に保持されます^*2。この許可要求は、ボタンクリックなどユーザー操作をきっかけに実行することが推奨されています^*4。

VAPIDとプッシュサービス——誰がメッセージを届けているのか

プッシュサービスは配信の仲介役ですが、送信元がどのアプリケーションサーバーなのかを判別する仕組みが必要です。この役割を担うのがVAPID(Voluntary Application Server Identification)で、IETF RFC 8292として標準化されています^*6。

VAPIDでは、アプリケーションサーバーがECDSA(楕円曲線暗号によるデジタル署名アルゴリズム。P-256曲線を使用)の鍵ペアを生成し、秘密鍵で署名したJWT(JSON Web Token)を配信リクエストに添付します^*6。プッシュサービスは対応する公開鍵でこの署名を検証し、リクエストの送信元を継続的に識別できます^*6。JWTには配信先プッシュサービスのオリジンを示す「aud」クレームと、任意で連絡先を示す「sub」クレームを含めます^*6。RFC 8292は、鍵交換用の鍵と署名用の秘密鍵を別に用意する必要があると定めています^*6。

プッシュサービス側の実装は、ブラウザベンダーごとに異なります。Mozilla Autopushの場合、アプリケーションサーバーが配信に使うエンドポイントは3系統(送信用・未配信メッセージ削除用・ブリッジ登録用)に分かれ、標準のWeb Push APIを使う開発者にとってはエンドポイントの内部実装は「不透明」として扱われます^*8。この設計により、ブラウザベンダー側の実装が変わっても、アプリケーションサーバー側のコードに影響が及びにくくなっています^*8。

配信データそのものにも暗号化が求められます。PushSubscriptionに含まれる鍵情報を使ってペイロードを暗号化することが前提となり、プッシュサービスはメッセージの中身を読み取れない設計です^*1*4。

iOS Safariの対応条件——ホーム画面追加とバージョン16.4以降

iOSでのWeb Push対応は、モバイル向けWeb Pushの実装可否を左右する重要な条件です。AppleはWebKit公式ブログで、iOS/iPadOSのバージョン16.4(2023年3月公開)からWeb Push・Push API・Notifications API・Service Workerを組み合わせた通知配信に対応したと発表しました^*5。

対応には条件があります。iOS/iPadOSでは、対象のWebサイトが「ホーム画面に追加」された状態であることが前提です^*5。具体的には、WebアプリのManifestファイルでdisplayプロパティがstandaloneまたはfullscreenに設定され、ユーザーがホーム画面に追加したうえで、そのアイコンから起動した状態でのみ通知の許諾を求められます^*5。Safariのタブでブラウジングしているだけでは、購読の申請自体ができません。また通知の許可要求は、ユーザーの直接操作(サブスクライブボタンのタップなど)に応じて呼び出す必要があるとされています^*5。Apple Developer Programへの登録は、この機能の利用に必須ではありません^*5。

この条件には過去に例外的な動きもありました。Appleは2024年3月公開のiOS 17.4で、EU域内のみホーム画面Webアプリの機能を制限する方針を一時発表しましたが、公開直前に方針を撤回し、EU域内でも従来どおりの機能を維持すると表明しています^*9。現在はEU域内・域外を問わず、同じ条件(ホーム画面追加とバージョン16.4以降)でWeb Pushが利用できます^*9*5。

この「ホーム画面追加が前提」という制約は、Android ChromeやデスクトップのWebサイトのような「サイトを開いただけで許諾を求められる」体験とは異なります。iOSユーザー向けにWeb Pushを届けたい場合は、ホーム画面追加を促す導線をあらかじめ用意しておく設計が欠かせません。

実装の実務——許諾UX・購読管理・配信基盤の設計

Web Push通知の実装は、標準APIを呼び出すだけの作業では終わりません。運用に乗せるには、許諾を得るタイミングの設計、購読情報の管理、配信基盤の構築という3つの実務が発生します。

許諾UXについては、ページ読み込み直後に許可ダイアログを表示する実装は避ける必要があります。web.devのガイドは、ユーザーが操作の意図やタイミングを理解していない状態での許可要求は、拒否や通知のブロックにつながりやすいと指摘しています^*4。ボタンクリックなど明確なユーザー操作をきっかけにNotification.requestPermissionを呼び出す設計が推奨されます^*2*4。

購読管理では、PushSubscriptionのエンドポイントと鍵情報をユーザー単位でデータベースに保存し、購読の失効に備える必要があります。ブラウザはonpushsubscriptionchangeイベントで購読の無効化を通知するため、Service Worker側でこのイベントを監視し、再購読を促す処理を組み込みます^*1。

配信基盤の構築では、VAPID鍵ペアの生成・保管、プッシュサービスへのリクエスト送信、ペイロードの暗号化を自前で実装する方法と、これらを代替するSaaS型の配信サービスを利用する方法の両方が選べます。配信先の端末数が多い場合、CSRF/XSRF対策や購読データの整合性チェックなど、セキュリティ面の実装負荷も増えます^*1。

オプトイン率と不達対策、プライバシー配慮の考え方

Web Push通知の効果は、購読してもらえるかどうか(オプトイン率)と、配信したメッセージが実際に届くかどうかの両方に左右されます。

オプトイン率を高めるためには、通知を許可する動機をユーザーに伝える導線が重要です。単に許可ダイアログを出すのではなく、通知で受け取れる情報(再訪の案内、更新のお知らせなど)を事前に説明し、ユーザー自身が判断できるようにする設計が、拒否率を抑える方向に働きます^*4。一度「拒否」を選択されると、ブラウザによっては再度の許可要求ができない、または通知欄からの再設定が必要になる仕様もあるため、初回の見せ方が重要になります^*2。

配信の不達については、ブラウザやOSのクォータ制限、購読の失効、端末側の通知オフといった複数の要因が関わります^*1。配信結果のログを追い、失効した購読情報を除外する運用を継続することが、実務上の不達対策になります。

プライバシー配慮の観点では、通知の内容にユーザーの個人情報を含めすぎない設計が基本です。配信のペイロードは暗号化されますが、通知に表示する文言自体は端末の画面に表示されるため、他人にも見える場所での通知内容には注意が必要です^*1。また購読の許諾・解除の手段をユーザーが自分で管理できるよう、設定画面や配信停止の導線をわかりやすく用意しておくことが、利用者側の納得感につながります。

内製と外注の分かれ目——配信基盤と運用体制の工数で判断する

Web Push通知の実装そのものは、公開されている標準APIとRFC仕様に沿って進められるため、対象ブラウザが限定的で配信規模が小さい場合は自社で対応できる場合もあります^*1*7。判断が分かれるのは、iOS/Android/デスクトップの複数環境に対応し、配信基盤の安定運用まで含めて構築する場合です。

専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目になります。Service Worker・Push API・Notifications APIの実装からVAPID鍵の管理、購読データベースの設計、iOS Safariのホーム画面導線設計までを一括して依頼できるかどうかを確認します^*5*6。内製では、既存のフロントエンド担当者が通常業務と並行して対応することになり、複数ブラウザでの動作検証や配信基盤の保守に割ける時間が限られる場合があります。

。対象ブラウザの範囲や配信規模、既存サイトのPWA対応状況によって必要な工数は変わってきます。現状のサイト構成を確認したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：Web Push通知の実装で押さえる3つの判断軸

本稿ではブラウザのWeb Push通知の仕組みと実務を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、Web PushはService Worker・Push API・Notifications APIの3つが連携し、VAPIDによる送信元識別を経てプッシュサービスがメッセージを配信する構成です^*1*2*3*6。第二に、iOS Safariは2023年3月公開のバージョン16.4以降で対応していますが、ホーム画面に追加したWebアプリであることが条件で、この条件はEU域内でも変わらず維持されています^*5*9。第三に、許諾UXの設計や購読管理、配信基盤の安定運用まで含めると実装負荷は小さくなく、対応ブラウザの範囲や配信規模によって内製と外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：MDN Web Docs「Push API」（https://developer.mozilla.org/en-US/docs/Web/API/Push_API）
2. *2　出典：MDN Web Docs「Notifications API」（https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API）
3. *3　出典：MDN Web Docs「Service Worker API」（https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API）
4. *4　出典：web.dev「Push notifications overview」（https://web.dev/articles/push-notifications-overview）
5. *5　出典：WebKit Blog「Web Push for Web Apps on iOS and iPadOS」（2023年2月16日）（https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/）
6. *6　出典：IETF RFC 8292「Voluntary Application Server Identification (VAPID) for Web Push」（https://datatracker.ietf.org/doc/html/rfc8292）
7. *7　出典：IETF RFC 8030「Generic Event Delivery Using HTTP Push」（https://datatracker.ietf.org/doc/html/rfc8030）
8. *8　出典：Mozilla「HTTP Endpoints for Notifications」（Autopush Server documentation）（https://mozilla-services.github.io/autopush-rs/http.html）
9. *9　出典：AppleInsider「Apple reverses course on death of Progressive Web Apps in EU」（2024年3月1日）（https://appleinsider.com/articles/24/03/01/apple-reverses-course-on-death-of-progressive-web-apps-in-eu）

Tweet