エラー文の読み方を覚えたら、AIに頼む回数が減った

• エラー文は長いが、見るべきは最初の1行と行番号だけ
• 同じ形のエラーは繰り返し出る。覚えると自分で直せる
• それでも分からないときの貼り方にも、効く形がある

画面が真っ白になるたびにエラーの全文を貼って聞いていた。返ってくる答えは当たることも外れることもあり、やり取りが長くなりがちだった。読み方を覚えてから、聞く回数そのものが減った。

エラー文のどこを見るか

長い文字列が並んでいるが、必要な情報は決まっている。

• 最初の1行 — 何が起きたかが書いてある
• ファイル名と行番号 — どこで起きたか
• 残りの行 — そこに至るまでの経路。最初は読まなくてよい

3つ目を読もうとして混乱していた。経路の記録は、原因が分からないときに初めて使うもので、普段は見なくていい。

行番号が指すもの

示された行が原因とは限らない。その行で「おかしい」と気づいただけで、原因は手前にあることが多い。閉じ忘れた括弧などは、何行も後で検出される。

よく出る形を覚える

同じ種類のエラーが繰り返し出ることに気づいた。意味を覚えたものを挙げる。

• 〜 is not defined / undefined — 名前の綴り違いか、読み込み忘れ
• Cannot read property 〜 of null — 取ろうとしたものが存在しない
• Unexpected token — 括弧や引用符の対応が崩れている
• 404 — ファイルの場所が違う

この4つで、遭遇したエラーのかなりの割合を占めていた。意味さえ分かれば、自分で直せるものが多い。

エラーが出ない場合のほうが難しい

何も表示されずに動かないときが一番困る。そのときに見る場所を決めた。

• ブラウザの開発者ツールを開き、赤い表示を探す
• 通信の記録を見て、読み込みに失敗しているファイルがないか確認する
• サーバー側のエラー記録を見る

2つ目で解決することが多かった。画面上は何も起きていなくても、裏でファイルの読み込みが失敗していることがある。

それでも分からないときの聞き方

自分で見当がつかないときは聞く。貼り方で返答の精度が変わった。

次のエラーが出ています。

【エラー】
（最初の3行だけ貼る）

【状況】
- 何をしたら出たか
- 直前に変更した箇所
- 試して駄目だったこと

【環境】
- 言語とその版
- 動かしている場所

「試して駄目だったこと」を書くと、同じ提案が返ってこない。これを書かずにいた頃は、既に試した方法を繰り返し提案されていた。

全文を貼らない理由

長いエラー記録を丸ごと貼ると、かえって的が外れることがあった。

• 無関係な警告が混ざり、そちらに引っ張られる
• 情報量が多いぶん、どこを重視するかの判断が入る
• こちらも、何が起きているか理解しないまま進んでしまう

3つ目が本質的な問題だった。貼って投げるだけだと、次に同じエラーが出ても自分で対処できない。

記録を残すようにした

解決したエラーは1行ずつ書き留めている。

• エラーの最初の1行
• 実際の原因
• どう直したか

同じエラーに再会したとき、記録を見れば数分で終わる。3か月ほど続けて20件ほど貯まったが、そのうち半数は2回以上出会っているものだった。

覚えておくと効く操作

エラーの読み方と合わせて、覚えると楽になる操作がある。

• 開発者ツールの開き方 — F12。これを知らないと何も始まらない
• ファイル内の検索 — 名前がどこで使われているか探せる
• 変更を戻す — 直前の状態に戻せると、切り分けが速い

3つ目が特に効く。壊れた状態で原因を探すより、動く状態に戻してから1つずつ入れ直すほうが確実だった。

まとめ

• 見るのは最初の1行とファイル名・行番号だけでよい
• 行番号が指す場所が原因とは限らない。手前を疑う
• よく出る4種類の意味を覚えると、自分で直せる割合が増える
• 聞くときは、試して駄目だったことを必ず添える
• 解決したエラーを1行記録すると、2回目が速い