HARファイル入門：実運用で役立つ取り扱いガイド
HARとは、ブラウザやツールが記録したHTTP通信の時系列ログ(JSON)である。
HARファイルはなにものか
HAR(HTTP Archive)は、Webページを読み込む際のリクエストとレスポンスの履歴を、時系列にまとめたJSONファイルです。拡張子は .har。各エントリには以下のような情報が入ります。
- リクエスト: メソッド、URL、クエリ、ヘッダー、Cookie、ボディ
- レスポンス: ステータス、ヘッダー、ボディ(必要に応じてテキストやbase64)、MIMEタイプ
- タイミング: DNS、接続、SSL、送信、待機(TTFB)、受信などのミリ秒単位の内訳
- キャッシュ情報: 事前・事後のキャッシュ状態
- ネットワーク情報: HTTPバージョン、リダイレクトチェーン、転送サイズ など
ポイントは「ページ表示時に発生する多数のHTTP処理を1つのファイルで再現・共有できる」こと。画面キャプチャでは追えない、ヘッダーや通信の順序・遅延の実態まで持ち出せます。
使い道: こういう時にHARが効く
- 不具合の再現共有: フロントとバックエンドの境界で起きるエラー(4xx/5xx、CORS、認証周り)を、チーム間で同じ材料として共有できる。
- パフォーマンス解析: TTFBや受信時間が長いのか、DNSやSSL確立に時間を食っているのかを切り分けられる。
- APIデバッグ: リクエストボディ・ヘッダー・レスポンスを一括で見直せるため、環境差や条件分岐の影響を特定しやすい。
- キャッシュ/ CDN検証: Cache-ControlやETag、Ageなどのヘッダーから、キャッシュヒット状況や再検証の挙動を確認。
- リソース依存関係の把握: ウォーターフォールでどのリソースがブロッキングになっているかを抽出。
- 回帰検出: 前回のHARと比較して、応答時間やサイズがどれだけ変わったかを差分でチェック。
取得方法(ブラウザ/自動化)
Chrome/Edge/Firefox
- DevToolsのNetworkタブを開く
- 必要ならPreserve logとDisable cacheをオン
- 問題の操作を再現して通信を記録
- 任意のリクエストで右クリック → Save all as HAR(With content を選べる環境なら推奨)
Safari
- WebインスペクタのNetworkパネルから同様にエクスポート可能
プロキシ系
- mitmproxyやFiddlerなどのHTTPプロキシでトレースし、HARに変換して扱う方法もある
自動テスト/ヘッドレス
- PlaywrightやPuppeteerは、シナリオ実行中のネットワークをHAR出力できる。CIでの回帰監視に便利。
解析のコツ(読み方)
-
timingsを見る
- dns/connect/ssl/send/wait/receiveのどこが支配的かを特定。waitが長い=サーバ側処理が重い、dnsやconnectが長い=ネットワーク/名前解決の問題、など。
-
サイズの解釈
- headersSizeやbodySizeは転送実サイズ、content.sizeはデコード後のサイズを表すことがある。圧縮やチャンクで数値が一致しないのは正常。
-
HTTPバージョン/プロトコル
- httpVersionにh2やhttp/1.1などが載る。並列性やヘッダー圧縮の効果を推測する材料に。
-
キャッシュ
- cacheオブジェクトやレスポンスヘッダーから、再検証(304)や期限切れ、変則なキャッシュ制御を把握。
-
リダイレクトチェーン
- 余計なジャンプが発生していないか、ステータスコードとLocationを追跡。
共有時の注意(セキュリティ/プライバシー)
- HARにはCookieやAuthorizationヘッダー、個人情報、フォーム入力が含まれる場合がある。
- 社外共有や外部ツールへアップロードする前に、必ずマスキング/削除する。最小限の再現に必要な範囲に絞る。
- 社内でもアクセス権を分け、保存期間を決める。不要になったHARは速やかに破棄。
HARと他手段の比較(同じ階層の比較)
| 手段 | 可視化の粒度 | ペイロード本文 | 暗号化越し(HTTPS) | 取得の手軽さ | 代表ユースケース |
|---|---|---|---|---|---|
| HAR | HTTPレベルの時系列(ウォーターフォール) | 取得可(With content) | 可(ブラウザが復号後に記録) | かんたん(DevTools) | バグ再現共有、性能解析 |
| PCAP | パケットレベル | 通常不可(TLSで不可視) | 難(鍵が無ければ内容不可視) | 中〜難(外部ツール) | 低レベルのネットワーク調査 |
| Chrome NetLog | ブラウザ内部のネットワークリログ | 部分的 | 可 | 中(専用手順) | コネクション管理/ソケット問題の深掘り |
| cURL trace | 単発HTTPの詳細ログ | 一部可 | 可 | かんたん(CLI) | 単体APIの挙動確認 |
| mitmproxy flow | HTTP/HTTPSプロキシ経由の詳細 | 取得可 | 可(プロキシで復号) | 中(証明書設定が必要) | モバイル含む広範なプロキシ調査 |
よくある落とし穴と対処
- 保存タイミング: 画面遷移後に保存すると、直前のPOSTボディが消えることがある。Preserve logを有効化し、再現前に記録開始。
- キャッシュの影響: Disable cacheをオンにしないと、サーバ未到達で200が出るなど原因特定を誤る。
- 機密漏えい: 生HARをそのまま課題管理に添付しない。最低限、Cookieと認証ヘッダーは削除。
- 巨大化: SPAで数万リクエストになることがある。フィルタで対象ドメインやパスに絞って再取得。
すぐ使えるミニチェックリスト
- 再現手順を簡潔にメモし、記録前にDevToolsを準備(Preserve/Disable cache)
- Save as HAR with contentで必要な本文を含める
- 問題の時間帯/URL/ユーザー影響を記載
- 機密情報をマスクし、保存先/共有範囲を限定
- ボトルネック(例: wait>dns+connect)の仮説を1行で添える
実務では、まずHARで何がいつ遅れた(失敗した)かを押さえ、必要に応じてNetLogやPCAPへ深掘り、という二段構えが効率的です。