エディタでは快適に動くのに、実機に入れるとカクつく。最初の10分は良いのに、遊んでいるうちに端末が熱くなってフレームレートが落ちる。プレイヤーからは「バッテリーの減りが早い」とレビューが付く——モバイル開発のあるあるです。
モバイルにはPCにない制約が2つあります。熱とバッテリーです。高負荷が続くと端末は熱暴走を防ぐためにCPU/GPUのクロックを強制的に下げ（サーマルスロットリング）、パフォーマンスがガクンと落ちます。つまりモバイルでは「動く」だけでは足りず、 「余裕を持って動く」 ことが目標になります。
この記事でわかること
- モバイル特有の制約——サーマルスロットリングとバッテリー
- 最適化の4本柱——レンダリング（GPU）・CPU・メモリ・モバイル特有対応
- 各テーマの要点と、詳細記事への入口（この記事はハブです）
- 実践：リリース前の実 機チェックを回す手順
「最初の10分は快適なのに、遊んでいるうちにカクつく」——この現象の正体がサーマルスロットリングです。熱が原因なので、起動直後の計測では絶対に見つかりません。
対策の全体像は4本柱です。負荷の種類ごとに効く手が違うので、この記事では柱ごとに要点と詳細記事への入口をまとめます。
1. レンダリング負荷の削減（GPU）
GPU負荷は発熱とバッテリー消費に直結します。描画をどれだけ軽くできるかが、サーマルスロットリング回避の第一歩です。
ドローコールの削減
CPUからGPUへの描画命令（ドローコール）が多すぎると、GPUより先にCPUが詰まります。SRP Batcherの有効化・テクスチャアトラス・スタティックバッチングが三本柱です。仕組みと使い分けは ドローコールとバッチング で詳しく解説しています。
ポリゴン数とオーバードローの管理
- ポリゴン数: モバイルの目安は画面全体で数万〜数十万。LOD（Level of Detail） で、遠くのオブジェクトを自動的に簡易モデルへ切り替えます。
- オーバードロー: 同じピクセルを1フレームに何度も塗り重ねることです。半透明のパーティクルの重なりが典型犯で、モバイルGPUの大敵です。SceneビューのDebug Draw Mode（Overdraw表示）で真っ赤な場所を探し、エフェクトの重なりを減らします。
- 解像度スケーリング: URPアセットの「Render Scale」を0.8〜0.9に下げると、UIの 鮮明さを保ったまま3D描画の負荷だけを下げられます。高解像度端末で効く即効薬です。
2. CPU負荷の削減
物理演算
- 「Project Settings > Time」のFixed Timestepを
0.02（50Hz）のまま使っているなら、物理の精度要求に応じて見直す価値があります。値を大きくすれば物理の更新回数が減り、CPUが軽くなります（UpdateとFixedUpdateの関係）。 - 動かない背景に
Rigidbodyを付けない・Layer Collision Matrix（Project Settings > Physics）で衝突不要なレイヤー同士の判定を切る、が基本の下ごしらえです。
C#コード
- GCアロケーション削減: モバイルはGCスパイクが体感に直結します。毎フレームのnew・文字列結合をなくす手筋は GC対策 へ。
- オブジ ェクトプーリング: 弾・敵・エフェクトの
Instantiate/Destroyは プーリング で撲滅します。モバイルでは必須級です。 - GetComponentのキャッシュ:
Update内のGetComponentは キャッシュが基本 です。
3. メモリ管理
メモリを使いすぎると、カクつきどころかOSにアプリごと強制終了させられます。
- テクスチャ: メモリの最大勢力です。テクスチャインポート設定で、プラットフォームごとのMax Sizeと圧縮形式（ASTC推奨） を設定します。「2048で作って、モバイルには1024で配る」といった出し分けができます。
- オーディオ: BGMなど長い曲は
Load Type: Streamingでメモリに乗せずに再生。短いSEはDecompress On Loadが定石です。 - アセットのロード管理: 「シーン＋参照で芋づる式にメモリに乗る」仕組みを理解し、必要に応じて Addressables でロードのタイミングを制御します。
4. モバイル特有の対応
- ターゲットフレームレート: モバイルでは
Application.targetFrameRateが既定で30fps相当に制限されることがあります。60fpsで動かすなら明示的にApplication.targetFrameRate = 60;を設定します。逆に、パズルゲームなど動きの少ないゲームであえて30fpsに固定するのは、発熱・バッテリー対策として立派な設計判断です。 - タッチ入力: マルチタッチやジェスチャーには、Input System のTouch対応を使うのが現行の標準です。
- セーフエリア対応: ノッチやパンチホールで隠れる領域を避けるため、
Screen.safeAreaを使ってUIのルートパネルの範囲を調整します。Canvasとアンカーの仕組み とセットで押さえてください。
実践：リリース前の実機チェックを回す
カジュアルパズルでも、3Dアクションでも、放置系でも——モバイルでリリースする以上、実機での「熱テスト」を通さずに出すのは危険です。エディタや起動直後の実機がいくら快適でも、プレイヤーは30分連続で遊びます。リリース前に最低1回、次の手順を回してください。
- 実機のリリース相当ビルドで試す: Development Buildのままだと計測オーバーヘッドが乗ります。パフォーマンス確認の仕上げはリリース設定で行います。
- ミドルレンジ端末で30分連続プレイする: 最新ハイエンドではなく、想定プレイヤー層の真ん中あたりの端末を1台用意します。10分・20分・30分時点での体感と端末の熱さをメモします。
- 落ち始めたらProfilerを接続して犯人を特定する: カクつきが出た状態のまま Profilerを実機接続 し、CPU（スクリプト・物理）とGPU（描画）のどちらが限界かを見ます。
- 4本柱のどれで殴るか決める: 描画が重いなら ドローコール削減 とRender Scale、スクリプトなら GC対策 と プーリング、メモリ警告が出るならテクスチャ圧縮——原因に対応する柱だけを叩きます。
- もう一度30分プレイする: 対策後に同じテストを繰り返し、「30分後も遊べる」ことを確認して合格です。
ポイントは2つです。 「熱の問題は時間を掛けないと再現しない」 こと（5分のテストでは何も分かりません）と、 「直す前に必ずCPUかGPUかを切り分ける」 こと。切り分けずに手を打つと、GPUが限界なのにコードを最適化するような空振りが起きます。
おまけ：先に知っておくと良いこと
- サーマルスロットリングのテスト: 実機テストは「起動直後の5分」だけでなく、15〜30分の連続プレイで確認してください。熱でクロックが下がったあとが、そのゲームの本当のパフォーマンスです。
- Adaptive Performance: Samsung端末などで、端末の熱状態をゲーム側から取得して動的に品質を下げられる公式パッケージがあります。本格的なモバイル運用では検討の価値があります。
- バッテリー消費の意外な犯人: 過剰なネットワーク通信・バイブレーション・GPS・画面輝度もバッテリーを削ります。ゲーム側の設定でオフにできるものは選択肢を用意しましょう。
- 端末の性能差: ハイエンドとローエンドでGPU性能は10倍以上違うことがあります。品質設定（Quality Levels）を分け、起動時に端末に応じて自動選択する仕組みが定番です。
まとめ
- モバイルの敵は熱とバッテリー。「動く」ではなく「余裕を持って動く」が目標。
- レンダリング: ドローコール削減・オーバードロー対策・Render Scale。
- CPU: 物理の下ごしらえ・GCゼロ・プーリング。
- メモリ: テクスチャ圧縮（ASTC）・オーディオのStreaming・Addressables。
- モバイル特有: targetFrameRate・タッチ入力・セーフエリア。
- リリース前はミドルレンジ実機で30分の熱テスト。5分では何も分からない。
そして何より—— 実機で計測しながら進めること。エディタの数字はモバイルの現実を映しません。あなたのゲーム、実機で30分遊び続けたことはありますか？