レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説

レイテンシは「1回の往復にかかる時間」です。1秒に運べる量（帯域幅）とは別の値で、Web ページや API は往復を何回もするため、レイテンシの影響が回数分だけ積み重なります。

flowchart TD
    A[PC・スマホ<br>送る] -->|片道の遅延| R[ルーター・回線<br>距離と混雑]
    R --> S[サーバー<br>処理する]
    S -->|片道の遅延| R2[ルーター・回線]
    R2 --> B[PC・スマホ<br>返事が届く]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.4 LTS・Linux カーネル 6.18。ネットワーク名前空間（ip netns。1台の中に独立したネットワークを作る仕組み）で、PC・ルーター・サーバーの3台分を作りました。ルーターとサーバーの間は TUN デバイス（パケットをプログラムで受け渡す仮想のネットワーク装置）でつなぎ、片道ごとに決めた時間だけパケットを止めて渡す Python 3.11.15 の中継で、往復 0・20・100・300ms の遅延を足しました（tc netem の delay と同じ働き。netem の書き方は man ページで確かめました）。測定は iputils 20240117 の ping・tracepath、traceroute 2.1.5、curl 8.5.0（OpenSSL 3.0.13・nghttp2 1.59.0）、iproute2 6.1.0 の ss、Python の http.client で行い、サーバーは Python の http.server（HTTP/1.1・TLS 1.3）と Hypercorn 0.18.0（HTTP/2）です。目安の値は Peter Norvig 氏の公開表、Microsoft Azure の公式のリージョン間の往復時間、光ファイバーの速さは査読論文、curl の各時間の意味は curl の公式ドキュメント、Windows の ping・tracert・pathping は Microsoft Learn、Mac は Apple サポート、パーセンタイルの考え方は Google の SRE 本、TCP の動きは RFC 5681 で確かめました（確認日 2026年10月23日）。

レイテンシとは（意味・読み方・たとえ）

この節では、レイテンシという言葉の意味と、分野ごとに何を指すのかが分かります。

レイテンシ（latency）は、何かを頼んでから、その結果が始まる（届く）までの待ち時間です。 英語の latent（潜んでいる、表に出ていない）から来た言葉で、日本語では「遅延」「待ち時間」と訳されます。読み方は「レイテンシ」「レイテンシー」のどちらも使われ、意味は同じです。単位は時間で、ネットワークではミリ秒（ms。1000分の1秒）が使われます。

分野ごとの「レイテンシ」の見分け表

同じ「レイテンシ」でも、何から何までの時間かが分野で違います。この記事は主にネットワークと Web・API のレイテンシを扱います。

音声の例では、48,000Hz（1秒に48,000回の値）で256個ずつまとめて処理すると、256÷48,000＝約5.3ms のレイテンシが1回分加わります。配信の例では、YouTube ヘルプが「低遅延」は通常10秒未満、「超低遅延」は通常5秒未満と説明しています。分野が違っても「待ち時間」という意味は同じです。

レイテンシと帯域幅・スループット・ジッター・RTTの違い

この節では、レイテンシと混同しやすい言葉の違いと、どれが体感の速さに効くのかが分かります。

レイテンシは「時間」、帯域幅とスループットは「量」です。 帯域幅は1秒に運べる最大の量（Mbps など）、スループットは実際に運べた量です。ジッターはレイテンシのばらつき、RTT は往復のレイテンシです。

flowchart TD
    L[レイテンシ<br>1往復の時間] --> S[小さいデータ<br>API・ページの開始]
    B[帯域幅<br>1秒に運べる量] --> G[大きいデータ<br>動画・ダウンロード]
    S --> T[体感の速さ]
    G --> T

RTT・ping 値との違い

RTT（Round Trip Time、往復時間）は、往復のレイテンシのことです。 ネットワークでは片道の時間を正確に測るのが難しい（送る側と受ける側の時計を合わせる必要がある）ため、多くの場合、往復の時間を測って「レイテンシ」と呼びます。ping で出る time= の値や、ゲーム画面の「ping 値」は、この RTT です。

帯域幅とレイテンシ、どちらが効くか（実測）

小さいデータはレイテンシで、大きいデータは帯域幅で時間が決まります。 同じサーバーから 1KB・1MB・10MB のファイルを取得し、「遅延なし・速さ10Mbps」と「遅延100ms・速さの上限なし」を比べました。

1KB は、帯域幅が細くても速く、遅延があると遅くなりました。10MB は逆で、帯域幅が細いと遅くなりました。「回線速度（Mbps）が速いのに反応が遅い」ときは、レイテンシを疑います。 速度テストの「ダウンロード 500Mbps」は帯域幅の値で、反応の速さは別に表示される ping 値（レイテンシ）で分かります。

