【Firebase】Unity WebGLを無料で公開する手順

投稿日: 2026年4月28日（2026年10月5日更新）
対象読者: Unity WebGL のビルドを Web に公開したいエンジニア

この記事はこんな方向け:

Unity WebGL を Firebase Hosting で公開したい方
firebase.json に Content-Encoding: br を書いたのに、読み込みエラーが出る方
無料枠でどれくらいのアクセスまで耐えられるのか知りたい方

手順の全体像

Firebase Hosting で Unity WebGL を動かすなら、Decompression Fallback を有効にしてビルドします。圧縮形式は Brotli のままで構いません。PoseMirror（Firebase Hosting で公開している Unity WebGL アプリ）の本番を測ると、firebase.json に書いた Content-Encoding: br は、指定どおりには返っていませんでした。Decompression Fallback を有効にしておけば、ヘッダーがどう返っても Unity が自分で展開するので動きます。

無料プラン（Spark）の転送量は、1日あたり 360MB までです。

はじめに

Unity WebGL を公開する解説では、「.br ファイルに Content-Encoding: br を付ければ、ブラウザが展開してくれる」とよく書かれています。Unity の公式マニュアルも、サーバーがこのヘッダーを付けることを前提に説明しています。

ところが Firebase Hosting では、このヘッダーを firebase.json に書いても、そのとおりには返りませんでした。この記事では、PoseMirror の本番で測った応答をもとに、Firebase Hosting で動く設定と公開までの手順をまとめます。

Firebase Hosting の無料枠

Firebase Hosting は、Google の静的サイトのホスティングです。無料の Spark プランの上限は次のとおりです（Firebase の料金ページ、2026年10月確認）。

項目	Spark プラン（無料）
保存容量	10GB
転送量	1日 360MB
独自ドメインと SSL	使える

このうち先に効くのは、1日 360MB の転送量です。PoseMirror の Unity のファイルは合わせて 10.43MB あります。初めて訪れる人だけで数えると、1日に約34人で上限に届きます（360 ÷ 10.43 ≒ 34.5）。2回目以降はブラウザのキャッシュが使われるので、この計算より多くの人を受けられます。

kabe-tech.com は、課金などのサーバー処理に Cloud Functions も使うため、従量課金の Blaze プランにしています。

事前準備：Unity のビルド設定

Player Settings → Publishing Settings で、次の2つを設定します。

項目	設定	理由
Compression Format	Brotli	3つの選択肢（Disabled／Gzip／Brotli）の中でファイルが最も小さい
Decompression Fallback	有効	Firebase Hosting がヘッダーを指定どおりに返さないため

Decompression Fallback を有効にすると、Unity はビルドに展開用の JavaScript を入れ、ファイル名の末尾を .unityweb にします。ブラウザが展開しなかったファイルは、この JavaScript が展開します。

代わりに、起動が少し遅くなります。マニュアルにも、ブラウザに展開させるほうが速いと書かれています。ヘッダーを正しく返すローカルの試験サーバーで PoseMirror を測ると、Decompression Fallback では起動に 944ms かかりました。ブラウザに展開させると 677ms です。ただ、Firebase Hosting ではこの速いほうの形を実現できていません。

本番用のビルドでは、Development Build はオフにします。

手順①：Firebase プロジェクトを作る

Firebase Console を開く
「プロジェクトを追加」を押す
プロジェクト名を入れる（例: pose-mirror-app）
Google Analytics の設定（使わないなら飛ばしてよい）
「プロジェクトを作成」を押す

作ると、your-project-id.web.app の URL が割り当てられます。

手順②：Firebase CLI でログインと初期化

# Node.js が必要
npm install -g firebase-tools

firebase login

# 公開するフォルダの1つ上で実行する
firebase init hosting

初期化の途中で、次のように答えます。

? Which Firebase project do you want to configure?
  → 作成したプロジェクトを選ぶ

? What do you want to use as your public directory?
  → public  （Unity のビルドを置くフォルダ）

? Configure as a single-page app (rewrite all urls to /index.html)?
  → No

手順③：firebase.json にヘッダーを書く

Decompression Fallback を有効にしたビルドでは、ファイル名が .unityweb で終わります。拡張子からファイルの種類が分からないので、Content-Type を書いておきます。PoseMirror では次のように書いています。

{
  "hosting": {
    "public": "public",
    "headers": [
      {
        "source": "**/Build/*.framework.js.unityweb",
        "headers": [{ "key": "Content-Type", "value": "application/javascript" }]
      },
      {
        "source": "**/Build/*.wasm.unityweb",
        "headers": [{ "key": "Content-Type", "value": "application/wasm" }]
      },
      {
        "source": "**/Build/*.data.unityweb",
        "headers": [{ "key": "Content-Type", "value": "application/octet-stream" }]
      }
    ]
  }
}

