Ping・パケットロステスト

仕組み

1. 他のダウンロードやストリーミングを閉じる. テスト中に別の端末やアプリが帯域を使うと、負荷時遅延の数値が実際の回線とは無関係な理由で膨らんでしまいます。
2. 有線接続を優先するか、ルーターの近くに座る. Wi-Fiは回線本来の性能に加えて独自の遅延とジッターを上乗せします — 有線ならその影響を切り離せます。
3. 開始を押してタブを前面に保つ. ブラウザはバックグラウンドタブを遅くするため、このテストが依存するタイミング計測が静かに狂ってしまいます。
4. まず無負荷時の遅延、次に負荷時の遅延を確認する. 最初のフェーズは静止状態の回線を測定し、次のフェーズは同じ遅延プローブと並行してダウンロードを開始し、混雑時にどれだけ遅くなるかを見ます。
5. ロス率ではなく安定性カウンターを読む. ロス率は存在しません（理由は後述）— 代わりに、応答のなかったプローブ数と、異常に遅く返ってきたプローブ数がほぼ同じことを教えてくれます。
6. 混雑時間帯にもう一度実行する. 遅延とバッファブロートは生の速度よりも時間帯に敏感です — 夜間の結果は昼間と大きく異なることがあります。

このテストが実際に測っているもの（そしてなぜ「Ping」という呼び方がやや不正確なのか）

`ping` コマンドは生のICMPパケットを送信し、応答時間を計測します。Webページはそれができません — ブラウザはICMPにも生のソケットにもアクセスできず、これはWebページが許可なくファイルを読めないのと同じサンドボックスの制約によるものです。そこでこのテストは、最も誠実な代替手段を採ります。Cloudflareのネットワークへの通常のHTTPSリクエストの時間を計測し、サーバー自身が報告する処理時間を差し引くことで、ネットワークの往復時間だけを残します。

• これはシミュレーションや推定ではなく、実際に測定された往復時間です — ICMPの代わりにHTTPSを使うだけです。
• 同じ宛先へのターミナルpingより数ミリ秒高く出るのが普通です。サーバーの処理時間を差し引いた後でも、TLSで保護されたHTTP通信は単純なICMPエコーより多少コストがかかるためです。
• 特定のゲームサーバーや通話サービス、Webサイトではなく、Cloudflareのエッジロケーションまでの経路を測定しています — 「自分の回線が全般的にどれくらい良いか」の目安として扱ってください。

このページにパケットロス率がない理由

単に数値を省略するのではなく、はっきり説明する価値があります。これは欠けている機能ではなく、意図的な選択だからです。

• 通常のWebリクエストの土台となるTCPは、失われたデータを自動的かつ見えない形で再送します。失われたパケットは失敗するのではなく、1回の再試行の後に遅れて届くだけです。
• つまりHTTPリクエストの時間を計測するWebページは、失われたパケットをロスとして認識することが原理的にできません — 見えるのは遅い応答だけで、一見すると通常の輻輳と区別がつきません。
• そのデータから「パケットロス0%」を算出するツールは、低いロス率を報告しているのではなく、ロスを検知できなかったことを報告しているにすぎません。これは不安定な回線をトラブルシューティングしている人にとってはまったく別の意味を持ちます。
• 本当のパケットロス計測には、ロスを隠さないプロトコル — 生のICMPやUDP — が必要ですが、これはまさにブラウザが送信を許可されていないものです。

代わりにこのテストが報告するのは、十分な猶予を設けたタイムアウト内に応答がまったくなかったプローブの数と、通常より大幅に遅く返ってきたプローブの数です — 直接カウントはできなくても、再送が起きた可能性を示す兆候です。どちらもロスそのものではありませんが、どちらもブラウザが実際に集められる最も近い証拠です。

遅延・ジッター・最悪ケース:それぞれの数値の意味

このテストは無負荷時の遅延フェーズから、関連しつつも異なる3つの数値を報告します。

• 遅延（ms）:典型的な往復時間 — 技術的にはすべてのプローブの中央値で、平均値と違い1つの遅い外れ値に左右されにくい指標です。
• ジッター（ms）:その往復時間がプローブごとにどれだけ変動するか — 平均的にどれだけ高いかではありません。平均遅延がそこそこ良くても、ジッターが高いと通話が途切れがちに感じられます。
• 最悪ケース（ms）:95パーセンタイルの往復時間 — 通話やゲームで実際に気づく数値に近く、非常に遅い1回の瞬間は典型的な瞬間よりはるかに目立ちます。

