【Unity最適化完全ガイド】ゲームを軽量化してFPSを改善する方法｜初心者〜中級者向け

Unityでゲームを作っていて、「Editorでは普通に動くのに、実機で遊ぶとカクつく」「敵や弾が増えた瞬間にFPSが落ちる」と感じたことはありませんか。

ゲームが重くなる原因は、スクリプトだけとは限りません。毎フレームの処理、オブジェクトの生成と破棄、ガベージコレクション、描画負荷、物理演算、UI更新など、いくつかの要素が重なって起きることがあります。

ここで大切なのは、いきなり設定を下げたり、コードを全部書き直したりしないことです。原因を見つけないまま最適化を始めると、時間をかけたのにほとんど改善しないこともあります。

FPSが落ちる場面には、必ず何かしらの手がかりがあります。一定間隔で一瞬止まるのか、オブジェクトが増えたときに重くなるのか、見た目が派手な場面だけ重いのか。まずは症状を整理し、そのあとProfilerで確認することで、直すべき場所が見えやすくなります。

「何から見ればいいのか分からない」という状態から、CPU・GC・描画・物理・UIのどこを疑えばいいのか判断できるように、順番に整理していきましょう。

---

Unityが重い原因を症状で判断する

Unityの最適化で最初に迷いやすいのは、「どこが重いのか分からない」という部分です。いきなりコードを書き換える前に、まずはゲーム中に起きている症状を見て、原因の候補を絞ってみましょう。

同じ「FPSが低い」という状態でも、原因は1つではありません。一定間隔でカクつく場合と、画面が派手な場面だけ重い場合では、見るべき場所が変わります。

症状	疑いやすい原因	確認したい場所
数秒おきに一瞬止まる	GC、生成・破棄、ログ出力	GC Alloc、Instantiate、Destroy
敵や弾が増えると重い	Update、物理演算、当たり判定	CPU Usage、Physics
エフェクトや背景が多いと重い	描画負荷、透明表現、ドローコール	Rendering、Stats
UIを開くと重い	Canvas再構築、Text更新	UI、Canvas関連の処理

一定間隔でカクつく原因

ゲームがずっと重いわけではなく、「たまに一瞬だけ止まる」場合は、ガベージコレクション、オブジェクトの生成と破棄、文字列生成、Debug.Logなどを疑います。

たとえば、弾を発射するたびにInstantiateで生成し、画面外に出たらDestroyで削除している場合、数が増えるほど負荷が目立ちやすくなります。エフェクト、ダメージ表示、敵のスポーンでも同じことが起きる場合があります。

判断の目安は次の通りです。

• 弾やエフェクトを出した瞬間に止まる
• 数秒おきに一瞬だけ画面が引っかかる
• 平均FPSは悪くないのに、体感ではカクつく
• 画面の派手さより、特定の処理タイミングで重くなる

このタイプは、見た目だけでは原因を決めにくいです。あとでProfilerのGC AllocやGC.Collectを確認すると、原因を絞りやすくなります。

オブジェクトが増えると重い原因

敵、弾、アイテム、パーティクルなどが増えたときにFPSが落ちるなら、毎フレーム処理や物理演算の負荷が増えている可能性があります。

Unityでは、オブジェクトが1つ増えるだけなら問題にならなくても、同じ処理を持つオブジェクトが100個、200個と増えると急に重くなることがあります。特にUpdate内で検索処理、距離判定、ループ処理、GetComponentを繰り返している場合は注意が必要です。

判断の目安は次の通りです。

• 敵が増えた瞬間からFPSが落ちる
• 弾幕や大量スポーンの場面で重くなる
• オブジェクトが少ない場面では軽い
• 当たり判定が多い場面で処理落ちする

この場合は、オブジェクト数そのものよりも、「増えたオブジェクトが毎フレーム何をしているか」を見るのが大切です。

見た目が派手な場面で重い原因

コードの処理がそれほど多くないのに、エフェクト、草、建物、透明UI、パーティクルが多い場面だけ重い場合は、描画負荷が原因かもしれません。

