「Unreal Engine 6」はなぜオープンエコシステム構想を進めるのか？　創業者のTim Sweeney氏らにUEの未来を聞いた

　Unreal Engineの開発元であるEpic Gamesが，2026年6月16日から18日にかけて米国・シカゴで開催した独自イベント「Unreal Fest 2026」にて，Epic Gamesの創設者であり，Unreal Engine（以下，UE）のアーキテクトを務めるTim Sweeney氏と，UE開発チームの責任者（Engine development lead）を務めるMarcus Wassmer氏に，日本メディアとしては唯一の単独インタビューを行う機会を得た。

Marcus Wassmer氏（左，Executive Vice President，Development，Epic Games）とTim Sweeney氏（右，Founder，CEO，Epic Games）

　基調講演の「State of Unreal」で明らかになったUE6についての詳細は，すでに記事を掲載済みだが，執筆段階で不確かだった部分について，UEのキーパーソンに話を聞ける貴重な機会だった。

UE6が目指すクロスゲームワールド的な相互運用性

4Gamer：
　まずは，基調講演で語られた「Open Specification for Interoperability」，具体的には「UE6のオープンモジュール的構想」についてお聞きします。
　単なるクロスプラットフォームプレイだけではなく，ゲーム世界をまたいだ相互運用性は，日本で絶大な人気を誇る小説・アニメ「ソードアート・オンライン」シリーズを想起させます。
　この作品は，各ユーザーのキャラクターや関連するスキル資産を，別のゲーム世界へ持ち込める設定になっていました。今回のUE6のアーキテクチャに，それと同じ方向性を感じたのですが，間違っていますか。

Tim Sweeney（以下，Sweeney）氏：
　私は以前から「真のオープンメタバースは，ひとつの企業が独占・囲い込みをする技術の上には成り立たない」ということを主張してきました。
　これは，誰でも実装可能なオープン仕様を作る構想です。UEに実装される仕様の多くを，UE専用ではなく，他社エンジンや独自エンジンでも同じ仕様を実装できるようにする，という考え方をUE6へ導入しようとしているのです。

　分かりやすい例として，「Fortnite Cosmetics」（※キャラクターの見た目を変える装飾品）を挙げましょう。これはFortniteのコスメティックアセットをUnreal Engine側へ移し，それらを記述するための仕様を作る，というものです。
　その仕様には，少なくとも3Dモデル（Mesh），ボーン構造（Rig），各関節の重み値（Bone Weights），動きデータ（Motion，Animation）といった情報が含まれます。
　UE6では，特別な設定や追加プラグイン，開発者による独自のパイプライン構築を必要とせずに，そうしたアセットを他のゲームエンジンとの間で取り込み，持ち出せるようにします。
　別のエンジンが同じ仕様を実装すれば，Unreal Engine以外でもそのアセットを扱え，Assets Interop，つまりアセットの相互運用が可能になるのです。

ゲームに登場するアセット自体が，Verseコードを含むようになる「スマートアセット」。これにより，アセットがゲームエンジンやゲームの垣根を越える

スマートアセットの概念（筆者作成）

Marcus Wassmer（以下，Wassmer）氏：
　我々は，「Unity」やオープンソースエンジンの「Godot」にも，こうした技術を採用してほしいと考えています。今回の基調講演では，「MetaHuman」を他社製エンジンが無償で実装・統合できる，という趣旨の話もしました。

　さらにEpic Gamesは以前から，「Verse Compiler」を将来的にオープンソース化して無償提供すると述べてきました。これにより，他社製エンジンもVerseを採用できるようになります。
　現時点でVerseがそうなっていないのは，外部公開できるほど仕様が固まっていないからです。

　Verseを鍛え上げるために，Epic GamesはUEFNをVerse基軸で構築して運用テストを重ねており，その第2段階として，UE6への統合を進めると考えられる。

