Pingスパイクの原因と対策｜pingとpathpingで自宅かISPかを切り分ける手順

ふだんは20msで安定しているのに、対戦中に数百msへ跳ね上がって数秒で戻る。この一過性の遅延がPingスパイクです。平均Pingが悪いわけではないので回線速度の測定サイトでは異常が出ず、原因の場所を特定しないまま「ルーターを買い替える」「ゲーミングVPNを入れる」と対処を重ねて外し続ける人が多い。この記事では、Windows標準のpingとpathping、そしてMTU起因を疑うときのping -f -lで、スパイクの発生箇所を宅内・最終マイル・中継網のどこかに切り分ける手順をまとめます。あわせて、ネットで定番になっている対処法（位置情報サービスのオフ、Nagle無効化、受信ウィンドウ自動チューニングの無効化など）が公式ドキュメント上で裏付けを持つのかも判定しました。

まとめ：先に結論

• Pingスパイクは「平均値」ではなく「分散」の問題。速度測定サイトの下り速度が十分でも起きる。見るべきはmax値とジッター、パケットロスの3つ。
• 切り分けはコマンド2本で足りる。ping -tで自宅ルーターと外部宛を同時に取り、pathpingでどのホップから遅延・ロスが立つかを見る。1ホップ目が荒れていれば宅内、途中から荒れていればISPか中継網。
• サイズ依存で通信が止まるならスパイクではなくMTU問題。ping -f -l 1472から二分探索でPath MTUを確認する（-fはIPv4専用、ヘッダ28バイトを足した値が実MTU）。
• 宅内起因で最も多いのは無線。Wi-Fiは半二重で、他チャネルを見に行くスキャン中はデータの送受信が滞る。これはMicrosoftのWlanScanのドキュメントに明記された挙動で、有線に差すだけで消えるスパイクは珍しくない。
• 定番の「PC設定いじり」はほとんど根拠がない。Nagle無効化も受信ウィンドウ自動チューニングの無効化も、Microsoftの一次文書に遅延対策としての記載はない。記事後半に公式記述と突き合わせた判定表を置いた。
• ゲーミングVPNが効くのは「経路が遠回りのとき」だけ。宅内や最終マイルが原因なら同じ区間を通るので改善せず、中継ホップと暗号化処理が増える分むしろRTTは伸びる。

Pingスパイクの定義と、見るべき3つの数値

Pingスパイクとは、往復遅延（RTT）が一時的に平常値の数倍から数十倍へ跳ね、短時間で元に戻る現象を指します。平常20ms・スパイク時400msというような分布になるため、平均値だけを見ると「平均35ms、問題なし」と読めてしまう。この見落としがPingスパイクの厄介さの本体です。RTTそのものの定義や、レスポンスタイムとの違いを整理したい場合はレイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法を先に読むと以降の切り分けが速くなります。

平均Ping・ジッター・パケットロスの役割分担

まず用語を分けます。レイテンシ（遅延）は片道・往復にかかる時間という概念で、PingはそれをICMPのエコー要求で実測するコマンドであり、その測定値です。「レイテンシとPingの違い」は、測る対象と測る手段の関係だと理解すれば足ります。

そのうえで、追う数値は3つあり、それぞれ別の故障を指します。平均Pingは物理的な距離と経路長を反映し、サーバーが海外にあれば下がりません。ジッターはRTTのばらつきで、RFC 3550は連続するパケット間の遅延差を平滑平均した値として定義しています。max値が「最悪どこまで跳ねたか」を示すのに対し、ジッターは「跳ねがどれだけ常態化しているか」を示す。パケットロスは届かなかった割合です。オンラインゲームの実データは大半がUDPで流れるため、ロスはTCPのような再送待ちにはならず、状態更新の欠落として現れます。抜けた分をクライアントが補間・巻き戻しで埋めるので、キャラクターのワープやコマ飛びとして体感される。追うべきはジッターとロスであり、平均Pingは正常でも構いません。逆に平均Ping自体が高いなら、それは距離・経路の問題であって本記事の対象外です。

60ms・80msの実用上限と競技タイトルの目標値

「Ping何msまでなら遊べるか」に業界標準の規格値はありません。参考にできるのは開発元が公表した目標値です。Riot Gamesは80ms未満で遊べるプレイヤーの比率を改善指標に使っており、ISPとのピアリングを始めた9か月余りでこの比率を31%から50%へ、さらにサーバーをシカゴへ移設した際には50%から80%へ一気に引き上げたと公表しています。VALORANTではプレイヤーの70%に対し35msを目標に置いたとも述べています。競技志向のFPSでは35ms前後が設計上の狙い、80msが実用の上限という水準感です。

