これまでUnrealの描画設定やUnrealの夜景づくりを、パワーのあるPC（Windows / RTX3060）で扱ってきました。今回はそのUnreal Engineの3Dシーンを、スマホ（Android）向けに書き出して動かすのに挑戦します。テーマは2つ。①モバイル向けの軽量化手法を、採用したかどうかに関わらず詳しく解説すること。そして②その軽量化で負荷が実際どれだけ変わるかを、前後の数字で比べることです。
・UEの3DシーンをAndroidに書き出す（パッケージング）大まかな流れ
・Android SDK/NDKの壁と、エミュレータではUEがまともに描画できないという大きな落とし穴（実話）
・モバイル軽量化の手法を採否に関わらず詳しく（Macでもできる設定を明示）
・軽量化前後の負荷を、モバイル描画パスで実測した相対比較（FPS +58% / GPU時間 −56%）
今回の負荷の数字は、後述の事情でAndroidエミュレータではなく、UEの“モバイル描画パス（ES3.1）”をPC（RTX3060）上で走らせて計測しています。つまり「同じ条件で軽量化の前後を比べた相対的な効き具合」であって、「この数値がそのままスマホ実機で出る」ものではありません。絶対性能を測るには本来スマホ実機が要りますが、今回は実機を使わない前提です。相対比較として読んでください。
やりたいこと：重いUEをスマホで、軽量化を数字で
Unreal Engineは「きれいだけど重い」というイメージがあります。実際、MacでUEを動かした回では“全部盛り”で相当重くなりました。ではその重いシーンをスマホで動かすには何を削ればいいのか、そして削ると実際どれくらい軽くなるのか——これを手を動かして確かめます。
題材は、Unreal標準のサードパーソン・テンプレートの床に、Starter Contentのメッシュを256個並べ、動く影つきのライトを7個置き、ポストプロセス（Bloomなどの後処理）も効かせた、そこそこ重いシーンです。これを「軽量化前（重い状態）」として、ここから軽くしていきます。
先に結論：軽量化でどれだけ変わったか
結論から。同じシーン・同じ視点で、軽量化の前後を計測した結果がこちらです。FPS（1秒あたりの描画回数。大きいほど滑らか）は約1.6倍、GPU時間（1フレームを描くのにかかる時間。小さいほど軽い）は半分以下になりました。
| 項目 | 軽量化前 重い状態 |
軽量化後 全部盛りで軽量化 |
変化 |
|---|---|---|---|
| FPS（滑らかさ・大きいほど良い） | 333.6 | 526.8 | +58% |
| フレーム時間 Frame（ms・小さいほど良い） | 2.92 | 1.91 | −35% |
| GPU時間（ms・小さいほど良い） | 2.45 | 1.09 | −56% |
| Draw（CPUが描画命令を出す時間 ms） | 2.85 | 1.90 | −33% |
| Draws（ドローコール＝描画命令の数） | 139 | 72 | −48% |
| Prims（描いた三角形の数） | 585K | 237K | −59% |
計測：UEのモバイル描画パス（PCD3D_ES31）をRTX3060上で実行、1280×720・固定視点。前＝Mobile HDR ON＋影・ポストプロセスあり／後＝Mobile HDRオフ＋影オフ＋ポストプロセスオフ＋エフェクト低。実機の絶対値ではなく相対比較です。
ドローコール（描画命令の数）と三角形の数が約半分になり、GPU時間が半分以下になっています。「重い」と言われるUEでも、削るべき所を削れば大きく軽くなる——これが今回の一番の結論です。以降で「どうやって書き出したか」「なぜエミュレータで測れなかったか」「何を削るとどれだけ効くか」を順に見ていきます。
UEをスマホに書き出す（Androidパッケージング）
UEでスマホアプリを作るには、シーンをAndroid用にパッケージング（＝APKという配布ファイルに書き出す）します。大きな流れはこうです。
- Android用の道具をUEに用意する：Android SDK / NDK / JDK（Androidアプリをビルドするための一式）を入れ、UEに場所を教える
- プロジェクト設定でAndroid向けの項目を決める：テクスチャの圧縮形式（今回はETC2）、向き（横）、描画方式（Vulkan など）
- Platforms > Android からパッケージング：しばらく待つとAPKができる
APKのビルド・インストール・起動そのものは成功しました（容量はおよそ150〜160MB）。ところが——ここからが今回の本題です。「作れた」のに「エミュレータでまともに動かせない」という壁にぶつかりました。
つまずき①：Android SDK/NDKの壁
まず、パッケージングにたどり着くまでに環境まわりで3つつまずきました。ここはUEのモバイル開発で誰もが通る所なので、具体的に残します。
- NDKのバージョン不一致：UE 5.7はNDK r27c（27.2.12479018）という特定のバージョンを要求します。PCに入っていたのは別バージョンだったので、UE同梱の
SetupAndroid.batで指定バージョンを入れ直しました。事前にsdkmanager --licensesで使用許諾を全部承認しておかないと、途中で止まります。 - 環境変数が引き継がれない：SetupAndroidはSDK/NDKの場所を「ユーザー環境変数」に書きますが、すでに起動していたツールはその変更を見てくれません。ビルド用のシェルで
ANDROID_HOMEやNDKROOTを明示的に指定して解決しました。 - テンプレートが“コード扱い”でビルド失敗：使ったテンプレートに含まれる一部プラグインのせいで、UEが「Androidをソースコードからビルドしよう」として失敗（
Platform Android is not a valid platform to build）。不要なプラグインを外してコンテンツだけの構成にすると、あらかじめコンパイル済みの本体が使われ、ソースビルド不要でパッケージングできました。
ここは「モバイル書き出しは、まずSDK/NDKの土台づくりが半分」という良い教訓でした。UEが要求するNDKのバージョンはUEのバージョンごとに決まっているので、そこを合わせるのが最初の関門です。
つまずき②：エミュレータでUEが描画できない（今回最大の学び）
当初の計画は「Androidエミュレータ（PC上で動く仮想のスマホ）でAPKを動かし、負荷を測る」でした。ところがAPKはインストールも起動もできるのに、肝心の画面が描画できないという壁に当たりました。エミュレータに出たのがこのエラーです。
原因を平たく言うと、Androidエミュレータの“描画エンジン”がUEの要求に届かないためです。何パターンか試しました。
- OpenGL（ホストGPU経由）：UEがテクスチャを作る所でクラッシュ（NVIDIAの変換ドライバとの相性）。
- OpenGL（ソフトウェア描画＝SwiftShader）：ES 3.1止まりで、UEが要求するES 3.2以上に届かず拒否（上のエラー画面がこれ）。
- Vulkan：ホストGPUのVulkanが素通しされず、CPUによるソフトウェアVulkanに落ちてしまい、起動ロゴから先に進むのに数分かかる“実用外”の遅さ。重いシーンではドライバごと落ちることも。
Androidエミュレータは“本物のスマホGPU”を積んでいません。PCのGPUを変換して使うか、CPUで描画のまねをするだけ。だからUEのような重い3Dエンジンの負荷検証には、エミュレータは基本的に向きません。UEの負荷やモバイル表現を本気で確かめたいならスマホ実機が必要——これは机上では気づけない、手を動かして初めて分かる大事な現実でした。
だから“モバイル描画パス”で軽量化前後を計測した
とはいえ、今回の目的は「軽量化で負荷がどう変わるか（＝相対比較）」を見ることです。実機がなくても、これは測れます。UEには「モバイルと同じ描画のやり方（モバイル描画パス、ES3.1）をPC上でプレビューする」機能があります。そこで、この“モバイルの描き方”をRTX3060上で走らせ、軽量化の前と後で同じ視点の負荷を計測しました。
下が「軽量化前」の画面です。右側に出ているのが負荷の数字（stat unit）。FPS 333、GPU時間 2.45ms、ドローコール 139、と表示されています。床や壁のメッシュに動的な光と影が当たった、リッチな見た目です。
この状態から、次章の軽量化手法を適用していきます。「モバイルの描き方のまま、設定だけを軽くしていく」ので、軽量化の効き具合を素直に比べられます。なお、この“モバイル描画パスでの計測”と、これから紹介する軽量化設定の大半はMacでも同じように操作できます（実機に近い重さを測るのはWindows/実機、設定づくりと相対比較はMacでも可能、という切り分けです）。
軽量化手法カタログ（採否に関わらず詳しく）
ここが記事の本体です。今回採用したかどうかに関わらず、モバイル向けの軽量化手法をひととおり解説します。★印は、Android SDKやWindowsやPCのパワーに依存せず、エディタの設定だけで効く＝Macでも同じ操作でできる手法です。
| 手法 | 何をする / なぜ軽くなる | Mac可 |
|---|---|---|
| ① スケーラビリティ | 影・ポストプロセス・テクスチャ・エフェクト等の品質を一括で下げる（sg.*）。まず最初に触る“総合ダイヤル”。 | ★ |
| ② Mobile HDR オフ | モバイルの描画を「HDR（高精度な明るさ）」から「LDR（普通）」へ。後処理と帯域が軽くなり、モバイルで最も効くことが多い。見た目は素っぽくなる。 | ★ |
| ③ 影・シャドウを削る | 動的な影は“もう一度シーンを描く”のに近い重さ。品質を下げる／距離を縮める／可能ならベイク（焼き込み）済みの影に。今回いちばん効いた。 | ★ |
| ④ ポストプロセスを切る | Bloom（光のにじみ）/ SSR（画面反射）/ SSAO（陰影）/ モーションブラー等の後処理を弱める・切る。画面全体を何度もなめる処理なので効く。 | ★ |
| ⑤ 解像度スケール | 描画する解像度を70〜80%などに下げる（r.MobileContentScaleFactor / r.ScreenPercentage）。負荷は解像度の“2乗”で効くので、下げると効果大。 | ★ |
| ⑥ ドローコール削減 | 物をまとめて描く。メッシュの結合（Merge Actors）やインスタンス化（同じ物を一括描画）、マテリアル数を減らす。物量シーンで効く。 | ★ |
| ⑦ LOD・カリング | 遠くの物は簡略モデルに差し替え（LOD）、見えない/遠すぎる物は描かない（カリング距離）。 | ★ |
| ⑧ テクスチャ圧縮・縮小 | Android向けはASTC/ETC2で圧縮。最大サイズを下げる、ミップマップを使う。メモリと帯域に効く。 | ★ |
| ⑨ 草・パーティクル密度 | フォリッジ（草木）やエフェクトの量・表示距離を下げる。数が効くタイプ。 | ★ |
| ⑩ パッケージ容量削減 | 未使用アセットをCookしない、Starter Contentを外す、テクスチャストリーミング。速さより配布サイズの話。 | △ |
今回は主に②Mobile HDRオフ・③影オフ・④ポストプロセスオフ・①スケーラビリティ低を適用しました。⑤解像度スケールや⑥⑦⑧は「効く仕組み」を押さえたうえで、シーンや目的に応じて足していく引き出しです。大事なのは“全部やる”ことではなく、重い所（影・後処理・解像度）から順に削ることです。
効果が大きかった手法トップ3
「どれがどれだけ効いたか」を切り分けるため、手法を1つずつ足して計測しました。
| 状態 | GPU(ms) | FPS | Draws | Prims |
|---|---|---|---|---|
| 軽量化前（全部ON） | 2.45 | 333.6 | 139 | 585K |
| ＋Mobile HDRだけオフ | 1.93 | 359.3 | 128 | 610K |
| ＋影・後処理も全部オフ | 1.09 | 526.8 | 72 | 237K |
- 影を切る：ドローコール139→72、三角形585K→237Kと、描く仕事そのものが最大に減りました。動的な影は「もう一度シーンを描く」のに近いので、切ると一気に軽くなります。
- Mobile HDRオフ：これ単体でGPU時間が2.45→1.93ms（約21%減）。ピクセルを塗る負担と帯域が下がります。
- ポストプロセスオフ：HDRをオフにした後の“残り”を削る後処理。画面全体をなめる処理が減ります。
順位から分かるのは、モバイルでは「影」と「明るさ処理（HDR）」と「後処理」が3大コストということ。まずこの3つを疑うのが定石です。
Lumen/Naniteは“モバイルでは土俵に上がらない”
前にUnrealの描画設定を比べた回では、Lumen（リアルタイムの映り込み・間接光）やNanite（超高精細メッシュ）が重さの主役でした。「じゃあモバイルでもそれを切れば軽くなるのでは？」と思いますよね。ところが——
これは裏を返すと、「UEはLumen/Naniteのせいで重い＝だからスマホでは無理」という思い込みは誤解だということ。モバイルでは最初からそれらを使わない、より軽い描き方に切り替わっています。スマホでUEが重くなる主因は、Lumen/Naniteではなく「影・後処理・解像度・物量（ドローコール）」——今回の計測はそれを裏づけています。
軽さの代償：見た目はどう変わるか
もちろん、軽くすればタダでは済みません。特にMobile HDRをオフにすると、明るさの表現が単純になり“白飛び”しやすくなります。下は同じシーンの「PC版フル品質」と「モバイル軽量化後」の見た目です。
白飛びは「HDRオフ＋後処理オフ」を一気にやった極端な例です。実際にはライトの明るさや露出を調整し直す・要所だけベイク影を残すなど、「軽さ」と「見栄え」の落としどころを探るのがモバイル最適化の本番です。今回はまず“どこまで軽くなるか”の振り幅を見るために、あえて振り切りました。
では実在のUE製スマホゲームはどう作っている？
ここで素朴な疑問。今回エミュレータではまともに動かせなかったのに、世の中にはUEで作られたスマホゲームが実在します（PUBG MOBILE、フォートナイトなど）。彼らはどうやっているのでしょう。調べてみると、答えは「UEに“別の仕組み”が標準で用意されていて、実機で作っている」でした。今回eightがやった手動軽量化とは、少し次元の違う話です。
① UE標準の切り札：「デバイスプロファイル」＝端末ごとに画質を自動で切り替える
今回、eightは1つのシーンの設定を手で切り替えて軽くしました。でも実際のスマホゲームは、アプリが起動したときに“今動いている端末”を自分で見て、その端末に合った画質を自動で選ぶ——という仕組みを使っています。これがUEに最初から入っているデバイスプロファイルです。
UEには標準で Android_Low / Android_Mid / Android_High という段階に加え、GPUの系統ごとのプロファイル（例：Adreno5xx系、Mali系）が用意されています。起動時にエンジンが端末の特徴を読み、合致するプロファイルを選んで、影・解像度・後処理などの品質を一括で適用します。しかも実行中も、ゲーム内の「グラフィック設定」メニューから切り替えられます。
この記事で解説した軽量化手法（影・Mobile HDR・後処理…）は、実はこのデバイスプロファイルが“中身”として出し入れしている設定そのものです。つまり手で切り替えて仕組みを理解 → 本番はデバイスプロファイルで端末ごとに自動化、という関係。今回学んだことは、実際のスマホゲーム開発の土台に直結しています。
② UEに“最初から入っている”モバイル最適化
独自にプログラムを書かなくても使える、UE標準のモバイル向け機能もひととおり揃っています。
- モバイル専用の描画方式：軽いForward（前方）シェーディングが既定。UE5では多灯・反射に強い「Mobile Deferred」も選べる
- ベイク（焼き込み）照明：光と影をあらかじめ焼き込む方式。動かない光は実行時ほぼ無償。出荷されているモバイルUEゲームの照明はこれが基本（＝前章のとおりLumenは使わない）
- HLOD：遠くにある複数の物を1つにまとめて描き、描画命令（ドローコール）を減らす
- テクスチャストリーミング／ASTC・ETC2圧縮／オクルージョンカリング（見えない物は描かない）
- 動的解像度＋FSR：重い場面だけ解像度を自動で落として超解像で補う（モバイル対応）
公式はドローコールの予算まで示していて、「そこそこのタブレットで約700、低スペック機では500未満」が目安。マテリアルの複雑さやテクスチャの枚数にも具体的な指針があります。
③ 大手タイトルは“標準の上に独自”を積む（PUBG MOBILEの例）
では超大作はどうか。PUBG MOBILE（開発：LIGHTSPEED／Tencent）のエンジン責任者によるGDC講演が具体的でした。
- 対応端末は22,000機種超、うち低スペック機が55%超という桁違いの幅の広さ
- UE標準のデバイスプロファイル／スケーラビリティを土台にしつつ、自社製のプロファイリングツール（GPU・CPUだけでなく“端末の温度”まで監視）を独自開発
- 最適化を4本柱で整理：①読み込みを減らす ②描画を減らす ③軽量な描画 ④毎フレーム処理を滑らかに
- 低スペック機と高性能機で別々の最適化ルートを用意（一律にしない）
つまり実在のUE製スマホゲームは、「UE標準の自動最適化（デバイスプロファイル）を使いつつ、規模に応じて端末分類・発熱対策・自社計測ツールといった独自の仕組みを足している」——というのが実態でした。
出典：UE公式「Customizing Device Profiles and Scalability for Android」／UE公式「Optimization and Development Best Practices for Mobile」／UE公式「Mobile Rendering and Shading Modes」／PocketGamer.biz「PUBG Mobile co-developer on optimising Unreal for thousands of phone types」
再現に必要な設定
- Unreal Engine：5.7.4 で確認（p931・p932と同系）
- Android一式：UE 5.7が要求するNDK r27c（27.2.12479018）／build-tools 35.0.1 ／platform android-34 ／JDK 21。
SetupAndroid.batでバージョンを合わせるのが要点 - プロジェクト構成：Third Personテンプレをコンテンツのみに（不要プラグインを外す）。テクスチャ圧縮＝ETC2、向き＝横、Development構成
- 軽量化の設定：Mobile HDR＝Project Settings > Rendering > Mobile。影・後処理・エフェクトはスケーラビリティ（Settings > Engine Scalability、または
sg.ShadowQuality=0／sg.PostProcessQuality=0など）でまとめて調整 - 負荷の確認：
stat unit・stat fpsで画面に表示。モバイルの描き方で見るならモバイル描画パス（ES3.1）でのプレビューを使う - 負荷の“本番”検証：エミュレータではUEはまともに描画できないため、実機（Android端末）を推奨
まとめ
Unreal Engineの3Dシーンをスマホ（Android）向けに書き出し、軽量化の前後を数字で比べました。ポイントを整理します。
- UEのAndroid書き出しはSDK/NDKの土台づくりが半分。UEごとに要求NDKバージョンが決まっている
- Androidエミュレータは本物のスマホGPUを積んでおらず、UEの重い描画は実用速度で動かない。負荷の本番検証は実機推奨（今回いちばんの学び）
- 軽量化は「影・明るさ処理(HDR)・後処理・解像度・物量」から削るのが定石。今回はモバイル描画パスでの相対比較でFPS+58%・GPU−56%
- Lumen/Naniteはモバイルでは元々使われないので「UEはそれで重い＝スマホでは無理」は誤解
- 軽さには見た目の代償（白飛び・立体感減）。落としどころ探しが最適化の本番
そして、ここで紹介した軽量化設定の多く（★の手法）は、実はMacのエディタでもそのまま操作できます。「実機に近い重さを測る」のはWindowsや実機が要りますが、「軽量化の設計と相対的な効きの確認」はMacでも十分やれる——この切り分けが分かると、手持ちの環境でモバイル最適化の練習を始められます。
それでは、今回はここまで。最後までありがとうございました😊