私の環境では、ゲーム本体を別SSDへ入れている状態で、NVIDIAの %LOCALAPPDATA%\NVIDIA\DXCache が約24GBになっていた。Shader Cache SizeはDriver Defaultのまま。この24GBには、今回遊んでいたゲームだけでなく、以前のゲームで増えていたDXCacheも含まれている。

つまり、ゲーム本体とは別に、Windowsが入っているCドライブで24GB近いシェーダーキャッシュを使っていたことになる。1本のゲームだけで必要になった容量ではなく、複数のゲームを遊んできた環境で蓄積した結果として確認した数字だ。

ここで気になったのが、PCゲームの「ストレージ要件」と、実際にプレイを続けるうえで必要になるストレージの差だった。DXCacheは、その差をかなり大きくする要素の一つになっている。

Steamのシステム要件にはCPU、メモリ、GPU、DirectX、ストレージが並ぶ。GPUは具体的な型番まで指定される一方、ストレージは「100GBの空き容量」のような一つの数字で示されることが多い。

ところが実際のWindows環境では、ゲーム本体に加えてOSの動作用領域やGPUドライバのシェーダーキャッシュもディスクを使う。ストレージ欄はゲーム本体を置く目安としては役立つものの、快適にプレイするためのPC全体の余裕までは読み取れない。

この記事では、DXCacheが約24GBになっていた自分の環境を起点に、NVIDIAのShader Cache、Windowsの仮想メモリ、Unreal EngineのDDCまで見ていく。目的は、ゲーム購入前とプレイ中で、どの容量を確認しておけばよいのかを掴むことだ。

AMDにもシェーダーキャッシュはあるが、今回は自分で確認できるNVIDIA環境に絞った。

複数のゲームを遊んだ環境で、DXCacheが約24GB使っていた

今回確認できた状態を単純化すると、次のようになる。

ゲーム本体
→ 別SSDへインストール

WindowsのCドライブ
└─ NVIDIA DXCache 約24GB
   ├─ 以前に別のゲームを遊んでいた時点で増えていた分
   └─ その後のプレイで増えた分

NVIDIAのDXCacheは、標準ではWindowsのユーザープロファイル側に作られる。

%LOCALAPPDATA%\NVIDIA\DXCache

ゲーム本体を別SSDへ入れていても、シェーダーキャッシュの保存先はCドライブ側のまま。私の環境では、過去に遊んだゲームの分も含めたDXCache全体で約24GBを使っていた。

ゲームのシステム要件を満たしていても、OSドライブ側では別の容量が消費されていく。今回の記事は、この差をどう見積もるかというところから始まった。

Steamのストレージ要件はインストール容量の目安として読む

Path of Exile 2のSteamページでは、2026年9月25日時点で最低・推奨ともに「100 GB の空き容量」と記載されている。

ゲーム本体の容量はアップデートで変わるので、ここで見たいのは100GBという数字そのものではなく、システム要件の示し方だ。

ストレージ欄は、ゲーム本体をインストールできるかどうかを見る目安になる。ただ、プレイ中に必要な総空き容量まで考えるなら、Windows側のページファイルや一時領域、NVIDIA DXCache、ゲーム固有のキャッシュも加味したい。

私はPCゲームのストレージを、次の2つに分けて見ている。

ゲームを入れるドライブ
└─ ゲーム本体

Windowsのシステムドライブ
├─ Windowsが安定して動くための空き
│  ├─ pagefile.sys
│  ├─ 一時ファイル
│  └─ OSやアプリの処理領域
├─ NVIDIA DXCache
└─ ゲーム固有のキャッシュやデータ

「ストレージ100GB」はゲーム本体を置く側の目安。Windows側にどれだけ余裕が残るかは、別枠で確認している。

Windows側の空きには仮想メモリも含まれる

Windowsでは、物理メモリに加えてページファイルも使い、メモリのコミット上限を確保している。

Microsoftの説明によれば、システム管理のページファイルは必要に応じて拡張される。その余地を残すには、ページファイルを置くボリューム側にも十分な空きが必要だ。コミット使用量が上限へ近づくと、フリーズやクラッシュにもつながるので注意したい。

そのため仮想メモリは、Windowsを安定して動かすための空き容量に含めて見ている。

ゲーム本体がDドライブにあっても、Cドライブの余裕まで増えるわけではない。そこへDXCacheが20GB台の規模で残れば、ゲームの保存先とは別の場所で容量が効いてくる。

NVIDIAはShader CacheのDriver Defaultを16GBにしている

NVIDIAは2026年5月に更新したサポート情報で、Shader Cache SizeのDriver Defaultを16GBとしており、大きなゲームライブラリではより大きなサイズが最適なパフォーマンスにつながる場合がある、と説明している。

NVIDIA Control Panelの説明によると、Shader Cache Sizeの上限へ達すると古いシェーダーから削除される。あとで同じシェーダーが必要になれば再コンパイルが発生するため、ゲーム中のstutterにつながる可能性もあるという説明だ。

Driver Defaultが16GBという時点で、現在のNVIDIA環境ではシェーダーキャッシュを十数GB単位で考えた方がよさそうだ。

