ジッターとは｜目安・測り方・下げ方を計算式4通りと実測で解説

ジッターは「遅いかどうか」ではなく「毎回同じ速さで届くかどうか」を表します。20msごとに送った音声のパケットが、8ms後・35ms後とばらばらに届くと、受け取る側は待ってそろえるか、間に合わなかった分を捨てるしかありません。

flowchart TD
    A[送る側<br>20msごとに送る] --> N[ネットワーク<br>混雑で待ち時間が毎回違う]
    N --> R[受ける側<br>8〜35msとばらばらに届く]
    R --> B[ジッターバッファ<br>少し待ってそろえる]
    B --> P[20msごとに再生]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上で、ip netns で作った3つのネットワーク名前空間（送る側 t89a 10.89.1.1・中継 t89r・受ける側 t89b 10.89.2.2）の中だけで実験しました。遅延のゆらぎは中継に置いた Python 3.13.18 の自作の中継で付け、混雑は中継の tc（iproute2 6.1.0 の tbf・htb）と iperf3 3.16 の TCP で起こしています。この環境のカーネルでは tc qdisc ... netem が「Error: Specified qdisc kind is unknown.」で使えなかったため、netem の書き方は公式の man ページで確かめた範囲だけを載せています。計測は iputils の ping 20240117、iperf3 3.16、tcpdump 4.99.4、自作の UDP 送受信（20msごと・160バイト）と計算スクリプトです。ジッターの定義は RFC 3550・RFC 5481、iperf3 の計算はソースコード、目安は Microsoft Learn と Microsoft サポート、速度テストの定義は Cloudflare の公式ブログで確かめました。ホストの tc・iptables・sysctl は変えず、名前空間は実験のあと削除しています。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

ジッターとは（遅延のゆらぎの意味と単位）

この節では、ジッターが何を表す値なのかと、どんな通信で問題になるのかが分かります。

ジッター（jitter）は、パケットが届くまでの時間（遅延）が、パケットごとにどれだけ違うかを表す値です。英語の jitter は「小刻みに震える」という意味で、日本語では「ジッタ」「遅延のゆらぎ」「遅延変動」とも書きます。単位は ms（ミリ秒、1000分の1秒）で、0に近いほど安定しています。

手元で、送る側から20msごとに UDP のパケットを送り、受ける側で届いた間隔を tcpdump で見ました。左の数字が「前のパケットからの時間」です。

# ゆらぎなし（遅延 40ms で一定）
 00:00:00.000000 IP 10.89.2.254.55959 > 10.89.2.2.5001: UDP, length 172
 00:00:00.019979 IP 10.89.2.254.55959 > 10.89.2.2.5001: UDP, length 172
 00:00:00.020019 IP 10.89.2.254.55959 > 10.89.2.2.5001: UDP, length 172
 00:00:00.019989 IP 10.89.2.254.55959 > 10.89.2.2.5001: UDP, length 172

# ゆらぎあり（遅延 40ms ± 10ms）
 00:00:00.000000 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.017885 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.025834 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.022815 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.018564 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.013133 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.034690 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172
 00:00:00.007949 IP 10.89.2.254.35094 > 10.89.2.2.5001: UDP, length 172

ゆらぎが無いと、送った間隔のまま約20.0msごとに届きました。ゆらぎがあると、7.9ms後から34.7ms後まで、届く間隔がばらばらになりました。平均すればどちらも20msごとですが、音声や映像は「決まった間隔で再生する」ため、間隔のばらつきそのものが途切れや音飛びの原因になります。

• 影響が大きい通信：音声通話・Web会議・オンラインゲーム・ライブ配信など、その場で再生・反映する通信。
• 影響が小さい通信：ファイルのダウンロード・メール・Web ページの表示など、全部そろってから使う通信。全体の時間が少し延びるだけです。

音響機器や電子回路でも、クロック信号のタイミングのずれを「ジッター」と呼びます。この記事はネットワークのジッターを扱います。

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

この節では、ジッターと混同しやすい指標との違いと、セットで見るべき理由が分かります。

レイテンシ（遅延）は「どれだけ遅れて届くか」、ジッターは「その遅れがどれだけ揺れるか」です。遅延が毎回100msでも、毎回同じならジッターは0です。逆に、平均10msでも 1ms と 40ms を行き来すればジッターは大きくなります。