ジッター（レイテンシのばらつき）

ジッターは、レイテンシが毎回どれだけ変わるかです。 往復20ms に片道 ±2ms 程度のばらつきを足して ping を20回送ると、最小と最大で約13ms の差が出ました。mdev がばらつきの大きさ（平均からのずれ）です。

20 packets transmitted, 20 received, 0% packet loss, time 3814ms
rtt min/avg/max/mdev = 16.879/20.971/29.594/2.950 ms

通話・Web 会議・ゲームでは、平均のレイテンシが小さくても、ジッターが大きいと音が途切れたり動きが飛んだりします。受け取る側は、遅れて来たパケットを待つためにバッファ（ためておく場所）を大きくするので、その分レイテンシも増えます。

レイテンシは何で決まる？（距離・機器・混雑・処理）

この節では、レイテンシがどんな時間の足し算でできているのかと、距離から最小のレイテンシを計算する方法が分かります。

レイテンシは「伝わる時間＋送り出す時間＋待つ時間＋処理する時間」の合計です。 どれか1つが大きいと、全体が遅くなります。

距離：光の速さより速くはならない

光ファイバーの中の光は、真空中の約3分の2の速さ（1ミリ秒に約204km）で進みます。 米国の光ファイバー網の遅延を調べた論文（Bozkurt ほか、arXiv:1811.10737）は、ファイバーの中の光の速さを真空の約2/3とし、計算に 204,000km/秒を使っています。つまり、1,000km 離れると、片道だけで約4.9ms、往復で約9.8ms かかります。どんなに機器を速くしても、この時間は減りません。

東京からの直線距離（地球の表面に沿った最短距離）と、この速さで一直線に結んだときの最小の往復時間を Python で計算し、Microsoft Azure が公開しているリージョン間の実際の往復時間（中央値）と並べました。

"""東京からの直線距離と、光ファイバーで一直線に結んだときの最小の往復時間"""
import math
def km(a, b):
    (la1, lo1), (la2, lo2) = [(math.radians(x), math.radians(y)) for x, y in (a, b)]
    h = math.sin((la2 - la1) / 2) ** 2 + math.cos(la1) * math.cos(la2) * math.sin((lo2 - lo1) / 2) ** 2
    return 2 * 6371 * math.asin(math.sqrt(h))      # 地球の半径 6,371km
V = 204                                             # 光ファイバーの中の光の速さ（km/ミリ秒）
tokyo = (35.68, 139.69)
for name, pos in [("大阪", (34.69, 135.50)), ("ロンドン", (51.51, -0.13))]:
    d = km(tokyo, pos)
    print(f"{name}: 約{d:,.0f}km  最小の往復 {2 * d / V:.1f}ms")

Azure の値は、Microsoft Learn「Azure ネットワーク往復待機時間の統計」の、Japan East から Japan West・Korea Central・Southeast Asia・West US・East US・UK South への往復の中央値（2026年7月30日までの30日間）です。実際の往復は、計算上の最小の1.3〜2.8倍でした。 ケーブルは一直線ではなく、海底ケーブルの陸揚げ地点や経由するネットワークを回るため、道のりが長くなります。ロンドンは2.5倍と大きく、直線から大きく外れた道のりを通っていると考えられます。

機器・混雑・処理

• 経由する機器：ルーター・ファイアウォール・VPN 装置は、受け取ったパケットを調べてから送り出します。1台ごとの時間は小さくても、数が多いと積み重なります。
• 混雑：回線やルーターが混むと、パケットが順番待ちの列（キュー）に並びます。夜の時間帯に遅くなる、大きなダウンロード中に ping 値が跳ね上がる、などはこれです。
• Wi-Fi：同じチャンネルを使う周りの機器と、電波を送る順番を取り合います。有線 LAN にするとレイテンシとジッターが小さくなることが多いのはこのためです。
• サーバーの処理：データベースの検索や外部 API の呼び出しを待つ時間は、ネットワークの外のレイテンシです。後の節の curl -w で、ネットワークとサーバーのどちらに時間がかかっているかを分けられます。

レイテンシの目安の早見表（メモリ・SSD・国内・海外）

この節では、「何 ms なら速いのか」を、コンピューターの中から海外まで1つの表で比べられます。

コンピューターの中の処理はナノ秒（ns。10億分の1秒）、ネットワークはミリ秒の単位です。 メモリの読み出しと海外との往復では、100万倍以上の差があります。

Norvig 氏の表は「一般的な PC でのおおよその時間」として公開されているもので、SSD の値は載っていません。SSD のレイテンシは製品の仕様書で確かめます。表のネットワークの値は、データセンター間の専用の回線の値です。家庭やスマホからは、ここに自宅の回線や Wi-Fi、携帯電話網の分が足されます。

