Checksum Offloadはゲームでオフにするべき？IPv4・IPv6・TCP・UDPチェックサムの違い【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
IPv4・IPv6・TCP・UDPチェックサムの違いをMicrosoft公式資料で検証
参考：Microsoft Learn「ハイ パフォーマンス ネットワーク」、同ページ（英語版）、Microsoft Learn「Windows Server でのネットワーク アダプターのパフォーマンス チューニング」、Microsoft Learn「Get-NetAdapterChecksumOffload」、Microsoft Learn「Set-NetAdapterChecksumOffload」、Microsoft Learn「Enable-NetAdapterChecksumOffload」、RFC 8200（IPv6仕様）、RFC 768（UDP仕様）、RFC 8085（UDP使用ガイドライン）、Wireshark Wiki「CaptureSetup/Offloading」。表示される項目名・既定値はNICとドライバーの組み合わせで異なります。
「オフロード系の設定をすべて無効にしてネットワークカードの負荷をCPUへ戻すと安定する」という趣旨の情報は、日本語の個人ブログやWikiで見かけることがあります。対象にChecksum Offloadが含まれているケースでは、この機能の役割と実際の挙動が噛み合っているか確認が必要です。
Checksum OffloadはIPv4・TCP・UDPのチェックサムの計算と検証をCPUからNIC側へ渡す機能で、チェックサムの計算そのものを省略する機能ではありません。Microsoft LearnのAddress Checksum Offloadの項目には、ワークロードや状況に関わらず常に有効にすることを推奨する記載があります。
IPv4とIPv6でチェックサムの扱いがどう違うのか、無効化がPingではなくCPU負荷に効く理由、Wiresharkで「Bad Checksum」と表示される仕組み、実際にオフを試す価値があるケースまで、公式資料の該当箇所を示しながら順番に確認します。
目次
要点先に結論
IPv4・TCP・UDPのChecksum Offloadは、チェックサムの計算・検証をNIC側のハードウェアへ渡す機能です。Microsoft Learnの「ハイ パフォーマンス ネットワーク」には、これらのオフロードについて「ワークロードや状況に関係なく、常に有効にする必要があります」という記載があり、既定でもすべて有効になっています。無効化するとCPU側の処理が増える方向に働くため、「ゲームで重いからオフにする」という説明は、この仕組みの目的とは逆になります。
ネットワークアダプターの詳細設定を一律で無効化する前に、Checksum Offloadが具体的に何をしているのか、送信・受信それぞれの処理から確認します。
仕組みChecksum Offloadは計算・検証をNICへ渡す機能
Windowsのネットワークアダプター詳細設定には、「IPv4 Checksum Offload」「TCP Checksum Offload (IPv4)」「TCP Checksum Offload (IPv6)」「UDP Checksum Offload (IPv4)」「UDP Checksum Offload (IPv6)」という5つの項目が並びます。Microsoft Learnでは、これらをまとめて「Address Checksum Offload」と呼び、IP・TCP・UDPのチェックサム計算を送信・受信の両方でNICハードウェアへオフロードする機能と説明しています。
受信側では、NICがIP・TCP・UDPヘッダー内のチェックサムを計算し、OSに対して成功・失敗・未チェックのいずれかを通知します。NICが成功と判定したパケットは、OS側で再計算せずそのまま受け取ります。NICが失敗または未チェックと判定した場合は、IP/TCP/UDPスタックが内部でチェックサムを再計算し、その結果が失敗であればパケットは破棄されます。送信側では、NICがチェックサムを計算し、必要に応じてIP・TCP・UDPヘッダーへ挿入します。
Checksum Offloadは、チェックサムの計算を省略する機能ではありません。計算する場所をCPU(Windows側)からNIC側のハードウェアへ移す機能です。無効にすると、この計算はCPU側で行われるようになります。
最重要の確認Microsoft公式は「ワークロードに関係なく常に有効化」を推奨
Microsoft Learnの「ハイ パフォーマンス ネットワーク」には、Address Checksum Offloadの管理方法を説明したあとに、次の記載があります。
「アドレス チェックサム オフロードは、ワークロードや状況に関係なく、常に有効にする必要があります。すべてのオフロード テクノロジの中で最も基本となるこの機能は、常にネットワーク パフォーマンスを向上させます。チェックサム オフロードは、Receive Side Scaling (RSS)、Receive Segment Coalescing (RSC)、および Large Send Offload (LSO) などといった、他のステートレス オフロードにも必要です。」
英語版の原文でも「Address Checksum Offloads should ALWAYS be enabled no matter what workload or circumstance.」と、より強い表現で書かれています。対象はWindows Serverのネットワークアダプター向け資料ですが、Checksum Offloadの仕組み自体はWindows 11でも共通です。「ゲームだから一律オフ」という単純化は、この記載とは逆方向になります。
同じMicrosoft Learnの「Windows Server でのネットワーク アダプターのパフォーマンス チューニング」でも、マイクロ秒単位の応答性を求める低遅延パケット処理の構成例として「静的オフロードを有効にします。たとえば、UDP チェックサム、TCP チェックサム、Send Large Offload (LSO) の設定を有効にします」という記載があり、方向性は一致しています。Large Send Offload（LSO）の検証も参照してください。
Checksum Offloadは、RSS(Receive Side Scaling)やRSC、LSOといった他のオフロード機能が動作するための前提にもなっています。RSSの切り分け手順は別記事で扱っているため、ここでは「Checksum Offloadを無効にすると、これらの機能にも影響しうる」という関係性の紹介にとどめます。
役割チェックサムはデータ破損の検出であり、暗号化ではない
チェックサムは、パケットが通信の途中で壊れていないかを確認するための検査値です。送信側がデータから計算した値をヘッダーに書き込み、受信側が同じ計算をして値が一致するかを確認します。一致しなければ、伝送中にデータが壊れたと判断してパケットを破棄します。
この仕組みが検出するのは偶発的なビット化けなどのデータ破損で、暗号化や改ざん防止のための機能ではありません。通信内容を第三者から隠したり、悪意のある書き換えを防いだりする目的では使われていません。
IPv4とIPv6IPヘッダーのチェックサムはIPv6に存在しない
IPv4のヘッダーには「Header Checksum」という専用のフィールドがあり、IPヘッダー部分だけの整合性を確認します。一方、IPv6の仕様を定めるRFC 8200のヘッダー形式には、このチェックサムに相当するフィールドがありません。RFC 8200は設計方針として「一部のIPv4ヘッダーフィールドは、パケット処理の一般的な処理コストを下げるため、削除するかオプション化した」と説明しており、IPヘッダー単体のチェックサムはIPv6で削除された項目のひとつです。
その代わりTCP・UDPのチェックサムはIPv4・IPv6のどちらにも存在し、上位層で整合性を確認します。UDPの使い方を定めるRFC 8085は、IPv6上でUDPを使う場合について「IPv6はチェックサムを持たないため、UDPチェックサムはIPv6ヘッダーとUDPヘッダー双方の破損を検出する役割を担っており、使用しなければならない(MUST)」としています。IPv4上のUDPについては「チェックサムを有効にすべき(SHOULD)」という表現で、IPv6よりやや弱い推奨になっています。
- IPヘッダー単体のチェックサムあり(Header Checksum)
- TCPチェックサムあり(必須)
- UDPチェックサム0(未使用)を許容する規定があるが、有効化が推奨(RFC 8085 SHOULD)
- IPヘッダー単体のチェックサムなし(RFC 8200でフィールド自体が存在しない)
- TCPチェックサムあり(必須)
- UDPチェックサム使用が必須(RFC 8085 MUST)
IPv6ではIPレベルの保護がない分、TCP・UDPのチェックサムがヘッダー全体の破損検出を一手に引き受けています。IPv6環境でUDP・TCPのChecksum Offloadを無効化しても、この検査自体が不要になるわけではなく、計算する場所がCPU側へ移るだけです。
既定値既定は送受信とも有効な4段階の設定
Checksum OffloadはPowerShellのSet-NetAdapterChecksumOffloadコマンドレットで見ると、各項目を「Disabled」「TxEnabled」「RxEnabled」「RxTxEnabled」の4状態のいずれかに設定できます。RxEnabledは受信方向だけ、TxEnabledは送信方向だけを有効にし、もう片方は無効になります。Enable-NetAdapterChecksumOffloadコマンドレットの説明には「既定ではすべてのチェックサムが送受信両方向で有効になっている」と明記されており、通常のPCでは送受信とも有効な状態が既定です。
無効化の影響無効にするとCPU側の処理が増える
受信側の説明のとおり、NICがチェックサムを「失敗」または「未チェック」と判定したパケットは、IP/TCP/UDPスタックが内部でチェックサムを再計算します。Checksum Offloadを無効にした場合、NICは検証自体を行わずOSへ渡すため、この再計算がすべてのパケットで発生する状態に近づきます。送信側でも同様に、無効化すればチェックサムの計算をCPU側が担うことになります。
つまりChecksum Offloadを無効にすると、これまでNICが担当していたチェックサムの計算・検証をCPUが肩代わりします。通信量が多い場面ほどCPU使用率が上がる方向に働くため、「オフにすれば軽くなる」という説明は、この機能が設計された目的とは逆になります。
なお、送信パスのChecksum Offloadだけを無効にしても、Large Send Offload(LSO)経由で送られるパケットのチェックサム計算・挿入は無効になりません。Microsoft Learnは、すべてのチェックサム計算を無効にしたい場合はLSOも合わせて無効にする必要があると説明しています。2つの設定は独立しているように見えて、実際には依存関係があります。
Pingへの影響UDP中心のゲーム通信でも、Pingを直接下げる設定ではない
多くのオンラインゲームは、プレイヤーの位置情報などリアルタイム性が求められる通信にUDPを使います。Checksum OffloadはこのUDP通信も対象に含まれますが、行っているのはチェックサムの計算・検証をどこで行うかという処理場所の変更であり、PCからゲームサーバーまでの伝送時間そのものを変える設定ではありません。
ゲーム内のPingは、回線の種類、ISP内の経路、ゲームサーバーとの物理的な距離、混雑状況に強く左右されます。Checksum Offloadの有効・無効はホスト側(PC内部)の処理を対象にした設定のため、オン/オフの切り替えだけでPingが大きく変わるとは考えにくい機能です。
よくある誤解Wiresharkで「Bad Checksum」と出るのは不具合ではない
Checksum Offloadが有効な環境でWiresharkなどのパケットキャプチャツールを使うと、自分のPCから送信したパケットのチェックサムが「Bad Checksum」「Checksum incorrect」と表示されることがあります。Wireshark公式Wikiでは、この表示について「Wiresharkはパケットがネットワークアダプターへ送られる前にキャプチャするため、まだ計算されていない値を見ることになり、正しいチェックサムを見られない」と説明しています。
Checksum Offloadが有効な場合、実際のチェックサム計算はNICのハードウェアが送信の直前に行います。Windowsのネットワークスタック内でキャプチャする位置は、その計算より手前にあるため、OSが初期化しただけの値がそのまま表示されることがあります。同じWikiは「多くのOSはこの値を初期化しないため、本来見えるはずのないメモリの断片が表示されている場合がある」とも補足しており、Wireshark 1.2以降ではこの誤表示を避けるため、チェックサム検証が既定で無効になっています。
Wiresharkで送信パケットの「Bad Checksum」表示を見て、Checksum Offloadやドライバーの不具合と誤解するケースがありますが、多くの場合はキャプチャする位置の問題です。受信したパケットのチェックサムが実際に不正な場合や、チェックサム検証を有効にしたキャプチャ環境で継続的に失敗が記録される場合は、NICドライバー側の問題を疑う根拠になります。
判断の分かれ目Checksum Offloadをオフにすべき具体的なケース
仕組みから見ると、Checksum Offloadは通常の環境で無効化する積極的な理由が見当たりません。一方で、切り分け目的で一時的にオフへ切り替える判断が妥当な場面もあります。
- 通信が安定しており、再現性のあるPing上昇やパケットロスが出ていない
- IPv6環境でUDP・TCP通信を使う(IPv6にはIPヘッダー単体のチェックサムがない分、TCP・UDPのチェックサムが重要度を増す)
- NICメーカーやWindows Updateが設定した既定値を変える具体的な理由がない
- 特定のNICドライバーが原因と疑われる不具合(受信パケットのチェックサムが実際に不正と記録される等)を切り分けたいとき
- VPNクライアントやブリッジ接続を経由すると通信が不安定になり、Checksum Offloadとの相性を切り分けたいとき
- LatencyMonでndis.sysの実行時間が高いなど、DPC遅延の原因をNIC側の設定から一つずつ確認しているとき
いずれの場合も、比較する設定は一つずつ変更し、変更前後でPing・パケットロス・CPU使用率を記録してください。効果が確認できなければ既定値へ戻します。
確認・変更方法デバイスマネージャーとPowerShellでの手順
デバイスマネージャーで確認する
Windows 11では、デバイスマネージャーを開き「ネットワーク アダプター」から使用中の有線LANまたはWi-Fiアダプターを右クリックして「プロパティ」を選びます。「詳細設定」タブに切り替えると、「IPv4 Checksum Offload」「TCP Checksum Offload (IPv4)」「TCP Checksum Offload (IPv6)」「UDP Checksum Offload (IPv4)」「UDP Checksum Offload (IPv6)」の5項目が一覧に表示されます。値の欄で無効・送信のみ有効・受信のみ有効・送受信で有効を切り替え、「OK」で確定します。
PowerShellで確認する
管理者権限のPowerShellでは、Get-NetAdapterChecksumOffloadコマンドレットで現在の状態を確認できます。
Get-NetAdapterChecksumOffload -Name "イーサネット"特定の項目だけを個別に切り替えたい場合は、Set-NetAdapterChecksumOffloadコマンドレットで対象を指定します。値にはDisabled・TxEnabled・RxEnabled・RxTxEnabledのいずれかを使います。
Set-NetAdapterChecksumOffload -Name "イーサネット" -IpIPv4Enabled RxTxEnabled -UdpIPv4Enabled RxTxEnabled -TcpIPv4Enabled RxTxEnabledすべての項目をまとめて有効・無効にしたい場合は、Enable-NetAdapterChecksumOffload／Disable-NetAdapterChecksumOffloadコマンドレットも使えます。
Enable-NetAdapterChecksumOffload -Name "イーサネット" -IpIPv4 -TcpIPv4 -TcpIPv6 -UdpIPv4 -UdpIPv6
Disable-NetAdapterChecksumOffload -Name "イーサネット" -UdpIPv4いずれのコマンドも既定ではアダプターを再起動するため、実行直後に通信が一瞬切れます。ゲームやダウンロードを終了してから実行してください。アダプター名は環境に合わせて置き換えます。
他の設定との対比「NIC設定は全部Disabledが正解」ではない
ネットワークアダプターの詳細設定には、Checksum Offload以外にもCPU負荷とレイテンシのトレードオフを持つ項目が並びます。それぞれ役割が異なるため、一括で無効化する判断は根拠が弱くなります。
- Checksum Offload チェックサムの計算・検証をNICへ渡す機能。Microsoft公式は常時有効化を推奨しています。
- LSO(Large Send Offload) TCP送信データの分割処理をNICへ渡す機能。詳しくはLSOの検証記事で解説しています。
- RSS(Receive Side Scaling) 受信処理を複数のCPUコアへ分散する機能。切り分け手順は有線LANでPingが跳ねる原因で扱っています。
- Interrupt Moderation NICがCPUへ割り込みを送る頻度を調整する機能。オフ固定ではなく段階的な比較が安全です。
- EEE(Energy Efficient Ethernet) 省電力のためリンク速度を落とす機能。低負荷時にPingが不安定になる原因になることがあります。
- Flow Control 受信側の処理が追いつかないときに送信側へ一時停止を要求する機能。
Checksum Offloadは、このうちMicrosoft公式が明確に「常時有効」を推奨している数少ない項目です。他の設定を見直す際は、Interrupt Moderation・EEE・RSSの切り分け手順を一つずつ試してください。ネットワークアダプター以外にも、HPETやbcdeditのuseplatformclockのように、単純な有効・無効の二択ではない設定があります。
FAQChecksum Offloadに関する質問
まとめ「ゲームでは一律オフ」は、公式資料の推奨と逆になる
Checksum Offloadは、IPv4・TCP・UDPのチェックサムの計算・検証をNIC側へ渡す機能です。Microsoft Learnには「ワークロードや状況に関係なく、常に有効にする必要がある」という記載があり、既定でも送受信とも有効になっています。無効化すればCPU側の処理が増える方向に働くため、「ゲームで重いから一律オフ」という説明は、この記載とは逆方向になります。
通信が安定している通常の環境では、既定値のまま使うことをおすすめします。NICドライバー起因の不具合やVPN・ブリッジとの相性を切り分けているときだけ、一時的にオフへ切り替えて比較してください。IPv6環境ではIPヘッダー単体のチェックサムが存在しない分、TCP・UDPのチェックサムの役割がより大きくなる点も踏まえて判断してください。
あわせて読みたい
