つぶやく
 |
これは，MicrosoftがGPUメーカーと協力して実現した「Advanced Shader Delivery」という仕組みによるものだ。
なぜシェーダコンパイルに時間がかかるのか，そしてAdvanced Shader Deliveryの仕組みについて，MicrosoftがGDC 2026で明らかにした情報をもとに解説しよう。
PCゲームはなぜシェーダコンパイルで待たされるのか
なぜPCゲームでは，CPU向けのx64（x86）コードのように，GPU向けのネイティブコードを出荷時に用意しておけないのか。理由は明快だ。Windows PCでは，GPUの種類が多すぎるからである。
GPUメーカーには，AMD，Intel，NVIDIAがあり，同じメーカーのGPUでも，世代が変われば直接実行できるネイティブコードも変わってしまう。GeForceとRadeonでコードが異なるのは当然だが，同じGeForce RTXでも，RTX 50/40/30/20シリーズといった世代ごとに違いがあるわけだ。
一方，家庭用ゲーム機では事情が異なる。PlayStation 5/5 ProやPlayStation 4/4 Proといった同一のシリーズ機であれば，CPUとGPUの種類は少ない。
そのため，CPUコードだけでなくGPUのネイティブコードも，事前にコンパイルして提供しやすいのだ。家庭用ゲーム機で，初回起動時のシェーダコンパイル待ちが目立ちにくいのはこの違いによる。
PCゲームで問題になるのは，とくに大作タイトルで，シェーダコンパイルの待ち時間が長くなりやすいことだ。最大の理由は，シェーダプログラムのバリエーションが膨大になる点にある。
処理の流れが似たシェーダでも，材質の種類や影の有無，レイトレーシングの有無などによって，別のシェーダとして生成することが多い。場合によっては，その数が数千から万単位に達する。
GPUでは，条件分岐命令を多用すると性能が落ちやすい。そのため現在は，速度を優先して，分岐の有無ごとに別のシェーダコードを用意する手法が主流だ。これも，シェーダ数が膨大になる理由のひとつである。
 |
DirectX 12やVulkanでは，描画時のGPUパイプライン構成をまとめた「パイプラインステートオブジェクト」（PSO）の定義も必要になる。
PSOは，固定機能パイプラインのブレンド，深度，ステンシル（必要ならラスタライザ設定など）をどう扱うかなどを含む。これも，コンパイル対象のバリエーションを増やす要因だ。
2010年代頃までは，初回起動時にまとめてコンパイルするのではなく，必要になったタイミングでオンザフライ方式のコンパイルを実行するゲームも多かった。たとえば，プレイヤーが新エリアに入ったときや，新しい敵，オブジェクトが画面に現れたときである。
しかし，ゲームグラフィックスが高度になるにつれて，シェーダコンパイルの実行頻度が増えた。その結果，オンザフライ方式では，ゲームが一瞬止まるプチフリーズが発生しやすくなる。
一瞬であっても，予期せず発生するプチフリーズは，ストーリー性の強い大作ゲームほど没入感を損ないやすい。こうしたユーザーの不満を避けるため，とくに2020年代以降は，初回起動時にシェーダプログラムをまとめてコンパイルするタイトルが増えてきたのだ。
Advanced Shader Deliveryが起動待ち時間を大幅短縮
シェーダコンパイルによる待ち時間の問題は，Microsoftも深刻に受け止めており，その対策に乗り出した。
具体的には，Microsoftがゲーム開発スタジオやGPUメーカーと連携し，コンパイル済みのシェーダバイナリをユーザーに配信する仕組みを整備する。
この仕組みを「Advanced Shader Delivery」（以下，ASD）と呼ぶ。ゲーム開発スタジオ，GPUメーカー，PCゲームのオンラインストアが連携して運用するプロジェクトだ。
 |