このタイプでは、スクリプトを少し整理してもFPSがあまり改善しないことがあります。カメラに映るものが多い、透明な画像が何枚も重なっている、同じようなオブジェクトを別々のマテリアルで描画している、といった状況で負荷が増えやすいです。

判断の目安は次の通りです。

• カメラの向きを変えるとFPSが大きく変わる
• エフェクトや透明UIが重なると重くなる
• 敵の数より、画面の派手さでFPSが変わる
• 背景や遠景まで細かく表示している

---

Unity Profilerで原因を確認する

症状から原因の候補を絞ったら、次はUnity Profilerで実際の負荷を確認します。ここを飛ばしてしまうと、「なんとなく重そうな場所」を直すことになり、時間をかけても改善しないことがあります。

Profilerは、Unityの処理時間を項目ごとに見られる分析ツールです。FPSが落ちた瞬間に、CPUが忙しいのか、描画が重いのか、GCが発生しているのかを確認できます。

Profilerで最初に見る項目

Profilerを開くには、Unity上部メニューからWindow > Analysis > Profilerを選びます。最初からすべてを見る必要はありません。まずは、FPS低下の原因を分けるために、次の項目を確認しましょう。

見る項目	分かること	疑う原因
CPU Usage	スクリプトや物理演算などの処理時間	Update、検索処理、物理演算
Rendering	描画にかかっている負荷	ドローコール、透明表現、エフェクト
Memory	メモリ使用量や割り当て	GC、生成・破棄、文字列生成
GC Alloc	そのフレームで発生したメモリ割り当て	毎フレームの不要な割り当て

たとえば、BehaviourUpdateやScriptsの処理時間が長い場合は、スクリプト側の負荷を疑います。Renderingが目立つ場合は、コードよりも描画側を確認したほうがよいかもしれません。

また、GC Allocが毎フレーム出ている場合は、少し注意が必要です。すぐに問題になるとは限りませんが、積み重なるとガベージコレクションが発生し、一瞬止まる原因になることがあります。

スパイクが出たフレームを見る

Profilerでは、重くなった瞬間のフレームをクリックして、何が起きていたのかを確認できます。FPSが落ちる場面を再現しながら、処理時間が急に伸びている場所を探しましょう。

確認の流れは次の通りです。

1. ProfilerのRecordを有効にする
2. ゲームを再生して、重くなる場面を再現する
3. グラフ上で処理時間が跳ねているフレームをクリックする
4. Timelineや詳細表示で、長くなっている処理を確認する
5. 最適化前のFPSやフレーム時間をメモしておく

スパイクとは、普段よりも一部のフレームだけ処理時間が大きく伸びる状態です。平均FPSだけを見ると問題が小さく見えることもありますが、プレイヤーはこの一瞬の引っかかりを強く感じます。

たとえば、普段は16ms前後で動いているのに、弾を大量に生成した瞬間だけ50msを超える場合、そのフレームで何か重い処理が発生しています。Instantiate、Destroy、GC.Collect、Canvas関連の処理などが近くに出ていないか確認してみましょう。

ログとProfilerを合わせて確認したい場合は、こちらの記事も参考になります。

Editorだけで判断しない

Unity Editor上の再生結果だけで、最適化の成功・失敗を判断するのは少し危険です。Editorでは、エディタ自体の処理やデバッグ用の負荷が入るため、実際のビルドとは結果が変わることがあります。

特にスマホゲームでは、端末の性能差、発熱、バッテリー状態によってもFPSが変わります。最初はEditorで原因を探しても問題ありませんが、最終的には実機やDevelopment Buildでも確認するのがおすすめです。

判断の目安は次の通りです。

• Editorでは軽いのに、スマホ実機では重い
• ゲーム開始直後は軽いが、数分後にFPSが落ちる
• 端末によってカクつく場面が変わる
• ビルド後だけ発生する重さがある

このような場合は、Editor上の数値だけで断定せず、できるだけ実際に遊ぶ環境に近い状態で測り直しましょう。

---

UnityのCPU負荷を下げる

ProfilerでCPU UsageやBehaviourUpdateが目立つ場合は、スクリプト側の処理がFPS低下に関係している可能性があります。

