fiddler-traffic-debugging

Fiddler 機能の検証

機能の実行によって生成されたトラフィックを分析し、観測された HTTP の動作が正しいように見えるかを判断して、エンドポイントごとにグループ化した概要と、考えられる問題を提示します。

運用ルール

1. このスキルでは MCP を優先します。現在のセッションで利用できる場合は、トラフィック分析に Fiddler Everywhere MCP ツールを使用してください。
2. Fiddler MCP ツールが利用できる場合は、トラフィックを調べるためにシェルツール、rg、grep、ワークスペース内のファイルスキャン、エクスポートしたセッションダンプを使用しないでください。
3. 重点的に確認するプロセスがわかっている場合は、キャプチャ前の手順として CaptureApplication を優先してください。これにより OS レベルでキャプチャ対象が限定され、最初からセッションリストを整理できます。機能検証に必要なトラフィックを絞り込む際は、必要に応じて ApplyFilters を使用してください。
4. 分析は実用的な範囲にとどめてください。目的は機能が動作しているように見えるかを検証することであり、パケットレベルの網羅的な監査ではありません。
5. 現在のセッションで Fiddler MCP ツールを利用できない場合は、そこで停止し、ユーザーに fiddler-mcp-setup を先に実行してから再試行するよう伝えてください。
6. ランタイムで Fiddler MCP ツールがすでに公開されている場合は、/mcp を手動で調べたり、curl で生の MCP プロトコルリクエストを送信したりしないでください。
7. ホストが tools/list で公開しているツール名のみを使用してください。セッションで利用可能なツール以外の名前を作り出したり、推測して使用したりしないでください。
8. すべてのセッションツール（GetSessionsCount、GetSessions、GetSessionDetails、ClearSessions、ApplyFilters）では、sessionsSource パラメーターが必須です。キャプチャした HTTP/HTTPS トラフィックには LiveTraffic、LLM/AI エージェントの API 呼び出しには AgentCalls を常に指定してください。このパラメーターを省略しないでください。

セッションソース

Fiddler には 2 つのセッションソースがあります。すべてのセッションツールに、常に適切なソースを指定してください。

sessionsSource	使用する状況
LiveTraffic	ブラウザー、ターミナル、計測対象プロセスからリアルタイムでキャプチャした HTTP/HTTPS トラフィック。機能検証ではこれをデフォルトで使用します。
AgentCalls	LLM/AI エージェントの API 呼び出し（例：OpenAI、Anthropic、Azure OpenAI）。ここにあるセッションには isCached、LLM モデル名、最後のユーザープロンプトのプレビューも含まれます。AI エージェントの動作を検証するときや、LLM 呼び出しのパターンを調査するときに使用します。

エージェントの API 呼び出しも HTTP トラフィックであり、両方のソースに表示されます。AgentCalls では、メタデータが拡充されたビューを利用できます。

前提条件の確認

1. Fiddler Everywhere がインストールされていることを確認します。
2. Fiddler Everywhere MCP ツールが利用可能であることを確認します。

便利なツールと使い方

GetStatus

最初にこれを使用して、Fiddler に接続でき、使用可能な状態であることを確認します。

確認に役立つ項目：

• ユーザーがログインしているかどうか
• Fiddler がトラフィックをキャプチャしているように見えるかどうか
• 接続中のブラウザーまたはターミナルのインスタンスがあるかどうか
• HTTPS インスペクションの前提条件が正常に見えるかどうか

CaptureApplication

確認したいトラフィックを生成するプロセスが分かっている場合は、いつでも最初の手順として使用してください。

これは、利用できるノイズ削減ツールの中で最も強力です。OS レベルのキャプチャを特定のプロセスに限定するため、ライブトラフィックインスペクターにはそのプロセスのトラフィックだけが表示されます。同時に実行中のブラウザー、IDE、システムサービス、その他のアプリによるバックグラウンドノイズを除去できます。

使用方法：

• 現在の IDE または CLI の状況から推測したプロセス名または PID を指定します（例：テスト対象の機能を実行しているプロセス）。
• 複数の対象はスペース区切りで指定します。複数の単語からなる名前は引用符で囲む必要があります（例："Google Chrome"）。
• 指定したリストで現在のキャプチャフィルターが置き換えられます。エリシテーションがサポートされている場合、Fiddler は既存のフィルターとの統合を提案することがあります。
• CaptureApplication を呼び出した後、ユーザーが機能を実行する前に、ClearSessions を sessionsSource: LiveTraffic を渡して呼び出し、古いセッションを消去してください。これにより、結果のキャプチャには関連する実行分のみが含まれます。

