アプリに通知を追加する方法:アプリ内通知、メール、プッシュ
Webアプリに通知を追加するには、まずアプリ内通知から始めましょう。通知のテーブルをデータベースに作り、未読の項目を示すベルのアイコンを置きます。ユーザーが離れている間にも知っておくべき情報には、メール送信サービスを使ったメールを追加します。タイムリーなアラートが本当に重要な場合にだけ、Webプッシュを追加してください。Webプッシュには、Service Worker、利用者の許可、そしてiPhoneではホーム画面へのアプリの追加が必要です。どのチャネルを使うにしても、通知はすべてサーバー上の一か所で作成し、受け取る内容は利用者が選べるようにしてください。
このガイドでは、各チャネルを比較し、シンプルな構成を示し、AIアプリビルダーで使えるプロンプトを紹介します。
主な通知チャネルの比較
| チャネル | 利用者に届くタイミング | 設定の手間 | 運用コスト | 向いている用途 |
|---|---|---|---|---|
| アプリ内(ベル、トースト) | 利用者がアプリを使っているとき | 低い | データベース以外に費用はない | 操作履歴、メンション、ステータスの変更 |
| メール | 利用者がメールを確認するとき | 中程度:プロバイダーとドメインの設定 | 送信ごとの料金(プロバイダーによる) | 領収書、ダイジェスト、重要な連絡 |
| Webプッシュ | ブラウザまたはインストール済みのWebアプリに、閉じていても届く | 中〜高 | 送信自体はたいてい無料 | 時間が重要なアラート |
| SMS | ほぼ確実に届く | 中程度。同意に関するルールがある | メッセージごとの料金 | 予約のリマインダー、緊急のアラート |
| チャットツール(Slack、Teams) | 利用者が仕事中のとき | 低〜中 | たいてい無料 | 社内ツールやチーム内のアラート |
ほとんどのアプリは、アプリ内通知とメールがあれば十分です。プッシュやSMSは、予約の確認や注文の準備完了のように、タイミングが本当に重要な場合に検討してください。
通知システムの仕組み
シンプルで、一か所にまとめておくのが基本です。
- 何かが起きる。 コメントが投稿される、支払いが失敗する、予約が明日に迫る、などです。
- サーバーが1つの関数を呼び出す。 例えば
notify(user, type, data)です。 - その関数が利用者の設定を確認し、ベル用の
notificationsテーブルに行を書き込みます。 - その種類について利用者がオンにしている他のチャネルに送信します。 メールはメール送信サービス経由、プッシュはPush API経由です。
- フロントエンドが未読の通知を表示し、開かれたら既読にします。
送信の入口を1つにしておくと、チャネルの追加、文面の変更、利用者設定の反映を、コードベース中を探し回らずに行えます。
保存する内容
通知のテーブルには、通常、利用者ID、種類(例:comment_reply)、短いタイトルと本文、関連ページへのリンク、作成日時、既読日時が必要です。利用者がどの種類でどのチャネルを希望するかは、別の設定テーブルに保存します。
新しい通知の表示
- ページ表示時に読み込み、30〜60秒ごとにポーリングする。 シンプルで確実です。
- WebSocketやServer-Sent Eventsによるリアルタイム更新。 即時性はありますが、動く部品が増えます。即時性が本当に必要でなければ、まずはポーリングから始めてください。
メール通知
メールには送信プロバイダーと認証済みドメインが必要です。詳細はアプリからメールを送る方法にまとめています。通知のためのメールでは、次の点に注意してください。
- 送信はサーバーから行う。 プロバイダーのキーをブラウザに置いてはいけません。
- 頻繁に発生するイベントはまとめる。 「新しいコメントが3件」を1通にまとめる方が、3通送るより優れています。
- 重要度の低い活動には、日次または週次のダイジェストを提供する。
- 必須ではないメールには、配信停止または設定へのリンクを入れる。 マーケティングメールのルールは国によって異なるため、ご自身に適用されるものを確認してください。
Webプッシュ通知
Webプッシュを使うと、サイトからアプリの通知のような表示でアラートを送れます。MDNのPush APIのドキュメントによると、仕組みは次のとおりです。
- サイトがService Worker(ブラウザがバックグラウンドで実行できるスクリプト)を登録します。
- 利用者が同意すると、Service Workerが
PushManager.subscribe()で購読します。ブラウザはエンドポイントと暗号化キーを含むサブスクリプションを返します。 - サーバーがそのサブスクリプションを保存し、何かが起きたら、通常はVAPIDキー(サーバーを識別するキーペア)で署名してエンドポイントにメッセージを送ります。
- ブラウザがService Workerを起動し、ページが開いていなくても通知を表示します。
MDNは、エンドポイントは秘密にすべきだとも述べています。エンドポイントを知っているだけで、その利用者にメッセージを送れてしまうためです。
iPhoneとiPad
WebKitは、iOSおよびiPadOS 16.4からWebアプリ向けのWeb Pushを追加しました。発表では2つの条件が示されています。サイトをホーム画面に追加していること、そして通知の許可は「購読」ボタンのタップなど、利用者の操作に応じて求めることです。そのため、iPhoneではWebアプリをインストールした利用者にしかプッシュは届きません。Webアプリをインストールするとはどういうことかは、ネイティブアプリとプログレッシブWebアプリを参照してください。
許可の求め方
初回訪問時に許可を求めないでください。まず利点を説明し(「授業の1時間前にリマインダーを受け取れます」など)、利用者がボタンをタップしたときにブラウザの確認画面を表示します。利用者が拒否すると、ブラウザが再度の確認を許さない場合があるため、早すぎる確認は、その利用者を永久に失う原因になりかねません。
予約通知には定期的なトリガーが必要
「24時間前のリマインダー」や「毎週月曜日の週次サマリー」には、スケジュールに従って実行される仕組みが必要です。これはバックグラウンドジョブの問題であり、バックグラウンドジョブの実行方法で扱っています。よくあるパターンは、外部のスケジューラーが数分ごとに保護されたエンドポイントを呼び出し、そのエンドポイントが期限の来たものを送信する、という形です。
AIビルダーに与えるプロンプト
まずはアプリ内通知から始めます。
アプリ内通知を追加してください。通知のテーブル(user、type、title、body、link、created_at、read_at)を作成します。すべての機能が呼び出すサーバー関数 notify(userId, type, data) を追加してください。ヘッダーに未読件数付きのベルアイコンを表示し、最新20件のドロップダウンと「すべて既読にする」ボタンを付けてください。新しい通知は60秒ごとにポーリングしてください。
次に設定とメールです。
通知設定を追加してください。種類ごと(コメントへの返信、メンション、請求)に、利用者がアプリ内、メール、両方、なしから選べるようにします。notify() はこの設定を必ず反映してください。メールは [PROVIDER] を使い、シークレット [ENV_NAME] をサーバー側でのみ使って送信してください。コメントのメールはまとめて、1人の利用者に15分あたり最大1通となるようにしてください。
必要であれば、次にプッシュを追加します。
任意のWebプッシュを追加してください。Service Workerを登録し、VAPIDキーを生成して、秘密鍵をシークレットとして保存してください。設定画面に「通知を有効にする」ボタンを追加し、ボタンがクリックされたときだけ許可を求めてください。購読は利用者とデバイスごとに保存し、利用者がオプトインしている場合にのみ notify() からプッシュを送信してください。プッシュサービスが期限切れと報告した購読は削除してください。
よくある間違い
- 通知がコード中に散らばっている。 機能ごとにメールの送り方が違い、設定が無視されてしまいます。
notify()という1つの関数を使いましょう。 - ページの読み込み時にプッシュの許可を求める。 多くの人は拒否しますし、もう一度求める機会はないかもしれません。
- 利用者設定がない。 うるさい通知を止められない利用者は、すべての通知をオフにするか、離脱してしまいます。
- ブラウザから送信する。 メールやプッシュのキーはサーバーに置くものです。
- 期限切れのプッシュ購読を整理しない。 期限切れの購読がたまり、送信が無駄になります。
- 通知の本文に機密情報を入れる。 ロック画面に表示されてしまいます。「新しいメッセージがあります」の方が、メッセージの内容そのものを書くより安全です。
- 送信内容の記録がない。 利用者から「メールが届かない」と言われたとき、プロバイダーのメッセージIDを含むログがあれば原因を突き止められます。
チェックリスト
- すべての場所で使われる、サーバー側の
notify()関数が1つある - 既読状態を持つ通知テーブルと、未読件数付きのベルがある
- 種類ごとのチャネル設定があり、
notify()が反映している - メールはサーバーから送信され、ドメインは認証済み。頻繁なイベントはダイジェストかまとめ送信にしている
- プッシュの許可は、利用者の操作の後に、説明とともに求めている
- デスクトップと、ホーム画面に追加したiPhoneの両方でプッシュをテストした
- 期限切れのプッシュ購読を削除している
- プッシュやメールのプレビューに機密情報が含まれていない
- 予約リマインダーには、信頼できるトリガーがある
Mythexでの通知
Mythexは、構築したアプリ向けの内蔵メール送信やプッシュ送信の機能を提供していません。そのため、ご自身のメール送信プロバイダーを用意し、プッシュ用のキーを自分で生成して、それらをプロジェクトのシークレットとして保存します。アプリ内通知の部分は、プロジェクトのデータベースだけで動きます。データベースは、必要に応じて Mythex が追加します。上記のようなプロンプトで構築し、ベルとメールはプレビューで確認してください。プッシュは公開したURLでテストしてください。Service Workerとプッシュには、実際のHTTPSアドレスが必要だからです。ドキュメントのアプリからメールを送信するレシピには、開始用のプロンプトがあります。Mythexでは定期ジョブについては説明していません。定時のリマインダーは、バックグラウンドジョブの実行方法で説明している外部トリガーで計画してください。
よくある質問
Webアプリに追加するのに最も簡単な通知は何ですか?
アプリ内通知です。データベースに通知のテーブルを作り、未読の通知を表示するベルのアイコンを置くだけで実現できます。外部サービスは不要です。次のステップはメールで、メール送信サービスが必要になります。
WebアプリからiPhoneにプッシュ通知を送れますか?
制限付きで可能です。WebKitは、iOSおよびiPadOS 16.4からホーム画面に追加したWebアプリ向けにWeb Pushを導入しました。そのため、利用者はまずWebアプリをホーム画面に追加する必要があります。また、通知の許可は「購読」ボタンなど、タップの操作に応じて求める必要があります。
Webサイトを閉じていてもプッシュ通知は届きますか?
届きます。Push APIは、メッセージをサイトのService Workerに届けます。メッセージが届くと、ブラウザがService Workerを起動するため、ページを開いておく必要はありません。ただし、事前に利用者から通知の許可を得ている必要があります。
通知で利用者を煩わせないようにするには、どうすればよいですか?
利用者が関心を持つ内容だけを通知し、連続した通知は1つにまとめ、種類ごとにどのチャネルで受け取るかを設定画面で選べるようにしてください。プッシュ通知の許可は、その便利さを理解してもらってから求めてください。