Edgeが旧式の広告ブロッカーを締め出す — Chromeが開けた扉を追って閉じる拡張機能エコシステム

旧式の広告ブロッカーが締め出されるのはセキュリティの前進なのか、それとも広告を売るブラウザ企業が自らの事業を守るための構造調整なのか。そしてこの二つは、本当に互いを排除するのか。

導入 — 二つ目の扉が閉じる

2026年8月、MicrosoftがブラウザEdgeにおいて、Manifest V2(以下MV2)規格で作られた拡張機能をデフォルトで無効化しはじめる、とThe Vergeが報じた。最初の対象はCanary・Dev・Betaといった試験版チャネルであり、続く数か月をかけて正式版(Stable)へと拡大される。報道を総合すると、一般消費者向け端末の移行は2026年末までに完了し、企業が管理する端末は別途のポリシーによって2027年まで猶予される。この措置の事実上の標的は、uBlock Originに代表される旧式の広告・トラッキングブロッカーである。ブラウザが拡張機能の規格を変えることは、一見すると開発者だけの事情のように見えるが、実際に揺らぐのは数億人が日々よりかかっている広告ブロックの土台なのである。

この光景に見覚えがあるのは、同じ扉をすでにChromeが先に閉じたからだ。Googleは2024年からMV2拡張機能の段階的な無効化を始め、2025年に大半を取り除いた。今回のEdgeの発表は、その軌跡をほとんどそのままなぞっている。The Vergeの記事見出しが「Chromeがしたのと同じように(just like Chrome did)」と釘を刺したのもそのためだ。EdgeはChromeと同じChromiumエンジンの上で動くため、Googleが拡張機能プラットフォームをMV2からManifest V3(以下MV3)へ移せば、その上に乗るEdgeも技術的に同じ制約を引き継ぐことになる。

しかし「引き継ぐ」という言い方は、半分だけが真実である。Edgeは企業顧客のためにMV2をより長く有効にしておけるポリシースイッチを残しており、この猶予をいつ取り下げるかはMicrosoftの選択だ。つまり今回の決定には、エンジンから降りてきた不可避性と、広告事業を持つ企業の自発的な判断とが重なっている。本稿はこの二つの層を切り分ける。まず何がいつどう締め出されるのかという事実、次になぜよりによって広告ブロックがその網にかかるのかという構造である。

何がいつ締め出されるのか — 事実の地図

まず規格の世代交代から整理しよう。ブラウザ拡張機能はmanifest.jsonという仕様ファイルで、自らの権限と挙動を宣言する。MV2は長く使われてきた旧世代の規格であり、MV3はGoogleがセキュリティ・性能・プライバシーを名目に推し進めた後続規格だ。今回Edgeが切るのはMV2で書かれた拡張機能であり、MV3で作った拡張機能は引き続き動く。したがって正確に言えば、今回の措置は「広告ブロック禁止」ではなく「旧規格の終了」である。この区別は些細に見えるが、後で見る論争の核心はまさにここにある。

MV2からMV3へ移るにあたって変わる技術的な核心は三つある。第一に、常時常駐していたバックグラウンドページがサービスワーカー(service worker)に置き換えられる。サービスワーカーは必要なときに起きて、アイドル状態では終了する一時的な実行単位であるため、拡張機能がブラウザの背後で状態を保ち続けることが難しくなる。第二に、リモートコード実行(remote code execution)が禁止される。拡張機能が外部サーバーからコードをダウンロードして実行する経路が塞がれ、審査を通ったコードだけが動くようになる。第三に、そして広告ブロックにとって最も決定的なことに、ネットワークリクエストを横取りする方式が根本的に変わる。

まさにこの三つ目が、uBlock Originの心臓を狙い撃つ。MV2ではブロッカーはwebRequest APIを「ブロッキング(blocking)」モードで使い、ブラウザが送ろうとするすべてのリクエストを拡張機能がリアルタイムに覗き込み、判断して止めていた。広告ドメインなのか、トラッキングスクリプトなのか、ページのどの要素を隠すべきなのかを、拡張機能のコードがリクエストごとに直接決めていたのである。MV3はこのモデルをdeclarativeNetRequest(宣言的ネットワークリクエスト、以下DNR)へと変える。拡張機能はもはやリクエストを直接見ることができず、代わりに「このパターンのリクエストは止めよ」といったルールのリストをあらかじめブラウザに渡す。実際のブロックはブラウザが行う。監視者が拡張機能からブラウザへ移るのだ。