CaptureApplication が適切でない場合：

• プロセス名または PID が不明で、推測もできない場合。
• 機能が複数のプロセスにまたがり、その名前を特定できない場合。
• ユーザーが明示的に、フィルターを適用していないトラフィックの分析を希望している場合。

その場合は、GetSessions の後に ApplyFilters を使用してください。

GetSessionsCount

詳細な分析に進む前の、簡単な妥当性確認として使用してください。

確認に役立つ項目：

• 何らかのデータがキャプチャされているかどうか
• 分析できる程度に、ユーザーが最近その機能を実行した可能性が高いかどうか

GetSessions

検証の主なツールです。これを使ってキャプチャされたセッションの一覧を取得し、その後、メモリ上でトラフィックを絞り込みます。

用途：

• 機能の実行に関連する可能性が最も高いリクエストを見つける
• リクエストの順序を特定する
• 失敗、再試行、リダイレクト、プリフライト、低速な呼び出しを見つける
• 最終的な要約に向けてエンドポイントのグループを作成する

一覧を絞り込む際は、次のようなユーザーの依頼に含まれる手がかりを優先してください。

• ホスト名
• URL パスまたはパスの一部
• HTTP メソッド
• 機能名またはキーワード
• 「たった今」や「保存をクリックした後」などのおおよその時間帯

セッション一覧を十分に扱える場合は、通常、メモリ上で絞り込むだけで十分です。キャプチャが大規模またはノイズの多い場合は、ApplyFilters を使用して、対象となるホスト、エンドポイント群、メソッド、または失敗パターンに絞り込んでください。

GetSessionDetails

GetSessions で対象のセッションを特定した後に使用してください。

詳細を調べるとよいセッション：

• statusCode が 400 以上のセッション
• statusCode が空、または存在しないセッション
• エンドポイントごとに最も遅いセッション
• 重要なエンドポイントの代表的な成功リクエスト
• CORS が関係している可能性がある場合の OPTIONS プリフライトリクエストと、その直後のリクエスト

詳細情報を使って、次の項目を調べます。

• リクエストヘッダーとレスポンスヘッダー
• リクエスト本文とレスポンス本文
• リダイレクト先
• コンテンツ長とコンテンツタイプ
• 認証ヘッダー、Cookie、検証メッセージ、エラーペイロード

AgentCalls セッションについては、LLM モデル、isCached フラグ、直近のユーザープロンプトのプレビューも確認してください。これらから、モデルルーティングの設定ミスや予期しないキャッシュヒットが分かることがよくあります。

レート制限：GetSessionDetails の呼び出しを短時間に 5 回を超えて連続実行しないでください。

ApplyFilters

フィルタリングによって分析が速くなる、または信頼性が高まる場合に使用してください。

用途の例：

• 1 つのホストのトラフィックだけを表示する
• 失敗したリクエストだけを表示する
• 特定のエンドポイント群に UI の表示を絞る
• 再試行、認証失敗、または POST などの 1 つのリクエストメソッドを分離する

フィルターをリセットするには、空のフィルターコレクションを指定して ApplyFilters を呼び出してください。

ClearSessions

対象を絞ったキャプチャを実行する前に、古いセッションを削除するために使用してください。必ず sessionsSource を渡します。通常は CaptureApplication の後、ユーザーが機能を実行する前に呼び出し、結果のインスペクターに関連するセッションだけが含まれるようにします。

StartCaptureWithBrowser / StartCaptureWithTerminal

テスト対象の機能で、プロキシが設定された新しい環境が必要な場合に使用します。

• StartCaptureWithBrowser — Fiddler プロキシがあらかじめ適用された Chrome インスタンスを開きます。
• StartCaptureWithTerminal — Fiddler プロキシの環境変数が設定されたターミナルを開きます。

対象のプロセスを CaptureApplication で計測できない場合や、キャッシュされた認証状態を避けるためにクリーンなブラウザーセッションが必要な場合に役立ちます。

推奨されるワークフロー

このワークフローは柔軟に使えるように設計されています。機能とキャプチャするトラフィック量に合わせて調整してください。

