ゲームを公開したら動かない：ローカルと本番の違い一覧
遊びをつくる執筆にClaudeを使用しています。
手元のブラウザで完璧に動いていたゲームを公開したとたん、画面が真っ白になったり、音が鳴らなくなったり、セーブが消えたりする——これはゲーム開発で非常によく起きる問題です。原因のほとんどは「ローカル環境と本番環境の構造的な違い」にあり、コード自体のバグではないことが多いです。 この記事では、ローカルで動いて本番で動かなくなる典型的な原因を一覧形式で整理し、それぞれの確認手順と修正の考え方を示します。「何から調べればいいかわからない」という状態から、原因の絞り込みができる状態になることを目標にしています。
この記事の目次
まず最初にブラウザの開発者ツールを開く
原因を推測する前に、ブラウザの開発者ツール（F12キー、またはCmd+Option+I）を開いてConsoleタブを確認してください。エラーメッセージが出ていれば、それが最大のヒントです。「404 Not Found」「CORS error」「Uncaught TypeError」など、エラーの種類によって原因カテゴリが絞り込めます。
Networkタブも有効です。リソース（画像・音声・JSONファイルなど）が読み込めているかどうかを、ステータスコードで確認できます。赤く表示されているリクエストがあれば、そのファイルのパスか配信の仕組みに問題があります。
原因カテゴリ①：ファイルパスの書き方
ローカルで最も多いミスが、絶対パスとルート相対パスの混在です。
ローカルでは C:\Users\user\game\assets\img.png や /Users/user/game/assets/img.png のようなローカルの絶対パスが動いてしまうことがあります。しかし本番サーバーにはその経路は存在しないため、404エラーになります。
また、/assets/img.png のようなルート相対パスは、サーバーのドキュメントルートからの経路を指します。ゲームが https://example.com/games/mygame/ に置かれている場合、/assets/img.png は https://example.com/assets/img.png を探しに行くため、ファイルが見つかりません。
安全な書き方は相対パスです。./assets/img.png や assets/img.png のように、HTMLファイル自身からの相対位置で指定すると、ローカルでも本番でも同じ基準で解決されます。ZIPで複数ファイルをまとめて公開する場合は、ディレクトリ構造をそのまま保ってアーカイブすることが前提です。
確認手順
- ソースコード内の src=、href=、url()、fetch() などのパス指定を全文検索する。
- / 始まりのルート相対パスや、ドライブ文字（C:など）を含むものを見つけて相対パスに書き換える。
- fetch('./data/stage1.json') のように ./ を明示的に付けると意図が明確になります。
原因カテゴリ②：HTTPSとHTTPの混在（Mixed Content）
本番環境はほぼ必ず https:// で配信されます。そのページ内から http:// のリソースを読み込もうとすると、ブラウザがセキュリティ上の理由でブロックします。これを「Mixed Content」と呼びます。
ローカルでは file:// プロトコルや http://localhost から動かすことが多く、Mixed Contentの制限が緩い状態になっている場合があります。そのため手元では動いていたものが、本番の https:// 環境でブロックされます。
外部のAPIやCDNを参照している場合も同様です。自分のコードではなく、読み込んでいるライブラリのURLが http:// になっていないか確認してください。修正方法は http:// を https:// に変えるだけで済む場合がほとんどです。ただし接続先が https:// に対応していない場合は、ライブラリを手元にダウンロードして相対パスで参照する方法に切り替えます。
原因カテゴリ③：CORSエラー（クロスオリジンのリソース取得）
fetch() や XMLHttpRequest で別ドメインのAPIやファイルにアクセスしようとすると、本番ではCORSエラーが発生することがあります。ローカルの file:// では制限が異なる場合があり、手元では動いていたのに本番でブロックされるパターンです。
Consoleに「CORS policy」という文字列が含まれるエラーが出ていれば、このカテゴリです。
解決のアプローチは主に二つです。一つは、アクセス先のAPIやサーバーがCORSを許可するヘッダー（Access-Control-Allow-Origin）を返すよう設定することです。自分で管理していないAPIの場合は設定できないため、もう一つのアプローチとして、サーバーサイドのプロキシを経由する構成に変えることが必要になります。
ゲームのデータをすべてHTMLやJSファイル内に含める（外部fetch不要の構成にする）と、CORSの問題を根本的に回避できます。小〜中規模のブラウザゲームでは、この構成が管理しやすいです。
原因カテゴリ④：`localStorage` とセーブデータの扱い
localStorage はドメインとプロトコルをキーにして分離されています。ローカルで file:// 上に保存したデータは、本番の https:// では読めません。これは仕様どおりの動作ですが、「ローカルでテストしたセーブが本番で消える」という形で現れます。
また、複数のページやゲームが同一ドメインで動いている場合、localStorage のキー名が被ると意図しないデータを読み書きする可能性があります。キー名にゲーム固有のプレフィックスを付けることで回避できます（例：mygame_v1_savedata のように）。
プレイ履歴やクラウドセーブのような機能が必要な場合は、プラットフォームが提供するSDKや外部のバックエンドサービスを使う必要があります。アソバースでは、作者がSDKを組み込んだゲームに限り、共通ログインとクラウドセーブが使えます。localStorage のみに依存した実装では、デバイスをまたいだセーブ共有はできません。
原因カテゴリ⑤：音声の自動再生制限
ローカルでは問題なく鳴っていた音楽やSEが、本番で無音になるケースがあります。モダンブラウザはユーザー操作（クリック・タップ）が発生する前の自動再生を制限しています。ローカルの開発環境ではこの制限が緩いことがあり、ギャップが生じます。
対処法は、音声再生のトリガーを必ずユーザー操作に紐づけることです。「スタート」ボタンのクリックイベント内で AudioContext.resume() や audio.play() を呼ぶ構造にすると、本番でも安定して動きます。BGMをページロードと同時に流したい場合でも、タイトル画面のクリックを挟む設計が現実的な回避策です。
原因カテゴリ⑥：大文字・小文字とファイル名の不一致
Windowsのローカル環境ではファイルシステムが大文字小文字を区別しないことが多く、Image.PNG と書いても image.png が読まれます。しかしLinuxベースの本番サーバーは大文字小文字を厳密に区別します。
結果として、ローカルで動いていたリソース読み込みが本番で404になります。ファイル名とソースコード内の参照が完全に一致しているか、大文字小文字を含めて確認してください。プロジェクト全体でファイル名を小文字に統一する規則を決めておくと、このミスを防ぎやすくなります。
原因カテゴリ⑦：キャッシュと古いバージョンの混在
本番サーバーや中間CDNがJSやCSSファイルをキャッシュしている場合、修正をデプロイしても古いファイルが配信され続けることがあります。開発者ツールのNetworkタブで「キャッシュを無効化して再読み込み」（Shift+Ctrl+R またはShift+Cmd+R）を行い、最新のファイルが取得されているか確認してください。
ファイル名にバージョン番号やハッシュを付ける（例：game.v2.js）か、クエリパラメータを付ける（例：game.js?v=20261020）手法でキャッシュを強制的に更新できます。
次の行動
まずブラウザの開発者ツールを開き、Consoleに表示されているエラーメッセージの種類でカテゴリを特定してください。上記の一覧と照合しながら一つずつ潰すことで、大半の「ローカルでは動くのに本番で動かない」問題は原因を特定できます。修正後は別のデバイスやブラウザでも動作を確認してから公開することを習慣にすると、再発防止につながります。アソバースへの投稿はZIPファイルでのアップロードにも対応しているため、複数ファイル構成のままディレクトリ構造を保って投稿できます。