この4つは別々に見えて、つながっています。手元の実験では、回線を埋めるダウンロードを始めると、帯域は同じ約9.4Mbps のまま、遅延が平均0.15ms から30.84ms に、ジッター（遅延の標準偏差）が0.21ms から51.04ms に増えました。さらに、ジッターバッファで待ちきれなかったパケットは「捨てた」扱いになり、使う人から見ればパケットロスと同じになります。

遅延そのものの意味・目安・測り方は、関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」で扱っています。この記事は、その「揺れ」の側に絞ります。

ジッターの計算方法（RFC 3550・平均・最大−最小・標準偏差）

この節では、ジッターの代表的な4つの計算式と、それぞれがどこで使われているかが分かります。

ジッターには「これ1つ」という計算式がありません。RFC 5481 も、遅延の変動にはいろいろな定式化があり、広く使われているのは2つの形だ、と書いています。ツールや記事によって使う式が違うため、数字を比べるときは式をそろえる必要があります。

RFC 3550 のジッター（RTP の interarrival jitter）

音声や映像を運ぶ RTP の仕様 RFC 3550 は、受け取ったパケットごとに次の式でジッター J を更新するよう決めています（6.4.1）。S は送った時刻、R は受け取った時刻です。

D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
J(i)   = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16

• D は「2つのパケットの、運ばれるのにかかった時間の差」です。送る側と受ける側の時計がずれていても、差を取るとずれが消えるため、時計を合わせなくても計算できます。
• 1/16 は、ならし方の強さです。RFC 3550 は、この値が「ノイズをよく減らしつつ、変化にほどよく追いつく」と説明しています。1回だけ遅れたパケットでは J は少ししか動きません。

手元の計算スクリプトの中心はこれだけです。

J = 0.0
for i in range(1, len(rows)):            # rows は (seq, 送った時刻, 受け取った時刻) を届いた順に並べたもの
    d = (rows[i][2] - rows[i-1][2]) - (rows[i][1] - rows[i-1][1])
    J += (abs(d) * 1000 - J) / 16        # ms に直して 1/16 ずつ取り込む

iperf3 の UDP モードが表示する Jitter も同じ式です。iperf3 3.16 のソースコード（iperf_udp.c）には「RFC 1889（RFC 3550 の前の版）の 6.3.1 と A.8 に基づく」とあり、sp->jitter += (d - sp->jitter) / 16.0; と書かれていました。

IPDV と PDV（RFC 5481）

• IPDV（Inter-Packet Delay Variation）：1つ前のパケットとの遅延の差。IPDV(i) = D(i) - D(i-1)。プラスにもマイナスにもなる。
• PDV（Packet Delay Variation）：いちばん速く届いたパケットとの差。PDV(i) = D(i) - D(min)。0以上。

RFC 5481 は、ジッターバッファの大きさを決めるには PDV の範囲（最大−最小）か 99.9% 点が向いており、IPDV とバッファの大きさには確かな関係が無い、としています。「隣どうしの揺れ」と「全体の振れ幅」は別の量です。次の節で、この違いが実測でどれだけ出るかを見ます。

同じ通信でもジッターの値は式で変わる（実測の比較）

この節では、同じパケットの記録から4つの式でジッターを計算すると、値がどれだけ違うかが分かります。

中継の名前空間に、届いた UDP を「40ms ± ゆらぎ」だけ待たせてから送り出す中継を置き、20msごとに500個（10秒分）送りました。ゆらぎは、指定した幅の中で一様にばらつく形（± の幅）と、正規分布（標準偏差）の2通りです。

# 中継の中心（t89r の中で動かす。netem の delay の代わり）
def sample():
    if a.dist == 'normal':
        return max(0.0, random.gauss(a.base, a.jitter))
    return a.base + random.uniform(-a.jitter, a.jitter)

data, _ = rx.recvfrom(2048)
t = time.monotonic() + sample() / 1000      # 送り出す時刻を決めて
heapq.heappush(heap, (t, n, data))          # 時刻順の待ち行列に入れる（別スレッドが時刻になったら送る）

