レイテンシ・ジッター・パケットロスの違い｜実務で使う判断基準の目安値

はじめに

回線速度を測ると十分な数値が出ているにもかかわらず、Web 会議の音声が途切れる、リモートデスクトップの操作が引っかかる、といった相談を受けることがあります。監視ツールや測定サイトには レイテンシ・ジッター・パケットロス という 3 つの値が並んでいるものの、どの値がいくつになったら問題なのかは、意外と整理されていません。

この 3 指標は互いに独立しており、1 つが良好でも別の 1 つが悪ければ体感品質は落ちます。原因の切り分けを進めるには、それぞれが何を表し、どの通信に効いてくるのかを分けて理解する必要があります。

結論を先に述べると、レイテンシは遅延の大きさ、ジッターはその遅延のばらつき、パケットロスは届かなかった割合であり、3 つは別々の現象です。実務で品質劣化として顕在化しやすいのは、平均レイテンシよりもジッターとパケットロスのほうです。判断基準としては、Microsoft が公開している Optimal / Poor の閾値と、ITU-T G.114 の片道遅延 150ms が実用的な出発点になります。

レイテンシ・ジッター・パケットロスの違い

3 指標はいずれもパケットの届き方に関する値ですが、着目している対象が異なります。レイテンシは「届くまでの時間」、ジッターは「その時間の揺らぎ」、パケットロスは「そもそも届いたかどうか」です。順に整理します。

レイテンシ: 遅延の大きさ

レイテンシ（Latency）は、パケットが送信元から宛先へ届くまでに要する時間です。表現方法には片道遅延（One-way Delay）と往復遅延（RTT: Round-Trip Time）の 2 つがあり、ping や traceroute が表示するのは RTT のほう です。片道遅延は送信側と受信側で時刻同期が必要になるため、簡易な測定では RTT を 2 で割った値を片道遅延の目安として扱います。

レイテンシは単一の要因ではなく、次の要素の合計として決まります。

• 伝搬遅延: 信号が物理的な距離を進むのに要する時間。光ファイバー中の伝搬速度は真空中の光速より遅く、おおむね 20 万 km/s 程度になる
• 伝送遅延: パケットをインターフェースへ送り出すのに要する時間。パケットサイズと回線速度で決まる
• 処理遅延: ルーターやファイアウォールでの経路検索、検査などの処理時間
• キューイング遅延: 出力キューで順番待ちをする時間。輻輳時に大きくなる

このうち伝搬遅延は物理的な下限であり、機器の設定では改善できません。たとえば直線距離 400km 程度の区間では、伝搬遅延だけで片道 2ms 前後（RTT で 4ms 前後）が理論上の下限となり、実際の経路は直線ではないため、これより大きい値になります。

実務で注目すべきは、変動するのは主にキューイング遅延だという点 です。回線が混雑して出力キューにパケットが滞留すると、この成分が増加します。優先制御によってキューイング遅延の配分を変える考え方は、関連記事『QoS とは｜優先制御の仕組みと製品共通で押さえる設計のポイント』で扱っています。

ジッター: 遅延のばらつき

ジッター（Jitter）は、レイテンシの変動を表す値です。同じ経路を通っていても、キューの混み具合や経路変更によって 1 パケットごとの遅延は揺らぎます。この揺らぎの大きさがジッターです。

RTP における厳密な定義は RFC 3550 の 6.4.1 節にあり、パケットの到着間隔の統計的なばらつきの推定値として規定されています。

参考: RFC 3550（RTP: A Transport Protocol for Real-Time Applications）
“An estimate of the statistical variance of the RTP data packet interarrival time”
（RTP データパケットの到着間隔の統計的な分散の推定値）
https://datatracker.ietf.org/doc/html/rfc3550

