JavaScriptエラーの調べ方｜Consoleの見方と、動かない原因を絞る手順

動かない操作と、確かめる条件をそろえる

最初に「どのページの、どの操作で、何が起きなかったか」を一つ決めます。画面の症状と記録が同じ場面かを確かめるためです。

期待する結果と、実際に見えた結果を書く

たとえば架空の料金ページで「料金を見る」を押し、料金の説明へ進むことを期待したのに、表示が変わらなかった場面です。「壊れている」だけでなく、押した場所と、期待した移動先・実際の表示を分けます。ボタンが選べないのか、押せたのに画面が変わらないのかも別の観察です。

対象URL、更新した版や日時、ブラウザーと端末、ログイン状態、問題に至る操作をそろえます。読み込み直後に出るもの、押した後に出るもの、別ページへ移動した後に出るものは分けてください。未確認の条件は、推測せず未確認のまま担当と合わせます。

一回の報告で、どこまで分かったかを残す

「料金を見るを押したが表示が変わらず、その操作時点にTypeErrorの行が見える」というところまでが、この例の手掛かりです。正確なメッセージ、ファイル、行、関連通信、原因と修正結果は未確認です。画面と記録が同時に起きたことだけで、因果関係まで確定しません。

Consoleを開き、見えている記録の範囲を確かめる

Consoleの表示は、対象ページ・記録した時点・フィルターによって変わります。空に見えることと、問題がないことは別です。

Chromeでは、対象ページからConsoleを開く

Chromeの対象ページで開発者ツールを開き、Consoleを選びます。Consoleを直接開くショートカットは、Windows等ではControl＋Shift＋J、MacではCommand＋Option＋Jです。画面やキーの扱いは利用環境で確かめてください。記事を読むためにコードを入力する必要はありません。

開いたページとURLを確認したうえで、対象の操作とメッセージの発生時点を合わせます。既に出ていた古い行や、別のフレーム・拡張機能に関係する行を、押したボタンの原因へまとめないでください。

レベル・文字列・URL・対象を確認する

ChromeのConsoleは、Error、Warning、Info、Verbose等のレベルや、文字列・URL・対象の文脈で表示を絞れます。Errorだけを見ているのか、入力したフィルターが残っているのか、必要な対象を見ているかを確認します。絞った範囲で0件でも、別レベルや別の対象の記録まで確認したことにはなりません。

架空の別会社の事例一覧では、一覧が表示されず、Errorだけの表示が0件という条件です。正確なメッセージや別対象のエラー、通信、原因、修正結果は未確認です。これは料金ページの修正後でも、JavaScript正常の証明でもありません。

遷移前後の記録を混ぜない

Chromeでは通常、新しいページの読み込みでConsoleの記録が消えます。ページ移動の前後も追う必要があるときはPreserve logの扱いを確認します。記録を残すと前のページの行も見えるため、どの操作・ページの記録かを併記します。ログを消したことを、エラーを直した結果にはしません。

開き方と表示範囲はChrome公式のConsole機能リファレンスを参照。仕様の説明と、自社サイトの観測は別です。

エラー名・メッセージ・ファイルの位置を分けて読む

エラー名は問題の種類、メッセージは起きた内容、ファイルと行は調べる入口です。入口の位置が、そのまま本当の原因の場所とは限りません。

押したのに変わらないとき、画面の結果と、どの時点の記録を並べればよいでしょうか。

原寸画像を開く

表示が変わらないことと、同時点にTypeErrorの行が見えることを分けて残します。メッセージ全文や関連ファイルを調べる前に、原因や修正完了へ飛ばないためです。

正式な名前を、短い意味と組にする

SyntaxError

コードを解釈する際、言語の構文に合わない書き方が見つかった種類です。

ReferenceError

その場所で存在しない、またはまだ初期化されていない変数などを参照した種類です。

TypeError

値や型に合わない操作など、適切でない方法で値を扱った場合の種類です。すべてを構文の書き間違いとは呼びません。

種類が同じでも、起点はさまざまです。名前だけを検索して見つけた修正を、そのまま公開サイトへ当てはめないでください。メッセージの文言はブラウザーや版で異なる場合もあるため、実際に表示された全文を、必要な範囲で正確に残します。

ファイル・行・呼出し履歴を、公開版と照合する

