【Unity】Unity Profiler入門：「なんか重い」の犯人をデータで特定する

ゲームがカクつく。オブジェクトを減らしてみたり、Update()の中身をコメントアウトしてみたり、影を切ってみたり——それでも直らない。この「手当たり次第に削ってみる」やり方がうまくいかないのは、犯人を推測で捜しているからです。

パフォーマンス最適化の鉄則は1行です。 「推測するな、計測せよ」。そのための計測ツールが、Unityに標準搭載されている Profiler です。

この記事でわかること

• 最適化の進め方——計測→特定→修正→再計測のループ
• Profilerの基本操作（Record・フレーム選択）
• CPU Usageモジュールの読み方——Self msソートとGC Alloc列で犯人を特定する
• 重い処理の典型パターンと対応する記事
• 実機プロファイリングのやり方（Development Build）

鉄則: 推測するな、計測せよ

最適化は、次のループで進めます。

1. 計測: Profilerで記録し、スパイク（突出した山）を見つける
2. 特定: そのフレームで一番時間を食っている処理を突き止める
3. 修正: 一番重い1箇所だけを直す
4. 再計測: 効果が出たかを数字で確認する

重要なのは、一度に1箇所しか直さないことです。まとめて直すと、どの修正が効いたのか（あるいは逆効果だったのか）がわからなくなります。また、全体の1%しか占めない処理をいくら速くしても、体感は1%も変わりません。常に「今一番重いもの」から手を付けます。

Profilerの基本操作

1. 開く: メニューの「Window > Analysis > Profiler」を選択します（ショートカット: Ctrl + 7）。
2. 記録する: 「Record」ボタンがオンの状態でゲームを再生すると、グラフがリアルタイムに流れ始めます。
3. フレームを選ぶ: グラフ上でカクついた瞬間——スパイク（突出した山）をクリックします。そのフレームの処理内訳がウィンドウ下部に表示されます。

tips グラフを眺めるときは、まず色の凡例に注目してください。スパイクの山が何色でできているか（Scripts＝水色ならコード、Rendering＝緑なら描画、GC＝黄色ならメモリ）で、犯人のジャンルが一目で絞れます。

CPU Usage——犯人捜しの主戦場

カクつき調査で最初に見るのは CPU Usage モジュールです。スパイクしたフレームをクリックしたら、下部のビューを Hierarchy に切り替えます。

そのフレームで実行されたすべての処理が階層リストで表示されます。見るべき列は3つだけです。

列	意味	使い方
Self ms	その処理自体にかかった時間	ここで降順ソート→上位が犯人
Time ms	子の処理を含めた合計時間	全体像の把握用
GC Alloc	そのフレームで確保したヒープメモリ量	毎フレーム0以外ならGCスパイクの火種

手順はいつも同じです。 「スパイクをクリック → Hierarchyを開く → Self msで降順ソート → 一番上を疑う」。自分のスクリプトはスクリプト名.Update()のような名前で表示されるので、階層を展開して具体的なメソッドまで掘り下げます。

tips 自分のコードの特定区間を計測したいときは、UnityEngine.Profiling.Profiler.BeginSample("EnemyAI")とProfiler.EndSample()で囲むと、Hierarchyに「EnemyAI」という名前付きの行として表示されます。「Updateのどの部分が重いのか」まで絞り込めます。

重い処理の典型パターン

Hierarchyの上位によく現れる「常連」と、その対策記事です。

Profilerでの見え方	犯人	対策
GC.Collectの巨大なスパイク	毎フレームのヒープアロケーション	GC対策
Instantiate / Destroyが頻出	弾・敵・エフェクトの大量生成破棄	オブジェクトプーリング
自作スクリプトのUpdate()が上位	ループ内のGetComponent・重い検索・毎フレームの文字列処理	GetComponentのキャッシュ
Camera.Render・Batchesが多い	ドローコール過多	ドローコールとバッチング
Physics.Simulateが重い	Collider過多・Mesh Collider多用	形状の単純化・FixedUpdate設定の見直し

実践：GCスパイクを特定して退治する

ここまでの手順を、実際によくあるケースで通しでやってみましょう。「数秒に一度、周期的にカクつく」——シューティングでもRPGでも頻発する、GCスパイクの典型症状です。

