「UE5プロジェクトの動作が重い…どうにかしたいけど、何から始めればいいかわからない…」そう感じている開発者は多いのではないでしょうか。Unreal Engine 5は驚くほど美しいグラフィックを実現できますが、その分、パフォーマンス管理は不可欠です。
UE5プロジェクトの動作が重いと感じたとき、闇雲に設定を変えても効果は薄いでしょう。最適化の第一歩は、どこに問題があるかを正確に特定することです。そのために最も強力なツールが、UE5に標準搭載されている「スタッツビュー」です。

とりあえず、ChatGPTなどの生成AIにこの結果を渡して相談しよう
スタッツビューとは?
スタッツビューは、プロジェクトのパフォーマンスに関するさまざまな統計情報をリアルタイムで表示するデバッグツールです。これを使うことで、CPU、GPU、メモリなど、どの部分がパフォーマンスのボトルネックになっているかを視覚的に把握できます。
Unreal Engine の Stat コマンド | Unreal Engine 5.6 ドキュメンテーション
スタッツビューの開き方
エディタのビューポートの左上にある [...
(3つのドット)をクリックするか、キーボードの ~
キー(日本語キーボードでは「@」)を押してコンソールコマンドを開き、Stat Unit
と入力します。
これを表示すると、ビューポート画面の右に以下が表示されます。

※ UE5.5 (バージョンによって表示内容が異なる場合があります)また上図では上2行はstat fpsで表示させています
Frame | 現在のフレームレート(FPS)の逆数[ms] つまり1フレームの全体処理時間 | これを狙い数値以下にしつつ表示などの品質を要件満たすのが最適化ゴール |
Game (CPU負荷) | ゲームロジック(ブループリントやC++コード)の処理時間 | 複雑なゲームプレイの計算 大量のオブジェクトのティック(更新) AIの処理など |
Draw (CPU負荷) | ドローコール(描画命令)の処理時間 | 画面に表示されるアクターやメッシュの数が多すぎる LOD(Level of Detail)の設定が不適切など |
RHIT (CPU負荷) | RHI スレッドの処理時間 Rendering Hardware Interface Thread | CPUがレンダリング命令を準備する負荷 ドローコール数が多い 複雑なシェーダー 物理演算など |
GPU Time (GPU負荷) | GPUでのレンダリング処理時間 | ポリゴン数、テクスチャの解像度 複雑なシェーダー ライティング(特にLumenやNaniteが原因でない場合)など |
Input | 入力処理(キーボード、マウス、コントローラーなど)にかかる時間 | |
Mem | メモリ使用量 | |
DynRes | Dynamic Resolution(動的解像度)のステータス | |
Draws | ドローコール数 | |
Prims | プリミティブ(三角形)の数 |
これらの数値は、プロジェクトのパフォーマンスを制限している「ボトルネック」を特定するための手がかりとなります。
AIに相談してみた

さきほどの画像の内容をAI(今回はGemini 2.5 Flash)に投げてみたところ、以下のような分析をしてくれました
(Gemini)
はい、ご提示いただいたStat Unit
の表示結果に基づいて、各項目が示す意味と、考えられるボトルネックを分析します。
各項目の分析
- Frame 35ms:
- 1フレームの処理に35ミリ秒かかっています。これは、FPSに換算すると約28.5 FPS(1000ms ÷ 35ms)となり、快適な動作とは言えません。
- Game 5ms:
- ゲームロジックの処理時間は5ミリ秒と比較的低く、ボトルネックではありません。ブループリントやC++のコードが重いわけではないことがわかります。
- Draw 33ms と RHIT 34ms:
- DrawとRHITの両方が非常に高い値を示しており、CPU側の描画処理が主なボトルネックです。
- Drawが高いのは、CPUが描画命令を準備するのに時間がかかっていることを意味します。
- RHITが高いのは、レンダリングスレッドがGPUへの命令をキューに入れるのに時間がかかっていることを意味します。
- この2つの値がほぼ同じで高いということは、CPUが大量の描画情報を処理しきれていない状態です。特に
Draws 476
(ドローコール数)が、このパフォーマンス低下に寄与している可能性があります。
- GPU Time 10ms:
- GPUの処理時間は10ミリ秒と比較的低く、GPU自体はボトルネックではありません。GPUが暇な時間があるのに、CPUが描画命令を十分に送れていない状況です。
- Input 95ms:
Input
が異常に高い値を示しています。これは、直接的な入力処理そのものが遅いというよりは、入力イベントに紐づく重い処理や、低フレームレートによる入力イベントの蓄積が原因である可能性が高いです。
- Mem 11GB:
- メモリ使用量が11GBと非常に多いです。これが直接的なボトルネックの主原因ではないにしても、パフォーマンスに悪影響を与える可能性があります。
結論:ボトルネックは「CPU側の描画処理」
この結果から、プロジェクトの主要なボトルネックはCPU側の描画処理にあります。特に、Draw
とRHIT
が高いことから、大量のオブジェクトやマテリアル、そしてそれらに伴うドローコールの多さがパフォーマンスを低下させていると考えられます。
推奨される改善策
- ドローコール数を削減する:
- 不要なアクターやメッシュを削除します。
- LOD(Level of Detail)を適切に設定し、遠くのオブジェクトの描画負荷を減らします。
- インスタンス化されたスタティックメッシュ(HISMC)やマテリアルのインスタンス化を積極的に活用します。
Input
の原因を特定する:Stat Game
コマンドでゲームロジックのボトルネックを探します。Input
イベントに紐づくブループリントやC++コードを見直し、重い処理がないか確認します。
- メモリ使用量を最適化する:
Stat Memory
コマンドを使用して、メモリを大量に消費しているアセット(特に高解像度のテクスチャ)を特定し、解像度を下げるなどの対策を講じます。
これらの改善策は、Draw
、RHIT
、そしてInput
の値を効果的に低下させ、全体のフレームレートを向上させることにつながります。

Inputがとても高い異常値なので、入力関連を怪しんでくれています。が、今回はそれが原因でないことが分かっていますので、さらにその情報を与えて再分析してもらいました。
(よっしー)
この例では、森のアセットにデフォルトのGameModeでプレイヤー処理は全くいじっていないデフォルトのカメラだけのポーンです。
(Gemini)
承知しました。プレイヤー処理がほとんどなく、カメラが森のアセットを映しているだけの状況ですね。
この場合、ゲームロジック(Game
)がボトルネックになる可能性は極めて低く、描画処理に問題があるという分析がより一層確かなものになります。
ご提示いただいたStat Unit
の結果は以下の通りです。
Frame 35ms, Game 5ms, Draw 33ms, RHIT 34ms, GPU Time 10ms, Input 95ms Mem 11GB DynRes:Unsupported, Draws 476, Prims 519K
この情報に、「デフォルトのカメラだけのポーンで、プレイヤー処理はほとんどない」という状況を合わせると、以下の点が明確になります。
ボトルネックの再分析
Game 5ms
: プレイヤー処理がないため、この値が低いのは当然です。ゲームロジックがパフォーマンスを妨げている可能性は完全に排除できます。Draw 33ms
とRHIT 34ms
: これらが高い値であることは、森のアセットが引き起こすCPU側の描画負荷がボトルネックであることを強く示唆しています。- 考えられる原因:
- 過剰なドローコール:
Draws 476
という数値は、森の木々、岩、草などのアセットが多すぎる、または各アセットのLOD設定が不適切で、CPUが処理しきれていない可能性があります。 - 密度の高いフォリッジ: 草や低木といったフォリッジ(植生)が広範囲に高密度で配置されている場合、その描画情報がCPUに大きな負担をかけます。
- 過剰なドローコール:
- 考えられる原因:
GPU Time 10ms
: CPUが命令を送りきれていないため、GPUは余裕があります。森の景観は非常に美しく見えますが、GPUの処理能力が限界に達しているわけではありません。Input 95ms
: この状況でInput
が非常に高いのは、Input処理に紐づいたカメラの処理が重いか、フレームレートの低下によってInputイベントの処理が詰まっていることが考えられます。- 特に、デフォルトのカメラであっても、マウスの動きに連動してビューが更新される処理は、ゲームのティックとは別の入力処理として計測される場合があります。この処理が何らかの理由で重くなっている可能性があります。
結論と推奨される対策
このケースでは、ボトルネックはほぼ間違いなくCPU側の描画負荷、特に森のアセット管理にあります。
- ドローコール数の削減:
- LODの調整: 森の木々や岩など、遠くにあるアセットのLOD設定が適切か確認し、遠景のポリゴン数を大幅に減らします。
- フォリッジの最適化: フォリッジツールの設定を見直し、遠くの草や低木の密度を下げるか、よりシンプルなメッシュに置き換えます。
- アセットの結合: 可能な範囲で、近くにある同一のマテリアルを持つスタティックメッシュを結合し、ドローコールを減らします。
Input
の原因を調査:Input
の値がこれほど高いのは異常です。カメラのブループリントやC++コードに、マウス移動などに紐づいて不必要な重い処理が走っていないか確認することをお勧めします。
これらの対策に焦点を当てることで、Draw
、RHIT
、そして Input
の値を大幅に改善し、全体のフレームレートを向上させることができます。
カメラを固定して測ろう
最適化の作業は大きなボトルネックで一気に解決!ということは少なく、チリツモな地味な作業となる場合が多いかと思います。
なるべく早い段階から観測しましょう。と同時に、安定した計測ができるようにするのも大事です。
パフォーマンス計測用の固定カメラを設置して、視点変更で画面に映るものが変わると安定しません。それはそれで確認必要でしょうが、安定して計測できるようにしましょう。

レベルシーケンスにカメラを登録して0フレームにトランスフォームのキーを打っておくのがおすすめです。うっかり動かしてしまっても位置や角度をリセットできるので。
実践(個人的おすすめ情報)
いろいろ情報がありますが、下記KomeFukuroさんの記事が初心者向けにわかりやすいと思いました。
UE5のFoliage(フォリッジ)の最適化|KomeFukuro
また、下記、Ben Clowardさんの最近始まった最適化シリーズはUnreal EngineとUnityでの無料のアセットで具体的な最適化方法について順を追って説明してくれています。

UE5最適化ベスト〇選とか、これだけやればOKみたいな話の否定から始まる感じで、真面目で丁寧で実践的に感じました。
あとは、ちょっと古いですが、プロの解説 2019年のUNREAL FEST EAST 2019の講演動画もあります。

これはてんこ盛りで駆け足・スキップされて素人にはハード目ですが

概要欄にスライドへのリンクもあります。(フェス自体へのリンクは最新のフェスに飛んじゃうけど)
あとは多すぎて全部は見てられないですが、最新情報は下記にまとめてくださってます。
プロファイリングと最適化 | Performance and Profiling | UE5攻略リンク

技術進歩で前提がどんどん変わるので、最新情報も必要ですね。
コメント