デバッグの技法

デバッグは「推理」である

デバッグとは、プログラムの不具合（バグ）の原因を突き止めて直す作業です。経験の浅いうちは、当てずっぽうにコードをあちこち書き換えがちですが、それでは運任せで、たまたま直ってもなぜ直ったのか分からないまま終わってしまいます。

デバッグの本質は、事実を集めて仮説を立て、検証で絞り込む推理です。

• 観察 — エラーメッセージ、症状、再現条件といった事実を集めます。
• 仮説 — 「この変数が想定外の値では」と原因の候補を立てます。
• 検証 — ログやデバッガで仮説が正しいかを確かめます。
• 修正と確認 — 直したうえで、確かに直ったことを確認します。

この章では、闇雲な試行錯誤から抜け出すための、実践的な進め方と道具を紹介します。

まず確実に「再現」する

すべての出発点は再現です。「どういう操作・入力をすると、確実にその不具合が起きるか」を特定できなければ、原因も追えず、直したかどうかの確認もできません。

• 手順を固定する — どの入力・状態・環境で起きるかを書き出します。
• 最小化する — 不具合に関係ない要素を削り、再現に必要な最小の条件まで絞ります。
• 環境差を疑う — 「自分の環境では再現しない」場合、OS・データ・設定の違いが手がかりです。

最小の再現条件まで削れれば、それ自体が原因を強く示唆します。逆に、たまにしか起きない不具合（競合状態や未初期化など）は、再現の難しさそのものが問題の性質を物語っています。

二分探索で範囲を絞る

原因がコードのどこにあるか見当がつかないとき、強力なのが二分探索の発想です。疑わしい範囲を半分に割って、どちら側に問題があるかを確かめるのを繰り返し、一気に範囲を狭めます。

不具合は処理 A〜H のどこかにある（8工程）

A B C D | E F G H   ← 中間（Dの後）の状態を確認
        ↑ ここまで正常なら、原因は E〜H 側に限定
E F | G H           ← さらに半分に
    ↑ ここが正常なら、原因は G〜H 側

8カ所でも、半分に割り続ければわずか3回ほどの確認で原因箇所にたどり着けます。この考え方は、コード内だけでなく、変更履歴に対しても使えます。

手法	何を半分に割るか	使う場面
コード内の二分探索	処理の流れ・行範囲	どの工程で値が壊れるか
git bisect	コミット履歴	いつから壊れたか（退行）

「昨日まで動いていたのに壊れた」場合は、git bisect で正常なコミットと壊れたコミットの間を二分探索すれば、原因のコミットを機械的に特定できます。

ログ・デバッガ・ラバーダック

仮説を検証する道具は、状況に応じて使い分けます。それぞれ得意な場面が違います。

手法	仕組み	向く場面
ログ出力（print デバッグ）	値や通過を出力して観察	手軽な確認・本番環境・非同期や並行処理
デバッガ	実行を止めて状態を逐次調べる	複雑な状態・呼び出し経路を追う
ラバーダック	他者（や人形）に声で説明する	思い込みに自分で気づく

ログ出力は、要所に値を出して「どこで何がおかしくなるか」を観察する、最も手軽で普遍的な方法です。一方デバッガは、ブレークポイントで実行を一時停止し、変数の中身を覗いたり1行ずつ進めたりできるため、複雑な状態変化を精密に追えます。

// ログデバッグ：値が想定通りか節目ごとに出す
function calc(items) {
  console.log('入力:', items);
  const total = items.reduce((a, b) => a + b.price, 0);
  console.log('合計:', total);   // ここで NaN なら price が壊れている
  return total;
}

思い込みを疑う

行き詰まるバグの多くは、技術ではなく思い込みが原因です。「ここは絶対正しいはず」と検証を飛ばした箇所に、真因が潜んでいます。

• 「動いているはず」を確かめる — 呼ばれているか、値は入っているかを、推測せず実際に出力して確認します。
• エラーメッセージを軽視しない — 行番号やスタックトレースは原因への最短の手がかりです。最後まで読みます。
• 一度に一つだけ変える — 複数を同時に変えると、何が効いたか分からなくなります。
• 直したら必ず再現確認 — 直った"つもり"を、再現手順を再実行して確かめます。

まとめ

デバッグは当てずっぽうではなく、事実から仮説を立てて検証する推理です。すべての起点は確実な再現で、これがあって初めて原因調査と修正確認が成り立ちます。原因の所在は二分探索で半分ずつ絞り込み（履歴なら git bisect）、ログ・デバッガ・ラバーダックを場面に応じて使い分けます。そして最大の敵は技術的難しさよりも思い込みです。「正しいはず」を事実で確かめ、一度に一つずつ変える——この規律が、最短で原因にたどり着く道です。