パケットロスとジッターの測り方｜Pingが低くてもゲームが不安定な原因

PRが含まれています

最終更新日：2026年8月31日

「Pingは15msなのに敵がワープする」「速度測定では問題ないのに、対戦中だけ操作が引っかかる」。このような症状は、平均Pingだけでは説明できません。

ゲームの通信を調べるときは、Pingの平均値に加えて、遅延の変動、パケットロス、連続した欠損、負荷をかけたときの変化を確認する必要があります。さらに、通信が正常でも、PCのフレームタイムやゲーム側の処理によって画面がカクつく場合があります。

この記事では、ブラウザーとWindowsの標準機能で測定する手順から、数字の読み方、原因別の対処法まで解説します。自宅のルーター・外部の測定先・実際のゲームを比較し、買い替えや回線変更の前に確認すべき場所を絞り込みます。

情報確認日：2026年8月30日。数値例のうち「独自計算」「仮想データ」と記載したものは説明用の計算であり、筆者宅や特定回線の実測結果ではありません。操作画面や表示項目は更新により変わる場合があります。

ゲーム内表示・ブラウザー・連続Pingを組み合わせる

最初はゲーム内の通信統計を確認し、次にブラウザーで品質を測り、異常が続く場合にルーターと外部への連続Pingで切り分けます。すべての測定を一度に行う必要はありません。

順番	確認すること	分かること
1	ゲーム内のPing・ロス・FPSを表示する	実際の対戦中に、通信と描画のどちらが悪化しているか
2	Cloudflare Speed Testを同じ条件で測る	その測定先への遅延・ジッター・ロスの傾向
3	ルーターと外部へ600回のPingを送る	宅内側と外部側のどちらで異常が観測されるか
4	有線とWi-Fi、無負荷と負荷ありを比較する	接続方法や家族の通信が症状に関係するか

ここでいう「無負荷」は、大容量のダウンロードや同期を意図的に止めた状態です。家庭内の通信を完全にゼロにするという意味ではありません。

Ping・ジッター・パケットロスは何が違う？

Pingは往復にかかった時間、ジッターは遅延の変動、パケットロスは届かなかったデータの割合を調べる指標です。どれか一つだけでは、ゲーム中の安定性を判断できません。

指標	意味	見落としやすい点
Ping／RTT	要求を送って応答が戻るまでの往復時間。単位はms	平均値では短時間の急上昇が目立たない
ジッター	パケットの遅延がどの程度変動するか	測定ツールによって定義や集計方法が異なる
パケットロス率	対象としたパケットのうち、受信できなかった割合	短い測定では低頻度の損失を見逃す
最大連続欠損数	応答や更新が続けて欠けた回数	同じロス率でも、まとまって欠けると影響が違う
負荷時遅延	ダウンロード・アップロード中の遅延	普段のPingが低くても、通信が重なると悪化することがある
フレームタイム	PCが1枚の映像を描画するのにかかる時間	通信遅延とは別の原因で画面が止まることがある

たとえるなら、Pingは配達の所要時間、ジッターは配達時間のばらつき、パケットロスは荷物の欠落です。「平均すると早く届く」ことと「毎回、必要なタイミングで届く」ことは別です。

WindowsのpingコマンドはICMPの応答と往復時間を確認する機能です。ゲーム内のPing表示は、そのゲームが用意した別の方法で測られている場合があります。また、往路と復路は対称とは限らないため、RTTを2で割った値を正確な片道遅延とは見なせません。出典：Microsoft Learn「ping」。

Pingが低いのにゲームが不安定になる主な原因

低いPingが出ていても、測定先が違う、表示が平均化されている、通信以外が詰まっている場合は、ラグやカクつきが発生します。

原因候補	起こり得る症状	確認方法
瞬間的な遅延の増加	普段は軽いが、ときどき操作が遅れる	平均だけでなく時系列・最大値・遅い側の分布を見る
パケットロス	位置が巻き戻る、敵が飛ぶ、更新が止まる	ゲーム内のロス表示と発生時刻を記録する
Wi-Fi区間の不安定さ	場所や時間によって症状が変わる	同じ端末でルーター直結の有線LANと比較する
通信が重なったときの順番待ち	バックアップやダウンロード中だけラグが増える	無負荷・ダウンロード中・アップロード中を分けて測る
ゲームまでの経路・サーバー側	特定のゲームや地域だけ不安定	別の外部測定先、別ゲーム、公式障害情報を比較する
PCの描画・処理	通信統計は変わらないのに画面全体が止まる	FPS、フレームタイム、CPU・GPU負荷を確認する