用途ごとの目安（ping 値）

NTT東日本の解説では、ping 値の目安を次のように分けています。

この値は国内のサーバーを相手にしたときの目安です。海外のサーバーは、上の表のとおり距離だけで 100ms を超えるので、同じ基準では比べられません。ゲームでは、1秒に60コマ描く画面の1コマが 1000÷60＝約16.7ms なので、往復が数十 ms あると、操作の結果が数コマ遅れて表示されることになります。

レイテンシの測り方（ping・traceroute・curl -w）

この節では、レイテンシを OS ごとのコマンドで測る方法と、出力のどこを見るかが分かります。

ping（Windows・Mac・Linux）

ping は、相手に ICMP（ネットワークの制御用の小さなメッセージ）を送り、返事が来るまでの往復時間を表示します。 往復100ms の遅延を足した相手に、Linux で4回送った出力です。

ping -c 4 10.76.2.2

PING 10.76.2.2 (10.76.2.2) 56(84) bytes of data.
64 bytes from 10.76.2.2: icmp_seq=1 ttl=63 time=101 ms
64 bytes from 10.76.2.2: icmp_seq=2 ttl=63 time=101 ms
64 bytes from 10.76.2.2: icmp_seq=3 ttl=63 time=101 ms
64 bytes from 10.76.2.2: icmp_seq=4 ttl=63 time=101 ms

--- 10.76.2.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 100.561/100.646/100.831/0.108 ms

• time=101 ms：1回ごとの往復時間（RTT）
• rtt min/avg/max/mdev：最小・平均・最大・ばらつき（ジッターの目安）
• 0% packet loss：返事が来なかった割合

Linux と Mac の ping は止めるまで送り続けるので、-c 4 で回数を決めます。Windows の ping は、Microsoft Learn によると既定で4回送り、/n で回数、/t で止めるまで送り続けます。Microsoft Learn の出力例は Reply from 192.168.239.132: bytes=32 time=101ms TTL=124 の形で、time= が往復時間です。

ping の返事が来ないことは、それだけでは「つながらない」の意味になりません。 ICMP をファイアウォールで止めているサーバーは多くあります。Web サーバーなら、次の curl -w で TCP 接続の時間を測ります。

traceroute・tracert・pathping（どこで遅れているか）

traceroute は、途中のルーターごとの往復時間を並べて、どの区間で遅くなるかを見るコマンドです。 PC → ルーター → 遅延100ms の線 → サーバー、という経路で実行しました。

$ traceroute -n -q 3 10.76.2.2
traceroute to 10.76.2.2 (10.76.2.2), 30 hops max, 60 byte packets
 1  10.76.1.1  0.024 ms  0.003 ms  0.002 ms
 2  10.76.2.2  100.474 ms  100.496 ms  100.496 ms

$ tracepath -n 10.76.2.2
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.76.1.1                                             0.037ms 
 1:  10.76.1.1                                             0.007ms 
 2:  10.76.2.2                                           100.757ms reached
     Resume: pmtu 1500 hops 2 back 2 

1つ目（ルーター）までは 0.02ms、2つ目（サーバー）で 100ms に増えたので、ルーターとサーバーの間で遅れていると分かります。 時間は「そこまでの合計」なので、急に増えた所の手前の区間が原因の候補です。途中だけ大きくて先がまた小さい場合は、そのルーターが自分あての返事を後回しにしているだけで、通信は遅れていないことがあります。

Windows では tracert（既定で最大30ホップ、応答待ち4秒）と、pathping を使います。Microsoft Learn によると、pathping は経路上の各ルーターに一定期間（既定で1ルーターあたり100回）ping を送り、ルーターごと・区間ごとの遅延と損失の割合を表示します。時間はかかりますが、どの区間でパケットが落ちているかまで分かります。出力の読み方と * * * の意味は、関連記事「traceroute・tracertの使い方｜見方と * ・!Hの意味を実例で」で扱っています。

curl -w（Web・API のどこに時間がかかったか）

curl -w を使うと、名前解決・TCP 接続・TLS・サーバーの処理・転送の各段階が何秒目に終わったかを表示できます。 curl の公式ドキュメントのとおり、どの値も「開始からの累積の時間」です。書式をファイルに書いておくと見やすくなります。

     名前解決: %{time_namelookup}s\n
     TCP接続: %{time_connect}s\n
     TLS完了: %{time_appconnect}s\n
   送信の直前: %{time_pretransfer}s\n
最初の1バイト: %{time_starttransfer}s\n
        合計: %{time_total}s\n

curl -s -o /dev/null -w @fmt.txt https://10.76.2.2:37602/f1.bin

