グラボのPCIe訂正済みエラーはベンチスコア・寿命に影響するか｜AERのCorrected Errorの実害を解説【2026年版】

出典：Microsoft公式「Hardware Errors and Error Sources」「Introduction to the Windows Hardware Error Architecture」、Linuxカーネル公式ドキュメント「The PCI Express Advanced Error Reporting Driver Guide HOWTO」、NVIDIA公式DCGM(Data Center GPU Manager)ドキュメント「Health Monitoring」「Field Identifiers」「DCGM Diagnostics」

イベントビューアーを開くと、WHEA-LoggerのソースでイベントID17が繰り返し記録されている。GPUのPCI Express Root Portで検出された訂正済みエラーだと分かっても、それが原因でベンチマークのスコアが以前より落ちているのではないか、グラフィックボード自体の寿命が縮んでいるのではないかという不安は残ります。

結論から整理すると、PCI ExpressのAER(Advanced Error Reporting)が検出する訂正済みエラーは、規格上「エラーが発生したがハードウェア側のリトライによって通信が正常に完了した」状態を指します。単発の訂正済みエラーがベンチマークの数値として体感できるレベルの遅延を生むことは考えにくく、GPUチップやVRAMの物理的な劣化を直接示す指標でもありません。ただし、頻度が明らかに増えている場合や、Uncorrected(未訂正)・Fatal(致命的)へ悪化している場合は話が変わります。この記事では、その線引きをどう確認するかまで含めて整理します。

WHEA-LoggerのイベントID自体の意味や、CPU・メモリ・PCIe・GPUへの切り分け方はWHEA-Logger 17・18・19の原因と直し方の記事で、Corrected・Uncorrectedごとの危険度の判断基準はWHEA-Loggerの危険度早見表の記事でそれぞれ幅広く扱っています。本記事はそのどちらでもなく、「訂正済みエラーが記録されること自体が、実際のベンチマークスコアやGPUの寿命にどれだけの実害を与えるのか」という一点に絞って深掘りします。

整理PCIeの訂正済みエラーが記録されること自体は、フリーズや故障とは別の話です

まず言葉の整理をしておきます。WHEA-LoggerのイベントID17は、Error Source欄が「Advanced Error Reporting (PCI Express)」、Error Type欄が「Corrected」となっているケースが該当します。Microsoft公式のWHEAドキュメントでは、訂正済みエラー(Corrected error)を「OSに通知される時点までに、ハードウェアまたはファームウェアによって訂正済みのハードウェアエラー状態」と定義しています。これに対して未訂正エラー(Uncorrected error)は、致命的(Fatal)か非致命的(Nonfatal)かにさらに分類される、より重い扱いのエラーです。

つまり、イベントID17が記録されているという事実だけでは、GPUやマザーボードが壊れかけているとは言えません。すでに訂正され、通信自体は完了しているからです。とはいえ「訂正されているなら気にしなくていい」と単純化するのも早計です。訂正という処理には仕組み上の裏付けがあり、その仕組みがどこまでの負荷に耐えられるように設計されているのかを知っておくことが、ベンチスコアや寿命への影響を判断する材料になります。次の章で、この訂正の仕組み自体を確認します。

仕組み訂正済みエラーは、PCIeの自動リトライ機構でその場で解決しています

PCI Expressは、Data Link Layer(データリンク層)という階層で、送受信するTLP(Transaction Layer Packet)ごとにCRCによる誤り検出とACK/NAKによる確認応答を行っています。送信側は送出したTLPをリトライバッファに保持しておき、受信側からNAK(再送要求)を受け取った場合や、一定時間内にACK(受信確認)が返ってこなかった場合に、保持していたTLPをそのまま再送信します。この再送(リプレイ)によって、途中で壊れた、あるいは届かなかったデータが正しく相手に届いた時点で、そのTLPは正常に完了したことになります。

Linuxカーネル公式ドキュメントのPCI Express AERドライバーガイドには、訂正済みエラーの扱いについて次のように明記されています。「Correctable errors pose no impacts on the functionality of the interface(訂正済みエラーはインターフェースの機能に影響を与えない)」。さらに、ソフトウェア側の対応についても「These errors do not require any recovery actions. The AER driver clears the device’s correctable error status register accordingly and logs these errors(これらのエラーは回復処理を必要としない。AERドライバーは該当デバイスの訂正済みエラーステータスレジスタをクリアし、エラーを記録するだけでよい)」とされています。