Intelも、パケットロスは高速回線で発生し得ること、ケーブル・NIC・ルーター・混雑・ゲームサーバーなど複数の原因があることを説明しています。症状だけでプロバイダーの不具合と決めつけることはできません。出典：Intel「パケットロスを解決する方法」。

ブラウザーでパケットロスとジッターを測る方法

ブラウザー測定は全体の傾向を確認する入口として使い、実際のゲーム通信とは分けて評価します。

Cloudflare Speed Testで項目を確認する

ブラウザーで手軽に調べるなら、Cloudflare Speed TestのLatency・Jitter・Packet Lossをセットで確認します。

ゲームの対戦をいったん終え、動画再生や大容量同期を止めます。
Cloudflare Speed Testを開き、測定が最後まで終わるのを待ちます。
Latency、Jitter、Packet Loss、測定先の場所を記録します。
詳細の無負荷時・ダウンロード中・アップロード中の遅延を確認します。
同じ端末・接続方法で3回測り、それぞれの結果を残します。

ロスが「－」や未完了の場合は、0％ではなく測定結果を取得できていない状態として扱います。エラーの理由を確認し、別の測定方法を併用してください。測定のためだけにファイアウォールを無効化する必要はありません。

Cloudflareの公式説明では、ジッターは連続するRTT測定の変動を使い、ロスはWebRTCのTURNサーバーを介して測定します。また、このテストは常に回線を使い切って最大速度を出す設計ではありません。したがって、良い結果でも実際のゲーム経路や完全な帯域飽和時の安定性まで保証するものではありません。出典：Cloudflare「How does Cloudflare’s Speed Test really work?」。

ブラウザー測定とゲーム内測定の違い

外部の速度テストが正常でもゲームが不安定なら、実際のゲーム通信を優先して確認してください。測定先、経路、通信方式、集計時間が異なるため、数字が一致しないことはあります。

測定方法	向いていること	限界
ゲーム内の統計	対戦中のPing・ロス・FPSと症状を結び付ける	項目や計算方法はタイトルごとに異なる
Cloudflare Speed Test	ブラウザーで遅延・ジッター・ロスを確認する	ゲームサーバーへの通信そのものではない
Windowsのping	指定した相手への応答・RTT・応答欠損を継続確認する	ジッターやP95は標準の集計欄には表示されない
pathping	経路と途中の応答状況を補助的に調べる	途中の応答欠損だけでは転送障害を断定できない

例えばApex Legendsでは、設定の「ゲームプレイ」から「パフォーマンス表示」を有効にすると、FPS・遅延・パケットロスを確認できます。ゲーム機でも、対応タイトルの統計表示があれば利用できます。出典：EA公式「Apex LegendsのPing・パケットロス・ラグの対処」。

Windowsでパケットロスを測る手順｜ルーターと外部を比較する

Windowsでは、接続先を確認してから連続Pingを実行し、外部だけでなく宅内側の結果も残します。

1．接続方法とデフォルトゲートウェイを確認する

外部だけにPingを送る前に、自宅のルーターまで正常に通信できているか確認します。Windows PowerShellを開き、次のコマンドを入力してください。

ipconfig

ipconfigをオプションなしで実行すると、各アダプターのIPアドレスやデフォルトゲートウェイを確認できます。出典：Microsoft Learn「ipconfig」。

現在使用している「イーサネット」または「Wi-Fi」の欄から、IPv4の「デフォルトゲートウェイ」を探します。以下では例として192.168.1.1を使用しますが、自分の画面に表示されたアドレスに置き換えてください。VPNや仮想アダプターの欄と取り違えないようにします。

最初の基準測定では、可能ならPCをルーターのLANポートへ直接つなぎます。メッシュ子機から先だけを有線にしても、子機と親機の間が無線なら、経路にWi-Fi区間が残ります。

