pathpingの使い方とパケットロスの読み方｜途中の100％損失を回線故障と決めつけないゲーム回線診断【2026年】

最終確認日：2026年10月25日。Microsoft公式ドキュメントを基準に、Windows 11のPC（Wi-Fi接続）で2026年10月25日の午前3時台にpathpingを実行した出力を載せています。ルーターや回線会社のアドレスの一部は伏せています。参照した資料：pathping（Microsoft Learn）、tracert（Microsoft Learn）、RFC 792（ICMP）、RFC 4443（ICMPv6）、MTR, Traceroute, and the Myth of the “Scary Hop”（ITLDC）

ゲームの回線が不安定なとき、pathpingを実行すると途中のルーターの行に「100%」と出ることがあります。数字だけ見れば、そこで通信が途切れているように見えます。

その行の損失は、ルーターが調査用の応答を返さなかった数です。次のホップと宛先の損失が0％なら、そのルーターは応答を返さないだけで、通信はそこを通過しています。回線の問題を疑うのは、損失があるホップから後ろのすべてのホップ、そして宛先まで同じように続くときです。

ただし、宛先の側が応答を絞っていて、宛先の行だけ損失が出ることもあります。また、pathpingが使うICMPの応答は、ゲームの通信とは種類も時刻も経路も同じとは限りません。測る相手はゲートウェイと外部の2か所にそろえ、同じ時刻の結果を並べて、自宅の中か外かを分けます。

役割ping・tracert・pathpingの違い

tracertは、TTLが0になったときにルーターが返す「Time Exceeded」の応答を使って経路を調べます。応答を返さないルーターは「*」の行になり、tracertからは見えません。pathpingも経路の探索は同じ仕組みで、そのあとに各ルーターへの応答を集計します。

この仕組みがあるため、pathpingの数字は「そのルーターが、自分宛てや期限切れの調査パケットにどれだけ応答したか」の記録です。ゲームのパケットがそのルーターを通過できたかどうかとは、別の話になります。

手順pathpingを実行する

コマンドプロンプトかPowerShellを開き、まず自宅のゲートウェイ（ルーター）のアドレスを調べます。

ipconfig

「デフォルト ゲートウェイ」に出ているIPv4アドレス（例では192.168.1.1）が、自宅側の測定先です。外部の測定先には、ゲームのサーバーのアドレスが分かればそれを、分からなければGoogle Public DNSの8.8.8.8のように、応答が安定している公開アドレスを使います。

pathping -4 -n -q 100 -p 100 192.168.1.1
pathping -4 -n -q 100 -p 100 8.8.8.8

2つは続けて、できるだけ近い時刻に実行します。所要時間は「-q × -p × ホップ数」が目安で、例の外部宛て（10ホップ）は約100秒でした。

既定値のままでも測れますが、-pの250ミリ秒は待ち時間が長くなります。例では-pを100ミリ秒に縮めました。Microsoftは、バースト的な損失の影響を避けるため、要求は十分にゆっくり送るよう書いています。間隔を詰めすぎると、結果そのものが変わることがあります。

実行すると、最初に経路の一覧が出て、続いて「統計を〇〇秒間計算しています」と表示されたまましばらく待ちます。この間に各ルーターへの要求を送っています。今回の外部宛て（10ホップ、-q 100、-p 100）では、表示は100秒でした。

見方結果の列を読む

まず、損失が出なかった例です。ゲートウェイ宛ては次のようになりました。

            ソースからここまで   このノード/リンク
ホップ  RTT    損失/送信 = Pct  損失/送信 = Pct  アドレス
  0                                           192.168.1.19
                                0/ 100 =  0%   |
  1    3ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1 

外部宛て（8.8.8.8）は10ホップで、すべての行が0/100＝0％でした。往復時間（RTT）は、2ホップ目が18ms、宛先の10ホップ目が6msです。

Microsoftのドキュメントの例には、損失が出た結果も載っています。リンク（「|」の行）で13％が失われている一方、ルーターの行で3％や1％の損失が出ていても、自分宛てではないトラフィックの転送には影響しません（Microsoftの記述）。ルーター自身宛ての損失と、通過するパケットの損失は分けて読みます。

tracertの「*」も同じです。今回、同じ経路をtracertで取ったところ、7ホップ目の3回目だけ「*」になりました。しかしpathpingでは、そのルーターは100回中100回応答しています。1回の「*」は、損失があった証拠になりません。

実測途中のホップだけ100％と出た例

IPv6でGoogle Public DNS（2001:4860:4860::8888）を、-6 -q 50 -p 100で測ったとき（そのため出力は0/50表記）、9ホップ目だけが100％になりました。アドレスのうち自宅側と回線会社側の行は伏せています。

            ソースからここまで   このノード/リンク
ホップ  RTT    損失/送信 = Pct  損失/送信 = Pct  アドレス
  0                                           （自分のIPv6アドレス）
                                0/  50 =  0%   |
  1    2ms     0/  50 =  0%     0/  50 =  0%  （ルーター）
                                0/  50 =  0%   |
 （2〜3ホップ目は伏せています。損失はすべて0/50）
  4    5ms     0/  50 =  0%     0/  50 =  0%  2001:3b8:101:e7:110:66:181:185
                                0/  50 =  0%   |
  8    4ms     0/  50 =  0%     0/  50 =  0%  2001:4860:0:1::64cd
                                0/  50 =  0%   |
  9  ---      50/  50 =100%    50/  50 =100%  2001:4860:0:1::5723
                                0/  50 =  0%   |
 10    4ms     0/  50 =  0%     0/  50 =  0%  2001:4860:4860::8888

