Godot 4ゲームのWebエクスポート方法（HTML5とitch.io）

GodotはHTML5とWebAssemblyとしてWebにエクスポートできます。つまり、ダウンロードもプラグインも不要で、ゲームがブラウザのタブで動きます。プレイできるビルドを人に届けるには、これがいちばん速い方法です。リンクを貼れば、相手はクリックするだけでプレイできます。

「Webにエクスポートする」には、実は2つの作業があります。ファイルを書き出すのは1分ほどで終わります。そのファイルをブラウザで動かす段階でブラックスクリーンに突き当たる人が多く、原因はたいていファイルの配信方法か、エクスポートオプションがホストの満たせない要件を知らないうちに有効にしていたことです。このガイドでは両方の段階、正確な設定、そしてエクスポート失敗の大半を占めるエラーを解説します。

対象はGodot 4.3以降です。それより古い4.xは常にスレッド対応ビルドを使っていたため、まだ4.0、4.1、4.2を使っている場合はヘッダーの節をよく読むか、エディタを更新してください。

{/* IMAGE: The Godot Export dialog open with a Web preset selected, the Export Project button highlighted. 1200x675 editor screenshot. */}

「Webエクスポート」が実際に生成するもの

エクスポートしても、Godotは単一のファイルを作るわけではありません。静的ファイルの小さなフォルダを書き出します。

• index.html はすべてを読み込むページです。ブラウザが開くのはこのファイルです。
• .wasmファイル はWebAssemblyにコンパイルされたGodotエンジン本体です。いちばん大きなファイルです。
• .pckファイル はゲームデータで、シーン、スクリプト、アセットがまとめてパックされています。
• .jsファイル はエンジンとページをつなぐローダーのグルーコードです。
• 場合によっては .audio.worklet.js があり、スレッド対応ビルドでは追加のワーカーファイルも含まれます。

これらのファイルはすべて同じ場所に置き、HTTPで配信する必要があります。index.htmlをダブルクリックしても動きません。多くの人が最初につまずくのがここです。

ステップ1. エクスポートテンプレートをインストールする

Godotはエディタとエクスポートテンプレートを別々に配布しています。テンプレートは各プラットフォーム向けにビルド済みのエンジンバイナリで、ブラウザ向けのWebAssemblyビルドも含まれます。インストールしたばかりの状態では入っていません。

Editor から Manage Export Templates（エクスポートテンプレートの管理）を開き、Download and Install をクリックします。使っているエンジンと完全に同じバージョンのテンプレートが取得されます。

テンプレートはエディタのバージョンと完全に一致している必要があります。4.4のエディタでは4.3のテンプレートを使ってエクスポートできず、その逆もできません。この不一致はWebビルドが壊れる原因としてとても多いものです。エディタを更新するたびに、テンプレートも入れ直してください。

ステップ2. Webエクスポートプリセットを追加する

Project から Export を開きます。Add をクリックして Web を選びます。

既定値はおおむね妥当です。Web向けに重要なオプションは3つのグループです。

• Variant、Thread Support。 Godot 4.3以降は既定でオフです。スレッドが本当に必要だと計測で確かめていない限り、オフのままにしてください。シングルスレッドのビルドは、どの静的ホストでも、ゲームポータルのiframe内でも動作します。オンにすると、ステップ4で説明する2つのCross-Originヘッダーが必要になります。
• Variant、Extensions Support。 プロジェクトでGDExtensionを使う場合にだけ必要です。こちらもCross-Originヘッダーが必要で、ネイティブ拡張ごとに専用のWebビルドが必要です。
• VRAM Texture Compression。 既定では「For Desktop」がオン、「For Mobile」がオフです。両方を有効にするとエクスポートは大きくなりますが互換性が高まります。スマートフォンは一般にデスクトップ向けのテクスチャ形式に対応していないため、スマホのプレイヤーを想定するなら重要です。

Head Include とカスタムHTMLシェルは、変更する理由がない限り空のままにしてください。既定のシェルが読み込みとプログレスバーを処理します。

ステップ3. プロジェクトをエクスポートする

出力先のフォルダを選びます。出力ファイルが他のものと混ざらないように、web-build のような名前で空のフォルダを作りましょう。

メインファイルの名前はゲーム名ではなく index.html にします。itch.ioを含むほとんどのホストは、エントリポイントとしてindex.htmlを探します。mygame.html という名前にすると、ホストはファイルを見つけられません。

Export Project をクリックします。数秒で、先ほど挙げたファイルがフォルダに書き出されます。

