ビルドしたゲームのコンソールエラーを読む:初心者向け読解表
遊びをつくる執筆にClaudeを使用しています。

ゲームをビルドして公開したとたん、ブラウザの開発者ツールにずらりとエラーが並んでいた――そんな経験はないでしょうか。開発中は動いていたのに、ファイルをまとめてサーバーに置いた途端に壊れるのは、ビルドと開発環境の違いが原因であることがほとんどです。 コンソールエラーは「何が」「どこで」「なぜ」壊れたかを一行で教えてくれる最初の手がかりです。しかし初心者にとっては英文の羅列に見えてしまい、どこから読めばいいのか分からないまま閉じてしまいがちです。この記事では、ビルド後のゲームに出やすいコンソールエラーの種類と読み方を整理し、「このメッセージが出たらここを直す」という判断の流れを示します。
コンソールエラーの開き方と基本の見方
まずブラウザでゲームのURLを開き、F12キー(macOSはCommand + Option + I)で開発者ツールを起動します。上部のタブから「Console」を選ぶと、エラーや警告が時系列で並びます。
1行のエラーには大きく三つの要素が含まれています。
- エラー種別:TypeError、ReferenceError、SyntaxErrorなど、何の種類の問題かを示す語
- メッセージ本文:is not defined、Cannot read properties of undefinedなど、何が起きたかの説明
- ファイルと行番号:main.js:42のように、どのファイルの何行目かを示すリンク
エラー行の右端に表示されるファイル名をクリックすると、Sourcesタブで該当箇所に飛べます。まずこの三点を確認することが、読解の出発点です。
ビルド後に出やすいエラーと読み解き方
開発中は問題なく動いていたのにビルド後に壊れる原因は、パス・スコープ・非同期処理の三つに集中しています。それぞれ代表的なメッセージと対処の考え方を示します。
パス関連のエラー
GET https://example.com/assets/player.png 404 (Not Found)404はリソースが見つからないという意味です。開発中は相対パスで問題なく読めていたファイルが、ビルド後にフォルダ構造が変わって見つからなくなるケースです。ビルドツール(ViteやWebpackなど)の設定でbaseやpublicPathを指定している場合、その値とサーバーのデプロイ先が一致しているか確認します。画像や音声ファイルをコードの中に文字列で直書きしているなら、ビルドツールが認識できる形式(importやpublicフォルダ経由)に統一するのが根本対処です。
Access to fetch at '...' from origin '...' has been blocked by CORS policyCORSエラーは、異なるオリジン(ドメインやポート)からリソースを取得しようとしたときに出ます。開発中はlocalhost同士でアクセスしていたAPIや外部ファイルを、本番ではhttpsの別ドメインから呼んでいる場合に発生します。フォントや外部APIなど、自分で管理できないサーバーからのリソースはCORSヘッダーの設定が必要で、ゲーム側のコードだけでは解決できません。回避策として、ファイルを自分のサーバーに置き直すか、プロキシを経由する方法があります。
スコープ・参照エラー
ReferenceError: myGame is not defined「その変数・関数が見つからない」という意味です。ビルド前はグローバルに宣言していた変数が、バンドル後にモジュールスコープに閉じ込められて外から参照できなくなるケースです。複数のJSファイルをscriptタグで順に読んでいた構成を、ビルドツールでまとめたときによく起きます。別ファイルから使うものはexportとimportで明示的につなぐのが正しい対処です。
TypeError: Cannot read properties of undefined (reading 'play')undefinedに対してプロパティにアクセスしようとしています。ビルド後は非同期処理の完了タイミングが開発中と変わることがあり、「読み込みが終わる前にオブジェクトを使おうとした」場面で出やすいエラーです。エラーの直前にconsole.logで変数の中身を出力して、undefinedになっているタイミングを特定します。
SyntaxエラーとParseエラー
SyntaxError: Unexpected token '<'JavaScriptを期待しているのにHTMLが返ってきたときに出るエラーです。スクリプトのパスが間違っていて、サーバーがエラーページ(HTML)を返しているのをJSとして読もうとしている状態です。NetworkタブでそのJSファイルのステータスコードを確認し、404や500になっていれば、パスか設定を修正します。
エラーの優先順位と読む順番
コンソールには複数のエラーが重なって出ることが多く、すべてを同列に扱うと迷子になります。次の順序で整理すると効率的です。
- 赤いエラー(Error)を最初に見る:警告(黄色のWarning)は動作に影響しないことも多いため、まず赤いエラーだけに絞ります。
- 一番上のエラーを優先する:後続のエラーは最初の一つが原因で連鎖していることが多く、最初のエラーを直すと他が消えることがあります。
- ファイル名と行番号をクリックして確認する:ミニファイ(圧縮)されたファイルを開くと一行に詰まって読みにくいですが、開発者ツールの「Pretty print」ボタン({}マーク)で整形できます。
- ソースマップが使えるか確認する:ビルド設定でソースマップ(.mapファイル)を生成していると、ミニファイ後のコードを元のファイルに対応づけて表示してくれます。エラーの行番号が圧縮後の1行目を指したままになっているなら、ソースマップが有効になっていない合図です。
「直しても同じエラーが出る」ときの確認ポイント
修正してアップロードしたはずなのに同じエラーが消えない、というケースはキャッシュが原因であることが多いです。ブラウザは以前のJSやCSSを保持しているため、Ctrl + Shift + R(macOSはCommand + Shift + R)でキャッシュを無視した強制再読み込みを試します。それでも解消しない場合は、開発者ツールのNetworkタブで「Disable cache」にチェックを入れてから再読み込みすると、確実に最新ファイルを取得できます。
CDNや静的ホスティングサービスを使っている場合は、サービス側のキャッシュが残っていることもあります。デプロイ後に数分待つか、サービスのキャッシュ無効化機能(パージ)を使います。
また、修正したつもりのファイルが実際にはアップロードされていないケースもあります。Networkタブで問題のJSファイルを選び、Previewタブで中身を確認して、修正が反映されているか目で見て確かめるのが確実です。
次の行動
今すぐゲームのURLを開いてF12キーを押し、Consoleタブにエラーが出ているか確認してみましょう。赤いエラーが出ていたら、この記事の読解表を手元に置きながら一番上の一件だけを読み解いて、ファイル名と行番号をクリックするところから始めてください。ビルド済みのHTMLとアセットをZIPにまとめてアソバースへ投稿する前に、このチェックを一度行っておくと公開後の不具合を大きく減らせます。
参考資料
- MDN Web Docs「JavaScript エラーリファレンス」
- MDN Web Docs「コンソール API」
- Chrome DevTools 公式ドキュメント「Console overview」
- Vite 公式ドキュメント「Static Asset Handling」および「Building for Production」