　すでにサウンド関連では，MP3のような音楽・メディア系の標準フォーマットが，エンジンの垣根を越えて利用されています。
　同様にゲームエンジン界隈にも，垣根を越えて運用されている高度な技術があります。「USD」や「glTF」がその例です。
　ゲームエンジンでこうした透過的な運用を実現するには，まだ足りない標準領域があるのではないか。我々はそう考えました。今後数年で，業界がそれらに合意し，互いに採用していけば，エンジン横断の相互運用が現実になると考えています。

USDも活用範囲を拡大しており，Pixar，Apple，NVIDIAが物理シミュレーション向けUSDの規格化に着手している

※USDとは，「Universal Scene Description」の略で，超大規模な3Dシーンを記述するための規格。Pixarが映画「ファインディング・ドリー」の制作時に開発した技術で，メタバース，ゲーム，映画などの業界で標準的に活用されている。
　glTFは，「GL Transmission Format」の略で，OpenGLやVulkanで名高い標準化団体のKhronos Groupが開発した規格だ。「3DCG業界のJPEG」と呼ばれており，3Dモデル表現の標準フォーマットといえる。

Sweeney氏：
　Chrome，Safari，FirefoxといったWebブラウザが，同じWeb標準に従って同じサーバーにアクセスできるように，ゲームエンジンも標準仕様の上で相互接続できる，という状態を目指しているのです。
　あくまでたとえ話ですが，Unreal Engineのブラウザ／クライアントがUnityサーバーに接続したり，別のプレイヤーはGodot Engineで同じUnityサーバーに接続する，といったイメージです。そうしたプレイヤー同士が，同じ世界で一緒に遊べるわけです。

　私はソードアート・オンラインという作品を存じ上げませんが，あなたが連想したことは間違っていませんよ。

AIを使ってUEを動かす技術について

4Gamer：
　基調講演で示された，AIがUnreal Editorを操作するデモについて質問します。用いるAIは「なんでもいい」とのことでしたが，とはいえ限度はあるのでしょうか。

　たとえば，COMPUTEX 2026で発表されたNVIDIAの「RTX Spark」搭載PCのように，大容量メモリでローカルLLMを動かし，Windowsアプリを制御する技術が発表されました。あれはローカルLLMにこだわったソリューションです。
　UE側のAI機能では，言語生成系AIについてどのような仕様を想定しているのでしょうか。

Sweeney氏：
　UEのAI連携は，基本的にAIとのやりとりがMCPを介して行われるので，この共通プロトコルに対応していれば，自然言語AIがローカルにあろうが，クラウド側にあろうが，UE側は問題にしません。

　MCPとは，「Model Context Protocol」の略で，AIがほかのアプリなどとデータをやりとりするための共通通信規格だ。RTX SparkのAIによるアプリ制御も，技術基盤は同じ。

Unreal EngineとAIの連携は，他のアプリと同様にMCP経由で行われる

UEは，AIモデルはなんでもよいというスタンスを取る。UEから見たAI連携の機能強化は，事実上，MCP Serverの強化に集約される

Sweeney氏：
　MCPはいわば「UEにツールセットを提供するサーバーのインタフェース」であり，Unreal EditorをAIから操作するための共通接続口です。どんなLLMを使うかをEpic側では決め打ちしない，という姿勢です。
　たとえばLLMではなく，ローカル環境において数GBのメモリで動作するSLM（Small Language Model，小規模言語モデル）でも構わないのです。

4Gamer：
　つまりNVIDIA RTX SparkもMCPベースですから，そこからUEを使えるわけですね。

Sweeney氏：
　MCPと話せる相手であれば，どんなAIとも組み合わせて使えます。

自然言語でUnreal Editorを操作するデモの様子

MegaLightsとハードウェアレイトレーシング

4Gamer：

Unreal Fest 2026では，現行UE5の最終版としてUE5.8が発表された

　「Unreal Engine 5.8」（以下，UE5.8）のMegaLightsについてもお聞きします。
　私の理解では，MegaLights機能は，G-buffer生成までを従来型のラスタライズで行い，その後のライティング，シェーディング，シャドウイングの各処理にハードウェアレイトレーシングを使うという，ハイブリッドレンダリング的なアプローチを採る直接光のライティング・シェーディング機能です。
　ということは，MegaLightsの利用にあたっては，ハードウェアレイトレーシング機能を搭載したプラットフォームが前提ということですよね。