2．ルーターと外部へ600回ずつPingを送る

ルーター宛てと外部宛てを別ウィンドウで同時に測ると、異常の発生時刻を比較しやすくなります。どちらも通常は管理者権限なしで実行できます。

1つ目のPowerShellでは、ルーターを測定します。

ping.exe -4 -n 600 -w 1000 192.168.1.1

2つ目では、外部の比較先を測定します。

ping.exe -4 -n 600 -w 1000 1.1.1.1

指定	意味
-4	IPv4で測定する
-n 600	600回送信する
-w 1000	各応答を待つ上限を1,000msにする

所要時間は通常およそ10分ですが、応答状況などで長くなることがあります。600回はこの記事で採用する初期診断用の回数であり、公的な合格基準ではありません。中断はCtrl＋Cです。オプションの定義はMicrosoft公式ドキュメントで確認できます。

外部の比較先を変える場合は、次の測定で1.1.1.1を8.8.8.8などに置き換えます。これらはゲームサーバーではありません。また、ここでIPアドレスを指定してPingを送っても、PCのDNS設定は変更されません。

「-4」はIPのバージョンの指定です。契約によってはIPv4 over IPv6を通るため、この指定だけでPPPoE／IPoEを判別することはできません。

ルーターが最初から一度も応答しない場合、ICMPへの応答をしない設定の可能性があります。インターネットを利用できているなら、その結果だけで宅内ロス100％と判断しないでください。

3．発生時刻を残したい場合はログを保存する

「何時何分にワープしたか」とPingの変化を照合できるログがあると、平均値だけの記録より切り分けに役立ちます。

外部宛ての測定を、次のコマンドに置き換えると、PowerShellが各出力行を受け取った時刻を付けて保存できます。

ping.exe -4 -n 600 -w 1000 1.1.1.1 | ForEach-Object { "$(Get-Date -Format o) $_" } | Tee-Object -FilePath "$env:USERPROFILE\ping-internet-01.txt"

保存先は自分のユーザーフォルダーです。ルーター側も同じ形式で残す場合は、宛先を変更し、ファイル名を「ping-router-01.txt」にします。再測定時は末尾を02、03と変え、前の結果を上書きしないようにしてください。

この時刻はパケットの厳密な送受信タイムスタンプではなく、症状とおおまかに照合するための記録です。通常のPingは細かなゲーム更新をすべて観測するものではないため、一瞬の異常を取り逃がす可能性があります。

4．割合と回数を両方確認する

ロスは「何％か」だけでなく、「何回送って何回応答しなかったか」を残します。

例えば600回中3回の応答を確認できなければ、応答欠損率は3÷600×100＝0.5％です。表示の丸めに左右されないよう、送信数と損失数から計算してください。

「宛先ホストに到達できません」などのエラー表示は、目的の相手との通信成功ではありません。集計欄だけでなく、各行に対象からの正常な応答と時間が記録されているかも確認します。

ただし、Pingのタイムアウトは「指定時間内にICMPの応答を受け取れなかった」という結果です。往路・復路の損失、遅すぎる応答、相手側の応答制限などを含む可能性があり、ゲームのUDPパケットが同じ割合で失われた証明にはなりません。待ち時間を変えた測定同士も単純比較できません。

ジッターの計算で「最大値－最小値」だけを使わない理由

最大Pingから最小Pingを引いた値は「測定期間全体の変動幅」です。すべてのツールのジッターと同じ値になるわけではありません。

IETFのRFC 5481は遅延変動の複数の定式化を扱っています。音声・映像で使われるRTPのRFC 3550にも、送受信間隔の差を平滑化する独自の計算式があります。単位がどちらもmsでも、異なる指標をそのまま比べることはできません。出典：RFC 5481、RFC 3550・6.4.1節。

独自計算：平均も最大・最小も同じなのに、揺れ方は違う

Pingの並び順を残すと、最大・最小・平均が同じ測定でも、安定性の違いを説明できます。

次の8回分の仮想データを比べます。単位はすべてmsです。

項目	測定A：途中で一度変化	測定B：毎回変化
Pingの順番	10、10、10、10、20、20、20、20	10、20、10、20、10、20、10、20
平均Ping	15ms	15ms
最大値－最小値	10ms	10ms
隣り合うRTTの絶対差の平均	約1.43ms	10ms