Driver DefaultでもDXCache全体は約24GBになっていた

私の環境では、Shader Cache SizeをDriver Defaultのまま使っていて、DXCache フォルダ全体は約24GBだった。今回のゲームを始める前から、別のゲームを遊んでいた時点ですでにDXCacheは増えている。

%LOCALAPPDATA%\NVIDIA\DXCache

NVIDIAのDriver Defaultは16GBだが、少なくとも私のPCではDXCacheフォルダがそれを超えていた。削除やgarbage collectionのタイミングなど、ドライバ内部の細かな挙動までは追えていない。

そこで16GBは、実使用量が必ず止まる境界ではなく、NVIDIAが現在のShader Cacheに割り当てている規模を知る参考値として見ている。複数のゲームを遊んだ環境でDXCache全体が24GB近くなった経験もあり、Cドライブには数十GB規模のキャッシュが残る前提で余裕を持たせるようになった。

DXCacheの実体を別SSDへ移した方法は、別の記事にまとめている。

グラフィックの進化で、シェーダーキャッシュの存在感も大きくなった

現在のゲームでは、多くの描画処理でシェーダーが使われる。必要なシェーダーをゲーム中に毎回コンパイルするとフレーム時間へ影響するため、一度生成した結果をディスクへ保存して次回以降に再利用するわけだ。

NVIDIAのShader Cacheも、この再コンパイルを減らすための仕組みになる。ストレージを消費する代わりに、同じ処理を何度も繰り返さずに済む。

GPUのシステム要件では、具体的な世代やVRAMまで細かく書かれることが多い。その一方で、ストレージ欄はゲーム本体の容量を中心にした一つの数字で終わることが多い。

Shader CacheのDriver Defaultが16GBで、実環境ではDXCache全体が20GB台になることもある。こうしたランタイム側の容量まで見ると、ストレージ欄の一数字だけでは見えない部分がかなり大きい。

Unreal EngineのDDCを見ると、キャッシュを使う設計がよく分かる

ゲームエンジン側の例として分かりやすいのがUnreal EngineのDerived Data Cache、DDCだ。

Epic Gamesのドキュメントでは、マテリアルのシェーダーなど、アセットを利用するために追加生成した派生データをDDCへ保存すると説明している。サイズが大きくなりやすいデータなので、毎回作り直すよりキャッシュして再利用する設計だ。

ローカルDDCの容量が問題になったときは、別の場所へ移す方法も公式に用意されている。

DDCは開発側のキャッシュなので、その容量をそのままプレイヤー側へ当てはめる話ではない。ただ、「計算済みのシェーダーや派生データをストレージへ置いて再利用する」という設計を見る参考にはなる。プレイヤー側でも、GPUドライバやゲーム自身が再計算を減らすためのデータを保存しているからだ。

ゲーム本体のファイル容量とは別に、こうしたキャッシュの領域も存在している。

Cドライブはどのくらい空けておくか

私の環境では、複数のゲームを遊ぶ中でDXCache全体が約24GBになっていた。これは新しいゲームを始めるたびにゼロから作られる容量ではなく、以前のゲームで増えた分を抱えたまま次のゲームへ移ることもある。

空き容量を見るときも、「DXCache用に24GBを追加」と単純に足し算するのではなく、まず現在のCドライブにどれだけ余っているかを見る。そのうえで、今後増えるDXCacheやpagefile、一時ファイル、更新処理に使える余地を考えたい。

私が普段の目安にしているのは次のくらい。

Cドライブの現在の空き私の目安
30GB未満今後のキャッシュ増加やWindows側の処理に使える余裕が小さい
50GB前後ゲーム用途で最低限残しておきたい目安
100GB前後SSD容量に余裕があるなら、この程度を維持したい

この表はMicrosoftやNVIDIAの公式推奨値ではなく、自分の環境でDXCacheが複数ゲームにまたがって増えていたこと、さらにWindows側にもpagefileなどの伸びしろが要ることを踏まえた運用上の目安だ。

新しいゲームを始める時点ですでにDXCacheが存在することもあるので、私は50GB前後の空きが残っている状態を一つの基準にしている。

チェック1: Cドライブの空き容量を見る

最初に見るのは、Windowsが入っているドライブの現在の空き容量だ。PowerShellなら、次のワンライナーで数字だけ確認できる。

Get-PSDrive C | Select-Object @{N='FreeGB';E={[math]::Round($_.Free / 1GB, 1)}}

出力例。

FreeGB
------
  47.3

ゲーム本体をDドライブへ入れていても、Cドライブの空きが少なければ次にDXCacheやpagefileの内訳を見る。

チェック2: NVIDIA DXCacheが何GB使っているか見る

次はDXCacheそのもの。合計サイズは次のコマンドで確認できる。