Consoleのファイルと行のリンクから、関連コードを確認できます。呼出し履歴は、そこへ至る関数呼出しの流れです。開発担当は、表示された位置、実際の配信ファイル、公開版、必要に応じて元のコードとの対応を照合します。圧縮されたファイルや対応表の違いがあるため、別版の同じ行番号へ機械的に修正を入れません。

料金ページの例には、正確なメッセージやファイル・行の値がありません。説明用にそれらを作り足さず、次に取得する手掛かりとして扱います。別の一覧ページも、0件表示だけから原因や修正を補いません。

種類の意味はMDNのTypeError、ReferenceError、SyntaxErrorを参照。自社の原因を確定する資料ではありません。

関連するコードと通信から、原因候補を絞る

エラーの入口に関係するファイル・通信・実行時の値を調べ、仮説を確かめます。症状だけで全体の設定を変えません。

読み込みに関係するなら、同じ資材の通信を見る

必要なスクリプトやデータが届かない手掛かりがあれば、開発担当はNetworkでそのURL、要求と応答、返った内容を確認します。同じファイル名やHTTP 200だけでは、期待するJavaScriptやデータを取得したことまで確定しません。表示された画面の版と、その資材の実内容も合わせます。

HTTPSページでHTTP参照が処理された場合など、該当する記録があるときは混在コンテンツの確認方法へ進めます。CORSや古い保存なども、関連する根拠を調べる候補です。「ボタンが動かない」だけを特定原因の証拠にはしません。

値や要素に関係するなら、動いた時点のコードを調べる

開発担当は、許可された確認環境で、関連するコードと現物の値を照合します。Sourcesの一時停止を使う場合は、処理の途中で止め、その時点の値や呼出しの流れを確認します。対象の要素があるか、必要な準備より先に処理したのか等を、実際の状態から調べます。

後続のエラーが最初の問題から続いていることも、別の問題であることもあります。起きた順序と操作を残し、仮説と確認済みを分けます。エラーを捕まえて表示しなくしただけで、利用者の用事が完了するとは限りません。

Chromeのデバッグ解説は、再現する操作と値の確認を組にしています。ブラウザー内だけで動かした修正は、全利用者へ配信した修正とは別です。

同条件で修正後を確かめ、継続監視とは分ける

修正した版で、同じ操作の画面結果と記録を再び確認します。一端末の試験と、継続して訪問者の問題を集める範囲は別に決めます。

エラーの表示だけでなく、期待した用事を確かめる

1. 対象と版を合わせる。修正を適用したURLと版、ブラウザー・端末・ログイン状態を残します。
2. 同じ操作を行う。最初の問題に至った順序を再現し、期待した表示や動きと実際を比べます。
3. 記録を読み直す。フィルターと対象、時点を合わせ、同じエラーや別の問題が残っていないか確認します。
4. 影響する操作も確認する。関連する重要な経路を許可された範囲で試し、未確認の条件は残します。

Consoleに例外が出なくても、表示する値や移動先が意図と違う場合があります。逆に、別の記録が見えても、対象の操作との関係は追加確認が必要です。画面結果・記録・条件を組にし、一回の成功を全訪問者の正常へ広げません。更新後の広い確認範囲は、更新前後の動作確認も参照できます。

継続監視では、集める範囲と対応先を決める

ときどきしか起きない問題は、発生ページ、公開版、ブラウザー等の環境、操作や発生時点、メッセージの種類を継続して関連付ける必要があります。会社が認めた方法で何を集められるかを決め、同じ問題をまとめて、影響する用事と担当への通知・調査・再確認につなげます。

単発のConsole点検を、全訪問者の記録を集めた証拠にはしません。監視の導入状況や収集できた範囲が不明なら、件数や発生率を作らず未確認と残します。URL内の識別子、入力値、顧客・決済情報をそのまま共有せず、必要な調査情報と共有範囲を担当者が確認してください。

まとめ：一つの操作と同じ時点の記録から始める

動かない操作を一つ決め、画面の結果と同時点のConsoleを対応させます。種類・メッセージ・ファイル位置・関連通信と現物の値から調べ、修正後の結果は同じ条件で確かめます。

TypeErrorの行が見えることは原因確定ではなく、Errorの表示が0件であることは正常の証明ではありません。未確認のメッセージ・原因・修正・再確認・公開結果を埋めず、次に調べる箇所と担当を具体的に決めましょう。