前回の続き——再現できたら、中をのぞく
前回のP-08では、環境・入力・手順・期待結果・実際の結果という再現条件の5点セットで、不具合を確実に起こせる状態にしました。再現できれば、次は原因をのぞく番です。この講義は、P-02で区別したデバッグ、つまり原因を特定する活動で使う3つの道具を配ります。ログ・スタックトレース・デバッガ。名前は難しそうに見えますが、見えるものが違うだけです。
このスライドのポイント
- P-08: 再現条件の5点セットで、不具合を「必ず起きる」状態にした
- 再現できたら、次は「なぜ起きるか」をのぞく段階
- この講義の役割: P-02のデバッグ（原因の特定）で使う3つの道具を配る
3つの道具の定義
3つの道具を定義します。ログは、実行中の記録です。J-08では書く側を学びましたが、今回は読む側に回ります。いつ・どこで・何が起きたかが、時系列で残ります。スタックトレースは、エラーが起きた瞬間の関数の呼び出し経路です。E-07で学んだ関数が、どこから呼ばれてここに至ったかの連鎖で、A-07のエラー原文に付いてきます。デバッガは、実行を一時停止して、その瞬間の変数の中身を見る道具です。動いているものを止めて、内部をのぞきます。
このスライドのポイント
- ログ＝実行中の記録（J-08で書いた側→今回は読む側）。いつ・どこで・何が起きたの時系列
- スタックトレース＝エラー発生時の関数（E-07）の呼び出し経路。エラー原文（A-07）に付いてくる
- デバッガ＝実行を一時停止して、その瞬間の変数（E-03）の中身を見る道具
なぜ必要か——長い英文に圧倒されないために
これを知らないと、エラー画面に出る長い英文、つまりスタックトレースに圧倒されて、ただ全部コピーして貼るだけになりがちです。A-07で学んだとおり、原文をそのままAIに渡すのは正しい行動です。ただ、自分でも先頭の数行から「どこで起きたか」を読めると、原因の切り分けが格段に速くなります。また、3つの道具で見えるものを区別できないと、状況に合わない道具を選んで遠回りしてしまいます。
このスライドのポイント
- 知らないと: エラー画面の長い英文（スタックトレース）に圧倒され、全部コピーして貼るだけになる
- コピペはA-07的には正解。ただし先頭数行から場所を読めると切り分けが速い
- 道具の見えるものを区別できないと、状況に合わない道具を選んで遠回りする
知りたいことで道具を選ぶ
3つの道具は、知りたいことで選び分けます。処理の流れや時系列の記録を追いたいなら、ログです。どこでエラーが起き、そこへどう呼ばれてきたかを知りたいなら、スタックトレースです。止まった瞬間に変数へ何が入っていたかを見たいなら、デバッガです。同じ不具合でも、知りたいことが変われば手に取る道具が変わります。まずはこの対応を頭に入れてください。
スタックトレースを上から読む
スタックトレースの読み方を実演します。まず、いちばん上の行を読みます。ここにはエラーの種類とメッセージが書かれ、「何が起きたか」がわかります。次に上から順に下りていき、自分が書いたコードのファイル名が最初に出てくる行を探します。そこが、まず疑うべき場所です。下のほうには、F-08で学んだ依存、つまり他人が書いたコードのファイルが並びますが、そこはたいてい無実です。上から読む、そして自分のコードの行を探す。この2つだけ覚えてください。
このスライドのポイント
- いちばん上の行＝エラーの種類とメッセージ（何が起きたか）
- 上から読み、自分のコードのファイル名が最初に出る行＝まず見る場所
- 下のほうの他人のコード（依存＝F-08）は、たいてい無実
技術サンプル: スタックトレースを読む
技術サンプルは、種別はログ、なかでもスタックトレースです。目的は、エラーの発生場所と呼び出し経路を読むこと。サンプルは、合計金額の計算に失敗したときの6行です。1行目のエラー行が、何が起きたかを示します。続く行を上から見ると、最初に自分のファイル名が出るのはexpense.jsの12行目で、ここがまず見る場所です。下のnode_modulesは依存で、たいてい無実です。上から読み、自分のコードの行を探す。この読み方は、AIにも確かめてもらえます。
このスライドのポイント
- 種別: log（スタックトレース）
- 目的: エラーの発生場所と呼び出し経路を読む
- サンプル本体:
混同しやすい——ログとデバッガ
混同しやすいのが、ログとデバッガです。ログは流れの記録で、常に残り、後から読めます。デバッガは、実行を止めたその瞬間の静止画で、変数の中身をその場で見ます。使い分けの目安はこうです。P-08で再現できるようにした不具合は、止めて中を見られるデバッガが向きます。反対に、たまにしか起きず再現しづらい不具合は、常時残るログのほうが手がかりになります。再現できるかどうかで、手に取る道具が変わります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。J-08で、エラーを握りつぶさずログに残すと決めました。そのログが、ここで自分を助けます。原因が絞れないときは、AIに「この処理の入口と出口にログを足してください」と頼むのが正攻法です。これは、E-03で学んだ、変数を途中で表示して確かめるやり方の本格版です。AIへの質問例はこうです。「このスタックトレースとログから、最初に確認すべき箇所を教えてください」。
このスライドのポイント
- J-08で「握りつぶし禁止」と決めたログが、ここで自分を助ける
- 「この処理の入口と出口にログを足して」はE-03の途中表示の本格版
- 原因をAIに尋ねるときは、スタックトレースとログを一緒に渡すと精度が上がる
まとめと次回
最後に一問一答です。エラーの発生場所と、そこへ至る呼び出し経路を示す道具は何でしょうか。……答えは、スタックトレースです。30秒まとめです。ログは流れの記録、スタックトレースはエラーの場所と経路、デバッガはその瞬間の変数の中身。スタックトレースは上から読み、自分のコードの行を探すのでした。次回はカテゴリP最終回、どの層が原因かを絞る原因切り分けへ進みます。関連資料は「エラー文の読み方」「ログ設計入門」「エラー解決プロンプト50」です。
このスライドのポイント
- 一問一答: エラーの発生場所と呼び出し経路を示すのは？
- 30秒まとめ: ログ＝流れの記録／スタックトレース＝場所と経路（上から読む）／デバッガ＝瞬間の変数
- 次回: P-10 原因切り分け（カテゴリP最終回）
- 関連資料: 「エラー文の読み方」「ログ設計入門」「エラー解決プロンプト50」