ASDは，2025年秋から携帯型ゲームPC「ROG Ally」シリーズ向けに，実験的な先行運用が始まっていた。
またValveは，ASDに先んじて，同様の考え方に基づく「シェーダプリキャッシュ」のダウンロード機能を，携帯型ゲームPC「Steam Deck」向けに運用している。
ちなみにIntelは，自社GPUにおけるASDの仕組みを，「Intel Precompiled Shaders」と呼んでいる。ほかのGPUメーカーも，独自の名前を付けるかもしれないが，やっていることは基本的に同じだ。
 |
Microsoftは，2026年2月に提供した「DirectX Agility SDK 1.619」で，シェーダ構成情報を登録するための新しいAPI「ID3D12StateObjectDatabase」（SODB）を追加した。
ゲーム開発者はこのAPIを使うことで，シェーダコードのネイティブコード（バイナリ）だけでなく，レンダリングステートやルートシグネチャ，入力レイアウトといった「シェーダを実行するための前提条件」も，標準化された形式でまとめられる。
そうして出力されるのが，ゲーム内に存在するシェーダ構成を網羅したSODBだ。
ASDの仕組みでユーザーとの接点になるのは，「XBOX App」や「Steam」などのゲーム配信プラットフォームだ。本稿では，これらを「ストアフロント」と呼ぶ。
意外かもしれないが，「NVIDIA App」や「AMD Software」のようなGPUメーカー製のコントロールパネルは，ASDのサポート対象外となっている。さらに，XBOX AppがASDに対応する一方で，Windowsのアプリ配信プラットフォームである「Microsoft Store」は，ASDの対象外だという。いろいろと複雑なようだ。
ゲーム開発元が作成したSODBは，まずストアフロント側のネットワークに提出される。その後，ストアフロントは，AMDやIntel，NVIDIAといったGPUメーカーのネットワークに対して，SODBに基づく事前コンパイルを依頼する。
つまりSODBは，ゲーム開発元からストアフロントを経由して，GPUメーカーへ渡されるわけだ。
では，なぜゲーム開発者は，SODBをGPUメーカーに直接提出しないのか。理由は単純で，新作ゲームやアップデートされたゲームは，SODBとあわせて，ストアフロントにも登録，または更新する必要があるからである。
GPUメーカー側も，新作ゲームやアップデートがストアフロントに登録されるタイミングに合わせて，ドライバソフトの最適化を行うことがある。そのため，SODBもいったんストアフロントを経由したほうが，何かと都合がいいのだ。
GPUメーカーは，提出されたSODBを受け取ると，その情報に従ってシェーダをコンパイルする。対象となるのは，自社GPUと主要なドライババージョンの組み合わせだ。そうして出力されたネイティブコードは，事前コンパイル済みキャッシュ「Pre-compiled Shader Database」（PSDB）としてまとめられる。
この「GPU世代×ドライババージョン」の組み合わせごとにコンパイルする作業は，かなり高負荷な処理だ。そのため，実際にはGPUメーカー側のサーバーで，自動コンパイルされるのであろう。
GPUメーカー側で生成されたPSDBは，ストアフロントに送られて，ストアフロント側のサーバーで管理，保存される。
ASDを利用するにあたって，ユーザーは何もする必要はない。ゲームをインストールするときや，初回起動時，あるいはGPUのドライバソフトやゲーム本体のアップデート後に，ストアフロントがユーザーの環境情報をもとに，自社サーバーを自動で確認する。
そして，ユーザーのPC環境に適したコンパイル済みネイティブコード（＝PSDB）がストアフロント側のサーバーにあれば，ユーザーのPCへ自動的に配信される仕組みだ。
 |
