トヨタの独自3Dゲームエンジン「Fluorite」と技術スタック考察

はじめに

先日トヨタ自動車が、ベルギーで開催された世界最大級のオープンソースイベント「FOSDEM 2026」において、Flutterを基盤としたオープンソースの3Dゲームエンジン「Fluorite」を発表しました。

Fluorite
https://fluorite.game/

三度の飯よりもゲームエンジン好き、なんならゲームで遊ぶよりもゲームエンジンと戯れる方が楽しいとすら感じている筆者は、これまでUnityはもちろんのこと、Godot, Unreal Engine, MonoGame, Stride, さらにはFlashからRPGツクールに至るまで、ありとあらゆる「ゲームエンジン」を使い倒してきました。
もちろんこのトヨタ製ゲームエンジンFluoriteにも大注目であり、機会があればFluoriteを用いて何かゲームを開発してみたいと考えています。

Fluoriteは、C++、Filament、Dart（Flutter）という、パフォーマンスとUI開発の効率を極限まで両立させるための、非常に意図的で尖った技術スタックを採用しています。
先進的ではありますが、その技術スタックは強い組み込み要件を前提としたものであり、一般的なアプリケーションやプロダクト開発においては必ずしも最適解とは言えない部分もあると思われます。

この記事では、この選択がどのような前提条件のもとで合理的なのか、また組み込み系以外の領域においても同様の技術スタックを選ぶ必然性があるのかを整理します。

トヨタの選択は「組み込み系」という前提から来ている

Fluoriteの設計思想を理解するうえで重要なのは、「車載システムは強い組み込み系である」という前提です。車載HMIでは、起動時間が秒単位で厳しく制約され、フリーズやフレーム落ちは安全性の問題に直結します。また、OSやSoC、ドライバ構成は長期間固定され、最悪ケースの挙動まで含めて完全に制御できることが求められます。

このような条件下では、メモリ管理やスレッド制御、初期化順序を明示的に支配できるC++が中核に選ばれるのは自然な帰結です。FluoriteにおけるC++採用は、性能追求というよりも「決定論的に制御できること」を最優先した結果だと整理できます。

「ゲームエンジン」と呼ばれているが、本質は組み込み向け3D基盤

FluoriteはECS構造を持ち、リアルタイム3Dレンダリングを行うため、技術的定義としてはゲームエンジンと呼ぶことに問題はありません。しかし、その主目的はゲーム制作ではなく、車載HMIやデジタルコクピットのための3D表現基盤です。

この点を踏まえると、「なぜ独自にゲームエンジンを作ったのか」という問いへの答えは、「既存のゲームエンジンが組み込み要件に合わなかったから」に尽きます。

組み込み系以外では、この技術スタックを選ぶ必然性は薄い

一方で、組み込み系という強い制約が存在しない場合、Fluoriteと同様の技術スタックを採用する必然性はほとんどありません。

もちろん、Flutter（Dart）自体は強力なホットリロード機能や優れた宣言的UIを備えており、モダンな開発体験においては定評があります。しかし、ウェブ技術のエコシステムと比較した場合、別の側面が見えてきます。

WebGPUの登場により、ブラウザ上でも高度な3Dグラフィックスを扱えるようになった今、HTML/TypeScriptが持つ「圧倒的な人材層の厚さ」と「既存のウェブ資産との親和性」は無視できない強みです。
特定のプラットフォームに依存せず、あらゆる環境で即座にプレビュー・共有できるウェブの機動力は、開発初期の試行錯誤において依然として優位性があります。

.NETを中核にした二重構造という選択肢

ビジネスロジックを堅牢に保ちたい場合、.NET（C#）を中核に据える構成は非常に合理的です。複雑な処理、状態管理、ドメインロジックをC#側に集約し、その上に軽量なブラウザ層を載せることで、以下のようなメリットが得られます。

型安全で保守性の高いビジネスロジック
UI側はHTML + TypeScriptによるホットリロード重視の開発
複雑な処理はC#で実行し、結果をTypeScriptに返す役割分担

この二重構造は、ヘッドレスな自動テストとも非常に相性が良く、UIを介さずにロジック単体での検証が可能です。結果として、品質と開発速度を両立しやすくなります。

ECSは技術スタックではなく設計思想

Fluoriteの特徴としてECS（Entity-Component-System）が挙げられますが、ECSは特定の言語や技術スタックに依存するものではありません。これはあくまで設計思想であり、TypeScriptとC#の組み合わせでも十分に実現可能です。

つまり、「ECSを採用したいからC++や専用エンジンが必要」というわけではなく、設計次第でウェブ技術や.NETの世界観の中にも自然に取り込めます。

そもそもゲーム開発においてゲームエンジンは必要なのか？

ゲーム開発といえば、まずUnityやUnreal Engineのような「ゲームエンジン」を思い浮かべる時代になりました。しかし、本当にすべてのプロジェクトに巨大なゲームエンジンは必要なのでしょうか。