Wassmer氏：
　正しい理解です。UEを使っていてMegaLightsが利用可能であれば，そこではハードウェアレイトレーシング機能が使われます。
　一方で，ソフトウェアレイトレーシングのフォールバック機能は搭載されていません。

　MegaLightsは，UE5.5で試験的に実装され，UE5.8で標準機能となった新しいライティング技術だ。
　シーン内に設置した膨大な数の動的光源を階層構造で管理し，着目するピクセルに最も影響しそうな光源をまず絞り込むことから始める。
　絞り込みの手がかりには，3D空間上の視点から見た対象ピクセルの位置や，光源の輝度などを用いる。視点や光源から遠ければ影響は少ないとみなすわけだ。
　対象の光源を絞り込んだら，そのピクセルから光源方向にレイを飛ばす。このとき，GPUのハードウェアレイトレーシング機能を活用する。

膨大な数の光源が設定されたシーンの例

それらの直接光ライティングやシェーディングは，ハードウェアレイトレーシングを活用したMegaLightsによって処理される

　視点から放たれたプライマリレイが3Dシーン内で最初に衝突する地点を求める手法に，ラスタライズ法を利用するので，いわゆるレイトレーシング＋ラスタライズによるハイブリッド手法になる（関連記事）。

Megalightsの仕組み（筆者作成）

　一方で，間接光の影響は無視する，直接光ライティング／シェーディング専用の技術である。直接光ライティング／シェーディングにハードウェアレイトレーシング機能が必須の時代が来たというのは，なんとも感慨深い。

Lumen LiteとLightmass

4Gamer：
　UE5では，リアルタイム間接光システム「Lumen」の実装が，大きなトピックとして注目を集めました（関連記事）。
　そして今回，UE5.8では，Lumenの軽量版「Lumen Lite」モードが発表されました。演算負荷がLumenの半分程度のようですね。

Wassmer氏：
　はい。Nintendo Switch 2での活用も想定した機能です。

4Gamer：
　その具体的な手法の説明がなかったので質問させてください。
　Lumen Liteでは，放射照度フィールド（Irradiance Fields）を活用するそうですが，この部分は事前計算するのですか。それともPlayStation 3〜4世代に流行したIrradiance Volume法のように，プローブ単位で事前計算するものですか。

　UE5で搭載されたLumenは，ハードウェアレイトレーシング――非対応の場合はソフトウェアレイトレーシング――を活用し，一度計算した間接照明情報をサーフェースキャッシュに落とし込むという，非常にユニークな技術であった。

サーフェースキャッシュの仕組み（筆者作成）

　1フレーム単位での計算量は微々たるものになるが，これを複数フレームに渡って計算（≒計算を時間方向に分散）し，その結果でフレームごとに，サーフェースキャッシュを更新していく。
　この方法では，瞬間的に安定した間接照明は得られず，時間方向に徐々に収束していくが，もともと間接照明は淡いものなので，それで良しとする手法だ。

Wassmer氏：
　Lumen Liteは，Lumenの軽量版という位置づけではありますが，別の見方をすると，Lumenの進化版，最適化版にも相当します。
　基本コンセプトはLumenと同じで，依然として事前計算が不要なアルゴリズムとなっており，完全に動的な大局照明技術である点も変わりません。
　ただし，時間方向に構築されていく「Acceleration Structures」（※Lumenのサーフェースキャッシュに相当するもの）は備えています。

　LumenとLumen Liteで何が違うのかといえば，品質面での妥協が大きい点です。つまりLumen Liteは軽量な分，間接照明の精度はLumenよりも劣るということです。

4Gamer：
　ということは，以前から存在するUEの軽量版間接光システム「Lightmass」を置き換えるものではないのですね。つまりLumen Liteも，空間方向と時間方向にリアルタイムに計算を分散させた動的な間接照明技術ということですね。