ここで注意したいのは、同じ「ジッター」という語でも、測定手法によって計算方法が異なる 点です。RFC 3550 の定義は直近のサンプルを重み付けした平滑化された推定値であり、ping の結果から標準偏差を求めた値とは一致しません。ツールが表示する数値を比較する際は、算出方法が同じかどうかを確認することをおすすめします。この違いは後半の測定セクションで詳しく扱います。

ジッターが問題になる理由は、リアルタイム通信の受信側がジッターバッファを持つ点にあります。受信側は届いたパケットを一時的に蓄え、一定間隔で再生することで揺らぎを吸収します。しかしバッファの容量を超える遅れで到着したパケットは、再生時刻に間に合わず廃棄されます。つまり、ジッターが大きい状態は、パケットロスが発生していなくても、アプリケーションから見れば実質的な損失として現れます。

なお、揺らぎを吸収するためにバッファを深くすると、その分だけエンドツーエンドの遅延が増えます。ジッター対策とレイテンシ短縮は、この点でトレードオフの関係にあります。

パケットロス: 届かなかった割合

パケットロス（Packet Loss）は、送信されたパケットのうち宛先へ届かなかったものの割合です。一定の測定期間に対する百分率で表します。主な発生要因は次のとおりです。

• 輻輳によるキュー溢れ: 出力キューが満杯になり、後続のパケットが破棄される。最も多い要因
• 物理層のエラー: ケーブルの劣化、コネクタの接触不良、無線区間の干渉など
• ポリシングによる破棄: 契約帯域や設定した上限を超えた通信を意図的に破棄する動作
• 機器の処理能力の超過: CPU 使用率の高騰などにより、転送処理が追いつかない状態

判断にあたって押さえておきたいのは、同じ損失率でも、欠落の分布によって体感が大きく変わる 点です。1000 パケット中 10 パケットが均等に分散して失われた場合と、10 パケットが連続して失われた場合では、いずれも損失率 1% ですが、後者は音声が明確に途切れます。損失率の平均値だけでは、バースト的な欠落を見落とす可能性があります。

また、フラグメント化されたパケットでは影響が拡大します。分割されたフラグメントのうち 1 つでも失われると、IP には部分再送の仕組みがないため、元のパケット全体が失われます。この点は関連記事『MTU/MSS とは｜PPPoE・IPsec で通信が止まる原因と対策』で詳しく扱っています。

3 指標の比較

3 指標の性質を整理すると次のようになります。

この表で注目したいのは、レイテンシだけが物理的な下限を持つ 点です。地理的に離れた拠点との通信では、レイテンシは一定以上下げられません。一方でジッターとパケットロスは、理論上はゼロに近づけられます。海外拠点との接続で「レイテンシは大きいが安定している」状態と、「レイテンシは小さいが揺らいでいる」状態では、後者のほうが対処すべき問題を抱えている可能性が高くなります。

3 指標が体感品質に与える影響の違い

3 指標のうちどれが問題として顕在化するかは、対象がどのプロトコルで通信しているかによって変わります。同じ 1% のパケットロスでも、ファイル転送では「遅くなる」現象として現れ、音声通話では「途切れる」現象として現れます。この違いを押さえておくと、症状から原因を絞り込みやすくなります。

TCP 通信と UDP 通信で現れ方が変わる理由

TCP には再送とフロー制御の仕組みがあるため、パケットが失われても最終的にデータは届きます。ただし TCP は、パケットロスを回線が混雑している兆候として解釈し、送信レートを下げます。

参考: RFC 5681（TCP Congestion Control）
“loss is an indication of congestion”
（損失は輻輳の兆候である）
https://datatracker.ietf.org/doc/html/rfc5681

つまり TCP 通信におけるパケットロスは、データの欠落ではなくスループットの低下として観測されます。この影響の大きさは、RTT とロス率の組み合わせで決まります。Mathis らが 1997 年に示したモデルでは、TCP のスループット上限はおおむね次の関係で表されます。

スループット ≦ (MSS ÷ RTT) × (1 ÷ √p)     p: パケットロス率

