Webの「通知を許可」とは？届く条件と、受け取り方の決め方

許可するのは、サイトが通知を表示すること

Web通知は、ページの本文とは別に、端末の通知領域などへ情報を表示する仕組みです。サイトからの通知を認めるかどうかは、ブラウザーが利用者へ確認します。

MDNのNotifications APIの説明では、通知の許可状態を未決定・許可・拒否の三つに分けています。未決定は許可済みではなく、その状態では通知を表示できません。

利用者が許可したことは、そのサービス内でどんな種類の知らせを選んだかとは別の情報です。「予約の変更だけ受け取りたい」という希望を扱うには、サービス側にも通知内容を選べる仕組みが必要になります。

プッシュ通知は、知らせを届ける経路も含む

通知の表示と、サーバーから知らせを受け取る処理は役割が違います。ページが開いていない場面も含めてサーバーからメッセージを受け取る仕組みの一つが、Push APIです。

MDNのPush APIの解説では、Service Workerを通じてプッシュメッセージを受け取る構成が説明されています。Service Workerは、ページとは別の実行環境でイベントを処理する仕組みです。

ただし、この説明から、どの端末・ブラウザーでも同じ条件で動くとは判断できません。対応状況、OSの通知設定、サービス側の配信処理を含めて、使う環境で確かめる必要があります。

許可があることと、利用者が通知を読んだことは別です。 通知が唯一の確認経路になっていると、表示されなかった場合や見落とした場合に情報を追えなくなります。

何が届くか分かる場面で、受け取り方を選ぶ

通知の意味が分からないうちに許可を求められると、利用者は判断材料を持てません。たとえば予約を登録したあとに、「変更があったら知らせる」という用途を示すと、受け取る理由が伝わります。これは本記事で提案する画面構成の例です。

MDNも、通知の許可要求はボタンのクリックなど、利用者の操作に応じて行うよう案内しています。サイトを開いただけで繰り返し要求する構成は避けたいところです。

通知には、受け取る内容だけでなく、あとから停止する方法も必要です。サービス内の通知設定とブラウザーの許可は別の場所にあるため、問い合わせ対応では、どちらを変更したのかを分けると話が通じやすくなります。

届かないときは、順番に切り分ける

通知が表示されない原因は一つではありません。利用者向けの案内なら、次のような順序で確認すると、同じ操作を繰り返さずに済みます。

運営者は、送信の受付や配信の結果を、既読や対応済みと同じ状態にしないことも重要です。必要な情報はアプリ内にも残し、通知から開いた先で内容を確認できると、利用者が次の行動を選べます。

まとめ

Web通知は、表示の許可、メッセージを届ける経路、サービス側の設定を組み合わせて動きます。用途が分かる場面で受け取り方を選べることと、通知を見逃しても内容へ戻れることが、使いやすさにつながります。

Webアプリの端末側の動作は、PWAで考える保存と送信の違いでも説明しています。