Intel PresentMon 2.6公開｜CPU負荷78%削減、PSOコンパイル計測でシェーダースタッター特定へ【2026年9月】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
CPU負荷78%削減、PSOコンパイル計測でシェーダースタッター特定へ
出典（確認日2026年9月26日）：GameTechDev/PresentMon「Release v2.6.0」公式リリースノート／Intel公式「PresentMon」製品ページ／GameTechDev/PresentMon Issue #659にもとづきます。
Intelがゲーム性能計測ツール「PresentMon」の最新版、2.6.0を2026年9月21日に公開しました。リリースノートには「負荷時のCPU使用量を78%削減」という数字が並んでいます。
「CPU使用率が78%削減」と聞くと、ゲームのCPU負荷が軽くなったように見えます。しかしこれは誤解です。軽くなったのはゲームではなく、性能を測定しているPresentMon自身の処理負荷です。ゲームのfpsが78%改善するという意味ではありません。
今回のアップデートでもう一つ見逃せないのが、DirectX 12のPipeline State Object（PSO）コンパイルをフレーム単位で記録する新機能です。「なぜこの瞬間だけカクついたのか」という原因調査に、新しい手がかりが加わります。PresentMon 2.6で何が変わり、何は変わっていないのかを整理します。
目次
要点先に結論だけ押さえる
CPU負荷「78%削減」の意味には注意が必要
PresentMonはWindows上でゲームや3Dアプリケーションのフレーム表示を解析するオープンソースの計測ツールです。Intelが開発していますが、Intel Arc専用のツールではありません。Intel公式もPresentMonを、GPU BusyをはじめとするCPU・GPU間のボトルネック分析、リアルタイムグラフ、パーセンタイル表示、CSVキャプチャに対応したオーバーレイ・テレメトリアプリケーションとして公開しています。
今回もっとも目を引く数字が「78%」です。GitHub公式のリリースノートでは、負荷時のPresentMonサービスのCPU使用量を78%削減したと説明されています。重要なのは、これがゲーム側のCPU使用量ではないという点です。たとえばゲームがCPUを50%使用していたとして、PresentMon 2.6へ更新すれば11%になる、という意味ではありません。PresentMonサービス自身がETWイベントやGPUテレメトリを取得する際に消費するCPU時間が減ったという話です。「PresentMon 2.6にするとゲームのfpsが78%上がる」「CPUボトルネックが78%改善する」という解釈は明確な誤りです。
なぜPresentMon自身のCPU負荷を減らす必要があるのでしょうか。性能を計測するソフト自体も、当然CPUやGPUを使用します。CPUに十分な余裕がある60fps環境ならほとんど問題になりませんが、1080pの低画質設定で300fps以上を狙うCPUベンチマークや、消費電力枠が限られたノートPCでは、計測ソフトによる処理そのものがノイズになりえます。リリースノートによると、ETWのフラッシュなど厳密なタイミングが不要な待機処理を、高精度タイマーから粗いSleepベースの待機へ変更したことに加え、PresentMonが何も追跡していないアイドル時には診断ログのフラッシュ自体を抑制することで、この削減を実現したとされています。PresentMonがゲームを高速化したのではなく、ゲームを測定するためにPresentMon自身が加える負荷を小さくした、と捉えるのが正確です。
新機能本命はDirectX 12のPSOコンパイル計測かもしれない
個人的に78%という数字より注目したいのが、PSOコンパイル計測です。PresentMon 2.6では、DirectX 12のPipeline State Object作成をETW経由で追跡できるようになりました。公式リリースノートでは、PSOコンパイルについて回数・所要時間・Busy率を計測し、フレームおよびCSVキャプチャへ割り当てると説明されています。これは、ETWのMicrosoft-Windows-Direct3D12プロバイダーが公開するPSO作成の開始・終了イベントを直接追跡する実装だと考えられます。つまり、「この瞬間にゲームがカクついた」というフレームタイムのスパイクだけでなく、その瞬間にPSOコンパイルが走っていたのかまで、同じ時間軸で確認しやすくなったということです。
PSOとは何か
DirectX 12では、シェーダーやラスタライザー、ブレンド、深度・ステンシルといった描画に必要な状態をまとめてPipeline State Objectとして管理します。ゲームプレイ中に初めて必要になったPSOの組み合わせは、その場で作成しなければなりません。これがDirectX 12タイトルで「初めてエフェクトを見た瞬間だけ止まる」「新しいエリアへ入った瞬間だけ引っかかる」といった症状につながることがあります。
これは理論上だけの問題ではありません。Epic GamesもUnreal Engine公式ドキュメントで、シェーダーのコンパイルが処理スパイクを生み、一時的なフレームレートのヒッチにつながると説明しています。その対策がUE5.2以降で導入された「PSO Precaching」で、実際に描画するときに初めてPSOを作るのではなく、必要になりそうなPSOを事前に収集してバックグラウンドでコンパイルする仕組みです。ただしPrecachingを使っていても、必要になるタイミングまでにコンパイルが間に合わないケースは残ります。Unreal Engine自身、ランタイムのPSO作成が既定で20ミリ秒を超えた場合を「ヒッチ」として検出・記録する仕組みを持っており、事前収集の網から漏れたPSOが必要になった瞬間には、従来どおりのランタイムヒッチが発生します。「PSOコンパイルとカクつき」は、ユーザーが想像で結び付けているものではなく、ゲームエンジン側でも明確に対策されている既知の問題です。
限界PSOが動いた＝原因、とは限らない
ここには注意点もあります。PresentMonが同じ時間帯にPSOコンパイルを検出したからといって、そのPSOだけがフレームタイムスパイクの全原因だったとは限りません。新しいエリアへ入った瞬間なら、CPU側のワールド生成・AI処理・テクスチャストリーミングなど複数の処理が同時に増えることもあります。PresentMon 2.6で分かるのは「このフレーム付近でDirectX 12のPSO作成処理が発生していた」という事実であり、フレームタイム・CPU Busy・GPU Busy・ストレージ・VRAMなどと組み合わせて判断する必要があります。
もう一つ重要なのが対応範囲です。PresentMon自体はDirectX以外のグラフィックスAPIも扱えるツールですが、今回追加されたPSOコンパイル追跡はDirectX 12のイベントを利用しています。したがって、VulkanゲームやDirectX 11ゲームで発生するシェーダーコンパイルまで検出できる万能な仕組みではありません。「PresentMon 2.6ならシェーダースタッターを完全に特定できる」という表現は避けた方がよく、正確には「DirectX 12タイトルでPSO作成処理とフレームタイムスパイクの時間的な関係を確認できるようになった」機能です。
使い方PSOスタッターを調べるなら「1周目と2周目」を比較する
PresentMon 2.6を使ってPSOスタッターを確認するなら、漫然と計測するより再現条件をそろえる方が重要です。新しいエリアへ入る、初めて特定の敵と戦う、初めて特定のエフェクトを表示するといった場面を決め、1回目のプレイをCSVへ記録します。そこでフレームタイムスパイクとPSOコンパイルが同じ時間帯に発生しているか確認します。その後、同じルートでもう一度プレイし、2回目ではPSOがキャッシュされて同じ場所のPSOコンパイルとフレームタイムスパイクが両方消えるかを見ます。両方消えるのであれば、PSOが関係していた可能性はかなり高まります。逆にPSOコンパイルが記録されていないのに毎回同じ場所でカクつく場合は、アセットストリーミング・CPU側のゲームロジック・ストレージアクセス・VRAM不足など別の原因を疑うべきです。フレームタイムグラフの基本的な読み方はフレームタイムグラフの読み方の記事、症状別の対処はシェーダーコンパイル・スタッタリング対処完全ガイドで解説しています。
その他の変更オーバーレイ・複数GPU・AMD VRAM取得も改善
PresentMon 2.6では「Game Experience」という新しいオーバーレイプリセットも追加されました。Intelはこのプリセットについて、ユーザーが感じるモーションやアニメーション品質と相関する指標を強調表示する構成と説明しています。ゲームを最適化する機能ではなく、多数ある計測項目の中からゲーム体験を見るのに適した情報をまとめたプリセットと考えるのが正確です。
テレメトリ表示についても、指標ごとに取得元のGPUを選べるようになりました。内蔵GPUとディスクリートGPUの両方を搭載する構成でも、それぞれのデバイスから必要な情報を選んで同じオーバーレイへ表示できます。IntelとAMDの内蔵GPUについても、デバイス一覧でディスクリートGPUより下へ正しく並ぶよう検出・並び順が改善されました。さらにAMDのADLを利用した専用VRAM使用量の取得も改善され、IntelはWindows側で報告される値と照合して動作を検証したとしています。PresentMonという名前からIntel GPU中心のツールと思われがちですが、AMD・NVIDIAのAPIからもテレメトリを取得する構造になっており、GeForceやRadeon環境でも今回のアップデートを確認する価値があります。
注意点78%軽くなっても「計測負荷ゼロ」ではない
PresentMon 2.6でCPU負荷が大きく減ったとしても、計測ソフトの影響が完全になくなったわけではありません。GameTechDev/PresentMonのGitHubには、「オーバーレイを有効にするとG-SYNC・VRRが正常に動作しない」というユーザー報告が2026年6月30日に投稿されており、2026年9月26日時点でもIssueはOpenのままです。同種の報告は2026年9月23日にも新たに投稿されています。すべての環境で発生すると確認された不具合ではありませんが、VRRを含めた厳密なベンチマークでは注意したい情報です。レビューや厳密な性能測定でPresentMonを使う場合、常に豪華なオーバーレイを表示する必要はありません。リアルタイム表示は原因調査には便利ですが、ベンチマーク結果を取るだけなら必要な指標だけに絞り、CSVキャプチャを中心に使う方が計測側の影響を小さくできます。
FAQよくある質問
総括まとめ｜カクつき調査の道具として一歩踏み込んだ
Intel PresentMon 2.6.0では、PresentMonサービスの負荷時CPU使用量が78%削減されました。ただし、これはゲームのCPU負荷やfpsが改善するという意味ではなく、性能を測定するPresentMon自身を軽量化した変更です。それ以上に注目したいのが、DirectX 12のPipeline State Objectコンパイルをフレーム・CSVへ関連付けられるようになった点で、フレームタイムが跳ねた瞬間にPSO作成が発生していたのかを確認できるようになりました。
すべてのシェーダースタッターを特定できる万能機能ではなく、対応はDirectX 12限定、PSOコンパイルとの時間的な一致だけで原因を断定することもできません。それでも、「初回だけカクつくからシェーダーかもしれない」という推測から、実際のPSO作成イベントを含めて判断できるようになった意味は大きいといえます。オーバーレイ表示時にVRRが正常に動作しないという未解決の報告もあるため、厳密な計測ではCSVキャプチャを中心に使うことをおすすめします。
あわせて読みたい
