UnityのECSで超高速処理！ゲームのパフォーマンスを飛躍的に向上させる方法

敵や弾、NPCの数が増えてくると、あるタイミングで急にゲームが重くなる——。
Unityで開発していると、多くの人が一度はこの壁にぶつかります。

Profilerを開いてみると、原因はだいたい同じ。
大量のGameObjectと、それぞれで毎フレーム呼ばれるUpdate処理です。

もちろん、MonoBehaviourやオブジェクト指向設計が悪いわけではありません。
Unityの標準的な開発スタイルとして、とても扱いやすく、学習コストも低い優れた仕組みです。

ただし問題になるのは、オブジェクト数が数千・数万規模に膨れ上がったとき。
弾幕系、群衆シミュレーション、交通AI、放置・シミュレーションゲームなどでは、 「ちゃんと書いているのに、なぜか重い」という状態に陥りがちです。

そこで登場するのが、UnityのECS（Entity Component System）です。

ECSは単なる高速化テクニックではありません。
「Updateを減らす」「処理を工夫する」といった小手先の最適化ではなく、
ゲームの設計そのものを“大量データ処理向け”に作り替えるための仕組みです。

とはいえ、

• ECSって難しそう
• 本当に速くなるの？
• 全部ECSにしないとダメ？

こんな不安を感じている人も多いと思います。

この記事では、UnityのECS（DOTS）について、

• なぜECSは大量オブジェクト処理に強いのか
• どんなケースで導入すべきか、逆に不要なのか
• 実務で失敗しにくい現実的な使いどころ

この3点を中心に、設計の考え方を軸にして解説していきます。

「Update依存の設計に限界を感じている」
「そろそろ次のレベルの最適化を知りたい」

そんなUnity中級者の方に、特に役立つ内容になっています。
一緒に、処理落ちと設計で戦わないゲーム構造を見ていきましょう🙂

---

結論：Unity ECSは「大量データ処理」に特化した最適解

結論から言うと、UnityのECSはすべてのゲームを高速化する万能薬ではありません。
しかし、大量のオブジェクトや同種の処理を毎フレーム繰り返すゲームにおいては、 従来のGameObject設計とは次元の違うパフォーマンスを発揮します。

重要なのは、「ECSを使うと速くなる」という理解ではなく、
ECSは“速く処理できる設計を前提にした仕組み”だという点です。

MonoBehaviour中心の設計では、

• オブジェクトごとにUpdateが呼ばれる
• メモリ配置が分散しやすい
• 処理の流れがオブジェクト単位でバラける

といった構造上の制約があります。
これは「書き方が悪い」のではなく、設計思想そのものが小〜中規模向けだからです。

一方ECSでは、

• データをまとめて保持し
• 同じ処理を一括で実行し
• CPUキャッシュとマルチコアを最大限活用する

という前提で設計されます。
その結果、数千〜数万単位のエンティティでも現実的な処理が可能になります。

ここで勘違いしやすいのが、「Updateを減らせばECSと同じでは？」という考えです。
確かにUpdate削減は有効ですが、それには限界があります。

この違いをより具体的に理解したい場合は、
Update最適化の基本を先に押さえておくと理解が深まります。

ECSは「Updateを減らす」のではなく、
そもそもUpdateという考え方に依存しない設計を実現するための選択肢です。

そのため、

• オブジェクト数が少ないゲーム
• UIや演出が中心のゲーム

では、導入コストに見合わないケースもあります。

逆に、

• 弾幕・群衆・交通・シミュレーション
• 同じロジックを大量のオブジェクトに適用する
• CPU負荷がボトルネックになっている

こうした条件が揃っているなら、ECSは最適解になり得ます。

---

なぜGameObject設計は大量オブジェクトに弱いのか

Unityでオブジェクト数が増えたときに起きる処理落ちは、
コードの書き方というより、GameObject＋MonoBehaviourという設計構造そのものに原因があることがほとんどです。

まず大きな要因が、Updateがオブジェクト単位で呼ばれるという仕組みです。

たとえば敵が1,000体いれば、1フレームで1,000回Updateが実行されます。
1回あたりの処理が軽くても、

• 関数呼び出しコスト
• 分岐処理
• 参照アクセス

が積み重なり、CPU負荷は一気に増えていきます。

さらに厄介なのが、メモリ配置の問題です。

GameObjectとMonoBehaviourは、それぞれが独立したオブジェクトとしてメモリ上に存在します。
そのため、同じ種類のデータであっても、

• メモリ上にバラバラに配置される
• CPUキャッシュに乗りにくい
• キャッシュミスが頻発する