本格的な運用開始が待たれるASDだが，2026年4月時点で公式情報として明らかになっているのは，2026年5月から，一般のゲーム開発スタジオも参加する実用的なトライアルが始まるという。
ASD自体は2025年8月に発表済みで，実運用は，早ければ2026年後半にも始まると見られる。トライアルが軌道に乗れば，本格運用の開始までそれほど時間はかからないのではないか。
GPUメーカーによる荒技的な最適化を，DirectXが公式にサポート
ゲームごとのドライバ最適化を高精度に行うためのフレームワーク整備についても，MicrosoftはDirectXで取り組む。
現在のGPUは，その構造が非常に複雑になっている。ハイエンドGPUでは，シェーダプロセッサの数が2万基を超えているほどだ。さらにAI処理ユニットやレイトレーシングユニットなど，新しい機能も加わっている。
そのため，あるバージョンのドライバソフトで導入した最適化が，特定のゲームでおかしな描画を引き起こす原因になることも珍しくない。
あるいは，GPUメーカーのエンジニアが，不具合の原因となったシェーダプログラムを命令レベルで調べると，想定外の使い方をしていることが発覚する場合もある。
ただ，その想定外の使い方が業界内で広まっていると，今さら「やめてくれ」とは言いにくいだろう。
そうした場合，GPUメーカーは，ゲームの実行ファイルを手がかりにして，特定のゲームが起動したときだけ，ドライバソフトに専用の動作をさせたり，専用プロファイルを適用したりすることがある。
ただ，この方法には弱点もある。たとえば，ユーザーがゲームの実行ファイル名を変更すると，この仕組みは機能しない。
また，個人で制作したゲームの挙動が，たまたま有名タイトルと似ていた場合，ドライバソフトが不要な最適化を適用してしまい，そのゲームに予期しない影響を与える可能性もある。
そこでMicrosoftはDirectXに，ファイル名ではなく，一意のIDでアプリケーションを識別する新機能「Explicit Application Identity」を導入した。
 |
上のスライドは，Explicit Application Identityで登録し，実行時にシステム側へ申告できる情報だ。その下の行には，128bit長の一意のIDが記されている。
- pExeFilename：ゲームの実行ファイル名
- pName：アプリ名，おおむねゲーム名に相当する
- Version：アプリのバージョン番号
- pEngineName：ゲームエンジン名
- EngineVersion：ゲームエンジンのバージョン番号
Explicit Application Identityは，これらの情報をDirectXランタイムやドライバに対して，標準化された形で申告するための仕組みだ。
128bit長のID生成には，中央管理システム不要で，世界規模で一意のIDを生成できる「Globally Unique Identifier」（GUID）や「Universally Unique Identifier」（UUID）の仕組みを使う。このIDは，ゲーム開発の初期段階で生成して，確定させるのが一般的だ。
IDを生成する場所は，使用している開発環境によって異なり，Visual Studioで生成する場合もあれば，各種ゲームエンジン側で生成する場合もある。
実際に，現在どのゲームが動いているのかをドライバソフトが把握する流れは，以下のようになるという。
まずゲームは，Direct3D 12デバイスを生成前に，先のスライドにある「SetApplicationIdentity」APIを使って，自身のIDやアプリ情報をDirectXランタイムに申告する。
一連の情報を受け取ったDirectXランタイムは，ドライバソフトからも参照できる形でこの情報を渡す。ドライバソフトは，それをアプリ識別のIDとして利用する。
ドライバソフトは，自身の動作制御プロファイルに，渡されたアプリIDやアプリ情報が登録されているかどうかを確認する。
登録されていなければ，ドライバソフトは通常の動作を続けるが，登録されている場合は，そのアプリ情報に紐付けられた専用の動作モードへ切り替えるわけだ。
 |
この仕組みを使えば，特定のベンチマークソフトに対する個別対応なども容易になる。そうなると，これはこれで別の議論を呼ぶ可能性もあろう。
しかし，ゲームにおいては，安定した動作を実現しやすくなる。PCゲームファンにとっては，それほど悪いシステムではないだろう。
Explicit Application Identityは，2026年2月にリリースされた「DirectX Agility SDK 1.69」で公開されている。ただし，ゲームエンジン側での実装や，各GPUメーカー側の運用体制が整って実際のゲームで使われるようになるのは，2026年後半から2027年にかけてになるのではないだろうか。