MSS を 1460 バイトとして計算すると、単一セッションのスループット上限の目安は次のようになります。

注目したいのは、わずか 0.1% のロスでも、RTT が 100ms あるとスループットが数 Mbps 台まで下がる 点です。「回線は 1Gbps 契約なのに、遠隔拠点へのファイル転送が数 Mbps しか出ない」という事象は、帯域ではなく RTT とロスの組み合わせで説明できる場合があります。

ただしこのモデルには前提があります。ロス率が 1% 未満の範囲を対象としたモデルであること、単一セッションが輻輳回避フェーズで動作していることを想定していること、そして現在広く使われている CUBIC や BBR は挙動が異なることです。あくまで桁感をつかむための目安として扱うことをおすすめします。

一方 UDP には再送の仕組みがありません。失われたパケットはそのまま欠落し、上位のアプリケーションが補完するか、欠落したまま再生されます。またジッターについても、TCP は受信バッファで順序を整えてからアプリケーションへ渡すため影響が見えにくいのに対し、リアルタイム通信ではジッターバッファを超える遅れが廃棄につながります。

3 指標とプロトコルの関係を整理すると次のようになります。

なお UDP を使う通信でサイズ超過の問題が絡むと、切り分けはさらに難しくなります。MSS は TCP 固有の仕組みであり UDP には効かないため、前掲の MTU/MSS の関連記事もあわせて確認しておくと切り分けが進めやすくなります。

音声・Web 会議で最初に破綻する指標

Web 会議の品質問題では、帯域よりも先に遅延系の指標が効いてきます。Microsoft が公開している Teams の帯域要件では、1 対 1 の音声通話に推奨される帯域は上り下りとも 58kbps とされており、映像や画面共有を含めても数 Mbps の範囲です。一般的なブロードバンド回線であれば、帯域そのものが不足することは多くありません。

参照: https://learn.microsoft.com/en-us/microsoftteams/prepare-network

そのため、「速度測定では十分な数値が出ているのに会議が不安定」という状況では、帯域ではなくジッターとパケットロスを疑うのが順当です。指標ごとの症状は次のように現れます。

• パケットロス: 単語や音節が抜ける、映像がブロック状に乱れる、画面共有が固まる
• ジッター: 音声が途切れがちになる、機械的な音質になる、映像と音声がずれる
• レイテンシ: 発話が重なる、相手の反応を待って会話のテンポが崩れる

このうち利用者から最初に指摘されやすいのはパケットロスとジッターによる症状です。レイテンシによる会話の重なりは、利用者が「回線の問題」として認識しにくく、報告として上がりにくい傾向があります。

どこからが「悪い」のか: 公開されている目安値

ここまで整理した 3 指標について、公開されている判断基準を確認します。ベンダー各社がさまざまな目安値を示していますが、一次情報として出典をたどれるものは限られます。ここでは Microsoft と ITU-T の 2 つを取り上げ、あわせて数値を引用する際の注意点を整理します。

Microsoft が示す Optimal / Poor の閾値

Microsoft は、リアルタイムメディアの品質を保つための指標として、次の閾値を公開しています。

参照: https://learn.microsoft.com/en-us/previous-versions/skypeforbusiness/optimizing-your-network/media-quality-and-network-connectivity-performance

この表を使う際は、あわせて示されている前提条件を確認しておくことをおすすめします。実務で誤用しやすい点は次の 4 つです。

測定対象の区間が限定されている

この値は、社内ネットワークから Microsoft のネットワークエッジまでの区間を対象としたものです。エンドツーエンドの全区間に対する基準ではありません

同一大陸内であることが前提

レイテンシの目標値は、拠点と Microsoft のエッジが同じ大陸にある場合を想定しています

単発の測定値ではなく 90 パーセンタイル値で比較する

1 週間程度の測定を推奨し、10 分ごとのサンプルから 90 パーセンタイル値を取って比較する方法が示されています

各指標は RFC 3550 の定義に基づく

