WebRTCによる超低遅延配信

なぜWebRTCが超低遅延なのか：設計思想と現場の数値感

双方向コミュニケーションを前提に設計されたWebRTCは、UDPベースのSRTP、エンドツーエンドな輻輳制御、ICEでの経路最短化が噛み合い、映像配信の往復遅延をサブ秒に抑えやすいのが強みです。一般的な設定でも国内視聴なら片道400〜800ms、LANや閉域なら300ms前後まで現実的に狙えます。HTTPベースのセグメント配信は安定と拡張性が長所ですが、セグメント長・バッファにより数秒〜十数秒の遅延が出やすく、オークション、ライブコマース、遠隔指導のように「相互作用」がKPIに直結する場面ではWebRTCの適性が高いです。

低遅延の鍵はネットワークだけではありません。エンコーダのGOP長（1〜2秒）、キーフレームリクエスト（PLI）への即応、ジッタバッファの最小化、音声優先度の設定、そしてシミュルキャスト／SVCでのレイヤー切替が、体感の差を大きく左右します。音声はOpus 48kHz・64kbps前後での堅牢性が高く、映像は端末互換性を重んじるならH.264、帯域効率を詰めるならVP9/AV1といった住み分けが現場の定石です。

実装アーキテクチャとチューニングの勘所

配信構成の選択

P2Pは少人数の会議で有効ですが、ライブ配信は送信側の上りがボトルネックになりがちです。多数視聴のケースではSFUでのファンアウトが前提になります。MCUは帯域効率は良い反面、サーバ側負荷とトポロジの柔軟性で不利。多拠点からの取り込みはWHIPで統一し、再生側はWHEPで単純化するとクライアント実装の負債が減ります。

ネットワーク設計

ICEでの候補収集はSTUN優先、失敗時にTURNリレーへフォールバック。モバイル比率が高いとTURN利用率は5〜20%に達することがあります。遅延を詰めるなら、地域別に中継ノードを置き、同地域内での経路確立を優先。TCPフォールバックを許可しつつ、QUIC/UDP優先を保つのが実務的です。

映像レイヤーと輻輳制御

シミュルキャストで1080p/720p/360pの3層を用意し、視聴者ごとに選好レイヤーを切り替えます。平均ターゲットは1.5〜2.5Mbps（1080p30）、0.9〜1.5Mbps（720p）、0.3〜0.5Mbps（360p）が目安。TWCCベースのフィードバックでGCCが帯域を追従できるよう、キーフレーム間隔は短すぎず（頻発はビットレートを圧迫）、ロス時はNACK/PLIで回復、FECはイベント性が高い場合のみオンにするなど、状況に応じて切り替えます。

録画・サイマル出力

長時間アーカイブや見逃し視聴を考えるなら、SFUでのサーバサイド録画と、HLS/DASHへのブリッジを並走させます。超低遅延の「ライブ面」とスケール優先の「VOD面」を分離することで、ピーク帯域とコストの変動をコントロールしやすくなります。

コストと運用：帯域・サーバ・監視のリアル

容量設計の第一変数は帯域です。平均選択レイヤーが1Mbpsで同時視聴1,000ならSFUの外向きだけで約1Gbps。これにTURN経由（上り下りとも課金対象になりやすい）と録画・サイマルの出力を加味します。粗い試算式は「平均視聴ビットレート × 同時数 × 1.1（プロトコルオーバーヘッド）」。イベント型ならピーク3倍を許容するバッファを、常設配信なら日内変動の平準化を意識します。

監視は「繋がるか」「滑らかか」「聞こえるか」を分解して可視化します。

• 接続性：ICE成功率（目安90%以上）、TURN利用率、シグナリング遅延
• 品質：RTT、パケットロス、Jitter、フレームドロップ、再送要求（NACK/PLI）
• 体感：再生開始までの時間、視聴遅延中央値、離脱の分位点

運用改善では、端末・回線別の切り分けが効きます。モバイル4Gは360p優先で音声を強め、Wi‑Fi/有線は720p以上を初期採択。障害時は低レイヤー固定＋音声優先に自動フォールバック。チャットや投票はDataChannelでリアルタイム処理し、バックエンド集計は冪等に。制作ワークフローでは、サムネやバナーをMidjourneyやStable Diffusionで素早く量産し、配信後のチャット要約やFAQ抽出をChatGPTやClaudeで回すと、編成とCSの反応速度が上がります。

身近な企業活用例：ライブコマースの失敗から改善まで

都市近郊で15店舗を展開する生活雑貨チェーンのEC部門（担当8名）。週末のライブコマースをHLSで始めたところ、遅延は12〜18秒。司会者の「今だけ割引！」にチャットが追随せず、クーポン適用のタイミングもズレ、視聴は伸びてもCVRは伸びませんでした。遅延対策としてWebRTCに切替えましたが、当初はP2Pで配信し、配信者の上り回線が飽和。映像がカクつき、離脱が悪化する逆効果に。

転機はSFU採用と配信レイヤー整理です。1080p/720p/360pのシミュルキャストに変更し、初期は720pを提案、回線状態で自動ダウンシフト。音声はOpus 64kbpsで安定化、ジッタバッファを短縮。モバイル視聴が多い時間帯は地域近接の中継ノードに誘導し、TURNはピーク時のみスケール。チャット・投票はDataChannelに集約し、重要な告知に合わせてキーフレームを即発行する仕組みを入れました。制作面では、毎回のテーマに合わせたキービジュアルをMidjourneyで素早く試作し、最終仕上げをデザイナーが行う体制に変更。配信後はChatGPTでチャットを要約し、次回の台本改善点を抽出しました。

結果、中央値の視聴遅延は約450msに。クーポン告知から適用までのラグが解消され、リアクションの「同時感」が戻りました。CTRは25%増、配信中CVRは18%増。帯域コストは増えたものの、TURN利用率を12%→6%へ抑制し、ピークでも輻輳制御が破綻しない設計に。現場が学んだのは「P2Pは少人数向け」「遅延は映像だけでなく運用と演出でも詰める」ということ。以降は、商品QAの事前整理をClaudeで、サムネの別案生成をStable Diffusionで行い、準備時間を3割短縮しました。

超低遅延は魔法ではなく、設計・チューニング・運用が三位一体で成立します。動画プラットフォーム事業としては、インタラクションを生む体験をWebRTCで担保しつつ、VODやサイマル出力でスケールとアーカイブの土台を整える。その二層構造が、視聴体験と経済性を両立させる現実解です。