为何选择 Unity 的企业易陷“赤字体质”：从 Flash 历史看技术选型的结构性风险

※本記事について
本記事は、筆者がゲーム開発の現場で抱えている課題感や知見をもとに、AI（Antigravity / Gemini）と壁打ち・議論した内容をAIに整理・執筆させたものです。

はじめに：なぜ「Unityにすれば早く作れる」が実現しないのか

ゲーム開発の現場において、新規プロジェクトの技術選定で 「今流行っているから」「経験者を採用しやすいから」 という理由で Unity が選ばれるケースは珍しくありません。

そこにはしばしば、以下のような期待が込められています。

「Unity を使えば、開発期間が半分になるはずだ」
「少人数でも、リッチで高品質なゲームが作れるはずだ」

しかし、実際の商業開発の現場でよく耳にするのは、開発期間が短縮されたという話ではなく、「リッチな表現を追求するあまり要求水準がインフレし、かえって開発期間も工数も膨れ上がっている」 という声ばかりです。

本記事では、特定のエンジンを批判することではなく、「事業採算（損益分岐点）」「CI/自動化の運用コスト」「企業開発の前提条件」 という構造的な観点から、なぜ「流行っているからUnity」という安易な選定が現場を疲弊させやすいのか、そしてかつての Adobe Flash と同じ歴史を繰り返さないための現実的な生存戦略について整理します。

1. 見落とされがちな「ライセンス固定費」と損益分岐点の上昇

技術選定の議論では機能や描画性能ばかりが注目されがちですが、ビジネスとして見落とせないのが 「ライセンスの固定費が事業の損益分岐点を直接押し上げる」 という事実です。

非エンジニアまで含めた「全職種ライセンス配布」の過剰投資

ある程度の規模を持つ開発組織（たとえば数十〜百名規模の現場）で Unity を全面採用すると、エンジニアだけでなく以下のような職種にもライセンスが配布され、組織の大部分（8割近く）が有料シートを保持している という状況が起きがちです。

エンジニア / テクニカルアーティスト
ディレクター / プランナー
レベルデザイナー
デザイナー
QA（品質保証）

仮に Unity Pro（1シート年額約34万円前後）を数十〜80名規模で契約すれば、開発を始める前から毎年数千万円規模の固定費 が発生し続けます。

「必要売上」が高くなるという構造的リスク

本来、昔ながらの C++ ベースの実装や自社エンジン、あるいは cocos2d-x や Godot のようなライセンス費ゼロの環境で開発していれば、人件費と最低限のインフラ費だけで済むため、小〜中規模のヒットでも十分に黒字化できます。

しかし、高額なライセンス固定費が毎年乗ることで、「最低限確保しなければならない売上ライン（損益分岐点）」が跳ね上がり、一定以上の大ヒットを出さないと利益が出ないハイリスクな体質 へと変化してしまいます。

2. 「CI/E2E自動テスト」を回そうとした瞬間に直面する三重苦

近年では、AI（VLM：視覚言語モデル）を使ったUIのレイアウト崩れチェック、レベルデザイン調整のためのバトル周回シミュレーション、特定画面の自動スクリーンショット撮影などを CI（GitHub Actions 等）で回したいというニーズが高まっています。

ところが、Unity でこれを実現しようとすると、Web開発の感覚では想像できないほどの「ライセンス制約」と「インフラ構築の手間」が立ちはだかります。

① 並列実行の台数分だけライセンスを消費する制約

一定以上の収益がある企業では、CI 上の実行であっても無料版（Personal）の使用は規約違反となります。さらに Unity Test Framework 等で Unity エディタをバッチモード起動して E2E テストを並列実行する場合、同時に起動するコンテナやマシンの数だけ有料ライセンス（Pro または Build Server）が必要 になります。

Web開発のように「無料の Docker コンテナを 10並列、20並列で気軽に立ててテストを回す」ことができないのです。

② 職種ごとのフロー違いによる「ビルド待ちの渋滞」

ライセンス消費を 1ライン（ビルド用）に抑えるために「1台のマシンでビルドして、完成したバイナリを複数のテストランナーに配る」という構成を組むことは可能です。しかし、実務では複数の開発者が同時に PR を出すため、結局 「ビルド順番待ちの渋滞」 が発生します。

しかも、確認したい観点は職種ごとにバラバラです。

職種	主な変更対象	確認したい内容	理想のフロー
プランナー	マスターデータ、CSV/JSON	バトル周回・バランス集計	コード変更なしならビルド不要で即回したい
デザイナー	UIプレハブ、画像、シェーダー	実機画面・VLMによる見た目チェック	アセット差し替えだけで数分で確認したい
エンジニア	C#スクリプト、基盤システム	ロジックの単体テスト・結合テスト	`.NET` 単体で高速に回したい

これらを一律の重い Unity ビルドパイプラインに乗せると無駄な待ち時間ばかりが増えるため、現場は「メインブランチのベースラインビルドをキャッシュし、データやアセットだけを外部注入する仕組み」や「PRラベルでのトリガー分岐」など、ゲームの本質とは関係ないインフラのハックに膨大なエンジニアリング工数を奪われる ことになります。

③ 重厚な状態（Library フォルダ）の維持コスト

数GB〜数十GBに膨らむ Library フォルダのキャッシュ管理や、macOS ビルド用の専用ランナー維持など、本来はゲームの中身を作ることに使いたかった時間とコストが、環境維持のために吸い取られていきます。

[Web開発 / C++・自社エンジン / cocos2d-x / Godot]
  コードPush ─> 軽量コンテナを並列起動（ライセンス費 ¥0） ─> 即座にテスト・検証完了

[Unity (商業開発)]
  コードPush ─> ライセンス枠の空き待ち ─> 巨大なLibraryキャッシュ復元 ─> 重いビルド
                    └─ これを回避するための独自基盤開発にエンジニア工数が奪われる

3. 「少人数でリッチに早く作れる」という幻想の正体

それでも「個人開発や小規模チームが Unity でリッチなゲームを短期間で作っているじゃないか」という反論はよく聞かれます。

しかし、そこには 「個人開発（インディー）」と「一般企業の商業開発」の決定的な前提条件の違い が見落とされています。

比較項目	個人開発・小規模インディー	一般企業の商業開発
素材・アセット調達	アセットストアを全面流用でき、数日で見栄えのベースを作れる	権利・ブランディング・IP制約上、既製品の流用ができずほぼ内製・外注が必要
ライブラリ・ツール	動くものを優先し、サードパーティ製アセットを即座に組み込める	長期運営・保守性・バージョンアップ耐性の観点からブラックボックスを嫌い内製しがち
開発体制	1〜数名の阿吽の呼吸で進行できる	ディレクター・企画・デザイン・開発の分業と承認フローが必要

個人開発が「早く安くリッチに」作れる最大の理由は、アセットストアの既製品や汎用プラグインをフル活用できるから です。

他社と見た目が被ることを避けなければならない商業タイトルや、長期運営を見据えてブラックボックス化した外部ツールを避けたい企業開発では、Unity の最大の武器である「アセットストアによるショートカット」を享受できません。結果としてすべてを自前で作り込むことになり、ツールの多機能さと重さだけがプロジェクトにのしかかります。

4. 「人材確保のためのUnity」という自己矛盾と、繰り返されるFlashの歴史

会社側が「流行っているから Unity」と推す最大の理由は 「人材の採用しやすさ」 です。確かに昔ながらの C++ ベースの自社エンジンや cocos2d-x 等を扱えるエンジニアは減っており、市場に Unity 経験者が多いのは事実です。

しかし、ここにはある種の 自己矛盾（鶏と卵の悪循環） が潜んでいます。

「人材確保のために Unity を選ぶが、そもそもなぜ大量の人材が必要になるのかといえば、リッチ化によって開発規模が膨れ上がっているから」

本来であれば、少人数・低コスト（C++・自社エンジン、cocos2d-x、Godot 等）で完結するスコープのゲームを作れば、大量の人材確保も高額なライセンスも不要です。しかし「リッチ化」を前提にするあまり、以下の悪循環に陥ります。

リッチな表現を追求し、開発規模と期間が膨らむ
人手が足りなくなり、採用しやすい Unity を選ぶ
Unity にしたことでさらに要求水準（期待値）が上がり、演出・工数が膨らむ
全職種へのライセンス費と増えた人件費を回収するため、さらに高い売上を狙う大作志向になる

かつての Adobe Flash と完全に重なる流れ

この構造は、2000年代後半〜2010年代前半のブラウザゲーム全盛期における Adobe Flash の栄枯盛衰と驚くほど一致 しています。

「採用しやすい・協業しやすい」による一強体制: Flash 職人を雇えばデザイナーと協業してリッチなゲームが作れると業界標準になった。
リッチ化競争による肥大化: 当初は数人で数週間で作れた軽量なゲームが、差別化のために演出・アニメーションを極限までリッチ化し、開発コストが暴騰した。
特定企業への完全ロックイン: 社内フレームワークからアセット、人材スキルまで特定企業の独自仕様に依存しきった結果、仕様変更や方針転換が起きた際に逃げられなくなった。
軽量・オープン標準への回帰: 重厚長大化した Flash は、最終的に軽量でオープンな HTML5 / JavaScript（およびネイティブ）へと主役の座を奪われた。

現在、「重すぎる・ライセンスに縛られる Unity」に対して、「軽量でライセンス縛りのない C++ 基盤・自社実装、あるいはオープン（MITライセンス）な Godot や cocos2d-x 系（Axmol 等）」が再評価され始めている流れは、まさに当時の 「Flash vs HTML5」の構図そのもの です。

5. 現場エンジニアとしての現実的な生存戦略

では、こうした構造的な罠の中で、現場のエンジニアや技術選定に関わる立場はどう立ち回るべきでしょうか。現実的な打ち手は大きく 2 つあります。

戦略①：損益分岐点（必要売上）からエンジンを選ぶポートフォリオ

すべてのプロジェクトを一律に高コストな構造へ乗せるのではなく、「狙う売上規模とスコープ」に応じてエンジンを使い分ける 視点を持つことです。

高い収益が見込める大型 3D 案件: 採用力や SDK 対応の速さを活かして Unity を採用する。
2D 中心・小〜中規模・運用型案件: ライセンス費ゼロで CI も軽快に回る 昔ながらの C++ / 自社エンジン実装 や cocos2d-x、あるいは Godot といった環境を活かし、「低い売上でも確実に黒字になる体質」を守る。

特にすでに社内に C++ ベースの自社エンジンや cocos2d-x の知見・資産がある場合、それは他社が今から真似しようとしてもできない「低コスト開発の強力な武器」です。流行に流されて軽量開発ラインの火を完全に消してしまうと、将来採算が合わなくなった際に戻れる場所を失います。

戦略②：それでも Unity を使うなら「クリーンアーキテクチャ + DI」で脱Unity依存を徹底する

事業判断として Unity を使う場合でも、「社内フレームワークやゲームのコアロジックまで Unity（MonoBehaviour や UnityEngine 名前空間）に密結合させない」 ことが極めて重要です。

┌───────────────────────────────────────────────────────────┐
│ Unity 依存層 (Adapter / View / Composition Root)          │
│   - MonoBehaviour, SpriteRenderer, UI, サウンド再生       │
│   - VContainer / Zenject 等での DI 組み立て               │
└─────────────────────────────┬─────────────────────────────┘
                              │ Interface 経由で接続
                              ▼
┌───────────────────────────────────────────────────────────┐
│ 純粋な C# (.NET Standard 2.1) コア層                      │
│   - バトル計算・ステートマシン・マスターデータ管理        │
│   - 通信基盤・暗号化・社内共通フレームワーク              │
│   ※ using UnityEngine; を一切禁止 (asmdef で強制分離)     │
└───────────────────────────────────────────────────────────┘
         │
         └─> CI 上では Unity ライセンス不要の `dotnet test` で
             無料コンテナを使って無制限・高速に並列周回テスト可能！

コアロジックと社内基盤を純粋な C# に分離する: asmdef（Assembly Definition）で UnityEngine への参照をコンパイルレベルで禁止し、バトル計算やデータ管理を独立させます。これにより、Unity ライセンスを 1 つも消費せず dotnet test だけでバトル周回やバランス検証を無制限に並列実行 できます。
エンジン機能は Interface で抽象化する: 時間経過（ITimeProvider）やアセット読み込み（IAssetLoader）などをインターフェース越しに扱い、テスト時はモックを差し込めるようにします。
DI はコンストラクタインジェクションに限定する: ドメイン層に特定の DI フレームワーク固有の属性（[Inject] 等）を持ち込まず、標準 C# のコンストラクタのみで受け取る設計にしておけば、将来万が一別の C# 対応エンジン（Godot C# 等）へ移行する際もコア資産をそのまま移植できます。
非エンジニアのライセンスを削減する: ディレクター・QA・レベルデザイナーの画面確認やデータ調整を「CI が自動生成した実機ビルドの配布」と「Web 管理画面・スプレッドシート」へ逃がすことで、エディタ用ライセンスの契約数を劇的に圧縮できます。

まとめ

「Unity にすれば早く安く作れる」は、アセット流用ができる個人開発の前提や、厳密なスコープ制限があって初めて成立する話である。
商業開発において無自覚に「流行っているから」で Unity を選び、全職種へのライセンス配布とリッチ化競争に突入すると、ライセンス固定費・CI構築工数・開発期間が雪だるま式に膨らみ、事業の損益分岐点を押し上げる。
歴史的に見れば、これはかつて Adobe Flash が辿った「採用のしやすさ → リッチ化による肥大化 → ロックイン」の流れ と同型である。
現場として取るべき対策は、「昔ながらの C++ 実装・自社エンジンや軽量エンジン（Godot / cocos2d-x 等）による低コスト開発の選択肢を消さないこと」、そして「Unity を使う場合でもクリーンアーキテクチャ + DI によってコア資産をエンジンから切り離し、特定の商用プラットフォームに殺されない構造を作っておくこと」である。