ただしこの数値は安定して80msの話です。平均20msでも200msのスパイクが数十秒おきに刺されば体感は平均80msの安定回線より悪くなります。格闘ゲームのロールバック方式（GGPO系）はまさにここが弱点になります。GGPOの公式説明によれば、従来手法が入力に遅延を足して伝送時間を吸収するのに対し、ロールバックは入力を即座に送信し、予測実行によって遅延ゼロの錯覚を作る設計です。その結果、RTTが急変する局面では予測が外れやすくなり、巻き戻し量の増大がコマ飛びとして表面化します。

切り分けの本体：pingとpathpingで発生箇所を特定する

スパイクの原因を推測で潰すのは時間の無駄です。宅内・最終マイル・中継網のどこで遅延が立っているかを、先に測定で確定させます。

連続測定で「いつ」跳ねるかを取る

Windowsのpingは既定で4回しか送らず、待ち時間も4000ミリ秒あるため、既定のまま叩いてもスパイクは捕まりません。連続測定に切り替えます。以下はコマンドプロンプト（cmd）で実行する前提です（PowerShellではREM行が通らないので、注釈は削るか # に置き換えてください）。

REM 自宅ルーター宛（宅内の切り分け用。IPは自環境のゲートウェイに置き換える）
ping -t 192.168.1.1

REM 外部宛。-n で回数を固定し、-w で待ち時間を1秒に縮める
ping -n 300 -w 1000 8.8.8.8

REM 結果をファイルへ残す（Ctrl+Break で途中統計、Ctrl+C で終了）。C:\temp は事前に作っておく
ping -t 8.8.8.8 > C:\temp\ping_log.txt

Microsoftのコマンドリファレンス上、-nの既定は4回、-l（データ長）の既定は32バイトで最大65,500バイト、-wの既定は4000ミリ秒です。2つのpingを同時に走らせるのが要点で、ルーター宛と外部宛が同時に跳ねれば宅内（Wi-Fiまたはルーター自身）、外部宛だけが跳ねれば宅外が疑わしい。ルーター宛が安定しているのに外部宛が荒れるなら、宅内の無線対策をいくら積んでも直りません。

pathpingでホップ単位のロスを見る

どのホップから劣化するかはpathpingが最も手数が少ない。各ルーターへ既定で100回のエコー要求を送り、ホップごとのロス率を出します。

pathping 8.8.8.8

REM 名前解決を止めて短時間で回す
pathping -n -q 50 8.8.8.8

REM 経路そのものを先に見るとき
tracert -d 8.8.8.8

pathpingは既定で最大30ホップ、各ホップへのエコー要求100回、送信間隔250ミリ秒、応答待ち3000ミリ秒。統計収集に約90秒かかる（ホップ数で変動し、Microsoftの掲載例では125秒）のはこの設計のためで、途中で止めないこと。読み方の注意が1つあります。途中ホップに出るロスや「*」は、そのルーターが壊れている証拠ではありません。pathpingの公式リファレンスは出力例の解説で「2番目と4番目のホップのルーターも自分宛のパケットを落としているが、このロスは自分宛でないトラフィックの転送能力には影響しない」と述べています。tracertのリファレンスにも、Time Exceededを返さないルーターでは「*」が並ぶと明記されています。判断材料になるのはそのホップ以降すべてでロスが継続しているかだけです。中間だけロスして最終ホップが0%なら、それは正常な機器です。

macOS・LinuxでのDFビット指定とmtr

# macOS: -D が Don't Fragment（Windows の -f 相当）
ping -c 100 8.8.8.8
ping -D -c 1 -s 1472 8.8.8.8

# Linux: -M do で DF をセット、mtr で経路別のロスとジッターを同時に見る
ping -M do -s 1472 -c 1 8.8.8.8
mtr -r -c 100 8.8.8.8

オプション名が紛らわしい点に注意します。Linuxの-Dはタイムスタンプ表示であって、DFビットではありません。macOSの-DがDFビットで、LinuxでDFを立てるのは-M doです。サイズ超過時のメッセージにも違いがあります。macOSやLinuxが返す「Message too long」は手元のインターフェースのMTUを超えたという送信側のエラーで、Windowsの「パケットの分割が必要ですが、DFが設定されています」は経路上のルーターが返したICMPです。前者が出たときは経路ではなく自分のNICやトンネルのMTUを見てください。なおmtrはmacOS・Linuxとも標準では入っておらず、Homebrewやaptで導入します。tracerouteとpingを統合したツールで、各ホップのロス率とジッターを1画面で継続監視できるため、スパイクの再現待ちにはWindowsのWinMTRを含めてこちらが向きます。

