「Gmae」ウィンドウ右端にある「Statistics」の情報を見ていきます。
CPU・GPU・メモリなど、エディター動作やビルド後動作に関わってくる数値ですので気にしていきましょう。
Batches / Tris / SetPassCalls

| 指標 | 負荷 | 改善 | |
|---|---|---|---|
| Batches | GPUに送られた描画命令の総数。 1フレームを描画するためにGPUへ発行した命令の回数です。 | CPU | まとめて送る |
| Tris | 描画されている三角形ポリゴンの総数。 画面内に存在するポリゴン数(三角形)と頂点数です。 | GPU | モデルの軽量化、LOD |
| SetPassCalls | レンダリングステート(シェーダーパス)の切り替え回数。 | CPU (重い) | 同じマテリアルを使う |
「Batches」と「SetPassCalls」の違いについて。
- Batches(食材を焼く):「準備した鍋に、肉を投げ入れる」という、実際の調理作業。
- SetPassCalls(調理器具の交換):「フライパンを洗って、次は鍋を出す」という、準備をガラッと変える作業。
比較すると「SetPassCalls」の方が重要度が高くなります。
GPU(グラフィックボード)は「同じ設定(マテリアルやシェーダー)」で大量のポリゴンを描くのは得意ですが、
マテリアルを切り替える(SetPass)瞬間に、一瞬動きが止まります。
CPUはこの切り替え命令を出すために大きなエネルギーを使うため、
SetPassCallsの数が多いほどCPUの負荷が高まり、結果としてFPSが下がります。
■ ターゲットデバイス別:許容値目安リスト
| ターゲット | Batshes(命令数) | Tris(ポリゴン数) | SetPassCalls | 備考 |
|---|---|---|---|---|
| ・超低スペックPC ・古いスマホ | ~ 200 | ~ 300k | 30 ~ 70 | Batchesを抑えるのが最優先。 |
| ・一般的なPC ・Switch等 | ~ 500 | 500k ~ 1M | 100 ~ 200 | この範囲なら余裕を持って 60FPSを狙えます。 |
| ・ミドルレンPC ・PS4 | ~ 1,000 | 2M ~ 5M | 300 ~ 600 | 多少重い処理も難なくこなせます。 |
| ・ハイエンドPC ・PS5 | 2,000 ~ | 10M ~ | 1000 ~ 2,000 ~ | ポリゴン数はほぼ無制限。 |
FPS制御
テストプレイ時に「160FPS」出ていたので、「60FPS」に強制固定させました。
- 物理的な安心感:160FPS出ていた過剰な負荷が抑えられ、電力消費や発熱が抑えられます。
- 本番に近い挙動:ユーザー環境「60FPS」で、アニメーションやカメラの動きを常にチェックできます。

「FrameRateConfig.cs」スクリプトファイルをアセットフォルダの任意場所に入れるだけで「60FPS」に固定されます。
using UnityEngine;
/// <summary>
/// ゲーム起動時に自動でフレームレートを設定するクラス
/// </summary>
public static class FrameRateConfig
{
// [RuntimeInitializeOnLoadMethod] は、シーンに配置しなくても
// ゲームが起動した瞬間にこのメソッドを実行してくれる属性です。
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
static void Init()
{
// 1. 垂直同期(VSync)をオフにする
// これが 1 以上だと、Application.targetFrameRate が無視されます。
QualitySettings.vSyncCount = 0;
// 2. フレームレートを 60 に固定する
Application.targetFrameRate = 60;
// 確認用のログ(ビルド後もConsoleやログファイルに出力されます)
Debug.Log($"[FrameRateConfig] FPS has been set to: {Application.targetFrameRate}");
}
}
「RuntimeInitializeOnLoadMethod」はビルドした製品版にも100%引き継がれるようです。
- 配布時の標準設定:起動した瞬間、このスクリプトが自動で走り、ユーザー環境でも60FPSに固定されます。
- 低スペック端末の保護:ユーザーPCが160FPS出そうとして熱暴走するのを未然に防げます。
固定の注意点 「バグの隠蔽」が起きる可能性がある
例えば、スクリプトミスで「1フレームにめちゃくちゃ重たい処理」を書いてしまった場合、
・160FPS(制限なし):FPSが80などにガクッと落ちるので、すぐに気がつける
・60FPS(制限あり):もともと余裕があるので、重い処理を書いても60を維持できてしまい、気がつかない
最終的には両方でチェックするのが良さそうです。

コメント