レイテンシとは？ わかりやすく10分で解説

レイテンシとは

レイテンシ（Latency）とは、通信や処理における「遅れ」のことです。かんたく言うと、何かをしてから結果が返ってくるまでの待ち時間を指します。

たとえば、Webページのリンクをクリックしてから画面が表示されるまでの時間、オンライン会議で話した声が相手に届くまでの時間、オンラインゲームで操作が反映されるまでの時間などがレイテンシです。レイテンシが短いほど、体感は「キビキビ」します。

なお、レイテンシはネットワークだけでなく、サーバー内部の処理（アプリの計算、DB検索、暗号化処理など）でも発生します。「通信の遅れ」だけに限定せず、全体の“待ち”として捉えると理解しやすいです。

レイテンシと混同しやすい言葉

レイテンシと似た言葉はいくつかあります。ここで整理しておくと混乱が減ります。

• 帯域幅（Bandwidth）：一定時間に送れるデータ量の上限（道路の「車線数」）
• スループット（Throughput）：実際に出ている転送量（道路を「実際に流れている車の量」）
• RTT（Round Trip Time）：送って戻るまでの往復時間（pingで測る値のイメージ）
• ジッター（Jitter）：レイテンシの揺れ幅（遅れが毎回バラつく状態）

ポイントは、帯域幅が大きくても、レイテンシが短いとは限らないことです。回線が太くても「最初の一歩」が遅いと体感は遅く感じます。

レイテンシが重要な理由

レイテンシはユーザー体験（UX）に直結します。待ち時間が増えるほど、操作が「重い」「反応が遅い」と感じやすくなります。

特にレイテンシが効きやすいのは、次のようなリアルタイム性が求められる用途です。

• オンライン会議（音声・映像の遅れが会話のしにくさになる）
• オンラインゲーム（操作遅延が勝敗やストレスに直結する）
• リモートデスクトップ／VDI（マウスやキー入力の体感が悪くなる）
• 決済・取引（少しの遅れが業務の詰まりになることがある）

逆に、ファイルの一括ダウンロードなどは、レイテンシよりも帯域幅やスループットが効きやすいケースが多いです（もちろん、条件によって変わります）。

レイテンシの測定方法

ネットワークのレイテンシを測る

ネットワークの遅れを確認する代表的な方法は次の通りです。

• ping：相手に届いて戻るまで（RTT）の時間を測る
• traceroute / tracert：どこを経由して遅れているか（中継点）を調べる
• mtr：traceroute + ping のように継続観測する（環境がある場合）

pingは手軽ですが、ICMPが制限されている環境では正確に見えないことがあります。その場合は、アプリ層（HTTPなど）での計測も併用すると実態が掴みやすいです。

Webの体感速度として測る

Webページの「遅い／速い」は、通信だけでなく、サーバー処理やブラウザ描画の時間も含まれます。そのため、次のような指標で見ます。

• サーバー応答（TTFB）：最初の応答が返るまでの時間
• ロード時間：表示に必要なリソースが揃うまで
• 描画の指標：主要コンテンツが見えるまで、操作可能になるまで、など

ツールとしては、ChromeのLighthouse、GoogleのPageSpeed Insights、ブラウザの開発者ツール（Networkタブ）などがよく使われます。

レイテンシと他のネットワーク指標

レイテンシと帯域幅

帯域幅は「一度に運べる量」、レイテンシは「届くまでの遅れ」です。たとえば、太い回線でも遠いサーバーにあると、クリックしてから反応が返るまでが遅くなることがあります。

また、本文にある「帯域幅を増やすとレイテンシも増える可能性がある」という説明は、少し誤解が生まれやすいです。帯域幅そのものがレイテンシを増やすというより、混雑（輻輳）や装置処理、バッファの溜まりなどが原因で遅れが増えるケースが多いです。回線を太くすると混雑が減って、結果としてレイテンシが改善することも普通にあります。

レイテンシとスループット

スループットは「実際に出ている転送量」です。一般に、TCP通信ではレイテンシ（RTT）が大きいと、ウィンドウ制御の影響でスループットが伸びにくいことがあります。

ただし「大量のデータを送るとレイテンシが増える」は状況次第です。ネットワークが混雑してキューが溜まると遅れが増えますが、余裕があるなら増えません。ここも、原因は「量」そのものというより、混雑と待ち行列です。

レイテンシとジッター

ジッターはレイテンシのブレです。音声・映像・ゲームなどは「遅れが小さい」ことに加えて、「遅れが安定している」ことも重要です。レイテンシがそこそこでも安定していれば、バッファで吸収できる場合があります。

レイテンシとパケット損失

パケット損失が起きると、再送が発生し、結果として体感の遅れが増えます。特にTCPでは、損失があると輻輳制御が働いて速度が落ち、遅さが目立つことがあります。

レイテンシに影響を与える要素

物理的距離と伝搬遅延

距離が伸びるほど、信号が届くまでの時間は増えます。光ファイバーでも無限に速いわけではなく、物理的に「遠い」と遅れは増えます。これはレイテンシの中でも基本となる要素です。

中継点（ルーター・スイッチ）と処理時間

通信は複数の機器や回線を経由します。経由する装置の性能、設定、混雑状況によって、そこでの待ち（キューイング）が増えるとレイテンシが大きくなります。

無線の品質（Wi-Fi／モバイル）

無線は干渉や電波状況に左右されやすく、再送が増えたり、遅れのブレ（ジッター）が増えたりしがちです。「pingが跳ねる」のは無線要因のことも多いです。

パケットサイズ

パケットが大きいと送信に時間がかかることがあり、逆に小さすぎるとヘッダの割合が増えて効率が落ちることがあります。実際はMTUやアプリの送信設計、混雑状況などとセットで見ます。

レイテンシを下げる方法

レイテンシ対策は「どこで遅れているか」によって効く打ち手が変わります。代表的な考え方は次の通りです。

• 距離を縮める：利用者に近い拠点にサーバーを置く、CDNを使う
• 混雑を減らす：回線増強、QoS、ピークの平準化、経路の最適化
• プロトコル改善：HTTP/2やHTTP/3（QUIC）を検討する
• リクエスト数を減らす：外部リソース削減、バンドル、キャッシュ活用
• 処理を速くする：サーバー側のDB改善、キャッシュ、アプリのボトルネック解消

本文にあるHTTP/2は有効な場面がありますが、「開発者が何も変えなくてよい」とは言い切れません。サーバー設定、TLS、配信基盤、HTTP/2で逆効果になる構成（無理な分割など）もあり得ます。導入は「可能なら有益」ですが、計測しながら進めるのが安全です。

まとめ

レイテンシは、ユーザーの操作から結果が返るまでの待ち時間であり、Web、会議、ゲーム、業務システムなど体感品質に直結します。

帯域幅やスループットとは違う指標で、レイテンシを下げるには「距離」「混雑」「中継点の処理」「無線品質」「サーバー処理」など、どこに原因があるかを見極めることが大切です。まずはpingやトレース、Webの指標（TTFBなど）で現状を測り、効く対策から順に打っていきましょう。