3つの名前空間は同じ計算機の中にあり、時計（CLOCK_MONOTONIC）を共有しているため、片道の遅延をそのまま測れます。実際のネットワークでは送る側と受ける側の時計がずれているので、RFC 3550 のように差を使う式が必要になります。

単位はすべて ms です。読み取れることを3つにまとめます。

同じ500個の記録から、遅延そのものと順番の入れ替わりも数えました。

平均の遅延はどれも約40msで、平均だけを見るとゆらぎの違いは見えません。ゆらぎの幅（± 10ms なら最大20ms の差）が送る間隔の20msを超えたあたりから、後に送ったパケットが先に届く「順番の入れ替わり」が出始めました。

ジッターの目安（Web会議・通話・ゲーム）

この節では、どれくらいのジッターなら問題が無いのかを、公開されている基準で確かめられます。

公式に数字を出しているのは、主に Web会議・通話のサービスです。Microsoft Learn の Teams のトレーニング教材は、ネットワークの性能の目標を2つの区間に分けて示しています。

また、Microsoft サポートの「Teams で通話と会議の品質を監視する」は、通話中の状態表示の目安として、受信のジッター30ms未満・往復時間200ms未満・受信のパケットロス2%未満を挙げています（2026年10月29日時点）。

• ITU-T G.114（片道の伝送時間）は、通話の片道の遅延についての勧告です（最新の版は2003年5月、2009年11月の追補あり）。ジッターの数字はこの勧告の題名には含まれません。上位の解説記事でよく引かれる「片道150ms」は G.114 の数字として紹介されていますが、この記事では ITU-T のページで題名と版までを確かめました。
• オンラインゲームには、共通の公式の基準は見当たりませんでした。ゲームは音声のように大きく待ってそろえることができず、揺れがそのまま操作の遅れやカクつきに出ます。目安はゲームごとの公式サポートの推奨を見ます。
• 動画の視聴（オンデマンド）は数秒分を先読みしてためるため、ジッターの影響は小さくなります。

どの基準も「何の式で」「どの区間を」「どれだけの時間で」測った値かが決まっています。Teams の値は「15秒ごと」の到着間隔のゆらぎです。速度テストに出る1回の数字とは、測り方が同じとは限りません。

ジッターの測り方（ping・iperf3・速度テスト）

この節では、手元でジッターを測る3つの方法と、それぞれの数字の読み方が分かります。

ping の出力からジッターを計算する

回線を埋めるダウンロードを流しながら、ping を20回送った結果です。

$ ping -c 20 -i 0.2 10.89.2.2
64 bytes from 10.89.2.2: icmp_seq=1 ttl=63 time=76.5 ms
64 bytes from 10.89.2.2: icmp_seq=2 ttl=63 time=43.1 ms
64 bytes from 10.89.2.2: icmp_seq=3 ttl=63 time=51.1 ms
64 bytes from 10.89.2.2: icmp_seq=4 ttl=63 time=44.7 ms
64 bytes from 10.89.2.2: icmp_seq=5 ttl=63 time=26.7 ms
...
64 bytes from 10.89.2.2: icmp_seq=19 ttl=63 time=28.5 ms
64 bytes from 10.89.2.2: icmp_seq=20 ttl=63 time=20.3 ms

--- 10.89.2.2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3812ms
rtt min/avg/max/mdev = 20.343/30.584/76.503/13.325 ms

最後の行の mdev は、20回の RTT の標準偏差です。手元で20個の値から標準偏差を計算すると13.34ms（表示が小数1桁に丸められているための差）で、一致しました。同じ出力から3通りで計算するスクリプトです。

# 使い方: ping -c 20 宛先 | python3 pingjitter.py
import re, sys, statistics as st
rtt = [float(x) for x in re.findall(r'time[=<]([\d.]+) ?ms', sys.stdin.read())]
if len(rtt) < 2:
    sys.exit('応答が2つ以上必要です')
diffs = [abs(b - a) for a, b in zip(rtt, rtt[1:])]
print('応答 %d 回  平均 %.2f ms' % (len(rtt), st.mean(rtt)))
print('隣どうしの差の平均  %.2f ms' % st.mean(diffs))
print('最大 - 最小         %.2f ms' % (max(rtt) - min(rtt)))
print('標準偏差（mdev）    %.2f ms' % st.pstdev(rtt))