この記事では比較用に、隣り合うRTTの差を絶対値にして合計し、差の個数で割る方法を使っています。Aは10÷7≒1.43ms、Bは70÷7＝10msです。

これはRTTの揺れ方を説明するための計算で、RTPのジッターや特定ツールの内部実装と同一だとするものではありません。タイムアウトを0msとして混ぜたり、欠損の前後を通常の連続サンプルとして扱ったりすると、値を誤解しやすくなります。

測定結果を比較するときは、ツール・測定先・通信方式・間隔・測定時間をそろえてください。「サイトAでは2ms、サイトBでは10msだった」だけでは、回線が悪化したとはいえません。

平均Pingが同じでもゲームの安定性は違う｜P95で比較する

平均Pingは全体をならした値なので、遅い側の値や発生回数も合わせて見ると、短時間の引っかかりを見つけやすくなります。

P95は、値を小さい順に並べたときの95％地点にある値です。ここでは小さい順に並べ、サンプル数×0.95を切り上げた順位の値を採用します。ツールによっては補間など別の方法を使います。

項目	安定したケース	遅延が混じるケース
測定値の内訳	20msが100回	10msが90回、110msが10回
平均Ping	20ms	20ms
P95	20ms	110ms
最大Ping	20ms	110ms
ロス率	0％	0％

後者の平均は、（10×90＋110×10）÷100＝20msです。平均とロス率だけを比べると同じですが、10回に1回は110msになっています。

ただし、P95も万能ではありません。例えば極端に遅い値が100回中1回だけなら、P95には反映されないことがあります。P95・最大値・時系列・症状の発生時刻を組み合わせて判断します。Pingの成功応答だけからP95を計算した場合は、欠損数も別に示してください。

標準pingはP95を自動表示しません。生ログの成功応答を集計するか、分布を確認できるツールを使います。MicrosoftのPsPingにはヒストグラム機能がありますが、ヒストグラムの区間から読める値と、生データから求める正確なP95は区別してください。

パケットロス0％でも安心できない理由｜測定回数と連続欠損

ロス率の読み方で重要なのは、観測する機会が十分だったかと、欠損が集中していないかの2点です。

独自計算：50回のPingでは1％のロスを見逃しやすい

「50回測ってロス0％」は、その50回で損失を観測しなかったという意味で、常にロスがない証明にはなりません。

各試行が独立し、毎回同じ確率pで応答を失う単純なモデルでは、n回の測定で少なくとも1回の損失を観測する確率は次の式です。

検出確率 ＝ 1 − (1 − p)^n

測定回数	実際のロス率が1％	実際のロス率が0.1％	1回欠損したときの割合
50回	約39.5％	約4.9％	2％
100回	約63.4％	約9.5％	1％
300回	約95.1％	約25.9％	約0.333％
600回	約99.8％	約45.1％	約0.167％

1％のロスがあっても、50回では約60.5％の確率で一度も観測しない計算です。一方、0.1％のようにまれな損失では、600回でも見逃しが多く、3,000回でようやく検出確率が約95.0％になります。

これは回線の正常・異常を95％の精度で判定できるという意味ではありません。現実の損失は混雑時に集中するなど、独立・一定確率という仮定から外れます。そのため、回数だけ増やすより、症状が出る時間帯や操作を含めて測ることが大切です。

独自計算：同じロス率1％でも、10回連続で欠けると違う

平均ロス率に加えて連続して欠けた数を確認すると、短時間の大きな停止を見逃しにくくなります。

説明用に、1秒に60個の更新を等間隔で送り、合計1,000個のうち10個を失う通信を考えます。ゲームのサーバー更新頻度と実際の送信パケット数は同じとは限らないため、これは特定タイトルの仕様ではありません。

損失の起こり方	全体のロス率	正常な更新から次の正常な更新までの最大間隔
1個ずつ、離れた箇所で10回欠損	1％	約33.3ms：2÷60秒
途中で10個連続して欠損	1％	約183.3ms：11÷60秒

計算では遅延の揺れ・再送・補間・冗長化を考慮せず、欠損した更新の前後は正常に届くと仮定しています。10個分の送信時間は約166.7msですが、直前の正常な更新から次の正常な更新までの間隔は11区間なので約183.3msです。

