スタッター対策 シェーダーコンパイル由来の引っかかり解消
この記事の要点
・ゲーム中の引っかかり(スタッター)はシェーダーコンパイル/CPU律速/VRAM不足/ストリーミングの4系統に切り分けると、対処が一気に絞れる。 ・初回エンカウント時だけ詰まるならシェーダーコンパイル由来。frametimeスパイクは50-500ms級で、ほとんどは2周目以降にキャッシュされ解消する。 ・効く対処はプリコンパイル完走・破損キャッシュ削除→再生成・DDUでクリーンドライバ・メニュー放置でのバックグラウンドコンパイル(現状は公開値/目安)。 ・将来はAdvanced Shader Delivery(AgilitySDK 1.618→1.619)が本命路線。DirectStorage 2.0でのシェーダー配信はアグリゲータの予測段階で、確定路線とは分けて考える。
ゲーム中に一瞬カクッと止まる「スタッター」は、原因を1つに決めつけると対処が空振りします。本記事は2026年6月時点の公開情報のみを根拠に、スタッターをシェーダーコンパイル/CPU律速/VRAM不足/ストリーミングの4系統へ切り分ける診断ツリーと、シェーダーコンパイル由来に効く具体対処、そして将来の改善要因を時系列で整理します。スコープは原因切り分けと対処の考え方で、特定ゲームの実測fpsは扱いません(実測値は順次追加・現状は公開値/目安)。
ゲーム中の引っかかり(スタッター)はまず何を疑うべき?
最初に疑うべきは発生する「場面」です。原因系統ごとに引っかかるタイミングが異なるため、場面さえ特定できれば対処はほぼ絞れます。目安は「初回だけ→シェーダーコンパイル」「広いマップ移動時→ストリーミング」「テクスチャが抜ける/遅れて貼られる→VRAM不足」「特定処理で常時→CPU律速」の4分岐です。frametimeを表示するツール(各種オーバーレイ)でスパイクの出方を見ると、より確実に切り分けられます。
この場面ベースの切り分けは、fpsそのものが出ない問題とは別軸です。平均fpsが低い・ボトルネックを特定したい場合は低fpsの原因を切り分ける診断ツリーを先に通すと、スタッター(瞬間的なフリーズ)とフレームレート不足(常時の遅さ)を混同せずに済みます。
スタッターを4系統に切り分ける診断ツリーはどう使う?
「引っかかる場面」を1問ずつ確認し、最初に当たった系統から対処します。1つの系統を潰してまだ残るなら、次に多い系統へ進みます。各系統には技術的な裏付けと固有の対処があり、混同すると効かない対処に時間を使うため、下表で枝と対処を対応させてください。
| 切り分け質問(場面) | 該当系統 | 技術的な理由 | 最初に試す対処 |
|---|---|---|---|
| 引っかかるのは初回エンカウント時だけ? | シェーダーコンパイル | DX12/VulkanはPSO(パイプライン状態)を初回使用時にJITコンパイル。コンパイルはCPUタスクで待ちが発生 | プリコンパイル完走/メニュー放置でバックグラウンドコンパイル/キャッシュ温存 |
| 広いマップを高速移動すると断続的? | ストリーミング | アセット読み出しがフレームに間に合わない。SATA SSD約15ms vs NVMe約3msの読み出しレイテンシ差 | 高速SSDへ導入/テクスチャストリーミング設定見直し |
| テクスチャが抜ける/遅れて貼られる? | VRAM不足 | 容量超過で読み込みが詰まり、テクスチャ解像度が落ちる | テクスチャ品質・影を下げる(VRAM節約) |
| 特定の処理(群衆・物理)で常時重い? | CPU律速 | コンパイルや演算がCPU側で詰まり、GPUが待たされる | CPU負荷の高い設定を下げる/CPUグレード見直し |
出典: SmoothFPS(shader-stutter guide, 2026)、BottleneckCalculator(shader compilation fix, 2026)、Game World Observer(2023)。レイテンシ実測値(SATA SSD 15ms/NVMe SSD 3ms)はBottleneckCalculator。なお高速SSDはストリーミング系のスタッターに効きますが、両出典とも「SSDの高速化でコンパイル自体のスタッターは消えない」と明記しています。SSD選定そのものはゲーミングSSDのNVMe・DirectStorage要件を参照してください。テクスチャ抜け側の対処はVRAM不足によるスタッターの対処で個別に掘り下げています。
なぜ初回だけ引っかかる? シェーダーコンパイルの仕組み
DirectX 12やVulkanは、シェーダー(描画プログラム)を初回に使うその瞬間にコンパイルする方式だからです。旧来のDX11はローンチ時に全シェーダーをプリコンパイルするため、ロードは長い代わりに本編はスムーズでした。DX12/Vulkanはロードが短い反面、新しいエフェクトや敵に初めて遭遇したフレームでコンパイルが走り、そこで50-500ms級のヒッチ(瞬間フリーズ)が出ます。
重要なのは、このコンパイルがGPUではなくCPUのタスクである点です。コンパイル中はCPUが詰まりGPUが待たされるため、見かけ上はCPU律速とも重なります。だからこそ「初回だけか/常時か」で切り分ける必要があります。初回エンカウントでだけ出るなら、ほとんどの環境で2周目以降はキャッシュ済みになり概ねスムーズになります。これは検証手順としても使え、同じ場面を再度通ってヒッチが消えればシェーダーコンパイル由来と確定できます(SmoothFPS / BottleneckCalculator)。
シェーダーコンパイル由来のスタッターを消す対処は?
コンパイルをプレイ前に終わらせるか、済みの結果を温存するのが基本方針です。2026年時点で公開されている主な対処は次の通りです(いずれも公開値/目安。効果は環境・タイトル依存)。
- プリコンパイルを完走させる: 起動時の「Compiling Shaders」「Optimizing」表示をスキップせず最後まで待つ。ここで終えた分は本編で詰まらない。
- 破損キャッシュを削除→再生成: キャッシュが壊れると却ってスタッターが出る。後述のキャッシュフォルダを削除し再生成させる。
- DDUでクリーンドライバ導入: Display Driver Uninstallerで旧ドライバを完全除去してから入れ直すと、キャッシュ起因の不整合が解消しやすい(SmoothFPS Fix 8 / Fix 3)。
- メニューで放置してバックグラウンドコンパイル: タイトル画面や設定画面で数分待つと、裏でコンパイルが進むタイトルがある。
- ページファイルを増やす/オーバーレイを無効化/レイトレを一旦オフ: コンパイル負荷の周辺要因を減らす。
- 可能ならDX11モードを選ぶ: 提供されていれば、ロードは延びるが本編スタッターを避けられる。
キャッシュの実体を知っておくと「温存」と「クリーン再生成」を正しく使い分けられます。NVIDIAはDirectXが%LocalAppData%\NVIDIA\DXCache、OpenGLがGLCache。AMDはDirectXがAMD\DxCache、VulkanがAMD\VkCache。ファイル拡張子はDX12が.PSO/.PipelineCache、Vulkanが.vkcache/.cacheです(SmoothFPS / BottleneckCalculator)。DDUでドライバをクリーン再インストールするとこれらが作り直されるため、再生成中は一時的にスタッターが戻る点も想定しておきましょう。
将来スタッターは減る? Advanced Shader Deliveryの時系列
本命の確定路線はMicrosoftのAdvanced Shader Delivery(ASD)です。ゲーム側のコンパイルをオフライン化・OS側で配信する仕組みで、AgilitySDKを起点に段階的に展開されています。下表が公開情報に基づく時系列です。
| 時期 | 出来事 | 内容 |
|---|---|---|
| 2025-09-25 | AgilitySDK 1.618(ASD初出) | SODB(State Object Database, SQLite3形式)とPSDB(Precompiled Shader Database, オフラインコンパイル成果物)を導入。ゲーム側コード変更なしでWindowsに登録 |
| 2025-10-16 | ROG Xbox Ally系で初投入 | ASDの実機初展開 |
| 2026-03-12 | AgilitySDK 1.619(GDC 2026) | App Identity API + Stats API(シェーダーキャッシュのヒット率取得)を追加。機能拡張の回 |
| 2026後半 | NVIDIA GeForce RTX対応予定 | 公式は「later this year」と案内。AMDはROG Ally系で展開済、IntelはLunar Lake/Panther Lake対応、Qualcomm Adreno X2予定 |
出典: Microsoft DirectX Developer Blog(Agility SDK 1.618: Advanced Shader Delivery, 2025-09-25 / Advanced Shader Delivery: What’s New at GDC 2026, 2026-03-12)。ポイントは、ASDの初出と仕組み導入は1.618であり、1.619は機能拡張とベンダー拡大の回だということです。「1.619でASDが始まった」と誤認しないよう、二段で押さえてください。
ゲームエンジン側の動きもあります。Unreal Engine 5はEpicがASD対応に前向きで、SODB/PSDBの初期テストやPSOシリアライズ周りの実装が進行中と表明しています(TweakTown, 2026-04-22。発言はGDC 2026)。UE系はシェーダースタッターが特に問題視されてきたため、ここが整うと体感差が大きくなる見込みです。
DirectStorage 2.0でシェーダー配信は確定路線?
いいえ、現時点では確定路線ではなく、アグリゲータの予測段階です。「DirectStorage 2.0でコンパイル済みシェーダーをストリーミングする」という話はBottleneckCalculatorの推測記述であり、Microsoftの一次発表ではありません。同記事自身が「広範な採用は2028-2029、2026-2027リリース作品はほぼ未使用」と限定しています。
加えて、ASD(AgilitySDK)とDirectStorageは別技術で、ASD側の一次ソース(Microsoft公式ブログ・UE5関連記事)にDirectStorageへの言及はありません。したがって本記事では、確定路線=ASD(AgilitySDK 1.618→1.619)と予測=DirectStorage 2.0でのシェーダー配信を明確に分けて扱います。今この瞬間の対処は前章の公開手順で行い、DirectStorage 2.0は「将来そうなるかもしれない予測」として温度感を下げて見るのが正確です。なお、これから重量級向けにPCを組むなら原因切り分けの前提となる構成の考え方を重量級PCゲーム向けゲーミングPCの選び方完全ガイドで、予算別の具体構成を重量級PCゲーム向けおすすめゲーミングPC2026 予算別BTO比較で確認しておくと、スタッター耐性の高い構成を選べます。
よくある質問
Q. シェーダーコンパイルのスタッターはSSDを速くすれば消えますか? A. 消えません。高速SSDはアセットのストリーミング系スタッター(広いマップ移動時の引っかかり)に効きますが、コンパイル自体はCPUタスクのため、SATA SSD約15ms→NVMe約3msという読み出しレイテンシ改善とは別問題です(SmoothFPS / BottleneckCalculator)。SSD要件はゲーミングSSDのNVMe・DirectStorage要件を参照してください。
Q. 1周目だけ引っかかって2周目は平気です。故障ですか? A. 故障ではなく、シェーダーコンパイル由来の典型的な挙動です。初回コンパイル結果がキャッシュされ、2周目以降は概ねスムーズになります。これは原因を確定させる検証手順にもなります。
Q. Advanced Shader DeliveryがあればもうPC側の対処は不要になりますか? A. 現時点では不要になりません。ASDは2025年のAgilitySDK 1.618で導入され、NVIDIA RTX対応は2026年後半予定です。普及途上のため、当面はプリコンパイル完走やキャッシュ管理など公開手順での対処が現実的です。
出典・一次情報
- Microsoft DirectX Developer Blog(Agility SDK 1.618: Advanced Shader Delivery, 2025-09-25)
- Microsoft DirectX Developer Blog(Advanced Shader Delivery: What’s New at GDC 2026, 2026-03-12)
- TweakTown(Unreal Engine 5 may be getting Microsoft’s DirectX 12 Advanced Shader Delivery, 2026-04-22)
- SmoothFPS(Shader Compilation Stutter Explained / Fix guide, 2026)
- BottleneckCalculator(Shader Compilation Fix: Stop Game Stuttering Forever, 2026)
- Game World Observer(What is shader compilation and how it became scourge of modern PC gaming, 2023-04-07)
- Unreal Engine Tech Blog(Game engines and shader stuttering: Unreal Engine’s solution)




コメント
コメント機能は準備中です(サイト公開時に有効化されます)。