本稿では、「ゲームエンジンを使うことが前提になっていないか」という観点から、その必要性を改めて問い直します。

一社の合理性と、一般解は別である

近年、商用エンジンのライセンス方針変更は大きな議論を呼びました。価格体系や利用条件が変更されることで、企業は技術的な判断だけでなく、経営的なリスクまで考慮しなければならなくなります。

その結果、自社でエンジンを内製するという選択は、特定の企業にとっては合理的です。外部ベンダーの方針変更に振り回されないための防衛策として、自前の基盤を持つことは理解できます。

しかし、それはあくまで一社にとっての最適解です。もし他社がそのエンジンを利用すれば、依存先が変わるだけで、新たなロックイン構造に入る可能性があります。

ゲームエンジンとは、単なるライブラリではありません。レンダリング、アセット管理、ビルドシステム、スクリプト実行環境など、広範な機能を内包した巨大な抽象化レイヤーです。その内部思想や更新方針と長期的に付き合うことを意味します。

軽量なゲームに巨大エンジンは本当に必要か

現在では、軽量な3DゲームであればTypeScriptとThree.jsの組み合わせで十分に構築可能です。WebGPUの登場により、ブラウザ上でも高度なリアルタイムグラフィックスを扱えるようになりました。

メニュー画面や結果画面といったUI部分については、ウェブ技術で開発するのがほぼ最適解といってよい状況です。レイアウト、アニメーション、ホットリロード、レスポンシブ対応など、ウェブが長年積み上げてきた技術資産は極めて成熟しています。

小規模から中規模のプロジェクトであれば、巨大エンジンを導入しなくても十分に成立します。むしろ、エンジン特有の制約やビルド工程の複雑さを回避できる分、開発体験は軽量になります。

HTMLはブラウザ専用の技術ではない

ちなみに、HTMLはブラウザのためだけの技術ではありません。
ElectronやChromiumといった技術を用いれば、デスクトップアプリとして展開できます。また、各種WebView技術を利用すればモバイルアプリ化も可能です。

つまり、ウェブ技術は「ブラウザ内のもの」という枠をすでに超えています。UI表現の基盤としてのHTML/CSS/TypeScriptは、極めて汎用性の高い選択肢です。

規模が大きくなればエンジンは不可欠なのか

上記の話とは逆に、大規模プロジェクトもまた、特定のエンジンへの強い依存は慎重に考えるべきです。開発期間が長く、チーム規模が大きく、保守も長期にわたる場合、基盤の選択は経営的リスクと直結します。

巨大エンジンに深く依存すると、以下のような問題が生じます。

エンジン内部仕様の変更に振り回される
不具合の原因がブラックボックス内部に隠れる
不要な機能まで抱え込む構造になる
アップデートの可否が経営判断に影響する

実際、大規模なUnity開発では、パフォーマンスや設計上の理由から、エンジン標準機能を避け、独自実装へ置き換えていくケースが少なくありません。レンダリングパイプライン、DI構成、状態管理、ビルド工程など、多くの部分で「エンジンを使わない前提」の設計が行われます。

その結果、事実上「Unityの上で.NETアプリケーションを構築している」状態に近づきます。であれば、最初から.NETを基盤に構築した方が単純で透明性が高かったのではないか、という結論に至ることもあります。

大規模開発において重要なのは、単一の巨大基盤に依存することではなく、広いコミュニティで長期にわたり利用されている安定した技術スタックを、要件に応じて組み合わせることです。

表示はウェブ技術や低レベルグラフィックスAPI
ロジックは.NETや他の成熟したバックエンド技術
必要な部分だけを明示的に統合する

このような構成は、透明性が高く、置き換えも容易で、技術的主導権を保持しやすいという利点があります。

規模が大きいからこそ、ブラックボックスへの全面依存ではなく、分解可能で可換性のある技術選択が重要になります。

まとめ

トヨタのFluoriteは、組み込み系という厳しい制約条件のもとでは非常に合理的で、先進的な技術基盤であると思われます。しかしその合理性は、描画遅延や起動速度をマイクロ秒・ミリ秒単位で削ぎ落とす必要がある「車載デバイスへの極限の最適化」という明確なミッションに支えられています。

組み込み特有の厳しい制約が存在しない一般的なプロダクトにおいては、Flutterが提供する高度な一貫性よりも、Three.jsやWebGPUを中心としたウェブ技術の「オープンな汎用性」や、.NETによる「堅牢なビジネスロジックの管理」を組み合わせたアーキテクチャの方が、チーム組成や保守性の観点でバランスが良い選択となるケースも多いはずです。

脱Unityの流れは今後も静かに加速していくと思われますが「ゲームエンジン」という言葉に引きずられるのではなく、前提条件と目的に応じて技術スタックを選ぶことの重要性を、Fluoriteは逆説的に示していると言えます。