デバッグの心構え
バグを見つけて直すための科学的なやり方
⏱ 想定 ~8 分
01 · 読む
コードは壊れます。どのエンジニアのコードも壊れます。初心者とプロの差は、プロがバグのないコードを書くことではなく、 体系的にバグを見つけて直す方法を知っていること です。
デバッグはランダムな試行錯誤ではありません。あちこちを変えて「うまくいけ」と祈ることでもありません。科学的な手法です：観察、仮説、検証、結論。
デバッグの魔法使いのように見えるエンジニアは、頭がいいわけではありません —— 慌てる代わりに手順を踏んでいるだけです。
💡 想像してみてくださいデバッグは探偵の仕事に似ています。事件（バグ）が起こる。証拠（エラーメッセージ、ログ）を集め、仮説（推論）を立て、検証（一度に 1 つだけ変える）して、解決するか新しい仮説に進む。当てずっぽうで誰かを連行したりはしません。
02 · ステップ解説
デバッグの流れ —— バグに出会うたびにこの手順で進めましょう
1. REPRODUCE （再現）
バグを安定して再現できますか？ランダムなら、タイミングや状態の問題を疑います。再現できないと自信を持って直せません。バグを発生させる正確な手順を書き留めましょう。
2. ISOLATE （切り分け）
正確にどこが壊れていますか？特定のファイル、関数、行まで絞り込みます。 console.log やエラーメッセージで場所を特定しましょう。調査範囲が狭いほど、原因は早く見つかります。
3. HYPOTHESIZE （仮説）
原因は何だと思いますか？何かを変える前に仮説を立てましょう。「配列が空のときに index 0 にアクセスしているからじゃないか」 —— 仮説があると調査がぶれません。
4. TEST （検証）
仮説を確かめるために、変えるのは 1 つだけ にしましょう。同時に複数変えると、バグが消えても何が効いたか分かりません。この規律が、後で何時間も節約してくれます。
5. FIX （修正）
分かったことに基づいて修正します。良い修正は症状ではなく根本原因に向き合います。配列が空のときにユーザーがクラッシュするなら、エラーを隠さず、空配列を正しく扱いましょう。
6. VERIFY （検証）
元のバグはまだ起きますか？他に壊したものはありませんか？修正を確認したうえで、周辺もテストします。新しいバグを生む修正は、本当の修正ではありません。
03 · 読む
実際に流れを当てはめてみましょう。バグありの app を引き継ぎました —— 訪問者カウント API です。ユーザーが /api/stats エンドポイントを叩くとクラッシュします。あなたの仕事：デバッグの流れに沿ってバグを見つけることです。
04 · ターミナル演習
ステップ 1: REPRODUCE —— エラーログを読んで、何が起きたか把握します。エラーメッセージは最良の友達です。何が、どこで起きたかをだいたい正確に教えてくれます。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
05 · ターミナル演習
ステップ 2: ISOLATE —— エラーは count が 7 行目で undefined だと指しています。その値は getVisitorCount() から来ています。コードを読んで、関数のどこで壊れているか探しましょう。
（このセクションはインタラクティブです — JavaScript を有効にしてください。）
06 · 読む
次のデバッグの黄金ルールは、後々あなたを何時間も救ってくれます。必要ならモニタに貼っておきましょう。
ポイントまとめ
- 一度に複数のことを変えない —— 何が効いたか分からなくなります
- エラーメッセージを読む —— 何が、どこで、をたいてい教えてくれます
- エラーを信じる、バグの位置についての自分の思い込みを信じない
- どのエンジニアもデバッグはします。シニアはより体系的にやるだけです。
07 · 空欄補充
デバッグの第一歩は、バグを安定して _____ することです。
08 · クイズ
デバッグの 第一歩 は？
- バグを安定して再現する
- コードを変えて祈る
- Claude に直してもらう
- ファイルを消してやり直す
⚠ 全機能のインタラクティブ体験には JavaScript が必要です。JavaScript を有効にして再読み込みしてください。
※ このサイトは独立した教育プロジェクトで、Anthropic の公式製品ではありません。Claude™ は Anthropic, PBC の商標です。