Wassmer氏：
　そうです。

Epic Gamesが発表したLumen Liteに関する情報の調査と追加取材を行ったところ，品質面に関して，いくつか追加で分かったことがある。

　公式情報によれば，UE5.8では，中品質の反射表現（Medium Quality Reflections）以下でLumen Liteが採用されるようだ。
　Lumen Lite採用時は，Lumen Reflectionsが無効化されるとのこと。一方で，滑らかな面には「Screen Space Reflections」（SSR，2.5D的な疑似映り込み）を適用し，粗い面（Rough Specular）にはLumen由来の成分を使うとの説明もあった。
　つまり，リアルタイムに生成される反射表現は，かなり疑似的なものになるということだ。
　また，Lumenと同じく，サーフェースキャッシュの仕組みは踏襲する。ただし間接光の精度が，ピクセル単位ではなく，離散的に配置されたプローブ単位となる。その分，処理負荷は50分の1〜100分の1程度に減る理屈だ。

　ざっくりいえば，Lumen Liteは映り込み的な鏡面反射効果は苦手だが，拡散反射主体の間接光については，Lumenにかなり近い効果が得られる。
　取材内容をもとにまとめたLumen Liteのパイプラインを示しておこう。

Lumen Liteのパイプライン概念図（筆者作成）

UE5.8の新機能「Mesh Terrain」とはなにか

4Gamer：
　UE5.8に追加された新機能「Mesh Terrain」について質問します。
　この機能は，ハイトマップ（Height Map）ではなく，3Dモデルでできた地形パーツを重ね合わせて立体的な地形を作れるもの，という理解でよろしいですか。

地形パーツ同士をCSG処理しながら編集，制作できるMesh Terrain機能

Wassmer氏：
　はい，そのとおりです。
　実際の3Dモデル（メッシュ）同士を交差・結合させることで地形を作れる機能です。また，CSG機能（後述）によって，他の3Dモデルから非破壊的に一部分を削ったり，くり抜いたりできます。

　これは，地面を上空からつまんだり押したりして造形する，ハイトマップ（Height Map）ベースの従来の地形システム（Landscape System）とは異なるものです。

4Gamer：
　三次元的なベクトルのハイトマップで変形させる，いわゆる3Dベクトルディスプレイスメントマッピング（3D Vector-Based Displacement Mapping）ではないのですね。

Sweeney氏：
　違います。Mesh Terrainは従来のLandscape Systemの改良ではなく，ハイトフィールドでもありません。あくまで実メッシュベースの地形システムという位置づけで理解してください。

　Mesh Terrainは，ランタイム時には通常の3Dモデル（メッシュ）として書き出されます。これに対し，バーチャルテクスチャ系の技術を適用できます。

Wassmer氏：
　このシステムはUnreal Editorのモデリングツール上に構築されており，その最大の特徴は，非破壊（Non-Destructive）な3Dモデル編集が可能なことです。

　たとえば，地形パーツを多層レイヤーで重ね，そこにテクスチャを貼り付けます。さらに，せり出した崖を加えたり，その下にトンネルを掘ったりもできます。
　その地形パーツの重ね合わせには，CSG（Constructive Solid Geometry，構成的立体幾何）機能も使えます。

　ここで言う非破壊とは，最終形状の情報だけが残るのではなく，元形状や加工手順，そのほかのパラメータが保持され，部分的な再編集や，やり直しができることを意味する。
　CSGは，たとえば大きな球体に小さな球体を重ね合わせて論理和を取ると，ひょうたん状の形状を表現できる機能のこと。論理差を取れば，小さな球体をかじり取ったような形状を，論理積を取れば，2つの球体が重なった部分の形状が得られる。

4Gamer：
　Mesh Terrainで作成した地形は，マイクロポリゴンシステムの「Nanite」でどう扱われるのですか。