応答 20 回  平均 30.59 ms
隣どうしの差の平均  6.09 ms
最大 - 最小         56.20 ms
標準偏差（mdev）    13.34 ms

同じ20回の ping で、ジッターは 6.09ms とも 56.20ms とも言えます。1回目だけが 76.5ms と大きく、最大−最小はその1回でほぼ決まっています。Microsoft Learn の ping の説明にある Windows の出力例（Reply from 192.168.239.132: bytes=32 time=101ms TTL=124）の形の行も、このスクリプトで読めることを確かめました。

iperf3 の UDP でジッターを測る

音声に近い形（160バイト・64kbps＝1秒に50個）で8秒送った結果です。サーバー側で iperf3 -s を起動しておきます。

$ iperf3 -c 10.89.2.2 -p 5202 -u -b 64K -l 160 -t 8
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-8.00   sec  62.5 KBytes  64.0 Kbits/sec  0.000 ms  0/400 (0%)  sender
[  5]   0.00-8.00   sec  62.5 KBytes  64.0 Kbits/sec  0.980 ms  0/400 (0%)  receiver

見るのは receiver の行の Jitter です（sender の行は常に0）。混んでいない状態で3回測ると 1.112ms・0.054ms・0.980ms とばらつきました。iperf3 が最後に出すのは、ならし続けた J の「最後の値」なので、終わり際に1回揺れると数字が変わります。何度か測って傾向を見ます。

ping・ip・ss などのコマンドの使い方全体は、関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」で扱っています。

ジッターが大きくなる原因（混雑を再現して確かめる）

この節では、ジッターが大きくなる代表的な原因と、回線の混雑でジッターが生まれる様子を実測で確かめられます。

混雑でジッターが生まれる様子を再現する

中継の名前空間の、受ける側へ出ていく口に「10Mbps・待ち行列は最大300ms分」の制限を付け、静かな10秒 → iperf3 の TCP で回線を埋める10秒 → 静かな10秒、の順に、20msごとの UDP と0.1秒ごとの ping を流し続けました。

# 中継（t89r）の、受ける側へ出ていくインターフェースだけに付けた
$ ip netns exec t89r tc qdisc add dev t89r1 root tbf rate 10mbit burst 32kbit latency 300ms
$ ip netns exec t89r tc qdisc show dev t89r1
qdisc tbf 8004: root refcnt 3 rate 10Mbit burst 4Kb lat 300ms

同じ時間の ping は、前が平均0.03ms（mdev 0.01）、混雑中が平均30.46ms・最大173.00ms（mdev 50.98）、後が平均0.04ms でした。TCP の速さは 9.43Mbps で、帯域は使い切れています。1秒ごとに分けると、何が起きたかが見えます。

iperf3 10.0-20.0 s
 9 s  avg=   0.14  max=   0.26  sd=  0.03  J= 0.03
10 s  avg= 156.52  max= 173.72  sd= 36.73  J= 1.41
11 s  avg=  62.33  max= 173.54  sd= 70.23  J= 2.02
12 s  avg=  11.84  max=  14.65  sd=  1.30  J= 0.87
13 s  avg=  11.42  max=  14.43  sd=  1.03  J= 0.71
...
19 s  avg=  11.37  max=  14.57  sd=  1.12  J= 0.82
20 s  avg=   0.36  max=  10.46  sd=  1.45  J= 0.18

• ダウンロードが始まった瞬間、TCP が速度を上げながら待ち行列を埋め、約1.5秒のあいだ遅延が170ms前後まで跳ねました。そのあと TCP が送る量を調整し、約11msで落ち着きました。Web会議中に誰かが大きなファイルを落とし始めると声が乱れるのは、この形です。
• このとき RFC 3550 の J は 1.39ms と小さいままでした。待ち行列がたまる遅延は、隣どうしでは少しずつしか増えないためです。全体の振れ幅は PDV（99%点 173ms）や標準偏差（51ms）に出ます。RFC 5481 が、バッファの大きさを決めるには PDV を使うとしているのはこのためです。

端末の負荷もジッターを作る

