高いフレームレートでもカクつくのはなぜか

ゲームの表示は毎秒90フレームを超えているのに、視点を変えたり新しいエリアに入ったりすると、一瞬止まることがあります。平均FPSが役に立たなくなったわけではありません。平均FPSが答えるのは「その時間内に何枚のフレームが生成されたか」という大まかな問いです。一定の間隔で届いているかを知るには、各フレームの時間を見る必要があります。

まずフレームタイムを調べ、それから追加で測定すべき項目を決めます。単一のボトルネック率や、一度のGPU使用率の低下だけでは、交換すべき部品は判断できません。

良好な平均値の裏に長いフレームが隠れる

理想的に均等な出力なら、フレーム間隔のミリ秒値はおよそ1,000 ÷ FPSです。60 FPSなら約16.67 ms、120 FPSなら約8.33 msになります。これは時間の換算であり、PCの実測ベンチマークではありません。

100フレームの記録を仮定します。99フレームが各10 ms、残る1フレームが100 msなら、合計時間は99 × 10 + 100 = 1,090 msです。総フレーム数を総時間で割ると約91.74 FPSになります。平均値は悪くありませんが、一度だけ大きな待ち時間があります。

図：仮想データによるフレームタイムの計算と確認手順。ゲームの実測画面ではありません。

各フレームの瞬間FPSを算術平均した値も、総フレーム数を総時間で割った値とは異なります。測定区間、ロード画面を含めるかどうか、ツールの統計上の定義によっても、最終的な数値は変わります。

遅いフレームが時間全体のどれだけを占めるかも役立ちます。仮に60秒の記録に100 msのフレームが6枚あると、それだけで0.6秒、区間全体の1%を占めます。これも仮想計算ですが、パーセンタイルでは見落とすことのある、まれな停止を把握できます。

図：仮想の100フレーム。横軸はフレーム番号であり、等間隔の時間軸ではありません。50番目が100 ms、ほかの99枚はそれぞれ10 msです。

何をフレームとして記録したのかを確認する

NVIDIAのFrameView公式ページでは、フレームレート、フレームタイム、消費電力の測定とログ保存が紹介されています。[1] ログは問題発生前後のデータを残せますが、記録ツールだけで「CPUがボトルネックだ」と証明することはできません。

結果を比べる前に、レンダリングされたフレームと表示されたフレーム、フレーム生成、垂直同期、FPS上限を確認してください。生成フレームと元のレンダリングフレームを混ぜると、入力応答が同じ割合で改善しなくても数値は上がる可能性があります。表示経路の問題がレンダリングのログに現れないこともあるため、滑らかなログだけですべての見た目のカクつきを否定することはできません。

「1% low」は低速側のフレーム性能を見るのに役立ちますが、計算方法はソフトウェアによって異なります。値と一緒にツール名、バージョン、指標の定義、記録時間を残してください。最も遅い1枚のフレームと同一視したり、異なるツールの値を混ぜて順位を付けたりしないようにします。

CapFrameXは、フレームを順位付けしたパーセンタイルと経過時間を明確に区別しています。[3] 少数の遅いフレームが長い時間を占めることがあるため、「99%のフレームが基準内」をそのまま「プレイ時間の99%が滑らか」とは言えません。また、パーセンタイル値と最も遅い一定割合の集計値も区別しています。報告が計算方法を示さず「1% low」とだけ記しているなら、その制約を残して扱います。

ログのどの項目を一緒に読むか

CSVを開いたら、まず列名を確認します。PresentMonのコンソール版ドキュメントは以下の項目を定義しています。実際の出力はバージョンとキャプチャ設定によって異なります。[2]

これらの項目は異なる区間を表しており、CPUとGPUの作業は重なる場合があります。列を単純に足して、フレーム全体の時間と一致するはずだと考えないでください。MsGPUBusyはタスクマネージャーのGPU使用率ではありません。比較できる数値かどうかは、定義を読んで判断します。

