PCゲームの「起動に時間がかかりすぎる問題」と「プチフリーズ」はなぜ起こる？　その原因を乗り越える取り組みも（1/3 ページ）

　先日、ゲームアプリのデータロード（読み出し）について、コンソール（据え置き型）ゲーム機では高速化が進んでいる反面、Windows PCではそれほど進んでいない背景について解説した。

• →Windows PC向けゲームの「ロード待ち」はなぜ起こる？　背景に過去との「互換性」

　コンソールゲーム機とWindows PCを同じゲームタイトルで遊び比べる観点でいうと、Windows PCではアプリの初回起動時（またはグラフィックスドライバの更新後の起動時）に数分待たされたり、十分なスペックを備えているはずなのにプレイの途中で画面が固まる「プチフリーズ」が起こったりすることがある。いずれも、コンソールゲーム機では見られない現象だ。

　この記事では、これらの問題が発生する背景と、問題解消に向けた対策状況を解説する。「何でこんなに待たされるんだ？」「どうしてスペックいいのに固まるの？」と気になっている人の参考になれば幸いだ。

初回起動の遅さやプチフリーズの原因は「シェーダーのコンパイル」

　冒頭で述べたWindows版ゲームアプリにおける「起動で待たされる」「プチフリーズ」の問題だが、現在ではこれらの現象の主因がシェーダーコンパイルの発動であることが広く知られている。要するに、3Dグラフィックスを描画する「シェーダー」というプログラムの“作り替え”をしているから起動を待たされたり、画面が一瞬固まったりするのだ。

　ゲーム回りのプログラム技術に少し詳しい人なら「ゲームのプログラム本体におけるCPUのx64（x86）コードのように、事前コンパイル済みの（ネイティブの）シェーダーを用意できないの？　開発者の怠慢なの？」と思ってしまうかもしれない。

　なぜネイティブコードを事前に用意しておけないのか――これには単純明快な理由がある。それはWindows PCではGPUのメーカーと種類（モデルや世代）が多く存在するからだ。

　GPUのメーカーは「NVIDIA」「AMD」に加えて「Intel」もある。NVIDIAの「GeForce」とAMDの「Radeon」、そしてIntelのグラフィックスでは別個にネイティブコードを用意しなければならない。

　GPUの場合はこれに加えて、同じメーカーでも世代（アーキテクチャ）が変わるとネイティブコードも変わってしまうという問題がある。同じGeForceでも「GeForce RTX 40」（Ada Lovelace）の世代と、「GeForce RTX 50」（Blackwell）の世代ではネイティブコードは異なる。

　「これらの事情はコンソールゲーム機も同様では？」と思うかもしれないが、例えばPlayStation 4（PS4）やPlayStation 5（PS5）の場合、同一世代であればCPU／GPUを強化した「Pro」モデルを含めてアーキテクチャ自体は“同一”なので、CPUコードはもちろん、GPUコードも事前にコンパイルして用意できる。大規模なアップデートが行われる際も、事前コンパイルしたネイティブコードを盛り込める。

　ゆえに、コンソールゲーム機ではゲームの初回起動時やGPUドライバの更新後に「シェーダーをコンパイルしています」といった形で長時間待たせることはないし、ゲームの途中で突然シェーダーコンパイルが実行されてプチフリーズしたりすることもない。

それにしても時間がかかりすぎるの、なぜ？

　Windows PCにおいて「シェーダープログラムのコンパイル」が必要な理由は分かった。しかし「なんであんなに時間が掛かるの？」という疑問は残る。特に大作ゲームともなると、本当に長時間待たされるケースもある。なぜなのだろうか？

　理由の1つとしては、シェーダーのバリエーションが膨大ということが挙げられる。これは大作ゲームで特に顕著になる。

　「用いる材質の種類」「影の有無」「レイトレーシング処理の有無」といった条件の違いによって、同じような流れでも、シェーダーを別個に用意（生成）することがあるのだ。1つのゲームタイトルにおけるシェーダーの数は、多い場合で数千～数万にもなる。

　GPUというプロセッサは、条件分岐命令を使うと処理速度がグッと遅くなる傾向にある。ゆえに“処理の速さ”を重視する観点で、昨今は分岐の有無に応じて“別の”シェーダーを用意しておくのが主流のアプローチとなっている。だから、シェーダーの種類がどうしても膨大になってしまうのだ。

　さらに補足すると、主要なゲームAPIである「DirectX 12」「Vulkan」では、「どんな頂点形式やプリミティブを使うか？」「どんなプログラマブルシェーダーを使うか？」「固定機能パイプラインのブレンド／深度／ステンシル（必要に応じてラスタライザ設定なども）をどう活用するか？」といった、描画時のGPUパイプライン構成をひとまとめにした「パイプラインステートオブジェクト（PSO）」の定義も必要となる。これも、コンパイルすべきシェーダーのバリエーションが増える一因となっている。

10年前には大した問題ではなかった「シェーダーのコンパイル」だが……

　実は10年以上前のPCゲームでは、シェーダーコンパイルがゲームのパフォーマンス面で問題視されることはなかった。事前コンパイルする場合もそれほど時間は掛からなかったし、もっというと「プレイヤーが新エリアに足を踏み入れたとき」「新しい敵や他のオブジェクトが画面に出現したとき」といったゲーム内のイベント発生タイミングで、必要に応じてコンパイルを行う「オンザフライコンパイル」でも十分に間に合っていたのだ。

　しかし、ゲームグラフィックスが高度になるにつれ、オンザフライコンパイルをするゲームタイトルではコンパイルの発動（実行）頻度が増えてきて、それに伴うプチフリーズの頻発が問題視されるケースも出てきた。

　一瞬とはいえ、プチフリーズがランダムに発生するとなると、ドラマチックなストーリー展開の大作ゲームでは「感情移入」「没入感」という観点でマイナスの効果をもたらしてしまう。

　結果として、近年（特に2020年代に入ってから）は、時間が掛かってしまうのを承知で「ゲームの初回起動時やGPUドライバの更新後に、全てのシェーダーを一括してコンパイルする」というスタイルが増えたのだ。