重要なのは、この一連のリトライ処理がData Link Layerというハードウェアに近い層だけで完結し、Windows本体やGPUドライバー、ましてやゲームエンジンやベンチマークソフトが関与するより上の層には、原則として影響が及ばないという点です。訂正済みエラーがイベントビューアーに記録されるのは、WHEAがハードウェアからこの訂正処理の発生を通知として受け取り、ログに残しているためであり、記録されること自体はリトライが正常に機能した証拠でもあります。

理論値1回の訂正でどれくらいの遅延が生じるのか、規模感を整理します

訂正済みエラーがベンチマークスコアに影響するかを考えるうえで、まず押さえておきたいのは時間の桁が大きく異なるという点です。PCIeのリトライは、リンク幅や転送速度に応じて規定されたリプレイタイマーの上限値にもとづいて動作し、実際の再送処理はナノ秒からマイクロ秒の単位で完了します。これに対して、ゲームの1フレームにかけられる時間は、60fpsで約16.6ミリ秒、144fpsでも約6.9ミリ秒あります。単発の訂正済みエラーによるリトライは、この1フレームの時間に対してはるかに小さい規模で終わる処理であり、フレームレートの数値として表れるほどの遅延にはなりにくいというのが、規格上の仕組みから導かれる整理です。

この「単発なら問題にならない」という考え方は、NVIDIA自身の公式ドキュメントでも裏付けられます。NVIDIAがデータセンター向けGPUの運用管理に提供しているDCGM(Data Center GPU Manager)には、GPUごとのPCIeリプレイ回数を追跡する項目(DCGM_FI_DEV_PCIE_REPLAY_COUNTER)があり、健全性監視の機能では「1分間に8回を超えるPCIeリプレイを検出した場合」に初めて警告(warning)として扱うとされています。診断テストの基準でも、PCIe Gen 3.0の正常なリンクで想定されるリプレイ発生率を1分あたり8回未満とした上で、その10倍にあたる80回、より負荷の高いテストでは160回に達するまでは許容範囲として扱われています。DCGMはコンシューマー向けのGeForceには提供されていないツールですが、同じPCIeコントローラーの仕組みにもとづく指標である以上、NVIDIA自身が「一定の頻度を超えて初めて注意が必要になる」という基準を公式に設けている事実は、訂正済みエラーの捉え方の参考になります。

逆に言えば、性能への実害が測定できるレベルで出てくるとしたら、それは訂正済みエラーが単発ではなく高頻度で繰り返され、リトライの発生自体がリンクの実効帯域を圧迫している状態か、あるいは訂正で済まなくなり、Uncorrected(未訂正)やリンクの再訓練(Link Training)を伴う障害へ悪化している状態のどちらかが伴っている必要があります。次の章で、その頻度をどう確認するかを整理します。

確認手順問題は回数そのものではなく、増加傾向にあるかどうかです

イベントビューアーを開いてイベントID17がいくつ記録されているかを数えるだけでは、それが正常な範囲なのか、異常に増えているのかは判断できません。確認すべきは、日を追うごとに発生件数が増えているかどうかという傾向です。PowerShellを使えば、直近の記録を日付ごとに集計し、推移を一覧で確認できます。

Get-WinEvent -FilterHashtable @{
  LogName      = 'System'
  ProviderName = 'Microsoft-Windows-WHEA-Logger'
  Id           = 17
  StartTime    = (Get-Date).AddDays(-14)
} -ErrorAction SilentlyContinue |
  Group-Object { $_.TimeCreated.ToString("yyyy-MM-dd") } |
  Select-Object Name, Count |
  Sort-Object Name |
  Format-Table -AutoSize

このコマンドを1週間おきなど定期的に実行し、日別の件数が横ばいか、明らかに右肩上がりになっているかを見てください。件数が数日単位でほぼ一定なら、環境として安定していると判断できます。反対に、特定の日を境に急増している場合は、その前後で何を変更したか(BIOS更新、Resizable BARの有効化、電源ケーブルの取り回し変更、GPUの挿し直しなど)を思い出し、直近で公開している関連記事の切り分け手順を確認してください。Resizable BAR有効化後にWHEA-Loggerが増える原因の記事とPCI Expressのリンク状態の電源管理はオフにすべきかの記事は、いずれも頻度が増える代表的な原因として扱っています。

