はじめに
Webシステムを使っていて、
「新しい情報があったとき、スマートフォンにも通知を出せないのかな？」
と疑問に思ったことをきっかけに、Webの通知について調べました。
最初は、
Chromeの通知設定をONにすればいいのでは？
くらいに考えていました。
しかし調べてみると、ブラウザの通知設定だけでなく、Webシステム側の実装も関係していることが分かりました。
さらに調べていく中で、
- Notifications API
- Push API
- Service Worker
- ポーリング
- WebSocket
など、似ているようで役割の異なる仕組みが登場しました。
この記事では、
「Webシステムからスマートフォンへ通知するには何が必要なのか？」
という疑問から調べた内容を、初心者向けに整理します。
1. まずスマホの通知設定を確認した
最初に確認したのは、AndroidとChromeの設定でした。
Chromeでは、
Chrome
↓
設定
↓
サイトの設定
↓
通知
から、Webサイトごとの通知権限を確認できます。
ここで疑問に思ったのが、
Chromeが通知に対応していれば、Webサイトからも通知できるのでは？
ということでした。
しかし調べてみると、Chromeが通知機能を持っているだけでは不十分でした。
Webシステム側にも通知を利用するための実装が必要です。
2. Chromeが勝手にWebサイトを監視するわけではない
最初は、次のような仕組みをイメージしていました。
Webシステム
↓
Chromeが更新を検知
↓
Android
↓
通知
しかし、ChromeがWebシステムの新着情報を勝手に監視して通知してくれるわけではありません。
Webアプリケーション側にも、
「このWebサイトでは通知を利用する」
ための仕組みが必要です。
Webの通知について調べると、代表的な技術として次の3つが出てきました。
Notifications API
Push API
Service Worker
最初は全部「通知のための技術」に見えましたが、それぞれ役割が異なります。
3. Notifications APIとは？
Notifications APIは、WebサイトからOSの通知領域に通知を表示するための仕組みです。
例えばJavaScriptでは、次のように通知の許可を要求できます。
Notification.requestPermission();
ユーザーが通知を許可したあとであれば、通知を表示できます。
new Notification("新しいメッセージがあります");
イメージとしては、
Webページ
↓
Notifications API
↓
ブラウザ
↓
OSの通知
です。
ここで重要なのは、Notifications APIは主に
「通知を表示する」
ための仕組みだということです。
では、
Webページを開いていないときに、サーバー側で発生した新着情報をどうやって受け取るのか？
という疑問が出てきます。
そこでPush APIやService Workerが関係してきます。
4. Service Workerとは？
通常のWebページで動くJavaScriptは、基本的にはそのページのライフサイクルと結び付いています。
一方、Web Pushでは、Webページを開いていないタイミングでもPushイベントを処理したい場合があります。
そこで利用されるのが Service Worker です。
Service Workerは、Webページとは別にブラウザによって管理され、Pushなどのイベントが発生した際に処理を実行できる仕組みです。
注意したいのは、
Service Workerが常にバックグラウンドで動き続けているわけではない
ということです。
必要なイベントが発生したときに起動し、処理を行います。
ざっくり表すと、
Webページ
↓
Service Workerを登録
↓
ブラウザが管理
↓
Pushなどのイベント
↓
Service Workerが処理
というイメージです。
5. Push APIは何をする？
次に出てくるのが Push API です。
Notifications APIが
「通知を表示する」
ための仕組みだとすると、Push APIは、
WebアプリケーションがPushメッセージを受け取るための仕組み
と考えると整理しやすくなりました。
かなり単純化すると、Web Pushは次のような流れになります。
アプリケーション側
↓
Pushサービス
↓
ブラウザ
↓
Service Worker
↓
通知を表示
役割を整理すると、
Notifications API
↓
通知を「表示する」
Push API
↓
Pushメッセージを「受け取る」
Service Worker
↓
Pushイベントなどを「処理する」
となります。
最初はこの3つを同じ「通知機能」だと思っていましたが、役割を分けて考えると理解しやすくなりました。
6. ブラウザの通知設定だけでは解決できない理由
ここまで調べると、
Chromeの通知設定をONにすれば通知できるのでは？
という最初の疑問にも答えが出てきます。
ブラウザが通知機能を持っていても、Webアプリケーション側に通知を利用する仕組みがなければ、それだけで新着情報を通知することはできません。
つまり、
通知が来ない
↓
OSの通知設定は？
↓
ブラウザの通知設定は？
↓
Webアプリケーション側は通知に対応している？
と、複数のレイヤーを確認する必要があります。
「ブラウザに通知機能があること」と、
「そのWebアプリケーションが通知機能を利用していること」
は別の話でした。
7. Push通知以外の方法はないのか？
さらに調べていくと、
新着情報をユーザーに知らせる方法はWeb Pushだけではない
ことも分かりました。
例えば、
- ポーリング
- WebSocket
- Server-Sent Events（SSE）
- Web Push
- メール通知
などがあります。
ただし、これらは目的や仕組みが異なります。
8. ポーリングとは？
ポーリングは、クライアント側からサーバーへ定期的に問い合わせる方法です。
例えば、
ブラウザ
↓
「新着ある？」
↓
サーバー
しばらく待つ
ブラウザ
↓
「新着ある？」
↓
サーバー
という処理を繰り返します。
例えば1分ごとに問い合わせれば、
12:00 → 新着ある？
12:01 → 新着ある？
12:02 → 新着ある？
12:03 → 新着ある？
という動きになります。
仕組みは比較的分かりやすいですが、問い合わせるたびに通信が発生します。
また、問い合わせ間隔によっては、新着が発生してから検知するまでに時間差が生じます。
9. WebSocketとは？
WebSocketは、クライアントとサーバーの間で接続を維持し、双方向に通信できる仕組みです。
通常のHTTP通信では、
クライアント
↓ リクエスト
サーバー
↓ レスポンス
クライアント
という形が基本です。
一方、WebSocketでは一度接続を確立すると、
クライアント
↕
↕
サーバー
のように双方向でデータをやり取りできます。
そのため、
- チャット
- オンラインゲーム
- リアルタイム更新
などで利用されます。
ただし、
WebSocketでリアルタイム通信することと、Webページを閉じている状態でOSのPush通知を受け取ることは別問題
です。
ここも最初は混同しやすいポイントでした。
10. Web Push・WebSocket・ポーリングの違い
大まかに整理すると、次のようになります。
| 技術 | 主な目的 |
|---|---|
| Notifications API | OSの通知領域に通知を表示する |
| Push API | Pushメッセージを受け取る |
| Service Worker | Pushなどのイベントを処理する |
| WebSocket | 接続を維持して双方向通信する |
| ポーリング | 一定間隔でサーバーへ問い合わせる |
| メール通知 | メール経由でユーザーに知らせる |
例えば、
「画面を開いている間、リアルタイムに更新したい」
という要件と、
「Webページを閉じていてもユーザーに知らせたい」
という要件では、必要になる技術が違います。
単純に「通知を実装したい」ではなく、
いつ、どの状態のユーザーに、どの程度リアルタイムに情報を届けたいのか？
を考える必要があることが分かりました。
11. 調べて理解できたこと
今回の調査は、
スマホに通知を出したい
という単純な疑問から始まりました。
しかし調べていくと、
スマホに通知したい
↓
ブラウザの通知設定を確認
↓
Webアプリ側にも仕組みが必要
↓
Notifications APIとは？
↓
Push APIとは？
↓
Service Workerとは？
↓
Push以外の方法は？
↓
ポーリング / WebSocket / メールなど
と、Webアプリケーションの通信方法についての学習につながりました。
特に理解が変わったのは、
ブラウザに機能が存在することと、Webアプリケーションがその機能を利用していることは別
という点です。
まとめ
Webシステムからユーザーへ情報を届ける方法には、さまざまな選択肢があります。
Notifications API
Push API
Service Worker
WebSocket
ポーリング
メール
これらはすべて「通知やリアルタイム処理に関係する技術」ではありますが、役割はそれぞれ異なります。
今回調べたことで、
Webアプリケーション
↓
ブラウザ
↓
OS
↓
ユーザー
という複数のレイヤーを意識するようになりました。
「通知が来ない」という現象一つでも、クライアント側だけを見るのではなく、
どのレイヤーがどの役割を担当しているのか
を分けて考えることが大切だと分かりました。
また、Web Pushが利用できない場合でも、ポーリングなど別の方法で目的を実現できる可能性があります。
次は、実際にChrome拡張機能から定期的に状態を確認し、変化があった場合に通知する仕組みについて整理してみたいと思います。