Large Send Offload（LSO）はゲームでオフにするべき？Ping・CPU負荷・パケット処理との関係【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
Ping・CPU負荷・パケット処理との関係をMicrosoft・Intel公式資料で検証
参考：Microsoft Learn「Performance in Network Adapters」、Microsoft Learn「Windows Server でのネットワーク アダプターのパフォーマンス チューニング」、Microsoft Learn「Set-NetAdapterLso」、Microsoft Learn「Get-NetAdapterLso」、Intel「Large Send Offload (IPv4 and IPv6)」。表示される項目名・既定値はNICとドライバーの組み合わせで異なります。
目次
先に結論LSOは送信データのCPU負荷を減らす機能。無条件のオフ推奨は仕組みと噛み合わない
Large Send OffloadはTCP送信データの分割処理をNIC側へ渡し、Windows側（CPU）の負荷を減らす仕組みです。「ゲームで重いからオフにする」という説明は、この仕組みと逆方向の理屈になります。
Microsoft Learnの「Windows Server でのネットワーク アダプターのパフォーマンス チューニング」には、低遅延パケット処理を狙う構成の一例として、LSOを含む「静的オフロード」を有効にする記載があります。「ゲームだから一律オフ」という単純化とは前提が異なるため、仕組みから順番に確認していきます。
仕組みLSOはTCP送信データの分割処理をNIC側へ渡す機能
通常、Windowsのネットワークスタックは、送信するデータをMTU（Maximum Transmission Unit、一般的なイーサネットで1500バイト）に収まるサイズへ分割してからNICへ渡します。Large Send Offload（LSO）を有効にすると、Windows側はこの分割処理を省略し、TCPが確保できる最大64,000バイトまでのまとまったデータをそのままNICドライバーへ渡します。分割処理そのものはNICのハードウェアが担当します。
Microsoft Learnの「Performance in Network Adapters」でも、LSOについて「TCPのセグメント化作業はホストCPUではなくネットワークアダプター／ドライバーのハードウェアが行う」と説明されています。Intel Ethernet Adapters User GuideのLarge Send Offload項目でも、対象を「TCPメッセージをイーサネットフレームへ分割するタスク」、上限を64,000バイトと説明しており、内容は一致しています。
目的「ゲームでは重いからオフ」という説明が仕組みと逆になる理由
PowerShellのGet-NetAdapterLsoコマンドレットのMicrosoft公式説明では、LSOの効果を「高負荷な送信処理の速度を上げ、処理をネットワークアダプター側で行うためコンピューターのプロセッサー使用率を下げる」としています。Intel公式のLarge Send Offload項目にも「アダプターのハードウェアはOSのソフトウェアよりずっと速くデータの分割を完了できるため、送信性能が向上し、使用するCPUリソースも少なくなる」という説明があります。
つまりLSOをオフにすると、これまでNICが担当していたTCPデータの分割処理をWindows側のCPUが肩代わりします。大量の送信データを扱う場面ではCPU使用率が上がる方向に働くため、「オフにすれば軽くなる」という説明は、この機能が設計された目的とは逆になります。
最重要の確認Microsoft公式の低遅延構成では、LSOを含む静的オフロードの有効化を挙げている
Microsoft Learnの「Windows Server でのネットワーク アダプターのパフォーマンス チューニング」には、マイクロ秒単位の応答性を求める「低遅延パケット処理」の構成例が示されています。この中で、静的オフロードについて次のように書かれています。
「静的オフロードを有効にします。たとえば、UDP チェックサム、TCP チェックサム、Send Large Offload (LSO) の設定を有効にします。」
対象はWindows Serverのネットワークアダプター向けチューニング資料であり、Windows 11のホームユーザー向けに書かれたものではありません。ただし、LSOやTCP/IPスタックの基本的な仕組み自体はWindows ServerとWindows 11で共通しており、低遅延を重視する用途に向けてMicrosoftが自ら「LSOを有効にする」方向の構成例を示している事実は、無条件のオフ推奨とは相容れません。
同じ資料は、割り込みモデレーションについては低遅延構成で「無効にする」方向の例も挙げており、CPU時間が増える可能性があるトレードオフとして説明しています。LSOと割り込みモデレーションは役割も推奨の方向も異なるため、両方をまとめて「ネットワーク系の重い設定」として一括でオフにする判断は根拠が弱くなります。
Pingへの影響Pingが変わらない理由。回線・ISP・サーバー距離が支配的
同じMicrosoft Learnの資料では、低遅延パケット処理のチューニングについて「このチューニングによって、パケットの送信にかかる時間は短縮されません」と明記されています。低遅延チューニングが対象にしているのは、NICが受信パケットを処理してから応答を返すまでの待ち時間で、通常はマイクロ秒単位です。一方、離れたサーバーへパケットを送る伝送時間はミリ秒単位、つまり一桁大きい単位で測定されるとも説明されています。
ゲーム内のPingは、回線の種類、ISP内の経路、ゲームサーバーとの物理的な距離、混雑状況に強く左右されます。LSOはホスト側（PC内部）の処理を対象にした機能であり、PCからゲームサーバーまでの伝送経路そのものを変える設定ではないため、オン/オフの切り替えだけでPingが大きく変わるとは考えにくい機能です。
対象プロトコルLSOが対象にするのはTCP送信、多くのゲームの主要通信はUDP
Microsoft Learnの「Performance in Network Adapters」ではLSOの対象を「TCPのセグメント化作業」、Intel公式でも「TCPメッセージをイーサネットフレームへ分割するタスク」と説明しています。PowerShellのGet-NetAdapterLsoコマンドレットの説明でも「TCP/IPが大きなデータパケットをネットワークアダプタードライバーへ送る」場面が対象として書かれており、いずれもTCP通信を前提にしています。
多くのオンラインゲームでは、プレイヤーの位置情報などリアルタイム性が求められる通信にUDPを使い、パッチ配信やマッチメイキング、一部のチャット機能などにTCPを使う構成が一般的です。ゲーム内Pingとして表示される数値の多くはUDP通信を基準にしているため、TCP送信を対象にしたLSOのオン/オフは、その数値に直接作用する設定ではありません。大容量アップロードやTCPを使う通信量が多い場面ではCPU負荷の差として現れる可能性がありますが、それも「ゲームのPingが下がる」という説明とは別の話です。
設定の単位IPv4とIPv6は別設定、Jumbo Frameとは別の機能
デバイスマネージャーの詳細設定には「Large Send Offload V2（IPv4）」と「Large Send Offload V2（IPv6）」が別項目として表示されます。PowerShellのSet-NetAdapterLsoコマンドレットにも-IPv4Enabledと-IPv6Enabledという別々のパラメーターが用意されており、片方だけを変更してももう片方には影響しません。古いNICドライバーでは、V2より前のLSO（V1）に対応する-V1IPv4Enabledパラメーターが別に存在する場合もあります。
Jumbo Frameとの混同もよく見られますが、目的が異なる機能です。LSOは既存のMTU（一般的に1500バイト）の範囲内で、分割処理そのものをNICへ渡す機能です。一方Jumbo FrameはMTU自体を大きくする設定で、Microsoft Learnでは「MTUを1514から9000へ変更した際にTCPスループットが20%向上した」という計測例が示されています。ただしJumbo Frameは経路上の全区間が対応していないと機能せず、オンラインゲームでの効果はLSOとはさらに別の論点になります。詳しくはMTUやJumbo FrameとPingの関係で解説しています。
| 設定名 | 対象 | 変更方法 |
|---|---|---|
| Large Send Offload V2（IPv4） | IPv4上のTCP送信データ | デバイスマネージャーの詳細設定、またはSet-NetAdapterLso -IPv4Enabled |
| Large Send Offload V2（IPv6） | IPv6上のTCP送信データ | デバイスマネージャーの詳細設定、またはSet-NetAdapterLso -IPv6Enabled |
| Jumbo Frame（Jumbo Packet等） | MTUサイズそのもの | デバイスマネージャーの詳細設定。経路上の全区間の対応が必要 |
混同されやすい設定Interrupt Moderationとの違い。役割が異なるだけで対立する設定ではない
LSOとよく一緒に語られる設定にInterrupt Moderationがあります。Interrupt Moderationは、NICがCPUへ割り込み通知を送る頻度を調整する機能で、通知をまとめるほどCPUへの負荷は減りますが、パケットが処理されるまでの待ち時間が延びる可能性があります。対してLSOは、送信データの分割処理そのものをCPUからNICへ渡す機能です。どちらもCPU負荷とレイテンシのトレードオフを持ちますが、対象にしている処理の段階が異なります。
有線LAN接続でゲーム中だけPingが跳ねる場合の切り分け手順や、Interrupt Moderationを一段階ずつ比較する具体的な方法は有線LANでゲーム中だけPingが跳ねる原因で扱っています。LSOだけをオフにしても、Interrupt Moderationが原因のジッターは解消しません。
確認・変更方法デバイスマネージャーとPowerShellでの手順
デバイスマネージャーで確認する
Windows 11では、デバイスマネージャーを開き「ネットワーク アダプター」から使用中の有線LANまたはWi-Fiアダプターを右クリックして「プロパティ」を選びます。「詳細設定」タブに切り替えると、「Large Send Offload V2（IPv4）」「Large Send Offload V2（IPv6）」という項目が一覧に表示されます。NICとドライバーによっては、旧世代の「Large Send Offload（IPv4）」が別途表示される場合もあります。値の欄で「有効」「無効」を切り替え、「OK」で確定します。
PowerShellで確認する
管理者権限のPowerShellでは、Get-NetAdapterLsoコマンドレットで現在の状態を確認できます。
Get-NetAdapterLso -Name "イーサネット"特定のIPバージョンだけを個別に切り替えたい場合は、Set-NetAdapterLsoコマンドレットで-IPv4Enabledと-IPv6Enabledを指定します。
Set-NetAdapterLso -Name "イーサネット" -IPv4Enabled $True -IPv6Enabled $FalseIPv4・IPv6の両方をまとめて切り替えたい場合は、Enable-NetAdapterLso／Disable-NetAdapterLsoコマンドレットも使えます。
Enable-NetAdapterLso -Name "イーサネット" -IPv4 -IPv6
Disable-NetAdapterLso -Name "イーサネット" -IPv6いずれのコマンドも既定ではアダプターを再起動するため、実行直後に通信が一瞬切れます。ゲームやダウンロードを終了してから実行してください。アダプター名は環境に合わせて置き換えます。
判断の分かれ目LSOをオフにすべき具体的なケース
仕組みからみると、LSOは通常の環境で無効化する積極的な理由が見当たりません。一方で、切り分け目的で一時的にオフへ切り替える判断が妥当な場面もあります。
- 通信が安定しており、再現性のあるPing上昇やパケットロスが出ていない
- 大容量データの送受信でCPU使用率を抑えたい（LSOが本来担う役割そのもの）
- NICメーカーやWindows Updateが設定した既定値を変える具体的な理由がない
- NICドライバーが原因と疑われる不具合（特定の通信だけ失敗する、パケットが破損する等）を切り分けたいとき
- LatencyMonでndis.sysの実行時間が高いなど、DPC遅延の原因をNIC側の設定から一つずつ確認しているとき
- NICドライバーやファームウェアを更新した直後に、更新前との違いを比較したいとき
いずれの場合も、比較する設定は一つずつ変更し、変更前後でPing・パケットロス・CPU使用率を記録してください。効果が確認できなければ既定値へ戻します。
FAQLarge Send Offloadに関する質問
受信側でパケットをまとめるReceive Segment Coalescing（RSC）はLSOと向きが逆の機能で、受信ウィンドウを回線に合わせて広げるTCP Auto-Tuningも「オフにすればPingが下がる」と誤解されやすい設定です。どちらも仕組みと確認方法を別の記事で解説しています。
まとめ「LSOオフ＝FPS向上」への一般化は、仕組みの説明としては成立しない
Large Send Offloadは、TCP送信データの分割処理をNIC側へ渡すことでCPU負荷を減らす機能です。Microsoft・Intelの公式資料はいずれもCPU負荷削減を効果として説明しており、Microsoft Learnの低遅延パケット処理の構成例では、LSOを含む静的オフロードを有効にする例が挙げられています。「ゲームでは重いから一律オフ」という単純化は、この仕組みとは噛み合いません。
通信が安定している通常の環境では、既定値のまま使うことをおすすめします。NICドライバー起因の不具合を切り分けているときや、LatencyMonでDPC遅延の原因をNIC側の設定から確認しているときだけ、一時的にオフへ切り替えて比較してください。変更は一つずつ行い、他のNIC設定と同時に変えないことが、原因を正しく特定する近道です。ネットワーク設定全般の見直しはオンラインゲームのラグ改善ガイドも参照してください。
あわせて読みたい
