Unity WebGLでスマホ対応は可能か：動作検証とパフォーマンス
遊びをつくる執筆にClaudeを使用しています。
Unity WebGLビルドをスマートフォンで動かしたいと思ったとき、最初にぶつかる壁は「そもそも動くのか」という疑問です。結論から言えば、動作はしますが、PCブラウザと同じ品質は期待できません。スマホのWebGLサポートは年々改善されていますが、メモリ制限・GPU性能・タッチ入力の扱いという三つの壁が常につきまといます。 この記事では「動くかどうか」よりも一歩踏み込んで、どういう条件で動き、どこで止まり、どう対処するかを整理します。公開を前提にした判断基準と、実際にビルド設定を調整する手順を中心に話を進めます。
スマホブラウザのWebGL事情
iOSのSafariはWebGL 1.0を長らく使い続けており、WebGL 2.0への対応はiOS 15以降から段階的に進んでいます。Androidは機種によってばらつきが大きく、Chrome for AndroidはWebGL 2.0に対応しているものの、GPUドライバの実装品質は端末ごとに異なります。
Unityが生成するWebGLビルドは、デフォルトでWebGL 2.0をターゲットにしています。Unity 2021以降のバージョンでは「Graphics API」の設定でWebGL 1.0へのフォールバックが難しくなっており、iOS Safari 14以前では正常に起動しないケースがあります。ターゲットにするOSバージョンの下限を決めてからビルド設定を選ぶ必要があります。
もう一つ見落とされがちなのがメモリです。スマホブラウザはタブ全体に割り当てられるメモリが厳しく制限されており、iOSのSafariはとくにその傾向が強いです。UnityのWebGLビルドは初期ヒープサイズをPlayer Settingsで指定しますが、この値が大きすぎるとSafariがページを強制終了します。一般的な目安として、モバイルを意識するなら初期ヒープは256MB以下に抑えることが推奨されています（Unityの公式ドキュメントでも注意書きがあります）。
パフォーマンスを左右する三つの要因
シェーダーとドローコール
スマホGPUはデスクトップGPUとアーキテクチャが異なります。タイルベースのレンダリングを採用しているため、ドローコール数が多いと極端に遅くなります。Unity標準のUniversal Render Pipeline（URP）を使っている場合でも、マテリアルのバリアント数が多いとシェーダーのコンパイル時間がロード直後に集中し、フリーズしているように見えます。
対策としては次の三点が有効です。
- Static Batching / GPU Instancingを活用してドローコール数を減らす：動かない背景オブジェクトはStatic Batchingでまとめると、一度のドローコールで描画できます。
- シェーダーバリアントを削減する：使っていないキーワードを#pragma shader_featureから#pragma multi_compileに整理し、Shader Variant Collectionで必要な組み合わせだけを事前コンパイルします。
- テクスチャ圧縮形式をETC2またはASTC（モバイル向け）にする：WebGLビルドではDXT（S3TC）が標準ですが、これはモバイルGPUのネイティブ圧縮ではありません。UnityのWebGLビルドはテクスチャをDXTで出力するため、モバイルGPU上でデコードのオーバーヘッドが発生します。これを完全に回避する方法はWebGLビルドの制約上難しいですが、テクスチャの解像度を下げてサイズ自体を減らすことがもっとも直接的な対処になります。
ロード時間とファイルサイズ
モバイルネットワーク環境でのロードは、ファイルサイズが直接体験品質に影響します。Unity WebGLのビルドサイズは何も設定しないと数十MBになることも珍しくありません。
圧縮設定は「Brotli」を選ぶとファイルサイズを最も小さくできますが、サーバー側でContent-Encodingヘッダーの設定が必要です。設定が合わない場合はブラウザがファイルをデコードできず、黒画面のまま止まります。ホスティング先がカスタムヘッダーを設定できない環境なら「Gzip」か「Disabled」を選び、ビルド後のファイルを確認するほうが確実です。アソバースを含む多くのゲーム公開プラットフォームでは、アップロード後の動作確認をスマホ実機で行うことを強くおすすめします。
タッチ入力の扱い
UnityのInput SystemはモバイルWebGLでもタッチイベントを受け取れますが、古いInput Manager（Input.GetMouseButtonなど）でもポインターイベントに変換されて動くことが多いです。ただしマルチタッチや長押しが絡むと挙動が不安定になりやすいです。
新しいInput Systemを使っている場合、Touchscreen.currentでタッチ入力を取得できますが、WebGLビルドではEnhancedTouchSupport.Enable()を明示的に呼ばないとTouchクラスが機能しません。これを忘れると「PCでは動くのにスマホで反応しない」という状態になります。
また、スマホブラウザはスクロールやピンチズームのデフォルト動作を持っており、ゲームキャンバス上でのタッチが誤ってブラウザのジェスチャーとして解釈されることがあります。Unityのテンプレートファイル（index.html）にtouch-action: noneのCSS指定を追加することで、ブラウザのタッチ干渉をある程度抑えられます。
動作確認の進め方
実機テストは可能な限り早い段階で始めることが大切です。エディタ上での動作確認とWebGLビルドの動作は異なり、さらにPCブラウザとスマホブラウザでも挙動が変わります。
確認の順序として次のステップが現実的です。
- 最小構成でビルドしてスマホで開く：コンテンツが何も入っていない状態でビルドし、対象のスマホブラウザで起動確認だけを行います。ここで止まるなら設定の問題です。
- ヒープサイズを256MB以下に設定する：Player Settings → Publishing Settings → Memory Sizeで調整します。
- 実際のアセットを段階的に加える：一度にすべてを入れず、モデル・テクスチャ・音声を順番に追加し、どの段階でパフォーマンスが落ちるかを特定します。
- ブラウザのDevToolsでメモリとフレームレートを計測する：ChromeのPerformanceタブやSafariのWeb Inspectorを使えば、ガベージコレクションの頻度や描画のボトルネックを把握できます。
- 機種を複数台で試す：iPhoneとAndroidで挙動が異なることはよくあります。最低でもiOS Safari最新版とChrome for Androidの二環境で確認します。
スマホ対応の現実的な判断基準
Unity WebGLでスマホ対応を「する・しない」の判断は、ゲームの内容と運用コストのバランスで決まります。
シンプルなパズルゲームや2Dカジュアルゲームであれば、ドローコール数・テクスチャサイズ・スクリプトの処理量を抑えることで、スマホブラウザでも十分に遊べる品質になります。3Dアクションや大量のパーティクルを使うゲームは、スマホを主要ターゲットにするならUnity WebGLより別の手段（React+Canvas、Phaser.jsなど）を検討したほうが現実的です。
一方で、ゲームをWebで公開する以上、スマートフォンからアクセスしてくるユーザーは無視できない割合を占めます。対応しない場合でも、スマホで開いたときに「スマートフォンには対応していません」とメッセージを表示するだけでユーザー体験は大きく変わります。Unityのビルドテンプレートをカスタマイズして、User Agentをチェックした簡単な分岐を入れるだけで実現できます。
UnityのWebGLスマホ対応は「完全対応」か「非対応」かの二択ではなく、どこまでの端末・シナリオに対応するかを設計段階で決めることが、余計な手戻りを防ぐ最善策です。
次の行動
Unity WebGLビルドをスマホで動かす前に、まずPlayer SettingsのMemory SizeとGraphics APIを確認し、iOS Safari・Chrome for Androidの両方で空ビルドが起動するかを先に試してみてください。作ったゲームを公開する場合は、アソバースにZIPファイルでアップロードしたあと、スマホ実機のブラウザで動作確認する手順を必ずビルドフローに組み込んでください。WebGLの動作環境や圧縮設定の詳細は、Unityの公式ドキュメント（Unity Manual）で最新の条件を確認することをおすすめします。
参考資料
- Unity Manual — WebGL: Deploying compressed builds
- Unity Manual — WebGL: Memory in Unity WebGL
- Unity Manual — Input System: Touch support
- MDN Web Docs — WebGL API
