エラーは敵ではなく道案内
エラーメッセージは、コンピュータが「ここに問題があるよ」と教えてくれる手紙です。何も言わずに止まる方が、はるかに困ります。「どの行で・どんな種類の問題が起きたか」が書かれているので、落ち着いて読むだけで原因の候補をかなり絞れます。
たとえば NameError: name 'pirnt' is not defined という英文は、「pirntという名前は定義されてないよ」という意味です。これは print をタイプミスしただけ、と気づけます。
エラーの3つの種類
①構文エラーは「文法ミス」。実行する前に出るので、行番号を見ると直しやすい種類です。②実行時エラーは「動かしたら止まる」種類。0で割り算をしたなど、途中のデータが想定と違うときに起きます。③論理エラーは見つけにくく、「動くけど答えが違う」状態。エラーメッセージは出ません。
最初に見るべき場所
エラー画面が長く見えると、全部読まなければいけない気がします。でも最初に見る場所は決まっています。Pythonなら最後の1〜3行、JavaScriptならコンソールの赤い行、HTML/CSSならブラウザの開発者ツールです。そこに、エラー名、行番号、問題の説明がまとまっています。
次に、自分が最後に変更した場所を思い出します。プログラムは、急に気まぐれで壊れるわけではありません。たいていは「直前に変えた1行」「コピーした部分」「スペルを変えた変数名」の近くに原因があります。ノートに「何を変えたら、どんなエラーが出たか」を短く残すと、同じミスを減らせます。
エラーを読む4ステップ
1〜4を順番にやると、多くのエラーは自力で原因に近づけます。あちこち同時に直すと、何が直ったかが分からなくなって余計に混乱するので、「1か所直して→動かす」を守りましょう。うまくいかなければ、直した部分を戻してから次の候補を試します。
人に聞くときのコツ
先生や友達、AIに聞くときは、「動きません」だけでは相手も困ります。質問には、やりたいこと、実際に出たエラー、試したこと、該当するコードの短い部分を入れます。たとえば「リストの合計を出したいです。line 5でTypeErrorが出ます。数字を文字列として読んでいるのかと思い、int()を試しました」のように書くと、助ける側も原因を見つけやすくなります。
この聞き方は、将来チーム開発をするときにも役立ちます。バグ報告や質問が上手な人は、技術力以上にチームを前に進められます。エラー対応は、コードを書く力だけでなく、状況を整理して伝える練習でもあります。
論理エラー（バグ）の見つけ方
動くのに答えがおかしいときは、エラーメッセージが出ません。代わりに使うのが「print文」と「最小ケース」の2つです。怪しい場所のすぐ前に print(x) を入れて、変数の中身が想定通りかを確認します。データが大きすぎる場合は、「3個だけ」「1日分だけ」のように小さくして再現させると、原因を絞り込みやすくなります。
気をつけたい落とし穴
- 赤い文字を見ずにそのままGoogleや先生に聞く。エラーメッセージが大きなヒント
- 「とりあえずあちこち直す」。何が直ったかわからなくなる。変更は1か所ずつ
- 諦めて再起動する。エラーは消えるが、原因はそのまま残っている
将来どう役立つ？
「困ったときに自分で調べて解決する」スキルは、プログラミングに限らず仕事の中心的な能力です。エラーから逃げずに読み解く経験を今のうちに積むと、社会人になっても「状況を整理して前に進める人」として信頼されやすくなります。
今日からできること
- 短いコードをわざと1か所だけ壊す
- 出たメッセージを声に出して読む
- 直したら、何が原因だったかを1行で残す
まとめ
確認 エラーが出たら最初にすることは？