バッファブロート:ダウンロードが始まった瞬間に回線が重くなる理由

これはほとんどの速度テストが完全に見落としている数値であり、「誰かが何かをダウンロードし始めるまでは回線が快調」の実際の原因であることがよくあります。

• ほとんどのルーターやモデムは、送信前に送信データをバッファでキューに入れます — これは合理的な考え方ですが、そのバッファが回線に対して過大な場合に問題が起きます。
• 大きなダウンロードやアップロードがそのバッファを満たすと、このテストの遅延プローブや通話・ゲームのあらゆるパケットを含む他のすべてのパケットが、その後ろで順番待ちをしなければなりません。
• 結果として、回線が空いているときは問題なかった遅延が、何かが回線を飽和させた瞬間に20msから300ms以上へと跳ね上がり、終わるとまた元に戻ります。
• このテストはまさにそれを測定します。遅延プローブを送り続けながらバックグラウンドで飽和させるダウンロードを実行し、その前後の遅延を比較します。

評価はA+からFまであり、負荷時に遅延がどれだけ増加するかに基づきます — A+はほとんど気づかない程度の数ミリ秒、Fは数百ミリ秒で、同じ回線でスマホがクラウドバックアップを始めた瞬間に通話が途切れるような急上昇です。

用途別に見る良い数値の目安

唯一の「良い」数値というものはありません — 何が重要かは回線上で何をしているかに完全に依存します。

• 音声通話:ジッターが低ければ、往復約200ms未満で快適 — ほとんどのVoIPコーデックには映像より多くを平滑化できるバッファがあります。
• ビデオ通話:遅延150ms未満、ジッター30ms未満なら安定して感じられます。バッファブロート評価がCより悪い場合、誰かが他にオンラインになるたびに通話が途切れる実際の原因であることがよくあります。
• オンラインゲーム:ジッターが低く50ms未満なら競技用途に最適。カジュアルなプレイの多くでは50〜100msで問題ありません。
• クラウドゲーミング:最も厳しいケース — 入力だけでなく映像フレーム全体が往復するため、非常に低いジッターで40ms未満が必要です。
• 閲覧・ストリーミング・ダウンロード:ここでは遅延はほとんど関係ありません — 実際にこれらを左右する数値はインターネット速度テストをご覧ください。

そのため、このテストは3つの生の数値を自分で解釈させるのではなく、これらの各用途について直接判定を表示します。

Wi-Fi・VPNなど、結果を悪化させる要因

悪い結果を回線そのものの問題と決めつける前に、独自の遅延を加えている可能性が高い要因を除外しましょう。

• Wi-Fi:独自の遅延を追加し、特に混雑した2.4GHz帯や重なり合うネットワークが多い集合住宅では独自のジッターも加わります — 多くの場合、実際の回線そのものより大きな影響を与えます。
• VPN:すべてのパケットを追加のサーバー（多くの場合遠方）経由でルーティングし、暗号化のオーバーヘッドに加えて実際の往復距離を追加します。
• 過負荷のルーター:古いまたは非力なルーターは、実際のインターネット回線とは無関係に負荷時の処理遅延を追加することがあり、外から見るとバッファブロートと見分けがつきません。
• バックグラウンドアプリ:クラウド同期や自動更新、同じネットワーク上の他の端末が、無負荷のテストのつもりが実は静かに回線を飽和させていることがあります。

原因を切り分ける最速の方法は、他をすべて一時停止して有線でテストを実行し、次に普段通りのバックグラウンド負荷のままWi-Fiで再度実行することです — 両者の差が、問題が実際にどこにあるかを教えてくれます。

結果が本当に問題を示している場合

不安定な結果のほとんどは上記のいずれかで説明がつきます。ISPに相談する価値が本当にあるパターンはもっと少数です。

• 有線接続でバッファブロート評価がDまたはFで、複数回のテストで確認された場合 — ISPが対応していれば、現代的なキュー管理（SQMやfq_codelと呼ばれる）でISP側から改善できることが多いです。
• 有線接続で、近くのCloudflareロケーションへの無負荷時遅延が100msを大きく超え、時間帯を問わず一貫して高い場合 — これは自宅内ではなく、上流のルーティングや輻輳の問題を示しています。
• VPNを使っていない有線接続で、応答のないプローブが多い場合 — スクリーンショットとともに再現・報告する価値があります。プロバイダーのネットワークに実際の問題がある可能性を示すためです。
• 午前3時は問題ないのに毎晩一貫して悪い場合 — ローカルなネットワーク輻輳であり、その具体的なパターンをISPに直接伝える価値があります。

よくある質問