だからWebプッシュ通知は普及しねぇ

趣味でWebプッシュ通知を研究している者です。*1

Webプッシュ通知の運用はiPhoneだけ特殊です。

調べれば調べるほど、iPhone特有の制約だけでなく、Webプッシュ通知そのものが実装・運用ともに想像以上に面倒な仕組みだと気づきました。

このままではWebプッシュ通知界隈に未来はありません。

強力なマーケティング武器になり得るWebプッシュ通知が、なぜ普及しないのか？実装と運用をしてみて感じた課題をご紹介します。

Webプッシュ通知とはこういうやつです。

あらかじめ通知を許可してくれた人に、スマホやPCの通知機能を使ってお知らせを届けることができます。

実際にどのように通知を作成し、ユーザーの端末へ配信するのかは、以前投稿したこの記事で紹介しています。

なお本記事は、現在稼働中のWebプッシュ通知を利用したサービスを否定するものではありません。

iPhoneだけ話が違う

ホーム画面への追加が必要

iPhoneではWebプッシュ通知機能に対応したWebページをPWA(Progressive Web Apps)として「ホーム画面に追加」した場合にかぎり、Webプッシュ通知を利用できます。

...あー！まだブラウザバックしないで😭

馴染みのない単語が多いので表にしてみますね。

わたしはさっきの文章でこの状況を伝えたかったんです。

PWAはネイティブアプリのようにApp Storeからインストールするわけではありません。

ブラウザの共有アイコンから「ホーム画面に追加」することで、初めてインストールされます。

このとき「Webアプリとして開く」をOFFにして、ブックマークとしてホーム画面に追加してもWebプッシュ通知は利用できません。

PWAとしてインストールしないと使えないのです🙅‍♀️

そのうえで、ネイティブアプリや他の端末と同様に、OSからの「通知の許可」要求でユーザーに「許可」してもらう必要があります。

他のOSではブラウザさえあればWebプッシュ通知を配信できるのに、ユーザーに特別な操作をお願いしないと、Webプッシュ通知を配信できる環境が整わないんです。

ましてやPWAでさえ知名度がありません。ネイティブアプリのインストール方法と違い、一般に浸透しているとは言い難いのが現状です。

解禁時期が遅すぎた

日本で圧倒的なシェアを誇るiPhoneですが、Webプッシュ通知の解禁時期があまりに遅すぎました。

iPhoneで標準仕様のWebプッシュ通知が使えるようになったのは、iOS 16.4が登場した2023年です。

Chromeは2015年、Firefoxは2016年にWeb Pushへ対応していたため、iPhone対応までには7～8年の時間差がありました。

Appleも2013年から「Safari Push Notifications」というService Worker不要の独自の仕組みを用意していました。*2

しかし、これは現在ChromeやFirefoxでも使われている標準仕様のWeb Push APIとは別物です。

Appleは電力効率やプライバシーへの影響を重視し、標準Web Pushの導入に慎重でした。（それが本当の理由か…？）

その結果、主要ブラウザどうし長期間に渡って実装方式が揃わず、開発者はApple製品向けだけ別の対応を考える必要がありました。

本ブログでも取り上げたことがあるのですが、iPhoneで標準 Web Push APIが使えるようになった頃には、スマホもネイティブアプリもすっかり普及済みです。

もう少し早く、主要OSで同じ仕組みが使えていたら。Webプッシュ通知は今とは違う立ち位置になっていたのかもしれません。

使える条件がわかりづらい

Webプッシュ通知が実際に届くような設定になるまで、かなりの手順を踏まなくてはなりません。

それを案内するUI導線を用意するのも一苦労です。

たとえばiOSからアクセスされた場合、

<①対応ブラウザか？>

→(No)

<②iOSか？>

→(Yes)→ [PWA化を案内]

...という具合に表示するように実装しています。

trogではFirebaseを利用してWebプッシュ通知を配信しているため @firebase/messaging のisSupported()関数を使用して、①の条件にあたる「現在の(ブラウザ)環境で Firebase Messaging が利用可能か？」を判定しています。

②のOS判定は Navigator.userAgent に頼っています。

以下は判定部分だけを抜粋・簡略化したコードです。

import { useEffect, useState } from "react";
import { isSupported } from "firebase/messaging";

const [supported, setSupported] = useState(null);
const [isIOS, setIsIOS] = useState(false);

// ① Firebase Messaging が利用できるブラウザ環境か判定
useEffect(() => {
  (async () => {
    const ok = await isSupported().catch(() => false);
    setSupported(ok);
  })();
}, []);

// ② iOSか判定
useEffect(() => {
  setIsIOS(/iPad|iPhone|iPod/.test(navigator.userAgent));
}, []);

// ①がNo、かつ②がYesならPWA化を案内
{supported === false && isIOS && (
  <p>
    iOS 16.4以降では「ホーム画面に追加」すると
    Webプッシュ通知を利用できます。
  </p>
)}

たとえばiPhoneでブラウザから通知設定ページにアクセスした場合、trogではこのような形で案内しています。（執筆時点）

エンジニア(デザイナー)が考えつくかぎり、親切に案内する導線を用意しないと、多くのユーザーが利用可能なスタートラインにすら立てません。

技術的にもブラウザ側で判定できることは、限界があります。

たとえばホーム画面に追加できていたとしても、PWAとして正しく起動できているかどうかは、直接知る術がありません。

