GodotとUnityのゲームをWebで公開する前に確かめたいこと

Web出力で何が生成されるか

ゲームエンジンのWeb出力は「HTMLファイル一枚」ではありません。実際には複数のファイルがセットで動作します。これを理解しておかないと、HTMLだけを投稿してゲームが起動しない、という状況になります。

Godotの出力ファイル構成

Godot（4.x系）でWeb向けにエクスポートすると、標準的な構成では次のファイルが生成されます。

• .html — ブラウザ側の起動ページ。index.htmlにリネームして使うことが多い
• .wasm — WebAssemblyバイナリ。エンジン本体が含まれる
• .pck — ゲームのアセットやシーンをまとめたパックファイル
• .js — エンジンを起動するJavaScript
• .png — 起動時のスプラッシュ画像

これらのファイルはすべて同じ場所に置かれている必要があります。HTMLだけをZIPに入れて投稿しても、.wasmや.pckが見つからずエラーになります。出力ディレクトリごとZIPに圧縮するのが基本です。

UnityのWeb出力ファイル構成

Unity（6000系）でWebプラットフォーム向けにビルドすると、BuildフォルダとTemplateDataフォルダを含むディレクトリが生成されます。Buildフォルダには次のファイルが含まれます。

• .loader.js — Unityコンテンツを読み込むJavaScriptローダー
• .framework.js — JavaScriptランタイムとプラグイン群
• .wasm — WebAssemblyバイナリ（エンジン本体）
• .data — シーンとアセットのデータ

圧縮設定によっては各ファイルに .gz（gzip）や .br（Brotli）の拡張子が付きます。この場合、サーバー側に対応するContent-Encodingヘッダーの設定が必要になります。圧縮形式とサーバー設定が一致しないと、ファイルが読めずにゲームが起動しません。

Unityの圧縮設定は「Player Settings > Web > Publishing Settings > Compression Format」で変更できます。サーバー設定を変えられない環境では「Disabled」を選ぶことで圧縮なしのビルドを作れますが、ファイルサイズは大きくなります。

スレッド設定とサーバーヘッダーの関係

Web出力がローカルでは動くのに公開先で動かない、という問題の原因として最も多いのがSharedArrayBufferとCORS隔離ヘッダーの不一致です。

マルチスレッドを有効にしたビルドは、SharedArrayBufferという仕組みを使って複数スレッド間でメモリを共有します。ブラウザはセキュリティ上の理由から、このAPIをクロスオリジン隔離状態（cross-origin isolated）のページでしか有効にしません。隔離状態にするには、サーバー側で次の2つのHTTPヘッダーを返す必要があります。

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp

これらのヘッダーを設定できないホスティング環境にマルチスレッドビルドを置くと、SharedArrayBufferが無効になりゲームが起動しません。対処は2つです。ひとつは投稿先のホスティングがこのヘッダーを設定できるか確認すること。もうひとつはエンジン側でシングルスレッドモードに切り替えることです。

Godotのシングルスレッドモード

Godot 4.3以降、Webエクスポートのデフォルトはシングルスレッドです。Godot公式ドキュメントでも「推奨かつ現在のデフォルト方式」と説明されており、前述のヘッダーが不要なため多くのホスティング環境で追加設定なしに動作します。ただし、低レイテンシーオーディオや重い処理に影響が出る場合があります。スレッドの有効・無効はエクスポートダイアログの「Thread Support」オプションで切り替えられます。

Unity 6のスレッド設定

Unity 6では「Player Settings > Web > Publishing Settings > WebAssembly Language Features > Enable Native C/C++ Multithreading」をオフにすることで、SharedArrayBufferを使わないシングルスレッドビルドを作れます。なお、この機能はUnity 6の公式ドキュメントで「experimental（試験的）」と明記されています。パフォーマンスは下がる場合がありますが、ヘッダー設定ができない環境への投稿には有効な選択肢です。

JavaScriptの window.crossOriginIsolated をブラウザのコンソールで確認すると、ページがクロスオリジン隔離状態かどうかをすぐ判定できます。true ならSharedArrayBufferが有効、false なら無効です。

Godot 4でC#を使っている場合の注意