ここで数字が登場する。ChromiumのDNRは、拡張機能が登録できるルール数に上限を設けている。文書化された基準では、静的ルールはおよそ30,000個(最大50個のルールセットにわたって)に制限され、動的ルールと正規表現ルールにもそれぞれ別途の上限がかけられている。広告・トラッキングのブロックリストはしばしばこの規模を大きく超えるため、上限そのものがブロック性能の天井になる。uBlock Originの開発者Raymond Hill(オンラインではgorhill)は、このルール数の限界や、動的フィルタリング・要素隠しといった機能の制約ゆえに、MV3向けに別途出したuBlock Origin Liteが元のuBlock Originと同じではない、と長らく指摘してきた。

整理するとこうだ。Edgeで8月から順次オフになるのはMV2拡張機能の全体であり、そのうちユーザーが最も痛切に体感するのがuBlock Originである。代替として挙げられるuBlock Origin LiteはMV3規格なので生き残るが、ルール数の上限と機能の縮小を抱えていく。一方、独自のエンジンを使うFirefoxはMV2式のブロッキングwebRequestを引き続きサポートすると決めており、クラシックなuBlock Originがそのまま動く。実際にMozilla側は今回のEdgeの動きを公然と狙い撃ちし、自社との違いを際立たせた。Chromium陣営が扉を閉じるあいだ、Firefoxは扉を開けたままにしている格好だ。

宣言的ブロックと、広告を売る門番 — なぜこんなことが起きるのか

さて、なぜかを見ていこう。二つの層がある。一つは技術的な正当性、もう一つは事業上の利害だ。

技術側の名分は本物である。MV2のブロッキングwebRequestは拡張機能に莫大な権限を与える。ユーザーが訪れるすべてのページのすべてのリクエストをリアルタイムに読み、書き換えられるということは、悪意ある拡張機能にとっては常時の盗聴・改ざんの通路になるという意味でもある。常時常駐のバックグラウンドとリモートコード実行まで加われば、MV2は性能とセキュリティの両面で攻撃面が広い。HNの議論でも、MV3がMV2の「常時開いたリモートコード実行の経路」を閉じるなど実質的なセキュリティ改善を含んでおり、広告ブロックの弱体化はその副作用にすぎない、という擁護論が出た(HNの議論での一参加者の主張、意訳)。ブラウザ自身がブロックをより効率的に処理できるという主張、Safariがすでに以前からMV3に似たコンテンツブロックのモデルを使ってきたのに、なぜかChromiumだけが非難される、という指摘も同じ文脈から出てきた(HNの議論、意訳)。

興味深いのは、「MV3が本当にブロック性能を落とすのか」ということすら、議論の中で合意がない点である。HNでは、MV3が広告ブロックの効果を測定可能な水準で落とすことはなく、むしろ改善する面もある、という主張が2026年の学術論文(PETS)を根拠に提示され、実際にuBlock Origin Liteで大半の広告がきちんと止まる、というユーザーの証言もいくつもあった(HNの議論、意訳)。反対側では、uBlock Originの開発者本人がLiteは劣ると述べた事実を挙げて、「理論的に劣ること」と「実戦で体感されないこと」は別の問題だ、という反論が交わされた(HNの議論、意訳)。整理すると事実はこうだ —— MV3の上限と機能縮小は文書で確認できる実在の制約であるが、その制約が平均的なユーザーの体感ブロック率をどれほど下げるのかは、いまだに論争中である。この区別を曖昧にした瞬間、議論はたちまち陣営争いになる。

問題は、技術の名分が真であっても利害の衝突が消えない点にある。HNの議論で、誰かが「ブラウザが直接広告をブロックするほうがよい」という主張に対して、「狐に鶏小屋を任せろというようなものだ」と応じた(意訳)。この比喩が急所を突いている。拡張機能プラットフォームの規格を定める企業が同時に世界最大級の広告事業者であるなら、その企業が「広告ブロックはブラウザが自分でやる」と言うとき、我々にはその判断が純粋に技術的だと信じる根拠がない。Googleは売上の圧倒的な比重を広告から得ており、MicrosoftもまたBingとMicrosoft Advertisingを通じて広告事業を育ててきた広告主だ。両社とも、ユーザーが広告をより少なく見ることは事業的に損である。

とはいえ、彼らが露骨に広告ブロックを禁止することはない。その必要がないからだ。規格を変えてブロッカーの性能上限を下げ、最も強力なツールを「旧式」と分類してじわじわと切り、残る措置を「セキュリティ」という反論しにくい名分で包めばよい。これがプラットフォーム権力の作動の仕方である。強制ではなく、デフォルトと規格で結果を誘導する。Edgeの場合が特に鮮明なのは、Chromiumエンジンから降りてきた不可避性の裏に、Microsoft自身の選択が隠れうるからだ。MV2をより長く有効にしておくポリシースイッチを企業向けには残しつつ、消費者向けには取り下げるという決定は、エンジンのせいだけでは説明がつかない。