最初に作った送信プログラムは、20ms を待つあいだ CPU を回し続ける書き方でした。CPU 2つの計算機で、ほかの処理も動いている中で送ると、中継で遅延を付けていないのに最大23.12ms 遅れたパケットがあり、標準偏差は2.74ms でした。待つあいだは眠る書き方（time.sleep）に直すと、最大7.72ms・標準偏差0.60ms に下がりました。測る側の端末が忙しいと、ネットワークとは関係なくジッターが出ます。

ジッターで起きること（順番の入れ替わりとジッターバッファ）

この節では、ジッターが大きいとパケットの順番が入れ替わる仕組みと、受け取る側のジッターバッファがどう吸収するのかが分かります。

順番の入れ替わりと、順番を守ると遅延が増えること

遅延のゆらぎが送る間隔より大きいと、後に送ったパケットが先に届きます。± 40ms のゆらぎでは、500個のうち180個が前のパケットを追い越しました。中継で「追い越しを禁止する（前のパケットより先に出さない）」ようにすると、入れ替わりは0になりましたが、平均の遅延が 41.26ms から 49.47ms に増えました。

順番を守る仕組み（TCP や順番を守る待ち行列）では、ジッターは「前のパケットを待つ時間」、つまり平均の遅延の増加に姿を変えます。TCP の上で動く通信が、揺れる回線で全体として遅く感じられるのはこのためです。TCP の遅延の落とし穴は、関連記事「TCPの落とし穴8選｜TIME_WAIT・40ms遅延の正体」で扱っています。

ジッターバッファの効果を模擬する（固定と適応）

ジッターバッファは、受け取ったパケットを少し待たせてから、決まった間隔で再生する仕組みです。待つ時間を長くすると間に合うパケットが増えますが、そのぶん会話全体が遅れます。記録した到着時刻を使い、「送ってから T ms 後に再生する」と決めたとき、間に合わずに捨てたパケットの割合を計算しました（± 20ms のゆらぎ、平均40ms）。

平均の遅延どおりの40msで再生しようとすると、半分以上が間に合いませんでした。ゆらぎの幅の分（約20ms）だけ待つと、ほぼ全部が間に合いました。次に、混雑が途中で起きた記録（前の節の、静か → 混雑 → 静か）で、固定のバッファと、直近1秒の遅延の95%点＋2ms に合わせて待つ時間を変える「適応バッファ」を比べました。

固定のバッファで全部を間に合わせるには、ずっと175ms待つ必要がありました。適応バッファは、静かなときは短く、混雑で揺れたときだけ長く待つため、平均18.2ms の待ちで捨てる割合を1.5%に抑えました。一方、揺れ方が一定の ± 20ms の記録では、適応バッファ（捨てた2.8%・平均59.9ms）は固定の T=60ms（0.4%）を上回りませんでした。適応が効くのは、揺れ方が時間とともに変わるときです。Web会議や通話のアプリは、この種の調整を内部で行っています。

ジッターを下げる対策（使う人：Wi-Fi・回線・機器）

この節では、自宅や職場でジッターが高いときに、使う人が自分でできる対策が分かります。

• 1同じ回線の大きな通信を止めるダウンロード・クラウドの同期・OS の更新・動画の視聴。手元では、これだけで遅延が173msまで跳ねた
• 2Wi-Fi をやめて有線 LAN にする電波の取り合いと再送が無くなる。有線と Wi-Fi で ping の mdev を比べると原因の場所が分かる
• 3Wi-Fi なら近づく・周波数帯を変える5GHz 帯は干渉を受けにくい。壁や距離がある場所では 2.4GHz 帯のほうが安定することもある
• 4ルーター・ONU・端末を再起動する熱や長時間の動作で処理が遅れていることがある。直るなら機器の買い替えや設置場所も見直す
• 5端末の重い処理を止める手元でも、CPU が忙しいだけで最大23ms 遅れたパケットが出た
• 6混む時間帯と空いている時間帯で比べる夜だけ悪いなら回線やプロバイダーの混雑。接続方式（IPv6 の IPoE など）やプランの見直しを検討する

速度テストの結果は、通信していないとき（負荷なし）と、ダウンロード・アップロード中（負荷あり）を分けて見ます。Cloudflare の速度テストは両方の遅延とジッターを表示します。