9ホップ目は50回中50回、返事がありません。しかし、その先の10ホップ目（宛先）には4msで、50回中50回の応答がありました。宛先宛ての要求は9ホップ目を通って往復しているため、通信はこのルーターを通過できています。9ホップ目で起きていたのは、このルーター自身宛ての調査パケットに応答していない、という状態です。

IPv6では、ICMPv6のエラーメッセージを送り出す側のノードは、その送信頻度を制限しなければならない（MUST）とRFC 4443に定められています。経路探索のTime Exceededもこのエラーメッセージに含まれます。IPv4のICMPも、RFC 792では期限切れの応答を「返してもよい」としており、必ず返す仕様ではありません。

この例から言えるのは、「9ホップ目が応答しなかった」ところまでです。応答しない理由が設定なのか、負荷なのかは、手元の出力から決められません。損失が後ろに続いていないので、ここを理由に自宅や回線会社に不具合を申し出る根拠にはなりません。

判断損失のパターンと読み方

ルーターは、1秒あたりに返すICMPの応答数を制限していることが多く、サーバーもICMPの応答を絞っている場合があります。最後のホップに損失が出たときは調べる価値がありますが、それでも「サーバーが応答を絞っているだけ」の可能性が残ります。

確かめる材料になるのは、ゲームのサーバー以外の宛先です。同じ時刻にGoogle Public DNSなど別の宛先も測り、どれにも同じ位置から損失が続くなら、自宅から近い部分の問題が疑われます。1つの宛先だけに出るなら、その宛先の側の事情を疑います。

ゲームゲーム内の表示と照らし合わせる

ゲーム内にPingやパケットロスが表示できる場合は、pathpingを始める前と終わった後の表示を控えます。ゲーム内で損失が出ているのにpathpingがすべて0％なら、ICMPでは見えない種類の問題が残ります。逆に、ゲーム内の表示が安定しているのにpathpingの途中だけ損失が出ているなら、前節の応答の絞りを疑います。

自宅の中の遅延が原因なら、Pingの跳ね方はルーター宛てのPingにも現れます。家庭内の通信量が増えたときの遅延はBufferbloatの記事、有線LANでPingが跳ねるときの切り分けは有線LANの記事が扱っています。

経路IPv4とIPv6を分けて測る

IPv4とIPv6の両方が使える環境では、-4と-6で別々に測ります。今回のPCでは、同じGoogle Public DNSでも、IPv4は10ホップですべて0％、IPv6は10ホップのうち9ホップ目だけが100％でした。経路もルーターも別になるため、片方の結果をもう片方に当てはめられません。

ゲームがどちらで通信しているかは、ゲーム内の接続情報や、Windowsの「netstat」などで宛先アドレスを見て判断します。分からない場合は、両方を測って記録し、どちらかだけに症状が出ていないかを見ます。

記録問い合わせに渡す記録の残し方

結果は画面のスクリーンショットではなく、テキストで保存します。長い出力も欠けずに渡せます。

pathping -4 -n -q 100 -p 100 192.168.1.1 > pathping-gateway.txt
pathping -4 -n -q 100 -p 100 8.8.8.8 > pathping-external.txt

出力の先頭の行（0ホップ目）には、自分のPCのアドレスが入っています。IPv6のアドレスは自宅の回線を特定できる情報なので、公開の場に貼るのは避け、問い合わせの窓口に渡すときだけ使います。

相談先は、結果の形で目安がつきます。ゲートウェイ宛てから損失が続くなら自宅の機器や接続、ゲートウェイは0％で外部のどの宛先にも自宅に近いホップから損失が続くなら回線会社です。特定のゲームだけで症状が出て、他の宛先は0％なら、ゲームの運営に、記録を添えて伝えます。この分け方は目安であり、最終的な原因の特定は、窓口の調査に任せます。

ラグ全体の原因の切り分けはオンラインゲームのラグ改善ガイド、MTUの影響を調べたいときはMTUとPath MTUの記事で扱っています。

FAQよくある質問

まとめまとめ｜損失が続く範囲を見て、断定しない

pathpingは、ゲートウェイ宛てと外部宛てを同じ時刻に測り、損失がどのホップから始まり、後ろへ続くかを見ます。途中の1ホップだけが100％でも、次のホップと宛先が0％なら、そのルーターが調査用の応答を返していないだけで、通過するパケットの損失とは言えません。宛先だけの損失も、サーバーが応答を絞っている可能性が残ります。ゲームの通信はICMPと種類も経路も時刻も違うため、ゲーム内の表示と合わせて読みます。

あわせて読みたい

トラブル・設定

オンラインゲームのラグ改善完全ガイド

トラブル・設定

ゲームでMTUやJumbo Frameを変えるとPingは下がる？Path MTUと断片化をpingで調べる手順