切り分け実際にベンチスコアが落ちている場合は、別の原因を疑ったほうが早く解決します

「訂正済みエラーは通常は無害」という整理を踏まえたうえで、それでも同じ設定・同じゲームでベンチマークスコアが以前より明確に落ちているなら、原因は訂正済みエラーそのものではなく、それと同時に起きている別の現象である可能性が高いといえます。優先して確認すべき候補は次の3つです。

この3つを確認してもリンク速度・幅に問題がなく、電源電圧も安定しており、Uncorrected・Fatalの記録もないのにベンチスコアだけが落ちているという状況は、実際にはかなり稀です。多くの場合、体感していたスコア低下は、ドライバーのバージョン差やゲーム側のアップデート、あるいは実行ごとの誤差の範囲であることも珍しくありません。

劣化指標GPUの寿命を判断する指標は、訂正済みエラーの回数とは別にあります

PCIeの訂正済みエラーが検出しているのは、GPUとマザーボードの間を結ぶPCIeリンクの信号品質です。接点の微細な酸化や汚れ、スロットへの挿し込みの甘さ、ケースの振動、あるいはASPM(リンク状態の電源管理)による電力状態の切り替えのタイミングなど、リンクという「通信経路」側の要因によって発生します。これはGPUチップやVRAMチップそのものが物理的に劣化していることを示す指標ではありません。AERが監視しているのはあくまでリンクの通信品質であり、GPU本体の摩耗や劣化を直接診断する仕組みではないということです。

GPUの実際の劣化や寿命に近い指標として一般的に参照されているのは、まったく別の項目です。具体的には、GPUコア温度とHot Spot(ホットスポット)温度の履歴、VRAM(メモリジャンクション)温度、ファンの累積稼働時間や回転数カーブの変化、高負荷時の電圧の安定性といった項目で、HWiNFOなどのモニタリングソフトでログを取りながら継続的に確認するのが実務的な方法です。訂正済みエラーの件数を寿命の代理指標として扱うのではなく、これらの温度・稼働時間系の指標を別途確認してください。

なお、NVMe SSDのSMART情報にも「Media and Data Integrity Errors」という似た響きの項目がありますが、これはPCIeのAERとは異なるNVMe規格独自の仕組みで、フラッシュメモリ側のデータ整合性を扱うものです。同じ「訂正済み」という言葉でも中身が異なるため、混同して判断しないよう注意してください。詳しい意味と交換判断の基準はNVMe SSDのMedia and Data Integrity Errorsとはの記事で扱っています。

訂正済みエラーがUncorrected(未訂正)やFatal(致命的)へ悪化するケースがあるのも事実です。その場合の危険度の見分け方や、緊急度に応じた対処の優先順位はWHEA-Loggerの危険度早見表の記事で詳しく整理しているので、頻度の増加とあわせてそちらも確認してください。

結論様子見でいいか、確認が必要かを判断します

どちらのケースでも、訂正済みエラーが記録されているという事実そのものを恐れる必要はありません。見るべきは件数の推移と、ベンチスコア・リンク速度・電圧・イベントの重大度という、訂正済みエラーとは別の指標です。これらに異常が見当たらないなら、GPUの寿命やベンチスコアへの実害はないと判断してよい状況です。

Q&Aよくある質問

まとめ訂正済みエラーの記録そのものより、頻度の変化とほかの指標を見てください

あわせて読みたい

トラブル・設定

WHEA-Logger 17・18・19の原因と直し方｜CPU・メモリ・PCIe・GPUをイベントログで切り分ける【2026年版】

トラブル・設定

WHEA-Loggerのエラーは無視しても大丈夫か｜Corrected・Uncorrectedで変わる危険度早見表【2026年版】

トラブル・設定

グラボがPCIe x16ではなくx8・x4で動作する原因｜GPU-Zでの確認方法・M.2共有・x16へ戻す手順【2026年版】

トラブル・設定

グラボが一瞬消えて復帰する・ブラックアウトする原因｜PCIeリンクダウンとLink Training失敗の直し方【2026年版】