往復100ms の相手に HTTPS で 1KB のファイルを取りに行った結果です。

     名前解決: 0.000023s
     TCP接続: 0.100554s
     TLS完了: 0.205742s
   送信の直前: 0.205800s
最初の1バイト: 0.310138s
        合計: 0.310200s

小さなファイル1つでも、HTTPS では3往復（約310ms）かかりました。 「最初の1バイトまで」から「送信の直前」を引いた値（ここでは約104ms）は、ネットワークの1往復とサーバーの処理時間の合計で、TTFB（Time To First Byte）と呼ばれる値に近いものです。この差が往復時間（ping の値）より大きく伸びていれば、サーバーの処理が遅いと分かります。curl の公式サイトによると、curl は Windows 10 のビルド 17063 から標準で入っています。PowerShell の curl は Invoke-WebRequest の別名なので、curl.exe と書きます。curl のオプションの全体は、関連記事「curlコマンドの使い方｜よく使うオプションとAPIの確認方法」で扱っています。

Mac の networkQuality と Linux の ss

Apple サポートによると、macOS Monterey 以降ではターミナルで networkQuality と入力すると、ネットワークの応答性を測れます。結果は RPM（1分あたりに何回往復できるか）で表され、「低い」「中間」「高い」の3段階に分けられます。詳しいオプションは man networkQuality で確かめます。

Linux では、使っている TCP 接続ごとに、OS が見積もっている RTT を ss -ti で見られます。往復100ms の相手につないだままの接続です。

$ ss -tin dst 10.76.2.2
State Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB 0      0          10.76.1.2:57392    10.76.2.2:37601
     bbr wscale:10,10 rto:304 rtt:101.214/12.29 ato:40 mss:1448 pmtu:1500 … minrtt:100.841 …

rtt:101.214/12.29 は、なめらかにした RTT とそのばらつき（ms）、minrtt:100.841 はこれまでの最小の RTT です。rto:304 は、返事が来ないときに送り直すまで待つ時間（ms）で、RTT が大きいほど長くなります。TCP の接続とポートのしくみは、関連記事「ソケットとは｜TCPとUDPの違いをPythonの通信とtcpdumpで解説」で扱っています。

遅延を0・20・100・300msに変えて実測（ping・curl・keep-alive）

この節では、レイテンシが増えると Web の所要時間がどれだけ増えるのかを、同じ操作を遅延だけ変えて測った数値で確かめられます。

1台の Linux の中に、ネットワーク名前空間で PC・ルーター・サーバーを作り、ルーターとサーバーの間の線に遅延を足しました。サーバーでは HTTP（37601番）と HTTPS（37602番）で、1KB のファイル10個と 1MB・10MB のファイルを返しています。

flowchart TD
    PC[PC<br>10.76.1.2] --- RT[ルーター<br>10.76.1.1]
    RT ---|遅延を足す線<br>往復0〜300ms| SV[サーバー<br>10.76.2.2]

遅延の足し方（tc netem と、この記事の中継）

Linux では、ネットワークの試験用に tc コマンドの netem で遅延を足すのが一般的です。man ページ（tc-netem(8)）の書き方は delay 時間 [ばらつき [相関]] で、例として次のコマンドが載っています。netem は、指定した装置から出ていくパケットを遅らせます。

tc qdisc add dev eth0 root netem delay 100ms          # 出ていくパケットを100ms遅らせる
tc qdisc change dev eth0 root netem delay 100ms 10ms  # ばらつき10msを足す
tc qdisc change dev eth0 root netem loss 0.1%         # 0.1%のパケットを落とす
tc qdisc del dev eth0 root                            # 元に戻す

この記事の測定では、netem と同じ働きをする Python の中継で遅延を足しました。 ルーターとサーバーにそれぞれ TUN デバイスを作り、片方から読んだパケットを決めた時間だけ止めてから、もう片方に書き込みます。往復で足したい時間の半分ずつを、行きと帰りで待たせます。

"""2つの名前空間の TUN をつなぎ、片道ごとに決めた時間だけ待ってから渡す遅延つきの線
usage: python3 delayline.py 往復の遅延ms [片道のばらつきms] [速さの上限Mbps]"""
import ctypes, fcntl, os, random, struct, sys, threading, time, collections
CLONE_NEWNET, TUNSETIFF, IFF_TUN, IFF_NO_PI = 0x40000000, 0x400454CA, 0x0001, 0x1000
libc = ctypes.CDLL(None, use_errno=True)

def open_tun(ns, name):                      # 名前空間に入ってから、その中の TUN を開く
    with open(f"/var/run/netns/{ns}") as f:
        libc.setns(f.fileno(), CLONE_NEWNET)
    fd = os.open("/dev/net/tun", os.O_RDWR)
    fcntl.ioctl(fd, TUNSETIFF, struct.pack("16sH", name.encode(), IFF_TUN | IFF_NO_PI))
    return fd