サイズ依存の停止はスパイクではない：ping -f -l でPath MTUを確認する

「特定のゲームだけ通信が固まる」「大きいファイルの転送だけ止まる」場合、それはPingスパイクではなくPath MTUの問題である可能性があります。両者は原因も対処も別物なので、混同すると永久に直りません。判別はDFビット付きのpingで行います。

REM -f は Don't Fragment。1472 バイトが通れば経路MTUは1500
ping -f -l 1472 8.8.8.8

REM 通らなければサイズを下げて二分探索する
ping -f -l 1432 8.8.8.8
ping -f -l 1426 8.8.8.8

指定するのはICMPのデータ長なので、実際のMTUは指定値に28バイト（IPv4ヘッダ20＋ICMPヘッダ8）を足した値です。「パケットの分割が必要ですが、DFが設定されています」と返れば、そのサイズは経路のどこかで通っていません。目安は次の3つです。

注意すべきは3行目です。v6プラスやtransixのMTU 1460は、ISPやVNEの公式ページに明記された値ではありません。JPNEやインターネットマルチフィードのサービス説明にMTUの記載はなく、1460という値はヤマハやNECのルーター公式設定例（ip tunnel mtu 1460）が一律に採用しているものです。IPv6ヘッダ40バイト分を1500から引いた値なので技術的には妥当ですが、「ISPが1460と定めている」と書いている解説記事は出典を持っていません。自環境の実値は上のコマンドで測るのが確実です。

-fはIPv4専用のオプションです（Microsoftのドキュメントに”available on IPv4 only”と明記）。IPv6ではルーターが断片化しない仕様のため、このオプション自体が存在しません。なお、Path MTU Discoveryが機能しない状態（ICMPのFragmentation Neededがフィルタされている、いわゆるPMTUDブラックホール）で起きるのは、RFC 2923が記述する通り「上位プロトコルが大きいパケットを送り続け、縮めるべきだと気づけずハングする」症状です。一過性の遅延スパイクではなく、サイズを超えた通信だけが完全に止まるという現れ方をします。この違いを押さえておけば、切り分けを1本の測定で終えられます。

宅内が原因のとき：無線・帯域競合・PC設定

ルーター宛のpingも一緒に跳ねていた場合、原因は宅内です。頻度の高い順に潰します。

Wi-Fiのスキャンによる中断（最頻）

無線は半二重で、在圏チャネルを離れて他チャネルを見に行っている間はデータを送受信できません。この挙動はMicrosoftのWlanScan APIのドキュメントに「スキャン中は無線インターフェースがデータパケットを送受信しづらくなるため、スキャン完了までレイテンシが増加しうる」と明記されています。同ドキュメントによれば、Windowsの無線LANサービス自体は既定で60秒間隔、しかもすでに接続済みの場合はスキャンを要求しないこともあるとされており、実際にスキャンを誘発しているのはアプリケーション側です。ドライバはロゴ要件上、スキャン要求を4秒以内に完了させる必要があるとも書かれています。つまり最悪ケースでは秒単位の遅延が入りうる。

周期的に、たとえば1分おきに規則正しくスパイクが来るなら、まず有線LANに差して再測定してください。それで消えるなら無線が原因で、確定です。恒常的な干渉源の切り分けまで踏み込むなら、2.4GHz帯はBluetooth（2.402〜2.480GHzをFHSSで使用）や電子レンジと同じISMバンドを共有しているため、5GHz帯・6GHz帯へ逃がすのが最短です。帯域そのものを増やす選択肢の比較はWi-Fi 6Eとは？6GHz帯の特徴とWi-Fi 6/7との違い・対応端末を解説で整理しています。

帯域競合とセキュリティソフト

同一回線でクラウドバックアップ、Windows Update、Steamの自動更新、動画配信が走ればアップリンクが埋まり、キューイング遅延としてスパイクが出ます。ルーターのQoSでゲーム端末を優先するのは有効ですが、その前に競合トラフィックを止めて再測定し、原因を確定させてください。優先制御は「埋まった帯域の中で順番を変える」だけで、埋まっている事実は変わりません。