ジッターを下げる対策（作る人：キューの大きさ・QoS）

この節では、ネットワークを設定する人が、待ち行列の大きさと優先制御（QoS）でジッターを下げる方法と、その効果が分かります。

待ち行列（キュー）を小さくする

前の節と同じ混雑を、待ち行列の上限だけ300ms分から20ms分に変えて起こしました。

$ ip netns exec t89r tc qdisc replace dev t89r1 root tbf rate 10mbit burst 32kbit latency 20ms

待ち行列を小さくすると、TCP の速さはほぼ同じまま、遅延の揺れが約20分の1になりました。代わりに、あふれたパケットが捨てられ、tbf の統計は dropped 87、iperf3 の TCP の再送は134回でした。TCP は捨てられたことで送る量を控えるため、待ち行列が長くたまりません。待ち行列がたまりすぎて遅延が大きく揺れる状態は「バッファブロート」と呼ばれます。

音声のパケットを優先する（QoS）

次に、待ち行列を2つに分け、音声用の印（DSCP の EF。IP ヘッダーの TOS の値で 0xb8）が付いたパケットだけを先に送るようにしました。大きなデータ用の待ち行列は300個までためられる設定のままです。

$ T="ip netns exec t89r tc"
$ $T qdisc add dev t89r1 root handle 1: htb default 20
$ $T class add dev t89r1 parent 1: classid 1:1 htb rate 10mbit
$ $T class add dev t89r1 parent 1:1 classid 1:10 htb rate 1mbit ceil 10mbit prio 0   # 音声用
$ $T class add dev t89r1 parent 1:1 classid 1:20 htb rate 9mbit ceil 10mbit prio 1   # その他
$ $T qdisc add dev t89r1 parent 1:10 handle 10: pfifo limit 50
$ $T qdisc add dev t89r1 parent 1:20 handle 20: pfifo limit 300
$ $T filter add dev t89r1 parent 1: protocol ip prio 1 u32 match ip tos 0xb8 0xfc flowid 1:10

送る側は、UDP は setsockopt(IPPROTO_IP, IP_TOS, 0xb8)、ping は ping -Q 0xb8 で印を付けました。

どちらも TCP の速さは約9.4Mbps でした。iperf3 の UDP（64kbps）でも、混雑中のジッターは印なしで6.825ms、--tos 0xb8 を付けると0.009ms でした。優先された音声のパケットは、混雑していない時と同じ遅延で通り抜けました。

アプリを作る側でできること

• リアルタイムの音声・映像は UDP（RTP・WebRTC）で送り、受け取る側にジッターバッファを置きます。遅れたパケットを待つより、捨てて次を再生したほうが会話は自然です。
• 受け取る側で RFC 3550 の J・パケットロス・遅延を記録し、ジッターが増えたら画質やビットレートを下げます。送る量を減らすと待ち行列も短くなります。
• 計測では、平均だけでなく PDV の99%点や最大を残します。平均の遅延は、ゆらぎが大きくても約40msのまま変わりませんでした。

なお、API のリトライで待つ時間をばらつかせる「ジッター」は、ここでのジッターとは別の意味です（同時に再送が集中しないよう、わざと待ち時間に揺れを足す）。そちらは関連記事「指数バックオフとは？リトライ間隔の決め方とジッターの実装」で扱っています。

tc netemでジッターを再現する方法（Linux）

この節では、Linux の tc netem でテスト用に遅延のゆらぎを付ける書き方と、使えないときの代わりの方法が分かります。

Linux では、tc の netem を使うと、ネットワークの口に遅延・ゆらぎ・損失を付けられます。tc-netem の man ページにある書き方です（この環境では netem が使えなかったため、書き方は man ページで確かめた範囲です）。

# 遅延 100ms に、ゆらぎ 10ms を付ける（DELAY := delay TIME [ JITTER [ CORRELATION ]]）
tc qdisc add dev eth0 root netem delay 100ms 10ms

# ゆらぎの分布を指定する（uniform | normal | pareto | paretonormal）
tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal

# ランダムな損失を付ける
tc qdisc change dev eth0 root netem loss random 1%