PoseMirror の firebase.json には、.unityweb 全体に Content-Encoding: br を付ける指定も書いてあります。本番の応答を取ると、その指定は次のようにしか返っていませんでした（2026年10月5日に curl で確認）。

ファイル	指定した Content-Encoding	実際に返った Content-Encoding
`.wasm.unityweb`	br	br
`.data.unityweb`	br	gzip
`.framework.js.unityweb`	br	なし

.wasm の br も、こちらの指定が通ったものではありません。Unity が Brotli で圧縮したファイルを、Firebase Hosting がさらに自分で圧縮し直して返したものです。ブラウザはその外側の圧縮だけを解くので、中身は Unity の Brotli のまま残ります。結局、展開しているのは Decompression Fallback の JavaScript です。

このとき、ブラウザのコンソールには Unity から次の案内が出ます。Decompression Fallback で動いているという意味で、エラーではありません。

You can reduce startup time if you configure your web server to add "Content-Encoding: br" response header when serving "...unityweb" file.

圧縮をやめて（Compression Format を Disabled にして）Firebase Hosting に圧縮を任せる方法も試しました。Firebase Hosting は大きなファイルを gzip で返したため、転送量は 10.33MB から 13.59MB に増えました。10Mbps の回線では、起動が 9.6秒から 11.4秒に遅くなっています。詳しくはパフォーマンス改善の記事に書いています。

手順④：デプロイして応答を確かめる

firebase deploy --only hosting

成功すると、最後に Hosting URL: https://your-project-id.web.app が出ます。ブラウザで開いて Unity が起動すれば公開は完了です。

返っているヘッダーは curl でも確かめられます。

curl -s -o /dev/null -D - -H "Accept-Encoding: br, gzip" \
  https://your-project-id.web.app/Build/your-build.wasm.unityweb

手順⑤：独自ドメインをつなぐ（任意）

Firebase Console の Hosting の画面で「カスタムドメインを追加」を選び、ドメイン名を入れます。表示された DNS レコード（TXT と A）を、ドメインの DNS に追加します。SSL 証明書は Firebase が発行し、更新もします。

kabe-tech.com は DNS を Cloudflare で管理しています。Cloudflare では、Firebase の A レコードをプロキシしない設定（DNS only、雲のアイコンが灰色）にしています。プロキシを通すと、Firebase 側の証明書の更新が通らないためです。

よくある不具合と対処

「Unable to parse … The file is corrupt, or compression was misconfigured」と出る

Unity のローダーが、届いたファイルを解釈できなかったときのエラーです。Decompression Fallback が無効のビルドで、サーバーが Content-Encoding を返していないと、このエラーになります。Firebase Hosting では、Decompression Fallback を有効にしてビルドし直してください。

デプロイしたのに古いバージョンが表示される

ブラウザが古いファイルをキャッシュしていることがあります。シークレットウィンドウで開くか、Ctrl+Shift+R で強制的に読み直して確かめます。

PoseMirror では、Unity のファイルの URL の末尾に、中身から作った値（?v=…）を付けています。中身が変わると URL も変わるので、利用者のブラウザが古いファイルを使い続けることがありません。ローダーと本体のファイルの組み合わせがずれて起動に失敗する事故も、これで防いでいます。

`firebase init` のあとにヘッダーの指定が消えた

firebase init を再び実行すると、firebase.json が書き換わることがあります。実行したあとは、書いたヘッダーの指定が残っているかを確かめてください。

まとめ

Firebase Hosting に Unity WebGL を置くとき、迷うのは圧縮の扱いだけです。Content-Encoding のヘッダーは指定どおりに返らないので、Unity 側の Decompression Fallback を有効にしてビルドします。起動は少し遅くなりますが、ヘッダーがどう返っても動きます。無料枠の1日 360MB は、ビルドのサイズで割って、何人まで受けられるかを先に見積もっておくと安心です。

この手順で公開しているのが、PoseMirror です。

この手順で公開したのが、このアプリです。

Firebase Hosting 上の Unity WebGL の動作を確認できます。

▶ この構成で公開しているWebアプリを見る

関連記事：

【Unity】Webアプリで表示するための軽量化方法：Unity のビルドサイズの削減
【Unity WebGL】PoseMirrorのパフォーマンス改善3つのアプローチ：圧縮方式を変えたときの実測
【Unity WebGL】MediaPipeで3Dポーズを動かす：Unity WebGL の実装解説

参考資料

← Kabe-Tech トップへ