だからこの案件の本質は「MV3が悪い規格なのか」ではない。セキュリティ改善は実在し、性能論争はいまだ開かれている。本質は、規格を定める者と広告で食う者が同一人であるとき、ユーザーにはその規格が誰の利益に最適化されたのかを検証する手段がない、という構造的な非対称である。ブラウザがコンテンツとユーザーのあいだの門番であるなら、その門番が広告を売る者であるとき、ユーザーの利益と門番の利益は静かにすれ違う。

展望 — ユーザーの選択権はどこへ向かうのか

では、ユーザーの選択権はどこへ向かうのか。現実的な出口はすでにいくつも開いている。

最も単純な道は、エンジンを変えることだ。FirefoxはブロッキングwebRequestを維持すると決めているのでクラシックなuBlock Originがそのまま動き、HNの議論で繰り返し出てきた反応も、「Edgeは結局のところFirefoxをダウンロードするのに最適なブラウザだ」という自嘲まじりのものだった(意訳)。Braveのように、ブロックを拡張機能ではなくブラウザ自体に内蔵したChromium系も存在する。ただしこの場合、ブロックの統制権が再びブラウザベンダーに戻る点は覚えておく価値がある。

二つ目の道は、ブロックの位置をブラウザの外へ移すことだ。Pi-holeやUnboundのようなDNS段階のブロックは、ネットワーク全体にわたってすべての端末・すべてのブラウザに適用される。その代わり限界は明確だ。HNの議論で指摘されたように、広告がコンテンツと同じドメインから提供される場合(例えば一部のYouTube広告)、DNSブロックではコンテンツまで一緒に止めない限りふるい落とせない(意訳)。要素隠しやスクリプトブロックといったページ内部の作業もDNSの領域の外である。だからDNSブロックは、ブラウザ拡張機能を置き換えるというより補完する。

エンジニアの観点で、今回の移行が与える実務的な示唆は二つある。一つ、拡張機能に依存したブロック・プライバシーのツールは、いまやプラットフォーム規格の変更という政治的リスクを定数として抱えることになった。ツールを選ぶとき、それがどのエンジン・どの規格に縛られているかが、機能の一覧と同じくらい重要な選択基準になる。二つ、統制権を自らの手に置きたいユーザーほど、ブロックのレイヤーをブラウザの外(DNS・ルーター・自前のプロキシ)へと分散させていく。プラットフォームが規格で上限を定めるなら、規格の外へ出ることが、唯一その上限を逃れる方法だからである。

悲観シナリオは明確だ。Chromiumが事実上のウェブ標準になった状況で、ChromeとEdgeが並んでMV2を切れば、ウェブ利用者の大多数が性能の制限されたブロックしか使えない世界がデフォルトになる。楽観シナリオは、この出来事がFirefox・DNSブロック・内蔵ブロックのブラウザへの分散を促し、「ブラウザベンダー=ブロック規格の決定者」という単一の統制点を揺るがすことだ。どちらが優勢になるかは、結局のところ平均的なユーザーがuBlock Origin Liteの体感性能に満足するかどうかにかかっている —— そしてその満足の有無こそ、先に見た、いまだ論争中のまさにその問いである。

結論 — 扉は閉じても、裏口はまだ開いている

リードの問いに戻ろう。旧式の広告ブロッカーが締め出されるのはセキュリティの前進か、広告企業の自衛か。答えは「両方であり、だからこそ問題だ」に近い。MV3のセキュリティ改善は捏造された名分ではない。しかし、その規格を定める手と広告で稼ぐ手が同じであるという事実は、名分がどれほど真実であっても消えない。真の争点は規格の是非ではなく、ユーザーがその規格の動機を検証できない構造的な非対称である。

Edgeの今回の決定が特に示唆的なのは、それが純粋なエンジンの相続ではなく、猶予のスイッチを握る企業の選択だった点だ。Chromiumが扉を作ったのだとしても、その扉をいつ閉じるかはMicrosoftが決める。それでもユーザーに残された力は依然として存在する —— エンジンを変え、ブロックをブラウザの外へ移し、どのツールがどの規格に縛られているかを吟味して選ぶことだ。プラットフォームがデフォルトで結果を誘導する時代において、デフォルトに逆らう選択そのものが、ユーザーの握る最後のてこである。

だからあなたに残る問いはこれだ。あなたの広告ブロックはいま誰の規格の上で動いており、その規格を定める企業は、あなたが広告を見ることと見ないことのどちらで稼いでいるのか。この問いに答えられるなら、8月に静かに閉じる扉の前で、どこへ歩くべきかもすでに分かっているはずである。


出典: