ゲーム中にGPU使用率が突然0%になる原因｜CPU・VRAM・SSD・ドライバーの待ちとTDRを切り分ける【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
CPU・VRAM・SSD・ドライバーのどこで仕事が止まっているかを切り分ける
出典：Microsoft DirectX Developer Blog「GPUs in the task manager」、Microsoft DirectX Developer Blog「Navigating the Redesigned Graphics Settings page」、Intel公式サポート「High CPU Usage but Low GPU Usage」、Microsoft Learn「Profile the CPU and GPU with timing captures」、GitHub（microsoft/DirectStorage）、Microsoft Learn「DXGI_QUERY_VIDEO_MEMORY_INFO structure」、「Residency」（Direct3D 12）、「Guidance for Troubleshooting Data Corruption and Disk Errors」、「Information about Event ID 51」、「WDDM Support for Timeout Detection and Recovery (TDR)」、「Bug Check 0x117 VIDEO_TDR_TIMEOUT_DETECTED」、「Bug Check 0x141 VIDEO_ENGINE_TIMEOUT_DETECTED」にもとづきます。情報は2026年9月8日確認。
PCゲームをプレイしていると、普段は90〜100%程度で張り付いているGPU使用率が、突然0%近くまで落ちる瞬間があります。その瞬間だけFPSが大幅に下がったり、画面が数秒だけ固まったりすると、グラフィックボードが故障したのではないか、GPUへ電力がうまく供給されていないのではないかと不安になるはずです。
しかしGPU使用率が下がったからといって、GPU自体が壊れているとは限りません。ゲーム中のGPUは、CPUから描画コマンドが届くのを待ったり、SSDからゲームデータが読み込まれるのを待ったり、VRAMへ必要なリソースが配置されるのを待ったりと、ゲーム全体の処理状況によって一時的に仕事待ちの状態になることがあります。Microsoftのゲーム解析ツールPIXでも、CPUがグラフィックス処理を送信してからGPUが実行するまでの待ち時間、ファイルI/O、メモリ割り当て、GPUの処理内容までを同じタイムライン上で確認できる設計になっており、フレームの生成はGPU単体ではなくCPU・メモリ・ストレージを含むパイプライン全体で成り立っています。
この記事ではGPU使用率が0%になったときに何をどの順番で確認すればいいかを、CPU・VRAM・SSD・GPUドライバーの4方向に分けて解説します。イベントビューアーに残るイベントID129・153・51や、GPUハングを示すLiveKernelEvent 117・141、WindowsのTDR（Timeout Detection and Recovery）が既定で何秒待つのかといった、原因の裏付けとして実際に確認できる情報までMicrosoft・Intel公式のドキュメントにもとづいて整理し、最後にGPU故障をどこまで疑うべきかの判断材料もまとめています。
目次
結論GPU使用率0%は原因ではなく結果であることが多い
GPU使用率が0%になったとき、GPU自体が壊れている可能性はゼロではありませんが、多くの場合はCPU・VRAM・SSDのどこかでGPUに渡す仕事が滞っているだけです。同じタイミングのCPU各コア使用率、VRAM使用量、SSDのアクティブ時間、GPUクロック、画面が暗転したかどうかをあわせて確認すると、原因のカテゴリをその場で絞り込めます。
基礎知識GPU使用率0%とは何を表しているか
GPU使用率は、その時点でGPUの処理エンジンがどの程度動作しているかを示す指標です。WindowsのタスクマネージャーはGPUに存在する3D、Copy、Video Decode、Video Encodeなど複数のGPUエンジンについて利用率を取得しており、Microsoft DirectX Developer Blogによると、この値はWindows Display Driver ModelのGPU SchedulerとVideo Memory Managerから直接取得され、DirectXだけでなくOpenGLやVulkanを利用する処理も対象になります。タスクマネージャーに表示される「GPU」使用率は、すべてのGPUエンジンを単純平均した数字ではありません。同ブログでは、複数エンジンの中で最も使用率が高いエンジンを代表値としてGPU全体の使用率に表示していると説明されています。
ゲームの3D描画処理を担当するエンジンです。タスクマネージャーの「GPU」列は複数あるGPUエンジンのうち最も使用率が高いものを代表値として表示するため、3Dエンジンがほぼ止まっていれば、ここが0%近くまで下がります。
テクスチャなどのデータ転送を担当するエンジンです。3D描画がほぼ止まっていても、Copyエンジンが動作していれば代表値としてのGPU使用率がゼロにならない場合があります。
動画の再生時に使用されるエンジンです。ゲーム内ムービーの再生方式によっては、3Dとは別にこのエンジンが動作します。
録画・配信機能が使う専用のエンコーダーです。ゲーム側の描画とは別に動作するため、3D側の状況を直接示すものではありません。
つまりGPU使用率0%とは、基本的には測定期間中に代表エンジン（多くの場合は3D）へほとんど処理が発生していなかった状態を指します。ただし一瞬だけ0%と表示されたからといって、必ず異常というわけではありません。
内蔵GPUとGeForceやRadeonなどのディスクリートGPUを両方搭載しているノートPCでは、確認しているGPUそのものを取り違えている場合もあります。たとえばタスクマネージャーに「GPU 0 Intel Graphics」「GPU 1 GeForce RTX」のように複数表示されているPCで、ゲームが実際にはGPU 1を使っているのにGPU 0だけを見ていれば、使用率がほぼ0%に見えても不思議ではありません。Windows 11では設定からシステム、ディスプレイ、グラフィックスと進むと、アプリごとに使用するGPUの既定を省電力または高パフォーマンスから選べます。Microsoft DirectX Developer Blogでも、複数のGPUを搭載するハイブリッドグラフィックス機では、高いグラフィック性能を必要とするアプリのGPUを個別に指定できる仕組みが用意されていると説明されています。ゲーム中に実際に使われている「GPU」がどれかも、タスクマネージャーのGPUエンジン列とあわせて確認してください。
一次判定正常な0%か異常を疑う0%かをまず切り分ける
GPU使用率が0%へ落ちたとき、最初に切り分けたいのは「ゲームの場面として普通に起きること」か「実際にプレイへ支障が出ていること」かです。ロード画面やメニュー画面、ムービーへの切り替え、マップ移動の一瞬など、GPUよりCPUやストレージ側の処理が中心になる場面では、GPU使用率が一時的に下がっても不自然ではありません。またFPSを60などに固定している場合や、測定ツールのサンプリング間隔の影響で数字だけ0%に見えている場合もあります。実際に調べたいのは、通常プレイ中に使用率が0%まで落ち、その瞬間にFPSも大きく下がったり画面が数秒止まったりする場合です。
- ロード画面・メニュー画面・ムービー再生・マップ切り替えの瞬間に発生する
- V-SYNCやFPS Limiter、NVIDIA Control Panel・AMD Software・RTSSなどでFPSを意図的に上限固定している
- 表示上は0%でも、FPSやフレームタイムに目立った変化がない（サンプリング間隔の影響が考えられる）
- 通常プレイ中に発生し、同じタイミングでFPSも大きく下がる
- フレームタイムに大きなスパイクが出てカクつく、または画面が数秒止まる
- 画面が一瞬暗転してから復帰する
CPUCPUボトルネックでGPU使用率が下がる
GPU使用率が下がる代表的な原因がCPUボトルネックです。GPUはCPUからゲームの描画に必要なコマンドが送られて初めて仕事を実行できます。CPU側でゲームロジックや物理演算、ドローコールの処理に時間がかかると、GPUが前の処理を終えても次の仕事が届かず、その間GPUは待機状態になります。Intel公式のサポート記事でも、CPU使用率が高くGPU使用率が低い状態はボトルネックの典型例として説明されており、ボトルネックとは他のハードウェアの性能上限によって全体の性能が制限される状態を指すとされています。MicrosoftのPIXでも、CPU側でグラフィックス処理が送信されてからGPUが実際に実行するまでの遅延を、CPUとGPU双方のタイムライン上で確認できる設計になっています。
VRAMVRAM不足でもGPU使用率が落ちることがある
GPU使用率の低下と大きなカクつきが同時に発生する場合はVRAMも確認します。WindowsではGPUが利用できるビデオメモリに予算（Budget）という考え方があります。MicrosoftのDXGI_QUERY_VIDEO_MEMORY_INFO構造体では、アプリケーションがターゲットとするVRAM予算をBudget、現在の使用量をCurrentUsageとして取得でき、CurrentUsageがBudgetを超えた場合はOSによる背景処理の影響でスタッターやパフォーマンス低下が発生する可能性があると説明されています。つまりVRAMが不足すると、必要なリソースをVRAMへ置けなくなり、メモリの退避や再配置が発生し、その間GPUの処理が一時的に待たされてフレームタイムが悪化する可能性があります。
単純に8GBのGPUで7.9GB使っているから故障と判断する必要はありません。ゲームやWindowsは利用可能なメモリをキャッシュとして積極的に使う場合があります。重要なのは搭載容量そのものではなく、OSがゲームへ割り当てているVRAM予算との関係です。Direct3D 12のResidencyについてMicrosoftは、プロセスごとにGPUメモリ予算が存在し、予算内に収まらない場合はプロセスが断続的に停止されたり、リソース作成のAPIが失敗を返したりする可能性があると説明しています。VRAM使用量が上限付近でGPU使用率0%のカクつきが起きているなら、テクスチャ品質を下げて変化を見る方法が有効です。
- テクスチャ品質を最高にしたままVRAM使用量7.9GB、GPU使用率が周期的に0%へ落ち、大きなカクつきが出ている状態
- テクスチャ品質を1段階下げるとVRAM使用量6.5GB、GPU使用率が安定し、カクつきが解消する状態
このような変化が見られるなら、VRAM容量やBudgetとの関係を疑う根拠になります。解像度、レイトレーシング、テクスチャパックなどVRAM消費の大きい設定もあわせて確認してください。
ディスクリートGPUでも、WindowsはシステムRAMを共有GPUメモリとして利用できます。ただしGPU上に直接搭載されたVRAM（専用メモリ）とシステムメモリでは、アクセス条件が異なります。Microsoft DirectX Developer Blogでも、専用メモリはGPUの排他的な使用のために予約されたメモリ、共有メモリはCPUとGPUの両方が使える通常のシステムメモリと説明されており、両者は別々に管理されています。専用VRAMが不足し、大量のリソース移動が発生する状態ではフレームタイムが悪化する可能性がありますが、共有GPUメモリの数字が少し増えただけで異常と判断せず、専用VRAM使用量とBudget、フレームタイムの変化をあわせて確認してください。
SSDSSD・ストレージ待ちでGPU使用率が下がる
SSDが遅いとGPU使用率が0%になる可能性はあります。ただしSSDが遅いからGPU性能そのものが落ちるという意味ではありません。ゲームが次に描画するテクスチャやモデル、マップデータをまだストレージから取得できていなければ、GPUへ仕事を送るためのデータがそろわず、GPUが待機して使用率が下がることがあります。MicrosoftのDirectStorageは、ゲームがNVMe SSDなど高速なストレージから多数の小さなデータを高いスループットかつ低いCPU負荷で読み込むことを目的として設計されており、現代のゲームではストレージからメモリへアセットを供給する速度もゲームパイプラインの一部になっています。
イベントIDイベントビューアーで確認するストレージ関連イベント
ゲーム中のGPU使用率0%と数秒のフリーズが繰り返し発生する場合は、イベントビューアーのシステムログも確認します。ストレージ関連のイベントには、GPUではなくストレージ側の遅延を示すものがいくつかあります。
Microsoft公式のトラブルシューティング資料によると、イベントID153はStorportミニポートドライバー（アダプターやHBAドライバー）が要求をタイムアウトした場合に記録され、ストレージサブシステムが過負荷になっていることを示します。
同資料では、イベントID129はStorportドライバー（Storport.sys）がディスクへの要求をタイムアウトした場合に記録されるとしています。イベントID153と同様、ストレージ側が過負荷になっているサインです。
Microsoft公式の情報によると、イベントID51はページング操作だけでなく、バッファードI/Oであれば通常のファイル読み書きでも記録される場合があるとされています。1件だけで即座に故障とは断定できませんが、GPU使用率が0%になる瞬間と時刻が一致しているなら、SSDやストレージドライバー側を調べる価値があります。
ゲームが固まった時刻とこれらのイベントが一致しているなら、GPUではなくゲームデータを供給するストレージ側で待ちが発生している可能性を調べる価値があります。同じゲームを別のSSDへ移動して症状が消えるか比較すると、切り分けとして有効です。またRAM使用率がほぼ100%になっている場合は、Windowsのメモリ管理によってページファイルへのアクセスが増える可能性があります。その状態でゲーム側も大量のアセットを読み込んでいれば、CPUやストレージ待ちが増え、結果としてGPUへ十分な処理が届かなくなることがあります。GPU使用率0%が頻発する場合は、RAM使用量やコミット使用量、SSDのアクティブ時間もあわせて確認してください。
GPUドライバーGPUドライバーのリセットとTDR
GPU使用率の低下と同時に画面が一瞬暗くなる場合は、GPUドライバーのTDR（Timeout Detection and Recovery）を確認します。WindowsのGPUスケジューラーは、GPUが特定の処理を規定時間内に完了または中断できない場合、GPUがフリーズしたと判断してGPUとディスプレイドライバーのリセットを試みます。
Microsoft公式のWDDMドキュメントによると、GPUスケジューラーがタスクをプリエンプトしようとする際の待機タイムアウトが実質的なTDRタイムアウトで、Windowsにおける既定の時間は2秒とされています。GPUがこの時間内に処理を完了もしくは中断できない場合、OSはGPUがフリーズしたと判断し、GPUとディスプレイドライバーのリセットを試みます。リセット中は通常のゲーム描画処理が継続できないため、GPU使用率が99%からゲーム停止、画面暗転、GPU使用率0%を経て数秒後に復帰するという流れなら、CPUボトルネックよりGPUハングやドライバーリセットを疑う優先度が高くなります。
Microsoft公式のバグチェックリファレンスでは、0x117はGPUが規定時間内にタスクを完了またはプリエンプトできなかった場合に記録されるとしています。信頼性モニターでこのイベントが出ている場合はGPUタイムアウトとの関連を疑えます。
同じくMicrosoft公式のリファレンスでは、0x141は複数あるGPUのディスプレイエンジンのうち、いずれかが適切な時間内に応答しなかった場合に記録されるとしています。117と141のどちらが頻発しているかで、GPU全体のハングかエンジン単位のタイムアウトかを見分ける手がかりになります。
GPU使用率が0%になったあとゲームそのものが落ちる場合は、イベントビューアーのアプリケーションログも確認します。DirectXのゲームではd3d12.dllやdxgi.dllが障害モジュールとして記録される場合があり、ゲーム側のログにDXGI_ERROR_DEVICE_HUNGやDXGI_ERROR_DEVICE_REMOVEDが残ることもあります。単にCPUボトルネックでGPU使用率が下がっているだけなら、通常はGPUデバイスそのものがリセットされる必要はありません。画面暗転やLiveKernelEvent、デバイスリセット系のエラーまで同時に発生しているなら、GPUドライバーやGPU自体の安定性を優先して確認してください。
GPUドライバー更新後から使用率0%とカクつきが始まったなら、ドライバーとの前後関係を確認します。最新版のドライバーへ更新すれば必ず改善するとは限りません。問題が起きる前に安定していたバージョンが分かっているなら、そのドライバーへ戻して比較してください。反対に新発売のゲームで古いドライバーを使っているなら、ゲーム対応版への更新を検討します。重要なのは最新版かどうかではなく、どのバージョンから症状が始まったかです。
GPUドライバーを入れ直す前に、症状の再現条件を記録しておくと原因を追いやすくなります。GPU使用率、GPUクロック、GPU温度、VRAM使用量、CPU各コアの使用率、RAM使用量、FPS、フレームタイム、SSD使用率を同時に監視してください。GPU使用率が低下した瞬間にCPUの特定コアだけ100%ならCPU側、VRAMがBudget付近ならVRAM側、SSDの応答時間が跳ねるならストレージ側、画面暗転を伴うならGPUドライバー側というように、原因の候補を分けられます。フレームタイムのスパイクをグラフで確認する具体的な手順はフレームタイムグラフの読み方を解説した記事で詳しくまとめています。
周辺要因GPUクロック・温度・OC・電源の確認
GPU使用率が0%になったときにGPUクロックも大きく低下することがありますが、これだけではGPU故障とは限りません。GPUへ仕事がなければ、省電力機能によってクロックを下げるのは正常な動作です。つまりGPUクロックが下がったからGPU使用率が0%になったのではなく、GPUへ仕事が来なくなった結果としてGPU使用率が下がり、必要がないのでクロックも下がったという順番になっている場合があります。
故障判断GPU故障を疑うべき条件・疑わなくていい条件
GPU使用率0%だけでは、GPU故障と判断する根拠として不足しています。ここまで確認した内容をもとに、ハードウェアそのものを疑ってよい条件と、まだソフトウェア側を優先して確認すべき条件を整理します。
- 複数の異なるゲームで同じ症状が出る
- 画面暗転や表示崩れを伴う
- LiveKernelEvent（117・141）やTDRが頻発する
- GPU・CPU・RAMを完全に定格へ戻しても再発する
- 別のGPUへ交換すると症状が消える
- 1本のゲームの特定エリアだけで発生する
- CPUの特定コアだけが張り付いている
- VRAM使用量がBudget付近まで来ている
- SSDのアクティブ時間やイベントID129・153・51と時刻が一致する
切り分け特定のゲームか複数のゲームかで対処を分ける
1本のゲームだけで発生する場合
1タイトルだけで症状が出るなら、ゲーム固有の原因である可能性が高くなります。ゲームファイルの整合性を確認し、MODやReShadeなどの外部ツールを外して比較します。DirectX 11と12を切り替えられるゲームなら、APIを変更して変化を見ます。テクスチャ設定を下げてVRAM使用量を減らす、同じゲームを別のSSDへ移動するといった方法も有効です。ゲームアップデート後から始まった場合は、公式が公表している既知の不具合やGPUドライバーとの相性も確認してください。
複数のゲームで発生する場合
ゲームエンジンもメーカーも異なる複数のタイトルで発生するなら、PC側の設定を優先して確認します。GPUドライバー、GPU・VRAMのOC、アンダーボルト、CPUのOC、XMPやEXPO、温度、電源などを一つずつ確認します。ストレージ関連のイベントまで複数のゲームで同時に発生しているなら、SSD側も調べる価値があります。一度PCを完全に定格状態へ戻して比較すると、ソフトウェア側とハードウェア側の設定を分けて考えやすくなります。
手順GPU使用率0%が起きたときの確認順序
最後に、GPU使用率が突然0%になったときに確認する順序をまとめます。
- ゲーム性能が実際に低下しているか確認する。GPU使用率表示だけが0%でも、FPSとフレームタイムが安定しているなら、数字を必要以上に気にする必要はありません。
- CPU各コアの使用率を確認する。特定の1コアだけが張り付いているならCPUボトルネックを疑います。解像度を大きく下げてもFPSが伸びないかもあわせて見ます。
- VRAM使用量を確認する。使用量がBudget付近まで達しているなら、テクスチャ品質などVRAM消費の大きい設定を下げて変化を見ます。
- SSDの使用率と応答時間を確認する。GPU使用率の低下と同時にディスクのアクティブ時間が跳ねるなら、ゲームを別のSSDへ移して比較します。
- イベントビューアーでイベントID129・153・51が同じ時刻に発生していないか確認する。発生しているならストレージ側の調査を優先します。
- 画面暗転を伴うか確認する。伴う場合はLiveKernelEvent（117・141）とGPUドライバーを確認します。Windowsは既定で2秒以内にGPUの処理を完了・中断できなければTDRによるリセットを行います。
- GPU・CPU・RAMのOCやアンダーボルトをすべて標準状態へ戻す。それでも複数のゲームで再現するなら、ハードウェアまで調査範囲を広げます。
関連情報似ているようで違う症状
ここまで説明してきた「プレイ中にGPU使用率が突然0%へ落ちる」症状は、名前が似ているだけの別の症状と混同されることがあります。あわせて起きていないか確認しておくと、原因の切り分けがさらに速くなります。
FAQよくある質問
まとめGPUではなくCPU・VRAM・SSD・ドライバーを見る
ゲーム中にGPU使用率が突然0%へ落ちても、それだけではグラフィックボードの故障と判断できません。GPUはCPU、VRAM、SSDなどから必要なデータや処理が供給されて初めて描画を続けられます。CPUがボトルネックになればGPUへ次の描画処理が届かず、GPUは待機します。Intel公式もCPU負荷が高くGPU使用率が低い状態はボトルネックの典型例だとしています。VRAMについても、搭載容量そのものよりWindowsがゲームへ割り当てるVideo Memory Budgetが重要で、MicrosoftはCurrentUsageがBudgetを超えるとスタッターや性能低下が起こりうると説明しています。
SSDが原因の場合もあります。現代のゲームはDirectStorageのようなAPIを使い、ストレージから大量のアセットを読み込みます。読み込みが追いつかなければ、GPUが次のデータを待って使用率が下がることがあります。一方、GPU使用率0%と同時に画面が暗転したりLiveKernelEvent（117・141）が出たりする場合は、GPUドライバーとTDRを確認してください。WindowsのTDRは既定で約2秒以内にGPUが処理を完了・中断できなければGPUハングと判断し、GPUとドライバーのリセットを試みます。
CPUの特定コアだけが張り付いていればCPUボトルネック、VRAM使用量がBudget付近ならVRAM不足、SSD負荷やイベントID129・153が重なるならストレージ待ち、画面暗転やLiveKernelEventを伴うならGPUドライバー側というように、GPU使用率が落ちた瞬間のほかの数値を見ることが原因の切り分けにつながります。GPU使用率0%は原因ではなく結果であることが多い指標です。CPU・VRAM・SSD・ドライバーを同じタイミングで確認すると、GPUが仕事を止めた本当の理由を見つけやすくなります。
あわせて読みたい