# ゆらぎで順番が入れ替わるのを避ける（man ページの例）
tc qdisc add dev eth0 root handle 1: netem delay 10ms 100ms
tc qdisc add dev eth0 parent 1:1 pfifo limit 1000

# 外す
tc qdisc del dev eth0 root

• man ページは「ゆらぎが十分に大きいと、パケットの順番も入れ替わる」と書いています。入れ替わりを避けたいときは、netem の中の待ち行列（tfifo）を単純な FIFO の待ち行列に置き換えます（上の例）。手元の中継でも、追い越しを禁止すると入れ替わりは0になり、平均の遅延が増えました。
• 自分の PC の外向きの口に netem を付けると、その PC のすべての通信が遅くなります。試すときは、ネットワーク名前空間（ip netns）や検証用の仮想マシンの中の口に付けます。

この環境で netem を付けようとしたときのエラーです。

$ ip netns exec t89a tc qdisc add dev t89va root netem delay 40ms 10ms
Error: Specified qdisc kind is unknown.

このエラーは、カーネルに netem の機能（sch_netem）が読み込めないときに出ます。同じ環境で tbf・htb・pfifo は使えたため、この記事では、遅延のゆらぎは名前空間の中に置いた自作の中継で付け、混雑による揺れは tbf と htb で作りました。

よくあるエラー・つまずき

この節では、ジッターを測ったり再現したりするときによく出るエラーと、つまずきやすい点が分かります。

tcpdump のエラーは、.deb を展開しただけの tcpdump を動かしたときに出ました（パッケージを入れるときに作られる利用者がいないため）。ping は通るのに通話やアプリがうまく動かないときの切り分けは、関連記事「ネットワークの切り分け8選｜pingは通るのに繋がらない」で扱っています。

判断表：ジッターが高いときにどこを見るか

この節では、ジッターが高いと分かったときに、原因の場所を順に絞り込む手順が分かります。

1. 1端末で重い処理や通信が動いていないか止めて下がるなら端末側。手元では CPU が忙しいだけで最大23ms
2. 2有線と Wi-Fi で比べる有線で下がるなら Wi-Fi（距離・干渉・周波数帯）
3. 3ルーターまでの ping と、外の宛先への ping を比べるルーターまでで揺れるなら家庭・社内の中。外だけなら回線から先
4. 4負荷なしと負荷ありで比べる負荷ありだけ跳ねるなら待ち行列（バッファブロート）。QoS・キューの設定
5. 5時間帯で比べる夜だけ悪いなら回線やプロバイダーの混雑。接続方式やプランを見直す
6. 6アプリの品質表示を見るTeams などは通話中のジッター・ロスを表示する。公開の目安と比べる

よくある質問

Q. ジッターとは何ですか？ A. 通信の遅延が、パケットごとにどれだけ揺れるかを表す値です。単位は ms で、小さいほど安定しています。遅延が大きくても毎回同じならジッターは0です。

Q. ジッターの目安は何msですか？ A. Web会議・通話では30ms未満が公開されている目安です。Microsoft Teams は、端末から Microsoft のネットワークまでの全体で15秒ごとに30ms未満、社内ネットワークの出口から先で15ms未満を求めています。ゲームには共通の公式の基準は見当たりませんでした。

Q. ジッターとレイテンシ（Ping 値）の違いは？ A. レイテンシは遅延の大きさ、ジッターは遅延の揺れです。ping の avg がレイテンシ、mdev（標準偏差）や、各回の差の平均がジッターの目安になります。

Q. ジッターはどう計算しますか？ A. よく使われるのは「隣どうしの遅延の差の平均」です。RTP や iperf3 は、その差を1/16ずつ取り込んでならす RFC 3550 の式を使います。ほかに最大−最小、標準偏差もあり、同じ20回の ping で6.09ms・56.20ms・13.34ms と大きく違いました。

Q. Windows でジッターを測るには？ A. ping -n 20 宛先 で20回送り、各回の time= の値の差を計算します。この記事の Python のスクリプトは、Microsoft Learn に載っている英語の出力例の形の行を読めることを確かめました。ブラウザの速度テストでも測れます。

Q. ジッターが高い原因は何ですか？ A. 回線や機器の混雑（待ち行列の待ち）、Wi-Fi、機器の性能や熱、端末の負荷、経路の変化です。手元では、同じ回線で大きなダウンロードを始めただけで遅延が0.15ms から173ms まで跳ねました。

