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