network-request-auditing

ネットワークリクエストの監査

cursor-ide-browser MCP を使ってネットワークの状態を詳しく調査します。このスキルでは browser_network_requests に注目し、単に「500 があるか」だけでなく、バグ、無駄、セキュリティ上の問題を示すパターンを確認します。

仕組み

1. ブラウザーでアプリを操作し（移動、クリック、フォームの送信）、実際のリクエストを発生させます。
2. 意味のある操作の後（およびページの移動が落ち着いた後）に browser_network_requests を呼び出します。
3. 以下の基準に沿って所見を分類し、報告します。

cursor-ide-browser のワークフロールールに従ってください。構造に関わる操作の前に browser_snapshot を使います。ページを変更する操作の後は、次の操作の前に新しいスナップショットを取得してください。

監査チェックリスト

失敗

• 4xx / 5xx — メソッド、URL（パス＋クエリ）、ステータス、および UI がエラーを処理したかどうかを記載します。
• CORS またはネットワークエラー — オリジンの設定ミスや混在コンテンツが原因であることがよくあります。

パフォーマンス

• 遅いリクエスト — レイテンシーが高いリクエストにフラグを付けます（タイミングが表示される場合は、サーバー処理時間が 500 ms を超えるものなど。表示されない場合は、ウォーターフォールが異常に長いことを記載します）。
• 重複した呼び出し — 1 回のユーザー操作で同じ URL ＋ メソッドが複数回呼び出されること（React の effect や重複排除の不足が原因であることがよくあります）。
• 大きすぎるペイロード — UI が必要とするデータ量に対して、レスポンスが大きすぎるように見える場合（ページネーション、フィールド選択、圧縮を提案します）。

セキュリティとプライバシー

• URL 内の機密データ — クエリ文字列内のトークンや個人を特定できる情報（PII）。
• 認証の欠落 — 認証情報やベアラートークンを送信する必要がある API 呼び出しで、それらが送信されていない場合（隣接する認証済みの呼び出しと比較します）。

正確性

• 想定外のホスト — 機能について文書化されていないサードパーティへの呼び出し（トラッカー、意図しない情報漏えいなど）。
• プリフライトの大量発生 — OPTIONS リクエストが過剰な場合、CORS キャッシュの設定ミスや、オリジンの種類が多すぎる可能性があります。

手順

1. 新しい状態から移動を開始する — browser_navigate で対象 URL に移動します（または browser_tabs で既存のタブを使用します）。

2. 機能を操作する — API の使用を引き起こす操作を行います（フィルター、無限スクロール、フォームの保存、モーダルを開くなど）。

3. ネットワークログを取得する — ページで複数回の往復が発生する場合は、論理的な各ステップの後に browser_network_requests を呼び出します。

4. 報告する — 次のように構造化して出力します。

   • 概要の件数（失敗、低速、重複グループ）。
   • URL パターン（必ずしも秘密情報を含む完全な URL でなくてかまいません）、ステータス、カテゴリ（失敗／パフォーマンス／セキュリティ／正確性）を含む問題の表または箇条書き。
   • 推奨する次のコード変更や調査。

注意事項

• iframe の通信は同じログに表示されないことがあります。機能が iframe 内で実行される場合は、その旨を記載してください。
• 想定される API 設計と比較してください。UI が適切に処理している場合、「任意のリソースが見つからない」ことを示す 404 は正しい場合があります。
• HTTP の失敗として表面化しないエラー（200 の後の解析エラーなど）については、browser_console_messages と組み合わせてください。