rtt = float(sys.argv[1]); jitter = float(sys.argv[2]) if len(sys.argv) > 2 else 0.0
rate = float(sys.argv[3]) if len(sys.argv) > 3 else 0.0
one_way = rtt / 2000.0                        # 片道の秒数
fd_r, fd_s = open_tun("s376-r", "tr"), open_tun("s376-s", "ts")

def pipe(src, dst):
    q = collections.deque(); cv = threading.Condition(); st = {"free": 0.0, "last": 0.0}
    def reader():
        while True:
            pkt = os.read(src, 65535); now = time.monotonic()
            if rate > 0:                      # 線が空くまで待つ（送り出す時間＝大きさ÷速さ）
                st["free"] = max(now, st["free"]) + len(pkt) * 8 / (rate * 1e6); now = st["free"]
            d = one_way + (random.gauss(0, jitter / 1000) if jitter else 0.0)
            due = max(now + max(d, 0.0), st["last"]); st["last"] = due   # 追い越しはさせない
            with cv:
                q.append((due, pkt)); cv.notify()
    def writer():
        while True:
            with cv:
                while not q:
                    cv.wait()
                due, pkt = q[0]
            time.sleep(max(0.0, due - time.monotonic()))
            with cv:
                q.popleft()
            os.write(dst, pkt)
    threading.Thread(target=reader, daemon=True).start()
    threading.Thread(target=writer, daemon=True).start()

pipe(fd_r, fd_s); pipe(fd_s, fd_r)             # 行きと帰り
print(f"delayline rtt={rtt}ms jitter={jitter}ms rate={rate}Mbit", flush=True)
while True:
    time.sleep(3600)

名前空間と TUN デバイスは、次のように作りました。ルーターの転送の設定は、ルーターの名前空間の中だけで変えています。

for n in c r s; do ip netns add s376-$n; ip -n s376-$n link set lo up; done
ip link add c0 netns s376-c type veth peer name r0 netns s376-r     # PC とルーターをつなぐ
ip -n s376-c addr add 10.76.1.2/24 dev c0; ip -n s376-r addr add 10.76.1.1/24 dev r0
ip -n s376-r tuntap add dev tr mode tun; ip -n s376-s tuntap add dev ts mode tun
ip -n s376-r addr add 10.76.2.1/24 dev tr; ip -n s376-s addr add 10.76.2.2/24 dev ts
# 各装置を up にし、PC とサーバーにデフォルトゲートウェイを設定（略）
ip netns exec s376-r sysctl -qw net.ipv4.ip_forward=1
python3 delayline.py 100 &                                           # 往復100msを足す

中継そのものにかかる時間は、遅延0のときの ping の平均で 0.276ms でした（PC からルーターまでは 0.02ms）。下の表の「0ms」は、この中継の分を含んだ値です。

測った結果

各条件を3回ずつ測り、中央値を載せました。10ファイルの行は curl を1回起動して10個を順に取得した時間で、curl の起動の時間（数 ms）も含みます。

所要時間は、ほぼ「往復の回数 × 往復時間」になりました。 HTTP の1KB は 202.5ms（約2往復）、HTTPS は 306.3ms（約3往復）で、遅延を3倍の300ms にすると、どちらもほぼ3倍になりました。帯域幅は同じなので、増えた時間はすべてレイテンシによるものです。

接続を使い回す（keep-alive）と往復が減る

HTTP/1.1 は、1つの TCP 接続で複数のリクエストを順に送れます（持続的接続、keep-alive）。 curl は同じサーバーへの2つ目以降の取得で接続を使い回し、%{num_connects}（新しく作った接続の数）が 1000000000 になりました。Connection: close を付けて毎回閉じさせると 1111111111 で、10回とも接続し直しています。

sequenceDiagram
    participant C as PC
    participant S as サーバー
    C->>S: TCP 接続
    S-->>C: 接続できた
    C->>S: 1つ目を要求
    S-->>C: 1つ目の応答
    C->>S: 2つ目を要求
    S-->>C: 2つ目の応答

• HTTP で毎回つなぎ直すと約20往復（接続10回＋要求10回）、使い回すと約11往復（接続1回＋要求10回）で、時間は 2,036ms から 1,127ms に減りました。
• HTTPS では、接続のたびに TLS の1往復も増えるので、毎回つなぎ直すと約31往復（3,106ms）、使い回すと約12往復（1,229ms）でした。HTTPS ほど、接続を使い回す効果が大きくなります。
• MDN の「HTTP/1.x のコネクション管理」も、短命な接続ではリクエストごとに TCP のハンドシェイクが起き、持続的接続ではその時間を節約できると説明しています。

