Fiddler: WindowsアプリケーションのHTTPトラフィックのデバッグ

```html

Windowsアプリケーションを開発またはテストしていて、どのHTTPリクエストが送信されているかを確認したい場合、Fiddlerはあなたの主要なツールとなります。すべてのトラフィックをキャプチャし、リアルタイムで分析、変更、再現することができます。特に、デフォルトでシステムプロキシを回避するUWPアプリケーションを扱う際に便利です。

このガイドでは、インストール、HTTPSキャプチャの設定、UWPとの連携、外部プロキシの接続、およびAPIのデバッグからバックグラウンドリクエストの監視まで、一般的な使用シナリオを解説します。

Fiddlerとは何か、なぜ必要なのか

Fiddlerは、Telerik（現在はProgress）によって開発されたHTTPプロキシデバッガです。ローカルプロキシサーバーとして機能し、コンピュータのすべてのHTTPおよびHTTPSリクエストが通過し、リアルタイムでそれらを確認できます。このツールは無料で、Fiddler Classic（Windows専用）とFiddler Everywhere（クロスプラットフォーム）の2つのバージョンがあります。

FiddlerはブラウザのDevToolsと何が違うのでしょうか？ブラウザの開発者ツールは、ブラウザ自体のトラフィックのみを表示しますが、Fiddlerはコンピュータ上のすべてのアプリケーションからのリクエストをキャプチャします。デスクトップアプリ、システムサービス、Windowsのバックグラウンドプロセス、Wi-Fi経由のモバイルアプリ、特に重要なのはMicrosoft StoreからのUWPアプリケーションです。

Fiddlerが解決する典型的なタスクは次のとおりです：

デスクトップアプリのAPIリクエストの分析 — プログラムが何を送信しているのか、どのヘッダー、どのデータが含まれているのか
自分のコードのデバッグ — アプリケーションの実際のリクエストを確認し、送信するつもりだったものではなく、実際に送信されるものを確認できます
リクエストとレスポンスをリアルタイムで変更 — エッジケースのテスト用にデータを置き換えます
バックグラウンドアクティビティの監視 — プログラムが知らないうちにどのサーバーに「電話」をかけているか
プロキシを介したテスト — 外部プロキシサーバーを介してアプリケーションの動作を確認します
リクエストの再現 — キャプチャしたリクエストを変更されたパラメータで再送信します

Fiddlerは、閉じられたAPIを扱う開発者にとって特に価値があります。たとえば、モバイルアプリやデスクトップクライアントのプロトコルのリバースエンジニアリングです。プログラムを起動し、インターフェースで必要なボタンを押すだけで、Fiddlerで全てのリクエストを確認できます。

インストールと初期設定

Fiddler Classicのインストールには約2分かかります。公式サイトからインストーラーをダウンロードし、実行してください。インストール後、Fiddlerは自動的にWindowsのシステムプロキシとして127.0.0.1:8888に設定されます。

起動後すぐに、3つのエリアを持つメインウィンドウが表示されます：

左パネル（セッション） — リアルタイムでキャプチャされたすべてのリクエストのリスト
右上パネル — 選択したリクエストの詳細（ヘッダー、ボディ、パラメータ）
右下パネル — サーバーのレスポンス

最初に行うべきことはフィルタリングの設定です。そうしないと、Windowsのすべてのシステムトラフィック（更新、テレメトリ、OneDriveなど）がリストに表示され、必要なリクエストを見つけるのが難しくなります。右側のフィルタータブに移動し、フィルターを使用を有効にします。次のホストのみを表示フィールドに、興味のあるドメインを指定します。

Fiddler Classicの便利なショートカットキー：

F12 — トラフィックのキャプチャをオン/オフ
Ctrl+X — セッションリストをクリア
Ctrl+F — セッションの検索
R — 選択したリクエストを再実行
Shift+Delete — 選択したセッションを削除

また、セッションの自動保存をすぐに設定することをお勧めします：ファイル → トラフィックをキャプチャおよびファイル → 保存 → すべてのセッション。これにより、後で記録されたトラフィックに戻ってオフラインで分析できます。

HTTPSトラフィックのキャプチャ: 証明書の設定

デフォルトでは、FiddlerはHTTPトラフィックのみをキャプチャします。HTTPS（現代のトラフィックの95％以上）を扱うには、SSL復号化を設定する必要があります。FiddlerはMan-in-the-Middleとして機能し、自分のルート証明書を生成し、すべてのHTTPS接続に署名します。

HTTPSキャプチャの手順：

ツール → オプション → HTTPSを開きます
HTTPS CONNECTをキャプチャにチェックを入れます
HTTPSトラフィックを復号化にチェックを入れます
ドロップダウンリストから...すべてのプロセスからを選択します
アクション → ルート証明書を信頼ボタンをクリックします
Windowsのシステムストレージに証明書をインストールすることを確認します
Fiddlerを再起動します

これで、プロトコル列にHTTPSが表示され、CONNECTの代わりに、リクエストとレスポンスの復号化された内容を確認できるようになります。

⚠️ 注意: 証明書のセキュリティ

Fiddlerの証明書は、現在のWindowsユーザーのストレージにのみインストールされます。証明書ファイルを第三者に渡さないでください — それにより、彼らがあなたのHTTPSトラフィックをキャプチャできるようになります。デバッグが終了したら、ツール → オプション → HTTPS → アクション → インターセプション証明書を削除を通じて証明書を削除できます。

一部のアプリケーションは証明書ピンニングを使用しており、特定のサーバー証明書を確認し、Fiddlerを介しては動作しません。この場合、アプリケーションで接続エラーが表示されます。ピンニングの回避は、この記事の範囲を超えた別のトピックです。

UWPアプリケーションのトラフィックをキャプチャする方法

UWP（Universal Windows Platform）は、Microsoft Storeからのアプリケーションです：メール、マップ、映画とテレビ、Spotify、Netflixなど。これらのアプリの特徴は、セキュリティ上の理由から、隔離されたコンテナ（App Container）内で動作し、システムプロキシを使用しないことです。そのため、通常のFiddlerの設定ではトラフィックをキャプチャできません。

この問題を解決するために、Fiddlerは特別なツールを提供しています — AppContainer Loopback Exemption Utility。これにより、UWPアプリケーションが例外リストに追加され、Fiddlerのローカルプロキシにアクセスできるようになります。

方法 1 — Fiddlerのインターフェースを介して：

メニューからWinConfigを選択します（ツールバーのボタンまたはツール → Win8 Loopback Exemptions）
インストールされているすべてのUWPアプリケーションのリストが表示されます
必要なアプリケーションを見つけて、その横にチェックを入れます
変更を保存をクリックします
UWPアプリケーションを再起動します

方法 2 — コマンドラインを介して（自動化のため）：

CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsMaps_8wekyb3d8bbwe"

Microsoft.WindowsMaps_8wekyb3d8bbweを必要なアプリケーションのPackage Family Nameに置き換えます。PowerShellで次のコマンドを使用して見つけることができます：

Get-AppxPackage | Select-Object Name, PackageFamilyName | Sort-Object Name

例外を追加した後、UWPアプリケーションはFiddlerを介してトラフィックを送信し始めます。セッションリストにそのリクエストが表示されます — 通常、User-Agentや宛先ホストで簡単に識別できます。

💡 ヒント: UWPとHTTPS

UWPアプリケーションのHTTPSトラフィックをキャプチャするには、loopback例外を追加するだけでは不十分です。Fiddlerの証明書をTrusted Root Certification AuthoritiesのLocal Machineストレージにインストールする必要があります（現在のユーザーだけでなく）。certmgr.mscまたはグループポリシーを介してこれを行ってください。

フィルター、ブレークポイント、リクエストの変更

Fiddlerのデバッグにおける3つの最も強力な機能は、セッションのフィルタリング、ブレークポイント、AutoResponderです。それぞれを解説します。

セッションのフィルタリング

フィルタータブでは、必要なリクエストのみを表示できます。主なオプションは次のとおりです：

次のホストのみを表示 — ドメインによるフィルター（例：api.example.com）
URLに含まれている場合のみ表示 — URLの一部によるフィルター
レスポンスのContent-Typeが次の場合のみ表示 — JSON、XML、画像など
URLに含まれている場合は非表示 — ノイズリクエストを除外（例：telemetry、analytics）

また、ウィンドウの下部にあるQuickExecバーを使用して、迅速なコマンドを実行できます。たとえば、select status 404は、404エラーのあるすべてのリクエストをハイライトし、bold apiは、URLに「api」を含むすべてのセッションを太字にします。

ブレークポイント

ブレークポイントは、リクエストまたはレスポンスを送信/受信する前に停止し、手動で内容を変更することを可能にします。これは、HTTP用のコードデバッガのブレークポイントのようなものです。

ルール → 自動ブレークポイント → リクエストの前 — 送信前に各リクエストを停止します
ルール → 自動ブレークポイント → レスポンスの後 — アプリケーションに渡す前に各レスポンスを停止します
セッションを右クリック → ブレークポイント → リクエストでブレーク — 特定のURLに対するポイントブレークポイント

リクエストが停止すると、任意のヘッダー、リクエストボディ、URLを変更し、完了まで実行をクリックして続行できます。これは、変更されたデータでアプリケーションの動作をテストする際に特に便利です。

AutoResponder

AutoResponderは、サーバーのレスポンスを置き換えるためのツールです。ルールを作成します：「URLがパターンと一致する場合 — このファイル/レスポンスを返す」。用途は次のとおりです：

実際のバックエンドなしでAPIのスタブを使用してアプリケーションをテストする
サーバーエラー（500、503、タイムアウト）をシミュレートする
リソースの置き換え — サーバーの代わりにローカルバージョンのJS/CSSをロードする
開発を加速する — 外部APIへの遅いリクエストをキャッシュする

Fiddlerを介して外部プロキシを接続する

Fiddlerの重要な機能の1つは、「プロキシを介したプロキシ」モード（アップストリームプロキシ）での動作です。Fiddlerはローカルでトラフィックをキャプチャし、その後外部プロキシサーバーを介して送信します。これにより、リクエストをデバッグしながらIPアドレスやジオロケーションを変更できます。

これが必要な場合：

企業プロキシを介してアプリケーションの動作をテストする
ジオ依存コンテンツを確認する — アプリケーションが他の国からどのように動作するか
自らプロキシを使用するアプリケーションをデバッグする
IP制限のあるAPIをテストする（IPホワイトリスト）

Fiddler Classicでのアップストリームプロキシの設定：

ツール → オプション → ゲートウェイを開きます
手動プロキシ設定を選択します
プロキシフィールドに、host:port形式でプロキシのアドレスを入力します
プロキシが認証を必要とする場合 — ユーザー名とパスワードを指定します
OKをクリックし、トラフィックキャプチャを再起動します

Fiddlerは、アップストリームとしてHTTP、HTTPS、SOCKS5プロキシをサポートしています。SOCKS5の場合、記述形式は少し異なります：

socks=proxy.example.com:1080

アプリケーションのジオ依存動作をテストするためには、レジデンシャルプロキシが適しています — それらは必要な国の実際の家庭ユーザーのIPを使用し、アプリケーションはその地域の実際のユーザーが受け取るのと同じ応答を得ます。これは、APIがジオに応じて異なるコンテンツを返す場合に重要です。

デバッグ中に大容量のデータを高速でダウンロードする必要がある場合は、データセンタープロキシが適しています — それらは安定した接続と最小限の遅延を提供し、重いAPIを扱う際に便利です。

💡 FiddlerScriptによる動的プロキシ選択

FiddlerScriptを使用すると、異なるホストに対して異なるアップストリームプロキシを設定できます。たとえば、api.us-service.comへのリクエストをアメリカのプロキシを介して送信し、他のリクエストは直接送信するように設定できます：

static function OnBeforeRequest(oSession: Session) {
  if (oSession.HostnameIs("api.us-service.com")) {
    oSession["x-OverrideGateway"] = "us-proxy.example.com:8080";
  }
}

実用的なシナリオ: パース、APIテスト、ジオバイパス

Fiddlerを使用して便利に解決できる具体的なタスクを見ていきましょう。

シナリオ 1: モバイルアプリのAPIのリバースエンジニアリング

アプリケーション内でのアクションを自動化したいが、公開APIがない場合の解決策は、AndroidエミュレーターまたはWindowsクライアントでアプリケーションを起動し、Fiddlerをプロキシとして使用するように設定し、必要なアクションを実行する際のすべてのリクエストを記録することです。

記録後、エンドポイント、リクエストの形式、認証ヘッダー、トークンの完全な概要を得ることができます。これらのデータは、自分自身のクライアントを作成したり、スクリプトを介して自動化するために使用できます。

シナリオ 2: マーケットプレイスのパーサーのデバッグ

Wildberries、Ozon、その他のマーケットプレイスのパーサーを開発する際、リクエストがブロックされる理由が不明なことがよくあります。Fiddlerを使用すると、通過するブラウザのリクエストとブロックされるパーサーのリクエストを比較し、ヘッダー、順序、Cookieの値、またはTLSフィンガープリントの違いを見つけることができます。

典型的な発見は、パーサーがヘッダーを異なる順序で送信している、Accept-Languageが欠けている、またはUser-AgentにPythonのバージョンが含まれていることです。これらの詳細をパーサーのコードで修正することで、ブロックされる可能性を減らすことができます。

シナリオ 3: ジオ依存コンテンツのテスト

アプリケーションが異なる国のユーザーに異なるコンテンツを表示する場合、これらの国からの実際のIPでテストする必要があります。Fiddlerを必要な地域のアップストリームプロキシで設定し、アプリケーションを起動すると、その国のユーザーが見るものと全く同じものが表示され、すべてのリクエストの完全なログが得られます。

シナリオ 4: アプリケーションのバックグラウンドアクティビティの監視

インストールされたプログラムがどこに「電話」をかけているかを知りたいですか？Fiddlerを起動し、プログラムを起動し、5〜10分待ちます。セッションリストに、プログラムがアクセスしたすべてのホストが表示されます。これは、サードパーティソフトウェアのセキュリティ監査、テレメトリの存在確認、または望ましくない接続のチェックに役立ちます。

シナリオ 5: 再現のためのリクエストのエクスポート

Fiddlerは、キャプチャしたリクエストをcURL形式でエクスポートすることができます。これは、ターミナルで直接実行したり、Postmanに貼り付けたりできます。セッションを右クリック → コピー → cURLリクエスト。これは、リクエストを同僚に渡したり、APIを文書化するのに便利です。

Fiddler ClassicとFiddler Everywhere: どちらを選ぶべきか

Telerikは2つのバージョンの製品をサポートしており、それらの間の選択は常に明確ではありません。主要な違いを見ていきましょう。

パラメータ	Fiddler Classic	Fiddler Everywhere
プラットフォーム	Windowsのみ	Windows、macOS、Linux
価格	無料	有料サブスクリプション（無料プランあり）
UWPサポート	はい（WinConfig経由）	制限付き
FiddlerScript	はい（JScript.NET）	いいえ（ルールが使用されます）
インターフェース	古いが機能的	現代的で使いやすい
共同作業	いいえ	はい（クラウドコレクション）
拡張性	.NETプラグイン	制限付き
システムトラフィックのキャプチャ	完全	完全

Fiddler Classicを選ぶべき時： Windowsでのみ作業している場合、UWPアプリケーションの作業が必要な場合、FiddlerScriptを自動化に使用する場合、または制限なしの完全無料版が重要な場合。

Fiddler Everywhereを選ぶべき時： macOSまたはLinuxで作業している場合、現代的なインターフェースが必要な場合、共有リクエストコレクションでのチーム作業が重要な場合、またはCI/CDパイプラインとの統合を希望する場合。

また、代替手段としてCharles Proxy（有料、macOSで人気）、mitmproxy（無料、コマンドライン、非常に柔軟）、Wireshark（パケットレベルで動作し、HTTPではない）を挙げることができます。各ツールにはそれぞれの強みがありますが、Windowsアプリケーションのデバッグに関しては、Fiddler Classicが最適な選択肢であり続けます。

一般的な問題とその解決策

Fiddlerを使用していると、時折一般的な問題が発生します。以下は最も一般的な問題とその解決策です。

問題: Fiddlerをオンにするとアプリケーションが動作しない

原因: 証明書ピンニング、アプリケーション内にハードコーディングされたプロキシ、またはアプリケーションがFiddlerの証明書を信頼しないこと。解決策：

Fiddlerの証明書をLocal Machine → Trusted Rootストレージにインストールします
アプリケーションが証明書ピンニングを使用していないか確認します
SSLの例外にホストを追加します：ツール → オプション → HTTPS → 次のホストの復号化をスキップ

問題: Fiddlerを閉じた後、インターネットが動作しない

Fiddlerが異常終了したため、システムプロキシを解除できませんでした。解決策: Windowsの設定 → ネットワーク → プロキシを開き、手動プロキシをオフにします。または、Fiddlerを再起動し、正常に閉じます。

問題: CONNECTトンネルのみが表示され、HTTPSの内容が表示されない

HTTPSキャプチャが設定されていません。証明書の設定セクションに戻り、HTTPSトラフィックを復号化のチェックボックスがオンになっていること、証明書がシステムストレージにインストールされていることを確認してください。

問題: UWPアプリケーションのトラフィックがFiddlerに表示されない

このアプリケーションのloopback例外が追加されていません。WinConfigを使用し（UWPに関するセクションで説明）、例外を追加した後にアプリケーションを再起動します。

問題: アップストリームプロキシが動作しない（接続エラー）

次の点を確認してください: プロキシのアドレスとポートが正しいか、ユーザー名/パスワードが正しいか、プロキシサーバーが利用可能か（Fiddlerなしで直接接続してみてください）。また、プロキシが必要なプロトコルをサポートしているか確認してください — すべてのHTTPプロキシがHTTPSトンネリングをサポートしているわけではありません。

結論

Fiddlerは、WindowsアプリケーションのHTTPトラフィックを扱うすべての人にとって欠かせないツールです。リアルタイムですべてのリクエストを確認し、リアルタイムで変更し、さまざまな条件下でアプリケーションの動作をテストし、ブラウザのDevToolsでは実行できないタスクを解決できます。特に、loopback例外メカニズムを介したUWPアプリケーションのサポートは、ほとんどの類似ツールにはないユニークな機会です。

アプリケーションのジオ依存動作をテストしたり、外部プロキシを介しての動作を確認したりする場合は、Fiddlerでアップストリームプロキシを設定してください。特定の国からの正確なテストのために実際のIPが必要な場合は、レジデンシャルプロキシに注目してください — それらは最大限に現実的なジオを提供し、テストしているサービスからのブロックのリスクを最小限に抑えます。

まずはFiddler Classicから始めてください — 無料で、十分に文書化されており、Windowsでのデバッグの90％のタスクをカバーしています。ニーズが高まるにつれて、Fiddler Everywhereに移行するか、mitmproxyのような専門ツールを追加して、より柔軟な自動化を実現できます。