Godot 4でC#（.NET）を使って開発したプロジェクトは、現時点ではWebエクスポートに対応していません（2026年10月時点の公式ドキュメント）。C#でWebに出力したい場合はGodot 3系を使う必要があります。GDScriptやC++（GDExtension）を使ったプロジェクトは通常どおりWeb出力できます。

この制限はエンジンのバージョンアップで将来的に解消される可能性はありますが、現時点では公式が「未対応」と明記しているため、C#を使っているGodot 4プロジェクトをWeb向けに出力しようとするとエクスポートが失敗します。開発言語の選定段階でWebをターゲットにするなら、この点を確認しておいてください。

ファイル容量と圧縮の扱い

WebAssemblyバイナリはサイズが大きくなりやすい傾向があります。Godotの公式ドキュメントでは、.wasmファイルはgzip圧縮で特に高い圧縮効率を発揮すると説明されています。ただしこれはサーバー側がgzip転送に対応していることが前提です。

ゲームをZIPで投稿する場合、ZIPの中にすでに圧縮済みファイル（.gz、.br）が含まれていると、投稿先の処理によっては二重圧縮になる場合があります。サーバー側の圧縮設定が不明な場合は、Unity・Godotともに圧縮なし（Disabled）でビルドして動作を確認し、問題がなければ圧縮ありに切り替えるという順番が安全です。

ゲームが重い画像や音声アセットを多数含む場合、.dataファイルや.pckファイルが数十MBになることがあります。大容量のビルドはロード時間に直結するため、アセットの解像度や音声フォーマット（OGGへの変換など）でサイズを減らす工程をビルド前に済ませておくと良いでしょう。

投稿前にローカルで確認できる手順

「ローカルでファイルをダブルクリックして起動する」方法は、ブラウザのセキュリティ制限によりWebAssemblyやリソースの読み込みがブロックされることが多く、動作確認になりません。ローカルでの確認にはHTTPサーバーを立てる必要があります。

シンプルなローカルHTTPサーバーの起動

Node.jsが入っている場合は npx serve を、Pythonが入っている場合は python3 -m http.server を使うと、出力フォルダをすぐHTTPで配信できます。

# Node.js の場合（出力ディレクトリで実行）
npx serve .

# Python 3 の場合
python3 -m http.server 8080

このコードは説明用の例です。ローカルHTTPサーバーではCOOP/COEPヘッダーは設定されないため、マルチスレッドビルドの動作確認には不十分です。その場合はGodotの公式が説明するService Workerによる回避策か、ヘッダー設定に対応したローカルサーバーツールを利用してください。

確認するポイント

1. ブラウザのコンソール（F12）にエラーが出ないか確認する。「SharedArrayBuffer is not defined」はヘッダー不足、「Failed to fetch」はファイルが見つからないことを示す
2. ZIPに必要なファイルがすべて含まれているかを確認する。GodotならHTML/WASM/PCK/JS/PNG、UnityならHTMLと全Buildファイルが揃っているか
3. index.htmlが存在しているかを確認する。投稿先によってはルートのHTMLファイルがindex.htmlである必要がある
4. ゲームが完全に起動してメインコンテンツが操作できるところまで動作を見届ける。ロード画面で止まる場合もある
5. スマートフォンのブラウザでも開いてみる。WebGL 2.0のサポート状況がPCと異なる場合がある

確認できたら投稿する

アソバースはHTMLファイル単体とZIPファイルの直接投稿、および公開済みURLの登録に対応しています。エンジンのWeb出力のように複数ファイルがセットになっている場合は、ディレクトリをまとめてZIPで投稿するのが基本です。

投稿前に上記の手順でローカル確認を済ませ、ゲームが実際に起動することを確かめてください。動作確認なしに投稿してもページは公開できますが、プレイヤーがゲームを開けない状態のまま公開されます。

また、Web出力はエンジンのバージョンや設定によって出力内容が変わります。エンジンをアップデートした後や設定を変更した後は、必ず再出力・再確認してから投稿し直すことをお勧めします。「以前投稿したものは動いていた」という実績があっても、設定変更後のビルドが同じように動くとは限りません。

Godot・Unity以外のエンジンやフレームワークを使っている場合も、考え方は同じです。出力ファイルの構成を把握し、サーバーヘッダーの要件を確認し、ローカルで実際に動かしてから投稿する。この順番を守るだけで、公開後に起動しないゲームになるリスクは大きく下がります。