{/* IMAGE: A file explorer showing the exported web-build folder contents: index.html, .wasm, .pck, .js files. 1000x500. */}

ステップ4. Cross-Originヘッダーが必要になるとき

古いチュートリアルの多くは、Godot 4のWebビルドには必ず特別なヘッダーが必要だと説明しています。それは4.3より前の話です。現在は2つのチェックボックス次第です。

Thread Support または Extensions Support を有効にしたビルドは SharedArrayBuffer を使います。ブラウザがこれを許可するのは、ページが次の2つのレスポンスヘッダー付きで配信された場合だけです。

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

これらがないとエンジンは起動できず、コンソールには SharedArrayBuffer や crossOriginIsolated に触れたエラーが表示されます。このヘッダーはGodotで設定するものではありません。ファイルを配信する側で設定します。

両方のオプションがオフのビルド、つまり既定のビルドには、どちらのヘッダーも必要ありません。だからこそ、itch.io、ゲームポータル、シンプルな静的ホスティングにはシングルスレッドのエクスポートが適しています。スレッドは重いゲームでパフォーマンスを上げることがありますが、その代わりにホスティングの自由度と埋め込み時の互換性を失います。

ステップ5. アップロードする前にローカルでテストする

アップロードとページの再読み込みを繰り返してWebエクスポートをデバッグするのはやめましょう。まず自分のマシンでテストします。

いちばん手早い確認方法は、エディタの ワンクリックデプロイ（one-click deploy）です。Webプリセットがあると、エディタ右上にブラウザのアイコンが表示されます。これをクリックするとローカルのWebサーバーが起動し、プロジェクトをエクスポートして既定のブラウザで開きます。このサーバーはCross-Originヘッダーを送信するので、スレッド対応ビルドも動きます。

すでにエクスポートしたビルドなら、Thread SupportとExtensions Supportがオフである限り、どんなローカルサーバーでも動作します。Pythonがインストールされていれば、web-build フォルダ内で python -m http.server 8000 を実行し、http://localhost:8000 を開きます。

スレッド対応ビルドの場合は、両方のヘッダー付きで配信します。次の内容を serve.py としてフォルダ内に保存してください。

import http.server, socketserver

class Handler(http.server.SimpleHTTPRequestHandler):
    def end_headers(self):
        self.send_header("Cross-Origin-Opener-Policy", "same-origin")
        self.send_header("Cross-Origin-Embedder-Policy", "require-corp")
        super().end_headers()

with socketserver.TCPServer(("", 8000), Handler) as httpd:
    print("Serving on http://localhost:8000")
    httpd.serve_forever()

python serve.py を実行して http://localhost:8000 を開きます。ここでゲームが読み込まれれば、エクスポートは正しく、残る問題はホスト側の設定の問題です。

ステップ6. ゲームを公開する

itch.io（最も簡単、無料）

共有やゲームジャムには、この方法がおすすめです。

1. 親フォルダではなく web-build フォルダの中身をzipにまとめ、index.htmlがzipの最上位に来るようにします。
2. itch.ioで新しいプロジェクトを作成し、Kind of project（プロジェクトの種類）を HTML に設定します。
3. zipをアップロードし、This file will be played in the browser（このファイルをブラウザでプレイする）にチェックを入れます。
4. 埋め込みオプションで、ゲームの解像度に合ったビューポートサイズを設定します。

itch.ioでは展開後のコンテンツが500 MBまで、1ファイルあたり200 MBまで、ファイル数は1,000個までです。シングルスレッドのビルドなら、ほかに何も必要ありません。スレッド対応ビルドの場合、itch.ioは埋め込みフレームのオプションに SharedArrayBuffer support のチェックボックスを用意しています。ただし、ページの一部が動かなくなる可能性がある実験的な機能として案内されているので、公開したページを複数のブラウザでテストしてください。

Netlify、Vercel、GitHub Pages、または独自サーバー

シングルスレッドのビルドは、通常のGitHub Pagesを含むどの静的ホストでもそのまま動作します。サーバーが .wasm ファイルを application/wasm のContent-Typeで送信し、圧縮して配信していることを確認してください。WebAssemblyはgzipでおよそ4分の1のサイズまで小さくなります。

スレッド対応ビルドの場合は、ホストが2つのヘッダーを送信する必要があります。Netlify では、デプロイのルートに _headers ファイルを追加します。

