フレームタイムグラフの読み方｜PresentMonのCPU Busy・GPU Waitでカクつく瞬間を特定する【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
PresentMonのCPU Busy・GPU Waitでカクつく瞬間を特定する
平均144FPSや200FPSと表示されているのに、特定の場面だけ画面が一瞬止まる、新しいエリアに入った瞬間だけ引っかかる——そんな違和感を覚えたことがあるはずです。多くの人はここでFPS表示そのものを疑いますが、平均FPSという数字には「いつ、どれだけ処理が遅れたか」という情報が含まれていません。原因を探るには、FPSではなくフレームタイムのグラフを見る必要があります。
フレームタイムとは、1つ前のフレームから次のフレームが表示されるまでにかかった時間のことです。ミリ秒(ms)で表され、グラフにすると「いつ処理が遅れたか」を直接確認できます。さらにPresentMonというツールを使うと、CPU Busy・CPU Wait・GPU Time・GPU Busy・GPU Wait・Display Latency・Frame Typeといった詳細な指標まで見られるため、遅延がCPU側で起きているのかGPU側で起きているのか、さらにDLSSやFSRのフレーム生成が絡んでいないかまで切り分けられます。
この記事では、フレームタイムというグラフをどう読むか、スパイクの発生パターンから何を疑えばいいかという「考え方」に絞って解説します。原因ごとの具体的な設定変更やパーツ交換の手順は、既に公開している「平均fpsは高いのにカクつく原因は『1% Low』」の記事で詳しく扱っているため、そちらへの案内を挟みながら進めます。
出典：Intel公式（How to Read and Understand CPU Benchmarks）、GitHub（GameTechDev/PresentMon）、GitHub（PresentMon README-CaptureApplication）、NVIDIA Research（Impact of Graphical Fidelity and Frame-Time Stutter in a First-Person Shooter Game）、CapFrameX公式ブログ（Explanation of different performance metrics）、CapFrameX公式ブログ（The challenge of displaying performance metrics as FPS）、GitHub（CXWorld/CapFrameX）、MSI公式ブログ（MSI Afterburner On Screen Display, Monitoring and Features）、Epic Games公式ドキュメント（Common Memory and CPU Performance Considerations）・（PSO Precaching for Unreal Engine）。2026年8月27日確認。
目次
結論グラフの「形」を見れば原因のカテゴリをその場で絞り込める
フレームタイムグラフが低い位置で細かく上下しているなら安定しています。そこに突然大きな山（スパイク）が出るなら、その瞬間にフレーム生成が遅れています。重要なのは、そのスパイクが初回だけなのか、一定間隔なのか、GPU使用率と連動しているのかという「発生パターン」です。パターンが分かれば、CPU側・GPU側・キャッシュ系・バックグラウンド処理のどれを疑うべきか、その場でカテゴリを絞り込めます。
基礎知識フレームタイムとは1フレームを更新する間隔
フレームタイムとは、前のフレームから次のフレームが表示されるまでにかかった時間のことです。一般的にはミリ秒(ms)で表示されます。FPSとフレームタイムは別々の性能指標に見えますが、実際には同じ現象を違う単位で表現したものです。計算式は「フレームタイム(ms) = 1000 ÷ FPS」、逆に「FPS = 1000 ÷ フレームタイム(ms)」で相互に変換できます。
ゲームが60fpsで完全に一定なら1フレームあたり約16.67ms、120fpsなら約8.33ms、144fpsなら約6.94ms、240fpsなら約4.17msになります。FPSが高いほど、次のフレームが表示されるまでの間隔は短くなります。ただし「平均FPSが高いこと」と「すべてのフレームタイムが短くそろっていること」はまったく別の話です。ここがカクつきを判断するうえで重要なポイントです。
Intel公式のCPUベンチマーク読み方ガイドでは、フレームタイムを1%Low・0.1%Lowと並べて「フレーム間の経過時間(ms)を示す指標であり、一貫性が重要で、値は低いほどよい」とだけ簡潔に説明しています。裏を返せば、フレームタイムというデータそのものは単純です。重要なのは、この数値をグラフに描いたときの「形」をどう読むかという実践的なスキルです。
グラフの読み方低く平らなグラフほど安定している
フレームタイムをグラフで表示すると、横軸が時間、縦軸がフレームタイム(ms)になるのが一般的です。正常に144fps付近で安定しているゲームなら、フレームタイムは約6〜7ms付近を細かく上下します。完全な一直線になる必要はありません。CPUやGPUの処理量はフレームごとに少しずつ変化するため、小さな上下は正常です。確認したいのは、大きな山が頻繁に出ていないかどうかです。
下の図は同じ144fps環境を想定した2つのパターンです。上段は6〜7ms前後で細かく揺れているだけの安定パターン、下段は同じ水準の中に1本だけ突出したスパイクが混ざったパターンです。
6〜8ms付近で推移しているところへ突然30ms、50ms、100msといった縦方向の大きなスパイクが出るなら、その瞬間にフレーム生成が遅れています。FPSグラフでも性能低下は確認できますが、瞬間的な処理落ちを見る目的ではフレームタイムの方が直感的です。通常144fpsで動いているゲームのフレームタイムは約6.94msですが、一瞬だけ50msになった場合、フレームタイムグラフでは平常時から50msまで大きな山が直接表示されるため、「いつ、どの程度長いフレームが発生したか」を一目で判断できます。
相対評価同じ20msのスパイクでも基準FPSで意味が違う
フレームタイムのスパイクを見るときは、普段の基準となるフレームタイムと比較する「相対評価」が重要です。60fpsの理想フレームタイムは約16.67msです。ここに20msのスパイクが乗ると、フレームタイムは約36.67msまで伸び、普段の約2.2倍の長さになります。一方、240fpsの理想値は約4.17msです。同じ20msのスパイクが乗ると、フレームタイムは約24.17msまで伸び、普段の約5.8倍もの長さになります。
つまり、絶対値としては同じ「20msの遅れ」でも、高FPS環境ほど普段との落差が大きくなり、グラフ上のスパイクが目立ちやすくなります。「10msを超えたら異常」というような固定のしきい値を一律に当てはめるのではなく、自分の環境の普段のフレームタイムからどれだけ離れたかという相対的な変化量で見る方が実態に近くなります。
詳細指標PresentMonのCPU Busy・GPU Wait・Frame Typeが何を示すか
フレームタイムが跳ねた瞬間が「CPU側で起きているのか、GPU側で起きているのか」までさらに詳しく調べたい場合はPresentMonが役立ちます。PresentMonはWindowsゲームのフレーム性能を計測するオープンソースのツールセットで、DirectXだけでなくOpenGLやVulkanにも対応しています。Intelが配布している現行のPresentMonアプリでは、リアルタイムのグラフやパーセンタイル表示に加え、CPUとGPUのバランスを見るための指標も提供されています。
PresentMonが記録できる主な指標は次の7つです。単純にフレームタイムが跳ねたことを確認するだけならCapFrameXやMSI Afterburnerでも十分ですが、「CPU処理が伸びたのか、GPU処理が伸びたのか」まで切り分けたい場合はこれらの指標が手がかりになります。
CPUがそのフレームの生成に実際にかかった時間です。この値が普段より伸びているなら、CPU側のゲーム処理が重くなっている可能性があります。
CPUがそのフレームの生成を始める前に待機していた時間です。GPU側の処理待ちや同期処理によって発生することがあります。
GPUがそのフレームの処理を開始してから終了するまでの合計時間です。GPU側の負荷全体を見る指標になります。
GPUがそのフレームの処理に実際に費やした時間です。GPU Timeとの差分から、GPUがどれだけ待機していたかも見えてきます。
GPUがそのフレームの処理中に待機していた時間です。GPU使用率が下がっているのにフレームタイムが伸びている場合、この値が手がかりになります。
フレームが送信されてから、実際に画面へ表示されるまでの時間です。表示パイプライン側の遅延を見る指標です。
そのフレームがアプリケーション側で実際にレンダリングされたものか、ドライバーやSDKによって補間（生成）されたものかを区別する指標です。DLSSやFSRのフレーム生成を使用している場面で重要になります。
切り分けの考え方スパイクの発生パターンから疑うべき原因を絞り込む
フレームタイムグラフでスパイクを見つけたら、「いつ、どんな条件で発生するか」というパターンを観察します。同じ「50msのスパイク」でも、発生パターンが違えば疑うべき原因はまったく異なります。代表的な4つのパターンは次の通りです。
同じ場所を最初に通ったときだけスパイクが出て、2回目以降は滑らかになるパターンです。シェーダーやPSO(Pipeline State Object)のコンパイル、初回のみ必要なデータ読み込みが候補になります。Epic Games公式のドキュメントでも、シェーダーのコンパイルは大きな処理スパイクを発生させ、瞬間的だが体感しやすいフレームレートのヒッチにつながると説明されています。事前キャッシュの仕組みでこのヒッチは軽減できますが、以前の実行で作られたキャッシュが残っていると、検証時にヒッチが隠れてしまうことがある点にも注意が必要です。
5秒ごと、10秒ごとなど、ほぼ一定間隔でフレームタイムが跳ねるパターンです。ゲームの描画負荷そのものよりも、オートセーブ、テレメトリ送信、録画ソフト、モニタリングツールなど定期的に走る処理が候補になります。複数のオーバーレイやモニタリングツールを同時に動かしている場合は、一度減らして比較する価値があります。
重い場所へ移動した瞬間にGPU使用率が99〜100%に張り付き、同時にフレームタイムも伸びるパターンです。PresentMonのGPU TimeやGPU Busyが同じタイミングで増えているなら、GPU側の描画負荷そのものが増えた可能性が高くなります。解像度やレイトレーシングなど、GPU負荷の大きい設定が候補です。
スパイクと同時にGPU使用率がむしろ50%や30%まで落ちるパターンです。GPUが仕事を処理し切れないのではなく、GPUへ次の仕事が届いていない状態です。CPU側のゲームロジック処理の遅延、シェーダーの準備、ストレージからのデータ待ちなどが候補になります。GPU使用率が低いという理由だけでGPU側の故障と判断しないよう注意してください。
いずれのパターンでも、原因のカテゴリを絞り込んだ後の具体的な対処（テクスチャ品質の調整、XMP/EXPOの有効化、CPU換装の判断基準など）は、前述の「1% Low」の記事で詳しく解説しています。
フレーム生成DLSS/FSRのフレーム生成使用時は「表示FPS」だけで判断しない
DLSS Frame GenerationやFSR Frame Generationなどを使用しているゲームでは、フレームタイムグラフを見るときにさらに注意が必要です。フレーム生成では、実際にレンダリングされたフレームの間にAIが補間で作った生成フレームが挿入されます。そのため、画面に表示されるFPSと、ゲームエンジンが実際にレンダリングしているベースのFPSは別物になります。
PresentMonにはFrame Typeという指標があり、そのフレームがアプリによってレンダリングされたものか、ドライバーやSDKによって補間されたものかを区別できます。表示上は120fpsという高い数値が出ていても、実際にレンダリングされているベース側のフレームタイムが大きく乱れていれば、操作感や滑らかさへの違和感は残ります。フレーム生成使用時は、単純な表示FPSだけでなくゲーム本体のレンダリング性能も確認した方がよいでしょう。
また、フルスクリーンとボーダーレスのどちらで実行しているか、VRR(可変リフレッシュレート)が有効になっているかといった表示設定も、フレームの表示間隔に影響します。Windows 11でのフルスクリーンとボーダーレスの違いはこちらの記事で解説しています。
フレームタイムスパイクが体感にどう影響するかについては、NVIDIA Researchと米Worcester Polytechnic Instituteの研究チームが2026年5月に発表した論文「Impact of Graphical Fidelity and Frame-Time Stutter in a First-Person Shooter Game」でも検証されています。独自開発したFPSゲームを使い、グラフィック品質とフレームタイムスパイクの組み合わせが体感に与える影響を21人の参加者で調べたもので、0ミリ秒(スパイクなし)、225ミリ秒、675ミリ秒という3段階の大きなスパイクを人為的に発生させています。実際のゲームで日常的に起きる数十ミリ秒規模のスパイクよりかなり大きい条件での検証ですが、結果としてグラフィック品質の違いは主に見た目の評価に影響する一方、フレームタイムスパイクの大きさはプレイの滑らかさとパフォーマンスの体感評価を左右する支配的な要因になったと報告されています。
誤解しやすい点フレームタイムが高い＝カクつきではない
フレームタイムの絶対値が高いことと、不安定であることは分けて考える必要があります。30fpsなら1フレーム約33.33msで、144fpsの約6.94msより大幅に長くなりますが、毎フレーム33ms付近で安定していればフレームペーシング自体は一定です。もちろん144fpsより動きは滑らかではありませんが、33ms・33ms・33msと一定な30fpsと、15ms・50ms・20ms・48msのように大きく揺れる60fps前後のゲームでは、後者の方が不規則なカクつきを感じる場合があります。
- 33ms・33ms・33msのように一定なら、動きが速くなくても引っかかりは感じにくい
- ターン制やじっくり進める系のゲームなら実用上ほぼ気にならないことが多い
- フレームタイムの絶対値だけで「重い/軽い」を判断しない
- 15ms・50ms・20ms・48msのように振れ幅が大きいと不規則なカクつきを感じやすい
- 平均だけを見て「60fps出ているから大丈夫」と判断すると見誤る
- フレームタイムグラフが「安定しているか」を必ず確認する
役割分担平均FPS・1% Low・フレームタイムグラフの使い分け
平均FPSは、その設定やPCが全体としてどれくらい速いかを見るのに便利です。1% Lowは、平均値では見えにくい悪い側の性能をひとつの数字にまとめて比較できます。フレームタイムグラフは、具体的にいつ処理遅延が発生したのかを直接見るのに向いています。PCパーツのベンチマークを比較するなら平均FPSと1% Lowが便利で、自分のPCで発生している「一瞬だけカクつく」を調査するならフレームタイムグラフの重要度が上がります。
なお、1% Lowという指標自体にも注意点があります。CapFrameX公式ブログは、1% Lowの計算方法には「最も遅い側のフレームを単純平均する方式」と「計測時間を基準にした時間ベースの方式」など複数の定義が存在し、統一された唯一の計算方法があるわけではないと説明しています。別のツールやサイトの1% Lowを数字だけで直接比較すると、計算方法の違いが結果に含まれる可能性があります。1% Lowの詳しい計算方法の違いや、原因別の具体的な改善手順は、前述の「1% Low」の記事で解説しています。
FAQよくある質問
まとめフレームタイムグラフはカクつきの「いつ・どこで」を教えてくれる
フレームタイムとは、ゲームで次のフレームへ更新されるまでの時間です。60fpsなら約16.67ms、120fpsなら約8.33ms、144fpsなら約6.94ms、240fpsなら約4.17msが基準になります。平均FPSだけを見ると、一瞬だけ発生した長いフレームが平均へ埋もれてしまいますが、フレームタイムグラフなら低い位置で細かく安定しているか、突然大きな縦方向のスパイクが出ているかを直接確認できます。
スパイクを見つけたら、初回だけ発生するのか、一定間隔で発生するのか、GPU使用率と連動するのか、逆にGPU使用率が下がった瞬間に発生するのかというパターンを確認してください。パターンごとにキャッシュ系・バックグラウンド処理・GPU側・CPU/待機系のどれを疑うべきかが絞り込めます。さらに詳しくCPU側とGPU側のどちらで時間を使っているか調べたい場合は、PresentMonのCPU Busy、GPU Busy、GPU Waitなどの指標が手がかりになります。DLSSやFSRのフレーム生成を使用している場合は、表示FPSだけでなくFrame Typeメトリクスでベース側のフレームタイムも確認してください。
グラフの形からカテゴリを絞り込んだら、テクスチャ品質の調整、XMP/EXPOの有効化、CPU換装の判断基準といった具体的な対処法は平均fpsは高いのにカクつく原因は「1% Low」で解説しています。あわせて読み進めてください。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年7月時点の目安・変動あり