通知できる環境が整っていたとしても、配信タイミングでiPhoneが集中モードになっていれば通知のプレビュー表示は出ません。

そもそも端末側でインストールしたPWAの通知設定がオフになっている可能性もありますからね。

「通知が来ない！」とユーザーから訴えられても不思議ではないケースばかり浮かびます…。

ただ、改善されていることもあります。

以前は通知を一度拒否すると再許可が難しく、PWAを再インストールするしかなかったと記憶していますが、現在はOS側の通知設定と連動するようになっていました。

正直、どの変更で改善されたのかは追い切れていません。iOS、Safari、WebKit、Firebase Messagingなど複数の仕組みが関わるため、どこを見れば仕様変更がわかるのかが非常に追いづらいです。

（皆さんどうしてるんです...？有識者の方がいらっしゃいましたら、ぜひ教えてください🙏）

ユーザーに説明できない

ここまで長々と説明してきた内容を、今度はユーザーに説明する必要があります。

エンジニアの皆さま、操作マニュアルを書きたいですか？

わたしはこのブログ用に、主要OS（Windows、macOS、Android、iPhone）それぞれの通知設定手順を書きました。

操作に詰まった人にもできるだけ理解してもらえるよう、画面の違いや操作手順をかなり丁寧に整理したつもりです。

しかし、閲覧されている気配はほとんどありません😢

…あ、いや、落ち込んでいるとかではなく。わたしだって説明書なんか読みたくないです。

OSやブラウザごとに画面が違えば、説明もスクリーンショットも分ける必要があります。丁寧に書くほどマニュアルは長くなり、読む側のハードルも上がります。

正直、かなり割に合いません。

一般ユーザー向けの機能なら「ここまで説明してまで使ってもらう価値があるか」は、実装前に考えた方がいいと思います。

第一印象が悪すぎる

ユーザーが理解できるような説明を用意できても、もう一つ厄介な問題があります。

Webプッシュ通知機能そのものが、すでに多くのユーザーから警戒されているのです。

Webサイトにアクセスした瞬間、「〇〇が通知の許可を求めています」というアラートが表示された経験はありませんか？

まだそのサイトがどんなものかもわからないのに、訪問直後に通知の許可を求めてくるアレです。

大多数のユーザーにとっては不快な体験です。

Appleも、Webプッシュ通知の許可は、ボタンのクリックやタップなどユーザーの直接的な操作をきっかけに許可ダイアログを表示するよう案内しています。*3

実際iPhone向けのWebプッシュ通知実装では必ず「通知を受け取る」などのボタンをユーザーが操作した後に許可を求める仕組みになっています。*4

（さっきまでAppleに対して散々な批判をしてきましたが、この許可ダイアログに関する快適なユーザー体験を守った判断は称賛に値します👏）

ところが実際には、ページを開いただけで許可ダイアログを表示するWebサイトがやけに目に付きます。

こうした使われ方が続けば、Webプッシュ通知そのものに「うるさい」「怪しい」「とりあえず拒否しておこう」という印象がついてしまっても不思議ではありません。

世界中のWebエンジニアによる雑な実装の積み重ねで、通知許可のダイアログは「とりあえず閉じるもの」になってしまいました。

本来は便利な機能なのに、使われ方のせいで第一印象を悪くしてしまったのは、かなりもったいないです。

エンジニアの自由な発想に任せず、標準 Web Push API自体で、必ず「ユーザーからの操作をトリガーにして許可ダイアログを表示する」という、Appleが求めるような仕組みにしてもよかったのではないか？と考えてしまいます。

動作確認が終わらない

これをサービスとして提供する開発側も大変です。

Webプッシュ通知をサービスとして提供する以上、Windows、macOS、Android、iOSに加え、Chrome、Edge、Firefox、Safariなど、主要な組み合わせで確認する必要があります。

とくにスマートフォンは差が大きく、iPhoneではPWAが必須、AndroidではブラウザとPWAの両方から通知を許可できるなど、挙動が統一されていません。

さらに、通知権限やOS側の設定、バックグラウンド受信などは、結局実機で確認するのが一番確実です。

ちゃんと届くことを確かめるだけでも、確認範囲が広すぎます。

実装できた後の、安定して使い続けてもらうための確認や運用にも、手間のかかる機能だと言えます。

おわりに

Webプッシュ通知機能には、本来アプリをインストールしなくても、Webサイトを開いていないときにお知らせを届けられるという大きなメリットがあります。

ユーザーから見れば、普段使っているアプリの通知とほとんど変わりません。わざわざメールクライアントを開いてもらう必要もなく、必要な情報をすぐ届けられます。

それだけ便利な機能なのに、使い始めるまでにOSやブラウザの違いを説明したうえで、PWAや通知権限についてもユーザーに理解を求めなければならないのは、かなりもったいないです。

セキュリティやプライバシーのために必要な制約があることは承知していますが、大多数のユーザーから見れば不誠実な仕組みと言わざるを得ません。

ユーザーにかかる手間や負担を減らす工夫はできなかったのでしょうか？

サービスとして提供できれば便利な機能なのに、ユーザー側で使える状態にするまでの過程があまりにも面倒です。

その面倒臭さこそが、Webプッシュ通知がなかなか普及しない大きな理由なのではないかと思っています。

1:

2:

3:

4: