DevToolsを「証拠収集」の道具にする
「再現できません」で止まる前に、証拠を残す
バグ報告のやり取りで一番時間を溶かすのは、実装のミスそのものより「再現できない」の往復です。報告者はもう一度同じ操作をしてくれるとは限らず、再現できた頃には状態が変わっていることも多いのです。この構造を変える方法は一つで、気づいた瞬間に DevTools で証拠を残すことです。デバッグのために開くのではなく、あとで自分や他の開発者が読める形で「その時に何が起きていたか」を保存する道具として使います。
Console — エラーの発生順を保存する
Console パネルは開いている間のログしか見えません。閉じたら消えます。バグに気づいたら、まず以下を行ってから操作を続けてください。
- Console 右上の歯車から
Preserve logを有効にする(ページ遷移してもログが消えなくなる) - 再現後、ログ全体を右クリック →
Save as...でファイルに書き出す - スタックトレースは折りたたまずに展開したままキャプチャする(折りたたんだ状態のスクリーンショットは原因究明に使えない)
ポイントは「エラーが出た」ではなく「どの順番で何が出たか」です。1つ目のエラーが原因で2つ目が誘発されているケースは珍しくありません。
Network — HAR エクスポートで通信の全体像を残す
UI のバグに見えて、実は API 側の異常だったというケースは実務でよくあります。Network パネルは Export HAR でリクエスト・レスポンス・タイミングをまるごとファイルに落とせます。
見るべき3点
- ステータスコード(200 系以外が混ざっていないか)
- レスポンスタイム(タイムアウト間際の遅延がないか)
- 直近のリクエスト履歴(バグに気づく数分前まで遡る)
ある報告では、「カンバンのドラッグ&ドロップでステータスが変更できない」という UI 不具合として上がってきました。しかし自動収集されたネットワークログを見ると、報告の約1分前に別 API への通信が2回連続でエラーを返していたことが分かりました。原因は D&D の実装ではなく、その直前に起きた一時的な API 障害でした。UI 側は無関係で、障害の復旧後は正常に動作していました。もしこのログが手動収集に頼っていたら、報告者は「D&D が壊れている」としか書けず、開発者は存在しない UI バグを探し続けていたはずです。
Application — 状態を疑うときに見る場所
「特定のユーザーだけ再現する」系のバグは、多くの場合ローカルの状態に原因があります。
- Local Storage / Session Storage の該当キーの値をコピーしておく
- Cookie の有効期限・SameSite 属性を確認する(ログイン絡みのバグで特に重要)
- Service Worker のキャッシュが古いバージョンを配っていないか(
Application > Service Workersで Update を試す)
条件付きブレークポイントで「毎回は起きない」を捕まえる
再現率が低いバグは、無条件のブレークポイントで止め続けても徒労に終わります。Sources パネルで該当行を右クリックし、Add conditional breakpoint から条件式(例: items.length === 0)を入れると、その条件が成立した時だけ止まります。さらにコードを止めずにログだけ出したい場合は Logpoint を使うと、本番相当の操作フローを崩さずに値を追えます。
Bugoon での実践
Bugoon のウィジェットは、バグ報告を送信する際に直前の Console ログとネットワークエラーを自動で添付します(error-collector.ts)。上で紹介した「証拠を残す」作業のうち、Console の Preserve log や Network の異常検知に相当する部分は、報告者が意識しなくても最初から報告に含まれる形になっています。開発者は再現手順を待たずに、報告が届いた時点で一次情報から調査を始められます。DevTools を自分の手で使いこなす技術と、それを自動化して非エンジニアの報告にも同じ質を持たせる発想は、同じ問題意識の延長線上にあります。