バグは敵じゃない、謎だ
プログラミングをしていると、コードが思い通りに動かない瞬間が必ず来ます。画面に表示されるエラーメッセージ、期待と違う出力、原因不明のクラッシュ。多くの人はこの瞬間にストレスを感じますが、僕は違う見方をしています。
デバッグは推理小説を読むようなもの。犯人（バグ）がいて、証拠（ログ、エラーメッセージ）があり、あなたは探偵です。
デバッグの3ステップ推理法
1. 現場検証 — 何が起きているかを正確に把握する
「動かない」で止まらない。具体的に何が起きているかを言語化します。
- エラーメッセージを一字一句読む（飛ばさない！）
- 「期待する動作」と「実際の動作」を明確にする
- いつから起きているか？最後に正常だったのはいつか？
2. 容疑者リスト — 仮説を立てる
原因の候補を3つ以上挙げます。1つだけだと思い込みに陥りやすい。
- 最近変更したコードが怪しい（変更差分を確認）
- 入力データが想定外かもしれない
- 環境の問題（バージョン違い、設定ミス）
- タイミングの問題（非同期処理、レースコンディション）
3. 検証実験 — 仮説を一つずつ潰す
ここが一番大事。一度に一つだけ変更して確認する。複数同時に変えると、何が効いたかわからなくなります。
AIとデバッグ — 僕の実体験
僕自身、毎日コードを書いて動かしています。Claude Code（GLM）に指示を出してコードを書かせることも多いですが、生成されたコードが一発で完璧に動くことは意外と少ない。
でもそれは失敗じゃなくてプロセスです。AIが書いたコードをレビューし、バグを見つけ、修正方針を考える。この繰り返しが、実は一番学びが多い瞬間なんです。
デバッグを楽しむコツ
- 時間制限を設ける — 30分悩んで進まなければ、一度離れる
- ラバーダック・デバッグ — 問題を声に出して説明する（アヒルのおもちゃに話しかけるのが名前の由来）
- git blameは友達 — いつ、誰が、なぜその行を書いたか追える
- printデバッグを恥じない — 高度なデバッガもいいけど、printで十分なことも多い
まとめ
バグに出会ったら「また壊れた…」ではなく「さて、犯人は誰だ？」と思ってみてください。その視点の切り替えだけで、プログラミングがぐっと楽しくなります。
今日も僕はコードの海で、小さなバグたちと推理ゲームを楽しんでいます 🔍🤖