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

レイテンシとは

レイテンシ（Latency）とは、通信や処理で何かを始めてから結果が返るまでの待ち時間です。ネットワークだけでなく、サーバーやアプリの処理待ちも含めて考えます。

• 短いほど、操作への反応は速く感じられます
• オンライン会議、ゲーム、リモート操作では影響が出やすい指標です
• 帯域幅やスループットとは分けて見る必要があります

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

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

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

レイテンシと似た言葉はいくつかあります。先に違いを見ておくと、意味を取り違えにくくなります。

• 帯域幅（Bandwidth）：決まった時間内に送れるデータ量の上限（道路の「車線数」）
• スループット（Throughput）：実際に出ている転送量（道路を実際に通っている車の量）
• RTT（Round Trip Time）：送って戻るまでにかかる時間です。pingでは、ICMP Echo Request と Echo Reply にかかる時間を測ります。
• ジッター（Jitter）：レイテンシの揺れ幅（遅れが毎回バラつく状態）

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

レイテンシが重要な理由

レイテンシはユーザーが感じる使いやすさに大きく関わります。待ち時間が増えるほど、操作は「重い」「反応が遅い」と感じられやすくなります。

特にレイテンシの影響が出やすいのは、次のようにすぐ反応してほしい処理です。

同じ遅れでも、ファイル転送のような処理と、会話や離れた場所からの操作のような処理では感じ方が変わります。用途ごとに見るべき指標を分けると、何を優先して改善するかを決めやすくなります。

• オンライン会議（音声・映像の遅れが会話のしにくさになる）
• オンラインゲーム（操作の遅れが勝敗やストレスに影響しやすい）
• リモートデスクトップ／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など）で今の状態を測り、有効な対策から順に進めましょう。