CPU負荷を下げるときは、まず「毎フレーム実行されている処理」を見直します。UnityではUpdateが便利ですが、必要ない処理まで毎フレーム動かしていると、オブジェクト数が増えたときに一気に重くなります。

Update内の不要処理を減らす

Updateそのものが悪いわけではありません。入力確認、キャラクターの移動、カメラ追従など、毎フレーム必要な処理はUpdateで問題ありません。

見直したいのは、「毎フレームでなくてもよい処理」です。たとえば、敵との距離チェック、画面内のオブジェクト検索、リスト全体のループ処理などは、数が増えるほど負荷が大きくなりやすいです。

次のような処理がUpdateに入っている場合は、優先して確認してみましょう。

• 毎フレームGameObject.Findでオブジェクトを探している
• 毎フレームGetComponentで同じコンポーネントを取得している
• 大量の敵や弾が、それぞれ距離判定をしている
• 毎フレーム、全アイテムや全敵をループで調べている

対処としては、毎フレームではなく数フレームに1回だけ実行したり、プレイヤーが範囲に入ったときだけ処理したりする方法があります。スコアが変わったときだけUIを更新する、敵が出現したときだけリストに追加する、というように「必要になったタイミングで動かす」形にできると負荷を減らしやすいです。

Updateの見直しをさらに詳しく進めたい場合は、こちらの記事で具体的な考え方を確認できます。

取得処理は必要な分だけキャッシュする

GetComponentやCamera.mainを何度も呼び出している場合は、最初に取得して変数に保存しておくと負荷を減らせることがあります。このように、一度取得した参照を使い回すことをキャッシュと呼びます。

たとえば、プレイヤーのRigidbodyを毎フレーム取得しているなら、AwakeやStartで一度だけ取得しておきます。

using UnityEngine;

public class PlayerMove : MonoBehaviour
{
    private Rigidbody rb;

    private void Awake()
    {
        rb = GetComponent<Rigidbody>();
    }

    private void Update()
    {
        // 毎フレームGetComponentせず、保存しておいたrbを使う
        rb.AddForce(Vector3.forward);
    }
}

ただし、何でもかんでもキャッシュすればよいわけではありません。1回しか使わない処理や、数が少ないオブジェクトでは、体感できるほどの差が出ないこともあります。

判断の目安は次の通りです。

• Update内で同じコンポーネントを何度も取得している
• 敵や弾など、大量に存在するオブジェクトで取得処理をしている
• Profilerでスクリプト処理が目立っている
• オブジェクト数が増えるほどFPSが下がる

「毎フレーム」「大量に」「同じものを何度も取得している」場合は、キャッシュを検討する価値があります。

Find系は毎フレーム使わない

GameObject.FindやFindObjectOfTypeのような検索系の処理は、シーン内から条件に合うオブジェクトを探します。便利ですが、毎フレーム使うと負荷が増えやすいです。

特に、敵や弾など複数のオブジェクトがそれぞれUpdateで検索している場合、数が増えたときに一気に重くなることがあります。

よくある改善方法は次の通りです。

• Inspectorから参照を直接設定する
• StartやAwakeで一度だけ取得する
• 管理用のスクリプトに参照をまとめる
• イベントや関数呼び出しで必要な相手に通知する

また、SendMessageやBroadcastMessageも、頻繁に使う処理では避けたほうが無難です。直接メソッドを呼ぶ、インターフェースを使う、イベントで通知するなど、処理の流れが追いやすい形にすると、負荷だけでなく保守性も改善しやすくなります。

ただし、初期化時に1回だけ使う程度なら、大きな問題にならないケースもあります。最適化では、コードを全部置き換えるよりも、Profilerで目立つ場所から直すことが大切です。

---

UnityのGC対策でカクつきを減らす

平均FPSはそこまで低くないのに、プレイ中に「一瞬だけ止まる」ようなカクつきが出る場合は、GCが関係しているかもしれません。

GCはガベージコレクションの略で、使われなくなったメモリを整理する仕組みです。必要な仕組みではありますが、ゲーム中に大きく動くと、その瞬間だけ処理が止まったように見えることがあります。

InstantiateとDestroyを減らす

弾、敵、エフェクト、ダメージ表示などを何度もInstantiateで作り、不要になったらDestroyで消している場合、カクつきの原因になることがあります。