実際の画面が183.3ms止まると断定できるわけではありません。ゲームごとに予測や補正があるためです。それでも、同じ1％を一律に「許容できる」と判断しない理由は分かります。

なお、通常の約1秒間隔のPingで見つけた連続欠損を、この60個／秒のモデルへ置き換えることはできません。連続欠損数と測定間隔は必ずセットで記録します。

測定結果から原因を絞る｜宅内・外部・ゲームの比較表

同じ時間帯に「ルーター」「外部の比較先」「ゲーム」のどこで異常が出るかを見ると、次に調べる場所を絞れます。以下は原因の確定表ではなく、確認の優先順位です。

観測された組み合わせ	優先する原因候補	次の確認
Wi-Fiではルーター・外部とも悪化し、有線では改善	宅内の無線区間	距離、周波数帯、設置場所、メッシュの中継区間を比較
有線でもルーター・外部が同時に悪化	PC、ケーブル、LANポート、ルーター周辺	別ケーブル・別ポート・別端末で再現するか確認
ルーターは安定し、複数の外部先とゲームが悪化	ルーターのWAN処理、回線、共通する外部経路	無負荷・負荷あり、別時間帯、別端末を比較
外部の比較先は安定し、特定ゲームだけ悪化	そのゲームの経路、サーバー、クライアント	公式障害情報、ゲーム内統計、接続地域を確認
通信統計は安定し、FPSやフレームタイムだけ悪化	描画・CPU処理・温度・ドライバーなど	画質や負荷を変え、通信とは別に検証
ルーターへのPingだけ悪化し、外部とゲームは正常	ルーター自身のICMP応答の扱い	ルーターへの応答だけを根拠に故障としない

ルーター宛てPingは、そのルーター自身の応答を測っています。WANへの転送処理をすべて検査するわけではありません。また、別々の公開IPでも経路の一部を共有する場合があるため、2つ測れば完全に独立した検査になるわけではありません。

無負荷・ダウンロード中・アップロード中を分ける

負荷時だけ悪くなるなら、回線の最高速度より、通信が重なったときの待ち時間に注目します。

同じ測定先へのPingを続けながら、普段行うダウンロードやバックアップを一つだけ開始し、開始・終了時刻を残します。対戦中に大容量の速度テストを走らせると、そのテスト自体で症状を作るため、負荷試験は対戦外で行ってください。

条件	平均RTT	無負荷との差
無負荷	15ms	基準
ダウンロード中	25ms	＋10ms
アップロード中	95ms	＋80ms

この例なら上り通信との関係を優先して調べます。ただし、＋80msという差だけで、待ち行列が自宅ルーター・回線・外部経路のどこにあるかまでは特定できません。考え方はバッファブロートとは？ゲーム・配信中にPingが上がる原因で詳しく解説しています。

設定変更の効果は「変更前・変更後」を繰り返して確認する

一度だけ改善した結果より、同じ条件で改善を再現できるかを重視します。

例えば、Wi-Fi→有線→Wi-Fi→有線と交互に測ります。最初と最後では時間帯の混雑が変わるため、「Wi-Fiを1回測って、その後に有線を1回測った」だけでは、接続方法が原因だったと断定しにくくなります。

毎回残すのは、測定先・回数・欠損数・平均・最大・負荷条件です。P95やジッターを集計できる場合は同じ方法で追加します。まず無負荷の条件をそろえ、その後にゲーム中の症状が減ったか確かめます。

途中のルーターでロスが出ても、故障と断定できない

pathpingで途中の機器に応答欠損が表示されても、その機器が実際のゲーム通信を同じ割合で捨てているとは限りません。

外部への問題が繰り返し出る場合は、補助的に次のコマンドを使えます。

pathping -n -4 1.1.1.1

結果が出るまで数分かかることがあります。Microsoftは、機器自身を宛先にしたパケットへの損失と、その機器を通過するパケットの転送能力は分けて読む必要がある例を示しています。出典：Microsoft Learn「pathping」。