1. 機能の範囲を把握します。

   • ユーザーのリクエストから役立つ手がかりを抽出します。たとえば、実行された操作、ホスト、パスの一部、メソッド、対象プロセス、想定されるエンドポイントなどです。
   • 適切な sessionsSource を判断します。標準的な HTTP 機能には LiveTraffic を、LLM または AI エージェントの動作を検証する場合には AgentCalls を使用します。
   • リクエストが曖昧な場合は、直近のトラフィックを分析し、結果が直近のキャプチャに基づいていることを伝えます。

2. キャプチャの対象を絞ります（強く推奨）。

   • 対象プロセスがわかっている場合、または IDE／CLI のコンテキストから推測できる場合は、プロセス名または PID を指定して CaptureApplication を呼び出します。
   • 次に、ClearSessions（sessionsSource: LiveTraffic を指定）を呼び出して以前のノイズを除去し、次回の実行でクリーンなキャプチャが得られるようにします。
   • まだ機能が実行されていない場合は、ユーザーに実行を依頼します。すでに実行済みの場合は、分析に進みます。

3. GetSessions でセッション一覧を取得します。

   • 機能の範囲に一致するセッションを絞り込みます。
   • 明確な手がかりがない場合は、キャプチャ履歴全体ではなく、関連するセッションが直近に集中している部分に注目します。
   • キャプチャにまだノイズが多い場合は、ApplyFilters を使ってさらに絞り込みます。

4. トラフィックをエンドポイントごとにグループ化します。

   • ホストと正規化したパスでグループ化します。
   • グループ化の際はクエリ文字列を除外します。
   • 数値 ID や UUID のようなセグメントはパス変数として扱い、/users/123 と /users/456 は同じエンドポイント群として認識します。

5. シーケンスを確認します。

   • リクエストの流れが、その機能にとって妥当かどうか確認します。
   • 作成後の取得、プリフライト後の実際のリクエスト、アップロード後のステータス確認、保存後の更新など、想定される後続の呼び出しを探します。
   • 必要な後続の呼び出しがない場合は、証拠が十分でない限り、確定事項ではなく問題の可能性として指摘します。

6. 代表的な詳細を調べます。

   • 失敗、低速な呼び出し、ステータスが混在するエンドポイント、および重要な成功エンドポイントを 1、2 件取得して詳細を確認します。
   • AgentCalls の場合は、モデル名、キャッシュヒット、プロンプトのプレビューも確認します。
   • 機能が正常に動作しているように見えるかを説明する際は、レスポンス本文とヘッダーを根拠として使用します。

7. 機能が適切に動作しているように見えるか判断します。

   • 正常な機能実行では通常、想定されるエンドポイントが確認でき、ステータスコードの大半が成功を示し、レイテンシが妥当で、失敗が繰り返されていません。
   • トラフィックが不完全または曖昧な場合は、そのことを明確に伝えます。

出力形式

生の JSON をそのまま出力しないでください。次のセクションで、平易な言葉による検証レポートを作成してください。

Feature Verification

Overall verdict: [Feature appears healthy / Feature appears partially successful / Feature likely failed / Inconclusive]

Traffic window: [what part of the capture you analyzed]
Sessions source: [LiveTraffic / AgentCalls]
Capture scope: [CaptureApplication used: <process name/PID> / Unscoped — all traffic analyzed]

Endpoint summary:
- METHOD HOST /normalized/path
  Calls: [N]
  Statuses: [e.g. 200 x3, 401 x1]
  Timing: [avg X ms, max Y ms]
  What happened: [plain-language summary of what this endpoint appears to do]
  Evidence: [optional header/body/status detail when useful]

- METHOD HOST /another/path
  Calls: [N]
  Statuses: [...]
  Timing: [...]
  What happened: [...]

Possible issues:
- ⚠️ [Endpoint] [Issue name] — [what looks wrong and why it matters]
- ⚠️ [Endpoint] [Issue name] — [supporting evidence]

Conclusion:
- [Short answer on whether the feature appears to work properly]

出力要件

1. 要約は生のセッション ID ではなく、エンドポイントごとにまとめます。
2. エンドポイント群ごとに、ステータスコードの分布と処理時間を記載します。
3. 使用した sessionsSource と、CaptureApplication でキャプチャ対象を絞ったかどうかを必ず記載します。
4. 明らかな問題がない場合は、分析したトラフィックに明らかな問題は検出されませんでした。 と明記します。
5. 問題がある場合は、それぞれの問題の先頭に ⚠️ を付け、問題を明確に示し、どのような問題と思われるかを説明します。
6. キャプチャが曖昧または不完全な場合は、結論が暫定的であることを伝えます。