配信プロトコル徹底比較｜RTMP・HLS・LL-HLS・DASH・WebRTCの遅延を数値で使い分ける完全解説

2026-07-21

会場の外壁に設置した大型ビジョンに、ライブ配信用のカメラ映像をそのまま表示していたことがある。スピーカーからは会場のPAが生音を流し、ビジョンにはその同じ音と映像が「配信経路を経由して」戻ってくる。開演直後、観客の何人かが「口の動きと音がズレている、エコーみたいだ」と口にした。

機材トラブルを疑って配線を洗い直したが、原因はケーブルでも機材でもなかった。配信に使っていたHLSという方式そのものに、22秒前後の遅延が構造的に組み込まれていたのだ。

22秒はどこから来るのか

HLSはApple社が策定した配信方式で、映像を6秒単位の「セグメント」に分割してサーバーに送り、視聴側はそれをダウンロードしながら再生する。この6秒という長さはApple社のHLS Authoring Specificationが推奨する値である。

さらに視聴側は、再生の安定性を保つために「プレイリストの末尾から3セグメント分は遡って再生を始める」というルールに従う（RFC8216bisのHOLD-BACK規定）。6秒×3＝18秒がまず理論上の最小遅延になり、そこにエンコードとパッケージング、CDN配信のオーバーヘッドが加わることで、実測ではおよそ22秒のグラス・トゥ・グラス遅延（カメラのレンズから視聴者の画面までの遅延）に達する。

これは機材の性能や設定ミスの問題ではない。HLSという方式が「まとめてから送る」設計思想を持っている以上、避けられない構造なのだ。

あなたの現場が悪いわけではない

これは、荷物の配送方法の違いに近い。HLSは宅配便のようなものだ。荷物（映像データ）をいったん段ボール（セグメント）に詰めて、トラック（CDN）に積んでから届ける。箱がいっぱいになるまで待つ時間が、そのまま遅延になる。

一方で、後述する別の配信方式には、荷物ができた瞬間に一つずつ届けるバイク便のような仕組みも存在する。どちらが優れているという話ではなく、荷物の量や届け先の数によって使うべき配送手段が違うだけだ。あなたの現場で起きた「ズレ」は、配送手段の選定という設計の問題であり、現場対応力の問題ではない。

方法は存在する

配信の遅延を決める要素は、実はプロトコルの選び方一つでほぼ決まる。RTMP・HLS・LL-HLS・DASH・WebRTCという5つの方式にはそれぞれ得意な遅延帯と、視聴者数への対応力と、双方向性の有無が異なる。この特性を理解して使い分ければ、「大型ビジョンと生音のズレ」も、「視聴者からのチャットが届くタイミングのズレ」も、設計段階で防げる。