特に、シューティングゲームの弾やヒットエフェクトのように、短い時間で大量に出たり消えたりするものは注意が必要です。1回だけなら問題になりにくくても、プレイ中に何百回も繰り返すと負荷が目立つ場合があります。

このような場合は、オブジェクトプールを検討します。オブジェクトプールとは、最初にいくつかのオブジェクトを用意しておき、使うときだけ表示し、使い終わったら非表示にして再利用する方法です。

判断の目安は次の通りです。

• 弾やエフェクトを出した瞬間に一瞬止まる
• InstantiateやDestroyを頻繁に呼んでいる
• 敵やアイテムを短時間で大量に生成している
• Profilerで生成・破棄の処理が目立っている

すべてのオブジェクトをプール化する必要はありません。まずは「数が多いもの」「何度も出し入れするもの」「Profilerで目立つもの」から対応すると、作業量を抑えながら効果を確認しやすいです。

オブジェクトプールの実装手順は、こちらで詳しくまとめています。

文字列とログ出力を整理する

GCの原因は、オブジェクトの生成だけではありません。文字列の結合や大量のログ出力でも、不要なメモリ割り当てが増えることがあります。

たとえば、Update内で毎フレーム次のような処理をしている場合は注意しましょう。

scoreText.text = "Score: " + score;
Debug.Log("Player position: " + transform.position);

スコアが変わっていないのに毎フレーム文字列を作り直していると、無駄な割り当てが増えます。ログも開発中は便利ですが、大量に出続けると処理の確認がしづらくなり、負荷の原因にもなりやすいです。

対処としては、値が変わったときだけ表示を更新します。

public void SetScore(int newScore)
{
    score = newScore;
    scoreText.text = "Score: " + score;
}

このように、毎フレーム更新ではなく「スコアが変わったタイミング」で更新すると、処理の回数を減らせます。

判断の目安は次の通りです。

• Update内で文字列を毎回作っている
• Debug.Logが大量に出続けている
• タイマーやスコア表示を無条件で毎フレーム更新している
• ProfilerでGC Allocが継続的に出ている

リリース前には、不要なDebug.Logを整理しておくと安心です。開発中だけ表示したいログは、条件分岐やビルド設定で切り替えられる形にしておくと管理しやすくなります。

GC Allocが毎フレーム出る処理を探す

GC対策で大切なのは、「なんとなくメモリに悪そうな処理」を全部消すことではありません。ProfilerでGC Allocを見て、毎フレーム割り当てが発生している処理から確認します。

GC Allocが少し出たからといって、すぐに大きな問題になるとは限りません。ですが、毎フレーム継続して発生していたり、一定時間ごとにGC.Collectが目立ったりする場合は、カクつきの原因候補になります。

特に注意したい処理は次の通りです。

• 毎フレームの文字列結合
• 大量のInstantiateとDestroy
• 毎フレーム実行されるLINQやラムダ式
• 一時的な配列やリストを何度も作る処理

LINQやラムダ式は便利なので、使うこと自体が悪いわけではありません。ただし、大量のオブジェクトに対して毎フレーム実行する処理では、割り当てが増えていないか確認したほうが安全です。

一方で、ゲーム開始時に1回だけ実行する処理や、メニュー画面でたまに使う処理まで無理に書き換える必要はありません。最適化は、効果が出る場所を選んで行うほうが、コードも読みやすく保てます。

GCの仕組みや具体的な改善方法をさらに深く確認したい場合は、こちらの記事も参考になります。

---

Unityの描画負荷を下げる

CPUやGCを見直しても、見た目が派手な場面だけFPSが落ちる場合は、描画負荷を疑います。描画負荷とは、カメラに映るオブジェクト、マテリアル、ライト、影、エフェクト、透明なUIなどを画面に表示するための負荷です。

このタイプの重さは、スクリプトを少し直しただけでは改善しにくいことがあります。コードが原因ではなく、「画面に映しているものが多い」「描画の条件が重い」ことが原因になっている場合があるからです。

描画負荷が原因の症状を見る

描画負荷が原因のときは、ゲーム内の処理量よりも、カメラに映っている見た目でFPSが変わりやすいです。