$p="$env:LOCALAPPDATA\NVIDIA\DXCache"; "{0:N1} GB" -f ((Get-ChildItem $p -File -Recurse -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum / 1GB)

私の環境では、以前のゲームで増えていた分も含め、このフォルダ全体で約24GBを使っていた。Cドライブの空きが急に減ったときは、まずここを見ればDXCacheがどの程度占めているか分かる。

チェック3: pagefileが現在どれくらい確保されているか見る

DXCacheだけで容量の減り方を説明できない場合は、pagefileも確認したい。Windowsが現在確保しているサイズは、次のコマンドで分かる。

Get-CimInstance Win32_PageFileUsage | Select-Object Name,@{N='AllocatedGB';E={[math]::Round($_.AllocatedBaseSize / 1024, 1)}},@{N='CurrentGB';E={[math]::Round($_.CurrentUsage / 1024, 1)}},@{N='PeakGB';E={[math]::Round($_.PeakUsage / 1024, 1)}}

AllocatedGB は確保済みのサイズ、CurrentGB は現在使用量、PeakGB はピーク使用量を示す。DXCacheと合わせて見れば、Cドライブで何が容量を使っているのか把握しやすい。

チェック4: ゲーム中のコミット量を見る

ゲームが重い、アプリが落ちる、Windows全体の反応が悪い。そこまで症状が出ているなら、現在のコミット量も見ておきたい。

Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory | Select-Object @{N='CommittedGB';E={[math]::Round($_.CommittedBytes / 1GB, 1)}},@{N='CommitLimitGB';E={[math]::Round($_.CommitLimit / 1GB, 1)}}

ゲームを起動した状態で実行すれば、物理メモリとページファイルを含むコミット上限へどの程度近づいているか分かる。

DXCacheの肥大化とメモリ不足は別の問題だ。ただし、Cドライブの空きが少なければpagefileの拡張余地も小さくなる。ゲームが重い原因を追うときは、ストレージとメモリの両方を見ておくと切り分けやすい。

チェック5: Cドライブ・DXCache・pagefile・コミット量をまとめて見る

一つずつ実行するのが面倒なら、主要な項目を次のワンライナーでまとめて表示できる。

$d=Get-PSDrive C;$p=Get-CimInstance Win32_PageFileUsage;$m=Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory;$c=(Get-ChildItem "$env:LOCALAPPDATA\NVIDIA\DXCache" -File -Recurse -ErrorAction SilentlyContinue|Measure-Object Length -Sum).Sum;[pscustomobject]@{C_Free_GB=[math]::Round($d.Free/1GB,1);DXCache_GB=[math]::Round($c/1GB,1);Pagefile_GB=[math]::Round(($p|Measure-Object AllocatedBaseSize -Sum).Sum/1024,1);Commit_GB=[math]::Round($m.CommittedBytes/1GB,1);CommitLimit_GB=[math]::Round($m.CommitLimit/1GB,1)}
項目見ているもの
C_Free_GBCドライブの現在の空き容量
DXCache_GBNVIDIA DXCacheの合計サイズ
Pagefile_GB現在確保されているページファイル
Commit_GB現在コミットされているメモリ
CommitLimit_GB物理メモリとページファイルを含むコミット上限

この5項目があれば、Cドライブの枯渇、DXCacheの肥大化、pagefileやコミット上限の逼迫を一度に見渡せる。ゲームが重いときの切り分けにも使いやすい。

アップデート時の一時容量は別枠で考える

ここまで扱ってきたのは、普段プレイするときに必要になる容量だ。

もう一つ、ゲームによってはアップデート時に大きな一時領域を使う。新しいpackファイルを作ってから差し替える方式では、差分ダウンロード自体が小さくても、更新処理側でゲーム本体に近い容量を要求することがある。

この部分はゲームのファイル構成や配信方法に左右されるので、できればゲームメーカー側がシステム要件やサポート情報として提示してほしい。

DXCacheとは別の話として、購入時には「普段使うための空き」と「大型アップデート時の一時空き」の両方を意識している。

ストレージ要件はインストール容量として読み、OSドライブの余裕を別に見る

今回一番気になったのは、ゲーム本体とは別にNVIDIA DXCacheがCドライブで大きな容量を使っていたことだ。私の環境では、複数ゲーム分を含めて約24GBになっていた。

NVIDIAのShader CacheはDriver Defaultで16GB。実際のDXCache全体が20GB台になる環境もあるのに、ゲームのストレージ要件は「100GBの空き容量」のような一数字で示されることが多い。

だから私は、ストレージ要件をゲーム本体側の目安として見つつ、快適にプレイするための余裕はWindowsの動作用領域とDXCacheまで含めて考えている。

NVIDIA環境でゲームを遊ぶなら、私は次の3つを別々に見る。

1. ゲームを入れるSSD
   → ゲーム本体が入る容量

2. Windowsのシステムドライブ
   → pagefileやOS処理に使える余裕

3. NVIDIA DXCache
   → 数十GBまで増える可能性があるランタイムキャッシュ

購入前なら1だけで終わらせず、2と3を見たうえでCドライブにも余裕を残しておく。すでにプレイ中で空き容量が急に減ったり、ゲームが重くなったりしたなら、PowerShellで実際の使用量を確認すればよい。

複数ゲーム分を含むDXCacheが約24GBになっていた自分の環境では、ゲームのストレージ要件とは別にOSドライブ側の余裕を見る、という考え方が一番しっくりきている。