といった状態になりやすくなります。

これは近年のCPU事情とも関係しています。
CPUのコア数は増えていますが、メモリアクセス速度の伸びは限定的です。

つまり、「たくさんの小さな処理をバラバラに行う」設計は、
現代のCPU構造と相性が悪くなってきている、というわけです。

もう一つ見逃せないのが、GC（ガベージコレクション）の影響です。

大量のオブジェクト参照、List操作、LINQ、Boxingなどが重なると、
フレーム単位では見えなくても、ある瞬間にGCが走って一気にカクつくことがあります。

GCによる処理落ちについては、こちらの記事で詳しく解説しています。

こうした問題は、

• 「Updateを減らす」
• 「処理を軽く書く」

といった工夫である程度は改善できます。
しかし、オブジェクト数が増え続ける設計では、いずれ限界が来ます。

ECSは、この問題を「最適化」ではなく、
設計そのものを変えることで解決しようとするアプローチです。

---

Unity ECSの基本概念を「設計視点」で理解する

ECSを学び始めたとき、多くの人が最初につまずくのが、

• Entityって何？
• ComponentはMonoBehaviourと何が違うの？
• Systemはどこに処理を書くの？

といった用語ベースの理解です。

ただ、ECSを本当に使いこなすために大切なのは、 クラス構造を覚えることではありません。
「設計の見方」を切り替えることです。

Entity：ただの「ID」だと割り切る

ECSにおけるEntityは、GameObjectの代替ではありますが、 役割はまったく違います。

Entityはデータもロジックも持たない、単なる識別子です。
「このデータのまとまりを指す番号」くらいに考えると、かなり気が楽になります。

見た目も、Transformも、挙動も持っていません。
あるのは「どのComponentを持っているか」だけです。

Component：状態だけを持つ純粋なデータ

ECSのComponentは、データ専用です。

MonoBehaviourのように、

• Updateを書く
• 他のComponentを参照する
• 処理を持つ

といったことはしません。

位置、速度、HP、フラグなど、
「今どういう状態か」だけを表すstructとして定義します。

ここが、オブジェクト指向設計との決定的な違いです。

System：処理はすべてここに集約する

ロジックはすべてSystemが担当します。

Systemは、

• 特定のComponentを持つEntityをまとめて取得し
• 同じ処理を一括で実行する

という役割を持ちます。

この「まとめて処理する」という考え方が、
ECSが高速な最大の理由です。

オブジェクト指向では、

「オブジェクトが自分の処理を知っている」

という設計が基本ですが、ECSでは真逆になります。

「データは何も知らない。処理する側が全部知っている」
これが、ECSの設計思想です。

この違いは、従来のオブジェクト指向設計を深く理解しているほど、 最初は戸惑いやすいポイントでもあります。

もし「これまでの設計と何がどう違うのか」を整理したい場合は、 こちらの記事も参考になります。

ECSはオブジェクト指向を否定するものではありません。
大量データ処理に特化した、別の設計アプローチです。

---

DOTSの3本柱で何が起きているのか

UnityのECSが「速い」と言われる理由は、ECS単体の仕組みだけではありません。
本当の力を発揮するのは、DOTS（Data-Oriented Technology Stack）の3本柱が 組み合わさったときです。

その3本柱が、次の3つです。

• ECS（Entity Component System）
• C# Job System
• Burst Compiler

それぞれの役割を、「何を担当しているのか」という視点で整理してみましょう。

ECS：メモリ配置とデータ構造を最適化する

ECSの役割は、データをCPUが扱いやすい形で並べることです。

同じComponentを持つEntityのデータは、
メモリ上に連続して配置されます。

これにより、

• CPUキャッシュに乗りやすい
• 無駄なメモリアクセスが減る

という状態が自然に作られます。

ECSは「速く処理する仕組み」というより、
速く処理できる前提条件を整える仕組みだと考えると分かりやすいです。

Job System：CPUのマルチコアをフル活用する

C# Job Systemは、処理を複数スレッドに分割して並列実行するための仕組みです。

MonoBehaviourのUpdateでは、
基本的にメインスレッドで順番に処理が実行されます。

一方、Job Systemでは、

• 大量のEntity処理を分割し
• 複数のCPUコアで同時に実行

できます。

これにより、コア数が多いほどスケールする設計が可能になります。

Job SystemとBurstの実践的な使い方については、こちらで詳しく解説しています。

Burst Compiler：C#をネイティブレベルまで最適化する

Burst Compilerは、C#で書いた処理を、
高度に最適化されたネイティブコードへ変換します。

