VRAM使用量が上限に達していないのにゲームがカクつく理由｜Video Memory Budgetの仕組みを公式資料で解説【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
犯人は搭載容量ではなく、Windowsが動的に決める“Video Memory Budget”という枠です
出典：Microsoft Learn「DXGI_QUERY_VIDEO_MEMORY_INFO structure」・Microsoft Learn「IDXGIAdapter3::QueryVideoMemoryInfo method」・Microsoft Learn「Residency」・Microsoft Learn「Memory Management Strategies」・Microsoft DirectXブログ「GPUs in the Task Manager」・Microsoft Learn トラブルシューティング「GPU Process Memory counters report incorrect value」・Microsoft Learn「IDXGIAdapter3::RegisterVideoMemoryBudgetChangeNotificationEvent method」にもとづきます。
タスクマネージャーの「パフォーマンス」タブでGPUを開き、専用GPUメモリがまだ8GB中5GB程度しか使われていないのを確認した。それでも特定の場面に入るたびにフレームが乱れる——VRAM不足を疑って調べても、数字だけを見る限り原因にたどり着けない。こういう相談は珍しくありません。
結論から言うと、この症状の多くは「VRAMの容量が足りているかどうか」とは別の問題です。DirectX 12以降のグラフィックスドライバーモデルは、GPUごとにDXGI_QUERY_VIDEO_MEMORY_INFOという構造体で管理されるVideo Memory Budgetという値を持っており、アプリの使用量がこの枠を一時的に超えると、Windows側の裏方処理によってスタッターが起こります。このBudgetは搭載しているVRAM容量そのものではなく、しかも他のアプリの動きに応じて常に変動する枠です。タスクマネージャーの表示だけでは、この変動を捉えられません。
専用GPUメモリの基本的な確認手順、解像度・タイトル別のVRAM容量目安、テクスチャ品質を下げるといった対処法までを扱う総合的な診断はVRAM不足の見分け方と対処法に譲ります。この記事はその一歩先、「タスクマネージャーを見ても専用GPUメモリに余裕があるように見えるのに、それでもカクつく」というケースに絞り、Microsoft公式資料にもとづいてBudgetとResidencyの仕組みを掘り下げます。
目次
定義Video Memory Budgetとは何か、搭載容量そのものではなくOSが決める枠
DirectX 12以降のグラフィックスドライバーは、GPUごとに「Video Memory Budget」という値を管理しており、ゲームなどのアプリはこの値をDXGI_QUERY_VIDEO_MEMORY_INFOという構造体を通じて取得します。Microsoft Learnの定義によると、この構造体のBudgetメンバーは「アプリケーションが目標にすべき、OS側が提供するビデオメモリの予算(バイト単位)」であり、搭載しているVRAM容量そのものを表す値ではありません。同じ資料は続けて、アプリの現在の使用量(CurrentUsage)がこのBudgetを上回ると、他のアプリへVRAMを公平に配分するためのOS側のバックグラウンド処理によって、スタッターやパフォーマンスの低下が起こりうると説明しています。
つまりゲームが実際にカクつくかどうかを左右するのは「VRAMを何GB搭載しているか」ではなく、「その瞬間にOSから割り当てられたBudgetを、ゲームの使用量が超えているかどうか」です。タスクマネージャーの専用GPUメモリは、搭載容量に対する現在の使用量を示しているだけで、この動的なBudgetそのものを表示しているわけではありません。だから「専用GPUメモリはまだ余裕がある」ように見えても、実際にはその瞬間のBudgetをすでに超えている、という状況が起こり得ます。
このBudgetを取得するAPIの仕様書は、アプリケーションは物理メモリの使用量を明示的にBudget内へ収める必要があり、割り当てられたBudgetに収まりきらないプロセスは一時的に処理を止められてページアウトされるため、スタッターが起こりやすいと説明しています。VRAMの搭載容量ではなく、この瞬間ごとの収支が症状を左右します。
変動要因なぜタスクマネージャーの数値だけでは判断できないのか
Direct3D 12のResidencyに関する公式資料は、このBudgetについて「プロセスに対して利用可能な物理メモリの量がビデオメモリバジェットと呼ばれるものであり、このバジェットはバックグラウンドプロセスの起動・終了によって目に見えて変動し、ユーザーが他のアプリへ切り替えたときには劇的に変動する」と説明しています。つまりBudgetは固定値ではなく、ゲーム以外に何が同時に動いているかによって秒単位で上下する枠です。
この性質が、「タスクマネージャーを見ても余裕があるように見えるのにカクつく」現象の核心です。タスクマネージャーで確認できるのはある瞬間のスナップショットにすぎません。プレイ中に配信ソフトのエンコード処理が動いたり、Discordのオーバーレイが描画を更新したり、バックグラウンドでブラウザが動画を再生し始めたりするたびに、Budgetは縮小方向へ動きます。ゲーム側の使用量が変わっていなくても、Budgetの方が縮んだ結果としてCurrentUsageがBudgetを上回り、スタッターが発生することがあります。
作り込まれたゲームエンジンは、Budgetの変化をOSから通知してもらう仕組み(RegisterVideoMemoryBudgetChangeNotificationEvent)を使い、Budgetが縮んだ瞬間にストリーミング品質を落とすなどして対応します。Microsoft Learnの仕様書も、定期的にBudgetを問い合わせる代わりにこの通知イベントを使えば、Budget変化に合わせて効率よくスレッドを起こせると説明しています。この通知への対応が甘いタイトルほど、Budgetが縮んだタイミングでスタッターが目立ちやすくなります。
内部構造ディスクリートGPUには2つのメモリプールがある
Direct3D 12のメモリ管理に関する公式資料は、GPUのメモリを「ローカル(local)」と「非ローカル(non-local)」という2つのプールに分けて扱います。専用のグラフィックボード(ディスクリートアダプター)を積んだ一般的なゲーミングPCでは、ローカルプールがそのままVRAM、非ローカルプールがシステムメモリに対応します。一方、CPUとGPUがメモリを共有する統合GPU(UMAアダプター)の構成では、非ローカルプールは常にゼロとして扱われる、と同じ資料は説明しています。
Residencyの資料はさらに踏み込み、本来ローカルプール側に置かれるべきヒープ(データの塊)を、カーネルがシステムメモリ側へ移すことがあると説明していますが、これは「極端な最終手段としてのみ」行われる処理だとしています。通常時には起こらない、限界に近づいたときだけ発動する保険のような仕組みです。同じ資料は、この退避が起きたときに毎フレーム参照されるようなテクスチャが対象になってしまうと、フレームレートに深刻な影響を与えると警告しています。
重要なのはVRAMの容量そのものが足りているかどうかではなく、Budgetを超えた瞬間にどのデータがシステムメモリ側へ追い出されるかです。毎フレーム参照するリソースが退避対象になると、専用GPUメモリの数値上はまだ余裕があるように見えても、フレームタイムだけが不規則に伸びるという症状として現れます。
実例オープンワールドタイトルで特に起きやすい理由
Direct3D 12のメモリ管理資料は、頻繁にロード・アンロードを繰り返す「ストリーミングリソース」の代表例として、地形やオープンワールドのテクスチャ・ジオメトリを挙げています。オープンワールドのゲームは、プレイヤーの移動に合わせて周辺エリアのテクスチャや地形データを継続的にVRAMへ読み込み、視界から外れたデータを解放するという処理を常に繰り返しています。
この読み込み・解放が集中するタイミング——高速移動時、エリアの切り替え直後、視点を大きく振ったときなど——は、瞬間的にCurrentUsageが跳ね上がりやすいポイントです。平均的なVRAM使用量はタスクマネージャー上で大きく変化して見えなくても、その一瞬だけBudgetを超えてしまえば、その瞬間のフレームだけがスタッターします。カクつくタイミングが特定の場所・動作に集中している場合は、平均的な使用量ではなく、このストリーミング処理のタイミングを疑うべきサインです。
訂正共有GPUメモリが表示されても、それだけで異常とは限らない
VRAM不足を調べる際によく言われる「共有GPUメモリが使われていたら危険信号」という説明は、半分だけ正しく、半分は単純化しすぎています。Microsoft公式のDirectX開発者ブログは、タスクマネージャーに表示される「共有GPUメモリ」を、GPUとCPUのどちらからも使える通常のシステムメモリと説明しています。前のセクションで触れた非ローカルプールは、ディスクリートGPUの構成でも最初から用意されている領域であり、共有メモリの数値が0を超えて表示されていること自体は、それだけで異常を意味しません。
問題になるのは、共有メモリの数値が急激に増える瞬間があるか、そしてその増加が専用GPUメモリの使用率上昇やスタッターと同時に起きているかどうかです。単発の数値の大きさだけを見て「共有メモリが出ているからもう限界」と判断するのではなく、ゲームを起動する前と後、あるいはカクつく場面の前後で数値がどう動くかを比較してください。
タスクマネージャーの「詳細」タブでアプリごとの専用GPUメモリを確認すると、Windowsの既知の問題により数値が実態より大きく増え続けて見える環境があります。Officeアプリでの再現手順が案内されているような環境依存の問題で、2026年に新しく判明したゲーム特有の不具合ではありません。この問題があっても「パフォーマンス」タブ側のGPU専用メモリ表示は影響を受けないため、判断に迷ったらパフォーマンスタブの数値を優先してください。
対処実際に何を確認すればいいか
ここまでの内容を踏まえると、「専用GPUメモリに余裕があるのにカクつく」場合に見るべきポイントは、容量の大小ではなく変化のタイミングです。以下の順番で確認してください。
- タスクマネージャーを開いたままカクつく場面を再現する。静止した数値ではなく、カクついた瞬間に専用GPUメモリ・共有GPUメモリが跳ね上がっていないかを確認します。
- バックグラウンドで動いているアプリを閉じてから同じ場面を再現する。配信ソフト、複数のブラウザタブ、RGB制御ソフトなどはいずれもBudgetを分け合う要因になります。閉じた状態と比較して症状が変わるかを見ます。
- カクつくタイミングが特定の状況に集中していないか確認する。高速移動中、エリアの切り替え直後、視点を大きく振ったときに集中しているなら、テクスチャストリーミングのタイミングが原因の可能性が高くなります。対応している設定があれば、テクスチャストリーミングの品質を1段階下げて再確認してください。
- マルチモニターや裏での動画再生など、GPUを同時に使う要因を洗い出す。これらもBudgetを縮める側に働きます。
- ここまで試しても改善しない、あるいは専用GPUメモリの使用率がそもそも90%前後に張り付いている場合は、根本的なVRAM容量不足の可能性があります。その場合は解像度・タイトル別のVRAM目安や設定変更の手順をVRAM不足の見分け方と対処法で確認してください。
そのうえで、Budget超過を疑ってよいサインと、それだけでは心配しなくていいケースを整理しました。
- 専用GPUメモリの数値が、カクついた瞬間に跳ね上がっている
- 高速移動・エリア切り替え・視点変更の直後にスタッターが集中している
- バックグラウンドアプリを閉じると症状が軽くなる
- 専用GPUメモリの使用率がそもそも90%前後に張り付いている
- 共有GPUメモリの数値が0より大きく表示されているだけで、急増していない
- タスクマネージャーの詳細タブでプロセス別の数値だけが増え続けて見える(パフォーマンスタブの値は正常)
- 平均的なフレームレート自体は安定していて、ごく短時間だけ乱れる
FAQよくある質問
総括まとめ、見るべきは容量ではなく変化のタイミング
VRAM使用量に余裕があるように見えてもゲームがカクつくのは、多くの場合「容量が足りない」からではなく、「その瞬間にOSが割り当てたVideo Memory Budgetを、ゲームの使用量が一時的に超えている」からです。Budgetは搭載容量より小さくなることがあり、バックグラウンドで動く他のアプリやウィンドウの切り替えによって絶えず変動します。
共有GPUメモリが表示されていること自体は異常のサインではなく、GPUとCPUが共有する通常のシステムメモリが使われているだけです。注目すべきは数値の急増と、それがスタッターと同時に起きているかどうか。高速移動やエリア切り替えの直後に症状が集中しているなら、テクスチャストリーミングのタイミングを疑ってください。
ここまで確認しても改善しない場合や、専用GPUメモリの使用率がそもそも高い場合は、根本的なVRAM容量不足の可能性があります。VRAM不足の見分け方と対処法で、解像度別の目安や設定変更の手順を確認してください。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年7月時点の目安・変動あり
