Manifest V3でuBlock Originが消えた本当の理由 — webRequestとdeclarativeNetRequestの決定的な差

はじめに

「Firefox が uBlock Origin をサポートする最後の主要ブラウザになった」という記事が Hacker News で 1574 ポイントを集めた。Microsoft Edge が Manifest V2 の終了時期を告知し、Chromium 系ブラウザから本家 uBlock Origin が事実上消えることが確定したためだ。

ただし、この話を「広告ブロッカーが使えなくなる」という消費者向けニュースとして読むと本質を取り逃す。実際に起きているのは、ブラウザ拡張がネットワークリクエストに介入するための API そのものの設計変更 であり、影響範囲は広告ブロックにとどまらない。本記事では、Chrome 公式のタイムラインと declarativeNetRequest の仕様上の上限値を確認しながら、「なぜ静的ルールでは代替できないのか」「Firefox の立場は何が違うのか」を整理する。

何が起きたのか — 3ブラウザの現在地

Google の公式タイムラインによれば、Chrome の Manifest V2 廃止はすでに完了フェーズに入っている。

2022年1月: Chrome Web Store が新規の公開 MV2 拡張の受付を停止
2024年10月9日: Chrome Stable で MV2 拡張の無効化を段階的に開始（ユーザーによる再有効化は可能）
2025年3月31日: 全チャンネルで既定無効化
2025年7月24日（Chrome 138）: 再有効化の手段ごと廃止。企業向けポリシー ExtensionManifestV2Availability による猶予も Chrome 139 で終了
2026年8月31日: 残存する MV2 拡張が Chrome Web Store から完全に削除

つまり Chrome ではすでに1年以上前に決着がついており、今回のニュースは Chromium 陣営の最後のピースが埋まったという話だ。Microsoft は Edge の MV2 について、一般利用者向けを 2026年末、企業環境向けを 2027年初頭にかけて段階的に無効化すると告知している。Edge Add-ons ストアの上位 MV2 拡張のうち 95% はすでに MV3 へ移行済みだという説明も添えられている。

一方 Mozilla は 2026年8月10日、「uBlock Origin へのサポートはどこにも行かない」と改めて表明した。これは 2025年2月の公式ブログの方針を再確認したものだ。

なお、報道の見出しにある「最後の主要ブラウザ」は厳密ではない。Brave は Chromium ベースでありながら MV2 拡張を自社サーバーでホストし、uBlock Origin・AdGuard AdBlocker・NoScript・uMatrix の4つを名指しでサポート対象としている（Settings > Extensions > Manifest v2 extensions で有効化）。ただしこれは上流 Chromium から MV2 のコードが除去されていく中で、フォーク側がパッチを当て続ける構図であり、Firefox のように「自前のエンジンで API を維持する」のとは持続性の前提が異なる。

技術的な核心 — webRequest と declarativeNetRequest の非対称性

MV2 の webRequest API は、リクエストが飛ぶ直前に拡張のコードへ制御を渡す ブロッキング型のフック だった。拡張は URL・ヘッダ・コンテキストを見て、その場で JavaScript のロジックとして「通す / 落とす / 書き換える」を決められる。

MV3 の declarativeNetRequest（DNR）はこれを反転させる。拡張は「こういう条件のリクエストをこう扱え」という 宣言的ルールを事前に登録する だけで、マッチングと実行はブラウザ側が行う。拡張のコードはリクエストの中身を見ない。Google はこれをプライバシー上の利点として説明している。実際、拡張が全リクエストを覗ける状態は攻撃面でもあり、その主張には根拠がある。

問題は、宣言的モデルには数の上限が必要になることだ。Chrome の公式リファレンスに記載されている主な定数は以下の通り。

定数	値
`GUARANTEED_MINIMUM_STATIC_RULES`	30,000
`MAX_NUMBER_OF_STATIC_RULESETS`	100
`MAX_NUMBER_OF_ENABLED_STATIC_RULESETS`	50
`MAX_NUMBER_OF_DYNAMIC_RULES`	30,000（safe ルール）
`MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES`	5,000
`MAX_NUMBER_OF_SESSION_RULES`	5,000
`MAX_NUMBER_OF_REGEX_RULES`	1,000（各正規表現はコンパイル後 2KB 未満）

数の上限そのものより効いてくるのが、ルールの表現力と更新のタイミングだ。DNR には他にも制約がある。任意のヘッダを追加できるわけではなく append は許可リスト方式に限られ、Service Worker の onfetch ハンドラや CacheStorage から返るレスポンスには介入できない。

そして最大の非対称性はここにある。広告配信側が回避手段を変えたとき、webRequest ベースの拡張はフィルタリストの更新だけで即座に追随できる。DNR では静的ルールセットの変更が拡張本体の更新を伴い、ストア審査を経る。防御側だけが審査のレイテンシを背負う構造になる。アンチアドブロック・スクリプトへの対抗のように、ページ上のコードを書き換える必要がある領域は、そもそも宣言的ルールの表現範囲の外にある。

