--- title: "Pingスパイクの原因と対策｜pingとpathpingの見方で自宅かISPかを切り分ける" url: "https://www.issoh.co.jp/tech/details/12052/" published: 2026-05-11 updated: 2026-10-14 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # Pingスパイクの原因と対策｜pingとpathpingの見方で自宅かISPかを切り分ける ふだんは20msで安定しているのに、対戦中に数百msへ跳ね上がって数秒で戻る。この一過性の遅延がPingスパイクです。平均Pingが悪いわけではないので回線速度の測定サイトでは異常が出ず、原因の場所が分からないまま「ルーターを買い替える」「ゲーミングVPNを入れる」と手を打つと、原因が別の区間にあれば費用だけかかって症状は残ります。この記事では、Windows標準のpingとpathping、そしてMTU起因を疑うときの**ping -f -l**で、スパイクの発生箇所を宅内・最終マイル・中継網のどこかに切り分ける手順をまとめます。pathpingの結果は列の読み方を1つ間違えると無実のルーターを犯人にしてしまうので、公式の出力例を使って読み分けを示しました。Wi-Fiのスキャンが遅延を生む様子も、検証環境で測った数値で示しています。 ## まとめ：先に結論 - **Pingスパイクは「平均値」ではなく「分散」の問題**。速度測定サイトの下り速度が十分でも起きる。見るべきはmax値とジッター、パケットロスの3つ。 - **切り分けはコマンド2本で足りる**。`ping -t`で自宅ルーターと外部宛を同時に取り、`pathping`でどのホップから遅延・ロスが立つかを見る。1ホップ目が荒れていれば宅内を、途中から荒れていればISPか中継網を先に疑う。 - **pathpingは「This Node/Link」列をIPの行と縦棒の行に分けて読む**。IPの行のロスはそのルーター自身の過負荷の目安で、通過する通信が落ちている証拠ではない。リンクの輻輳を疑う手がかりは縦棒（|）の行のロスで、それが以降のホップでも続くかを見る。 - **サイズ依存で通信が止まるならスパイクではなくMTU問題**。`ping -f -l 1472`から二分探索でPath MTUを確認する（`-f`はIPv4専用。通った最大のデータ長に28バイトを足した値が、その宛先までの経路MTU）。 - **宅内で最初に確かめるのは無線**。有線に差し替えて再測定するだけで切り分けられる。5GHz帯の検証環境で測ると、Wi-Fi一覧を取得している間だけ、宅内ルーター宛のRTTの最大値が14.5msから138msへ跳ねた。 - **定番の「PC設定いじり」はほとんど根拠がない**。Nagle無効化はTCPの送信に関わる設定で、ICMPで測るping値には関与しない。受信ウィンドウ自動チューニングの無効化は、Microsoftの文書では古い機器との互換性の回避策として案内されている。ゲーミングVPNが効くのも「経路が遠回りのとき」だけです。 ## Pingスパイクの定義と、見るべき3つの数値 Pingスパイクとは、往復遅延（RTT）が一時的に平常値の数倍から数十倍へ跳ね、短時間で元に戻る現象を指します。平常20ms・スパイク時400msというような分布になるため、平均値だけを見ると「平均35ms、問題なし」と読めてしまう。この見落としがPingスパイクの厄介さの本体です。RTTそのものの定義や、レスポンスタイムとの違いを整理したい場合は[レイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法](/column/details/7053/)を先に読むと以降の切り分けが速くなります。 ### 平均Ping・ジッター・パケットロスの役割分担 まず用語を分けます。レイテンシ（遅延）は片道・往復にかかる時間という概念で、Pingはそれを**ICMPのエコー要求で実測するコマンドであり、その測定値**です。「レイテンシとPingの違い」は、測る対象と測る手段の関係だと理解すれば足ります。 そのうえで、追う数値は3つあり、それぞれ別の故障を指します。平均Pingは物理的な距離と経路長を反映し、サーバーが海外にあれば下がりません。ジッターはRTTのばらつきです。RTPの仕様であるRFC 3550はパケットの到着間隔の揺らぎを「interarrival jitter」として平滑平均で求める式を定めており、後述のmtrもこの考え方の「Interarrival Jitter」を表示列に持っています。max値が「最悪どこまで跳ねたか」を示すのに対し、ジッターは「跳ねがどれだけ常態化しているか」を示す。パケットロスは届かなかった割合です。**UDPで状態を送るゲームでは、ロスはTCPのような再送待ちにはならず、状態更新の欠落として現れます**。抜けた分をクライアントが補間・巻き戻しで埋めるので、キャラクターのワープやコマ飛びとして体感される。追うべきはジッターとロスであり、平均Pingは正常でも構いません。平均Ping自体が常に高い場合は、距離・経路に加えて回線の慢性的な混雑も疑う別の問題で、本記事は一時的に跳ねる側を扱います。 ### Ping 60ms・80msの目安とRiot Gamesの公表値 「Ping何msまでなら遊べるか」に業界標準の規格値はありません。参考にできるのは開発元が公表した目標値です。Riot Gamesは[リアルタイム通信の改善を説明した技術記事](https://www.riotgames.com/en/news/fixing-internet-real-time-applications-part-ii)で、**80ms未満で遊べるプレイヤーの比率**を改善指標に使ったと述べています。ISPとのピアリングを始めた9か月余りでこの比率を31%から50%へ、さらにサーバーをシカゴへ移設した際には50%から80%へ一晩で引き上げた。VALORANTでは[ネットコードの解説](https://www.riotgames.com/en/news/peeking-valorants-netcode)で、プレイヤーの70%に35msを届けることを目標に置いたとしています。60msや80msで遊べるかに公式の線引きはなく、参考にできるのはこうした個別タイトルの改善指標と目標値です。 ただしこの数値は**安定して80ms**の話です。平均20msでも200msのスパイクが数十秒おきに刺されば体感は平均80msの安定回線より悪くなります。格闘ゲームのロールバック方式（GGPO系）はまさにここが弱点になります。GGPOの公式説明によれば、従来手法が入力に遅延を足して伝送時間を吸収するのに対し、ロールバックは入力を即座に送信し、予測実行によって遅延ゼロの錯覚を作る設計です。その結果、RTTが急変する局面では予測が外れやすくなり、巻き戻し量の増大がコマ飛びとして表面化します。 ## pingとpathpingによる発生区間の切り分け手順 スパイクの原因を推測で潰すのは時間の無駄です。宅内・最終マイル・中継網のどこで遅延が立っているかを、先に測定で確定させます。 ### ルーター宛と外部宛の同時連続測定 Windowsのpingは既定で4回しか送らないので、数十秒おきに起きるスパイクは既定のままでは見逃しやすい。`-t`か`-n`で回数を増やした連続測定に切り替えます。以下はコマンドプロンプト（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のpingコマンドリファレンス](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping)上、`-n`の既定は4回、`-l`（データ長）の既定は32バイトで最大65,500バイト、`-w`の既定は4000ミリ秒です。**2つのpingを同時に走らせるのが要点**で、ルーター宛と外部宛が同時に跳ねれば宅内（Wi-Fiまたはルーター自身）、外部宛だけが跳ねれば、宅外か、宅内の別の端末がアップロードで回線を埋めている状態が疑わしい。ルーター宛への応答はWAN側の送信待ち行列を通らないため、この2つはこの比較だけでは見分けられません。ルーター宛が安定しているなら、少なくとも無線の対策を積んでも効きません。 cmdの`ping -t`のログには時刻が付きません。後から「毎分発生」を照合したいなら、PowerShellで受信時刻を付けて保存します（宅内宛は別ウィンドウ・別ファイルに）。 ``` ping.exe -t 8.8.8.8 | ForEach-Object { '{0:o} {1}' -f (Get-Date), $_ } | Out-File -FilePath C:\temp\ping_log.txt -Encoding utf8 ``` ### pathpingのオプションと所要時間 どのホップから劣化するかはpathpingが最も手数が少ない。tracertと同じ要領で経路を表示したあと、各ルーターへエコー要求を一定時間送り続け、ホップごとのロス率を統計にして出します。tracertが各ホップを3回だけ試して経路の形を見せるコマンドだとすれば、pathpingはその経路の各区間で**どれだけ落ちているか**まで数えるコマンドです。 ``` pathping 8.8.8.8 REM 名前解決を止めて短時間で回す pathping -n -q 50 8.8.8.8 REM 経路そのものを先に見るとき tracert -d 8.8.8.8 ``` [pathpingの公式リファレンス](https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/pathping)に載る既定値は次のとおりです。Windows 10・11とWindows Serverの各版が適用対象で、追加の導入は要りません。 | オプション | 意味 | 既定値 | | ----- | ---------------- | ------- | | \-n | ホスト名を解決しない | 解決する | | \-h | 探索する最大ホップ数 | 30 | | \-q | 各ルーターへ送るエコー要求の回数 | 100 | | \-p | 送信間隔 | 250ミリ秒 | | \-w | 応答の待ち時間 | 3000ミリ秒 | 統計収集の時間はおおむね「ホップ数×100回×250ミリ秒」、つまり1ホップあたり25秒で、Microsoftの掲載例（5ホップ）では125秒でした。15ホップなら6分を超えるので、途中で止めずに待ちます。急ぐときは`-q 50`で回数を半分にできます。既定の100回はロス率が1%刻みで表示される回数というだけで、1〜2%の差が意味のある違いかまでは判断できません。 ### pathpingの結果の見方：IPの行と縦棒の行の読み分け pathpingの結果で迷うのは、ロス率の列が2本あることです。公式リファレンスの出力例をそのまま引きます。 ``` Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct address 0 172.16.87.35 0/ 100 = 0% | 1 41ms 0/ 100 = 0% 0/ 100 = 0% 172.16.87.218 13/ 100 = 13% | 2 22ms 16/ 100 = 16% 3/ 100 = 3% 192.168.52.1 0/ 100 = 0% | 3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.168.80.1 0/ 100 = 0% | 4 21ms 14/ 100 = 14% 1/ 100 = 1% 10.54.247.14 0/ 100 = 0% | 5 24ms 13/ 100 = 13% 0/ 100 = 0% 10.54.1.196 ``` | 列・行 | 示すもの | 読み方 | | --------------------- | ---------------- | -------------------- | | Source to Here | 自分からそのホップまでの累積ロス | 以降のホップで下がらなければ本物 | | This Node/Link（IPの行） | そのルーター自身のロス | 過負荷の目安。通過する通信の損失ではない | | This Node/Link（\| の行） | 2つのホップの間のリンクのロス | 輻輳を疑う手がかり | | RTT | そのホップまでの往復時間 | 最終ホップの値と比べて判断 | 公式の解説はこの例を、172.16.87.218と192.168.52.1の間のリンクが13%を落としていると読み、**ホップ2と4のルーターも自分宛てのパケットを落としているが、その損失は自分宛てでないトラフィックの転送能力には影響しない**と述べています。縦棒の行に出るロスはリンクの輻輳、IPアドレスの行に出るロスはそのルーターの過負荷、という区別です。実際、この例ではホップ1と2の間の縦棒行で13%が立ち、Source to Hereは以降ずっと13〜16%のまま戻っていない。経路上の問題はこの1か所だけです。 読み方の要点は2つです。1つ目は、**途中ホップに出るロスや「\*」は、そのルーターが壊れている証拠ではない**こと。[tracertのリファレンス](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/tracert)にも、Time Exceededを返さないルーターでは「\*」が並ぶと明記されています。2つ目は、**判断材料になるのはそのホップ以降すべてでロスが継続しているか**だけということ。中間だけロスして最終ホップが0%なら、そのロスは通過する通信の損失を示していません。自宅ルーターまでの縦棒行が0%で、ISP側の縦棒行から先のSource to Hereでロスが続いていれば、宅外を第一候補にできます。宛先を2〜3か所に変え、有線で、混む時間帯と空く時間帯の両方で同じ傾向が出れば、問い合わせの根拠として十分です。ただしpathpingが数えるのはロスで、ロス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 で経路別のロスとジッターを同時に見る（-o の J・M・X・I がジッター列） ping -M do -s 1472 -c 1 8.8.8.8 mtr -r -c 100 -o LSNBAWVJMXI 8.8.8.8 ``` オプション名が紛らわしい点に注意します。**Linuxの`-D`はタイムスタンプ表示であって、DFビットではありません**。macOSの`-D`がDFビットで、LinuxでDFを立てるのは`-M do`です。サイズ超過時のメッセージにも違いがあります。macOSやLinuxが返す「Message too long」は**送信する前に手元で拒否された**というエラーで、Windowsの「パケットの分割が必要ですが、DFが設定されています」は**経路上のルーターが返したICMP**です。ただしLinuxの[ip(7)](https://man7.org/linux/man-pages/man7/ip.7.html)はこのエラー（EMSGSIZE）を「経路上のMTUより大きく、分割できない」場合と説明しており、OSが過去に経路から学習したMTUで拒否していることもあります。前者が出たら、自分のNICやトンネルのMTUと、学習済みの経路MTUの両方を疑ってください。なおmtrはmacOS・Linuxとも標準では入っておらず、Homebrewやaptで導入します。tracerouteとpingを統合したツールで、`-o`でジッター列を加えれば各ホップのロス率とジッターを並べて見られ、pathpingに相当する役割をWindows以外で担います。`-r`は指定回数を測ってから結果をまとめて出すレポート形式で、外すと画面上で継続監視になります。スパイクの再現待ちにはWindowsのWinMTRを含めてこちらが向きます。 ## 大きい通信だけ止まる症状とping -f -lによるPath MTU確認 「特定のゲームだけ通信が固まる」「大きいファイルの転送だけ止まる」場合、それはPingスパイクではなくPath MTUの問題である可能性があります。両者は原因も対処も別物で、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のデータ長なので、送られるIPパケットの長さは指定値に28バイト（オプションなしのIPv4ヘッダ20＋ICMPヘッダ8）を足した値です。**通った最大の指定値に28を足した値が、その宛先までの経路MTU**になります。宛先が変われば経路も変わるので、特定のゲームで問題が出るならそのサーバーに近い宛先でも測ってください。「パケットの分割が必要ですが、DFが設定されています」と返れば、そのサイズは経路のどこかで通っていません。目安は次の3つです。 | 接続方式 | MTU | ping -l で通る最大値 | MTU値の出どころ | | ----------------------------- | ---- | -------------- | ------------------- | | 一般的なイーサネット | 1500 | 1472 | IEEE 802.3の最大ペイロード長 | | フレッツのPPPoE | 1454 | 1426 | NTT東日本 技術参考資料 | | v6プラス・transix等のIPv4 over IPv6 | 1460 | 1432 | ルーターメーカーの設定例 | 2行目は、NTT東日本の[技術参考資料「IP通信網サービスのインタフェース フレッツシリーズ 第三分冊」](https://www.ntt-east.co.jp/info-st/katsuyou/h25/temp22-1.pdf)に「フレッツ 光ネクストではIP通信網におけるIPv4通信のMTU値は1454byteです」と書かれた値です。注意すべきは3行目で、**v6プラスやtransixのMTU 1460は、ISPやVNEの公式ページに明記された値ではありません**。JPNEやインターネットマルチフィードのサービス説明にMTUの記載はなく、1460という値は[NECのUNIVERGE IXのv6プラス設定例](https://jpn.nec.com/univerge/ix/Support/ipv6/v6plus-staic/ver9.7.html)（`ip mtu 1460`）などルーターメーカーの設定例が採用しているものです。IPv6ヘッダ40バイト分を1500から引いた値なので技術的には妥当ですが、「ISPが1460と定めている」と書いている解説記事は出典を持っていません。自環境の実値は上のコマンドで測るのが確実です。MTUの仕組みそのもの（フラグメンテーションやMSSクランプ）は[MTUとは？最大転送単位の仕組み・1500とジャンボフレーム・PMTUD/MSS調整と測定手順を実装者向けに解説](/tech/details/14476/)で掘り下げています。 `-f`はIPv4専用のオプションです（Microsoftのドキュメントに”available on IPv4 only”と明記）。IPv6ではルーターが断片化しない仕様のため、このオプション自体が存在しません。なお、Path MTU Discoveryが機能しない状態（ICMPのFragmentation Neededがフィルタされている、いわゆるPMTUDブラックホール）で起きるのは、[RFC 2923](https://www.rfc-editor.org/rfc/rfc2923.txt)が記述する通り「TCP接続が進まなくなり、タイムアウトで閉じられるまでハングする」症状です。**一過性の遅延スパイクではなく、サイズを超えた通信だけが止まるか、OSが検出して回復するまで待たされる**という現れ方をします。この違いを押さえておけば、切り分けを1本の測定で終えられます。 ## 宅内が原因のとき：無線・帯域競合・PC設定 ルーター宛のpingも一緒に跳ねていた場合、原因は宅内です。手間の少ない順に確かめます。 ### Wi-Fiのスキャンによる送受信の中断 無線は半二重で、在圏チャネルを離れて他チャネルを見に行っている間はデータを送受信できません。この挙動はMicrosoftの[WlanScan関数のドキュメント](https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/nf-wlanapi-wlanscan)に**「スキャン中は無線インターフェースがデータパケットを送受信しづらくなるため、スキャン完了までレイテンシが増加しうる」**と明記されています。同ドキュメントによれば、Windowsの無線LANサービス自体は既定で60秒ごとにスキャンを要求し、**すでに接続済みの場合はスキャンを要求しないこともある**とされています。WlanScanはアプリからも呼べるので、スキャンの要求元はOSとアプリの両方がありえます。ドライバはロゴ要件上、スキャン要求を4秒以内に完了させる必要があるとも書かれていますが、これは完了までの期限で、パケットがその間ずっと止まるという意味ではありません。どれだけ遅れるかは下の実測を見てください。 周期的に、たとえば1分おきに規則正しくスパイクが来るなら、まず有線LANに差して再測定してください。それで消えるなら無線が原因とみてよい。恒常的な干渉源の切り分けまで踏み込むなら、2.4GHz帯はBluetooth（2.402〜2.480GHzをFHSSで使用）や電子レンジと同じISMバンドを共有しているため、5GHz帯・6GHz帯へ逃がすのが最短です。帯域そのものを増やす選択肢の比較は[Wi-Fi 6Eとは？日本の6GHz帯チャネル・Wi-Fi 6/7との違いとアクセスポイントの設定【2026年】](/tech/details/8851/)で整理しています。 ### Wi-Fi一覧の取得中に測った宅内ルーター宛RTT スキャンがどの程度の遅延を生むのかを、2026年10月14日に次の検証環境で測定しました。1台・1回の測定で、他の機種や2.4GHz帯での値を代表するものではありません。端末はMacBook Pro（MacBookPro16,1）・macOS 26.6.2で、宅内ルーターと5GHz帯（36ch・80MHz幅・802.11ac）で接続しています。宅内ルーター宛に0.2秒間隔でpingを400発送りながら、周辺のWi-Fi一覧を取得するコマンド（`system_profiler SPAirPortDataType`）を15秒の間を空けて3回走らせ（開始間隔は約20秒）、各回の開始・終了時刻を記録して、その区間に受信した応答とそれ以外でRTTを分けて集計しました。比較のため、一覧の取得をしない300発も別に取っています。 ``` # 宅内ルーター宛に0.2秒間隔で400発（--apple-time で受信時刻を記録） ping --apple-time -i 0.2 -c 400 192.168.86.1 > ping_scan.txt & # 15秒待ってから周辺のWi-Fi一覧を取得（スキャンが走る）。開始・終了時刻を残して3回 for n in 1 2 3; do sleep 15 echo "START $(date +%T)" >> marks.txt system_profiler SPAirPortDataType > /dev/null echo "END $(date +%T)" >> marks.txt done wait # pingの完了を待ってから、marks.txt の区間で ping_scan.txt を分けて集計する ``` | 区間 | 応答数 | 中央値 | 最大 | 30ms超 | | ---------------------- | --- | ----- | ------- | ----- | | 一覧取得の実行中（3回・各4.6〜5.1秒） | 43 | 5.5ms | 138.5ms | 17回 | | 同じ測定のそれ以外の区間 | 357 | 2.7ms | 14.5ms | 0回 | | 一覧取得なしの対照（300発） | 300 | 2.5ms | 76.7ms | 2回 | 3回とも、実行中に87〜138msの値が数回続けて立ち、終了とともに数msへ戻りました。ロスは0%でした。観測できたのはここまでで、遅れの内訳（オフチャネルでの待機か、無線の再送か、端末内の処理待ちか）はpingでは分けられません。ただ、WlanScanのドキュメントが述べる「スキャン中は送受信しづらくなる」挙動とは整合します。宅内ルーターまでの1ホップしか通っていない測定でこれだけ跳ねるので、回線やISPを疑う前に無線を外して測る価値は十分にあります。 対照の300発でも、こちらが何もしていないのに76.7msと58.6msのスパイクが2回出ました。この2回はちょうど60秒間隔で、OSか常駐アプリのどちらかが周期的に無線を使っていたと考えられますが、どのプロセスかまでは特定していません。「1分おきに規則正しく跳ねる」という症状報告が多いのは、この種の周期処理と整合します。Windowsで同じ確認をするなら、宅内ルーター宛の`ping -t`を流したまま、タスクバーのWi-Fi一覧を開いて更新させ、その瞬間に値が跳ねるかを見てください。 ### 帯域競合とセキュリティソフト 同一回線でクラウドバックアップ、Windows Update、Steamの自動更新、動画配信が走ればアップリンクが埋まり、キューイング遅延としてスパイクが出ます。ルーターのQoSでゲーム端末を優先するのは有効ですが、その前に競合トラフィックを止めて再測定し、原因を確定させてください。優先制御は埋まった帯域の中で順番を変えるもので、回線容量が増えるわけではありません。ルーターにSQM（fq\_codelやCAKEなど、送信待ち行列が伸びすぎないよう制御する仕組み）の設定があれば、帯域を使い切る通信が走っていても待ち行列による遅延を抑えられます。IETFも[RFC 7567](https://www.rfc-editor.org/rfc/rfc7567.html)で、ネットワーク機器は待ち行列の長さを管理してエンドツーエンドの遅延を減らすAQMを実装すべきだとしています。 セキュリティソフトの影響は、通説ではなく公式に根拠があります。MicrosoftはTCP関連のドキュメントで、サードパーティ製のWFP（Windows Filtering Platform）フィルタが実装次第でネットワーク性能を著しく低下させうると明記しています。切り分けでは、一時的に停止して同じ測定を回す価値があります。 ## ISP・経路が原因のとき：輻輳の証明と交渉材料 pingの連続測定で外部宛だけが跳ね、pathpingで自宅ルーターより先の縦棒行からロスが続き、それが平日夜間に集中するなら、最終マイルか中継網の輻輳が有力な候補です。この場合に自宅側の機器を買い替えても意味がありません。問い合わせに進むなら、以下を揃えてから連絡すると話が早い。 - **連続ログ**：混雑時間帯（平日21〜23時台）と閑散時間帯（早朝）の同一宛先への`ping -t`ログを、それぞれ最低1時間分。「遅い」ではなく「同一宛先で平常18ms・夜間はmax480msが毎分発生」と数値で言う。 - **pathpingの結果**：どの縦棒行からロスが始まり、以降も続いているかを示したもの。宅内ホップが0%であることが、自宅側の切り分けが済んでいる証拠になります。 - **有線直結での再現**：無線を除外済みであることを明示する。これがないと「Wi-Fiでは？」で終わります。 再発を待つ段階では、WinMTRやmtrを常駐させてロス率とジッターを継続記録するか、宅内ルーターと外部の固定宛先の2系統へ定期的にpingを打って日次でmax値を残します。スパイクは再現待ちの勝負なので、発生した瞬間のログが残っている状態を先に作ることが交渉材料そのものになります。 接続方式の変更（PPPoEからIPoE系のIPv4 over IPv6へ）は、PPPoE網終端装置の輻輳が原因の場合に効きます。ただし**夜間だけ悪化し、ISP側の最初のホップあたりから劣化が始まることを比較測定で確かめてから**にしてください。IPv6（IPoE）宛のping（`ping -6 -n 300 2001:4860:4860::8888`）が同じ時間帯に安定しているなら、IPv4のPPPoE区間の混雑を疑う材料になります。IPoEに変えても中継網や海外のゲームサーバー側が原因なら何も変わりません。ICMPやTCP/IPの階層関係が曖昧なまま切り分けると読み違えるので、必要なら[OSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違いを解説](/tech/details/8201/)で層の分担を確認しておくと、どの数値が何を意味するかを取り違えずに済みます。 ## 定番の対処法は本当に効くのか：通説と一次情報の判定 Pingスパイクの検索結果には、レジストリ改変やOS設定の変更を勧める記事が並びます。その多くは出典が「試したら直った」であり、公式ドキュメントに当たると裏付けが取れません。**PC側の設定は、ルーター宛と外部宛の連続測定とpathpingを終えてから触ります**。 | よく勧められる対処 | 一次情報の記載 | 判定 | | -------------------- | ------------------------------------------- | ----------- | | 位置情報サービスをオフ | 直接の因果を述べた公式文書はない。WlanScanは「スキャン中は遅延増」と明記 | 機序は説明できる | | Nagle無効化（TCPNoDelay） | TCPの送信に関わる設定。ICMP・UDPは対象外 | ping値には効かない | | 受信ウィンドウ自動チューニング無効化 | 公式では古い機器との互換性回避策 | 根拠なし・逆効果あり | | NIC省電力（EEE）をオフ | Intel公式は「a small amount of network latency」 | 効果は小さい | | ゲーミングVPNを導入 | 経路改善の理屈は成立（Valve SDRの公式説明） | 経路起因のときだけ | ### 位置情報サービスのオフが効く場合の機序 「位置情報サービスをオフにしたらPingスパイクが直った」という報告はQiitaをはじめ多数ありますが、**その因果を直接述べたMicrosoftの文書はありません**。ただし、公式に書かれている2つの事実をつなぐと機序は説明できます。1つは、WlanScanのドキュメントにある「スキャン中は遅延が増加しうる」という記載。もう1つは、Windowsの位置情報サービスが近隣のWi-Fiアクセスポイントを用いて位置を推定するという公式仕様です。位置情報を要求するアプリが常駐していれば、そのアプリがWi-Fiスキャンを誘発しうる。Windowsの無線LANサービス自体は接続済みならスキャンを要求しないことがあるので、**接続中に起きるスキャンはアプリの要求による場合がある**、というのが位置情報オフが効く筋道です。 これを裏づける仕様変更もあります。Microsoftは[Wi-Fiアクセスと位置情報に関するAPIの挙動変更](https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes)として、BSSIDを返すAPIを精密な位置情報の利用を許可されたアプリに限定し、開発者には「必要でない限りアプリ内でWi-Fiスキャンを呼ばない」「位置を得る目的のスキャンは位置情報APIの呼び出しに置き換える」よう求めています。同じ文書によれば、精密な位置情報の利用に同意していないアプリが`WlanScan`を呼ぶと`ERROR_ACCESS_DENIED`が返ります。**位置情報の許可を切れば、対象APIを使うアプリからのスキャン要求そのものを抑えられる**わけです。とはいえ、これは「効く場合がある」の説明であって万能薬ではありません。1分周期の規則的なスパイクが有線接続で消えることを先に確認してから触る設定です。 ### Nagle無効化と自動チューニングを勧めない理由 TcpAckFrequencyについては[公式KB 328890](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/registry-entry-control-tcp-acknowledgment-behavior)が存在し、既定値は2、有効範囲0〜255で、**「環境を慎重に検討せずに既定値を変更することは推奨しない」**と明記されています。一方、ゲーミング記事の定番であるTCPNoDelayをインターフェース配下に作る手順は、Microsoftの一次文書で裏が取れません。Nagleアルゴリズムの無効化そのものはTCPの正規の機能で、Microsoftも[StreamSocketのNoDelayプロパティ](https://learn.microsoft.com/en-us/uwp/api/windows.networking.sockets.streamsocketlistenercontrol.nodelay?view=winrt-26100)として、アプリがソケットごとに切り替える設定を用意しています（StreamSocketの既定はNagle無効）。問題は対象です。**ここで扱っているのは、UDPで状態を送るゲーム通信と、ICMPで測るpingコマンドの値**で、TCPの遅延ACKやNagleアルゴリズムはそのどちらにも関与しません。TCPの挙動を変えてping値が下がるという説明は、プロトコルの層を取り違えています。 受信ウィンドウ自動チューニングも同様です。Microsoftの[ネットワークアダプターの性能チューニング文書](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics)では、帯域・ネットワーク遅延・アプリケーション遅延を継続監視して受信ウィンドウをスケールさせ、スループットを最大化する機能とされ、既定はNormalです。無効化は[KB 947239](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/receive-window-auto-tuning-for-http)で、RFC 1323に準拠しない古いルーターやファイアウォールを変更できない場合の回避策として案内されており、遅延対策としては一切推奨されていません。無効化すればスループットが落ちるリスクの方が現実的です。 NICの省電力機能EEE（Energy Efficient Ethernet）も同じ並びで語られますが、[Intelのアダプター ユーザーガイド](https://edc.intel.com/content/www/us/en/design/products/ethernet/adapters-and-devices-user-guide/other-power-options/)は、低電力アイドルから通常電力へ戻る遷移が「a small amount of network latency」を生みうると書くにとどまります。数百msのスパイクの主因として疑う順番は、無線と帯域競合のあとです。 ### ゲーミングVPNが効く条件と、効かない条件 LagoFastやNoPingのような「ゲーミングVPN」は、宣伝の効果を検証した独立した一次データが見当たりません。ただし技術的な理屈自体は成立します。BGPで選ばれる既定経路が遠回りだったり混雑したピアを通っていたりする場合、専用バックボーン経由で中継すると速くなりうる。これはゲーム会社自身が述べていることで、Valveは[Steam Datagram Relayの公式ドキュメント](https://partner.steamgames.com/doc/features/multiplayer/steamdatagramrelay?l=english)で**「驚くほど多くのプレイヤーについて、自社ネットワーク経由の方が速い経路を見つけられ、実際にping値が改善する」**と説明しています。ゲーミングVPNは、これと同じ発想を第三者が提供するものです。 **効かない条件のほうがはっきりしています**。スパイクの原因がWi-Fiのオフチャネルスキャン、宅内の帯域競合、最終マイルの輻輳にある場合、VPNも同じ区間を通るため何も改善しません。既定の経路がすでに良好なら、中継ホップと暗号化処理が増える分だけRTTが伸びる可能性の方が高い。同じValveの文書も、専用サーバーが中継拠点の近くに無ければ**中継経路が既定のIP経路より遅くなり、一部のプレイヤーは現状より遅延が悪化する**と認めています。中継拠点の近くに置いた場合でさえ「中継経路が既定経路より遅くなりすぎない」という書き方で、常に速くなるとは主張していません。CS2やDota2、Riotのタイトルのように独自リレー網を持つゲームでは、そもそも第三者が最適化できる余地は小さい。 試す価値があるのは、ルーター宛が安定して外部宛だけが跳ね、pathpingで中継網より先の縦棒行からロスが続いているときです。導入したら、同じ時間帯・同じゲームサーバーでVPNの有無を切り替えて、pingとジッターを比べて判断してください。VPNプロトコル自体のオーバーヘッドを理解しておきたいなら[WireGuardとは？仕組み・設定方法・OpenVPNとの違いを実践解説](/tech/details/7696/)が参考になります。 ## よくある質問 ### Pingの応答が飛び飛びになる原因は何ですか？ 連続測定の途中で応答が抜ける、値が飛び飛びに乱高下する場合、宅内であればWi-Fiのスキャンや帯域競合、宅外であれば経路上の輻輳が典型です。順序としては、自宅ルーター宛と外部宛のpingを同時に走らせて、両方が同時に飛ぶのか外部宛だけが飛ぶのかを先に確定させてください。宛先サーバーが自分宛のICMPを間引いている場合もあるので、宛先を変えて再測定すると切り分けが進みます。 ### 回線速度は十分なのにPingだけ跳ねるのはなぜですか？ 速度測定サイトが測るのはスループット（単位時間あたりの転送量）で、Pingスパイクは遅延の分散です。アップリンクが一時的に埋まってキューが伸びれば、下り速度が1Gbpsでも遅延は跳ねます。両者は別の指標なので、速度が出ていることはスパイクが無い証明になりません。 ### ping -f -l で「パケットの分割が必要」と出ます。故障ですか？ 故障ではありません。指定したサイズが経路のMTUを超えているだけです。1472で出るならPPPoEやIPv4 over IPv6のトンネルを通っている可能性が高いので、1432、1426と下げて通る最大値を探してください。通る最大の値に28を足したものが、その宛先までの経路MTUです。 ### pathpingの途中ホップでロス100%と出ました。そこが原因ですか？ ほぼ違います。自分宛のICMPに応答しない、または低優先で処理するルーターは正常でもロスとして表示されます。原因の候補にしてよいのは、縦棒行にロスが出て、そのホップ以降のすべてでSource to Hereのロスが続いている場合です。最終ホップが0%なら、途中のロスは通信の損失を示していません。ただしロス0%でも遅延は跳ねうるので、RTTは別に見てください。 ### Ping 60ms・80msはゲームで使えますか？ 60ms・80msで遊べるかを決める公式の基準はありません。参考になるのは開発元の公表値で、Riot Gamesは80ms未満で遊べるプレイヤーの比率を改善指標に、VALORANTでは35msを目標値にしています。ただし平均値が良くてもスパイクが刺されば体感は悪化するので、maxとジッターを併せて見てください。 ## 関連記事 - [レイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法](/column/details/7053/) - [MTUとは？最大転送単位の仕組み・1500とジャンボフレーム・PMTUD/MSS調整と測定手順を実装者向けに解説](/tech/details/14476/) - [Wi-Fi 6Eとは？日本の6GHz帯チャネル・Wi-Fi 6/7との違いとアクセスポイントの設定【2026年】](/tech/details/8851/) - [OSI参照モデルとは？7階層の役割・各層プロトコル・TCP/IPとの違いを解説](/tech/details/8201/) - [WireGuardとは？仕組み・設定方法・OpenVPNとの違いを実践解説](/tech/details/7696/) --- 出典: [Pingスパイクの原因と対策｜pingとpathpingの見方で自宅かISPかを切り分ける]()（株式会社一創）