表示の例	読み方
途中だけ欠損が多く、最終宛先は安定	途中の応答制限などの可能性。そこで転送障害があるとは断定しない
途中以降と最終宛先で欠損が繰り返される	経路上の問題を疑う材料。ただし、その区間を責任箇所と確定しない
一部のホップが表示されない	診断用パケットに応答しない機器や経路構成の可能性もある

ICMPの扱い、往復経路の違い、経路変更などがあるため、最終宛先の結果とゲームの症状を合わせて読みます。診断コマンドが失敗したことと、サービスが使えないことは区別してください。

過去の公式事例：自宅の回線だけが原因ではない

ゲーム運営元の過去の発表からも、端末・回線・ゲーム側の処理を分けて調べる必要性が分かります。

VALORANT：ネットワークの揺れとゲーム側のバッファー

ゲームの体感遅延には、通信時間に加えて、到着のばらつきを吸収するゲーム側の処理も関わります。

Riot Gamesは2022年4月15日の説明で、ネットワークの揺れを吸収するために処理を少し遅らせる仕組みや、短いネットワーク・性能上の乱れでバッファーが増えた後、回復に時間がかかる問題を調査していると公表しました。出典：Riot Games「VALORANT Gameplay Consistency Update」。

これは当時の説明であり、その不具合が現在も残っていると示すものではありません。ここから分かるのは、Pingの表示だけではゲーム内部の待ち時間を説明し切れない場合がある、ということです。

FFXIV：DDoS攻撃による広域の接続障害

多数の利用者に同時に起きる切断は、家庭内の機器交換では解決しない場合があります。

スクウェア・エニックスは、2024年5月6日22時ごろから5月7日22時33分ごろまで、DDoS攻撃によるネットワーク障害が発生し、切断やログイン・データ送受信の困難が起きる場合があったと公表しています。出典：FFXIV公式「DDoS攻撃によるネットワーク障害復旧のお知らせ（5/7）」。

この事例は現在の不調の原因を示すものではありません。症状が急に始まった場合は、公式障害情報などを確認し、障害の発生時間と自分の記録を照合することが先です。

ほかの測定解説と比較して押さえたい点

短いPingテストや最大・最小の比較は入口として役立ちますが、まれな不調を調べるには測定の条件と限界も確認する必要があります。

比較した解説	役立つ点	この記事で補う点
Intelのパケットロス解説	50回のPingによる確認と基本対処を紹介	50・100・300・600回の検出確率を独自計算し、0％の限界を説明
NIFTYのジッター解説	最大Pingと最小Pingの差で分かりやすく説明	全体の変動幅と、連続するRTTの変動を別々に比較
ブイキューブのジッター解説	到着時間の変動とリアルタイム通信への影響を説明	ゲームで一律の許容値を使わず、同じ定義・条件で症状と照合
INTERNET WatchのPsPing検証	LAN内の有線・無線を分布で比較する実測を掲載	家庭内検証と公開サーバーへの診断を分け、少数の比較先へ穏当な頻度で測定

各記事は対象読者や目的が異なります。別の目的の測定をそのまままねるより、「自宅の無線区間を調べたいのか」「実際のゲームを調べたいのか」を先に決めると、結果を解釈しやすくなります。

改善策は測定結果に合わせて選ぶ｜10ギガへの変更は必要？

買い替えや回線変更の前に、異常が再現する場所を絞り、費用の少ない対策から一つずつ試します。

対策	試す価値が高い状況	利点	注意点・限界
ルーターまで有線で接続	Wi-Fi時に宅内Pingが悪化する	無線区間の影響を比較しやすい	ケーブル・ポート・外部経路の問題は残る
ケーブル・LANポートを交換	有線でも宅内側が不安定	予備があれば低費用で比較できる	規格名だけ上げても、不調の原因が別なら改善しない
同期・ダウンロードの時間分散	大容量通信と症状が一致する	追加費用なしで試せる	通信完了が遅れる場合がある
QoSや帯域上限を調整	通信が重なると遅延が増える	重要な通信の待ち時間を減らせる可能性	効果は機種・設定次第。速度との両立を有効・無効で確認する
公式のファームウェア・ドライバー更新	不具合修正が公開されている	機器の既知の問題へ対応できる	手順を守り、変更前の設定と結果を残す
接続方式やプロバイダーを確認	宅内は安定し、外部だけ時間帯依存で悪化	宅外側の問題を相談できる	IPv6という名称だけで改善が保証されるわけではない
10ギガ回線へ変更	家庭全体の同時通信で帯域を使い切っている	通信容量に余裕ができる可能性	ゲーム側の障害やWi-Fiの不調を直接直すものではない

