UE5 Game Thread最適化の実践チェックリスト

PS5からSwitchクラスのハードまでを対象とするUE5タイトルでは、最初に予算を超過 するのはたいていGame Threadです。コードに手を入れる前に、私が確認している チェックリストをまとめます。

1. 推測より計測

• stat unit — ボトルネックが本当にGame Threadか（DrawやGPUではないか）を確認。
• stat game — Tick・アニメーション・物理のコスト内訳を確認。
• Unreal Insights（-trace=default,task）— スパイクしているフレームと、その中で実行された処理を特定。

実機でしか発生しないスパイクは、実機でプロファイリングする。エディタの数値は当てになりません。

2. よくある原因

1. Tickするアクターが多すぎる。 毎フレームTickしているが実際にはイベント駆動で 十分なコンポーネントを探す。PrimaryActorTick.bCanEverTick = falseはエンジンで 最も安価な最適化です。
2. Tick頻度。 どうしてもTickが必要な処理でも、プレイヤーに直接見えないロジックなら SetTickIntervalで10〜15Hzに落としても60Hzとの違いは分かりません。
3. Blueprintのホットパス。 毎フレーム計算を行うBlueprint Tickは、C++化の有力候補。 内側のループをC++へ移し、Blueprintは設定として残します。
4. ゲームプレイ中のスポーン。 弾・VFXアクター・UIウィジェットはプール化する。 戦闘中のSpawnActorはフレームタイムの手榴弾です。
5. オーバーラップとトレースの量。 毎フレームのトレースは、結果が1フレーム遅れても 問題ない箇所ならバッチ化または非同期クエリ（AsyncLineTraceByChannel）にまとめる。

3. 最も弱いターゲットで検証する

PCで0.3ms稼げた変更がSwitchでは誤差ということもあれば、その逆もあります。 CPUキャッシュの挙動もコア数もまったく異なるからです。変更をまとめるたびに、 最も弱いプラットフォームで同じInsightsキャプチャを取り直し、PRの説明に before/afterの表を残して効果を検証可能にします。

すべてに共通するパターンは、フレームの仕事を減らすこと、残った仕事を イベント駆動にすること、そして実機で計測していない数値を信用しないことです。