# ネットワークリクエストとレスポンスを変更する: chrome-use network route 詳解

開発かいはつしていると、ネットワークを一時的いちじてきに少し変かえたくなる瞬間しゅんかんがどうしてもあります。バックエンドAPIがまだできていないので、まず仮かりデータでフロントエンドを動うごかしたい。あるリクエストに別べつのパラメータを付つけたらどうなるか試ためしたい。あるいは統計とうけいや埋うめ込こみ計測けいそくのリクエストをそのまま止とめたい。これまでは、コードを変更へんこうしてスイッチを追加ついかするか、mock serverを立たてるか、パケットキャプチャ用のプロキシを挟はさむか（しかもCA証明書しょうめいしょのインストールが必要ひつよう）でした。どれも極端に重おもいわけではありませんが、どれも追加ついかの準備じゅんびが必要ひつようです。

chrome-useの network route は、この作業さぎょうをブラウザ本体ほんたいの中なかに収おさめます。あなたが操作そうさしているそのChrome上で、マッチしたリクエストを直接ちょくせつインターセプトし、レスポンスをmockする、送信そうしんされるリクエストを変更へんこうする、またはそのままブロックできます。プロキシも証明書しょうめいしょも、検証けんしょう対象たいしょうコードの変更へんこうも不要ふようです。

4つの使つかい方かた

1つの network route コマンドが、渡わたしたパラメータに応おうじて動作どうさを決きめます。

# 1) Mockレスポンス: リクエストは外へ送られず、指定した仮データを直接返す
chrome-use network route "*/api/me" --body '{"vip":true}' --status 200 --content-type application/json

# 2) リクエスト変更: リクエストは送るが、メソッド/ヘッダー/ボディ/URLを変更し、実レスポンスは通常どおり返る
chrome-use network route "*/api/save" --method POST --set-header Authorization="Bearer test"
chrome-use network route "*/v1/*" --rewrite-url https://staging.example.com/v1/thing

# 3) 実レスポンス変更: リクエストは送信し、実レスポンス取得後にステータス/ヘッダー/ボディを変更する
chrome-use network route "*/api/me" --edit-status 503 --edit-header X-Env=test --replace 'prod=>staging'

# 4) ブロック: 直接止める（埋め込み計測の遮断、オフラインテスト）
chrome-use network route "*/analytics" --abort

区別くべつはとても簡単かんたんです。mock用ようフィールド（--body / --status / --header / --content-type）があればレスポンスを偽造ぎぞうし、リクエストは短絡たんらくされて外そとへ出でません。リクエスト用ようフィールド（--method / --set-body / --set-header / --rewrite-url）があれば、変更へんこうしてから通過つうかさせ、実際じっさいのレスポンスを受うけ取とります。編集へんしゅう用ようフィールド（--edit-status / --edit-header / --replace 'from=>to'）があれば、まず通過つうかさせ、実じつレスポンスが戻もどってきてからそれを変更へんこうします。mockと「実じつレスポンス変更へんこう」の違ちがいはここにあります。前者ぜんしゃはまったく外そとへ出でず、データを自分じぶんで作つくります。後者こうしゃは実じつレスポンスが返かえってくる必要ひつようがあり、その一部いちぶだけを変更へんこうします。これらのヘッダー関連かんれんパラメータはいずれも複数回ふくすうかい指定していでき、既存きそんヘッダーにマージして上書うわがきします。

名前なまえは意図的いとてきにPlaywrightの route / fulfill / continue / abort に合あわせています。使つかったことがある人ひとなら学まなび直なおす必要ひつようはありません。

原理げんり: すでに話はなしているプロトコル

この仕組しくみの内部ないぶはChrome DevTools ProtocolのFetchドメインです。Fetch.enable でマッチルールを設定せっていし、ヒットしたリクエストは Fetch.requestPaused で停止ていしします。その後、状況じょうきょうに応おうじて fulfillRequest（仮かりレスポンスを返かえす）、continueRequest（上書うわがきパラメータつきで通過つうかさせる）、または failRequest（ブロック）を呼よびます。これは新あたらしく作つくった仕組しくみではありません。DevToolsの「Local Overrides」やPlaywrightのrouteも、Chromeに対たいするインターセプトの内部ないぶでは、同おなじFetchドメインを包つつんでいます。

chrome-useにとって、重要じゅうような点てんは2つあります。

1つ目めは、もともとCDPを話はなしていることです。chrome-useは独自どくじのネイティブCDPクライアントでブラウザを操作そうさしており、fulfillRequest / continueRequest などのコマンドはすでにコード内ないにあります（ドメインフィルタやプロキシ認証にんしょうでも使つかっています）。mockやリクエスト変更へんこうの追加ついかは、既存きそんの実行じっこう能力のうりょくをコマンドラインから出だしただけに近ちかく、ゼロから別べつの仕組しくみを書かいたわけではありません。