HTTP/2 で同時に送る

HTTP/2 は、1つの接続の中で複数のリクエストを同時に送れます（多重化）。 HTTP/2 に対応したサーバー（Hypercorn）に同じ10個のファイルを置き、curl の --http2 -Z（同時に取得）で測りました。

$ curl --http1.1 （10個を順に）      → 1.1:1 1.1:0 … 1.1:0   1,243ms
$ curl --http1.1 -Z （10個を同時に）  → 1.1:1 1.1:1 … 1.1:1     340ms
$ curl --http2 -Z （10個を同時に）    → 2:1 2:0 … 2:0           440ms

2:1 2:0 … は「HTTP のバージョン:新しく作った接続の数」です。HTTP/2 は接続1本のまま、10個を 440ms（約4往復）で取得しました。 HTTP/1.1 で同時に取ると 340ms とさらに短くなりましたが、接続を10本作っています（1.1:1 が10個）。接続の数が増えると、そのたびに TCP と TLS の往復が要り、サーバーが受け持つ接続も増えます。HTTP/2 は、接続1本のまま往復の回数を減らせる方法です。

大きなファイルもレイテンシで遅くなる理由

1MB のファイルは、往復0ms で 17.5ms、往復100ms で 858.7ms と、約50倍になりました。帯域幅は同じなのに遅くなったのは、TCP が最初から全力では送らないためです。TCP は、届いたことの確認（ACK）を受け取るたびに、一度に送ってよい量を増やしていきます（スロースタート）。 RFC 5681 は、ACK を1つ受け取るごとに最大1セグメント分ずつ増やすと定めていて、結果として1往復ごとにおよそ倍に増えます。往復時間が長いほど、量が増えるまでの時間も長くなります。

レイテンシが高い・低いとは？（ゲーム・配信・Web会議・API）

この節では、「高い」「低い」がどういう状態で、使い方ごとにどんな影響が出るのかが分かります。

レイテンシは低いほうがよい値です。 「低レイテンシ」は待ち時間が短く反応が速いこと、「高レイテンシ」は待ち時間が長く反応が遅いことを指します。速さ（Mbps）のように「高いほどよい」値ではないので、逆に覚えないように気をつけます。

アプリやデータベースでは、「1回の往復の時間 × 往復の回数」で考えます。 たとえば、アプリのサーバーとデータベースが往復1ms の距離にあっても、1画面で SQL を100回順に送ると、それだけで 100ms になります。同じ処理を、サーバーとデータベースを別のリージョン（往復11ms）に置いて行うと 1.1秒です。まとめて1回で取得する、近くに置く、のどちらかで短くできます。

p50・p99の見方（平均ではなくパーセンタイル）

この節では、API やサービスのレイテンシを「平均」ではなく「p50・p99」で見る理由と読み方が、実測で分かります。

p50 は「全体の50%がこの時間以内に終わった」、p99 は「99%がこの時間以内に終わった」という値です。 p50 は中央値で、ふつうのリクエストの速さを表します。p99 は遅いほうの1%を除いた最悪に近い値で、テールレイテンシ（遅い裾の部分）と呼ばれます。Google の SRE 本は、99パーセンタイルのような高い値は「起こりうる最悪に近い値」を、50パーセンタイルは「典型的な値」を示し、平均だけを見ると遅いリクエストの変化が見えなくなる、と説明しています。

往復20ms（ばらつきあり）の線の先に、95%は 5ms、5%は 100ms かかる API を置き、同じ接続で1000回呼び出して測りました。

"""同じ接続で /api に1000回リクエストし、所要時間の平均・p50・p90・p99・最大を出す"""
import http.client, time, statistics
c = http.client.HTTPConnection("10.76.2.2", 37601)
ms = []
for _ in range(1000):
    t = time.perf_counter(); c.request("GET", "/api"); c.getresponse().read(); ms.append((time.perf_counter() - t) * 1000)
ms.sort()
q = lambda p: ms[min(len(ms) - 1, int(len(ms) * p / 100))]
print(f"件数 {len(ms)}  平均 {statistics.mean(ms):.1f}ms  p50 {q(50):.1f}ms  p90 {q(90):.1f}ms  p95 {q(95):.1f}ms  p99 {q(99):.1f}ms  最大 {ms[-1]:.1f}ms")
print("100ms以上かかった件数:", sum(m >= 100 for m in ms))

件数 1000  平均 33.7ms  p50 28.6ms  p90 32.4ms  p95 120.6ms  p99 126.4ms  最大 129.2ms
100ms以上かかった件数: 55

