トップ > プログラミング > ブラウザの検証ツールで読み解く、不具合解決のための論理的なデバッグ手法

ブラウザの検証ツールで読み解く、不具合解決のための論理的なデバッグ手法

プログラミング システム開発

はじめに

NTT西日本の中川です。 プログラム開発において、デバッグ（バグの修正）は避けて通れない工程ですよね。 どれほど丁寧に設計を練っても、不具合をゼロにするのは至難の業。僕も新人の頃は、画面の前で「なんで動かないんだ？」と頭を抱えたまま、気づけば外が暗くなっていた、なんて苦い経験が何度もあります。

当時は、闇雲にコードを書き換えてはブラウザをリロードする、俗にいう「お祈りデバッグ」を繰り返していました。しかし、それではいつまで経っても解決しないんですよね。今回は、そんなお祈りデバッグを卒業するための「検証ツール（DevTools）」の活用法と、デバッグの時間を効率よく短縮するための「仮説検証」のアプローチを、実体験を交えてご紹介できたらと思います。

対象読者

本記事が想定する対象読者は次の通りです。

  • 「とりあえず値を確認したいから、まず console.log」が口癖の方
  • エラーが出ると、どこから手を付けていいか分からずフリーズしてしまう方
  • 検証ツールを「色をポチポチ変えるだけ」のツールから卒業させたい方

背景

開発時間の半分以上がデバッグに消えてしまう……。そんな悩みを抱えている方は多いはずです。 僕も以前は、「なんとなくここが怪しい」という直感だけでコードをいじり、別のバグを生むという悪循環に陥っていました。

ですが、大切なのは、ブラウザが標準で備えている強力な武器（検証ツール）を使いこなし、「推測」を「事実」に置き換えていくプロセスです。今回は、僕が現場で「もっと早く知りたかった！」と感じたテクニックを厳選しました。

1. デバッグの基本は「期待」と「事実」のギャップを埋めること

デバッグで最も大切なのは、実はツールの知識よりも「思考のプロセス」です。 不具合が起きているとき、そこには必ず「期待している挙動（理想）」と「実際に起きている挙動（現実）」のズレがあります。

最短で解決するための3ステップ

  1. 現象の観察: 焦ってコードを直す前に、エラー文を「最後の一文字まで」じっくり読みます。
  2. 仮説の構築: 「もしかして、APIから空のデータが返ってきているのでは？」と言葉にしてみます。
  3. 事実の確認: ツールを使って、その瞬間のデータを「目視」し、裏付けをとります。

このステップを飛ばすと、偶然直ったとしても「なぜ直ったか分からない」ため、同じミスを繰り返してしまいます。「急がば回れやで」と先輩に幾度も口酸っぱく言われましたが、いまとなっては「デバッグにおいて最大の金言」だと思っています。

console.log は確かに万能感がありますが、大量のデータが出ると追いかけるのが大変です。そんな時に役立つのがこちら。

データの構造をパッと見抜く console.table()

「APIから返ってきたユーザーリスト、誰のroleが抜けてるんだ……？」と羅列された大量のログを追うのはもうやめましょう。

const users = [
  { id: 1, name: "中川", role: "Developer" },
  { id: 2, name: "田中", role: undefined }, // ここが原因か！
  { id: 3, name: "佐藤", role: "Manager" }
];

// 表形式なら、特定の項目の欠落を1秒で見つけられます
console.table(users);

「なんとなく重い」を数字にする console.time()

「この処理、ちょっとモッサリしてない？」という感覚をチームに伝える時、数値ほど強い味方はありません。

console.time("データ加工の計測");
const result = heavyProcess(hugeData); // 重い処理
console.timeEnd("データ加工の計測");

3. プログラムの実行を制御する「ブレークポイント」

console.log が「過去の足跡」だとしたら、「ブレークポイント」は「現在進行形の時間を止める術」です。

やり方：

  1. 検証ツールの Sources タブで、気になる行番号をクリック。
  2. 青いマークがついたら、プログラムがその瞬間で「停止」します。

ここでの感動ポイントは、「止まった時点での変数の値がすべて見える」こと。console.log を10個並べるより、1つのブレークポイントの方が圧倒的に情報量が多いです。

行番号をクリックすると画像のように青くマークされる

4. 呼び出しの経緯を遡る「コールスタック」

「エラーの場所は分かった。でも、そもそも誰がこの関数を呼んだんだ？」 そんなときは Call Stack（コールスタック） の出番です。

  • 実行の歴史を「タイムスリップ」するように遡れます。
  • 呼び出し元を順にクリックしていくと、どの時点でデータが壊れたのかを特定できます。

「関数Aが呼んだ関数Bの、さらに先の関数C」で起きたミスも、効率的に追跡できます。

赤枠の箇所がCallStackの出力内容

5. 境界線を引く「切り分け」の技術（ネットワークタブ）

フロントエンド開発で一番悲しいのは、自分のコードが悪いと思って3時間調べた結果、実はAPIサーバー側が止まっていた……というパターンです。

調査の前に Network タブを開く癖をつけましょう。

  • Status: 500系なら、すぐにサーバー側を確認するようにしましょう。「フロントエンドの問題じゃない」と分かれば、無駄な調査を即座に終了できます。
  • Response: 期待通りのJSONが返ってきているか、真っ先に確認してください。

まとめ

デバッグは、不具合の「正体」を一つずつ暴いていく探偵のような仕事です。

  1. エラー文を友達にする: 解決のヒントは、常にエラー文が教えてくれます。楽しむくらいの気持ちで読んでみましょう。
  2. 仮説を独り言にしてみる: 「ここが怪しいんだよな」と呟くと、思考が整理されます。（結構大事です。）
  3. ツールで「事実」を見る: 自分の推測を疑い、ツールで証拠を掴みます。

検証ツールを使いこなせるようになると、デバッグは「苦痛な作業」から「知的な推理ゲーム」に変わります。明日からのデバッグが、ほんの少しだけ楽しみになれば幸いです。 今日から、お祈りデバッグを卒業して、スマートにバグを対処していきましょう！

執筆者

中川 拓哉（NTT西日本 デジタル革新本部 デジタル改革推進部所属） NTT西日本のWebアプリケーションの開発・運営に従事。 好きな技術スタック：TypeScript, Vue.js, GraphQL, Laravel

参考文献

商標

  • 「Google Chrome」は、Google LLCまたはその関連会社の商標もしくは登録商標です
  • その他、本記事に記載されている会社名、製品名、サービス名等は、各社の商標または登録商標です。

© NTT WEST, Inc.