【ITニュース解説】ModHeader in Selenium stopped working. Here's what sets HTTP headers in tests in 2026

最近、Webアプリケーションのテストを自動化する際に、HTTPヘッダーという重要な情報を設定するツール「ModHeader」が動作しなくなり、多くのシステムエンジニアが困っている状況が起きている。これは、Webテストのパイプラインに大きな影響を与えているため、初心者にも理解できるよう、何が問題で、どのような解決策があるのかを説明する。

まず、HTTPヘッダーとは、Webブラウザとサーバーが通信する際に、やり取りする情報の種類や内容を伝えるための付箋のようなものだ。たとえば、「このユーザーはログイン済みだ」という情報や、「テスト用のステージング環境に接続したい」といった指示をサーバーに伝えるために使われる。テスト自動化では、このようなヘッダーを意図的に設定して、特定のシナリオをシミュレーションすることがよくある。

ModHeaderは、Google Chromeの拡張機能として、このHTTPヘッダーを簡単に設定できるツールだった。Seleniumなどのテスト自動化フレームワークから、ModHeaderの機能を呼び出してテストを実行するパイプラインが多く存在した。しかし、現在その多くが機能しなくなっている。

ModHeaderが動作しなくなった理由は主に二つある。一つは、ModHeaderが「Manifest V2」という古いバージョンのChrome拡張機能のルールに基づいて作られていたためだ。Google Chromeは、セキュリティやパフォーマンスの向上を目的として、新しいルールである「Manifest V3」への移行を積極的に進めている。その結果、Manifest V2形式の拡張機能は、Chromeブラウザから順次無効化されている。ModHeader 4.3.2はManifest V2のままで、更新もされていないため、新しいChromeでは読み込まれなくなってしまったのだ。

もう一つの理由は、Google Chrome 137以降のバージョンで、「--load-extension」というコマンドライン引数が無視されるようになったことだ。これは、Seleniumなどのテストツールが、ブラウザ起動時にModHeaderのような拡張機能を読み込むために使っていた設定だ。この引数が無視されるようになったことで、ModHeaderのような拡張機能は、テスト中に読み込まれることができなくなった。ただし、テストのために特別に提供されている「Chrome for Testing」や、オープンソース版の「Chromium」では、この引数はまだ有効である。

ModHeaderは機能しなくなったにもかかわらず、毎月約15万回もダウンロードされており、多くのCI（継続的インテグレーション）パイプラインで、実際には何も機能しないものがインストールされ続けている状況だ。

では、ModHeaderの代わりに、どのようにHTTPヘッダーを設定すれば良いのだろうか。状況に応じた複数の代替手段がある。

最もシンプルなケースとして、すべてのWebリクエストに同じHTTPヘッダーを追加したい場合は、拡張機能なしで対応できる。 例えば、Playwrightというテストフレームワークには、この機能が組み込まれている。browser.newContext({ extraHTTPHeaders: { 'X-Env': 'staging' } })のように記述するだけで、そのテストコンテキスト内で行われるすべてのリクエストに「X-Env: staging」というヘッダーを追加できる。 Selenium 4とChromeを組み合わせる場合も、Chrome DevToolsプロトコルという、ブラウザの内部機能を操作する仕組みを使って、同様の設定が可能だ。driver.execute_cdp_cmd('Network.enable', {})でネットワーク機能を有効にし、driver.execute_cdp_cmd('Network.setExtraHTTPHeaders', {'headers': {'X-Env': 'staging'}})というコマンドを実行することで、すべてのリクエストにヘッダーを追加できる。 これらの方法は、「テストユーザーとしてログインする」や「ステージング環境にルーティングする」といった多くのシナリオで役立つ。しかし、これらの方法では、サーバーからの応答ヘッダーを変更したり、ブラウザが標準で送信するヘッダーを削除したり、特定のURLに限定してヘッダーを設定したりすることはできない。

より高度な制御が必要な場合、例えばCORS（異なるドメイン間の通信許可）やCSP（コンテンツセキュリティポリシー）に関する応答ヘッダーをテストしたい場合、あるいはブラウザが自動で送るReferer（参照元）やCookie（セッション情報）といったヘッダーを削除したい場合、または特定のURL（例: api.example.com）のみにヘッダーを適用したい場合は、やはりブラウザ拡張機能が有効だ。プロキシサーバー（例: mitmproxy）を使う方法もあるが、証明書の管理が必要になり、特にクラウド環境では導入が難しい場合がある。

このような複雑なシナリオに対応するために、HeaderwiseというオープンソースのManifest V3対応ヘッダー拡張機能がある。この拡張機能は、テスト自動化のために特別なビルドを提供している。Headerwiseは固定の拡張機能IDを持ち、特定のURLを開くことでヘッダー設定をプログラム的に行える。例えば、chrome-extension://ogjbgamdhnjnagcdgboifgmhlgddcdce/automation.html?X-Env=stagingのようなURLにアクセスすると、拡張機能が指定されたヘッダーを設定し、設定完了をWebページ上で通知する。

PlaywrightでHeaderwiseを利用する場合、まずchromium.launchPersistentContextを使ってHeaderwise拡張機能を読み込み、その後page.gotoで設定用のURLにアクセスする。設定が完了するまでpage.waitForFunctionで待機することで、確実にヘッダーが適用された状態でテストを進められる。 Seleniumで利用する場合、Selenium Managerがダウンロードする「Chrome for Testing」を使う必要がある。これは、通常のChrome 137以降が--load-extension引数を無視するのに対し、Chrome for Testingは引き続きこの引数をサポートしているためだ。ChromeOptionsに--load-extension=/path/to/headerwise-automationという引数を追加して、Headerwise拡張機能を読み込むことで利用できる。

既存のModHeaderで書かれたテストコードを活かしたい場合でも、Headerwiseは対応している。Headerwiseの自動化ビルドは、ModHeaderが利用していたwebdriver.modheader.com/addのようなURLを内部的にエミュレートし、ページタイトルを「Done」と表示する。これにより、テストコード内で読み込む拡張機能をHeaderwiseに切り替えるだけで、多くのModHeader用テストを修正せずに再利用できる可能性がある。拡張機能は署名された.crx形式で提供されており、Base64形式で拡張機能を受け入れるクラウドグリッド環境でも動作するが、その際もChrome for Testingを指定することが推奨される。

どの方法を選ぶべきかは、テストの要件によって変わる。 もし、すべてのリクエストに同じHTTPヘッダーを設定するだけで良いならば、PlaywrightのextraHTTPHeadersやSeleniumのDevToolsプロトコルを使う方法が最もシンプルで、何もインストールする必要がない。 応答ヘッダーの変更、ヘッダーの削除、特定のURLに限定したルール設定、または既存のModHeader用のテストコードがたくさんある場合は、HeaderwiseのようなManifest V3対応の拡張機能を利用するのが良い選択肢だ。 また、Firefoxブラウザでのテストが必要な場合や、ブラウザを介さないネットワークトラフィック（例えばAPIテスト）も制御したい場合は、プロキシサーバーを導入するのが適切な解決策となるだろう。

今回のModHeaderの件は、Web技術の進化、特にブラウザのセキュリティ強化や拡張機能のルール変更が、テスト自動化の現場にどのような影響を与えるかを示す良い例と言える。システムエンジニアを目指す上では、このような技術変化に対応し、常に新しい解決策を学び続ける姿勢が非常に重要となる。