平均は 33.7ms で「速い」ように見えますが、1000回中55回は 100ms を超えていました。 1画面で API を10回呼ぶ画面なら、10回のうちどれか1回でも遅いと画面全体が遅くなるので、p99 のような遅い側の値が体感に効きます。目標（SLO）を決めるときは「p99 を 200ms 以内」のように、パーセンタイルと時間をセットで決めます。多数のリクエストを送ってパーセンタイルを測る方法は、関連記事「負荷テストの進め方とk6の使い方｜スクリプト例と結果の読み方」で扱っています。

レイテンシを下げる方法（CDN・リージョン・接続の再利用・キャッシュ）

この節では、レイテンシを短くする方法を、「距離を縮める」「往復を減らす」「待ちを減らす」に分けて選べます。

レイテンシを下げる方法は、「1往復を短くする」か「往復の回数を減らす」かの2つです。 距離による時間は光の速さで決まっているので、遠い相手との1往復は短くできません。その場合は回数を減らします。

• 1サーバーは利用者の近くにあるか東京の利用者に米国東部から返すと、距離だけで往復160ms前後かかる
• 2静的なファイルを CDN から返しているかCDN は利用者の近くのサーバーに写しを置き、遠くまで取りに行かずに返す
• 3接続を毎回作り直していないか実測では HTTPS 10回で31往復が12往復に減った
• 4HTTP/2 以上で配信しているか実測では10個のファイルが1本の接続で約4往復に収まった
• 5ループの中で1件ずつ問い合わせていないか100回の往復は、1回の往復が1msでも100msになる
• 6同じデータを毎回取りに行っていないかキャッシュに当たれば、ネットワークの往復そのものが無くなる

Cloudflare の解説も、CDN は静的なコンテンツを分散したサーバーにキャッシュし、利用者の近くから配信することで読み込みの時間を短くする、と説明しています。キャッシュの置き方と有効期限の決め方は、関連記事「キャッシュ設計の戦略一覧：Cache-Asideなど5方式の違いとTTLの決め方」で扱っています。

家庭やオフィスで ping 値を下げたいときは、Wi-Fi を有線 LAN にする、大きなダウンロードやアップロードを同時に行わない、ルーターを再起動する、ゲームのサーバーの地域を近くにする、の順に試すと、効果を比べやすくなります。

レイテンシが高いときの原因と切り分け

この節では、「遅い」と感じたときに、どこが原因かを順に絞り込めます。

1. 1ping で往復時間を測るいつも通りの値か、急に大きくなったか、ばらつき（mdev）が大きいかを見る
2. 2自宅・社内のルーターに ping するルーターまでで既に遅ければ、Wi-Fi や LAN の中が原因
3. 3traceroute・pathping で区間を見るどのホップから急に増えるかで、回線・プロバイダー・相手側を見分ける
4. 4curl -w で段階を分けるTCP 接続は速いのに最初の1バイトが遅ければ、サーバーの処理が原因

家の中が原因か外が原因かは、自宅のルーター（デフォルトゲートウェイ）に ping すると分かります。 自分の外向きの IP アドレスと、NAT の内側と外側の違いは、関連記事「グローバルIPの確認方法｜コマンド・プライベートIPとの違いとNATを実演」で扱っています。

よくある質問

Q. レイテンシとは簡単に言うと何ですか？ A. データを送ってから届く（返事が返る）までの待ち時間です。単位はミリ秒（ms）で、小さいほど反応が速くなります。宅配便でいえば、注文してから届くまでの日数にあたります。

Q. レイテンシとレイテンシー、読み方はどちらが正しいですか？ A. どちらも英語の latency のことで、意味は同じです。記事や製品によって「レイテンシ」「レイテンシー」の両方が使われます。

Q. レイテンシは高いのと低いの、どっちがいいですか？ A. 低いほうがよい値です。「低レイテンシ」は待ち時間が短いこと、「高レイテンシ」は待ち時間が長く反応が遅いことです。回線速度（Mbps）とは逆なので注意します。

Q. レイテンシと ping 値の違いは？ A. ping 値は、ping コマンドなどで測った往復のレイテンシ（RTT）の値です。ゲームや速度テストで表示される「ping」は、ほぼレイテンシと同じ意味で使われています。

Q. レイテンシと遅延の違いは？ A. レイテンシの日本語訳が「遅延」で、同じものを指します。ネットワークでは、パケットが届くまでの時間を「遅延時間」「レイテンシ」のどちらでも呼びます。

Q. レイテンシの目安は何 ms ですか？ A. 国内のサーバーなら数 ms〜20ms 台、東京から米国は往復100〜160ms 前後、ヨーロッパは200ms 台が、データセンター間の公開値です。NTT東日本の解説では、ping 値15ms 以下を非常に速い、51ms 以上をやや遅いとしています。