たとえば、何も操作していないのに、森や街の方向を向いたときだけ重くなる場合があります。これは、敵のAIや入力処理ではなく、木、建物、草、影、エフェクトなどの描画が増えている可能性があります。

判断の目安は次の通りです。

• カメラの向きを変えるとFPSが大きく変わる
• エフェクトやパーティクルが重なると重い
• 透明なUIや半透明オブジェクトが多い場面で重い
• 敵の数より、背景や演出の多さでFPSが変わる
• ProfilerのRenderingが目立つ
• StatsでBatchesやSetPass Callsが多い

まず描画しない工夫をする

描画負荷を下げるときは、見た目を大きく削る前に「そもそも描画しなくてよいもの」を減らすのが効果的です。

たとえば、プレイヤーから見えない場所にある敵や、カメラの外にあるエフェクトまで動かし続けていると、見た目には分からない負荷が増えます。遠くの背景を細かく描画しすぎている場合も、FPS低下につながることがあります。

最初に確認したい項目は次の通りです。

• カメラに映らないオブジェクトを更新し続けていないか
• Far Clip Planeが必要以上に広すぎないか
• 遠くのオブジェクトまで高い精度で表示していないか
• 透明な画像やパーティクルが何枚も重なっていないか
• 不要なライトや影が多すぎないか

Far Clip Planeは、カメラがどれくらい遠くまで描画するかを決める設定です。広くしすぎると遠くのオブジェクトまで表示対象になり、負荷が増える場合があります。広大な3Dマップでは特に確認しておきたい設定です。

また、透明なUIやパーティクルは、重なりが多いほど負荷が増えやすいです。炎、煙、魔法エフェクト、半透明のパネルをたくさん重ねている場合は、数や表示時間を見直すだけでも改善することがあります。

同じ見た目のものをまとめる

木、岩、草、敵、背景パーツなど、同じ見た目のオブジェクトを大量に配置している場合は、バッチングやGPU Instancingを検討します。

バッチングは、複数のオブジェクトをできるだけまとめて描画する仕組みです。GPU Instancingは、同じメッシュとマテリアルを使うオブジェクトを効率よく描画するための仕組みです。

ただし、設定すれば必ず速くなるわけではありません。オブジェクトの動き、マテリアルの種類、描画パイプライン、シェーダーの設定によって効果は変わります。設定後は、必ずProfilerやStatsで変化を確認しましょう。

判断の目安は次の通りです。

• 同じ木、岩、草、背景パーツを大量に置いている
• 同じ見た目なのに、別々のマテリアルを使っている
• StatsのBatchesやSetPass Callsが多い
• 動かない背景オブジェクトが多い

動かない背景にはStatic Batching、同じ見た目の大量配置にはGPU Instancingが向いている場合があります。一方で、すべてのオブジェクトを無理にまとめようとすると管理が難しくなることもあるので、まずは数が多く、画面によく映るものから試すのがおすすめです。

軽量なBGM素材をまとめて用意したい場合は、制作効率を上げる選択肢として音楽アセットを使う方法もあります。描画負荷そのものを下げるものではありませんが、素材探しの時間を減らしたいときには便利です。

Ultimate Game Music Collection
✅ Unity Asset Storeでチェックする

---

物理演算とUI負荷を確認する

CPU、GC、描画負荷を見直しても原因がはっきりしない場合は、物理演算やUI更新も確認してみましょう。どちらも普段は見落としやすいですが、ゲームの作り方によってはFPS低下の原因になります。

特に、RigidbodyやColliderをたくさん使うゲーム、スコアやゲージなどのUIが頻繁に変わるゲームでは、Profiler上で物理やCanvas関連の処理が目立つことがあります。

物理演算が重いか判断する

物理演算が重い場合は、Rigidbody、Collider、接触判定、FixedUpdateまわりを確認します。アクションゲーム、落下物が多いゲーム、敵や弾の当たり判定が多いゲームでは、物理処理が積み重なって負荷になることがあります。

まず確認したいのは、Colliderの数と形です。細かい形の当たり判定が必要ない場面では、Mesh ColliderよりもBox Collider、Sphere Collider、Capsule Colliderのような単純なColliderを使ったほうが軽くしやすいです。

