プッシュ通知の概要、プッシュ通知を使用する理由、仕組みについて説明します。
プッシュ通知とは
push メッセージを使用すると、ユーザーがウェブサイトを使用していないときでも、ユーザーの注意を引くことができます。ユーザーがアクティブでない場合でも情報を「プッシュ」できるため、pushpush メッセージと呼ばれます。このコンセプトをさらに理解するには、push テクノロジーと pull テクノロジーを比較してください。
通知は、ユーザーに情報の小さなチャンクを表示します。ウェブサイトは通知を使用して、時間的制約のある重要なイベントや、ユーザーが行う必要があるアクションをユーザーに通知できます。通知のデザインは、プラットフォームによって異なります。
プッシュ メッセージと通知は、互いに補完する別の技術です。push は、ユーザーがウェブサイトを使用していないときでも、サーバーからメッセージを送信するためのテクノロジーです。通知は、プッシュされた情報をユーザーのデバイスに表示する技術です。プッシュ メッセージなしで通知を使用することもできます。ある日、ユーザー向けの通知なしで push メッセージを使用（サイレント push）することも可能になるかもしれませんが、現時点ではブラウザではそのようなことが許可されていません。実際には、通常は一緒に使用されます。技術者以外のユーザーは、プッシュ メッセージと通知の違いを理解できないでしょう。このコレクションで「プッシュ通知」とは、メッセージをプッシュしてから通知として表示することを意味します。push メッセージという言葉は、プッシュ テクノロジー自体のことを指します。ここで言う通知とは、それ自体が通知技術のことを指します。
プッシュ通知を使用する理由
- ユーザーにとって、プッシュ通知は、タイムリーで、適切で、正確な情報を受け取る方法です。
- ウェブサイトの所有者にとって、プッシュ通知はユーザー エンゲージメントを高める手段です。
プッシュ通知の仕組み
プッシュ通知を実装する主なステップは次のとおりです。
- プッシュ通知を送信する権限をユーザーに要求するクライアント ロジックを追加し、クライアント識別子情報をサーバーに送信してデータベースに格納する。
- クライアント デバイスにメッセージをプッシュするサーバー ロジックを追加する。
- デバイスにプッシュされたメッセージを受信して通知として表示するクライアント ロジックを追加します。
このページの残りの部分では、これらのステップについて詳しく説明します。
プッシュ通知を送信する権限を取得する
まず、ウェブサイトでプッシュ通知を送信するユーザーの許可を取得する必要があります。これは、Do you want to receive push notifications? プロンプトの横にある [はい] ボタンのクリックなど、ユーザー操作によってトリガーされます。確認したら、Notification.requestPermission() を呼び出します。ユーザーのデバイスのオペレーティング システムまたはブラウザは、ユーザーがプッシュ通知のオプトインを正式に確認するために、なんらかの UI を表示するでしょう。この UI はプラットフォームによって異なります。
クライアントをプッシュ通知に登録する
権限を取得したら、ウェブサイトでプッシュ通知のユーザー登録プロセスを開始する必要があります。この処理は、Push API を使用して JavaScript で行います。定期購入プロセス中に公開認証キーを指定する必要があります。これについては後で詳しく説明します。定期購入プロセスを開始すると、ブラウザはプッシュ サービスと呼ばれるウェブサービスにネットワーク リクエストを行います。これについても後ほど詳しく説明します。
購読が成功したと仮定すると、ブラウザは PushSubscription オブジェクトを返します。このデータは長期間保存する必要があります。通常は、管理しているサーバーに情報を送信し、その情報をサーバーでデータベースに保存します。
push メッセージを送信する
実際にサーバーがプッシュ メッセージをクライアントに直接送信することはありません。これは push サービスが行います。push サービスは、ユーザーのブラウザ ベンダーによって制御されるウェブサービスです。プッシュ通知をクライアントに送信する場合は、プッシュ サービスに対してウェブサービス リクエストを行う必要があります。push サービスに送信するウェブサービス リクエストは、ウェブ push プロトコル リクエストと呼ばれます。ウェブ push プロトコル リクエストには、以下を含める必要があります。
- メッセージに含めるデータ。
- メッセージの送信先のクライアント。
- push サービスがメッセージを配信する方法に関する手順。たとえば、push サービスが 10 分後にメッセージの送信の試行を停止するように指定できます。
通常は、管理しているサーバーを介してウェブ push プロトコル リクエストを行います。もちろん、サーバーで未加工のウェブサービス リクエスト自体を作成する必要はありません。web-push-libs など、この処理を行えるライブラリがあります。ただし 基盤となるメカニズムは HTTP 経由のウェブサービスリクエストです
push サービスはリクエストを受信して認証し、push メッセージを適切なクライアントにルーティングします。クライアントのブラウザがオフラインの場合、push サービスはブラウザがオンラインになるまで push メッセージをキューに入れます。
各ブラウザは、必要なプッシュ サービスを使用します。ウェブサイトの開発者はこれを 制御できませんウェブ push プロトコル リクエストは標準化されているため、これは問題ではありません。つまり、ブラウザのベンダーがどの push サービスを利用しているかを気にする必要はありません。必要なのは、ウェブ push プロトコル リクエストが仕様に準拠していることを確認することだけです。特に、仕様には、リクエストに特定のヘッダーを含める必要があることと、データをバイト ストリームとして送信しなければならないことが規定されています。
ただし、ウェブ push プロトコル リクエストを正しい push サービスに送信していることを確認する必要があります。この情報は、購読手続き中にブラウザから返された PushSubscription データから取得されます。PushSubscription オブジェクトは次のようになります。
{
"endpoint": "https://fcm.googleapis.com/fcm/send/c1KrmpTuRm…",
"expirationTime": null,
"keys": {
"p256dh": "BGyyVt9FFV…",
"auth": "R9sidzkcdf…"
}
}
endpoint のドメインは基本的に push サービスです。endpoint のパスは、push サービスがメッセージを push するクライアントを正確に判断するうえで役立つクライアント識別子情報です。
keys は、次に説明する暗号化に使用されます。
push メッセージを暗号化する
push サービスに送信するデータは暗号化する必要があります。これにより、push サービスはクライアントに送信するデータを表示できなくなります。使用するプッシュ サービスはブラウザ ベンダーが決定します。プッシュ サービスは理論的には安全でない、または安全でない可能性があります。サーバーは、PushSubscription で提供される keys を使用して、ウェブ push プロトコル リクエストを暗号化する必要があります。
ウェブの push プロトコル リクエストに署名する
push サービスには、他のユーザーがユーザーにメッセージを送信できないようにする方法があります。技術的には必要ありませんが、Chrome での最も簡単な実装には必要となります。Firefox では省略可能です。今後、他のブラウザで必要になる可能性があります。
このワークフローには、アプリケーションに固有の秘密鍵と公開鍵が含まれます。認証プロセスの概要は次のとおりです。
- 秘密鍵と公開鍵は 1 回限りのタスクとして生成します。秘密鍵と公開鍵の組み合わせは、アプリケーション サーバー鍵と呼ばれます。また、VAPID 鍵と呼ばれることもあります。VAPID は、この認証プロセスを定義する仕様です。
- クライアントをサブスクライブして JavaScript コードからのプッシュ通知を送信する場合は、公開鍵を指定します。プッシュサービスは、デバイスの
endpointを生成するときに、提供された公開鍵をendpointに関連付けます。 - ウェブ push プロトコル リクエストを送信する場合は、秘密鍵を使用して一部の JSON 情報に署名します。
- push サービスは、ウェブ push プロトコル リクエストを受信すると、保存されている公開鍵を使用して署名付き情報を認証します。署名が有効な場合、push サービスは、一致する秘密鍵を持つサーバーからリクエストが送信されたことを認識します。
push メッセージの配信をカスタマイズする
ウェブ push プロトコル リクエスト仕様では、push サービスがクライアントにプッシュ メッセージを送信する方法をカスタマイズできるパラメータも定義されています。たとえば、以下をカスタマイズできます。
- メッセージの有効期間（TTL）。これは、push サービスがメッセージの配信を試みる時間を定義します。
- メッセージの緊急度。これは、push サービスが優先度の高いメッセージのみを配信することでクライアントのバッテリー駆動時間を延ばす場合に便利です。
- メッセージのトピック。同じトピックの保留中のメッセージを最新のメッセージに置き換えます。
プッシュされたメッセージを受信して通知として表示する
ウェブ push プロトコル リクエストを push サービスに送信すると、push サービスは次のいずれかのイベントが発生するまで、リクエストをキューに入れたままにします。
- クライアントがオンラインになると、プッシュ サービスがプッシュ メッセージを配信します。
- メッセージの有効期限が切れる。
クライアント ブラウザは、push されたメッセージを受信すると、push メッセージのデータを復号し、push イベントをサービス ワーカーにディスパッチします。Service Worker は基本的に、ウェブサイトが開いていないときやブラウザを閉じているときでも、バックグラウンドで実行できる JavaScript コードです。Service Worker の push イベント ハンドラで、ServiceWorkerRegistration.showNotification() を呼び出して、情報を通知として表示します。
次のステップ
- ウェブでのプッシュ通知の概要
- プッシュの仕組み
- ユーザーの登録
- 権限の UX
- ウェブプッシュ ライブラリを使用したメッセージの送信
- ウェブのプッシュ プロトコル
- push イベントの処理
- 通知の表示
- 通知の動作
- 一般的な通知パターン
- プッシュ通知に関するよくある質問
- 一般的な問題とバグの報告