SystemやJobに[BurstCompile]を付けるだけで、

• 不要な処理の削除
• SIMD最適化
• 分岐の最適化

といったコンパイル最適化が自動で行われます。

その結果、C#で書いているにもかかわらず、
C++に近いパフォーマンスを引き出せるケースもあります。

3つは「セット」で初めて意味を持つ

ここで大切なのは、
ECS・Job System・Burstは単体で使うものではないという点です。

ECSでデータを整理し、
Job Systemで並列化し、
Burstでネイティブ最適化する。

この3つが揃って、初めて

「Unityで数万単位のオブジェクトを現実的に処理する」

という世界が見えてきます。

---

ECS導入の基本フロー（Authoring〜Systemまで）

ECSは設計思想が大きく異なるため、いきなりコードを書き始めると混乱しやすいです。
ここでは、実務でつまずきにくい導入の流れを、全体像として整理します。

ポイントは、「全部理解してから使う」のではなく、
最低限の流れを押さえて、小さく動かすことです。

① Entitiesパッケージを導入する

まずはUnity Package Managerから、Entitiesパッケージを導入します。

Entitiesを入れると、以下のパッケージも依存関係として追加されます。

• C# Job System
• Burst Compiler
• Unity Mathematics
• Collections

この時点で、ECS・Job・Burstの基盤が揃います。

② Componentを定義する（データだけを書く）

次に行うのが、Componentの定義です。

ECSのComponentは、
「処理を書かない」「参照を持たない」のが鉄則です。

位置、速度、HP、フラグなど、
純粋な状態データだけをstructとして定義します。

ここで「MonoBehaviourっぽく書きたくなる」のを、ぐっと我慢するのが最初の関門です🙂

③ Authoring & BakingでGameObjectとつなぐ

ECSでは、エディタ上で値を設定するために、
Authoring → Bakingという仕組みを使います。

AuthoringはMonoBehaviourで、

• インスペクターで値を設定し
• Bakerを通して
• ECS用Componentに変換する

という役割を持ちます。

この工程のおかげで、
「エディタ操作は今まで通り、実行時はECS」というハイブリッドな運用が可能になります。

④ SubSceneを使ってEntityに変換する

実務では、SubSceneの利用がほぼ必須になります。

SubScene内に配置したGameObjectは、
再生時に自動でEntityへ変換されます。

これにより、

• 大量Entityの生成が高速
• 変換コストを事前に吸収できる

といったメリットがあります。

⑤ Systemでロジックをまとめて処理する

最後に、処理を書くのがSystemです。

最近のEntitiesでは、
ISystemが推奨されるケースが増えています。

Systemでは、

• 特定のComponentを持つEntityをクエリし
• foreachなどで一括処理する

という流れになります。

ここで重要なのは、
「1Entityずつ考えない」という意識です。

「この条件を満たすデータ群に、同じ処理を流す」
この考え方に慣れると、ECS設計が一気に楽になります。

---

ECSで「本当に差が出る」実践テクニック

ECSを導入しただけでは、劇的なパフォーマンス改善が起きないケースもあります。
差が出るかどうかは、「どこをどう使っているか」で決まります。

ここでは、実務で効果を実感しやすいテクニックを中心に紹介します。

タグコンポーネントで高速に分類する

ECSでは、データを持たないComponentを 「タグ」として使うことができます。

たとえば、

• EnemyTag
• PlayerTag
• BulletTag

のようなタグを付けておけば、
特定のEntityだけを非常に低コストでフィルタリングできます。

boolフラグやenumを毎回チェックするよりも、
クエリ段階で対象を絞れるため、処理効率が大きく向上します。

Enableable Componentsで状態切り替えを軽くする

ECSには、Componentを削除せずに
有効・無効を切り替えられる仕組みがあります。

これを使うと、

• スタン中
• 無敵状態
• 一時停止中

といった状態管理を、
構造的変更なしで実現できます。

構造的変更（Componentの追加・削除）は高コストなので、
Enableable Componentsは大量Entity管理で特に効果的です。

Entity Command Bufferで安全に変更する

Jobや並列処理の中で、

• Entityを生成する
• 削除する
• Componentを追加・削除する

こうした処理を直接行うと、競合が発生します。

そこで使うのが、Entity Command Buffer（ECB）です。

変更内容を一度バッファに溜めて、
メインスレッドでまとめて反映することで、
安全かつ高速な構造変更が可能になります。

Aspectで可読性と再利用性を上げる

複数のComponentを毎回クエリに書くと、
コードが読みにくくなりがちです。

Aspectを使うと、