判断の目安は次の通りです。

• Rigidbodyを持つオブジェクトが多い場面で重い
• 敵、弾、アイテムなどの接触判定が大量に発生している
• ProfilerでPhysics関連の処理が目立つ
• 複雑なMesh Colliderを多く使っている
• 当たり判定が不要な飾りオブジェクトにもColliderが付いている

対処としては、まず不要なColliderを外し、必要なColliderもできるだけ単純な形にします。たとえば、背景の小物すべてに細かい当たり判定を付けるのではなく、プレイヤーが実際に触れる部分だけにColliderを置くと管理もしやすくなります。

Fixed Timestepを調整して物理計算の頻度を下げる方法もありますが、これは操作感や当たり判定に影響することがあります。数値を変える場合は、ジャンプ、移動、衝突、敵の挙動を必ずプレイして確認しましょう。

UpdateとFixedUpdateの使い分けが不安な場合は、こちらの記事も参考になります。

UI更新が重いか判断する

UIは軽そうに見えますが、更新の仕方によっては負荷が大きくなることがあります。特にCanvas全体が何度も再構築されると、スコア表示やゲージ更新のような小さな変更でも重く感じる場合があります。

たとえば、HPバー、スコア、タイマー、ミニマップ、アイテム一覧などが毎フレーム更新されている場合は注意しましょう。値が変わっていないのにTextやLayoutを更新していると、無駄な処理が増えてしまいます。

判断の目安は次の通りです。

• メニューやインベントリを開くとFPSが落ちる
• スコアやタイマーが動いている場面で重い
• ProfilerでCanvasやUI関連の処理が目立つ
• Layout Groupを多く使っている
• 変化しないUIまで毎フレーム更新している

UI負荷を下げる基本は、頻繁に変わるUIと、ほとんど変わらないUIを分けることです。たとえば、常に変わるHPバーやタイマーと、背景パネルや固定アイコンを同じCanvasにまとめていると、一部の更新が全体に影響する場合があります。

また、Textの更新は「値が変わったときだけ」にするのがおすすめです。スコアが変わっていないのに毎フレーム文字列を作り直すと、UI負荷だけでなくGCの原因にもなります。

UIまわりで表示やクリックの不具合も合わせて確認したい場合は、こちらの記事で原因を整理できます。

---

Unity最適化の修理判断リスト

ここまで確認すると、FPS低下の原因候補はかなり絞れてきます。最後に大切なのは、「今すぐ直すべき処理」と「後回しでよい処理」を分けることです。

最適化は、細かくやろうと思えばいくらでも作業が増えます。ただ、効果が小さい場所まで直し始めると、コードが読みにくくなったり、別の不具合が出たりすることもあります。私なら、まずProfilerで目立つ場所から順番に直していきます。

今すぐ直すべき処理

優先して直したいのは、「発生回数が多い」「対象数が多い」「Profilerで目立つ」の3つに当てはまる処理です。ここに手を入れると、FPSやカクつきの改善につながりやすくなります。

優先度が高い処理	判断基準	対処の方向性
毎フレームの不要処理	Update内で検索・取得・大量ループをしている	実行回数を減らす、イベント化する
大量オブジェクトの処理	敵や弾が増えるほどFPSが落ちる	処理を間引く、距離や範囲で制限する
頻繁な生成と破棄	InstantiateやDestroyが目立つ	オブジェクトプールを使う
毎フレームのGC Alloc	ProfilerでGC Allocが継続して出る	文字列生成や一時オブジェクトを減らす
画面内の大量描画	RenderingやBatchesが多い	描画対象を減らす、同じ素材をまとめる

たとえば、弾が100個ある状態で、それぞれが毎フレームGameObject.Findをしているなら、かなり優先度が高いです。逆に、タイトル画面で1回だけ実行する検索処理なら、急いで直さなくてもよい場合があります。

修正するか迷ったときは、次の4つを確認してみてください。

• その処理は毎フレーム実行されているか
• その処理を持つオブジェクトは大量にあるか
• Profiler上で処理時間やGC Allocが目立つか
• 修正前後で数値を比較できるか