特にジッターは、前述のとおり算出方法によって値が変わります

ジッターの Optimal 値が 3ms と、かなり厳しい水準に設定されている 点は注目に値します。一般的な家庭用回線でこの値を安定して満たすのは容易ではありません。Optimal を「これを下回らなければ問題」と読むのではなく、目標水準と許容限界を示す 2 つの目盛りとして扱うのが実態に合います。

ITU-T G.114 の片道遅延 150ms

レイテンシの基準として広く参照されているのが、ITU-T 勧告 G.114 です。この勧告では、片道の伝送時間が 150ms を下回れば、音声・非音声を問わずほとんどのアプリケーションで対話性に問題が生じないとされています。また上限についても言及があります。

参考: ITU-T Recommendation G.114（One-way transmission time）
“delays above 400 ms are unacceptable for general network planning purposes”
（400ms を超える遅延は、一般的なネットワーク計画上受け入れられない）
https://www.itu.int/rec/t-rec-g.114-200305-i

ここで実務上まぎらわしいのが、G.114 の 150ms は片道の値であり、ping が表示する RTT とは基準が異なる 点です。RTT に換算すればおおむね 300ms 相当となり、Microsoft の Optimal 値である RTT 60ms とは、そもそも比較している対象が違います。異なる出典の数値を並べる際は、片道か往復かを必ず確認することをおすすめします。

なお G.114 は 1996 年版・2000 年版も存在し、現行版は 2003 年 5 月承認のものです。引用する際はどの版を参照したかを明示しておくと、後から検証しやすくなります。

よく引用される数値の出典を確認する際の注意点

ここまで示した数値は現在も広く引用されていますが、出典の位置づけには注意が必要です。

前掲の Microsoft の閾値表は、Skype for Business Online の retired（提供終了）扱いのドキュメント上に残っているもの です。ページの最終更新は 2017 年 11 月、Skype for Business Online 自体も 2021 年 7 月に提供を終了しています。一方、現行の Teams 向けネットワーク準備ページ（最終更新 2026 年 5 月）を確認すると、記載されているのは帯域要件が中心で、レイテンシ・ジッター・パケットロスの閾値表は掲載されていません。

つまり、「Teams の推奨値」として各所で引用されている 3 指標の閾値は、現行の Teams ドキュメントではなく、アーカイブ扱いのページに由来します。G.114 についても 2003 年版が最新であり、いずれも古い基準である点は共通しています。

これらの数値が実務で無意味になったわけではありません。リアルタイムメディアの要求水準は当時から大きく変わっておらず、判断の出発点としては引き続き有用です。ただし、次の 2 点は意識しておくことをおすすめします。

• 社内の設計基準や SLA に転記する場合は、出典の URL と参照日を併記する。後任者が根拠をたどれる状態にしておく
• 現行の環境に即した数値が必要な場合は、公開値ではなく実測に基づく判断を優先する。Microsoft は Teams Network Assessment Tool と Call Quality Dashboard を提供しており、自社環境の実データから基準を設定できる

公開されている目安値は「どのくらいの水準を目指すか」の出発点として使い、最終的な判断は自環境の測定値で行う、という位置づけが実態に合います。

測定方法と、ping では分からないこと

3 指標を測る手段には、ping や mtr のようなコマンドラインツールと、ブラウザベースの測定サイトがあります。いずれも手軽ですが、測定できる範囲と、そもそも測定できない項目がそれぞれ異なります。数値を判断材料にする前に、その値が何を測ったものかを把握しておくことをおすすめします。

ping・mtr で分かる範囲

ping は RTT とパケットロスを測る最も基本的な手段です。既定の実行回数は少ないため、傾向をつかむには回数を増やして実行します。

Windows の場合は次のように実行します。

ping /n 100 <宛先>

主なオプションは次のとおりです。

参照: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping

Linux の場合は次のようになります。

ping -c 100 -i 0.2 -D -O <宛先>

