---
title: "レイテンシーとは？レスポンスタイム・スループットとの違いと測定方法・目安"
url: "https://www.issoh.co.jp/column/details/7053/"
published: 2025-06-02
updated: 2026-10-21
categories: ["ネットワーク"]
publisher: "株式会社一創"
---

# レイテンシーとは？レスポンスタイム・スループットとの違いと測定方法・目安

レイテンシー（latency）とは、データを送ってから相手に届くまで、または応答が返ってくるまでにかかる遅延時間のことで、ミリ秒（ms）で表します。似た言葉のレスポンスタイムは、操作してから結果が返るまでの全体の時間で、サーバーの処理時間も含みます。スループットは時間あたりに運べるデータ量で、遅延とは別の軸です。この記事では、この3つとターンアラウンドタイムの違いを1つの表で整理したうえで、ping・traceroute・curlを実際に叩いた結果を使って、どこで何ミリ秒かかっているかの読み方を示します。距離で決まる遅延の下限、用途別の目安、原因の層ごとの改善策までをまとめています。

## まとめ：レイテンシーの意味と目安、改善の優先順位

- **レイテンシー**はネットワーク上の遅延時間。往復で測った値をRTT（Round Trip Time）と呼び、pingが表示するのはこのRTTです。
- **レスポンスタイム**はレイテンシーにサーバーの処理時間などを足した、応答までの全体の時間。**スループット**は1秒あたりの転送量（bps）で、回線が太くても遅延は縮みません。
- HTTPSの通信は、名前解決・TCP接続・TLSハンドシェイク・リクエストの往復を重ねるため、**新規接続では最初の応答までにDNSを除いてRTTの3〜4倍**の時間がかかります。RTT 190msのアメリカ東部への接続で、計測開始から最初の応答まで約0.55〜0.62秒かかりました（実測）。
- 距離による下限は、光ファイバーの中で**片道1,000km（往復2,000km）あたり約10ms**。実測ではその1.8倍前後でした。海外向けでは配信拠点の近接化が有効ですが、経路や混雑の改善でも遅延を減らせます。
- 目安は用途で変わります。音声通話は片道150ms以内（ITU-T G.114）、Webページは最初の1バイトが返るまで0.8秒以内（web.dev）が一つの基準です。
- 改善は**測定で主因を特定し、その原因に効く対策を費用と効果で比較する**順で進めます。平均値ではなくp95・p99で判断します。

## レイテンシーの意味と、遅延が生まれる仕組み

### レイテンシー（遅延時間）の定義と片道・往復（RTT）

