【脱Unity】Unity歴10年の筆者が敢えて問う、これからのゲーム開発

前書き

Unityのことは大好きです！
以下はUnity批判記事ではありません。

まだ業務アプリの3D実装で「消耗」していませんか？

「デスクトップアプリで3Dを扱いたい」と考えたとき、多くの開発者が脊髄反射的にUnityを選択します。しかし、それは本当に「最適解」なのでしょうか。

かつては盤石に見えたUnityでの開発ですが、現在は無視できない大きな課題が立ちはだかっています。

ライセンス体系の不透明さと不信感

2023年、Unityが発表した「Runtime Fee（インストール数に応じた手数料）」の導入騒動は、全世界の開発者に衝撃を与えました。後に撤回や修正が行われたものの、プラットフォーム側の都合でビジネスモデルが突然書き換えられるという「ベンダーロックインのリスク」が浮き彫りになりました。

巨大すぎるランタイム

単純な3D表示をしたいだけでも、Unityはゲームエンジンとしてのフル機能を同梱します。結果として、配布バイナリは数百MBを超え、起動速度やメモリ消費がビジネスアプリとしては許容できないレベルまで膨れ上がります。

業務UI構築の「苦行」

Unity UI（uGUIやUI Toolkit）はあくまでゲーム用です。大量の入力フォーム、複雑なデータテーブル、アクセシビリティ対応など、Web技術なら数行で書ける「当たり前のUI」を構築するのに、気が遠くなるような時間と工数を要します。

AI時代との相性の悪さ

これが最も現代的な課題です。LLM（大規模言語モデル）やAIエージェントを活用したアプリでは、ストリーミングテキストの表示、Markdownのレンダリング、柔軟なレイアウト変更が求められます。しかし、Unityという「あらかじめビルドされたブラックボックス」の中でこれらを動かすのは極めて困難です。また、AIを「Headless（画面なし）」で動作させてバックエンドで処理を回したい場合、重厚なUnityエンジンはその足かせにしかなりません。

じゃあどうする？

そのような自問自答から、筆者はここ数年、Unityに依存しない3D業務アプリの開発手法を模索する長い長い旅を続けてきました。
本レポートでは、その旅路の経過報告として、ポストUnity時代の開発環境を提案します。

そして、これは単なる技術的な試行錯誤の結果ではなく、不要な思想を削ぎ落とした末に辿り着いた、ひとつの「解脱」の記録です。

なぜ単純に.NET移行するだけでは足りないのか？

素朴に考えれば、なんとも不自然な話です。
Unityを一番楽に脱却するのであれば、共通言語であるC#が活かせる.NETを使えばいい、ただそれだけではないの？という疑問を持たれる方も多いでしょう。
正直、私も最初はそんな楽観論を抱いていました。そして、.NETを使うということは基本的には正しい。
ですが、.NETには決定版の3D描画ライブラリが存在しないという極めて深刻な問題があります。
そこで我々は、.NETで使用可能な3D描画ライブラリを自らの手で探し当てなければならないのです。

結論 : Three.jsが最強

まず、最終奥義からいきなりお伝えしてしまいましょう。
UnityおよびUnreal Engineを除くと、多数の実務案件で採用されてきた実績を持つ3D描画ライブラリは、Three.jsただひとつしかない、という冷酷な事実を受け入れることから始めねばなりません。
すくなくともコミュニティーの人数で言えば、Three.jsは他を遥かに凌駕しています。後述するGodotなどの勢力も一定数伸びてはいますが、業務での使用に耐えうるとなると、Three.jsしか残りません。

ですから、我々がUnityを捨てるということは、まずはThree.jsとの向き合い方を考えることなのです。

じゃあもうTypeScriptでいいの？

だだし、この記事で伝えたいことは、Unityを捨てるついでにコアロジック層までC#を捨てて、TypeScriptに完全移行してしまおうという単純な話ではありません。
とはいえ、先に言っておくと、開発内容によってはTypeScriptで3Dアプリを作り切ることは完全に現実的な話です。
TypeScriptはウェブだけのものという認識は完全な思い込みであり、実際にはElectronというフレームワークを使えば、TypeScriptで開発した製品を完全にスマホやパソコンのアプリとして書き出すことができます。
もし、あなたの作りたいアプリの機能の9割が3D描画やUI操作であり、特殊なハードウェア制御や、既存のC#資産の活用が必要ないなら、Electronの方が圧倒的に「楽」です。
実際筆者も、この手法でいくつものアプリを開発しています。