参照: https://man7.org/linux/man-pages/man8/ping.8.html

このうち -Oは、欠落したパケットを出力上で確認できるようにするオプションです。man page でも -Dと組み合わせてログに残し、応答が欠けた箇所を探す用途が示されています。継続的にログを取りながらロスの発生タイミングを特定したい場合に有用です。

ping の集計行にも注意点があります。Linux の iputils 版は min/avg/max/mdev を表示しますが、この mdev は平均偏差であり、標準偏差とは異なります。Windows の ping は最小・最大・平均のみを表示し、ばらつきを表す統計値を出力しません。ジッターを評価する目的では、Windows の ping 出力だけでは不十分です。

経路のどこで劣化しているかを見るには mtr が有効です。各ホップに対して継続的にプローブを送り、ホップごとのロス率と RTT の統計を表示します。

mtr --report --report-cycles 100 <宛先>

ただし ping と mtr には共通の限界があります。ICMP は経路上の機器において、実際に転送されるトラフィックとは異なる扱いを受ける場合があります。Microsoft も、リアルタイムメディアの品質評価という文脈で次のように述べています。

参考: Microsoft Learn（Media Quality and Network Connectivity Performance in Microsoft Teams）
“Measuring network performance through ping (ICMP) is not effective”
（ping（ICMP）によるネットワーク性能の測定は有効ではない）
https://learn.microsoft.com/en-us/previous-versions/skypeforbusiness/optimizing-your-network/media-quality-and-network-connectivity-performance

背景には、ICMP の応答生成が機器の制御プレーンで処理されること、QoS の扱いが実トラフィックと異なること、そして実際のメディア通信が UDP である場合に経路や優先度が一致しないことがあります。中間ホップの RTT が高く表示されていても、そのホップの転送性能に問題があるとは限りません。mtr の出力を読む際は、中間ホップの値そのものより、最終ホップの値と、あるホップ以降で一貫して悪化しているかどうかに注目することをおすすめします。

RFC 3550 のジッター定義と ping の標準偏差の違い

前述のとおり、ジッターは算出方法によって値が変わります。実務でツール間の数値を比較する際は、この違いが混乱の原因になりやすいため、整理しておきます。

ping の結果から標準偏差を求める方法は、測定期間中の全サンプルを対象とした統計値です。一方 RFC 3550 の interarrival jitter は、附録 A.8 にアルゴリズムが示されており、直近のサンプルに重みを置いた指数移動平均として算出されます。この方式では、突発的な遅延のスパイクが数値に反映されるまでに時間差が生じ、また平滑化によって値が小さめに出る傾向があります。

つまり、同じ回線を同じタイミングで測っても、ping ベースのツールと RTP ベースの監視では表示されるジッターの値が一致しません。前述の Microsoft の閾値（Optimal < 3ms）は RFC 3550 の定義に基づく値であり、ping の標準偏差と直接比較できるものではない点には注意が必要です。

実務上の対処はシンプルです。異なるツールの数値を横並びで比較せず、同一ツール・同一条件で時系列の変化を追う ことをおすすめします。絶対値よりも、平常時と問題発生時の差分のほうが判断材料として有用です。

ブラウザ測定ではパケットロスが見えない理由

ブラウザベースの測定サイトは手軽ですが、パケットロスについては原理的な制約があります。

ブラウザから発生させられる通信は、基本的に HTTP/HTTPS（TCP）か WebRTC です。このうち TCP を使う測定では、パケットが失われても再送によって回復するため、アプリケーション層からは欠落として観測できません。前述のとおり、TCP におけるロスはスループットの低下として現れます。したがって、TCP ベースの測定ツールが「パケットロス 0%」と表示していても、経路上でロスが発生していないことの証明にはなりません。

正確なロス率を測るには、再送を伴わない UDP ベースの測定が必要です。ブラウザ上では WebRTC の DataChannel を使う方法がありますが、実装が複雑になる割に精度が出にくいため、簡易ツールでは採用されないことが一般的です。