/*
  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp

Vercel では、vercel.json の headers ルールで同じ2つのヘッダーを設定します。nginxやApacheでは、locationブロックに追加します。GitHub Pagesはカスタムヘッダーを送信できないため、そこでスレッド対応ビルドを動かすにはcoi-serviceworkerのようなService Workerによる回避策が必要ですが、すべてのブラウザがそれを尊重するわけではありません。スレッドが不要なら、Thread Supportをオフにするのがいちばん簡単な解決策です。

ブラックスクリーンを直すチェックリスト

黒いキャンバスが表示されたら、ブラウザの開発者コンソールを開き（F12を押してConsoleタブを選びます）、最初の赤いエラーを読んでください。次の項目を順番に確認します。

1. ファイルを直接開いていませんか？ URLが file:// で始まっている場合は、HTTPで配信してください。
2. エラーに SharedArrayBuffer や crossOriginIsolated が含まれていませんか？ Thread SupportまたはExtensions Supportが有効なのに、ホストがヘッダーを送信していません。両方のオプションをオフにして再エクスポートするか、ホスト側でヘッダーを追加してください。
3. エラーにバージョンやテンプレートの読み込み失敗が出ていませんか？ エクスポートテンプレートがエディタのバージョンと一致していません。Manage Export Templatesで入れ直してください。
4. C#のプロジェクトではありませんか？ Godot 4ではC#のプロジェクトをWebにエクスポートできません。WebビルドにはGDScriptのプロジェクトが必要です。
5. .wasm ファイルが誤ったタイプで配信されていませんか？ ホストによっては一般的なダウンロードとして送信します。application/wasm のContent-Typeを設定してください。

Webエクスポートの失敗のほとんどは、この5つのどれかです。

ブラウザでは同じように動かないもの

Webビルドは、デスクトップ版にURLを付けただけのものではありません。いくつかの点で動作が異なります。

• セーブデータ はディスク上のフォルダではなくブラウザのIndexedDBに保存され、データを保持するにはプレイヤーがサイトのストレージを許可する必要があります。ポータルのiframe内ではサードパーティストレージが必要になる場合があるので、実際に使うホストでセーブをテストしてください。
• オーディオ は、プレイヤーがクリック、タップ、キー入力をするまで再生されません。ブラウザが自動再生をブロックするためです。「クリックしてスタート」の画面を用意すれば解決します。
• ネイティブプラグイン（デスクトップ向けにコンパイルされたGDExtensionライブラリ）は、Webビルドが同梱されていてExtensions Supportが有効でない限り読み込まれません。
• C# はGodot 4ではWebにエクスポートできません。
• レンダリング はWebではCompatibilityレンダラー（WebGL 2）を使うため、Forward+やMobileで作ったプロジェクトは見た目が変わります。SDFGI、ボリュメトリックフォグ、スクリーンスペースリフレクションなどのエフェクトは描画されません。Web向けのゲームは最初からCompatibilityで作り、エディタで見えるものがそのまま出荷されるようにしましょう。Summer独自のWebテンプレートは異なり、WebGPUとForward+またはMobileを使います。
• 読み込みサイズはほかのどこよりも重要です。 プレイヤーはゲームが始まる前に、エンジン、データパック、すべてのアセットをダウンロードします。Pokiの開発者ガイドによると、読み込みに10秒以上かかるとプレイヤーはたいてい離れてしまうので、最初のダウンロードは小さく保ってください。

Summer EngineとWebエクスポート

Summer Engine は、Godot 4のワークフローをそのまま使えるmacOSとWindows向けのデスクトップエンジンで、普段の言葉からシーン、スクリプト、アセットを作るAIを備えています。ゲームのデスクトップ版をビルドでき、Steamで販売したり、ダウンロード版としてitch.ioにアップロードしたりできます。Webビルドの書き出しにも対応しています。

エンジン0.7以降、エディタにはSummer独自のWebエクスポートテンプレートが含まれており、WebGPUとForward+またはMobileレンダラーを使います。WebエクスポートはGDScriptのプロジェクトで使えます。C#を使うプロジェクトはWebにエクスポートできません。これはGodot 4と同じ制限です。Webビルドはルートにindex.htmlがある標準的な静的.zipです。Summer Games に公開すると、ブラウザでプレイしてもらえます。Summer Gamesは、上で説明したCompatibilityレンダラーによるGodot標準のWebエクスポートも受け付けます。エージェントはMCPツールのsummer_export_game（ターゲットはweb）とsummer_publish_buildで、この2つの手順を行えます。

今日からSummerでゲームを作り始めるなら、移動とカメラがすでに組み込まれた テンプレート から始め、その上に加えたいメカニクスを言葉で説明し、うまく遊べるようになったらビルドをエクスポートしてください。