そして、今からゲームを開発したいという人達にも強く伝えたい。
「TypeScript + Three.jsでも普通にカジュアルゲーム作れますよ」と。
むしろその方がプレイアブル広告にもそのまま流用できるかも知れないので、正解なくらいです。

改めて.NETの強みを確認する

一方で、.NETにはこれまで数多くの堅牢な業務アプリの開発に耐えてきた長い歴史があります。ExcelやPDFといったデータの取り扱いもC#の大得意分野であり、JS/TSは太刀打ちできません。
そして何よりも、「コンピュータの資源（CPU/メモリ/ハードウェア）を限界まで使い倒す、泥臭くて重い処理」において、.NETはJS/TSに圧勝します。具体的には以下の4つの領域です。

1. 「真のマルチスレッド」による重い計算

JavaScript（Node.js/ブラウザ）は、基本的に「1つのスレッド」で動くシングルスレッドの王様です。対してC#は、CPUの全コアをフル動員する「並列処理」のプロです。

C#の強み: Parallel.For や Task を使えば、数百万個の頂点計算や、複雑な物理シミュレーション、大量の画像処理を、8コアや16コアのCPUで同時にぶん回せます。
JSの限界: Web Workerなどで擬似的に分けられますが、データの受け渡し（コピー）にコストがかかり、C#のような「共有メモリによる超高速な連携」は不可能です。

2. ハードウェア・センサーとの「直接対話」

もしアプリが3Dだけでなく、外部機器と繋がるならC#一択です。

PLC・シリアル通信: 工場のライン制御や計測機器とのRS-232C通信。
特殊なUSBデバイス: 独自のカメラ、医療機器、センサー。
OSの深部: Windowsのレジストリ、ファイルシステムの低レベル監視、Active Directoryによる社内認証。これらはNode.jsでも「アドオン」を使えば不可能ではありませんが、.NETなら標準ライブラリ（BCL）や、メーカー公式の.NET用SDKで安定して動かせます。

3. メモリ管理の「精密な制御」

3Dアプリで最も怖いのは、突然のカクつきです。

JSのGC: ブラウザのガベージコレクションは「いつ、どれだけ止まるか」を開発者が制御できません。
C#の最新機能: .NET 9/10 世代では、Span<T> や Memory<T>、あるいは「Native AOT（事前コンパイル）」により、「メモリを一切汚さずに計算し続ける」コードが書けます。これにより、毎秒60フレームを1ミリも落とさない極限の安定性を追求できます。

もちろん、JS側にデータを渡した後に new THREE.Vector3() などを毎フレーム数万回実行してしまえば、JSのGCによって台無しになります。しかし、ロジックをC#に閉じ込め、JS側を『単なるバイナリの受け皿』に徹させることで、このリスクを実用上の限界まで封じ込めることができます。

4. 巨大で複雑な「型」の迷宮を支える

3D空間のロジックは、ベクトル、行列、四元数、当たり判定……と、凄まじい数の「型」と「数学」の塊です。

C#の型システム: 2026年現在のC#は、TypeScriptよりも厳格で、かつ「Generic Math（静的抽象メンバー）」などの機能により、数学的なロジックを極めて美しく、かつ高速に記述できます。数万行に及ぶ物理エンジンを保守するなら、C#の方が圧倒的にバグを抑え込めます。

.NET + Three.jsという選択肢について

以上を踏まえると、「コアロジックはC#で堅牢さと安定性を追求したい、でも3Dを描画したい」というニーズが必ず発生することがお分かり頂けるでしょう。

そこで筆者は、3D描画は最高にモダンなThree.jsで作り、コアロジックでは鉄壁のC#ライブラリを使って、複雑なデータ処理を行う開発方法としての.NET + Three.jsを提案しています。

C#側で巨大なデータから必要な部分をリアルタイムで高速に抽出し、最後に整形済みの3DメッシュデータだけをTS側のThree.jsに送り込む、というような使い方です。

この構成が「正解」である理由

圧倒的な情報量とアセット: .NETのどの3Dライブラリよりも、Three.jsの方がサンプルコード、ライブラリ、3Dモデルのインポーター（glTF等）が充実しています。
学習コストの低さ: シェーダーや行列計算を自前で書かなくても、数行のJavaScriptで美しい描画が手に入ります。
UIとの親和性: 3Dの上に重ねるボタンやメニューを、HTML/CSSでリッチに作れます。これはStrideやSilk.NETで苦労するポイントです。

Three.jsと.NETを繋ぎ合わせるための工夫

コアロジックをC#でどれだけこだわり極限のレスポンスを実現しても、最終的な描画を「JavaScriptのガベージコレクション」や「ブラウザのメインスレッド」に委ねた瞬間、そこがボトルネックになります。

しかし、2026年現在の技術スタックでは、この「台無し」を防ぐための「防衛策」がいくつか確立されています。

1. 「描画」と「計算」の分離（データの転送コスト）

最大の懸念は、C#で計算した大量のデータをJS側に渡す際のオーバーヘッドです。

NGな方法: 毎フレーム数万個の座標を JSON.stringify してシリアライズする。これではJS側のパース処理でGCが暴れ、画面がカクつきます。
2026年の正攻法: Shared Array Buffer や Direct Memory Access に近い手法を使います。WebView2では、C#側の共有メモリをJSの TypedArray (Float32Arrayなど) として直接参照させる（またはバイナリで流し込む）ことで、コピーコストを最小化し、JS側のメモリ管理をバイパスできます。

2. Three.js を「ただの薄いラッパー」にする

JS側に「ロジック」を持たせないことが鉄則です。

JSの仕事: 届いたバイナリデータを頂点バッファ（GPU）に叩き込むだけ。
C#の仕事: 全ての物理演算、アニメーションの補間計算。このように、JS側を「何も考えない土方（レンダラー）」に徹させることで、JS特有の「気まぐれな遅延」の影響を最小限に抑え込めます。

3. WebGPU の活用

2026年現在、Three.jsは WebGPU への移行が完了しています。

従来のWebGLよりもGPUをダイレクトに叩けるため、CPU（JS側）の介入が減り、ドライバ層でのオーバーヘッドが激減しました。これにより、「JSだから遅い」という常識が、描画に限っては過去のものになりつつあります。

Three.jsが通用しなくなる境界線はどこか？

以上を踏まえると、3Dが絡むほとんどの案件は、TypeScript + Three.jsもしくは.NET + Three.jsで開発が可能と言うことができそうです。
それでも、以下のケースでは「やっぱりC#ネイティブ（StrideやSilk.NET）で書くべきだった」と後悔することになります。

数千万ポリゴンの超巨大CADデータ: ブラウザのメモリ制限（通常4GB程度）に引っかかります。
マイクロ秒単位の同期: VRのように、頭の動きと描画が1ミリ秒でもずれると酔うような超低遅延が求められる場合。

前者に関しては、C++でフルスクラッチ開発が可能な変態的な数学・GPU知識を持つプロに素直に依頼しましょう。
後者のVRは…これは今後もUnityもしくはUEに依存しましょう。正直VRをゲームエンジン以外で開発されている現場と出会ったことがありません。

極薄の接続：Photinoがもたらす疎結合

余談ではありますが、Unityを卒業することで得られるもう一つの利点として「UI開発がめちゃくちゃ簡単になる」と言うことが挙げられます。

.NETと言えばMAUIが主流であり、もちろんこれもUnityのUGUIと比較すれば遥かに効率的にUIを開発することができるのですが、忘れてはならないのが.NETではHTML/CSSでさえもUI開発が可能であると言うことです。
どれだけ低く見積もってもUGUIおよびMAUIの総人口の100倍以上はいるであろうウェブデザイナーさんたちの知見をフルに活用できることになります。

.NETでウェブ技術を使用する際にはBlazor Hybridが主流ですが、どうしてもビュー駆動な書き方になり、筆者の設計思想には合わないことが多々ありました。
そこで最近では、.NETとウェブの繋ぎ役には、Photino.NET を試験的に採用しています。 Blazor Hybridのようにフレームワークの思想を押し付けてこない「薄さ」が、このアーキテクチャの良さです。
ウェブ側はただの表示役として独立させ、.NETはイベント駆動で指示を出すだけ。この疎結合な設計が、将来の「技術の入れ替え」を容易にします。

以上が、筆者の現時点での脱Unityのためにたどり着いた現実回です。
ここからは、この構成に辿り着くまでの紆余曲折の中で最終的に選ばれなかった技術を列挙していきます。

その他の脱Unity案① Godot

筆者が最初に白羽の矢を立てたのはGodotでした。しかし結論として、Godotは私の理想とするUnityの代替ではありませんでした。

.uid ファイルの厄介な点

正直、今回の検証にあたり最も幻滅したのは、.uidファイルの存在でした。あの忌まわしいUnityの .meta ファイルから逃れたくてGodotを触り始めたつもりが今度は.uidファイルがベタベタと張り付いてきます。
これはもう気分の問題と言えばそれまでなのですが、でも…生理的に無理でした。Godotファンの皆さん申し訳ありません。

UI構築のハードルの高さ

これも、Godotファンの皆さんには大変申し訳ないのですが、私はここで挫折してしまいました。UnityのUGUIですら相当難解で覚えるのに苦労したのですが、ここでまた同じような独自仕様を時間をかけて覚える労力に見合うメリットを見つけることができませんでした。

代替案② .NET+Stride 3D

.NET開発者にとって、C#で書けるオープンソースエンジン Stride 3D は希望の星でした。しかし、実務レベルの検証で突きつけられた現実は、あまりにも厳しいものでした。

macOSおよびiOS対応という高い壁

Strideの描画基盤はDirectXへの依存が強く、macOSとiOSに用いられるMetalへの安定した対応は、現時点では「不可能に近い」という結論に至りました。マルチプラットフォームが当たり前の現代において、Windowsという檻に閉じ込められることは、技術選定として致命的です。

Blendshape表情が使えないという「実務上の致命傷」

モダン3D表現を語る上で欠かせないのが、Blendshape（モーフターゲット） です。 Unity歴10年の経験から断言しますが、現在のインタラクティブアプリにおいて、表情や口パク（リップシンク）を実現するこの機能は「あれば嬉しい」レベルではなく「必須」です。

私が実際にStrideでの実装を試みた際、このBlendshapeがサポートされていないという壁に突き当たりました。これは、会話キャラクターやAIエージェント、感情を伴うアバター表現が根本的に不可能であることを意味します。

「シェーダーを自前で書けばなんとかなる」という次元の話ではありません。エンジンがコアレベルで対応していないことは、エンジニアにとって「自分でエンジンを作り直す」か「プロジェクトを諦めるか」の二択を迫られることを意味します。この「実務で踏み抜いた地雷」こそが、私がStrideを諦め、Three.jsへの移行を決意した最大のトリガーでした。

とは言え、いまだに決定版を欠いているC#の3Dライブラリの中では、安定した更新が現在も継続しており、最も信頼できる存在と言えそうです。
上記のような、Blendshapeなどの細々とした問題が気にならなければ、コアロジックと3DをC#で完結できる貴重な存在です。

結論：私たちはUnityから「卒業」できる

以上を踏まえ、筆者の現時点での最終構成は下記のようになりました。

計算: .NET
表現: Three.js (TypeScript)
接続: Photino.NET

この構成は、Unityという巨大なブラックボックスに振り回される日々に終止符を打ちます。
ただし、「Unityアンチ記事」ではないということはご理解ください。
「業務アプリにUnityは過剰では？」という提案です。

もちろん、この構成が唯一の正解ではありません。
上述の通り、そもそもElectronでフルTypeScriptでも構わないのです。
また、Photino.NETなどという変化球ではなく素直にBlazor Hybridを用いてもいいでしょう。
そして、本記事ではあまり触れませんでしたが、Windows製品前提で普通に3Dオブジェクトを書くだけならば、StrideでC#で完結させるというのも全然アリです。Strideが今よりも進化したら、その用途はさらに広がるでしょう。

何よりも重要なのは、ひとつの巨大なものにロックインせず、TypeScript, Three.js, .NET, Stride…これらの武器を案件に応じて使い分ける、その自由度です！

「ゲーム」を作りたいのではない、「3Dを活用した強靭なアプリケーション」を作りたい。そう願うすべての.NET開発者にとって、この 「引き算のアーキテクチャ」 が、消耗戦から抜け出すための手助けとなれば幸いです。

もし同じように「Unity以外で3Dアプリを作れないか」と考えている方がいれば、ぜひ弊社にお気軽にご連絡ください。全力でサポート致します。