この制約を踏まえたうえで、ブラウザ測定が有用な場面もあります。負荷をかけた状態と無通信時のレイテンシを比較する用途であれば、TCP ベースでも十分に意味のある値が得られます。当ブログでも、この考え方に基づいた『回線品質診断ツール』を公開しています。パケットロスについては測定できない旨を明示したうえで、負荷時の遅延増加とジッターを判断材料として提示する構成にしています。

数値が悪いときの切り分け

数値が基準を下回っていた場合、次に必要なのは原因箇所の特定です。やみくもに機器を確認するのではなく、切り分けの順序を決めておくと調査時間を短縮できます。ここでは 2 段階の切り分けを紹介します。

常時悪いのか、負荷時だけ悪いのか

最初の分岐は、劣化が常時発生しているのか、通信量が増えたときだけ発生するのか の判別です。この 2 つは原因も対処も異なります。

判別の手順はシンプルです。無通信の状態で ping を継続実行しておき、その状態のまま大容量のファイル転送などで負荷をかけ、同じ ping の数値がどう変化するかを観察します。結果の読み方は次のとおりです。

このうち 「アイドル時は良好だが、負荷をかけると大きく悪化する」パターンは、輻輳時のキュー制御に改善余地がある ことを示唆します。速度測定では良好な数値が出るにもかかわらず Web 会議が不安定になる、という事象の典型的な背景です。この状態への対処として、限られた帯域の配分を制御する考え方は、前掲の QoS の関連記事で扱っています。

宅内・無線区間と ISP 区間の切り分け

劣化が常時発生している場合、次は経路上のどこで発生しているかを絞り込みます。手元に近い側から順に確認していくと、確認範囲を段階的に狭められます。

Cisco の遅延トラブルシューティング資料でも、traceroute で問題のあるホップを特定したうえで、そのホップ間で直接 ping を実行して確認する手順が示されています。

参照: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9300-series-switches/225617-troubleshooting-network-latency-and.html

切り分けを進めるうえで、あわせて確認しておきたい観点が 2 つあります。

時間帯による差 です。夜間や業務時間帯にのみ劣化する場合、宅内機器ではなく上位区間の輻輳が要因である可能性が高くなります。同じ測定を複数の時間帯で実施し、再現性を確認することをおすすめします。

測定回数と代表値の取り方 です。前述のとおり、Microsoft は 1 週間程度の測定を推奨し、10 分ごとのサンプルから 90 パーセンタイル値を取って比較する方法を示しています。単発の測定で判断すると、たまたま良好だった瞬間や、逆に一時的なスパイクを捉えて誤った結論に至る可能性があります。問題の報告を受けた際は、まず継続測定を仕掛けてデータを集めることが、遠回りに見えて確実な進め方 です。

まとめ

レイテンシ・ジッター・パケットロスは、いずれもパケットの届き方に関する指標ですが、着目している対象が異なります。速度測定で十分な数値が出ているにもかかわらず品質が低下している場合、原因は帯域ではなく、この 3 指標のいずれかにあることが少なくありません。判断基準としては公開されている目安値が出発点になりますが、出典の前提条件と測定手段の限界を理解したうえで使うことが、誤った結論を避けるうえで有効です。

• レイテンシは遅延の大きさ、ジッターはその揺らぎ、パケットロスは欠落の割合
• ロスは TCP でスループット低下、UDP では欠落としてそのまま現れる。
• 物理的な下限を持つのはレイテンシのみで、残る 2 指標は改善の余地あり
• 広く引用される Microsoft の閾値表は retired 扱いのドキュメント由来
• ITU-T G.114 の 150ms は片道の値で、ping の RTT とは基準が異なる。
• ICMP は実トラフィックと扱いが異なり、ping の値には限界がある。
• 切り分けはアイドル時と負荷時の比較から始めるのが効率的

以上、最後までお読みいただきありがとうございました。