この記事について
原因の見当がつかないバグに出会ったとき、未経験者ほど「怪しそうな場所を勘で1箇所ずつ確認する」やり方に頼りがちです。運が良ければ早く終わりますが、外れ続けると際限なく時間がかかります。
この記事では、勘に頼らず候補を毎回半分に絞り込む（二分探索的デバッグ）考え方と、実務でも使われている git bisect というツールを紹介します。
なぜ「勘で1箇所ずつ」は遅くなりうるのか
候補が N 箇所あるとき、勘で1箇所ずつ確認する方法は、運が悪いと N 回近くかかります（最後の1つが正解というケースもあり得るため）。
一方、候補を毎回半分に割って「疑わしい方だけ残す」を繰り返す方法（二分探索）は、最大でも log2(N) 回で必ず特定できます。
| 候補数 N | 勘で1箇所ずつ（最悪） | 半分に絞り込む（最悪） |
|---|---|---|
| 8 | 8回 | 3回（8→4→2→1） |
| 16 | 16回 | 4回 |
| 32 | 32回 | 5回 |
候補が増えるほど差が開くのが分かります。これは実測ではなく、log2(N) という数学的な性質そのものなので、条件が揃えば誰にでも当てはまります。
手順（コードの変更点を切り分ける場合）
- 疑わしい範囲（今回追加・変更した箇所）を洗い出す
- そのうち半分を一時的に無効化・コメントアウトする
- バグが再現するか確認する
- 再現する → 原因は「無効化していない残り半分」の中
- 再現しない → 原因は「今無効化した半分」の中
- 原因がある側だけを対象に、2〜3をもう一度繰り返す
- 対象が1つになったら終了
// 例: 8個の変更点があると仮定
// 1回目: 4〜8番目を一時的にコメントアウトして確認
// 2回目: 再現した側をさらに半分に
// 3回目: 最後の1点まで絞り込み
git bisect: 同じ考え方をコミット単位でやってくれるツール
「最近まで動いていたのに、いつからか壊れた」というケースでは、コードの箇所ではなくコミット単位で同じ二分探索ができます。それが git bisect です。
git bisect start
git bisect bad # 今のコミット（壊れている）を悪いと報告
git bisect good v1.2.0 # 動いていた頃のタグ/コミットを良いと報告
# → Gitが自動で中間のコミットにcheckoutしてくれる
# そのコミットで動作確認し、結果を報告する
git bisect good # または git bisect bad
# → 上記を繰り返すと、Gitが原因コミットを特定してくれる
git bisect reset # 終了して元のブランチに戻る
100個のコミットの中に原因があっても、git bisect なら最大7回程度（log2(100)≈6.6）のチェックで特定できます。手作業で1個ずつ git checkout して確認するより圧倒的に速いです。
AIに手伝ってもらうときの頼み方
二分探索の「枠組み」を渡すと、AIも的確に動いてくれます。
今日追加した変更は8箇所ある。このうちどこかにバグの原因があるはず。
まず半分（4箇所）をコメントアウトして切り分けたい。
どの4箇所を先に無効化すべきか、依存関係も踏まえて一緒に考えてほしい。
「全部見て原因を教えて」と丸投げするより、絞り込みの構造を渡した方が、AIも人間も次に何をすべきか迷いません。
まとめ
原因不明のバグは、勘で1箇所ずつ確認すると候補数に比例して時間がかかりますが、毎回半分に絞り込む二分探索的な考え方なら log2(N) 回で必ず特定できます。コードの変更点はコメントアウトで、コミット履歴は git bisect で、それぞれ同じ考え方が使えます。
※ Qiita 読者の方には易しすぎる内容なので、プログラミング未経験の知り合いへの紹介や、社内研修・後輩育成の参考としてどうぞ。
未経験から Next.js + Supabase + Claude Code で Webアプリを作って公開するまでを体系化した教材があります。
- まず無料で試す（教材体験版・最初の数セッションを無料で試せます）→ https://github.com/ayies128/next-ai-camp-trial
- 教材完全版＋月5,500円のメンタリング（全20セッション＋チャット質問し放題）→ https://menta.work/plan/20251?ref=qiita
- YouTube『AIエンジニア情報局』（AI×開発ニュースを1本5分でキャッチアップできる別運営チャンネル・無料）→ https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/?ref=qiita