• 関連するComponentをひとまとめにする
• 処理単位で意味のある構造を作る

ことができます。

結果として、ECSでも保守しやすいコードになりやすくなります。

「計測しない最適化」はほぼ意味がない

ここで、とても重要な話をします。

ECSを使っていても、
どこが速くなっているのかを把握していなければ、改善は続きません。

「なんとなく速くなった気がする」では、
設計の判断を誤りやすくなります。

実務では、ECS導入前後で、

• CPU負荷
• ジョブ実行時間
• フレームごとの変動

を必ず可視化することが大切です。

そのための補助ツールとして、
ECSやDOTS環境と相性の良いパフォーマンス計測アセットがあります。

Performance Tools

✅アセットストアでチェックする

「ECSを使っているのに速くならない」と感じたら、
まずは計測できているかを疑ってみてください。

---

メモリ・CPU負荷を“見える化”する重要性

ECSを導入すると、処理構造が大きく変わるため、
「何がボトルネックになっているのか分かりにくくなる」という問題が出てきます。

特に多いのが、

• フレームレートは安定しているのに、時々カクつく
• どのSystemが重いのか判断できない
• メモリ使用量が増えているのか減っているのか分からない

といった状態です。

これはECSが悪いのではなく、
内部で起きている処理が「見えにくい設計」だからこそ起こります。

フレームレートだけ見ても意味がない

「60fps出ているから大丈夫」と判断してしまうのは、
ECSでは特に危険です。

なぜなら、

• ジョブの実行タイミング
• メモリ確保・解放
• 一時的な構造的変更

これらはフレームレートに表れにくいからです。

ECSでは、
CPU時間・ジョブ実行時間・メモリアロケーションをセットで見る必要があります。

メモリ配置が変わると、見るべき指標も変わる

ECSでは、データが連続配置される一方で、

• Chunk単位のメモリ管理
• 構造的変更による再配置

といった、MonoBehaviour時代には意識しなかった要素が増えます。

そのため、

「今、どのComponentがどれだけメモリを使っているのか」

を把握できないと、
最適化の方向性を誤りやすくなります。

DOTS環境では専用ツールがあると圧倒的に楽

Unity標準のProfilerでも基本的な確認はできますが、
ECSやDOTSを本格的に使う場合、メモリ周りの可視化が不足しがちです。

そこで役立つのが、
DOTS向けに設計されたメモリ解析ツールです。
Profiler Memory Plus

✅アセットストアでチェックする

この手のツールを使うと、

• Componentごとのメモリ使用量
• アロケーションの発生箇所
• フレームごとの増減

を視覚的に確認できます。

「ECSにしたのに、なぜかメモリが増えた」
「どこを直せば軽くなるのか分からない」

そんな状態に陥る前に、
見える化 → 判断 → 改善の流れを作っておくことが大切です。

---

ECSはどんなゲームで真価を発揮するのか

ここまで読んで、

「ECSは速そうだけど、自分のゲームに本当に必要なのか？」

と感じている方も多いと思います。

ECSは強力ですが、向き・不向きがはっきり分かれる技術です。
この章では、実務視点で「使うべきケース」「使わなくていいケース」を整理します。

ECSが特に向いているケース

ECSの恩恵を受けやすいのは、次のようなゲームです。

• 弾幕・シューティング系（弾や敵が大量に出る）
• 群衆・交通・都市シミュレーション
• 放置・経営・シミュレーションゲーム
• 大量のNPCが同じロジックで動くゲーム

これらに共通するのは、

「同じ種類の処理を、大量のデータに対して繰り返す」

という点です。

ECSはまさに、この条件のために作られた設計です。

「本当にそんな規模で動くの？」と感じた場合は、
実例を見るのが一番イメージしやすいです。
DOTS Traffic City

✅アセットストアでチェックする

都市内の車両や信号をECSで制御するサンプルで、
「ECSが想定しているスケール感」を体感できます。

ECSを無理に使わなくていいケース

一方で、次のようなゲームでは、

• UIや演出が中心
• オブジェクト数が少ない
• 複雑な個別挙動が多い

ECSのメリットは出にくくなります。

この場合、MonoBehaviour設計のまま、

• Update削減
• オブジェクトプール
• GC対策

を行ったほうが、開発効率は高いことも多いです。

「向いているかどうか」は途中で変わる

重要なのは、
最初からECS前提で作る必要はないという点です。

開発が進むにつれて、

• 敵数が増えた
• 処理が複雑になった
• CPU負荷が限界に近づいた

こうしたタイミングで、
重い部分だけをECSに切り出すのが現実的な選択になります。