1. 計測: Recordをオンにしてプレイし、カクついた瞬間の赤いスパイクをクリック。
2. 特定: Hierarchyを開くと、GC.Collectが数十msを占有しています。ただしGC.Collectは「掃除した瞬間」であって真犯人ではありません。GC Alloc列で降順ソートし直すと——ScoreUI.Update()が毎フレーム2.3 KB確保していました。中身は"Score: " + scoreの文字列連結です。
3. 修正: 毎フレームの文字列生成をやめます。スコアが変わったときだけtextを更新する（イベント駆動にする）だけで、このアロケーションはゼロになります。
4. 再計測: 同じ場面を記録し、GC Allocが0 Bになったこと、周期的なスパイクが消えたことを数字で確認します。

ポイントは2つです。

• GC.Collectは犯人ではなく「結果」: スパイクの行自体を睨んでも直せません。GC Alloc列で「毎フレーム確保している奴」を探すのが正しい追い方です（仕組みは GC対策の記事 参照）。
• 修正は「呼ぶ回数を減らす」が王道: 文字列連結そのものを高速化するより、「毎フレームやる必要があるのか？」を疑う方が効きます。値が変わったときだけ更新する形は、イベント駆動設計 の入り口でもあります。

実機でプロファイリングする

エディタでの計測は、エディタ自身の処理が混ざるため参考値です。傾向を掴むには十分ですが、「本当に間に合っているか」の最終判断は必ず実機で行います。特にモバイルは、PCとCPU/GPUの性能バランスがまったく違います。

1. 「File > Build Profiles」（旧Build Settings）で 「Development Build」 と 「Autoconnect Profiler」 にチェックを入れてビルドします。
2. 実機でゲームを起動すると、同じネットワーク（またはUSB接続）のエディタのProfilerに実機のデータが流れてきます。
3. つながらない場合は、Profilerウィンドウ上部のターゲット選択（Playmodeドロップダウン）からデバイスを直接選択します。

そのほかのモジュール

• Rendering: ドローコール（Batches・SetPass Calls）やポリゴン数を確認できます。描画が重いときの入口です。
• Memory: メモリ全体の使用量を確認できます。「どのテクスチャ・どのアセットが食っているか」まで調べるなら、おまけで紹介するMemory Profilerパッケージが強力です。メモリに乗る仕組み自体は アセット管理の記事 で解説しています。
• GPU Usage: GPU側の処理時間を計測します（プラットフォームにより利用不可の場合あり）。CPUを削ってもフレームレートが変わらないなら、GPUがボトルネック（GPU Bound）の可能性があります。

おまけ：先に知っておくと良いこと

• Deep Profile: すべてのメソッド呼び出しを記録するモードです。犯人がピンポイントでわかる反面、計測自体が激重になり数字も歪むため、「短時間だけオンにして構造を見る」使い方に向きます。
• Frame Debugger: 「Window > Analysis > Frame Debugger」。1フレームの描画を1ドローコールずつ再生でき、「なぜバッチングが切れたのか」まで教えてくれます。描画最適化の相棒です。
• Memory Profilerパッケージ: Package Managerから追加できる別ツールで、メモリのスナップショットを撮って「何がどれだけ占有しているか」をツリーマップで可視化できます。メモリ不足クラッシュの調査はこちらが本命です。
• Profiler Analyzer: 複数フレームの統計比較ができる公式パッケージです。「修正前後の比較」を平均値で行えるため、再計測の精度が上がります。

まとめ

• 推測で直さない。計測→特定→修正→再計測のループで、一度に1箇所ずつ。
• カクつき調査は 「スパイクをクリック → Hierarchy → Self msで降順ソート」 が基本手順。
• GC Alloc列に毎フレーム値が出ていたら、それはGCスパイクの予告。GC.Collectは結果であって犯人ではない。
• 最終判断は実機のDevelopment Buildで。エディタの数字は参考値。
• 典型パターン（GC・Instantiate・ドローコール）には、それぞれ定石の対策がある。

Profilerは「開いて眺めるツール」ではなく「犯人を指差してもらうツール」です。重いと感じたら、削る前にまず開いてください。