要約

  • 端末上の通知表示と、配信サービスで待機するメッセージには、それぞれ別の置換の仕組みがある。見た目が一件でも、業務上の作業まで一件になったとは限らない。
  • Web Push では同じ購読内の Topic が置換対象を結び付ける。本文だけでなく有効期間、緊急度、配信確認の設定も入れ替わり、すでに配信を試みた旧メッセージを呼び戻すことはできない。
  • 中間の通知を省く価値は、最新の状態や必要な履歴を別の場所から回復できるかで変わる。送信件数の減少だけでは、その判断はできない。

通知欄には、担当案件についてのカードが一つだけ残っている。利用者にはすっきりした画面に見える。しかし、その一枚からは、古い通知が端末に届く前に省かれたのか、届いた後に表示だけ差し替えられたのかは分からない。さらに、以前の通知を受けてアプリケーションがすでに何かを処理したかどうかも分からない。

この違いは、実装担当者だけが気にすればよい細部ではない。「通知をまとめる」という同じ要件でも、通信量を減らす設計と、画面の占有を減らす設計とでは、手を加える場所が違う。必要な情報を失わないための条件も違う。

例えば、一つの案件に複数の確認作業が残っている場合、画面には案件全体の要約を一枚だけ出す設計があり得る。その要約から未完了の作業をすべて開けるなら、表示をまとめることには意味がある。ところが、各通知だけが別々の作業を知る手段だったなら、最後の一枚を残すだけでは同じ結果にならない。

これは実際の障害事例ではなく、設計の違いを示す例である。問題は通知を減らすこと自体ではない。何を減らしたのか、減らした後でも利用者が何を知り、何を実行できるのかを説明できるかにある。

画面の整理と配信の整理は別の場所で起きる

WHATWG の Notifications 標準は、表示する通知の置換について、空でない tag の一致と同じオリジンを条件にした処理を定めている。通知プラットフォームが置換を直接サポートするかどうかでも処理は分かれる。対象は端末側の通知であり、業務データの更新や履歴の保存そのものではない。

一方、2016年12月の RFC 8030 が定める Web Push の置換は、配信サービスに残っているメッセージを対象とする。同じ購読に対し、同じ Topic を持つ新しいメッセージが、対応する待機中のメッセージを置き換えられる。新しいメッセージ資源を作成し、該当する古い資源を同時に削除する仕組みだ。

この二つの識別子は、同じものが経路を通じて運ばれているわけではない。RFC は Topic をユーザーエージェントへ転送しないことを要求している。したがって、配信側で Topic を設定しただけで、表示側の tag が自動的にそろうわけではない。

アプリケーションが両者を意図的に対応させることはできる。ただし、その対応は設計上の選択である。配信では案件ごとに最新の状態を残し、表示では複数案件を一つの要約にまとめることも考えられる。逆に、配信された情報をそれぞれ処理したうえで、画面だけを静かに保つ必要があるかもしれない。

重要なのは、見える枚数を処理の回数や保存された事実の数と混同しないことだ。通知欄の整理は注意の配分を変える。待機メッセージの整理は、端末に届く情報の候補を変える。どちらも、過去に完了した動作を取り消す一般的な仕組みではない。

同じ案件でも、省ける内容は同じではない

Topic はメッセージを対応付けるための値であり、その内容に業務上の意味を与えない。配信サービスは同じ値を見分けられればよく、「今回の承認依頼が前回の依頼を無効にするか」まで理解する必要はない。

そのため、同じ案件番号を使うことが常に適切とは限らない。一通ごとに未完了作業の全体像を送るなら、より新しい完全な一覧が古い一覧に代わることはあり得る。一通ごとに新たな作業を追加するなら、後の作業が前の作業を包含するとは限らない。両方とも同じ案件についての通知でも、置換できる範囲は異なる。

内容の型を区別すると判断しやすい。第一は、その時点で必要な状態を丸ごと記述するメッセージ。第二は、受信者が持つ状態に適用する差分。第三は、別の場所にある正本を取得するよう促すメッセージである。

完全な状態なら中間の記述を省ける場合がある。差分は、抜けた変更を無視すると結果が変わる場合がある。取得の合図は、正本が必要な情報を返せるなら、複数の変更を一回の確認にまとめられる。ただし、最後の方式は記憶を不要にしたのではなく、記憶を別の場所に置いている。

その場所が現在の状態しか返さないなら、途中の出来事を理解する必要がある仕事には足りないかもしれない。保存期間が短くなったり、戻ってきた利用者の権限が変わったりすれば、以前は成立していた回復方法が成立しなくなる可能性もある。通知の方式と正本の提供条件は、一緒に評価する必要がある。

あらゆる変更の永久保存を求めているわけではない。現在の状況だけで十分な仕事に、すべての中間状態を保存・配信すれば、通信や注意だけでなく保管と運用の負担も増える。省略の安全性は、履歴の量ではなく、その仕事に必要な情報が残るかによって決まる。

差し替わるのは本文だけではない

RFC 8030 の置換では、古いメッセージに設定された有効期間、緊急度、配信確認の購読も、新しいメッセージのものに置き換わる。新しい文章を古い配送条件のまま届ける単純な編集ではない。

