エラーメッセージを読んで自分で直す
開発中に赤い文字のエラーが出ると、内容を読む前に画面を閉じたくなります。しかし、エラーメッセージは「どこで、何が起きたか」を機械が正確に報告してくれる、最も信頼できる手がかりです。読み方さえ身につければ、エラーは怖いものから頼れる道しるべに変わります。
この記事では、エラーメッセージのどこを見るか、原因の切り分け方、AIに質問するときの正しい貼り方を、MDNとChrome DevToolsの一次情報にもとづいて整理します。
エラーメッセージの3つの部品を見つける
言語やツールが違っても、エラーメッセージはおおむね次の3つの部品でできています。
エラーの種類：先頭に出る分類です。JavaScriptなら SyntaxError（文法の誤り）、ReferenceError（存在しない名前を参照した）、TypeError（値の種類が想定と違う）などがあります
説明文：何が起きたかの短い英文です。「x is not defined」「Cannot read properties of undefined」のように、問題の対象が名指しされています
場所：ファイル名と行番号です。
app.js:42のように書かれていれば、app.js の42行目付近が出発点です
最初にやることは、この3つを声に出して読める状態にすることです。「TypeErrorが、app.jsの42行目で、undefinedのプロパティを読もうとして起きた」と言い換えられれば、原因調査の半分は終わっています。
場所の情報から出発する
エラーの下に続くたくさんの行はスタックトレースと呼ばれ、エラーが起きるまでに通った関数の経路を新しい順に並べたものです。すべてを読む必要はありません。
上から順に見て、自分が書いたファイル名が最初に出てくる行を探します
ライブラリやフレームワークの内部ファイル（node_modules内など）は、多くの場合は原因ではなく通り道です
行番号の場所を開き、その行で使っている変数や関数を確認します
エラーが表示された行が悪いとは限りません。「undefinedのプロパティを読んだ」場所は42行目でも、undefinedになった原因はもっと前の処理にあります。エラーの行は出発点であり、犯人とは限らないと覚えておきます。
種類別の考え方を持つ
よく出るエラーには、それぞれ定番の原因があります。
SyntaxError：括弧や引用符の閉じ忘れ、カンマの欠落など、書き方そのものの誤りです。示された行かその直前を見ます
ReferenceError：名前のつづり間違い、定義より前に使った、読み込み忘れが典型です
TypeError：データが想定した形で届いていません。通信の失敗、空の配列、名前の違うプロパティなど、値がどこで想定とずれたかをさかのぼります
ブラウザで動くアプリなら、開発者ツールのコンソールにエラーの一覧と発生場所が表示されます。コンソールを開いたまま操作を再現するのが、原因の場所を特定する最短の方法です。
再現手順をつくってから直す
原因の見当がついたら、直す前に「必ずエラーが出る手順」を確認します。
どの画面で、何を入力し、どのボタンを押すとエラーが出るかを書き出す
その手順で、毎回同じエラーが出ることを確かめる
修正したら、同じ手順でエラーが消えたことを確かめる
再現手順がないまま修正すると、「直ったように見えるが、実は別の条件で残っている」状態になりがちです。確認の一周は初めて作ったアプリを自分で確認する方法の考え方がそのまま使えます。
AIに質問するときは3点セットで貼る
エラーメッセージはAIに相談するときの最良の材料です。ただし、貼り方で回答の質が大きく変わります。
エラー全文：先頭の種類から場所の行まで、省略せずに貼ります。最後の1行だけでは情報が足りません
該当するコード：エラーに出たファイルの、該当行を含む前後のまとまりを貼ります
やろうとしていたこと：「何をしたらこうなったか」「本当はどうなってほしいか」を一文ずつ添えます
このとき、APIキーやパスワードなどの秘密の値がエラーやコードに含まれていないかを必ず確認します。伏せ方は個人開発の秘密情報を安全に管理するで整理しています。AIへの伝え方全般はAIに作りたいアプリを伝える方法が土台になります。
次に読む記事
AIが提案した修正をそのまま受け入れてよいかの判断は、AIが書いたコードを自分で確かめるで整理しています。エラーを利用者に見せる側の文章は入力エラーを利用者が直せる文章にするで扱っています。