先に要点
- レイテンシとは、データが送られてから届くまでの遅延時間 です。実務では往復にかかる時間 RTT(Round Trip Time)をミリ秒(ms)で見ることがほとんどです。「反応の速さ」 を表す指標です。
- よく混同される帯域(バンド幅)とは別物です。帯域は一度に運べる量、レイテンシは届くまでの速さ。水道管にたとえると、帯域は管の太さ、レイテンシは蛇口をひねってから水が出るまでの時間です。
- 主な原因は 物理的な距離・経由する機器の数・各機器での処理待ち・回線の混雑。光ファイバーの中の光は1kmあたり約5マイクロ秒かかるので、距離だけで下限が決まり、帯域を増やしても縮みません。
- HTTPSの新しい接続は、最初の1バイトが届くまでに TCP・TLS・リクエストで3往復前後 かかります。RTTが100msなら、それだけで約300msです。
- 測るときは ping だけで判断せず、
curl -wやブラウザの開発者ツールで「どの段階に何ms」かを分けて見る と、距離・サーバー処理・帯域のどれが原因か切り分けられます。下げる基本は CDNで近づける・往復回数を減らす・接続を再利用する、です。
レイテンシとは、データが相手に届くまでの遅延時間 のことで、ネットワークの実務ではほとんどの場合、行って戻ってくるまでの往復時間(RTT)を指します。回線は速いはずなのに反応が遅い 海外サーバーにアクセスするともたつく といった速いはずなのに遅いの正体は、たいていこれです。
定義だけなら一言で終わるので、このページでは、その先の実務で必要になることを扱います。地域ごとのRTTの実測値の目安、HTTPSの1回目のアクセスで何往復かかるか、ping と curl -w とブラウザの開発者ツールで実際に測った出力の読み方、そして「遅い原因はレイテンシなのか、サーバーなのか、帯域なのか」の見分け方と下げ方です。
レイテンシとは何か
レイテンシは、送ったデータが届くまでの遅れ を表します。厳密には片道の遅延(One-way delay)と往復の遅延(RTT)があり、片道は送り手と受け手の時計を正確に合わせないと測れないため、普段は往復のRTTで扱います。この記事でも、とくに断らない限りレイテンシ=RTTの意味で書きます。
目安として、Microsoft が公開している Azure のデータセンター間の往復時間(2026年7月30日までの30日間の中央値)から、東日本リージョン(東京)を起点にした値を抜き出すと次のとおりです。
これはクラウド事業者の基幹網どうしの値なので、家庭や会社の回線からサーバーまでは、ここにアクセス回線(Wi-Fi・光回線・モバイル)の分が上乗せされます。それでも「国内なら十数ms、アジア圏で数十ms、米国で100〜160ms、欧州・南米で200ms超」という桁の感覚は、そのまま設計の目安になります。
数字が小さいほど反応が速く、大きいほどもたつきます。オンラインゲームでping 値と呼ばれているものは、まさにこのレイテンシ(往復時間)のことです。pingが高いはレイテンシが大きいと同じ意味です。
重要なのはこの点です。通信の中で往復が何回も発生すると、その回数ぶんレイテンシが積み重なります。「1往復は速くても、何十回も往復すると全体が遅くなる」という構造を押さえておくと、後の改善の話がつながります。
レイテンシと帯域(バンド幅)の違い
ここが最も誤解されやすいポイントです。レイテンシと帯域(バンド幅)は、どちらも通信の速さに関わりますが、測っているものが違います。
| 観点 | レイテンシ | 帯域(バンド幅) |
|---|---|---|
| 意味 | 届くまでの遅延(速さ) | 一度に運べるデータ量(太さ) |
| 単位 | ミリ秒(ms) | Mbps / Gbps |
| 効く場面 | 反応速度、小さな通信の往復が多い処理 | 大きなファイルや動画の転送 |
| 水道管のたとえ | 蛇口をひねって水が出るまでの時間 | 管の太さ(同時に流せる水の量) |
これが決定的な違いです。回線の帯域が10倍になっても、東京とアメリカの物理的な距離は変わらないので、往復時間はほぼ同じです。「回線速度(帯域)を上げたのに反応が速くならない」のは、ボトルネックが帯域ではなくレイテンシ側にあるからです。
逆に、大きな動画をダウンロードするような場面では帯域が効きます。もう1つ、似た言葉に スループット(実際に出た転送速度)があります。3つの関係は次のように覚えておくと使い分けられます。
レイテンシが効く
小さなデータを何度もやり取りする処理。反応速度に直結します。
帯域が効く
大きなデータを一気に流す処理。大きなファイルや動画の転送です。帯域は「出せる速さの上限」です。
スループット
実際に出た転送速度。帯域が上限で、レイテンシやパケットの欠落が大きいほど下がります。
レイテンシがスループットまで下げるのは、TCPが「相手からの受け取り確認を待ちながら送る」仕組みだからです。1つの接続で出せる速さは、おおよそ「確認を待たずに送れる量(ウィンドウ)÷RTT」で頭打ちになります。たとえばウィンドウが64KBのままなら、RTT 100ms では約5Mbpsが上限です。今のOSはウィンドウを大きく広げられる(ウィンドウスケール)ので通常はここまで低くなりませんが、「遠いサーバーからの大きなダウンロードが、回線の帯域ほど速くならない」理由の1つはこれです。帯域とコストの関係は 帯域(転送量)コストの基礎 でも整理しています。
レイテンシは何で決まるか
レイテンシが大きくなる要因は、主に次の4つです。
物理的な距離
光ファイバーの中の光は真空中より遅く、秒速約20万km(1kmあたり約5マイクロ秒)で進む。往復なら100kmごとに約1ms。地球の裏側(約2万km)までは、ケーブルが一直線でも往復で約200msかかる。距離は帯域では縮められない最大の壁。
処理待ち
サーバーやネットワーク機器が混んでいると、処理の順番待ちで遅延が出る。Webの体感ではサーバー側の処理時間も含めて「遅い」と感じる。
回線の混雑(輻輳)
同じ経路に大量の通信が集中すると、渋滞が起きて遅延が増える。時間帯やイベントで変動し、値のばらつき(ジッター)としても現れる。
このうち 物理的な距離が、レイテンシの下限を決める一番大きな要因 です。東京からロサンゼルスまでは直線で約8,800kmなので、光ファイバーが一直線に通っていても往復の下限は約88msです。前の図の米国西部が100ms前後なのは、実際のケーブルが遠回りし、途中の機器の処理が加わるためです。改善策の多くがユーザーとサーバーの距離を縮める方向に向かうのはこのためです。
HTTPSの1回目のアクセスは何往復かかるか
Webの体感に直結するのが、新しい接続を作るときの往復の回数 です。HTTPSでページを取りに行くと、DNSで宛先を調べたあと、次の往復が順番に発生します。
TCPの接続(1往復)
3ウェイハンドシェイク。違いは TCPとUDPの違い で整理しています。
リクエストと応答(1往復)
ここにサーバーの処理時間が加わる。これが TTFB の中身。
つまりRTTが100msの相手には、サーバーが一瞬で返したとしても、新しい接続では最初の1バイトまで約300ms(TLS 1.2なら約400ms)かかります。HTTP/3 は土台の QUIC が接続と暗号化の握手を1回にまとめるので1往復減り、接続を使い回せば握手そのものが不要になります。RTTが10msの国内サーバーなら同じ3往復でも約30msなので、往復の回数を減らす工夫は、遠い相手ほど効く ということになります。
レイテンシの測り方
レイテンシは身近な道具で測れます。役割が少しずつ違うので、組み合わせて使います。
ping
ping 宛先 で往復時間(RTT)がミリ秒で表示される。最も手軽だが、使うのは ICMP という別の仕組みで、Webの通信そのものではない。
traceroute / tracert
経路上の各機器(ホップ)ごとの遅延が見える。どの区間で遅くなっているかの手がかりになる。
ブラウザ開発者ツール
Networkタブで各リクエストの内訳(Timing)を確認できる。体感に近い実測値が取れる。
ping の出力の読み方
Windows 11 の PowerShell から、公開DNSサーバーの 1.1.1.1 に4回送った実際の出力です(2026年10月に計測)。
PS> ping -n 4 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=5ms TTL=57
Reply from 1.1.1.1: bytes=32 time=19ms TTL=57
Reply from 1.1.1.1: bytes=32 time=7ms TTL=57
Reply from 1.1.1.1: bytes=32 time=6ms TTL=57
Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 19ms, Average = 9ms
見るのは time= の値と、最後の Minimum / Maximum / Average です。この例では普段は5〜7msで、1回だけ19msに跳ねています。平均だけでなく最小値とばらつきを見る のがコツで、最小値がその経路の実力、跳ね方が混雑や Wi-Fi の不安定さの目安になります。Lost が0%でなければ、遅延より先にパケットの欠落を疑います。
ping が使う ICMP は、Webの通信(TCPの443番)とは扱いが別です。サーバー側で ICMP を止めていて ping が返らないのにサイトは正常、ということはよくあります。逆に、同じ日に www.example.com へ ping すると平均6msでしたが、次の curl では1往復が約110msかかっていました。Webの遅さを調べるときは、実際のプロトコルで測った値を優先します。
curl -w で「どこに何ms」かを分ける
curl の -w(write-out)に時刻の変数を並べると、1回のHTTPS通信を段階ごとに分けて表示できます。どの値も「開始からその段階が終わるまで」の累計秒数です。
curl -4 -s -o /dev/null -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/
Windows の PowerShell では curl.exe と書き、/dev/null を NUL、改行の \n を `n に置き換えます。手元(Windows 11、curl 8.22.0)で2つのサイトに対して実行した実際の出力が次です。
www.example.com dns=0.014662 tcp=0.129785 tls=0.244579 ttfb=0.354885 total=0.354938
www.cloudflare.com dns=0.018958 tcp=0.027715 tls=0.043217 ttfb=0.251322 total=0.371638
累計なので、隣り合う値の差 を取ると各段階の時間になります。
| 差の取り方 | 意味 | example.com | cloudflare.com |
|---|---|---|---|
| tcp − dns | TCPの接続=ほぼ1往復(RTT) | 約115ms | 約9ms |
| tls − tcp | TLSの握手 | 約115ms | 約16ms |
| ttfb − tls | 1往復+サーバーの処理 | 約110ms | 約208ms |
| total − ttfb | 本文のダウンロード | ほぼ0 | 約120ms |
example.com は3つの段階がどれも約110msでそろっています。これは前の章の「新規接続は3往復」がそのまま見えている形で、遅さの原因はほぼレイテンシ(接続先までの距離・経路) です。一方 cloudflare.com は1往復が10ms弱と近いのに、最初の1バイトまでに約200ms待っています。こちらは サーバー側でページを用意する時間 が主因で、ネットワークを速くしても縮みません。同じ「0.3〜0.4秒かかる」でも、手を打つ場所がまったく違います。
ブラウザの開発者ツールで見る
Chrome なら開発者ツールの Network タブでリクエストを選び、Timing タブを開くと、curl と同じ内訳が画面で見られます。
| Timing の項目 | 中身 |
|---|---|
| Queueing / Stalled | ブラウザ内の順番待ち。HTTP/1.1 で同じ相手への接続数が上限(6本)に達したときなどに伸びる |
| DNS Lookup | 宛先のIPアドレスを調べる時間 |
| Initial connection / SSL | TCPの接続とTLSの握手。新規接続のときだけ出る |
| Waiting (TTFB) | 1往復+サーバーの処理時間 |
| Content Download | 本文の受信。大きいファイルで伸びるなら帯域側 |
2回目以降のリクエストで Initial connection が出ていなければ、接続が再利用されています。毎回出ているなら、接続の使い回しが効いていない可能性があります。
測った結果から原因を見分ける
| 見えたこと | 疑う原因 | 次の手 |
|---|---|---|
| TCP・TLS・TTFBの各段がどれも同じくらい大きい | レイテンシ(距離・経路) | CDN、近いリージョン、往復回数の削減 |
| TCP・TLSは小さいのにTTFBだけ大きい | サーバーの処理 | キャッシュ、重い処理やDBの見直し |
| TTFBは小さいがダウンロードが長い | 帯域・ファイルの大きさ | 圧縮、画像の最適化、CDN |
| 同じ測定で値が大きく揺れる | 混雑、Wi-Fi、モバイル回線 | 時間帯や回線を変えて複数回測る |
1回の測定で決めつけず、数回測って傾向を見ます。手元からは遅いがサーバーの近くから測ると速いなら、原因はユーザーとサーバーの間の距離・経路です。世界各地から測りたいときは WebPageTest のような計測サービスも使えます。
レイテンシが効く場面
レイテンシは、次のような小さなやり取りを何度もする場面で体感に直結します。
| 場面 | レイテンシの影響 |
|---|---|
| Webサイトの表示 | サーバー応答の開始(TTFB)に直結。往復が多いほど初期表示が遅れる |
| API呼び出し | 1画面で多数のAPIを順番に呼ぶと、往復回数ぶん遅延が積み上がる |
| オンラインゲーム | ping値そのもの。高いと操作の反映が遅れる |
| ビデオ会議・通話 | 遅延が大きいと会話がかみ合わなくなる |
特にWeb開発で見落としがちなのが APIの往復回数 です。1往復が50msでも、画面表示に必要なAPIを20回順番に呼べば、それだけで1秒の遅延になります。前の呼び出しの結果を待たなくてよいものは並列に呼べば、待ち時間は「一番遅い1回」程度まで縮みます。1回を速くするだけでなく往復回数を減らす・まとめる・並べる発想が重要です。1回の問い合わせで必要なデータをまとめて取る設計は GraphQLとREST APIの違い、リアルタイム通信が必要な場面では WebSocketとHTTPの違い も判断材料になります。
レイテンシを下げる方法
レイテンシは物理法則の制約を受けるためゼロにはできませんが、設計で大きく改善できます。
レイテンシを下げる方法
優先順位としては、CDNでの距離短縮と、往復回数の削減が二大対策 です。回線を速くする(帯域を上げる)はレイテンシには効かないので、近づけると往復を減らすの二方向で考えます。ただし、curl で見て TTFB だけが大きいならサーバーの処理が主因なので、先にそちらを直します。Webの表示速度全体の改善は TTFBとは や CDNとは とあわせて見ると、どこに手を打つか整理しやすくなります。
レイテンシに関するよくある質問
Q. レイテンシと帯域はどう違いますか？
A. レイテンシはデータが届くまでの遅延(速さ)、帯域は一度に運べるデータ量(太さ)です。水道管でいうと、レイテンシは蛇口をひねって水が出るまでの時間、帯域は管の太さです。小さな通信を何度もする処理はレイテンシが、大きなファイル転送は帯域が効きます。
Q. 回線速度を上げればレイテンシは下がりますか？
A. ほとんど下がりません。回線速度(帯域)を上げても、ユーザーとサーバーの物理的な距離は変わらないため、往復時間はほぼ同じです。速い回線にしたのに反応が変わらない場合、ボトルネックは帯域ではなくレイテンシ側にあります。
Q. レイテンシは何ミリ秒なら良いですか？
A. 一律の合格ラインはなく、相手との距離で決まる下限と比べて判断します。国内同士なら十数ms程度、アジア圏で数十ms、米国で100〜160ms前後が基幹網での目安で、海外サーバーが100msを超えるのは正常です。ゲームや通話のように操作がすぐ反映されてほしい用途ほど小さい値が求められます。どこから誰がアクセスするかを前提に評価します。
Q. ping と RTT は同じものですか？
A. ほぼ同じ意味で使われます。ping コマンドが測っているのは対象までの往復時間(RTT = Round Trip Time)です。ただし ping は ICMP という仕組みで測るため、Webの通信(TCP)と同じ値になるとは限りません。
Q. ping が通らないサーバーはおかしいのですか？
A. おかしいとは限りません。セキュリティ上の理由で ICMP への応答を止めているサーバーやネットワークは珍しくなく、その場合も Web サイトは普通に表示されます。Webの遅延を測るなら、curl -w の tcp と dns の差のように、実際の通信で測る方法を使います。
Q. レイテンシはなぜゼロにできないのですか？
A. 光ファイバーの中の光は秒速約20万km(1kmあたり約5マイクロ秒)で進み、距離に比例して時間がかかるためです。さらに途中の機器での処理も加わります。物理法則上、距離があるかぎりレイテンシをゼロにはできません。
Q. CDN を入れるとレイテンシは下がりますか？
A. 下がりやすいです。CDNはユーザーに近いエッジからコンテンツを返すため、物理的な距離が縮まり往復時間が減ります。TCPやTLSの握手も近いエッジとの間で済みます。ただし毎回サーバーで生成する動的処理は、キャッシュ設計をしないと効果が限定的です。
Q. API が遅いのはレイテンシのせいですか？
A. レイテンシが原因のこともあれば、サーバー側の処理が重い場合もあります。curl や開発者ツールで、接続の段階と TTFB のどちらが大きいかを見ると切り分けられます。1画面で多数のAPIを順番に呼んでいるなら、まとめる・並列化する・回数を減らすといった対策が有効です。
参考リンク
- Microsoft Learn: Azure network round-trip latency statistics(リージョン間RTTの中央値。本文の数値は2026年7月30日時点のデータ)
- The Fiber Optic Association: Fiber FAQs(光ファイバー内の伝搬速度。1kmあたり約5マイクロ秒)
- curl: curl man page(-w, --write-out)
- Chrome for Developers: Network features reference(Timing breakdown)
- IETF: RFC 8446 TLS 1.3・RFC 9000 QUIC・RFC 7323 TCP Extensions for High Performance(ウィンドウスケール)
- Cloudflare: レイテンシーとは
- MDN: Latency
- AWS: レイテンシーとスループット