unityroomの使い方：投稿から公開までの流れ

WebGLビルドを用意する前に確認すること

unityroomへの投稿には、UnityプロジェクトをWebGL向けにビルドしたファイル一式が必要です。デスクトップ向けの実行ファイル（.exe など）はそのままでは使えません。

まずUnity Hubでインストール済みのUnityバージョンにWebGL Build Supportモジュールが追加されているかを確認します。Unity Hubの「インストール」タブから対象バージョンの歯車アイコンを開き、「モジュールを加える」からWebGL Build Supportを追加できます。モジュールが入っていない状態でビルドしようとするとターゲット選択肢にWebGLが表示されないため、最初に確認しておくと時間を節約できます。

次に、ゲーム内で使っている素材（フォント・音源・画像）のライセンスを確認します。WebGL公開は不特定多数への配布にあたるため、再配布が禁止されている素材が含まれていると後から問題になります。使用素材のライセンスを一覧にしておくと、投稿フォームの「クレジット」欄を記入するときにも役立ちます。

WebGLビルドの設定と書き出し手順

UnityエディターのメニューからFile → Build Settingsを開き、プラットフォームをWebGLに切り替えます（Switch Platformボタンが必要な場合は数分かかります）。

その後、Player Settingsで以下の点を調整します。

• Resolution and Presentation：デフォルトのキャンバスサイズを確認します。unityroomのプレイヤー表示域に合わせて縦横比を設定しておくと、公開後のレイアウト崩れを防げます。
• Compression Format：Gzip または Brotli を選択します。ただし、サーバー側の設定によっては解凍に失敗することがあります。迷った場合は「Disabled」で書き出し、ファイルサイズが問題になってから再検討する方が確実です。
• Publishing Settings → Enable Exceptions：デバッグ目的でない本番ビルドでは「Strip Engine Code」を有効にするとファイルサイズを削減できます。

Build Settingsに戻りBuildボタンを押すと、指定したフォルダにビルドファイルが生成されます。生成されるフォルダ構成は概ね次のようになります。

Build/
  ゲーム名.data
  ゲーム名.framework.js
  ゲーム名.loader.js
  ゲーム名.wasm
index.html
TemplateData/

このフォルダ全体をZIPで圧縮したものを投稿します。ZIPを作る際、フォルダを「中に入れて圧縮」するか「フォルダごと圧縮」するかで階層が変わります。unityroomが求める構造はindex.htmlがZIPの直下にある形なので、macOSのFinderで右クリック圧縮した場合はフォルダ名のZIPになってしまいます。圧縮前にフォルダ内のファイルをすべて選択してからZIPにするか、コマンドラインでzip -r game.zip .のように実行すると階層のズレを防げます。

ファイルサイズの上限については、unityroomの公式サイトで現在の条件を確認してください。大きなアセットが含まれる場合はAddressablesやアセットバンドルで外部ホストする方法もありますが、初投稿では素直に軽量化を先に試す方が手順がシンプルです。

投稿フォームの入力と注意点

アカウント登録とログイン後、「投稿する」からフォームを開きます。入力項目は多くありませんが、後から変えにくいものを先に挙げます。

ゲームのURLスラッグ（ゲームID）は一度公開すると変更できません。短く、ゲームの内容を反映した英小文字で設定します。SNSでシェアしたあとにURLが変わると、過去のリンクがすべて切れるため慎重に決めます。

タイトルとキャッチコピーは検索・一覧ページでの印象を左右します。キャッチコピーは一覧表示時にタイトルの下に出ることが多いため、「どんな体験ができるか」を一文で伝える内容にすると、クリック率が上がりやすくなります。

ジャンルとタグは、ゲームジャムへの参加作品でない場合も正確に設定します。ジャンルは後から変更できますが、タグは公開直後の検索流入に影響するため、内容を表す言葉を3〜5個程度入れておきます。

操作説明の欄はプレイヤーが最初に読む情報です。「WASDで移動、Spaceでジャンプ」のように箇条書きで具体的に書くと離脱を減らせます。スマートフォン対応の有無もここに書いておくと、スマホからアクセスしたプレイヤーへの配慮になります。

ZIPファイルをアップロードし、サムネイル画像を設定したら「非公開で保存」を選びます。すぐに公開せず、まず自分のアカウントでプレビューして動作確認するのが基本的な流れです。

公開前の動作確認と公開操作

非公開状態のゲームページには自分だけがアクセスできます。実際にブラウザでプレイしてみて以下の点を確認します。

• ゲームが正常に起動し、タイトル画面が表示されるか
• 操作が説明通りに機能するか
• スマートフォンで開いたときにレイアウトが崩れないか（対応を謳う場合）
• 音が出る場合、ブラウザの自動再生制限に引っかかっていないか

WebGLビルドでよくある問題として、ローカルでは動くのに公開環境でテクスチャや音声が読み込まれないケースがあります。これはビルド時のパス設定やCompressionの設定に起因することが多く、Disabled圧縮に変えて再ビルドすると解決する場合があります。

ブラウザのデベロッパーツール（F12）のコンソールにエラーが出ていないかも確認します。「Failed to load resource」や「CORS error」が出ていれば、ファイル構成かサーバー設定の問題です。

動作確認が終わったら、編集ページから「公開する」に切り替えて保存します。公開後はunityroomのゲーム一覧に表示され、プレイ数やコメントが記録されるようになります。初期状態では新着順に表示されるため、公開直後がもっともアクセスが集まりやすいタイミングです。SNSへのシェアはこのタイミングで行うと効果的です。

公開後に確認・調整できること

公開後も編集ページからほとんどの項目を変更できます。バグを修正してZIPを差し替えることも可能で、URLは変わりません。説明文やタグの修正、サムネイルの変更も同じ操作で行えます。

コメント欄は公開後に受け取るフィードバックの主な窓口です。「操作が分からなかった」「◯◯のステージでフリーズした」といった声は次の改善に直結します。通知設定を有効にしておくとコメントを見落としにくくなります。

ゲームジャムに参加している場合は、提出期限と「提出済み」にする操作が別途存在します。ゲームを公開しただけでは参加扱いにならないケースがあるため、ジャムのルールページで手順を確認してください。

次の行動

unityroomへの初回投稿では、まずUnityのWebGLモジュールが入っているか確認し、軽量なテスト用プロジェクトでビルド〜投稿の流れを一度通しておくと本番で詰まりにくくなります。ブラウザゲームをZIPで投稿して公開する仕組みはアソバース（https://aso-verse.com）でも同様に利用できるため、複数のプラットフォームに並行投稿して反応を比べてみるのも一つの選択肢です。ファイルサイズ上限やアップロード仕様は変わることがあるため、投稿前に各プラットフォームの公式情報で最新の条件を確認してください。