Manifest V3強制移行：Edgeが突きつけるブラウザ拡張機能の終焉とエンジニアの覚悟

深夜のデバッグ作業中、ブラウザの挙動が不可解な挙動を示した際、我々エンジニアがまず疑うのは拡張機能の干渉だ。特にuBlock Originのような強力な広告ブロッカーは、Web開発者にとって「通信の可視化」と「不要なノイズの排除」を両立させるための必須ツールであった。しかし、Microsoftが2026年8月から開始するMicrosoft EdgeにおけるManifest V2（MV2）の段階的な無効化は、この開発環境の前提を根底から覆すものだ。Google Chromeが先行して2025年7月にMV2を完全に葬り去った今、Chromiumベースのブラウザにおける「旧来の自由」は、ついに終焉の時を迎えたと言える。

技術的な核心は、Web Request APIからDeclarative Net Request（DNR）APIへの強制的な移行にある。MV2時代、Web Request APIはリクエストをリアルタイムで傍受し、動的にブロック・改変することを可能にしていた。これは強力な反面、ブラウザのパフォーマンスやセキュリティ上の懸念材料でもあった。対してMV3で導入されたDNR APIは、拡張機能が事前にルールセットをブラウザ側に登録し、ブラウザがそれを解釈して処理を行う仕組みだ。一見すると効率的でセキュアな設計に見えるが、これは「拡張機能が持つ柔軟なフィルタリング能力」を、ブラウザベンダーが定義した「枠組み」の中に閉じ込めることを意味する。我々エンジニアが直面するのは、これまでのように複雑な正規表現や動的なスクリプトで広告を叩き落とすという「力技」が、APIの制約によって封じられるという現実だ。

Microsoftの発表によれば、Edgeアドオンストアにおける主要なMV2拡張機能の95％はすでにMV3へ移行済みであり、残るMV2拡張機能はわずか58種類、そのうちMV3版が存在しないものは3種類のみという。この数字は、エコシステムの移行が「完了間近」であることを示唆しているが、裏を返せば「残された選択肢の消滅」を意味する。企業環境においては2027年初頭まで猶予があるとはいえ、開発現場の標準ブラウザが強制的にMV3へ移行される以上、我々は「広告ブロッカーが効かない環境」を前提としたWeb開発、あるいは「DNR APIの制約下でいかに効率的なフィルタリングを実現するか」という新たな技術的課題に向き合わざるを得ない。

「広告ブロッカーが廃止されるわけではない」というMicrosoftの弁明は、技術的には正しいが、ユーザー体験の観点からは半分しか真実を語っていない。uBlock Origin LiteのようなMV3対応版は確かに存在するが、それはMV2版が持っていた「高度なフィルタリング機能」を完全に代替できるものではない。MV3の制約下では、拡張機能が外部からリモートホストコードを読み込むことも原則禁止される。これは、セキュリティ向上という大義名分がある一方で、拡張機能のアップデート頻度や柔軟性を著しく低下させる要因となる。我々エンジニアがこれまで享受してきた、ブラウザを「自分の思い通りに制御する」という特権は、今やベンダーの審査とAPIの仕様という名の「壁」に阻まれている。

以下の表は、MV2とMV3の主要な技術的差異を整理したものである。この構造的な変化を理解することは、今後のブラウザ拡張機能開発において避けて通れない。

この移行は、単なるAPIのアップデートではない。ブラウザというプラットフォームが、オープンな実験場から、ベンダーが完全にコントロールする「管理されたアプリケーション」へと変貌を遂げたことを象徴している。我々エンジニアは、この変化に対してどう立ち回るべきか。まず、既存のMV2拡張機能に依存したワークフローを早急に見直す必要がある。uBlock Origin Liteへの移行検証はもちろんのこと、必要であればFirefoxのような、依然としてMV2的な柔軟性を維持するブラウザへの移行も視野に入れるべきだ。また、ブラウザ拡張機能に頼り切った開発環境そのものを見直し、プロキシサーバーやDNSレベルでのフィルタリング（Pi-holeなど）といった、ブラウザ外での制御手法を強化することが、より堅牢な開発環境を構築するための実践的な処方箋となるだろう。

今回のMV3強制移行は、Webの未来に対する一つの強烈な問いを突きつけている。それは、「ブラウザの主権は誰にあるのか」という問いだ。かつてWebは、ユーザーが自身の環境を自由にカスタマイズできるオープンな空間であった。しかし、現在のブラウザ市場はChromiumという巨大な重力圏に支配されており、GoogleやMicrosoftといった少数のテックジャイアントが、APIの仕様一つでWebのあり方を決定できる状況にある。NECが「部長も部下もすべてAI」という組織改革を断行するような時代において、我々エンジニアが使うツールさえも、AIやベンダーのアルゴリズムによって「最適化」という名の下に管理されるのは必然の流れなのかもしれない。

しかし、忘れてはならないのは、技術の進化が常に「自由の制限」と引き換えに行われてきたという歴史だ。MV3は確かにセキュリティとパフォーマンスを向上させるが、それは同時に、ユーザーがWebサイトの通信を詳細に制御する権利を奪うことにも繋がっている。我々エンジニアは、この「利便性と引き換えに失われる透明性」に対して、どのような対抗策を講じるべきだろうか。単に新しいAPIに適応するだけで満足するのか、それとも、ブラウザというブラックボックスに依存しない、よりオープンで分散的なWebのあり方を模索し続けるのか。

明日から我々が取るべき行動は明確だ。まずは、現在利用している拡張機能がMV3でどのような制限を受けるのかを詳細に調査し、代替手段を確保すること。そして、ブラウザベンダーの意向に左右されない、自分自身の開発環境の「ポータビリティ」を確保することだ。技術コミュニティに身を置く者として、我々は「ベンダーが提供する便利な箱」の中で踊るだけの存在であってはならない。ブラウザの仕様変更という小さな波紋を、Webの未来を再定義するための大きな議論へと昇華させることができるか。その問いに対する答えは、我々エンジニア一人ひとりの日々の選択に委ねられている。