「Googleが発表したChromeのPush APIレート制限（Rate Limits）とは、具体的にどのような仕組みなのか？」
「自社で運用しているWeb Push通知には、どのような影響があるのか？」
Googleは2026年1月6日、サイトエンゲージメントが少ないにもかかわらず多数の通知を送信するサイトに対して、ChromeがPush APIメッセージのレート制限を段階的に導入すると発表しました。
本記事では、Google／Chromiumの公式アナウンス、Chromium内部の設計文書、および Web Push の標準仕様（RFC 8030）に記載された一次情報に基づき、判定の仕組みからエラー処理、運用上の影響まで体系的に解説します。
TL;DR（本記事の要約）
- 導入の目的: 過剰な通知からユーザーを保護し、Web Pushを有用な機能として維持するための仕組み。
- 判定の仕組み: 「サイト滞在時間あたりのPush送信数」「権限プロンプト表示数」「Site Engagement Scoreと滞在時間」を毎日計算。過剰なサイトを「disruptive」と判定（初期方式）。
- レート制限値: 制限値は毎分1,000件を下回らない値（下限値）。超えた場合は HTTP 429 Too Many Requests を返却。
- ペナルティ期間: 判定回数に応じて 1日 → 7日 → 14日 と段階的に延長。42日間連続で非disruptive状態を維持するとリセット。
- 対象範囲: Push API のみ（サイトを開いている間の Notifications API による通知表示は引き続き利用可能）。ほぼすべてのWebサイトは影響を受けないとされています。
本記事の構成（目次）
- 背景と基本方針：なぜ今 Push API にレート制限が導入されるのか？
- 対象APIと動作領域：Push API と Notifications API の役割
- 判定方式の概要と3つのシグナル：disruptive 判定のメカニズム
- 【深掘り】Site Engagement Score の一般仕様：Chromium内部のスコア計算
- 制限値と HTTP 429 仕様：毎分1,000件の意味と RFC 8030 標準
- 制限期間（ペナルティ）のエスカレーション：フラッピング防止と42日リセット
- 主要用語集：Web Push・Chrome仕様の用語整理
- 【実践】Googleが推奨するWeb Pushのベストプラクティス：UX・頻度・権限要求の最適化
- Webサイトへの影響とまとめ：自社サービスでのチェックポイント
第1章：背景と基本方針〜なぜ今 Push API にレート制限が導入されるのか？
近年、ユーザーが十分にサイトを利用していないにもかかわらず、一方的かつ大量のWeb Push通知を送信するサイトが課題となっていました。これにより、ユーザーが通知機能自体を嫌悪し、ブラウザ通知全体をブロックしてしまう懸念が生じています。
Googleは過剰な通知量からユーザーを保護し、通知を有用なコミュニケーション手段として維持することを目的として本仕様を策定しました。
【基本ステータス一覧】
・公式発表日 : 2026年1月6日
・ロールアウト開始 : 2026年1月より段階導入
・目的 : ユーザー保護 / 有用な通知体験の維持 / 不適切な大量配信の抑制
・一次情報出典 : Chrome for Developers (Google公式)
第2章：対象APIと動作領域〜Push API と Notifications API の役割
Webの通知に関連するAPIには主に Push API と Notifications API の2種類が存在しますが、今回のレート制限対象は Push API のみ です。
Push API と Notifications API の関係
Push API と Notifications API を組み合わせることで、Webアプリがブラウザ上で実行されていない状態（サイトを開いていない状態）でもユーザーに通知を届けられます。通常、Push API がサーバーからのメッセージを受信し、Notifications API が通知の表示を担います。
今回のレート制限の対象は Push API であり、サイトを開いている間の Notifications API による通知表示は引き続き利用できます。
APIの役割比較表
| 比較項目 | Push API | Notifications API |
|---|---|---|
| 主な役割 | サーバーからのメッセージ受信 | 画面への通知表示 |
| Service Worker | 現行Chromeでは必須 | 単体表示はメインスレッドでも可 |
| 今回のレート制限 | 制限対象 | 対象外（サイト閲覧時の表示は継続利用可） |
第3章：判定方式の概要と3つのシグナル〜disruptive 判定のメカニズム
Chromeはサイトをレート制限対象（disruptive）とするかどうかを判断するため、当初は毎日以下の3要素を計算すると説明しています。
※ Googleは本方式を「初期方式（Initially）」としており、Webエコシステムの変化に応じて計算方法の詳細は変更される可能性があると説明しています。
毎日計算される3つの判定シグナル（概念モデル）
-
Pushメッセージ送信密度
$$\text{送信密度} = \frac{\text{サイトで送信されたPushメッセージ数}}{\text{ユーザーがサイトで費やした時間}}$$ -
権限プロンプト表示密度
$$\text{プロンプト密度} = \frac{\text{通知権限プロンプトの表示数}}{\text{ユーザーがサイトで費やした時間}}$$ -
ユーザーエンゲージメント水準
- Site Engagement Score
- フォアグラウンド滞在時間
※上記の比率表現は公式発表文言を概念的に整理したイメージです。
通知の送信量や権限要求の頻度が多く、それに対してユーザーのサイト利用（滞在時間等）が極端に少ないサイトが、Chromeによって「disruptive（過剰な通知を行う状態）」と判定されます。
第4章：【深掘り】Site Engagement Score の一般仕様
判定材料として利用される Site Engagement Score について、Chromiumの設計文書（Chromium Design Documents）から確認できる一般仕様を整理します。
スコアの基本プロパティ
-
管理単位: オリジン単位（
https://example.comごとに独立して計算） -
スコア範囲:
0〜100の数値で表現 - 目的: ユーザーがサイトにどれだけアクティブに関与（エンゲージ）しているかを測定
スコアに影響を与えるユーザーシグナル一覧
| シグナル分類 | 具体的な操作・アクション | スコアへの影響 |
|---|---|---|
| アクティブ操作 | ページのスクロール、クリック、キーボード入力 | 加点（エンゲージメント向上） |
| メディア利用 | サイト上での動画・音声コンテンツの再生 | 加点（エンゲージメント向上） |
| アクセス経路 | アドレスバー直打ち、ブックマークからの直接アクセス | 加点（シグナルとして機能） |
| アプリ化 | ホーム画面への追加、PWA（デスクトップアプリ化） | 加点シグナル（grant-based signal等） |
| 時間経過 | サイトを利用しない期間が継続する | 減衰（スコア低下） |
注意点：端末ごとの個別管理
Site Engagement Score は端末（ブラウザインスタンス）ごとにローカル管理されます。デバイス間で同期されないため、同一ユーザーであってもPCとスマートフォンでスコアは個別に計算されます。
※ Chromium設計文書は一般的なスコア計算仕様を示すものであり、Push APIレート制限において各シグナルがどのような重みや閾値で判定に利用されるかの詳細数値はChrome公式記事では非公開となっています。
第5章：制限値と HTTP 429 仕様〜毎分1,000件の意味と RFC 8030
「disruptive」と判定されたサイトには、Pushメッセージの配信能力に制限がかけられます。
制限値の定義：「毎分1,000件」の正しい理解
Chrome公式ドキュメントにおける表現は以下の通りです。
- 制限値: 「毎分 1,000 件を下回らない値」
-
超えた場合の挙動:
HTTP 429 (Too Many Requests)を返却
公式情報では制限値の下限（毎分1,000件を下回らない値）のみが明記されており、具体値の決定方法やサイトごとの差分の詳細は公表されていません。
Web Push標準（RFC 8030）と HTTP 429 レスポンス
Web Push の標準仕様である RFC 8030（Generic Event Delivery Using HTTP Push） では、アプリケーションサーバーからの送信がレート制限に達した場合の動作が規定されています。
RFC 8030 §8.4 によると、リクエスト率を超過した場合、Push サービスは HTTP 429 Too Many Requests を返すことができ（MAY）、次の送信試行までの待機時間を示す Retry-After ヘッダー（秒数、または HTTP-date 形式）を含めることが推奨されています（SHOULD）。
HTTP/1.1 429 Too Many Requests
Date: Wed, 22 Jul 2026 11:20:00 GMT
Retry-After: 60
※ HTTP 429 は Chrome の disruptive 判定以外にも、Push サービス（FCM等）側の送信クォータ超過や一時的な過負荷によって返却される場合があります。429 エラー発生時は単一の原因に特定せず、レスポンスのヘッダーやエラー詳細メッセージを確認することが重要です。再送制御を行う際は、単純な一定間隔の再試行ではなく、**指数バックオフ（Exponential Backoff）とジッター（Jitter）**を適用した実装が推奨されます。
※ 上図の成功応答（HTTP 201 Created）は RFC 8030 規格に基づく Web Push endpoint へ直接送信した場合の仕様です。FCM HTTP v1 API などを経由する場合は成功応答として HTTP 200 が返却されます。
第6章：制限期間（ペナルティ）のエスカレーション〜フラッピング防止ロジック
「disruptive」判定を受けたサイトの制限期間は、判定された回数に応じて伸びる段階的ペナルティ構造をとります。
判定回数と制限期間の推移
【制限期間のエスカレーションフロー】
1日目の判定 : [ 1日間制限 ]
2日目の判定 : [ 7日間制限 ]
3日目の判定 : [ 14日間制限 ]
│
非disruptive状態が 42日連続継続
│
▼
[ 判定カウントがリセット（初期状態へ） ]
詳細テーブル
| 判定ステップ | レート制限の適用期間 | 仕組みの意図 |
|---|---|---|
| 1回目の disruptive 判定後 | 1 日間 | 初回検出時の制限 |
| 2回目の disruptive 判定後 | 7 日間 | 制限の強化 |
| 3回目以降の disruptive 判定後 | 14 日間 | 最大ペナルティの適用 |
| 非disruptive状態が42日間連続 | 判定回数を完全リセット | 正常状態への復帰 |
この期間設定は、サイトが制限の適用と解除を短期間で繰り返す現象（フラッピング）を防ぐために設計されています。
第7章：主要用語集（Web Push・Chrome仕様）
本記事に登場する重要な専門用語および仕様関連用語の一覧です。
| 用語 | 概要・説明 |
|---|---|
| Push API | サーバーからのプッシュメッセージをブラウザがバックグラウンドで受信し、Service Worker等で処理するためのWeb標準API。 |
| Notifications API | 画面上にシステム通知ポップアップを表示するためのWeb標準API。サイトを開いている間の表示は継続利用可能。 |
| Service Worker | ブラウザがバックグラウンドで実行するスクリプト。Push通知の受信ハンドラ（push イベント）などを担う（現行Chromeで必須）。 |
| Site Engagement Score | Chromiumがユーザーの操作（クリック、スクロール、訪問等）に基づきオリジン単位で計算する0〜100のエンゲージメント指標。 |
| disruptive 判定 | 滞在時間に対する通知数や権限要求が過剰であるとChromeに判断されたサイトの状態。 |
| HTTP 429 (Too Many Requests) | クライアントが送信上限を超えた際にPushサービスから返されるHTTPエラーレスポンス（RFC 8030 §8.4）。 |
| Retry-After ヘッダー | HTTP 429 応答時に、次回送信までの待機時間（秒数または HTTP-date）を伝える標準レスポンスヘッダー。 |
| RFC 8030 | IETFで標準化されたHTTP Pushによる汎用イベント配送の仕様。Web Push配信の基盤規格。 |
| フラッピング (Flapping) | 制限の適用と解除が短期間で頻繁に繰り返される現象。これを防ぐために段階的な制限期間（1日/7日/14日）が設けられます。 |
第8章：【実践】Googleが推奨するWeb Pushのベストプラクティス
Google（web.dev / Chrome for Developers）では、通知の価値を高め、適切な頻度と良質なユーザー体験を提供するためのガイドラインが公開されています。
1. 権限プロンプト要求の最適化（Permission UX）
-
ページロード直後のプロンプト要求を避ける
訪問直後のポップアップ要求は拒否率が高くなり、滞在時間あたりのプロンプト頻度を押し上げる要因となります。 -
コンテキストに応じた権限要求（Contextual Prompting）
「発送状態を通知で追跡する」「特定の更新情報を受け取る」など、ユーザーが通知を必要とした特定のアクションの文脈でダイアログを表示します。 -
アプリ内通知設定UIの提供
Webアプリ内に通知の種類や配信頻度を変更・解除できる設定画面を用意することで、ユーザーによるコントロール性を高めます。
2. メッセージコンテンツの質向上（Notification Content）
-
具体的で価値のあるタイトル・本文
単なる「新着通知」ではなく、誰からのメッセージか、どのような更新か具体的に明記します。 -
自ドメイン名の重複記載を回避
ブラウザ側が自動的にドメイン情報を提示するため、タイトル等での手動重複記載は避けます。
3. セグメンテーションとエンゲージメントの向上
-
一律無差別配信の回避
ユーザーの関心や利用履歴に応じた適切なセグメント配信を行い、過剰な通知頻度を抑えます。 -
サイトエンゲージメントの活性化
通知から訪問したユーザーに質の高いコンテンツを提供し、スクロール・クリック・PWA利用などのエンゲージメント（Site Engagement Score）を高める設計を意識します。
第9章：Webサイトへの影響とまとめ
自社サービスへの影響範囲
Googleは公式資料において、**「ほぼすべてのWebサイトはこの変更の影響を受けない」**と明記しています。
影響を受けるのは、ユーザーエンゲージメントにそぐわない価値の低い通知を過剰に送信している一部のサイトに限られます。
まとめ（公式資料から確認できる要点）
- 判定: 毎日「Push送信数」「プロンプト表示数」「Site Engagement Scoreと滞在時間」から総合評価（初期方式）。
-
制限値: 毎分1,000件を下回らない値（下限）。超過時は
HTTP 429を返却。 - 期間: 1日 → 7日 → 14日 とペナルティが拡大。42日間の非disruptive継続でリセット。
- 対象: Push API のみ対象（サイトを開いている間の Notifications API による通知表示は継続利用可能）。
ユーザーに真に価値のある通知を適切な頻度で届けているサービスであれば過度に懸念する必要はありませんが、Web Pushのバックエンド送信処理を実装するエンジニアは HTTP 429（クォータ制限等含む）や Retry-After ヘッダーを意識したエラーハンドリング、および指数バックオフとジッターを組み込んだ再送制御を考慮しておきましょう。