MV3 対応版として提供されている uBlock Origin Lite は、この制約を正面から受け入れた設計だ。ブラウザ内蔵の DNR エンジンとバンドル済みルールセットで動作し、動的フィルタリングとカスタムフィルタリストは持たない。ステートレスであり、汎用コスメティックフィルタはサイトごとに Complete モードへ引き上げるまで有効にならない。「軽量版」というより、別の設計思想で作り直された別物と捉えるのが正確だ。

Firefox は「MV3 を拒否した」わけではない

ここは誤解されやすい。Firefox も Manifest V3 に対応している。Mozilla が選んだのは、MV3 を採用しつつ blocking webRequest を残す という道だ。2025年2月の公式ブログには次の一文がある。

Firefox, however, will continue supporting both blockingWebRequest and declarativeNetRequest — giving developers more flexibility

Mozilla は互換性のために DNR も実装している。つまり Firefox の MV3 は「DNR で書ける拡張は DNR で、足りないものは webRequest で」という二本立てだ。

Firefox の MV3 が Chromium と異なる点は他にもある。バックグラウンドスクリプトは Service Worker ではなく Event Page（非永続バックグラウンドページ）を採用しており、この点は Safari と同じ方向を向いている。ホストパーミッションの扱いも Firefox 127 以降で変更され、host_permissions と content_scripts に列挙されたホストがインストール時のプロンプトに表示され、インストール時に付与されるようになった。

「MV3 = Chrome の MV3」ではない、というのが拡張機能開発者にとって実務上の要点になる。

エンジニアへの影響

1. 拡張機能を開発しているなら、対象ブラウザごとに設計が分岐する。 リクエストの内容に応じた動的な判断がプロダクトの中核にある場合、Chromium 系では DNR の表現範囲に収まるかを先に検証する必要がある。収まらないなら、機能を削るか、ブラウザ拡張以外のレイヤー（プロキシ、DNS、OS レベル）へ移すかの判断になる。「MV2 を MV3 に書き換える」ではなく「MV3 で成立する製品か」を問う作業だ。

2. 影響は広告ブロックだけではない。 社内のセキュリティ拡張、リクエストを記録する開発ツール、ヘッダを注入する検証用拡張、企業プロキシ連携など、webRequest のブロッキング挙動に依存していたものはすべて同じ制約を受ける。Edge の企業向け猶予が 2027年初頭まで確保されているのは、この層の移行に時間がかかるという認識の裏返しでもある。

3. 検証環境としてのブラウザ選択が変わる。 ネットワーク挙動の観察を拡張に頼っていたワークフローは、DevTools・ローカルプロキシ（mitmproxy 等）・Firefox の併用へ寄せることになる。開発機のブラウザ構成を見直す価値がある。

4. Brave の MV2 サポートは、上流依存のリスクを織り込んで評価する。 現時点で動作することと、Chromium から MV2 の実装が削られた後も同じコストで維持されることは別の話だ。恒久的な前提には置きにくい。

まとめ

Chrome の MV2 廃止は 2025年7月（Chrome 138）に実質完了し、2026年8月31日に Web Store から完全削除される
Edge は一般向けを 2026年末、企業向けを 2027年初頭にかけて無効化する
争点は広告ブロックではなく、webRequest（動的・命令的）から declarativeNetRequest（静的・宣言的）への API 設計変更にある
DNR にはルール数・正規表現・ヘッダ操作の明示的な上限があり、更新にストア審査が挟まる点が防御側に不利に働く
Firefox は MV3 に対応した上で blocking webRequest を維持しており、「MV3 に非対応」ではない

ブラウザ拡張は「ブラウザの実装に相乗りする機能」であり、その API 設計はプラットフォーム側の判断で変わる。今回の一件は、拡張という形態に事業や業務フローを載せる際のリスクを可視化した事例として残る。移行先を考えるなら、拡張レイヤーの外側にも選択肢を持っておくことが実務的な備えになる。

今日のその他のニュース

Codex に自律研究ループを回させて GPU カーネルを232倍高速化 — 「仮説を立てて実装し、ベンチを取り、結果から次の仮説を立てる」ループをエージェントに回させた実践記録。人間が思いつく最適化案が枯渇した後もエージェントが探索を継続した点が要点で、評価関数を自動で回せる領域におけるエージェント運用の有力なパターンを示している。（Hacker News, 296pt）

Anthropic が Claude 出力のテキストウォーターマークを公式解説 — 生成テキストに統計的な電子透かしを埋め込む仕組みの解説。AI 生成コンテンツの検出可能性が上がる一方、透かしを意識した加工に関する議論も出ている。（Anthropic）

概念設計が、その後のコードの命運を左右する — ドメイン概念の切り出し方がコード全体の保守性を規定するという設計論。はてなブックマーク 318users。AI 生成コードの比重が上がるほど「何を作るか」の定義精度が効いてくるという文脈でも読める。（Zenn）