レイテンシーは「待ち時間」を意味する英語で、ITの文脈ではデータがある地点から別の地点へ届くまでの時間を指します。測り方は2つあり、送信側から受信側までの**片道遅延**（One-Way Delay）と、送ってから応答が戻るまでの**往復遅延**（RTT）です。IETFでは片道遅延を[RFC 7679](https://www.rfc-editor.org/rfc/rfc7679.html#section-3.4)（最初のビットの送信から最後のビットの受信まで）、往復遅延を[RFC 2681](https://www.rfc-editor.org/rfc/rfc2681.html#section-2.4)（送信から、相手がすぐ送り返した応答を受け取り終えるまで）で別々に定義しています。

片道遅延を測るには送信側と受信側の時計を正確に合わせる必要があるため、現場で手軽に測れるのは往復のほうです。pingの結果やオンラインゲームの「Ping値」も、通常はRTTを表します。「レイテンシーが高い」は遅延が大きい＝遅い状態、「低い」は遅延が小さい＝速い状態を意味し、数値は低いほど良好です。

### 遅延の4つの成分：伝搬・伝送・処理・待ち行列

ネットワークの遅延は、次の4つの足し算として考えると原因を切り分けやすくなります。

| 成分     | 何に比例するか     | 縮める手段                  |
| ------ | ----------- | ---------------------- |
| 伝搬遅延   | 物理的な距離      | 拠点を利用者に近づける（CDN・リージョン） |
| 伝送遅延   | データ量÷帯域     | データを小さくする・回線を太くする      |
| 処理遅延   | 機器・サーバーの処理量 | 機器の更新・サーバー処理の高速化       |
| 待ち行列遅延 | 混雑の度合い      | 混雑を避ける・優先制御（QoS）       |

小さなパケットをやり取りするpingでは伝送遅延はほぼゼロで、残りの3つが見えます。時間帯でRTTが大きく揺れるなら待ち行列遅延、いつ測っても一定以上に下がらないなら伝搬遅延が主因です。回線が混んで遅延が膨らむ仕組みは[輻輳（ネットワーク混雑）の仕組みとTCP輻輳制御](/tech/details/14677/)で詳しく扱っています。

### TCP上のHTTPS新規接続に必要な往復回数

Webサイトを1ページ開くとき、遅延は1回では済みません。新しい接続では次の往復が順に積み重なります。

1. DNSで名前をIPアドレスに変換する（キャッシュが無ければ1往復以上）
2. TCPの3ウェイハンドシェイク（1往復）
3. TLSハンドシェイク（TLS 1.3は1往復、TLS 1.2は2往復）
4. HTTPリクエストを送り、最初の1バイトを受け取る（1往復＋サーバー処理時間）

TCP上で通常のフルハンドシェイクを行うHTTPSでは、DNSの時間を除き、最初の応答まで**約3〜4 RTT**に処理時間などが加わります。RTT 20msなら80ms前後ですが、RTT 190msの海外なら0.6秒近くになります。次の章の実測で、この積み重なりを数字で確かめます。

## レイテンシーとレスポンスタイム・スループット・ターンアラウンドタイムの違い

4つの指標に、遅延のばらつきを示すジッターを加えて比較します。

| 指標          | 測るもの       | 単位      | 含む範囲          | 主な測り方           |
| ----------- | ---------- | ------- | ------------- | --------------- |
| レイテンシー      | 遅延時間       | ms      | ネットワーク上の移動    | ping・TCP接続時間    |
| レスポンスタイム    | 応答までの時間    | ms・秒    | 遅延＋サーバー処理     | curl・APM・TTFB   |
| スループット      | 時間あたりの処理量  | bps・件/秒 | 一定時間に運べた量     | 速度測定・iperf      |
| ターンアラウンドタイム | 依頼から結果完了まで | 秒〜日     | 処理の開始から全出力の完了 | ジョブの開始・終了時刻     |
| ジッター        | 遅延のばらつき    | ms      | 連続するパケットの遅延差  | pingの標準偏差・RTP統計 |

情報処理技術者試験の用語としては、レスポンスタイムは[ITパスポート試験の用語辞典](https://www.itpassportsiken.com/word/%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%A0.html)のとおり「処理の実行指示を与えてから最初の応答を得るまでの時間」、ターンアラウンドタイムは「処理を依頼してから結果がすべて返るまでの時間」と区別されます。Webの性能測定では、応答の受信が終わるまでをレスポンスタイムと呼ぶ使い方もあるため、数値を比べるときは終点がどちらかを確かめてください。大量の帳票を出力するバッチ処理では、最初の1枚が出るまで（レスポンスタイム）は短くても、全件が出終わるまで（ターンアラウンドタイム）は何時間もかかる、という関係です。

### レスポンスタイムとの違い：サーバーの処理時間を含むかどうか

違いを実測で示します。指定した秒数だけ応答を遅らせるテスト用API（httpbin.orgの `/delay/1`）を、東京からアメリカのサーバーへcurlで3回呼びました。

```
$ curl -s -o /dev/null -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://httpbin.org/delay/1
dns=0.042804 tcp=0.241509 tls=0.648851 ttfb=2.058817 total=2.059093
dns=0.005607 tcp=0.185593 tls=0.562363 ttfb=1.785577 total=1.785774
dns=0.005102 tcp=0.191281 tls=0.575455 ttfb=1.774770 total=1.774944
```

2回目で読むと、TCP接続にかかった時間（tcp−dns）が約0.18秒で、これがRTTです。TLSの完了からTTFB（最初の1バイト）までは約1.21秒で、サーバーが意図的に待った1秒と、リクエストの往復1回分の約0.2秒が足されています。**レスポンスタイム約1.79秒のうち、指定した待機が1秒、TCPとTLSの接続確立までが約0.56秒、リクエストの往復が約0.22秒**で、待機以外の約0.79秒はほぼ接続確立と往復の時間で説明できます（DNSは約0.006秒でした）。

この切り分けが付くと打ち手が変わります。サーバー処理が大半ならSQLやアプリの改善、往復が大半なら接続の再利用や配信拠点の移動が効きます。

### スループット・帯域幅との違い：回線を太くしても遅延は縮まない

スループットは1秒あたりに実際に運べたデータ量、帯域幅はその回線が理論上運べる上限です。道路に例えると、帯域幅は車線の数、スループットは実際に通過した車の台数、レイテンシーは1台が目的地に着くまでの時間に当たります。車線を増やしても、東京から大阪までの所要時間は変わりません。

そのため、大きなファイルのダウンロードはスループットで速さが決まり、小さなリクエストを何度も往復するWeb閲覧・API呼び出し・オンラインゲームはレイテンシーで決まります。1Gbpsの回線から10Gbpsの回線に変えても、海外サーバーとの往復時間はほぼ同じです。ストレージの性能を表すIOPS・スループット・レイテンシーの関係は[IOPSの計算式とスループット・レイテンシの違い](/tech/details/14683/)で整理しています。

### pingとの違い、ジッターとの関係

pingはレイテンシーを測るためのコマンドの名前で、ゲームや速度測定サイトで表示される「Ping値」は通常RTTの指標ですが、必ずしもpingコマンドで測定した値ではありません。pingはICMPという制御用のパケットを使うため、WebやゲームのTCP・UDPの通信と経路や優先度が異なる場合があり、Ping値とアプリの体感が一致しないこともあります。

ジッターは遅延のゆらぎで、RTP（音声・映像の伝送に使うプロトコル）を定義した[RFC 3550の6.4.1節](https://www.rfc-editor.org/rfc/rfc3550.html#section-6.4.1)では、受信側のパケット間隔と送信側のパケット間隔の差を平滑化した平均偏差として算出方法が決められています。平均のレイテンシーが低くてもジッターが大きいと、Web会議の音声が途切れたりゲームの動きが飛んだりします。

## レイテンシーを測定する方法：ping・traceroute・curlの使い方と読み方

ここからの実測値は、2026年10月21日の22時台に、東京都内の固定回線（ケーブルテレビ系のISP）につないだmacOS 26.6.2のPCで測ったものです。回線や時間帯で値は変わるため、数値そのものより読み方を参考にしてください。

### pingによる往復時間（RTT）の測定

最も基本的な方法です。WindowsではコマンドプロンプトやPowerShellで `ping -n 10 ホスト名`、macOSとLinuxではターミナルで `ping -c 10 ホスト名` と入力します（Windowsは何もしなければ4回で止まり、macOSとLinuxは止めるまで送り続けます）。

```
$ ping -c 10 8.8.8.8
...
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.827/14.177/18.519/2.156 ms
```

最終行の4つの数値は、最小・平均・最大・標準偏差です。**最小値は観測期間中の最短RTT**で、経路の基礎的な遅延を推定する手掛かり、平均と最大の差は混雑による待ち時間、標準偏差はジッターの目安として読みます。Linuxでは標準偏差が `mdev` と表示されます。packet lossが0%でないときは、遅延より先にパケットの欠落を疑います。ping値が急に跳ね上がる現象の原因と、自宅とISPのどちらで起きているかの切り分けは[Pingスパイクの原因と対策](/tech/details/12052/)で手順を解説しています。

### tracerouteによる経路と各ホップのRTTの確認

tracerouteは、宛先までに通過するルーター（ホップ）を順に表示し、それぞれまでのRTTを測ります。Windowsでは `tracert`、ホップごとの損失率まで集計するなら `pathping` を使います。Linuxでは継続的に測る `mtr` も使えます。

```
$ traceroute -q 1 -w 1 -m 22 35.71.73.124      # AWSアイルランド（eu-west-1）のエンドポイント
 1  192.168.86.1   3.075 ms
 ...
 8  asbr1-kote.bb.itscom.jp   23.770 ms
 9  ae-24.a04.tokyjp05.jp.bb.gin.ntt.net   28.180 ms
10  *
 ...
14  ae-19.a03.londen12.uk.bb.gin.ntt.net   238.534 ms
15  *
```

9ホップ目の東京（tokyjp）で28ms、14ホップ目のロンドン（londen）で238msに跳ねています。この測定では国際区間の影響が疑われますが、各ホップへのRTT差だけで区間の遅延や回線変更の効果を確定することはできません。

読むときの注意が2つあります。1つは、途中のルーターはtraceroute用のパケットへの応答を後回しにすることがあり、**途中のホップだけRTTが大きくても、その先のホップで小さく戻るなら問題ではない**ことです。別の計測では、1ホップ目の家庭用ルーターが18.97ms、2ホップ目が2.84msという逆転も出ました。もう1つは、`*` は応答を返さない設定のルーターであることが多く、通信が途切れているとは限らないことです。

### curlによるDNS・TCP・TLS・初回応答時間の測定

Webサイトの遅さを調べるなら、curlの `-w` オプションが最も役に立ちます。各変数は**リクエスト開始からの累積秒数**です（[curlのマニュアル](https://curl.se/docs/manpage.html)の定義。time\_starttransferは「time\_pretransferとサーバーが結果を計算する時間を含む」と明記されています）。

```
$ curl -s -o /dev/null -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://www.google.co.jp/
dns=0.003907 tcp=0.017707 tls=0.056072 ttfb=0.122892 total=0.123296
```

| 変数                  | 開始から何が終わるまでか | 差分で見えるもの               |
| ------------------- | ------------ | ---------------------- |
| time\_namelookup    | 名前解決         | DNSの遅さ                 |
| time\_connect       | TCP接続        | connect−namelookup≒RTT |
| time\_appconnect    | TLSハンドシェイク   | TLSの往復回数×RTT           |
| time\_starttransfer | 最初の1バイト受信    | 往復1回＋サーバー処理            |
| time\_total         | 転送の完了        | 本文の転送時間                |

上の例では、TCP接続（RTT）が約14ms、TLSが約38ms、TLS完了から最初の1バイトまでが約67msです。**TLS完了から最初の1バイトまでの時間がRTTを大きく上回る場合は、サーバー処理や通信中の待ち時間が増えている可能性がある**と読めます。同じコマンドを10回程度繰り返し、ばらつきも含めて見るのが基本です。

### 平均値とp95・p99による遅延分布の評価

8.8.8.8にpingを200回（0.2秒間隔）送った結果です。p95・p99は、それぞれ測定値の95％・99％がその値以下に収まる境界を示します。

| 統計量      | RTT    |
| -------- | ------ |
| 最小       | 8.3ms  |
| 中央値（p50） | 14.3ms |
| 平均       | 15.4ms |
| p95      | 21.9ms |
| p99      | 25.5ms |
| 最大       | 62.9ms |

平均は15.4msですが、最大は4倍の62.9msでした。1ページで数十本のリクエストを出すWebサイトでは、遅い側の数本がページ全体の表示時間を決めるため、平均が良くても利用者は遅いと感じます。SLAや監視のしきい値は、平均ではなく**p95かp99**で決めるのが実務の定石です。監視項目の設計は[システム監視の監視項目と性能監視の考え方](/column/details/13447/)も参考にしてください。

## 距離で決まるレイテンシーの下限：東京から海外リージョンまでの実測

光ファイバーの中を進む光は、真空中の約3分の2の速さ（毎秒約20万km）に落ちます。標準的なシングルモード光ファイバーの実効群屈折率は、Corningの技術資料（[AEN124](https://www.corning.com/catalog/coc/documents/application-engineering-notes/AEN124.pdf)）で波長1310nmが1.467、1550nmが1.468で、光速をこの値で割ると毎秒約20.4万kmになります。1kmあたり約5マイクロ秒、**片道1,000kmの区間を往復すると約10ms**が、どんな機器を使っても下回れない物理的な下限です。

実際の値と比べるため、AWSの各リージョンにあるDynamoDBのエンドポイントへ、東京からcurlでそれぞれ7回接続し、TCP接続にかかった時間（≒RTT）の中央値をとりました。大圏距離は東京と各リージョン所在都市の座標から計算した概算です。

| 接続先（リージョン）             | 大圏距離      | 理論上の下限RTT | 実測RTT（中央値） | 倍率    |
| ---------------------- | --------- | --------- | ---------- | ----- |
| 東京（ap-northeast-1）     | –         | –         | 19.4ms     | –     |
| 大阪（ap-northeast-3）     | 約400km    | 3.9ms     | 24.9ms     | –     |
| シンガポール（ap-southeast-1） | 約5,300km  | 52.1ms    | 92.9ms     | 1.78倍 |
| オレゴン（us-west-2）        | 約8,000km  | 78.1ms    | 140.6ms    | 1.80倍 |
| バージニア北部（us-east-1）     | 約10,900km | 106.6ms   | 192.8ms    | 1.81倍 |
| アイルランド（eu-west-1）      | 約9,600km  | 94.0ms    | 270.4ms    | 2.88倍 |

読み取れることは3つあります。1つ目は、同じ都内のリージョンでも約19msかかっている点です。このうちどれだけが自宅からISPまでのアクセス回線の分かは、この測定だけでは分けられません。一方で東京と大阪の差は約5.5msで、往復800kmの理論値（約4ms）に近い値でした。2つ目は、海外ではケーブルが大圏に沿って敷かれていないことや中継の処理が加わることで、実測が理論値の約1.8倍になる点です。3つ目は、アイルランドだけ2.88倍と大きいことで、前の章のtracerouteのとおり、東京からロンドンを経由する遠回りの経路になっていました。

この表から言えるのは、**距離による伝搬遅延の下限は、サーバー性能や回線帯域を増やしても縮まらない**ということです。日本のサーバーにアメリカ東部の利用者がアクセスすると、新規のHTTPS接続だけで0.6秒近くかかります。主な対策は配信拠点の近接化（CDN・海外リージョン・エッジ）で、経路の改善や接続再利用も検討できます。処理を利用者の近くで行う設計については[エッジコンピューティングの仕組みとクラウドとの違い](/column/details/15366/)で解説しています。

## レイテンシーが高くなる原因の切り分け

「遅い」と言われたときは、どの層で遅延が生じているかを測定結果の形から当てていきます。

| 測定で見える症状              | 疑う層        | 確かめ方             |
| --------------------- | ---------- | ---------------- |
| 1ホップ目（自宅ルーター）から遅い・揺れる | Wi-Fi・LAN  | 有線LANで測り直す       |
| 夜だけRTTが跳ねる            | ISP・回線の混雑  | 時間帯を変えてp95を比較    |
| 特定のホップから先が一律に遅い       | 距離・国際区間    | tracerouteの都市名   |
| RTTは小さいがTTFBが大きい      | サーバー処理・DB  | curl -wの差分・APM   |
| TLSにRTTの2倍かかる         | TLS 1.2のまま | curl -vでTLS版を確認  |
| packet lossが0%でない     | 回線・機器の不良   | pathping・mtrの損失率 |

多いのは、ネットワークを疑って回線を見直したのに、実際はサーバー処理やデータベースの待ちが原因だったというケースです。RTTが小さいのにTTFBが大きい場合は、DNS・接続確立・再送の影響を確認したうえで、サーバー処理を調べます。逆に、利用者の通信環境に起因する遅延は、Wi-Fiの電波干渉や古いルーターがよくある原因で、有線LANで測り直すだけで切り分けられます。

## 用途別のレイテンシーの目安

「何ms以下なら快適」という値は用途で大きく変わります。ここでは規格や公式ガイドに根拠がある値だけを挙げます。

| 用途             | 目安          | 測る区間           | 根拠              |
| -------------- | ----------- | -------------- | --------------- |
| 音声通話・Web会議     | 片道150ms以内   | 口から耳まで         | ITU-T G.114     |
| Webページの初期応答    | TTFB 0.8秒以内 | リクエストから最初の1バイト | web.dev         |
| Webページの表示      | LCP 2.5秒以内  | 最大要素の描画まで      | Core Web Vitals |
| 操作への反応         | INP 200ms以内 | 操作から次の描画まで     | Core Web Vitals |
| 5Gの無線区間（eMBB）  | 4ms         | 無線区間の片道        | ITU-R M.2410    |
| 5Gの無線区間（URLLC） | 1ms         | 無線区間の片道        | ITU-R M.2410    |

音声通話の150msは[ITU-T G.114](https://www.itu.int/rec/T-REC-G.114-200305-I/en)が示す片道の目安で、150ms未満なら大半のアプリケーションは大きな影響を受けないとされ、一般的なネットワーク設計では片道400msを超えないことが推奨されています。この値はネットワークの遅延だけでなく符号化やバッファの時間も含みます。pingのRTTに置き換えると往復なので、回線の遅延だけで100ms台に乗る海外との通話は、余裕が少ないと考えてください。TTFBの0.8秒は[web.devのTTFBの解説](https://web.dev/articles/ttfb)で「良好」とされる値で、LCPは2.5秒以下、INPは200ms以下が「良好」です。サイトの評価では、モバイルとデスクトップを分けた75パーセンタイル値で判定します。WebのTTFB・LCP・INPの基準と測り方は[Core Web VitalsのLCP・INP・CLSの基準値と測り方](/tech/details/18645/)にまとめています。

5Gの1msは、ITU-Rが[ITU-R M.2410-0](https://www.itu.int/dms%5Fpub/itu-r/opb/rep/R-REP-M.2410-2017-PDF-E.pdf)（2017年11月）の4.7.1節でIMT-2020（5G）の最低要件として定めたユーザープレーン遅延（eMBBは4ms）で、端末からインターネット上のサーバーまでの遅延ではありません。また、無負荷（unloaded）で端末がアクティブ状態にあるという評価条件での値です。「5Gならどこと通信しても1ms」という意味ではない点に注意が必要です。オンラインゲームについては、規格として決まった値が無く、目安はゲームや情報源ごとにまちまちです。競技性の高い対戦ゲームほど低い値が求められる、という程度に捉え、運営が推奨値を出していればそれに従ってください。

## レイテンシーを下げる方法と優先順位

測定で原因の層がわかったら、その層に効く対策から手を打ちます。

### 往復回数を減らす：接続の再利用とTLS 1.3・HTTP/3

距離を変えられなくても、往復の回数は減らせます。アメリカ東部のエンドポイントに、1回のcurlで同じURLを2回続けて要求した結果です。

```
$ curl -s -o /dev/null -o /dev/null -w "conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} new_conns=%{num_connects}\n" https://dynamodb.us-east-1.amazonaws.com/ https://dynamodb.us-east-1.amazonaws.com/
conn=0.195950 tls=0.378963 ttfb=0.554609 new_conns=1
conn=0.000000 tls=0.000000 ttfb=0.191249 new_conns=0
```

1回目は新規接続で0.55秒、2回目は接続を使い回したため `new_conns=0` で、TCPとTLSの往復が消えて0.19秒（RTT 1回分）に縮みました。HTTPのKeep-Alive、HTTP/2の多重化、DBやAPIの接続プールは、この効果を狙ったものです。

TLSのバージョンも往復回数に直結します。同じ回線で、TLS 1.3で応答したAWSのエンドポイントはTLSハンドシェイクが約0.18秒（1往復）、TLS 1.2で応答したhttpbin.orgは約0.38秒（2往復）かかりました。TLS 1.3はフルハンドシェイクが1往復で、以前の接続で鍵を共有していれば最初の送信でデータを送る0-RTTも使えます。TLS 1.3の仕様はRFC 8446でしたが、2026年7月に[RFC 9846](https://www.rfc-editor.org/rfc/rfc9846.html)へ改訂され、RFC 8446とTLS 1.2のRFC 5246は廃止扱い（Obsoletes）になりました。仕組みと0-RTTを使ってよい条件は[TLS 1.3の仕組みと0-RTTの採否](/tech/details/16243/)を参照してください。さらにHTTP/3（2022年6月公開のRFC 9114）はQUIC（2021年5月公開のRFC 9000）の上で動き、[RFC 9001](https://www.rfc-editor.org/rfc/rfc9001.html#section-2)のとおり接続確立と暗号化のハンドシェイクを1往復にまとめ、条件を満たす再接続では0-RTTも使えます（[QUICの仕組みとTCPとの違い](/tech/details/16234/)）。

### 距離を縮める：CDN・リージョン・エッジ

前の章の表は、海外向け通信では距離の影響が大きく、配信拠点の近接化が有力な対策になることを示しています。画像・CSS・JavaScriptなどの静的ファイルはCDNで利用者に近い拠点から返し、APIやデータベースは利用者が集中する地域のリージョンに置きます。今回の東京発の測定では、大阪と東京の中央値の差は約5.5msでした。配置先は、利用者の地域ごとの遅延と可用性要件で判断します。

ただし、データベースを複数の地域に分けると、書き込みの整合性を保つための通信が地域間で発生し、かえって遅くなることがあります。どこまで分散させるかは、読み取りと書き込みの比率で決めます。クラウド上の配置やネットワーク構成の設計から相談したい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)でも対応しています。

### 待ち時間と処理時間を減らす：混雑・サーバー・データベース

RTTは小さいのにTTFBが大きい場合は、DNSや接続確立などを分けて確認し、サーバー処理が長いかを調べます。遅いSQLの改善、キャッシュの導入、同期処理の非同期化が主な手段で、サーバー処理が主因なら、ネットワーク設定だけを変えてもその処理時間は短縮できません。社内ネットワークで特定の時間帯だけ遅延が膨らむ場合は、帯域の増強やQoS（通話や業務システムを優先する設定）で待ち行列を減らします。

利用者の側でできるのは、Wi-Fiから有線LANへの切り替え、古いルーターの交換、IPv6（IPoE）方式に対応した回線やプロバイダーへの変更です。アクセス回線の遅延や混雑が原因なら、海外サーバーへの総遅延も改善できます。ただし、海外までの距離による伝搬時間は短縮できません。

## 低遅延化に投資しないほうがよい場面

レイテンシーは低いほど良い指標ですが、下げるための費用が効果に見合わない場面もあります。

1つは、利用者の体感が変わらない領域です。夜間に動くバッチ処理や、結果をメールで受け取る帳票の生成は、ターンアラウンドタイムが問題であってレイテンシーではありません。数十msを削るために高価な回線や複数リージョン構成を入れても、誰も違いに気づきません。

もう1つは、遅延より正しさを優先すべき処理です。決済・在庫の引当・会計の記帳は、読み取りを近くのキャッシュや複製から返すと速くなる一方で、古いデータを返すリスクが生まれます。こうした処理は、多少遅くても1か所のデータベースで確定させる設計が安全です。**低遅延化は「利用者が待っている処理」と「何度も往復する処理」に絞って投資する**のが、費用対効果の高い判断です。

## よくある質問

### レイテンシーとレスポンスタイムの違いは？

レイテンシーはネットワーク上でデータが移動する遅延時間、レスポンスタイムはそれにサーバーの処理時間と転送時間を加えた、操作から応答までの全体の時間です。RTTが小さいのにレスポンスタイムが大きい場合も、DNS・接続確立・転送とサーバー処理を分けて確認します。

### レイテンシーは何msなら快適に使えますか？

用途によります。音声通話は片道150ms以内（ITU-T G.114）、Webページは最初の1バイトが返るまで0.8秒以内（web.dev）が基準です。国内のサーバーとの通信なら、pingのRTTは数ms〜数十msに収まるのが普通です。

### レイテンシーとpingは同じ意味ですか？

同じではありません。pingはレイテンシー（往復時間）を測るためのコマンドの名前で、「Ping値」は通常RTTの指標ですが、測定方式はサービスによって異なります。pingコマンドは制御用のICMPパケットを使うため、アプリの通信の遅延と一致しない場合があります。

### レイテンシーとスループットの違いは？

レイテンシーは1つのデータが届くまでの時間（ms）、スループットは1秒あたりに運べるデータ量（bps）です。回線を太くするとスループットは上がりますが、距離で決まるレイテンシーは縮みません。

### レイテンシーが高いとはどういう意味ですか？

遅延時間が大きく、応答が返るまで待たされる状態を指します。レイテンシーは数値が低いほど良好です。Web会議の音声の遅れ、ゲームの操作の遅れ、ページの表示の遅れとして現れます。

## 関連記事

- [Pingスパイクの原因と対策｜pingとpathpingの見方で自宅かISPかを切り分ける](/tech/details/12052/)
- [IOPSとは？計算式とスループット・レイテンシの違い、目安とSSD/クラウドの性能設計](/tech/details/14683/)
- [輻輳とは？ネットワーク混雑の仕組み・原因・TCP輻輳制御から対策の判断まで実装者向けに解説](/tech/details/14677/)
- [TLS 1.3とは？RFC 8446の仕組みと0-RTTの採否を実装者向けに解説](/tech/details/16243/)
- [Core Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitals・CrUX APIでの測り方【2026年10月】](/tech/details/18645/)

---

出典: [レイテンシーとは？レスポンスタイム・スループットとの違いと測定方法・目安](<https://www.issoh.co.jp/column/details/7053/>)（株式会社一創）