例えば、案件の状況が落ち着けば、新しい通知の緊急度を下げることは合理的だろう。一方、別の送信処理が異なる既定値を使っただけでも、同じ変化は起こり得る。ユーザーエージェントが緊急度で受信対象を絞る場合、これは単なる付加情報ではない。

有効期間にも同じ注意が必要だ。長く待たせるつもりの通知を、短い期間を持つ通知で置き換えれば、残った情報に対する新たな配信機会は早く終わり得る。本文の内容が改善されたことだけでは、その変更が妥当か判断できない。

また、送信者が要求した期間は、無条件の保管保証ではない。サービスは期間を短くすることができ、期限後は新たな配信を試みてはならない。通信中の時間がこの計算ですべて扱われるわけでもない。運用上の事情による早期の失効も想定され、配信確認を求めていた場合には失敗を知らせる扱いが定められている。

期間や緊急度を見れば、いつでも必ず端末を起こせると考えるのは誤りだ。RFC にある電池や接続状態の例は、すべての端末が同じしきい値で動くという実測結果ではない。利用者が戻る場面を支えるには、通知が届かなかった場合に何が残るかまで設計しなければならない。

ここで必要になるのは、送信処理を一つずつ見るだけでなく、同じ Topic を共有する処理の組み合わせを見ることだ。本文の意味も配送条件も異なるまま一つの置換グループを使えば、各処理が単独では正常でも、全体として意図しない情報の残り方をする可能性がある。

すでに動き始めたものは、待機欄から消せない

旧メッセージの配信を試みた後に置換が起きる場面も、RFC は扱っている。古いメッセージへの応答が、置換の後に到着することがある。削除されたメッセージについては、送信者向けの配信確認を抑止することが推奨されている。

したがって、古いメッセージの確認が見当たらないことを、古い内容が受信者に届かなかった証拠として扱えない。待機資源を削除できたことと、経路上の内容をすべて回収できたことは違う。

通知が単なる閲覧のきっかけなら、最新の状態を開くことで十分な場合もある。ところが、通知の処理が何らかの動作を始める設計なら、旧版に基づく動作をどう扱うかが必要になる。取り消し、補償、古い版の拒否といった判断はアプリケーションの仕事であり、配信資源の置換に自動で付くものではない。

「最後」という言葉にも二つの順序がある。業務上は古い更新でも、送信側の遅れによってサービスには後から届くことがある。Topic の一致を調べるだけでは、暗号化された内容の業務版を比較できない。最後に受け付けたメッセージが、業務上も最新だとは限らないという点は、この仕組みから導かれる分析である。

送信側の順序をそろえる、受信側が古い版を識別する、正本から現在の状態を取得する。こうした選択肢の適否は仕事によって異なる。RFC が新たにそれらを一律義務付けているわけではなく、配信の置換だけでは引き受けられない意味付けを、どこに置くかという問題だ。

暗号化と画面表示の間にある解釈

RFC 8291 による Web Push の内容保護は、HTTP ヘッダーを対象に含めない。受信者はヘッダーを push サービスから来たものとして扱う必要がある。TLS による通信路の保護は引き続き必要であり、外部の第三者が内容を自由に読めるという意味ではない。

ここから分かるのは、本文が暗号化されていることと、配送用の値がアプリケーションの意図を端から端まで証明することは別だという点である。業務対象や版を安全に解釈するための情報には、その目的に合った置き場所が要る。

Topic の名前を詳しい業務説明にすれば、運用時には分かりやすくなるかもしれない。その反面、サービスに関連する活動を伝える度合いも変わる。本文の秘匿を、そのまま関連付けのメタデータの秘匿と見なしてはならない。この点も、禁止一辺倒ではなく、必要性と露出の釣り合いを検討する対象になる。

W3C の2025年12月1日付 Push API 作業草案は、通常の service worker による受信経路と、宣言的通知の経路を区別している。また、復号に失敗した場合やイベント処理が繰り返し失敗した場合などでも、配信の応答を返す手順を含む。

その応答は再試行を終えるために意味を持つが、利用者の仕事が完了した証拠にはならない。画面に一枚表示されたことも、業務上の処理が完了したことと同義ではない。配信、解釈、表示、作業は、それぞれ別の結果として捉える必要がある。

この草案は完成した勧告として扱っていない。すべてのブラウザーが記載された経路を実装しているという調査も行っていない。本稿は標準文書に基づく分析であり、特定端末の互換性試験や障害の再現結果ではない。

静かな端末の外で増える仕事も数える

RFC 8030 の第7.4節は、無線利用の効率と、再送、問い合わせ、状態の再同期に伴う費用を合わせて考えている。すぐに古くなる未読件数の例は、中間値をすべて運ぶことが必ずしも有益でないと分かる場面だ。

その一方で、通知を省いたために正本への問い合わせが増えるなら、それも設計の費用である。問い合わせで回復できないものを人が調べ直すなら、別の種類の負担になる。通知を減らさずに注意を奪い続ける負担も、同じ比較から外せない。

ここでは節電率も削減金額も実測していない。重要なのは、送信側の件数だけでは損得が閉じないという構造である。端末が戻った後、何が利用可能になり、何が追加の確認を要するかまで見て初めて、まとめる価値を評価できる。

よい設計では、画面は静かで、必要な仕事は見失われない。すべての通知を見せることも、すべてを最後の一件にすることも、それ自体は目的ではない。省かれた情報がなくても利用者の作業が成立するようにすることが目的だ。