ステージング環境のAPIをテストしたいとき、多くの開発者がとる手段はVPN、プロキシ、あるいは専用のブラウザプロファイルだ。どれも動く。ただ、どれも面倒くさい。VPNはすべてのトラフィックをルーティングし直す。プロキシは証明書の問題を引き起こしやすい。専用プロファイルはログイン情報もブックマークも別管理になる。
Header Modifierはもっとシンプルな選択肢を提供する。特定のURLに特定のリクエストヘッダーを追加するだけだ。ルーティングは変わらない。他のブラウザタブに影響しない。
具体的な使い方
多くのシステムでは、バックエンドが特定のヘッダーの値によってリクエストの転送先を切り替える。たとえば：
X-Environment: stagingX-Target-Backend: stagingX-App-Version: next
これらは実在するヘッダーではなく、あくまで構成例だ。自分のシステムで使っているヘッダー名に置き換えてほしい。
Header Modifierでルールを追加するとき、設定する項目は三つだけ：
- ヘッダー名（例：
X-Environment） - 値（例：
staging） - URLパターン（例：
*://api.example.com/*）
このURLパターンが重要だ。*://*/*（すべてのURL）に設定してしまうと、そのChromeから出るあらゆるリクエストにヘッダーが付く。ステージングヘッダーが外部サービスや本番CDNに届いてしまう可能性がある。パターンは必ず必要なドメインに絞ること。
リクエストヘッダーとレスポンスヘッダー
はっきりさせておく。Header Modifierが変更できるのはリクエストヘッダーだけだ。
リクエストヘッダーとは、ブラウザがサーバーに送るもの（Authorization、Accept-Language、カスタムのX-*ヘッダーなど）。レスポンスヘッダーはサーバーがブラウザに返すもの（Content-Type、Cache-Control、Access-Control-Allow-Originなど）。
「なぜAccess-Control-Allow-Originが変わらないんだ」と時間を無駄にするケースは多い。それはレスポンスヘッダーだから、変えられない。これを最初から理解しておくだけで、余計なデバッグが減る。
Chromeが無音で拒否するヘッダーがある
Chromeはいくつかのヘッダーを拡張機能から保護している。Host、Cookie、Content-Lengthなど、セキュリティ上の理由で変更が禁止されているものがある。Header Modifierでそれらに対するルールを設定しても、Chromeはそのルールを黙って無視する。エラーメッセージは出ない。
どのヘッダーが保護されているかはChromeのdeclarativeNetRequestドキュメントに一覧がある。「ヘッダーの設定が効いていない」と感じたら、まずそのリストを確認する習慣をつけると時間が節約できる。
このブラウザにしか効かない
Header Modifierのルールが影響するのはそのChromeブラウザから発行されるリクエストだけだ。
curl、Postman、GitHub ActionsなどのCI/CDパイプライン、サーバーからのアウトバウンドリクエスト——これらにはまったく無関係だ。「Chromeでは確認できたのにCIでは本番APIに繋いだまま」は仕様通りの動作であって、バグではない。ローカル開発・QA確認に特化したツールだ。
ルールはChromeのSync機能で同じアカウントの他のデバイスにも同期される。自宅のMacと職場のMacで同じルールを使いたければ、一度設定すれば両方に反映される。逆に、特定のデバイスだけに限定したい場合は別のChromeプロファイルを使うか、テスト後にマスタースイッチをオフにする。
マスタースイッチで終わる
Header Modifierにはマスタースイッチがある。全ルールを一括で無効化するためのものだ。ルールは削除されない——オフにするだけで何も起きなくなり、次のテストのときに再度オンにするだけで使える。
テストが終わったらスイッチをオフにする。これを習慣にするだけで、ステージングヘッダーをうっかり本番セッションに送り続けるミスを防ぎやすくなる。
Header Modifierは無料でアカウント不要、収集するデータは何もない。ChromeウェブストアからインストールできるChrome専用の拡張機能だ。詳細はHeader Modifierの製品ページと開発者向けツールページで確認できる。