セキュリティソフトの影響は、通説ではなく公式に根拠があります。MicrosoftはTCP関連のドキュメントで、サードパーティ製のWFP（Windows Filtering Platform）フィルタが実装次第でネットワーク性能を著しく低下させうると明記しています。切り分けでは、一時的に停止して同じ測定を回す価値があります。

ISP・経路が原因のとき：輻輳の証明と交渉材料

pathpingで自宅ルーターより先のホップからロス・遅延が立ち、それが平日夜間に集中するなら、最終マイルか中継網の輻輳です。この場合に自宅側の機器を買い替えても意味がありません。問い合わせに進むなら、以下を揃えてから連絡すると話が早い。

• 連続ログ：混雑時間帯（平日21〜23時台）と閑散時間帯（早朝）の同一宛先へのping -tログを、それぞれ最低1時間分。「遅い」ではなく「同一宛先で平常18ms・夜間はmax480msが毎分発生」と数値で言う。
• pathpingの結果：どのホップからロスが始まるかを示したもの。宅内ホップが0%であることが、自宅側の切り分けが済んでいる証拠になります。
• 有線直結での再現：無線を除外済みであることを明示する。これがないと「Wi-Fiでは？」で終わります。

接続方式の変更（PPPoEからIPoE系のIPv4 over IPv6へ）は、PPPoE網終端装置の輻輳が原因の場合に効きます。ただしスパイクの発生箇所がPPPoE区間にあることをpathpingで確認してからにしてください。IPoEに変えても中継網や海外のゲームサーバー側が原因なら何も変わりません。ICMPやTCP/IPの階層関係が曖昧なまま切り分けると読み違えるので、必要ならOSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違いを解説で層の分担を確認しておくと、どの数値が何を意味するかを取り違えずに済みます。

定番の対処法は本当に効くのか：通説と一次情報の判定

Pingスパイクの検索結果には、レジストリ改変やOS設定の変更を勧める記事が並びます。その多くは出典が「試したら直った」であり、公式ドキュメントに当たると裏付けが取れません。ここは立場をはっきりさせます。PC側の設定いじりは、宅内の測定を終える前に手を出す価値がない。

位置情報サービスのオフが効く場合の機序

「位置情報サービスをオフにしたらPingスパイクが直った」という報告はQiitaをはじめ多数ありますが、その因果を直接述べたMicrosoftの文書はありません。ただし、公式に書かれている2つの事実をつなぐと機序は説明できます。1つは、WlanScanのドキュメントにある「スキャン中は遅延が増加しうる」という記載。もう1つは、Windowsの位置情報サービスが近隣のWi-Fiアクセスポイントを用いて位置を推定するという公式仕様です。位置情報を要求するアプリが常駐していれば、そのアプリがWi-Fiスキャンを誘発しうる。前述の通り、Windowsの無線LANサービス自体は接続済みならスキャンを要求しないことがあるので、スキャンの引き金はOSではなくアプリ側です。

これを裏づける仕様変更もあります。MicrosoftはWi-Fiアクセスと位置情報に関するAPIの挙動変更として、Wi-Fiスキャン結果から位置を得るなら位置情報APIを使うべきこと、BSSIDを返すAPIは精密位置の許可を持つアプリに限定することを明記しました。位置情報の許可を切れば、その種のアプリはスキャン結果を取得できなくなる——つまりスキャンを誘発する動機が消えます。とはいえ、これは「効く場合がある」の説明であって万能薬ではありません。1分周期の規則的なスパイクが有線接続で消えることを先に確認してから触る設定です。

Nagle無効化と自動チューニングを勧めない理由

TcpAckFrequencyについては公式KBが存在し、既定値は2、有効範囲0〜255で、「環境を慎重に検討せずに既定値を変更することは推奨しない」と明記されています。一方、ゲーミング記事の定番であるTCPNoDelayをインターフェース配下に作る手順は、Microsoftの一次文書で裏が取れません。より本質的な問題があります。オンラインゲームの実データの大半はUDPで流れており、ping値の計測に使うのはICMPです。TCPの遅延ACKやNagleアルゴリズムは、そのどちらにも原理的に関与しません。TCPの挙動を変えてping値が下がるという説明は、プロトコルの層を取り違えています。

