Push APIは、サーバー側から特定のクライアントブラウザへ任意のメッセージを配信し、ページが開かれていない状態でもService Workerを起動して通知を表示できるようにするWeb APIです。W3C Web Applications Working Groupが2015年に最初のワーキングドラフトを公開し、同年Chrome 42、Firefox 44で最初の実装が登場しました。それまでネイティブアプリの専売特許だったプッシュ通知をWebアプリでも実現する画期的な仕様で、PWAをネイティブアプリと並ぶ体験へ押し上げる中核ピースとして位置づけられています。
この記事の目次
- Push API・Notifications・Service Workerの三役
- Service Worker経由の配信フロー
- Web通知の用途と運用上の注意
- ネイティブプッシュとの違い
- まとめ
Push API・Notifications・Service Workerの三役
Webプッシュ通知は単一のAPIではなく、三つの仕様が連携して成り立っています。Push APIは「サーバーからのメッセージを受け取る購読の仕組み」、Notifications APIは「画面に通知バナーを表示する仕組み」、Service Workerは「ページが閉じていても動くバックグラウンド実行環境」です。サーバーが送信したメッセージはまずブラウザベンダーが運用するPush Service（FCM・Mozilla autopush・Windows WNSなど）を経由して端末に届き、ブラウザがService Workerを起動して push イベントを発火させ、Service Worker内で self.registration.showNotification を呼んで通知を表示する流れです。
購読のセットアップでは、まずService Workerを登録し、registration.pushManager.subscribe でサブスクリプションを取得します。このときVAPID鍵（Voluntary Application Server Identification）と呼ばれる公開鍵をブラウザに渡し、Push Serviceへの認証に使います。VAPIDは2016年に標準化され、それ以前のFCM秘密鍵に依存した運用から脱却して「ブラウザ非依存・サーバー独自鍵」での運用が可能になりました。これによりWebプッシュは真にオープンな標準として完成しました。
Service Worker経由の配信フロー
サーバーがプッシュ通知を送る流れを具体的に追うと、まずサーバーがPush Serviceに対し「このエンドポイントに対してメッセージを届けて欲しい」というHTTPリクエストを送信します。リクエストにはWeb Push Protocol（RFC 8030、2016年標準化）に従って暗号化（RFC 8291）されたペイロードと、VAPID鍵による署名（RFC 8292）が含まれます。Push Serviceは端末との接続を維持しており、適切な端末へメッセージを配信します。
端末側ではブラウザが受信を検知し、登録済みService Workerを起動して push イベントを渡します。Service Workerはイベント内でペイロードを復号し、self.registration.showNotification(title, options) を呼んでOS標準の通知UIで表示します。ユーザーが通知をクリックすれば notificationclick イベントが発火し、アプリのURLを開いたり、特定のページにフォーカスしたりといった処理が可能です。ペイロードを含めない「タップで再フェッチ」型と、ペイロードに本文を含める「ハイブリッド」型があり、セキュリティ要件に応じて選び分けます。
Web通知の用途と運用上の注意
Push APIが活躍する代表的な分野は、ニュースサイトの速報配信です。BBC・NHK・New York Timesなど主要メディアが採用しており、ユーザーがブラウザを開いていない時間でも重要なニュースを即座に届けられます。WebメールやチャットツールではSlack Web版・Google Chat Web版などが新着メッセージ通知に利用しています。ECサイトでは「カートに商品を入れたまま離脱した」ユーザーへの復帰促進通知や、セール開始のアナウンスに使われ、業務SaaSでは作業完了・承認待ち・障害発生など状態変化を即時にユーザーへ届ける用途で広く普及しています。
一方で運用には注意が必要で、初訪問時にいきなり許可ダイアログを出すサイトが嫌われたため、ChromeやSafariは「ユーザー操作の直接の応答時のみ許可ダイアログを出せる」よう仕様を厳格化しました。iOS Safariは長らくWebプッシュ未対応でしたが、2023年3月のiOS 16.4でホーム画面に追加したPWA限定で対応開始し、AndroidとmacOS・WindowsのChromeに続いて主要プラットフォームが揃いました。通知頻度・タイミング・配信内容の質を維持しないとユーザーは即座に通知を切ってしまうため、送る価値のある情報だけを丁寧に選ぶ運用設計が成否を分けます。
ネイティブプッシュとの違い
ネイティブアプリのプッシュ通知（iOS APNs・Android FCM）と比較すると、Web Pushはブラウザを介する分リッチなUI拡張（添付画像・ボタン応答など）に若干の制約があり、表示できる項目はOSやブラウザ依存です。またiOS Safariはホーム画面に追加したPWAでしかWebプッシュを受け取れず、通常のSafariタブでは未対応のため、iPhoneユーザーへ届けるには「ホーム画面追加」を促す導線が必要です。それでもWeb標準として実装されている強みは大きく、ネイティブアプリの開発・配布・審査を経ずにプッシュ通知の体験を提供できます。
Webプッシュの設計上の優位点は、Push Service（FCM・autopushなど）を経由する仕様によりベンダーロックインが起きにくい点、VAPID鍵により自前サーバーから直接配信できる点、Service Workerと連携してオフラインキャッシュや非同期処理と一体で扱える点です。PWAの普及とiOSの対応開始により、Webプッシュはネイティブと並ぶ通知手段として位置を確立しつつあります。ユーザーの許可を尊重した節度ある運用ができれば、Webアプリの定着率・継続率を引き上げる強力な武器になります。
まとめ
Push APIは、Service Worker・Notifications APIと連携して、Webアプリにネイティブ並みのプッシュ通知体験をもたらすWeb標準です。VAPID鍵により自前サーバーから配信でき、iOS 16.4以降のPWAを含む主要プラットフォームに対応しました。節度ある運用ができれば、Webアプリの存在感をユーザーの日常に強く刻み込む武器になります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント