跳到正文
Qiita · Unity 开发社区· 来源· sator_imaging·· 3 小时前AI 评分53

AI生成多视角反论：Unity企业赤字体质论的局限与替代方案陷阱

🤖「Unityを選ぶ企業は赤字体質である。」に対する反論

正文 · 原文

はじめに

私は当該記事のタイトルに惹かれ、冒頭だけざっと読み、全文を読む前に以下のプロンプトを Gemini / Claude に投げました。

Unityを選ぶ企業は赤字体質である。
https://qiita.com/roripika/items/bdeb5537efc1f27af726

これを読んで、例えば (UE|Godot) なら上手くいくのか、という視点で反論記事を書いて。
反論自体を目的とせず、認めるべきは認めること。
また隣の芝生は青く見えるという視点を持って論を展開すること
（つまりそんなうまい話は無いのではないか、と私が思っているという事）

私の記事に対する考えは 👆 のプロンプトのみであり、以下の文章は一切の推敲やチャットのやり取り無しの AI ポンだしであり、何かを意図・示唆するものではありません。

  • 別視点欲しいな
  • 読む前に先に AI に生成させておくか
  • せっかくだからアップしておくか

程度の軽い気持ちの内容です。踏まえた上でご覧ください。

🤖 【Claude】 Unityが高いなら UE にすればいいのか？ — 隣の芝生を数えてみる

「Unityを選ぶ企業は赤字体質である。」（Qiita, 2026-11-13）への応答。数字は 2026年11月時点の公式ページ等による。

先に、元記事で同意するところ

元記事は「筆者の課題感を AI と整理したもの」とのことですが、診断の骨格はかなり正確だと思います。

  • Unity のシート料金は固定費で、人数が多いほど損益分岐点を押し上げる。Unity Pro は 2026年時点で $2,310/席/年。円換算で約34万円という元記事の数字は妥当。
  • 収益のある企業は CI 上でも Personal が使えず、並列数がライセンス数に響く制約は実在する。
  • 「少人数でリッチに早く」は、アセットストアを流用できる個人開発の前提で語られがち。企業開発では前提が違う。
  • 特定ベンダーに条件を握られるリスクも実在する。Unity は一度発表したランタイム料金を撤回しており、その後シート課金に戻って Pro/Enterprise は 2026年1月に 5% 値上げされた。

私が気になったのは別の点です。元記事の処方箋は自社 C++、cocos2d-x、Godot で、UE は勧めていません。それでも現場で一番出る疑問は「Unity が重いなら、別の大手に替えれば解決するのでは？」だと思います。UE は ゲームなら席料ゼロで、ソースも標準で読める、ライセンスだけ見れば最も条件のいい隣の芝生です。そこで、元記事の論点を UE にそのまま当てはめてみます。結論を先に言うと、コストは消えず、置き場所が変わるだけになりそうです。

1. 固定費は消えるのではなく、変動費に化ける

UE のゲーム向けライセンスは、席料なし、製品ごとの生涯グロス売上のうち $1M を超えた分に 5%、Epic Games Store 経由の売上は免除です。これは本当に良い条件で、元記事の「必要売上が跳ね上がる」問題には構造的に答えています。小さく当たった、あるいは当たらなかったタイトルでは UE が有利です。ここは素直に認めます。

ただし、売上が伸びると話が逆転します。ざっくり試算します（前提：1ドル=150円、80席、運用3年、$1M=1.5億円）。

  • Unity：80席 × $2,310 ≈ 2,770万円/年。3年で約 8,300万円。
  • UE：生涯グロス L に対して 5% × (L − 1.5億円)。
  • 逆転点は L ≒ 18億円。生涯グロス100億円なら UE のロイヤリティは約4.9億円で、Unity の席料の約6倍。

なお UE のロイヤリティは、ストアが徴収した分も含めた総売上が対象です（EGS を除く）。

つまり UE は 下振れに強く、上振れに弱い。元記事の「大ヒットしないと黒字にならない体質」の裏返しが「大ヒットしても取り分が目減りする体質」です。どちらが良いかは、そのタイトルの売上の期待値の分布で決まります。

もう一点。席料そのものの大きさも見ておきます。1人あたりの年間総コストを仮に 1,000万円とすると、80人で年8億円。Unity の席料 2,770万円はその約3.5%です。損益分岐点を動かす主役は人数×期間で、ライセンス料は二番手です。これは元記事4章の「リッチ化で開発規模が膨らむ」という指摘と整合します。本当に効いているのは要求水準のほうで、席数は元記事の戦略②にあるとおり絞れます。

2. CI：ライセンスは消えるが、重さは消えない

ここも認めるところから。UE には CI のライセンス制約がありません。コンテナやビルドエージェントを増やしても、かかるのはマシン代だけです。Horde、BuildGraph、UBA（Unreal Build Accelerator）など、分散ビルドの道具立ても公式にあります。元記事の②「並列数だけライセンスを消費する」は UE にはほぼ当てはまりません。

ですが、元記事が本当に困っていたのは「ビルド待ちの渋滞」と「重い状態の維持」でした。こちらは UE のほうが重い方向です。

  • 専用サーバー向けのビルドなどには、ランチャー版ではなくソースからビルドしたエンジンが要る（OSS のビルドツール Ludus の前提条件の記載による）。デバッグ情報込みのフルビルドで 350GB 超という報告や、初回ビルドが数時間〜10時間超という報告がある（ハード依存）。
  • Epic の公式フォーラムには、大規模案件で開発ビルド約8時間、本番ビルド約18時間という報告もある。一方で、Horde + UBA + キャッシュを整えれば、エディタの CI ビルドが10分以内という例もある。速くはできるが、その整備自体が専門職の仕事になる。
  • Unity の Library キャッシュ問題に相当するものとして、UE には DDC/Zen、Intermediate、cook 結果、シェーダーコンパイルがある。macOS/iOS 用の専用ランナーが要る点も同じ。

元記事の「ゲームの本質と関係ないインフラのハックにエンジニア工数を奪われる」という構図は、UE ではライセンスの行から工数の行に移るだけで、場合によっては増えます。無料で20並列できても、1ジョブが数時間かかるなら、渋滞は解消しません。

職種ごとのフロー違い（プランナーはビルド不要で回したい、など）は、エンジン非依存の話です。データ駆動の度合いと分離設計で決まり、エンジンを替えても解決しません。

戦略②（純粋なコア層を分離して、エンジン外でテストする）の UE 版も考えてみます。純 C++ のコア層を作って UE の外でテストすることは可能です（Build.cs のモジュール依存で参照の向きを縛ることもできます）。ただ私の理解では、UE の C++ は UObject、リフレクション、GC といった独自の型システムを前提にしているため、エンジン非依存のコアを保つには、意識的な設計規律が C# + asmdef より多く要ります。Unity の「UnityEngine 参照禁止を asmdef でコンパイル時に強制し、dotnet test で回す」は、この点では相当に安上がりな部類です。

3. 「少人数でリッチ」：期待値のインフレは UE のほうが強いかもしれない

元記事3章のとおり、企業開発はストア流用がしにくい構造です。UE の Fab（マーケットプレイス）も事情は同じです。

そのうえ UE5 は、Lumen、Nanite、World Partition などで標準状態から見栄えがします。標準で見栄えがするなら、競合も同じ見栄えを出してきます。すると「リッチが最低ライン」になります。元記事の「Unity にしたことでさらに要求水準が上がる」は、UE ではより強く起きるはずです（これは私の推論で、実証はしていません）。

逆に、2D 中心・小〜中規模の運用型は UE の本領ではありません。モバイルでは、空のプロジェクトでもパッケージが数十〜百数十 MB 規模になるという報告が長年あります（古い版の報告が多いので現行版は要確認）。元記事の「2D・小〜中規模は軽量エンジンを」という整理は、UE と比較しても筋が通っています。

4. 人材とロックイン：Flash の教訓は UE にも当てはまる

人材。 日本のモバイル・運用型では Unity 経験者のほうが厚いと一般に言われます（市場統計までは確認していません）。UE は C++ 前提で、採用・育成のコストが高くなりがちです。元記事の「人材確保のための Unity という自己矛盾」は、リッチ化が人員を膨らませる部分は鋭い指摘です。ただ、軽量エンジンや自社 C++ に寄せても人材問題は消えません。採用市場の薄い技術を選ぶのは、人材リスクを自社で抱える選択で、元記事自身も C++ 自社エンジンを扱える人材は減っていると認めています。

ロックイン。 Epic も条件を変えてきました。UE 5.4 から非ゲーム向けに席課金が導入され、2026年5月27日からは Unreal Subscription に Twinmotion と RealityScan が含まれなくなりました。ゲーム向けのロイヤリティは据え置きですが、「条件は変わりうる」は Unity だけの話ではありません。

Flash との同型性。 警告としては有効です。ただ Flash の衰退は、iOS 非対応を含むプラットフォーム側の転換が大きな要因とされ、「重さ」だけでは説明できません。Unity や UE はネイティブにビルドするので、ブラウザプラグインだった Flash とは構造も違います。同型とまでは言い切れないと思います。

まとめ：元記事の論点を UE に当てはめると

論点 Unity UE
ライセンスの形 席数ぶんの固定費 席料なし＋生涯売上 $1M 超に 5%
小さく当たった場合 固定費が重い 有利
大ヒットした場合 席料は相対的に小さい ロイヤリティが大きい（概算で約18億円超で逆転）
CI のライセンス制約 あり ほぼなし
CI の重さ・環境維持 Library キャッシュ等 ソースビルド、DDC/Zen、cook 等でむしろ重い傾向
エンジン非依存の設計 C# + asmdef で比較的容易 可能だが設計規律がより必要
2D・小規模運用型 実績は厚い 本領ではない
日本での人材 厚いと言われる C++ 前提で採用コストが高い傾向

結論：コストは保存される

エンジンを替えるのは、コストを置く場所を替える操作に近いです。Unity から UE への移行なら、固定費が変動費になり、ライセンス費がインフラ工数になり、採用市場の厚みが表現力の高さと引き換えになります。どれも「消える」わけではありません。

元記事の診断（固定費、CI 制約、前提条件の違い、ベンダー依存）はおおむね正しいと思います。処方箋のうち、戦略②（コアをエンジンから切り離す）はどのエンジンでも効くので最も強いと感じました。エンジン選定より、エンジンに依存しない資産の比率を設計で決めることのほうが、隣の芝生に頼らず済む方法です。戦略①（用途別に使い分ける）にも賛成ですが、軽量エンジンや自社 C++ にも、人材と保守という隠れコストがあることは勘定に入れておきたいところです。

タイトルの「赤字体質」はやや断定が強すぎます。元記事の数字は「全職種に約80席」という仮定に立っていて、席数を絞るだけでも影響は大きく縮みます。

確認できていないこと

  • 日本市場でのエンジン別の人材数、採用単価の実数
  • 1人あたり人件費（1,000万円）、為替（150円）、席数（80）、運用年数（3年）はすべて仮定
  • ビルド時間やパッケージサイズは公式フォーラムの個別報告に基づき、一般化できない

参照

🤖 【Gemini】 隣の芝生は本当に青いのか？──「Unityを選ぶ企業は赤字体質である」という言説への現実的視点

元記事（@roripika氏執筆）では、Unityを採用する商業開発の現場が抱える構造的リスクとして、以下の3点が鋭く指摘されています。

  1. 固定費の高騰: 全職種へのライセンス配布による損益分岐点（必要売上）の跳ね上がり
  2. 自動化の壁: CI/E2Eテスト環境におけるライセンス制約や並列実行の難しさ、インフラ維持のコスト
  3. 幻想の崩壊: インディーの成功体験を企業組織にそのままスライドさせた場合の生産性低下

では、これらの課題を目の当たりにしたとき、「じゃあUnreal Engine（UE）に乗り換えれば、すべてが上手くいくのか？」 という疑問が湧いてきます。

結論から言えば、そんなうまい話はありません。むしろ「隣の芝生は青く見える」の典型であり、安易にUEへ逃げ込もうものなら、Unity以上に致命的な罠にハマる可能性すらあります。本稿では、元記事の指摘を「認めるべきは認めつつ」、UEという巨大なエンジンを選択した場合に何が起きるのかという視点から、現実的な反論を展開します。

1. ライセンスと固定費：UEのロイヤリティは本当に「安上がり」か？

認めるべき点：シート固定費の構造的罠

元記事が指摘する「非エンジニアも含めた全職種へのProライセンス配布」が、開発初期から固定費として経営を圧迫するという点は紛れもない事実です。数十年規模のプロジェクトで、使っているかどうかも怪しいプランナーやQAにまで毎年数万円のシート代を払い続けるのは、確かに「赤字体質」への第一歩と言えます。

反論と現実：UEにおける「後払い（ロイヤリティ）」と採用コストの重み

では、UE（Unreal Engine）ならどうか？ UE自体は無料からダウンロードでき、ゲームの総売上（Gross Revenue）が100万ドルを超えるまではロイヤリティ（5%）が発生しないという、初期フェーズにおいては極めて魅力的なモデルを採用しています。

しかし、ここに企業開発特有の大きな落とし穴があります。

  • 大ヒット時の「5%」の重み: 仮にそのゲームが数億円〜数十億円規模のヒット作になった場合、エピックゲームズに持っていかれるロイヤリティは、Unityの年間ライセンス料とは比較にならないほどの莫大な金額になります。「固定費」ではなく「変動費（レベニューシェア）」であるため、売れれば売れるほど吸い取られる仕組みは、経営の観点では別の意味でリスクです。
  • 採用市場と教育コストの壁: 「エンジニアを集めやすいからUnity」という選定理由を元記事は批判していますが、ではUEで優秀な C++ / Blueprint エンジニアを十分な人数集められるでしょうか？ 日本のゲーム市場（特にモバイルや中規模タイトル）において、即戦力のUEエンジニアの母数はUnity層に比べて圧倒的に少ないのが現実です。学習コストや採用難易度を含めたトータルコストで考えると、決して「UEのほうが安上がり」とは言えません。

2. CI/E2E自動テスト：UEのほうが自動化しやすいという幻想

認めるべき点：Unityのテスト・ビルドの重さ

UnityでGitHub Actionsなどを用いたCI環境を構築しようとすると、Library フォルダのキャッシュ肥大化や、テスト並列実行時のライセンス縛りに苦しめられるのは事実です。

反論と現実：C++のビルド地獄とアセットの圧倒的な重さ

「じゃあUEで綺麗にCI/CDや自動テストを回せるのか」といえば、現実はもっとシビアです。

  • ビルド時間とアセットの規模: UEはC++ベースのエンジンであり、ソースコードの変更に伴うコンパイル時間はUnityのC#スクリプトの比ではありません。インクリメンタルビルドが効くとはいえ、大規模なプロジェクトになればクリーンビルドやシェーダーコンパイルに途方もない時間がかかります。
  • エディタの重量級ステート: UEのエディタやCook（ビルド用データクック）プロセスは、Unityのバッチモードよりもさらにリソースを食います。これをクラウド上のCI（Linux/Windowsランナー）で並列実行しようとすれば、AWSやGitHub Actionsのランナー代（従量課金）が、Unityのライセンス料を軽く凌駕するインフラコストとして跳ね返ってきます。
  • 自動テストの難易度: Blueprint主体の開発であれC++であれ、UE上で安定したE2Eテストを自動実行するインフラをメンテナンスするには、Unity以上に専門性の高い「テクニカルなインフラエンジニア」の常駐が必要になります。「ツールを変えれば自動化が楽になる」ということは決してありません。

3. 「リッチに早く作れる」の本当の正体：エンジン以前の問題

認めるべき点：要求水準のインフレ

「少人数でリッチに早く作れる」という触れ込みでプロジェクトを始めると、ツールの強力さに目が眩み、アセットストアの素材を並べただけの「グラフィックだけは豪華だが中身がスカスカ、または最適化不足で重いゲーム」になりがちです。

反論と現実：UEでそれをやると、もっと悲惨なことになる

この「要求水準のインフレ」と「リッチな表現への誘惑」は、Unity以上に Unreal Engine でこそ顕著に発生する現象 です。

  • UEは、デフォルトのレンダリングクオリティ（LumenやNaniteなど）が非常にリッチであるため、プロジェクトの初期段階から「フォトリアルで美しい画」が簡単に作れてしまいます。
  • その結果、プランナーやデザイナーの目が肥え、「もっとグラフィックをリッチに」「もっと物理挙動をリアルに」という要求が際限なく膨れ上がります。
  • その要求に応えようとした結果、モバイルやミドルスペックのPCではまともに動かない「最適化地獄」に陥り、開発チームはグラフィックのチューニングだけで数ヶ月を溶かすことになります。

Unityで起きる肥大化が「コードやアセットの管理の乱れ」だとすれば、UEで起きる肥大化は「リッチな機能のオーバースペック化によるプロジェクト全体の自壊」です。エンジンを変えても、チームの「身の丈に合った設計をする規律」がなければ、結末は同じか、より深刻なものになります。

まとめ：隣の芝生は青くない。選ぶべきは「自社の身の丈」

「Unityを選ぶ企業は赤字体質である」という批判は、技術の構造的リスクを突いた見事な指摘です。しかし、そこから「だからUE（あるいは他の軽量なエンジン）にすれば救われる」と考えるのは、単なる逃避にすぎません。

  • ライセンス費をケチれば採用難やロイヤリティの爆発に悩まされ、
  • 自動化を求めれば、より重厚なコンパイルとインフラコストに殴られ、
  • リッチさを求めれば、エンジンの性能に引っ張られて要求水準がさらにインフレする。

結局のところ、問題の本質は 「どのエンジンを選ぶか」ではなく、「そのエンジンのコスト構造とリスクを理解した上で、プロジェクトの規模やチームの能力に合わせたコントロールができているか」 に尽きます。

「うちのプロジェクトにはUnityは重すぎる、あるいは高すぎる」と感じてUEに逃げ込む前に、まずは自分たちの開発プロセス、メンバーのスキルセット、そして「作りたいゲームの規模」が本当に対象のエンジンに合っているのかを冷徹に見つめ直す必要があるのです。

🤖 【Claude】 Unityが重いのは事実。でも「Godotにすれば黒字」はそんなに甘くない

元記事：Unityを選ぶ企業は赤字体質である。（Qiita / @roripika）

はじめに

元記事は、ライセンス固定費・CI運用・採用とリッチ化の悪循環を「損益分岐点」という軸で整理していて、現場の疲弊に覚えのある人には刺さる内容だと思う。この記事の目的は元記事の否定ではない。認めるべきところは先に認めたうえで、元記事が代替案として挙げている 「じゃあ Godot にすれば上手くいくのか？」 という一点だけを検討したい。

先に結論を書いておく。Unityの痛みは本物。ただしGodotに移ればそれが消えるのではなく、請求書に載らない場所へ移る部分が大きい、というのが私の見立てだ。隣の芝生は青く見えるが、そんなにうまい話は無いのではないか、という話である。

料金などの数字は2026年11月時点で公開情報から確認したもので、人件費などの試算は私の仮置きである。

1. 元記事が正しいと思うところ

まず、同意できる点を整理する。

  • ライセンスは人数に比例する固定費である。 Unity Pro は2026年1月12日に5%値上げされ、年額2,310ドル／シートになった。元記事の「約34万円前後」は1ドル150円換算でほぼ整合する。80人全員に配れば約18.5万ドル、およそ2,800万円。「毎年数千万円規模」は誇張ではない。
  • 無料のPersonalが使えない企業では、CIも例外ではない。 Personalは売上・調達額が20万ドル以下の事業者向けで、それを超えるとProが必要になる。
  • ベンダーリスクは現実に起きた。 2023年のランタイムフィー騒動は2024年に撤回され、シート課金に戻ったが、エンジンの課金モデルを一社が一方的に変えうることは実証されてしまった。元記事のロックイン懸念は妥当だ。
  • 「リッチ化 → 人手不足 → 採用しやすいエンジン → さらにリッチ化」という循環 は、多くの現場で観察できるはずだ。
  • 戦略②（コアを純粋なC#に分離し、dotnet test で回す）は、エンジンを問わず有効。 元記事で一番実用的なのはここだと思う。全面的に同意する。

2. それでも「赤字体質」と言い切るのは苦しい

2-1. 規模感

仮に80人規模、1人あたりの年間総人件費を800万円とすると、人件費は年6.4億円。ライセンス約2,800万円はその 4%強 にあたる。無視できない額だが、「事業の体質」を決める大きさだろうか。赤字か黒字かを分けるのは、通常は売上の山の高さと、開発期間が生む人件費のほうだ。

2-2. 8割に配るのは運用の選択である

元記事は全職種にライセンスが配られる状況を問題にしているが、これはUnityの仕様ではなく社内運用の選択だ。実際、元記事自身が戦略②で「非エンジニアのライセンスを削減する」と書いている。つまり対策は "Unityをやめる" ではなく "席を絞る" で成立する。

2-3. CIの「台数分」問題はある程度緩和できる

Unityにはビルド機向けの Build Server ライセンス（ライセンスサーバーから必要時に払い出すフローティング方式）がある。「並列数だけProが必要」という書き方は、構成次第でかなり緩む。ただし、Web開発のように無料で何並列でも、には遠いのは元記事の言う通りだ。価格は販売元によって差があり、私は確定額まで確認できていない。

2-4. 因果の向き

「Unityを選んだから赤字になる」のか、「大型・マルチプラットフォームで赤字になりやすい案件だからUnityが選ばれる」のか。元記事の構造論だけでは区別できない。Unityで黒字を出している企業の存在も、この理屈では説明しにくい。

3. Godotにすれば、本当に楽になるのか

ここからが本題。元記事が挙げた痛みを、Godotに置き換えて順に見てみる。

3-1. シート課金：解消する（ここはGodotの勝ち）

GodotはMITライセンスで、シート課金もランタイム課金も無い。これは素直に大きな利点だ。

3-2. コンソール：お金は消えるが、手間は残る

Godot財団は、オープンソースのライセンス上の理由などから公式のコンソール移植を維持していない。Switch・Xbox Series・PS5は、W4 Gamesのミドルウェアか、第三者の移植サービスを使うことになる。W4 Consolesの公式ページには、中規模企業向けプランで1機種年4,000ドル、全機種で年1万ドルとある（対象条件あり）。Unityを80席入れるよりはるかに安いので、コスト面は認めるしかない。ただし、エンジンが移植されても「ゲーム側の移植作業」は自社に残る。

3-3. CI：ライセンスは消えるが、重さの正体は残る

ライセンス待ちが無くなるのは確かに楽だ。一方で、元記事が挙げた他の苦しみは構造的に残りやすい。

  • VLMによる画面チェックには、結局GPU（またはソフトウェアレンダリング）が要る。
  • iOSのビルドにmacOSの環境が要るのはUnityと同じ。
  • インポート結果のキャッシュ（Godotでは .godot 配下）の扱いは、Unityの Library ほど巨大にならないにせよ、ゼロにはならない。

3-4. C#資産を持ち込む道が、実は一番細い

元記事の戦略②は、純C#のコアを持っておけば「将来Godot C#へ移行できる」と述べている。ところがGodot公式ドキュメントでは、Godot 4のC#プロジェクトは Webにエクスポートできない。AndroidとiOSも4.2以降で対応したものの、ドキュメント上は experimental 扱いだ。W4 Consolesも、SwitchとXbox向けのC#サポートを「ベータ」としている。

つまり、純C#資産を持つ組織にとって理想の移行先であるはずのGodot C#は、モバイル・Web・コンソールのどれでも「完成」とは言い切れない。GDScriptに書き直せば解決するが、それは「Godot専用言語への新しいロックイン」だ。

3-5. エコシステムが小さい＝内製が増える

元記事の第3章は、商用開発ではアセットストアのショートカットが使えず内製に寄る、と指摘していた。Unityには、使わない選択をしてもなお、膨大なアセット・ミドルウェア・ノウハウ記事がある。Godotでは「使いたくても無い」が増える。つまり、元記事が嫌った「全部自前」は、エコシステムが小さいほど加速しやすい。ライセンス費が減る代わりに、一番高価な資源であるエンジニアの時間が増える。

3-6. OSSだから直せる、は直せる人がいるときだけ

エンジンの不具合を自分たちで直せるのはOSSの強みだ。ただし、エンジン本体（C++）を読んで直せる人材は、元記事が「減っている」と書いた人材そのものだ。Unityの採用難は、別の形で戻ってくる。

3-7. 3Dと大規模案件

Unityのほうが3Dレンダラーが成熟しているという評価が一般的で、コンソール公式対応も含め、大型3D案件はUnityの得意領域だ。すると、Godotで成立する案件は もともとUnityでも小さく作れた案件 なのでは、という疑いが出る。それなら効いているのは「Godotだから黒字」ではなく「小さく作るから黒字」だ。

3-8. 勢いは本物。ただし読み方に注意

Steam上のGodot製ゲームは、ある集計で618本（2023〜24年）→1,500本→2,864本（2025〜26年）とほぼ倍々で増えている。伸びは認める。ただし、これは個人や小規模チームが中心だと思われ、元記事の第3章が言う「個人開発と企業の商業開発は前提が違う」がそのまま当てはまる。

ここまでの整理

元記事の痛み Godotで 残るもの
シート課金 解消 なし
コンソール 費用は大幅減 ゲーム側の移植作業、ミドルウェア依存
CIライセンス 解消 GPU検証、macOS、キャッシュ管理
C#資産の移行 一部可能 Web不可、モバイルはexperimental、コンソールはベータ
アセット・内製 悪化しやすい 内製工数の増加
人材 別の形で再発 エンジン改修できる人の確保

4. コストは消えず、移動する

ライセンス料は請求書に載る。一方、内製工数・移植作業・学習コスト・ツール整備・採用難は、請求書には載らない。載らないコストは見えにくいので、乗り換え前の隣の芝生は青く見える。Unityに不満があるときほど、Godotの欠点は「まだ知らない問題」としてゼロ評価されがちだ。

振り返ると、元記事の冒頭にある「Unityにすれば開発期間が半分になるはず」という期待と、「Godotにすれば黒字になるはず」という期待は、構造がよく似ている。どちらも エンジンという一つの変数に、事業全体の結果を背負わせている。

5. Flashの比喩について

Flashとの類比は印象的だが、Flashの凋落は一般には、iPhoneが対応しなかったこと、セキュリティ問題、ブラウザ標準（HTML5）の成熟といった外部要因で語られることが多く、「リッチ化による肥大」が主因とは言いにくい。また、HTML5には「ブラウザ標準」という共通の受け皿があったが、ゲームエンジンにはそれに当たるものが無い。GodotもMITライセンスだが、エンジン固有のシーン形式やスクリプト言語を持つ点で、ロックインが無くなるわけではない。

ただし、一社が課金体系を変えうるリスク、という警告そのものは冒頭に書いたとおり正当だと思う。

6. 結論：エンジンを替えるより、替えられる構造に先に投資する

  • 「赤字体質」の要因は、エンジンの名前ではなく、スコープ管理・席数管理・コアの分離 の3つではないか。
  • エンジンを比較するなら、ライセンス費だけでなく、人件費・ツール内製工数・移植費・採用と教育を含めた総額を案件単位で 見る。
  • 試すなら、小さな2D案件でGodotを試し、撤退基準を先に決めておく。同時に、コアは純C#などポータブルな形に保つ。元記事の戦略②は、これを両立する一番強い手だと思う。

元記事は、現場が抱える問題を損益分岐点という共通言語に直した点に価値がある。そのうえで、Godotへの期待は「ライセンス料がゼロになる」ことの先まで見積もっておきたい、というのが本稿の主張である。

参考

🤖 【Gemini】 「Godotなら上手くいく」のか？：エンジン移行という隣の芝生と構造的コストの正体

「Unityを選ぶ企業は赤字体質である」というQiita記事に対し、Godotという選択肢を持ち出しつつ、「隣の芝生は青く見える」という冷徹な現実的視点から多角的に検証した反論（というか構造的批判の再評価）の記事構成です。

元記事である「Unityを選ぶ企業は赤字体質である」という指摘は、ビジネスモデル、開発フェーズ、組織の構造的負債の本質を突いており、単純な感情論で否定できるものではない。Runtime Fee騒動以降、「脱Unity」の受け皿としてGodot Engineに注目が集まったのも記憶に新しい。

しかし、「Unityの代わりにGodotを採用すれば、収益体質が改善し、開発がバラ色になるか」といえば、それは典型的な「隣の芝生は青く見える」現象に過ぎない。ゲームエンジンを変えたところで、組織の構造やビジネスモデルの歪みが自動的に解消されるわけではないからだ。

本稿では、元記事の指摘のうち「認めるべき事実」を受け入れた上で、Godotを軸にした移行論が孕む致命的な盲点と、真に持続可能なエンジニアリング選択の条件を検証する。

1. 元記事の主張における「認めるべき事実」

まず、元記事が指摘する「Unityを選ぶ企業が抱えがちな構造」の本質は、エンジンの優劣ではなく「開発速度（Time-to-Market）と技術的負債・収益化能力のトレードオフ」にある。

  • アセット依存による肥大化： Unity Asset Storeの強力なエコシステムに依存するあまり、自社でコアロジックをコントロールせず、プラグインのパッチワークでプロダクトを組み上げてしまう体質。結果として技術的負債が蓄積し、長期的な保守コストが跳ね上がる。
  • バーンレートの高さ： 高度な人材をアトラクトするためにUnityプロのエンジニアを大量採用し、多額のライセンス費用やアセットコストを固定費として抱えながら、肝心のマネタイズ（LTV > CACの確立）に失敗する構造。

これらはUnityというツールそのものの問題というより、「プロダクトの検証が不十分なまま、エコシステムの速度感に依存してアクセルを踏み続けた経営・開発体制」の表れである。ここを直視せず、単に「ツールを乗り換える」だけで解決しようとするアプローチは危険だ。

2. 「Godotなら上手くいく」という幻想（隣の芝生）

では、OSS（オープンソース）であり、ランタイム料金の懸念もないGodot Engineを採用すれば、こうした赤字体質から脱却できるのだろうか？ 結論から言えば、中・大規模な商業開発において、Godotへの移行は「別の種類のコストとリスク」を爆発的に増大させる。

① サポートとエコシステムの欠落（自前主義の罠）

Unityには、長年かけて蓄積された膨大なアセット、ドキュメント、トラブルシューティングの知見、そして何より有償のサードパーティ製SDK（広告、アナリティクス、プラットフォーム固有のAPIなど）が揃っている。
Godotも急速にエコシステムを拡大しているが、AAA級やミドルウェアを多用する商業タイトルにおいて、「必要なインテグレーションが公式/非公式で存在しない」という壁にぶつかる。結果として、エンジニアがドライバやコアの拡張、ブリッジコードを自前で実装・保守するコスト（人件費）が発生し、かえってバーンレートを高める要因になりかねない。

② 言語とパフォーマンスの制約（GDScript vs C# / C++）

Godotの標準言語であるGDScriptは非常にクリーンで迅速なプロトタイピングに向いているが、極限の最適化が求められるハイパフォーマンスな処理（メモリ管理の制御、複雑な計算、CPUバウンドなアルゴリズム）においては、C#やC++（GDNative / GDExtension）を持ち出す必要がある。
結局のところ、Unity（C# / IL2CPP / Burst Compiler）と同等レベルのパフォーマンスを引き出そうとすれば、要求されるエンジニアのスキルセットはUnity以上に尖ったものになり、「誰でも簡単に作れるからコストが下がる」という図式は崩壊する。

③ 「フリーソフトウェア」という名の隠れコスト

「ライセンス料が無料」という点は一見すると財務上の大きなメリットに見える。しかし、商用開発において真にコストを占めるのはライセンス料そのものではなく、「開発工数（人件費）」と「機会損失」である。
エンジン起因のバグ、プラットフォーム側の仕様変更（iOS/Androidや家庭用ゲーム機のアップデート）に対する追従、コミュニティ主導の開発ロードマップへの依存など、商用サポート契約（Unity Enterprise等）が存在しないOSS環境では、トラブル発生時のディザスターリカバリコストは企業自身が全額負担することになる。

3. 健全な体質を決めるのは「エンジン」ではなく「構造」

結局のところ、赤字体質になる企業の本質的な原因は、Unityを使っていることではなく、以下の構造にある。

  1. プロダクトマーケットフィット（PMF）未達のまま、開発リソースを過剰に投入していること
  2. アセットや外部機能に依存し、自社のコアコンピタンス（独自技術・アーキテクチャ）を定義できていないこと
  3. コストコントロールと技術選定の主導権が、経営戦略と乖離していること

Godotは、小規模チームによるインディーゲーム開発、2D/軽量3Dタイトル、あるいは技術的コントロールを完全に自社で握りたいプロフェッショナルな少数精鋭チームにおいては、圧倒的な武器となり得る。しかし、「Unityで赤字だからGodotにすれば黒字になる」という短絡的な思考で移行すれば、開発の遅延、人材採用の難航、エコシステムの壁に阻まれ、かえって赤字を加速させる結果（まさに隣の芝生の罠）に直面するだろう。

結論

ツール（エンジン）は、あくまでビジネスの目的に奉仕する手段に過ぎない。UnityであれGodotであれ、「自分たちが何を作り、どうやって持続的にマネタイズするか」というアーキテクチャの設計思想が欠落している限り、どの芝生に移動しても、やがて同じ乾燥地帯に行き着くことになる。

来源：Qiita · Unity 开发社区 · qiita.com

策划与编程教程实践#教程/实践#游戏编程#Unity#Unreal Engine#Godot