提出間隔が伸び、GPUの実作業時間も大きく増えていれば、描画処理を調べる価値があります。GPUの作業は短いのに待ち時間が長ければ、FPS上限、CPUからの処理供給、スケジューリングなどが関係する可能性があります。後者は調査範囲を狭める手掛かりであり、CPU性能不足の確定ではありません。プロジェクトはAPIやハードウェアスケジューリングによる制約も記載しています。欠測や制約のある項目を無理に補わないでください。[4]

再現できる短いルートで証拠を残す

繰り返し走れるルートを選び、解像度、画質設定、カメラの動かし方、FPS上限を固定します。元の設定を保存してから記録を開始し、終了後の出力を残します。後で比較できるよう、ファイルにはゲームのバージョン、グラフィックドライバー、シーン、設定を記します。

スパイクごとに、初めて入ったときか、急に視点を回したときか、バックグラウンドソフトが起動したときか、同じ地点を通るたびかを記録します。取得できたCPU、GPU、メモリ、ストレージの指標を合わせて見ます。取得していないセンサー値をゼロで埋めてはいけません。

まず3回繰り返し、すべての結果を保存します。差が大きい場合は、測定を長くしたり回数を増やしたりする前に、シーン、温度、キャッシュ、バックグラウンド処理を確認します。最良の1回だけを残すと、説明すべきばらつきを消してしまいます。

以下は記録を始めるための例です。60秒と3回という設定は例示であり、すべてのゲームに十分だと保証するものではありません。

コールドスタートと既に訪れたシーンは分けて比較します。初回ロード時のカクつきは独立した記録に値します。継続的な描画負荷を見るなら、一方を初回ロード、もう一方をウォームアップ後のデータにしないでください。

PresentMonでは、プロセス名による対象選択、記録時間の指定、出力CSVの指定ができます。[2] GUIでもコマンドラインでも対象プロセスを確認し、ランチャーとゲームのフレームを混ぜないようにします。この記事では実際のゲームキャプチャは行っていません。画像は指標の説明用です。

一度に変える条件は1つだけ

描画負荷が疑わしいなら、具体的な描画設定を1つ下げて同じルートを繰り返します。バックグラウンド処理が疑わしいなら、特定のプログラムを1つ閉じて再測定します。ドライバー、画質、FPS上限を同時に変えてゲームを再起動すると、何が改善に効いたのか分からなくなります。

画質を下げて平均FPSが上がっても、同じ地点のスパイクが残るなら、平均的な描画負荷とその停止は別の問題かもしれません。初回だけ強く、後で軽くなるカクつきにはアセット読み込みやキャッシュが関係する可能性がありますが、その傾向だけでは原因を特定できません。低いGPU使用率は、上限設定、CPU待ち、その他の制約を反映する場合があり、直ちにGPUの性能不足を意味するわけではありません。

「PCに30%のボトルネックがある」ではなく、「3回ともエリア進入時にスパイクがあり、影を下げても消えなかった」のように、条件付きの結論を保存します。次はその地点と影の設定差を調べられ、再び推測だけから始めずに済みます。

参考資料

1. NVIDIA FrameView公式ページ。フレームレート、フレームタイム、ログ機能の根拠。実測の実施、全GPUで同じ電力項目が得られること、ソフトのインストール済み状態を示すものではありません。

2. PresentMon Console Applicationドキュメント。2026-09-27にmainブランチを確認。CSV項目、対象プロセス、記録時間を定義しています。項目はバージョンで異なり、ローカルでの実測を意味しません。

3. CapFrameX: Explanation of different performance metrics。Taxxor、2020-05-31。パーセンタイルとx% lowを解説。指標の概念に使用しており、現行UIのスクリーンショットではありません。

4. PresentMonプロジェクトのドキュメントと制約。2026-09-27確認。APIやハードウェアスケジューリングは測定に影響し得ます。直接ボトルネックを断定せず、環境を記録します。