QoSは、機能名だけで効果を判断せず、実際に有効・無効で比較します。待ち行列を管理する方式の一つであるFQ-CoDelは、異なる通信の干渉や待ち時間を減らすことを目的としています。ただし、すべての「ゲーム優先」機能がこの方式を採用しているわけではありません。出典：RFC 8290：FQ-CoDelの設計。

Pingやロスが良好で、ダウンロード時間だけが不満なら、10ギガ化の検討は別の話になります。ゲーム用途と回線容量の関係は10ギガ回線でオンラインゲームは有利になる？1ギガとの違いを参照してください。

ファイアウォールの全面無効化、DMZへの安易な追加、根拠のないレジストリー変更は、初期診断には必要ありません。変更する場合も公式の案内に沿い、一度に複数の設定を変えないようにします。

パケットロスとジッターのよくある質問

数値の合格・不合格を決める前に、何をどの条件で測った結果かを確認してください。

ジッターは何ms以下ならゲームに問題ありませんか？

すべてのゲーム・測定ツールに共通する合格ラインはありません。同じmsでも定義が違い、ゲームの補正処理やジャンルでも影響が変わります。まず同じ方法で良好時と不調時を比較し、変動が増えた時刻と症状が一致するか確認してください。

ロスが1％未満なら放置してもよいですか？

1％未満でも連続して欠ければ影響する可能性があるため、割合だけで判断しません。一度だけのICMPタイムアウトなら、相手の応答制限なども考えられます。ゲーム内のロス、再現性、発生時刻を確認します。

Pingがタイムアウトしたら、ゲームの通信も失敗していますか？

必ずしも同じではありません。ICMPとゲームの通信は扱いや経路が異なる場合があります。また、UDP自体は確実な配達を保証する仕組みではなく、再送や補正をどう行うかは上位の仕組み次第です。「パケットが失われたら、どのゲームでも同じように再送される」とは考えないでください。出典：RFC 768「User Datagram Protocol」。

スマートフォンやPS5でも測れますか？

スマートフォンはブラウザー測定、ゲーム機は対応ゲームの通信統計を利用するのが入口になります。ただし、別のPCで測った結果は、ゲーム機自身のWi-FiやLANアダプターの正常性を証明しません。できるだけ同じ接続場所・同じ時間帯で、ゲーム機側の表示と比較してください。

VPNを使うと改善しますか？

経路が変わって改善する可能性はありますが、迂回や追加処理で悪化する場合もあります。個人のゲーム用VPNなら有無で比較できますが、結果だけで元の経路のどこが悪いかは特定できません。勤務先などが管理するVPNは、許可なく無効化せず管理者へ相談してください。

問い合わせ前に残す測定メモ

「ラグい」という説明に、発生時刻・測定先・接続方法・欠損数を添えると、回線事業者やゲームのサポートへ状況を伝えやすくなります。

項目	記録する内容
発生日時	年月日、開始・終了時刻、タイムゾーン
回線と機器	契約サービス、ルーター型番、PC・ゲーム機、接続構成
接続条件	有線／Wi-Fi、メッシュの有無、VPNの有無
測定方法	ツール名、宛先、IPv4／IPv6、回数、待ち時間
結果	送信数、応答欠損数、平均・最大RTT、連続欠損数
追加の統計	取得できる場合はジッター・P95と、その算出方法
症状	ゲーム名、接続地域、ワープ・切断などの内容、発生時刻
比較結果	ルーターと外部、有線とWi-Fi、無負荷と負荷ありの違い
実施済みの対策	ケーブル交換、別端末、設定変更と、それぞれの結果

ログにはIPアドレスや端末名などが含まれる場合があります。SNSや掲示板へ全文を公開せず、必要な相手へ必要な範囲だけ共有してください。

主な参考情報

測定機能は提供元の公式資料、過去事例はゲーム運営元の発表を基にし、本文の独自計算とは区別しています。