2つ目めは、ブラウザ拡張機能かくちょうきのうの権限けんげんに触ふれないことです。chrome-useが実際じっさいのChromeにつながるときは、拡張機能かくちょうきのうの chrome.debugger 経路けいろを使つかいます。リクエストのインターセプトは、この経路けいろでCDPコマンドをいくつか追加ついかで送おくるだけです。拡張機能かくちょうきのうのmanifestは1文字もじも変かえる必要ひつようがなく、webRequest も不要ふようで、declarativeNetRequest も不要ふようです。そしてこの2つは、まさにChromeウェブストアが重点的じゅうてんてきに審査しんさする権限けんげんです。つまり、この機能きのうは新あたらしい権限けんげんを一切いっさい導入どうにゅうせず、拡張機能かくちょうきのうの審査しんさ通過つうかに悪影響あくえいきょうを与あたえるリスクもありません。

ついでに、なぜ既存きそんのmockツールをそのまま統合とうごうしなかったのかも説明せつめいします。いくつか調査ちょうさしました。mockttpはプロセス内ないのNodeプロキシで、自己署名じこしょめいCAが必要ひつようです。mitmproxyは独立どくりつしたPython MITMプロキシで、こちらも証明書しょうめいしょのインストールが必要ひつようです。MSWはページにService Workerを注入ちゅうにゅうするため、この道みちはchrome-useの「JS注入ちゅうにゅうゼロ」というステルス原則げんそくに直接ちょくせつ反はんします。これらは重おもいか、プロキシと証明書しょうめいしょが必要ひつようか、ステルス性せいを壊こわすかのどれかです。そしてChromeに対たいするインターセプトでは、内部ないぶでやはりCDP Fetchを包つつんでいます。すでにこのプロトコルを話はなしているなら、表面ひょうめんを補おぎなうのが最もっとも軽かるい道みちです。

実機じっきで一度いちど動うごかす

httpbin.org（リクエストをそのままエコーバックしてくれる）を使つかって、2つの主おもな経路けいろを検証けんしょうします。まず隔離かくりしたブラウザを起動きどうします。

Mockレスポンス: /get に仮かりデータを設定せっていし、その後ページ内ないからfetchします。

chrome-use --launch --session demo network route "*/get" \
  --body '{"mocked":true,"by":"chrome-use"}' --status 200 --content-type application/json
chrome-use --session demo open https://httpbin.org/
# ページ内: fetch('/get') → {"mocked":true,"by":"chrome-use"}

返かえってくるのは設定せっていした仮かりデータであり、httpbinの実際じっさいの /get レスポンスではありません。リクエストはまったく外そとへ出でていません。

リクエスト変更へんこう: /headers にカスタムヘッダーを追加ついかし、もう一度いちどfetchします（httpbinは受うけ取とったリクエストヘッダーをエコーバックします）。

chrome-use --session demo network route "*/headers" --set-header X-Chrome-Use=hello123
# ページ内: fetch('/headers') → エコーされたheaders内に "X-Chrome-Use": "hello123" が現れる

httpbinがエコーバックしたリクエストヘッダーに X-Chrome-Use: hello123 が含ふくまれているため、このヘッダーがリクエストの実際じっさいの送信前そうしんまえに追加ついかされたことがわかります。

実じつレスポンス変更へんこうは example.com で検証けんしょうします。リクエストは通常つうじょうどおり送信そうしんし、実際じっさいのページを取得しゅとくした後、レスポンスボディ内ないの文字列もじれつを置換ちかんし、ステータスコードを599に変更へんこうし、レスポンスヘッダーを追加ついかします。

chrome-use --launch --session demo network route "*example.com/" \
  --edit-status 599 --edit-header X-Edited=yes --replace 'Example=>EDITED' --resource-type xhr,fetch
chrome-use --session demo open https://example.com/
# ページ内で fetch('/') → {status:599, xedited:"yes", bodyEdited:true}

取得しゅとくできるのは、実じつレスポンスを変更へんこうしたバージョンです。ステータスコードは599になり、X-Edited ヘッダーが追加ついかされ、ボディ内ないの Example は EDITED に置おき換かわっています。ここでは --resource-type xhr,fetch を使つかい、編集へんしゅう対象たいしょうをAPIリクエストに限定げんていし、トップレベルドキュメントのナビゲーションには触ふれないようにしています（ナビゲーションドキュメントのステータスコードをエラーコードに変かえると、ページ読よみ込こみの意味いみが乱みだれるためです）。

現在げんざいの境界きょうかい

実じつレスポンス変更へんこうは、現時点げんじてんでは「レスポンスボディ全体ぜんたいを取得しゅとくし、文字列もじれつ置換ちかん + ステータス/ヘッダーの上書うわがき」をするものです。日常的にちじょうてきにフィールドを変かえたり、エラー状態じょうたいを作つくったりするには十分じゅうぶんです。より細こまかい構造化こうぞうか書かき換かえ（たとえばJSONのあるフィールドだけを変かえるなど）は、今いまは文字列もじれつ置換ちかんで対応たいおうします。今後こんご、需要じゅようを見みて考かんがえます。また、もともとHARは記録きろくできるので、次つぎのステップとして、記録きろくしたHARエントリをそのままmock fixtureとして使つかえるようにする予定よていです。一度いちど記録きろくし、再生時さいせいじに少し変更へんこうすればよい、という形かたちです。

2つのリポジトリがあります。chrome-useは github.com/leeguooooo/chrome-use にあります。完全かんぜんなコマンドは chrome-use skills get core でローカルに取得しゅとくして確認かくにんできます。