Q. レイテンシと帯域幅（通信速度）の違いは？ A. 帯域幅は1秒に運べる量、レイテンシは1往復にかかる時間です。実測では、1KB のファイルは帯域幅を10Mbps に絞っても 2.4ms、往復100ms の遅延があると 202ms かかり、小さいデータはレイテンシで時間が決まりました。

Q. レイテンシを下げるにはどうすればよいですか？ A. 利用者の近くにサーバーを置く・CDN を使う（1往復を短くする）か、接続を使い回す・HTTP/2 を使う・まとめて送る・キャッシュする（往復の回数を減らす）かです。家庭では有線 LAN にすると下がることが多くあります。

Q. ジッターとは何ですか？ A. レイテンシのばらつきです。ping の mdev や、最小と最大の差で分かります。通話やゲームでは、平均が小さくてもジッターが大きいと音や動きが途切れます。

Q. p99 レイテンシとは何ですか？ A. 全体の99%のリクエストがその時間以内に終わった、という値です。実測では平均 33.7ms に対して p99 は 126.4ms で、平均だけでは遅い1%が見えませんでした。

Q. ゲームのレイテンシは何 ms なら快適ですか？ A. 国内のサーバーで ping 値が15ms 以下なら非常に速い、30ms 以下なら速い、という目安が公開されています。1秒60コマの画面では1コマが約16.7ms なので、往復が数十 ms あると操作の結果が数コマ遅れて表示されます。

まとめ

• レイテンシは、データを送ってから届く（返る）までの待ち時間。単位は ms で、低いほどよい。
• 帯域幅は「1秒に運べる量」、スループットは「実際に運べた量」、ジッターは「レイテンシのばらつき」、RTT は「往復のレイテンシ」。
• レイテンシは「距離＋送り出し＋順番待ち＋処理」の合計。光ファイバーでは 1,000km ごとに往復約9.8ms かかり、これより速くはならない。
• 東京から大阪は往復11ms、米国西海岸は107ms、ロンドンは230ms（Azure の公開値）。メモリは 100ns で、100万倍以上の差がある。
• 測るときは ping（往復）、traceroute・tracert・pathping（区間）、curl -w（Web の段階）を使う。
• Web の所要時間は「往復の回数 × 往復時間」。往復100ms で HTTPS の10ファイルは、毎回つなぎ直すと 3,106ms、使い回すと 1,229ms、HTTP/2 で同時に取ると 440ms だった。
• API のレイテンシは平均ではなく p50・p99 で見る。

次に読むとよい記事です。経路の区間ごとの調べ方は関連記事「traceroute・tracertの使い方｜見方と * ・!Hの意味を実例で」で、TCP の接続のしくみは関連記事「ソケットとは｜TCPとUDPの違いをPythonの通信とtcpdumpで解説」で扱っています。

参考・出典

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

• Microsoft Learn「Azure ネットワーク往復待機時間の統計」：https://learn.microsoft.com/en-us/azure/networking/azure-network-latency
• Bozkurt ほか「Dissecting Latency in the Internet's Fiber Infrastructure」（arXiv:1811.10737）：https://arxiv.org/abs/1811.10737
• Peter Norvig「Teach Yourself Programming in Ten Years」（Approximate timing for various operations on a typical PC）：https://norvig.com/21-days.html
• NTT東日本「レイテンシとは？」：https://business.ntt-east.co.jp/column/service/flets-hikari/latency.html
• Cloudflare「レイテンシーとは」：https://www.cloudflare.com/ja-jp/learning/performance/glossary/what-is-latency/
• Google「Site Reliability Engineering - Service Level Objectives」：https://sre.google/sre-book/service-level-objectives/
• everything curl「Available --write-out variables」：https://everything.curl.dev/usingcurl/verbose/all-variables.html
• MDN「HTTP/1.x のコネクション管理」：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Connection_management_in_HTTP_1.x
• RFC 5681「TCP Congestion Control」：https://www.rfc-editor.org/rfc/rfc5681
• man7.org「tc-netem(8)」：https://man7.org/linux/man-pages/man8/tc-netem.8.html
• curl「curl shipped by Microsoft」：https://curl.se/windows/microsoft.html
• Microsoft Learn「ping」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/ping
• Microsoft Learn「tracert」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/tracert
• Microsoft Learn「pathping」：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/pathping
• Apple サポート「Apple ネットワーク応答性テストで Wi-Fi をテストする」：https://support.apple.com/ja-jp/101942
• YouTube ヘルプ「ライブ配信の遅延について」：https://support.google.com/youtube/answer/7444635?hl=ja

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