Microsoftは2026年10月21日、Unreal Engine(UE)5.8.4で、シェーダーの事前コンパイル技術「Advanced Shader Delivery(ASD)」をゲームの制作工程に組み込めるようになったと発表した。Epic GamesのUE 5.8.4リリースノートにも、ゲームのビルドからASD向けデータを生成する機能と、ローカル環境でコンパイルや登録を試すためのツールが追加されたことが記載されている。ASDは、GPUごとに事前コンパイルしたシェーダー関連データをゲームとともに配信し、プレイヤーのPCで発生するコンパイル処理の負担を軽減する仕組みだ。今回の対応によって、開発者はゲームを実行せずに配信用データを生成できるようになるが、必要な描画処理をすべて網羅できるわけではない。実際の効果を得るには、データの収録範囲と、ゲーム実行時の準備状況を確認する必要がある。
ゲームのビルドから配信用データを生成する「ASDTool」
UEに追加された「ASDTool」は、ゲームのビルドからASD向けデータを生成する独立したコマンドラインツールだ。対象プラットフォーム向けに変換・最適化されたゲームのビルドを使用するため、Unreal Editorを起動したり、ゲームを実行したりする必要はない。Microsoftの10月21日付発表では、UE 5.8.4でASD向けデータを制作工程に組み込めるようになったことが明記されている。Epic Gamesのリリースノートでも、データ生成機能に加え、ローカルでのコンパイルと登録を検証するツールの追加が確認できる。
シェーダーはGPUが実行するプログラムで、PSO(Pipeline State Object)はシェーダーと描画・計算処理に必要な設定をまとめたものだ。ASDToolが生成する「SODB(State Object Database)」には、シェーダーやPSOなどを再構築するための情報が、GPUに依存しない形式で保存される。ゲームの配信ストアは、このSODBをGPUの種類やドライバーに応じてコンパイルし、「PSDB(Precompiled Shader Database)」を作成する。その後、プレイヤーのPC環境に適したPSDBを配信することで、従来は各PCで行っていたコンパイル処理の一部を事前に済ませられる。開発者が共通のデータを用意し、ストアがGPUごとのコンパイルと配信を担う仕組みだ。
ただし、ASDを導入しても、ゲーム実行時にPSOを作成する処理そのものがなくなるわけではない。ゲームがPSOを作成する際、対応するデータがPSDBに含まれていれば、ドライバーは事前コンパイル済みのデータを読み込む。一方、PSDBに存在しないPSOについては、従来どおりコンパイルが必要になる。つまり、SODBの生成に成功したとしても、ゲームで必要なPSOが十分に収録されていなければ、コンパイルに伴うカクつきが残る可能性がある。
導入にはいくつかの前提条件もある。Epic Gamesが公開したASDToolの利用手順によると、ASDToolはコンパイル済みの実行ファイルとして配布されておらず、開発者がUnreal Engineのソースコードからビルドする必要がある。対象となるのは、Windows向けDirect3D 12(D3D12)のShader Model 6を使用したビルド(PCD3D_SM6)だ。また、シェーダーのアーカイブを生成するため、シェーダーコードの共有機能を有効にしておく必要がある。この機能は既定で有効だが、プロジェクトの設定で無効化している場合は変更しなければならない。
Microsoftは、SODBを生成する方法として、開発工程に組み込む自動生成方式と、実際にゲームを動かして収録する手動方式を案内している。自動生成は、新規開発や開発初期のゲームで継続的に利用する方法として推奨されている。一方、手動収録は、すでに発売されたゲームや開発終盤の作品など、エンジンの変更に多くの工数をかけにくい場合に適している。UE 5.8.4のASDToolは、ゲームのビルドに合わせてデータを繰り返し生成する工程を導入しやすくするものだが、実際にどれほど開発工数を削減できるかについて、具体的な測定結果は示されていない。
計算用シェーダーは一括収録、描画用PSOは既存キャッシュに依存
ASDToolが収録できるデータには、計算用シェーダーとグラフィックス用PSOで違いがある。Shader Model 6に対応する計算用シェーダーは、ゲームのシェーダーアーカイブから一括して収録できる。一方、グラフィックス用PSOは、開発時に用意された既存のPSOキャッシュから取り込む必要がある。同じツールで生成できても、収録できる範囲を決める条件が異なる点が重要だ。
Epic Gamesの公式ドキュメントによると、ASDToolで利用できる主な収録方法は次のとおりだ。
| 対象 | 収録方法 | 収録範囲と制約 |
|---|---|---|
| SM6計算用シェーダー | -AllCompute |
シェーダーアーカイブに含まれる対象を一括収録する |
| グラフィックス用・計算用PSO | -BundleDir |
既存のPSOキャッシュから収録する。グラフィックス用PSOはこの方法でのみ取り込める |
| レイトレーシング用PSO | 非対応 | 現時点ではASDToolの収録対象外 |
-AllComputeと-BundleDirは併用でき、その場合は両方の収録元に含まれる計算用シェーダーの重複が除去される。これにより、アーカイブに含まれる計算用シェーダーをまとめて取り込みながら、既存キャッシュに記録されたグラフィックス用PSOも一つのSODBに収録できる。ただし、グラフィックス用PSOの収録範囲は、元となるPSOキャッシュの内容によって決まるため、キャッシュに記録されていない描画処理まで自動的に追加されるわけではない。
したがって、計算用シェーダーを一括で収録できることと、ゲーム内で必要となる描画用PSOを網羅できることは別の問題だ。グラフィックス用PSOについては、従来と同様に、さまざまな場面や描画設定で必要になるPSOがキャッシュに含まれているかを確認する必要がある。ゲームを実行せずにSODBを生成できるようになっても、PSOの収集や収録範囲の検証が不要になるわけではない。また、必要なPSOが配信用データに含まれていても、ゲームがそのPSOを使用する時点までに準備が整っていなければ、カクつきが発生する可能性は残る。
ASDだけでは防げないカクつき、PSOプリキャッシュとの併用が必要
Epic Gamesは、ASDを導入したゲームでも、従来のPSOプリキャッシュを引き続き有効にすることを推奨している。PSOプリキャッシュは、ゲーム内で必要になるPSOを事前に収集し、実際に使用する前に非同期で準備するUnreal Engineの仕組みだ。ASDは、このプリキャッシュやゲームに同梱するPSOキャッシュを置き換えるものではなく、事前コンパイル済みのデータを配信することで補完する役割を持つ。PSDBに含まれないPSOについては従来どおりコンパイルが必要になるため、プリキャッシュを継続することで、ASDの収録対象から漏れたPSOによるカクつきにも対処できる。
また、PSDBに必要なデータが含まれていても、読み込みによる遅延が完全になくなるとは限らない。事前コンパイル済みのシェーダーであっても、ディスクからデータを読み込む処理は必要であり、そのタイミングによっては小さなカクつきが生じる可能性がある。PSOプリキャッシュには、こうした読み込みや準備を、実際の描画で必要になる前に済ませる役割もある。つまり、ASDがGPU向けのコンパイル処理を事前に済ませ、PSOプリキャッシュがゲーム実行時の使用タイミングに備えるという分担になる。
このため、ASDの効果を検証する際には、PSDBのヒット率とPSOプリキャッシュの準備状況を別々に確認する必要がある。PSDBのヒット率が高くても、必要なPSOの準備が描画時点に間に合わなければ、プレイ中のカクつきは残り得る。一方、ヒット率が低ければ、必要なPSOがSODBに収録されていないか、PSDBが正しく登録・照合されていない可能性を調べる必要がある。問題がデータの収録段階にあるのか、配信・照合にあるのか、それとも実行時の準備にあるのかを切り分けることが重要だ。
Epic GamesのASD生成手順、Microsoftの実装ガイド、Unreal EngineのPSOプリキャッシュに関する公式ドキュメントを基に、主な確認項目を整理すると次のようになる。
| 観測した状態 | 確認する領域 | 主な確認項目 |
|---|---|---|
| PSDBのヒット率が低い | ASDの収録・配信 | 必要なPSOの収録範囲。特にグラフィックス用PSOの取り込み元となるキャッシュ |
| PSDBのヒット率がゼロ | ASDの照合・登録 | 実行ファイル名、ゲーム名、エンジン情報の一致、実行パスの登録状況 |
| UEの検証統計で「Missed」 | PSOプリキャッシュ | 使用時点でプリキャッシュの対象になっていなかったPSO |
| UEの検証統計で「Too late」 | PSOの準備タイミング | 事前準備に登録されたPSOのコンパイルが、使用時点までに完了したか |
| PSDBからの読み込みで小さなカクつきが発生 | PSOの使用前準備 | ディスクからの読み込みに備えたプリキャッシュが適切に機能しているか |
ASD側のヒット率は、「D3D12CacheListener」などのツールを使い、Windowsのイベントトレース機能「Event Tracing for Windows(ETW)」の記録から確認できる。一方、「Missed」と「Too late」はUnreal Engine側のPSOプリキャッシュに関する検証統計だ。「Missed」は必要なPSOが使用時点でプリキャッシュされていなかったことを示し、「Too late」は事前準備の対象になっていたものの、コンパイルが使用時点までに完了しなかったことを示す。このように、ASD側の収録・照合状況と、UE側のPSO準備状況を組み合わせて調べることで、カクつきが発生する原因を絞り込める。
ただし、ヒット率が低いことやゼロであることだけで、原因を一つに特定できるわけではない。また、PSDBのヒット率とUEのプリキャッシュ統計は、測定対象や集計方法が異なるため、数値を直接比較することは適切ではない。これらは、公式ドキュメントに記載された仕様を基にした確認項目であり、ASDの導入によってどの程度カクつきが減少するかを示すベンチマーク結果ではない。対応していないGPUやドライバー、ASDの対象外となるPSOについても、同じ効果が得られることを保証するものではない。
シェーダー更新時の再生成と、ストア側の対応も必要
ASDを継続的に利用するうえでは、ゲームの更新に合わせてSODBを適切に管理する必要がある。SODBにはゲームのビルドに含まれるシェーダーコードが保存されるため、シェーダーを変更した場合は再生成しなければならない。一方、シェーダーに変更がないビルドでは、既存のSODBを再利用できる。そのため、すべてのパッチで無条件にデータを作り直すのではなく、シェーダーの変更に応じて生成処理を実行する運用が想定されている。グラフィックス用PSOの収録範囲も含め、更新後のゲームで必要なデータが適切に含まれているかを確認することが重要だ。
配信前の検証に向けて、ASDToolにはストア側の処理をローカル環境で再現する機能も用意されている。GPUメーカーのD3D12コンパイラープラグインを使用し、compilepsdbsコマンドでSODBからPSDBを生成した後、registerpsdbsコマンドでローカル環境に登録できる。登録後にゲームを起動し、PSDBが実際に読み込まれているかを確認することで、単にSODBを生成できたかだけでなく、実行環境で正しく利用されるかまで検証できる。これらの機能によって、ストアへ提出する前に、データの生成からコンパイル、登録、実行時の利用までを一通り確認できるようになった。
この検証では、ゲームを識別する情報の整合性にも注意が必要だ。SODBに記録するゲーム名や実行ファイル名、エンジン情報は、実際に起動するゲームの情報と一致していなければならない。また、ローカルでPSDBを登録する際には、対象となる実行ファイルのパスを正しく指定する必要がある。例えば、エンジン名を指定する引数にはUnrealEngine5.8のようにメジャー・マイナーバージョンを使用する仕様となっており、今回ASDに対応したUE 5.8.4のバージョン番号をそのまま指定するわけではない。データが正しく生成されていても、こうした識別情報が一致しなければ、ゲーム実行時にPSDBが利用されない可能性がある。
一方、開発者がASDに対応しただけでは、すべてのプレイヤーがその恩恵を受けられるわけではない。Microsoftの10月21日の発表では、ASDがMicrosoft StoreとXbox PCアプリに加え、今後SteamとEpic Games Storeにも対応する予定であることが示された。Epic Gamesは、Epic Games Storeでの対応を2027年初頭に予定しているが、Steamについては具体的な開始時期が明らかになっていない。また、『Fortnite』についても、今後のアップデートでASDに対応する計画とされている。UE側の開発ツールが対応しても、実際にプレイヤーへデータを届けるには、個別のゲームと配信ストアの双方で対応が必要になる。
プレイヤー側の動作環境にも条件がある。ASDの利用にはWindows 11バージョン24H2以降と、対応するGPUおよびドライバーが必要だ。MicrosoftはAMD、Intel、NVIDIA、Qualcommの対応ハードウェアへの展開を発表しているが、すべてのGPUやドライバーで利用できるわけではない。対応していない環境では、従来どおりゲーム実行時にシェーダーのコンパイルが必要になるため、開発者は既存のPSOキャッシュやプリキャッシュも維持しなければならない。つまり、UE 5.8.4への対応によって、既存のUnreal Engine製ゲームが一斉にASDを利用できるようになるわけではない。
現時点では、UE 5.8.4のASD対応によって、実際のゲームプレイ中のフレーム時間やカクつきがどの程度改善するのかを示す、独立したベンチマーク結果は確認できていない。また、PSDBのヒット率が高くても、シェーダー以外の原因によるカクつきまで解消されるわけではない。今回の対応で重要なのは、開発者がSODBの生成とローカル検証を制作工程に組み込みやすくなり、プレイヤーのPCで行っていたコンパイル処理の一部を、事前処理と配信に移せるようになった点だ。今後は、実際のゲームで必要なPSOを十分に収録できるか、更新後も正しく照合・利用されるか、そして各ストアへの対応が進むことでプレイヤーの体験がどれほど改善するかが焦点となる。