---

ハイブリッド設計という現実的な落としどころ

ECSを知ると、

「全部ECSで作らないと意味がないのでは？」

と感じてしまう人も少なくありません。

ですが、実務的な結論から言うと、
ECSは“全部置き換える技術”ではありません。

むしろおすすめなのは、

重い処理だけをECSに任せ、それ以外は従来通りGameObjectで管理する

というハイブリッド設計です。

ECSが得意なこと、GameObjectが得意なこと

役割分担をはっきりさせると、設計はぐっと楽になります。

• ECS向き：大量データ処理、反復ロジック、数値計算、群衆・弾幕
• GameObject向き：UI、演出、アニメーション、入力、カメラ制御

UIや演出までECSで管理しようとすると、
設計が複雑になり、かえって開発効率が下がることも多いです。

「重いところだけECSにする」
この割り切りが、長く保守できる設計につながります。

ECSとGameObjectはどうやって連携する？

ハイブリッド設計では、
データの受け渡しがポイントになります。

よく使われるのが、

• Singleton Componentで状態を管理する
• Systemから値を取得してMonoBehaviour側で反映する
• イベントやフラグを介して疎結合に保つ

重要なのは、
GameObject側からECS内部を直接操作しすぎないことです。

「ECSはデータと計算担当」
「GameObjectは見た目と操作担当」

この境界を守るだけで、設計はかなり安定します。

完成系サンプルを見ると理解が一気に進む

ハイブリッド設計は文章だけだとイメージしづらいため、
実際に動いているサンプルを見るのが一番早いです。

ECSを使った交通・歩行者システムの完成例として、
次のアセットはとても参考になります。
The City – Traffic and Pedestrians ECS System

✅アセットストアでチェックする

ECSで重いロジックを処理しつつ、
表示や制御は従来のUnityワークフローを活かしているため、

「現実的なECSの使い方」がよく分かります。

---

よくある誤解・注意点

ECSは強力な仕組みですが、
使い方や期待値を間違えると、

「導入したのに速くならない」
「むしろ開発が大変になった」

という結果になりがちです。

ここでは、実務で特に多い誤解と注意点を整理します。

ECSにしただけで自動的に速くなるわけではない

一番多い誤解がこれです。

ECSは正しい設計をしたときに初めて力を発揮する仕組みです。
MonoBehaviour時代の考え方のまま、

• EntityをGameObject感覚で扱う
• System内で分岐だらけの処理を書く
• 構造的変更を頻繁に行う

こうした使い方をすると、
期待したほどのパフォーマンスは出ません。

オブジェクト数が少ないと効果はほぼ出ない

ECSは「大量データ処理向け」の設計です。

Entityが数十〜数百程度しかない場合、

MonoBehaviourのほうが速い・書きやすい

というケースも珍しくありません。

無理にECSを使うと、

• コード量が増える
• 学習コストが上がる
• デバッグが難しくなる

といったデメリットだけが目立ってしまいます。

構造的変更の多用はパフォーマンスを殺す

ECSで特に注意したいのが、構造的変更です。

Componentの追加・削除やEntityの生成・破棄は、
内部的にメモリ再配置を伴うため、コストが高くなります。

状態切り替えのたびにComponentを付け替えていると、
ECSのメリットが一気に薄れます。

そのため、

• Enableable Componentsを使う
• 変更はECBにまとめる

といった設計が重要になります。

「全部ECSにしないといけない」は完全な誤解

ECSはあくまで選択肢の一つです。

UI、演出、入力、カメラ制御まで含めて
ECSで統一しようとすると、

保守性と開発スピードが大きく落ちる

ことが多いです。

繰り返しになりますが、

重い処理だけECSに切り出す

これが、実務で最も失敗しにくい使い方です。

---

参考文献・公式ドキュメント

• Unity DOTS（Data-Oriented Technology Stack）公式ページ
• Unity ECS（Entity Component System）公式解説
• Unity Burst Compiler 公式マニュアル
• Unity Entities：SystemとJobのスケジューリング（公式ドキュメント）
• Unity DOTS/ECS入門解説（npaka氏・note）
• Getting Started with Unity DOTS – Part 1: ECS
• Getting Started with Unity DOTS – Part 3: Burst Compiler
• Unity ECSサンプルゲーム解説（Aiming開発者ブログ）
• Unity公式：DOTS/ECS 解説動画（YouTube）
• ゲームメーカーズ：Unity DOTS/ECS 解説記事
• Entity Component System（Wikipedia）
• Unity公式eBook：Understanding Unity DOTS

---

よくある質問（FAQ）