要約

  • Session の取得から購読作成までの間に鍵が変わると、プッシュ確認が拒否されることがある。サーバーは拒否された確認を再試行してはならず、クライアントは応答の sessionState を調べる必要がある。
  • RFC 9749 の任意の最終通知には、定義されていないメソッドを参照しているという技術的な訂正報告がある。確認時の状態は Reported であり、確定済みの規格改訂として扱うことはできない。

運用の引き継ぎで最も見えにくいのは、次の担当者がまだ自分の仕事だと認識していない時間である。送信側は処理を終えたつもりで、受信側は次の連絡を待っている。その連絡がもう来ないと決まっているなら、待機は復旧手順にならない。

RFC 9749 は、JMAP Web Push でこの状況が起こり得る条件を明記している。2025 年 3 月に公開された文書は VAPID 認証を導入し、購読の作成中にアプリケーションサーバーの鍵が変わる競合も扱う。確認要求が鍵の不一致で拒否された場合、サーバーはその PushVerification を再試行してはならない。

ここで取り上げるのは、特定の製品で確認された障害ではない。調査した資料からは、影響を受けた事業者、通知の欠落率、失われたメール数は分からない。それでも、変更作業の受け入れ条件を考える材料にはなる。サーバーが次を送らないとき、古くなった前提を誰が発見するのかが、仕様上はっきりしているからだ。

同じ購読が、二つの時点をまたぐ

クライアントは Session オブジェクトからアプリケーションサーバーの公開鍵を知る。その鍵に結び付いたプッシュの接続先を用意し、JMAP に購読を登録する。Session の読み取りと PushSubscription/set は、一つの不可分な操作ではない。

その間にサーバーが鍵を更新すれば、接続先は旧公開鍵に制限されたまま、確認メッセージには新しい鍵による認証が付く可能性がある。RFC 9749 が説明する 403 は、この時間差による不一致である。単に署名計算をやり直せば直るとは限らない。

この制限には理由がある。RFC 8292 では、制限付き購読への送信には、作成時に指定された公開鍵に対応する秘密鍵の保有を示す必要がある。送信者が「今はこちらの鍵を使っている」と宣言するだけで置き換えられるなら、作成時の制限は意味を失う。公開鍵を替えるには、新しい購読が必要になる。

ただし、403 を見ただけで鍵更新の競合だと断定してはいけない。署名の不正、トークンの対象の誤り、有効期限の問題なども認証拒否につながる。作成時刻、鍵の世代、Session の状態が整合して初めて、この競合を原因として扱える。すべての 403 に対して購読を作り直す対処は、忙しく動きながら別の不具合を放置することにもなる。

鍵の役割も分けて理解する必要がある。VAPID の署名はアプリケーションサーバーの認証に使う。通知内容の暗号化は別の目的を持ち、その鍵交換に使う秘密鍵と署名用秘密鍵は異なるものでなければならない。認証に成功したことは、通知の到達や閲覧を証明しない。

作成の応答だけでは、利用可能になったとは言えない

RFC 8620 の購読手順では、クライアントが指定先に送られた確認コードを正しく返すまで、サーバーは後続の要求を送れない。登録が受理された状態と、確認を終えた通知経路は別物である。

復旧の実装や評価では、どの状態を調べるかが重要になる。PushSubscription/set には ifInState がなく、結果にも oldState と newState はない。通常のデータ集合に対する更新時の競合制御を、そのまま当てはめることはできない。見るべき sessionState は API 応答の外側にあり、Session オブジェクトの状態を示す。

RFC 9749 は、この状態と想定していた applicationServerKey の整合をクライアントに確認させる。不一致を見つけた場合、クライアントは購読作成を再び試みてもよく、先の未完了の購読を破棄してもよい。必要なのは、古い仮定を維持したまま同じ要求を送り続けることではなく、現在の情報から関係を作り直すことである。

一方、サーバーに対する再試行禁止は、この拒否された確認についての規則だ。すべてのプッシュ通知の再送を一律に禁じているわけではない。クライアントが新たに正しい鍵へ結び付ける操作と、サーバーが失敗済みの条件で確認を繰り返す操作を混同すると、運用手順は矛盾した指示になる。

内部の監視で「購読済み」という一語にまとめるのも危うい。作成が受理されたのか、コードが戻ったのか、どの鍵世代で確認が完了したのか。利用者向け画面にすべてを見せる必要はないが、運用側には区別する証拠が必要だ。

通知がないという見え方は、新しい変更がない場合にも、経路が未完成の場合にも生じる。受理件数だけを見て正常とする監視では、この二つを分けられない。

「最後に知らせる」には二重の留保がある

RFC 9749 は、旧購読を旧鍵で扱う移行期間を任意で設けられるとしている。期間が終わった時点、または移行期間を設けない場合は直ちに、旧鍵に結び付いた購読を破棄しなければならない。すべての環境に共通する猶予日数が指定されているわけではない。

元の文書には、特定の旧購読へ最後の StateChange を送る任意の手順もある。それによって PushSubscription/changes を呼び出し、新しい Session 状態に気付かせるという説明だ。しかし、この呼び出し経路はそのまま確実な復旧策として採用できない。

RFC Editor の訂正報告 9055 は、2026 年 7 月 31 日に Neil Jenkins が提出した技術的な指摘である。PushSubscription はアカウントに関連付けられておらず、記述された StateChange の構造に合わないこと、さらに RFC 8620 に PushSubscription/changes が定義されていないことを理由に、該当段落の削除を提案している。

9 月 7 日の確認時点では、状態は Reported のままで、Verified ではなかった。提案をすでに確定した規範文の修正として紹介することはできない。ただし、二つのインターフェース上の指摘は RFC 8620 自体で照合できる。実務上の結論は限定的だが重要である。争点のある呼び出し列を、実証済みの相互運用経路や確実な最終警告として説明しないことだ。

仮に有効な警告経路があっても、眠っている端末への到達は別問題になる。RFC 8030 はメッセージの保持時間を制限し、プッシュサービスによる短縮も認める。保持時間がゼロなら、その時点で利用できない端末を待たない。「最後の一通」という送り手の命名は、受信の保証を生まない。

検証すべきなのは、何も警告を受けずに活動を再開したクライアントが、変更を発見して購読を作り直せるかどうかである。IANA の JMAP 能力登録 は拡張の識別子を記録しているが、導入済みの各クライアントの復旧動作を認定するものではない。

消したはずの情報を、ログで生き延びさせない

復旧の調査には、鍵の世代、作成の受理、確認の完了、廃止といった足跡が役立つ。だからといって、プッシュ URL や暗号化の秘密情報をすべて長期保存する必要はない。

RFC 8620 は、購読を破棄したらこれらを速やかに安全に消去するよう求めている。PushSubscription/get でも、明示的に要求された場合を含め URL と鍵を返してはならない。秘密ではない世代識別子と保存期限を限定した時刻情報で、必要な経過を追えるようにする方が、廃止の意味を保てる。

購読の寿命は、それを作成した API の認証情報にも結び付く。認証情報の失効や取り消しを、単なる通信再試行の問題として扱ってはいけない。クライアントは、自分のものと認識できない deviceClientId の購読も変更すべきではない。

一台を直すために他の端末の購読まで消せば、局所的な成功と引き換えに別の障害を作る。復旧手順の品質には、動くようになったかだけでなく、許された対象だけを扱ったかも含まれる。