Q. 回線が速い（Mbps が大きい）のにジッターが高いのはなぜですか？ A. 帯域と揺れは別の量だからです。手元の実験では TCP が約9.4Mbps を使い切っている間も、待ち行列が長いと遅延が大きく揺れ、待ち行列を小さくすると速さはそのままで揺れが約20分の1になりました。

Q. ジッターバッファとは何ですか？ A. 受け取ったパケットを少し待たせてから、決まった間隔で再生する仕組みです。待つほど間に合うパケットは増えますが、会話全体が遅れます。± 20ms の揺れでは、平均どおりに再生すると54%が間に合わず、約20ms 余分に待つとほぼ全部が間に合いました。

Q. QoS を設定するとジッターは下がりますか？ A. 混雑が起きる機器に設定すれば下がります。手元では、音声の印（DSCP EF）が付いたパケットを優先すると、混雑中のジッター（RFC 3550）が20.08ms から0.02ms になりました。自分の管理外のインターネットの区間では効くとは限りません。

Q. 有線にすればジッターは必ず下がりますか？ A. Wi-Fi が原因なら下がりますが、回線の混雑や端末の負荷が原因なら変わりません。有線と Wi-Fi で同じ時間に測り比べると、どちらが原因か分かります。

Q. 指数バックオフの「ジッター」と同じものですか？ A. 別のものです。リトライの「ジッター」は、再送が同時に集中しないよう、待ち時間にわざと揺れを足す工夫のことです。ネットワークのジッターは、意図せず生まれる遅延の揺れです。

まとめ

• ジッターは遅延の揺れ（ms）。レイテンシ（遅延の大きさ）とは別で、平均の遅延が同じ約40msでも、揺れの大きさで順番の入れ替わりや途切れが変わった。
• 計算式は1つではない。隣どうしの差の平均、RFC 3550 の J（iperf3 も同じ）、最大−最小、標準偏差（ping の mdev）で、同じ ping 20回から6.09〜56.20ms と値が変わった。比べるときは式をそろえる。
• Web会議の目安は30ms未満（Teams：端末からの全体で15秒ごと）。社内の出口から先は15ms未満。
• 大きな原因は混雑による待ち行列。ダウンロードの開始で遅延が約1.5秒間173msまで跳ね、待ち行列を小さくすると最大22ms、音声を優先（QoS）すると混雑中でも0.06ms のままだった。
• 受け取る側はジッターバッファで吸収する。揺れが一定なら固定、混雑で揺れ方が変わるなら適応型が有利で、適応型は平均18.2ms の待ちで捨てる割合を1.5%に抑えた。

次に読むとよい記事です。遅延の大きさそのものは関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」で、ネットワークの切り分けは関連記事「ネットワークの切り分け8選｜pingは通るのに繋がらない」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• IETF「RFC 3550 RTP: A Transport Protocol for Real-Time Applications」6.4.1・A.8：https://www.rfc-editor.org/rfc/rfc3550
• IETF「RFC 5481 Packet Delay Variation Applicability Statement」：https://www.rfc-editor.org/rfc/rfc5481
• Microsoft Learn「Understand Teams network requirements」：https://learn.microsoft.com/en-us/training/modules/plan-optimize-network-performance-for-teams-phone-system/2-understand-teams-network-requirements
• Microsoft サポート「Monitor call and meeting quality in Microsoft Teams」：https://support.microsoft.com/en-us/topic/7bb1747c-d91a-4fbb-84f6-ad3f48e73511
• Microsoft Learn「ping」（Windows Commands）：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping
• ITU-T「G.114 : One-way transmission time」：https://www.itu.int/rec/T-REC-G.114
• Linux man-pages「tc-netem(8)」：https://man7.org/linux/man-pages/man8/tc-netem.8.html
• ESnet iperf3 のソースコード「iperf_udp.c」（3.16）：https://github.com/esnet/iperf/blob/3.16/src/iperf_udp.c
• Cloudflare ブログ「How does Cloudflare's Speed Test really work?」（2025年10月27日）：https://blog.cloudflare.com/how-does-cloudflares-speed-test-really-work/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。