この4つに多く当てはまるほど、先に直す価値があります。

後回しでよい処理

反対に、すぐ直さなくてよい処理もあります。最適化は大切ですが、効果が小さい場所まで無理に書き換えると、コードの見通しが悪くなることがあります。

後回しにしやすいのは、次のような処理です。

• ゲーム開始時に1回だけ実行される軽い処理
• Profilerでほとんど目立っていない処理
• 修正してもFPSへの影響を測りにくい処理
• 可読性を大きく下げる細かすぎる最適化
• 原因が分からないまま行う大規模な作り直し

たとえば、少しでも軽くしたいからといって、いきなりJob SystemやECSに移行する必要はありません。大量の計算処理が本当にボトルネックになっているなら候補になりますが、まずは通常のProfiler確認と基本的な改善で十分なことも多いです。

また、コードを短くすることと、ゲームを軽くすることは同じではありません。読みやすさを大きく失う最適化は、あとからバグの原因になることがあります。特にチーム開発や長く運用するゲームでは、「少し速いけれど直しにくいコード」より、「必要な場所だけ軽くした読みやすいコード」のほうが扱いやすいです。

修正後は必ず測り直す

最適化をしたら、必ず修正前と同じ場面で測り直しましょう。体感だけで判断すると、改善したように見えても、別の場面で重くなっていることがあります。

確認したい項目は次の通りです。

• 平均FPSが上がったか
• 1フレームの処理時間が下がったか
• 一瞬だけ跳ねるスパイクが減ったか
• GC AllocやGC.Collectが減ったか
• 実機でも同じように改善しているか

たとえば、Editor上ではFPSが上がっていても、スマホ実機では発熱や端末性能の影響で結果が変わることがあります。特にモバイル向けゲームでは、数分プレイしたあとも安定しているかを確認しておくと安心です。

セーブ・ロード処理やデータ管理を整理したい場合は、専用アセットを使う方法もあります。FPS改善の中心ではありませんが、保存処理まわりを自作しすぎて複雑になっている場合は、開発効率を上げる選択肢になります。

Easy Save
✅ Unity Asset Storeでチェックする

---

まとめ：Unity最適化は原因別に直す

UnityでFPSが落ちると、つい「とりあえず軽そうな設定に変えよう」と考えたくなります。ですが、原因が分からないまま直し始めると、時間をかけても改善しないことがあります。

まずは、ゲーム中の症状を見て原因の候補を絞りましょう。一定間隔で一瞬止まるならGCや生成・破棄、敵や弾が増えると重いならUpdateや物理演算、見た目が派手な場面だけ重いなら描画負荷を疑います。

そのうえで、Unity Profilerを使って実際の処理時間を確認します。CPU Usage、Rendering、Memory、GC Allocを見ると、どこに負荷が集まっているのか判断しやすくなります。

• BehaviourUpdateが重いなら、Update内の不要処理を減らす
• GC Allocが多いなら、生成・破棄や文字列更新を見直す
• Renderingが重いなら、描画対象やエフェクトの重なりを確認する
• Physicsが目立つなら、ColliderやRigidbodyの数を見直す
• Canvas関連が重いなら、UI更新やCanvas分割を確認する

最適化で大切なのは、全部を完璧に直そうとしないことです。毎フレーム実行される処理、大量に存在するオブジェクト、頻繁に生成・破棄されるもの、Profilerで目立つ処理から優先して直すと、作業の効果を確認しやすくなります。

反対に、1回しか実行されない軽い処理や、Profilerで目立っていない処理は、後回しで大丈夫なことも多いです。細かい最適化を積み重ねるよりも、プレイヤーが実際にカクつきを感じる場面から直していきましょう。

最後に、修正後は必ず同じ場面で測り直してください。平均FPSだけでなく、スパイクが減ったか、フレーム時間が安定したか、実機でも改善しているかを見ると、最適化の効果を判断しやすくなります。

Unityの最適化は、勘で直す作業ではなく、原因を見つけて順番に対処していく作業です。症状を見て、Profilerで確認し、効果が大きい場所から直す。この流れを作れると、FPS改善で迷う時間をかなり減らせます。

---