レイテンシとは

レイテンシ (Latency) とは、データが送信元から宛先に到達するまでにかかる時間のことです。一般にミリ秒 (ms) 単位で測定され、値が小さいほど応答が速いことを意味します。

Web ブラウザで URL を入力してからページが表示され始めるまでの「待ち時間」の大部分は、レイテンシによるものです。DNS の名前解決、TLS ハンドシェイク、サーバーの処理時間、そしてデータの往復にかかる物理的な伝搬遅延が積み重なって、体感的な遅さを生み出します。

レイテンシは「水道管の長さ」に例えられます。蛇口をひねってから水が出るまでの時間がレイテンシであり、水が出始めた後の水量が帯域幅です。どれだけ太い管 (高帯域幅) を用意しても、管が長ければ最初の一滴が届くまでに時間がかかります。

レイテンシの測定方法

レイテンシを測定する代表的なツールは ping と traceroute です。

ICMP Echo Request を送信し、応答が返るまでの往復時間 (RTT: Round-Trip Time) を測定する。最も手軽なレイテンシ確認手段。ping example.com で実行でき、平均 RTT・最小・最大・パケットロス率が表示される。

パケットが宛先に到達するまでに経由する各ルーター (ホップ) のレイテンシを個別に表示する。どの区間で遅延が発生しているかを特定できる。Windows では tracert、macOS / Linux では traceroute コマンドを使用。

ping と traceroute を組み合わせたツール。各ホップのレイテンシとパケットロスをリアルタイムに継続表示し、断続的な遅延の検出に優れる。

測定時の注意点として、レイテンシは時間帯やネットワーク混雑状況で大きく変動します。1 回の測定で判断せず、異なる時間帯に複数回測定して傾向を把握することが重要です。

レイテンシと帯域幅の違い

レイテンシと帯域幅は混同されやすいですが、まったく異なる指標です。

データが到達するまでの「時間」。単位はミリ秒 (ms)。物理的な距離、経由するルーターの数、処理遅延に依存する。

単位時間あたりに転送できるデータの「量」。単位は Mbps / Gbps。回線の太さに相当する。

回線速度テストで「下り 1 Gbps」と表示されても、レイテンシが 200 ms あれば Web ページの表示は遅く感じます。逆にレイテンシが 5 ms でも帯域幅が 1 Mbps なら、大容量ファイルのダウンロードには時間がかかります。用途に応じてどちらの指標が重要かが変わります。リアルタイム通信 (ゲーム、ビデオ会議) ではレイテンシが、大容量転送 (動画ストリーミング、バックアップ) では帯域幅が支配的な要因になります。

用途別のレイテンシ影響

レイテンシの許容値は用途によって大きく異なります。

オンラインゲーム: FPS やリアルタイム対戦では 20 ms 以下が理想、50 ms を超えると操作の遅れが体感でき、100 ms 以上では競技性に深刻な影響が出る。ゲームサーバーの物理的な距離が最大の要因であり、CDN やエッジサーバーの活用が有効。
ビデオ会議: 150 ms 以下であれば自然な会話が可能。300 ms を超えると発話のタイミングがずれ、会話のキャッチボールが困難になる。音声は映像よりレイテンシに敏感で、音声だけ先に届くと違和感が生じる。
動画ストリーミング: バッファリングにより再生中のレイテンシは問題になりにくい。ただし再生開始までの待ち時間 (初期バッファ) にはレイテンシが影響する。ライブ配信では低レイテンシが視聴体験を左右する。
Web ブラウジング: ページ読み込みには複数の HTTP リクエストが発生するため、1 リクエストあたりのレイテンシが積み重なる。HTTP/2 や HTTP/3 の多重化はこの問題を緩和する。

レイテンシを削減する方法

レイテンシの削減には、物理的な距離の短縮とプロトコルの最適化の両面からアプローチします。

CDN (コンテンツ配信ネットワーク): ユーザーに近いエッジサーバーからコンテンツを配信し、物理的な伝搬遅延を最小化する。静的コンテンツだけでなく、動的コンテンツのキャッシュや API レスポンスの高速化にも活用される。
エッジコンピューティング: 処理自体をユーザーの近くで実行する。Cloudflare Workers や AWS Lambda@Edge が代表例。サーバーへの往復を減らし、レイテンシを大幅に短縮できる。
HTTP/3 (QUIC): UDP ベースのプロトコルで、TCP の 3 ウェイハンドシェイクと TLS ハンドシェイクを統合し、接続確立のラウンドトリップを削減する。初回接続で 1-RTT、再接続で 0-RTT を実現。
DNS の最適化: 高速なパブリック DNS (Cloudflare の 1.1.1.1 や Google の 8.8.8.8) を使用し、名前解決のレイテンシを短縮する。DNS プリフェッチ (<link rel="dns-prefetch">) も有効。
接続の事前確立: <link rel="preconnect"> で DNS 解決・TCP 接続・TLS ハンドシェイクを事前に完了させ、実際のリクエスト時のレイテンシを削減する。

よくある誤解

回線速度が速ければレイテンシも低い: 帯域幅 (回線速度) とレイテンシは独立した指標です。光回線で 1 Gbps の帯域幅があっても、地球の裏側のサーバーへのレイテンシは 200 ms を超えます。光の速度という物理的な制約があるため、帯域幅をいくら増やしても距離に起因するレイテンシは改善しません。
レイテンシはサーバー側の問題: レイテンシはクライアントからサーバーまでの経路全体で発生します。自宅の Wi-Fi ルーターの処理遅延、ISP のバックボーンの混雑、海底ケーブルの物理的距離、経由するルーターの数など、複数の要因が積み重なります。サーバーの応答時間はレイテンシの一部にすぎません。
ping が低ければすべてのアプリケーションが快適: ping は ICMP パケットの往復時間を測定しますが、実際のアプリケーション通信は TCP/UDP を使用し、パケットサイズや通信パターンも異なります。また、ジッター (レイテンシの揺らぎ) やパケットロスも体感品質に大きく影響するため、ping の値だけでは通信品質を完全には評価できません。

レイテンシ (Latency)