Wassmer氏：
　Naniteで使っても，使わなくても，どちらでも構いません。たとえば，ハイエンドゲームプラットフォームでは，Nanite用地形データに出力し，スマートフォンなどでは通常の3D地形モデルとして出力してもいいでしょう。

ランタイム時にはソリッドな3Dモデルとして出力される

Mesh Terrainで制作した地形データは，Naniteのマイクロポリゴンレンダリングによる無段階LOD地形データとしても活用できるというデモ

　Naniteは，初めて実用化された新発想の連続LOD（≒無段階LOD）システムで，UE5の象徴的な機能のひとつだ。
　クラスタLODシステムの延長線上にある技術で，3Dモデルを構成するポリゴンを，Compute Shaderで実装したソフトウェアラスタライザによって1ピクセル単位まで分解し，1ピクセル未満となったポリゴンを破棄していくという並外れたアルゴリズムである。
　最終的にNVIDIAは，この技術の一部を，GeForce RTX 50シリーズにレイトレ用の支援技術としてハードウェア実装した。当初はさまざまな制限があったが，現在はその多くが緩和されている（関連記事）。

MetaHumanのオープンソース化とロイヤリティフリー化

4Gamer：
　MetaHumanの開発キットがMITライセンス化され，実質的に他社もMetaHuman関連技術をロイヤリティフリーで利用できるようになりました。

　Epic Gamesは2026年2月に，ボーン駆動を用用いず，イメージベースでノンスケルタルな方式によりMetaHumanの3D人体モデルをアニメーションさせられる「Meshcapade」の技術を買収しましたね。
　Meshcapadeは，AI推論技術も組み合わせることで，これまで難しかった体内の筋肉の動きや，姿勢によって生じる肉のたるみ・しわまで再現する優れた技術です。この技術も，MetaHuman開発キットとともに他社製エンジンで使えるのですか。


Sweeney氏：
　現状のMeshcapadeは，Unreal用プラグインのみです。主な機能は，動画やWebカメラ映像からモーションを抽出することです。その抽出結果から人体アニメーションを生成できるわけですが，このモーション抽出処理は，現時点ではUE内のみで実行できます。

ボーンの埋め込みなしで，AI推論によって人体モデルを動かすMeshcapadeは，現状UE専用機能となる

4Gamer：
　つまり，オープンソース化される開発キットには，Meshcapadeまでは含まれないということですね。

Wassmer氏：
　UE環境上で抽出したアニメーションデータをエクスポートすれば，自由に使ってもらって構わないというスタンスです。

スマートアセットの考え方を業界はどう受け止めるのか

　Sweeney氏とWassmer氏へのインタビューは以上のとおりだ。
　基調講演での発表から，UE6以降のEpic Gamesは，UEへのユーザーの囲い込みだけに注力するのではなく，オープン仕様や標準化，他社製エンジンでの実装可能性を，かなり強く打ち出していることが分かった。

　Fortnite CosmeticsやMetaHuman，Verse，USDにglTF，そして将来追加する標準化技術などを通じて，UnityやGodot，そのほか各社のゲームエンジンが，UE6の動きに同調していくのかが注目される。

　AIに関してもモデル非依存の方針を打ち出しているが，現時点では，UE6の中核にまでAIが入り込むには至っていない。あくまでMCPを共通プロトコルとして使い，Claude Code，Codex，Gemini，ローカルLLM，RTX Spark上のモデルなど，MCP対応であれば何でも接続できる，という姿勢を示すにとどまった。
　これは，AIの進化が速すぎるため，UE6コアへの組み込みは時期尚早という判断で，あえて今は見送ったという見方もできるだろう。

　余談だが，「UE6専用のパストレーサーの予告や発表はないのか」とSweeney氏らに質問したところ，「今は何かを話せる段階ではない」という答えだった。
　UE5発表時におけるNaniteやLumenの衝撃が大きかっただけに，パストレーシングへの言及がまったくないのは，少々意外ではある。
　そのあたりは当面，NVIDIA独自のカスタム版UEである「NvRTX」に任せる，ということなのかもしれない。