受信ウィンドウ自動チューニングも同様です。Microsoftの説明では、帯域・ネットワーク遅延・アプリケーション遅延を継続監視して受信ウィンドウをスケールさせ、スループットを最大化する機能で、既定はNormal。無効化はRFC 1323に準拠しない古いルーターやファイアウォールとの互換性問題への回避策として案内されており、遅延対策としては一切推奨されていません。無効化すればスループットが落ちるリスクの方が現実的です。

ゲーミングVPNが効く条件と、効かない条件

LagoFastやNoPingのような「ゲーミングVPN」は、宣伝の効果を検証した独立した一次データが見当たりません。ただし技術的な理屈自体は成立します。BGPで選ばれる既定経路が遠回りだったり混雑したピアを通っていたりする場合、専用バックボーン経由で中継すると速くなりうる。これはゲーム会社自身が述べていることで、ValveはSteam Datagram Relayの公式ドキュメントで「驚くほど多くのプレイヤーについて、自社ネットワーク経由の方が速い経路を見つけられ、実際にping値が改善する」と説明しています。ゲーミングVPNは、これと同じ発想を第三者が提供するものです。

効かない条件のほうがはっきりしています。スパイクの原因がWi-Fiのオフチャネルスキャン、宅内の帯域競合、最終マイルの輻輳にある場合、VPNも同じ区間を通るため何も改善しません。すでに最短経路で繋がっているなら、中継ホップと暗号化処理が増える分だけRTTは確実に伸びます。ValveのSDRですら「中継経路がデフォルト経路より遅くなりすぎることはない」という慎重な書き方で、常に速くなるとは主張していません。CS2やDota2、Riotのタイトルのように独自リレー網を持つゲームでは、そもそも第三者が最適化できる余地は小さい。

判定の順序は決まっています。pathpingでスパイクが中継網のホップに出ていて、かつ宅内・最終マイルが0%ロスであるときだけ、試す価値があります。VPNプロトコル自体のオーバーヘッドを理解しておきたいならWireGuardとは？仕組み・設定方法・OpenVPNとの違いを実践解説が参考になります。

よくある質問

Pingの応答が飛び飛びになる原因は何ですか

連続測定の途中で応答が抜ける、値が飛び飛びに乱高下する場合、宅内であればWi-Fiのスキャンや帯域競合、宅外であれば経路上の輻輳が典型です。順序としては、自宅ルーター宛と外部宛のpingを同時に走らせて、両方が同時に飛ぶのか外部宛だけが飛ぶのかを先に確定させてください。宛先サーバーが自分宛のICMPを間引いている場合もあるので、宛先を変えて再測定すると切り分けが進みます。

回線速度は十分なのにPingだけ跳ねるのはなぜですか

速度測定サイトが測るのはスループット（単位時間あたりの転送量）で、Pingスパイクは遅延の分散です。アップリンクが一時的に埋まってキューが伸びれば、下り速度が1Gbpsでも遅延は跳ねます。両者は別の指標なので、速度が出ていることはスパイクが無い証明になりません。

ping -f -l で「パケットの分割が必要」と出ます。故障ですか

故障ではありません。指定したサイズが経路のMTUを超えているだけです。1472で出るならPPPoEやIPv4 over IPv6のトンネルを通っている可能性が高いので、1432、1426と下げて通る最大値を探してください。通った値に28を足したものが経路のMTUです。

pathpingの途中ホップでロス100%と出ました。そこが原因ですか

ほぼ違います。自分宛のICMPに応答しない、または低優先で処理するルーターは正常でもロスとして表示されます。原因と判断してよいのは、そのホップ以降のすべてでロスが継続している場合だけです。最終ホップが0%なら経路は正常です。

Ping 60ms・80msはゲームで使えますか

安定して80ms程度なら多くのタイトルで遊べます。Riot Gamesは80ms未満を改善指標に、VALORANTでは35msを目標値として公表しています。ただし平均値が良くてもスパイクが刺されば体感は悪化するので、maxとジッターを併せて見てください。

スパイクの再発を監視するにはどうすればいいですか

WinMTRやmtrを常駐させ、ロス率とジッターを継続記録するのが最も手軽です。長期の傾向まで取るなら、宅内ルーターと外部の固定宛先の2系統に定期的にpingを打ち、日次でmax値を残します。スパイクは再現待ちの勝負なので、発生時にログが残っている状態を先に作ることが対策そのものです。

関連記事

• レイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法
• Wi-Fi 6Eとは？6GHz帯の特徴とWi-Fi 6/7との違い・対応端末を解説
• OSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違いを解説
• WireGuardとは？仕組み・設定方法・OpenVPNとの違いを実践解説