プログラミングエラーが解けない時に効く3つの調べ方
画像出典: Daniil Komov / Pexels
エラーが解決できない原因の多くは、どこで壊れているかを特定しないまま調べ始めることにあります。処理の途中で変数の値を出力して動いている範囲を切り分け、エラーメッセージを一字一句そのまま（必要ならダブルクォーテーションで囲んで）検索し、AIには「答えだけ」でなく原因の説明と自分の仮説への意見を求めます。この順番を守るだけで、詰まる時間は大きく短くなります。
独学でプログラミングを続けていると、コードを書く時間よりエラーとにらめっこしている時間のほうが長い日があります。しかも参考書や動画は「正しく動いたあと」の話が中心で、動かなかったときの進め方はあまり教えてくれません。
正直なところ、詰まる時間の長さは実力よりも手順を持っているかどうかで決まります。エラーは「あなたが失敗した通知」ではなく、コンピュータが残してくれた手がかりです。ここでは、その手がかりの読み方から、検索・AIの使い方までを順番に並べていきます。
エラーが解決できないのはなぜ？
解決できないときに起きているのは、たいてい同じことです。どこが壊れているか分からないまま、全体を眺めて悩んでいる。コードが50行あれば、原因の候補も50行分あります。その状態でいくら見つめても、当たりを引くのは運任せです。
逆に「30行目までは想定どおりの値が入っている」と分かれば、疑う範囲は一気に狭まります。調べ物の効率は、検索のうまさより先に、疑う範囲の狭さで決まります。
もうひとつよくあるのが、エラーメッセージを読まずに閉じてしまうことです。メッセージには「何が起きたか（エラーの種類）」「どのファイルの何行目か」「どの処理から呼ばれたか」が書かれています。英語だからと飛ばしてしまうと、いちばん濃いヒントを自分から捨てることになります。
原因の切り分けはどうやる？
複雑なプログラムでエラーが出たときの基本手順は、処理の前後に変数の値を出力する処理を挟み、どこまでは正しく動いているかを確かめていくことです。ログ出力でも、Pythonのprintのような単純な出力でも構いません。
- エラーメッセージを最後まで読む種類・ファイル名・行番号を書き写します。手を動かす前に、この3点だけはメモに残します。
- 怪しい処理の直前で値を出す「ここまで来ているか」「その時点で変数に何が入っているか」を出力します。想定と違う値が出た地点が犯行現場です。
- 範囲を半分ずつ狭める前半が正常なら後半、後半が正常なら前半へ。数回繰り返せば数行まで絞り込めます。
- 最小の再現コードを作る関係ない処理を削り、エラーだけが再現する短いコードにします。この作業の途中で原因に気づくことも多いです。
- そこで初めて調べる絞り込んだ状態で検索やAIに向かうと、返ってくる答えの精度が変わります。
- ファイルを保存したか／実行したのは編集中のファイルか
- スペルミス・全角スペース・閉じ忘れの括弧がないか
- ライブラリのインストール先と実行環境が同じか
- 昨日まで動いていたなら、直前に変更した箇所は何か
拍子抜けするような内容ですが、独学で長時間詰まるエラーの相当数はこの範囲に収まります。難しい原因を疑う前に、まず安いところから潰すのが結果的に速い進み方です。
エラーメッセージはどう検索する？
検索で成果が変わる分かれ目は、エラーの「種類」ではなく「メッセージそのもの」をそのまま検索することです。「Python error」ではなく「ZeroDivisionError: division by zero」のように、表示された文言をそのまま検索窓へ貼ります。ダブルクォーテーションで囲めば完全一致検索になり、同じ問題に当たった人の投稿へたどり着きやすくなります。
このとき、自分の環境固有の情報（ユーザー名を含むファイルパス、自分で付けた変数名など）は検索語から外します。世界中で共通して出る部分だけを残すのがコツです。この線引きに迷ったら、貼ろうとしている文字列を一語ずつ見て「これは自分のパソコンの中にしか存在しない言葉か」を問うだけで、消すべき部分はほぼ判別できます。
それでも見つからないときは、Q&Aサイトを使う手があります。Stack OverflowやTeratailのような場では、再現手順・実行環境・すでに試したことを整理して書くほど回答が付きやすくなります。この3点は切り分けの過程でそのまま手元に残っているはずなので、順番どおり進めていれば質問文はほぼ書けています。
AIにはどう聞けば学びになる？
エラーメッセージを貼って解決策だけを受け取る使い方は、独学の場面ではあまり勧められていません。動くコードは手に入っても、なぜ壊れていたのかが自分の中に残らないためです。学習効果を高めるのは、エラーの内容と原因をAIに説明させる使い方と、自分の仮説を先に伝えて別の視点をもらう「仮説検証型」の使い方だとされています。
具体的には、聞き方をこう組み替えます。
| 惜しい聞き方 | このエラーを直してください（＋コード全文） |
|---|---|
| 理解が残る聞き方 | このエラーは何が起きている状態か説明してください。私は◯行目の変数がNoneになっているのが原因だと考えていますが、他に考えられる原因はありますか |
上の表の後者では、AIの答えが自分の仮説と合っているかを確かめる形になります。合っていれば理解が裏づけられ、外れていれば「自分の読み方のどこがずれていたか」が分かる。どちらに転んでも次に活きます。
あわせて、AIは常に正しい答えを返すとは限らない点も忘れないでください。提示された修正をそのまま貼り付ける前に、その修正が何を変えるのかを一文で説明できるかを自分に問うと、鵜呑みを防げます。説明できないなら、もう一段掘り下げて質問する合図です。
締め切り直前のトラブル対応や、業務で今すぐ復旧が必要な場面では、原因を理解する前に既知の対処法を当てるほうが正しいこともあります。ここで紹介した手順は、学習の途中で時間を投資できるときの進め方です。学生の長期休暇や社会人の週末のように、まとまった時間が取れる日に「切り分けの練習」として意識的にやってみると身につきやすくなります。
エラーを学習の材料に変えるには？
エラーを失敗ではなく手がかりとして扱い、記録しながら進める考え方は「エラーログ駆動開発」とも呼ばれます。難しい仕組みは必要なく、テキストファイルを1つ用意して、詰まるたびに3行だけ書き足せば十分です。
- 出たメッセージ（先頭の1行をそのまま）
- 原因（どこで、何が想定と違ったか）
- 対処（何を変えたら直ったか）
同じエラーに2回目で出会ったとき、この3行があれば数分で片が付きます。さらに10件、20件とたまってくると、自分がどの種類のミスを繰り返しやすいかが見えてきます。詰まった時間は、記録して初めて次の速さに変わります。
この3行がもうひとつ効くのは、AIへの質問文をそのまま用意できることです。メッセージと自分の仮説（原因の欄）が並んでいれば、前の章の「理解が残る聞き方」はコピーするだけで組み立てられます。切り分け・検索・AIがばらばらの技術ではなく、記録を真ん中に置いた一本の流れになるのがこのやり方の効きどころです。
時間の使い方も現実に合わせて構いません。平日の可処分時間が1時間ほどの社会人なら、切り分けまでを平日に済ませ、調べ物と記録を週末にまとめる。授業の合間にまとまった時間が取れる学生なら、最小再現コードを作るところまで一気に進める。どちらでも、順番さえ守れば結果は同じところへ着きます。
エラーは独学をやめる理由ではなく、通り道です。次に赤い文字が出たら、まず「どこまでは動いているか」から。それだけで、今までとは違う場所に立てます。
よくある質問
エラーメッセージが英語で読めないときはどうすればいいですか
まずエラーの種類（先頭の単語）、ファイル名、行番号の3点だけを拾えば十分です。この3点で場所と種類が特定でき、残りの文はその補足であることがほとんどです。全文の意味が知りたい場合は、メッセージをそのまま翻訳やAIに貼って「何が起きている状態か」を説明してもらうとよいでしょう。
エラーメッセージを検索しても情報が出てこないのはなぜですか
検索語に自分の環境固有の情報（ファイルパスや自作の変数名）が混ざっている可能性が高いです。世界中で共通して表示される部分だけを残し、ダブルクォーテーションで囲んで完全一致検索にすると、同じ問題の投稿に当たりやすくなります。
AIにエラーを解決してもらうのは独学として良くないのでしょうか
使い方次第です。解決策だけを求めて貼り付ける使い方は理解が残りにくい一方、エラーの内容や原因を説明させたり、自分の仮説を伝えて別の視点をもらう使い方は学習効果を高めるとされています。AIが常に正しいとは限らないため、提示された修正が何を変えるのかを自分で説明できる状態にしてから採用するのが安全です。
Q&Aサイトで質問しても回答がつかないのはなぜですか
再現手順・実行環境・すでに試したことが書かれていない質問は、回答者が状況を再現できないため答えづらくなります。この3点を整理して書くと回答が得られやすくなります。切り分けの作業を先に済ませておけば、必要な情報は自然と手元に揃います。
※記事で使用した内容・数値は変更される場合があります。最新情報は公式サイトをご確認ください。