01. なぜ MoQ なのか

🎯 この章のゴール

• 既存のライブ配信技術（RTMP / HLS・DASH / WebRTC）の得意・不得意を知る
• Media over QUIC（MoQ）が何を目指しているのかを説明できる
• IETF moq ワーキンググループのドラフト群の全体像を掴む

💡 ひとことで言うと

MoQ は「CDN で配れる WebRTC」を目指す新しい pub/sub プロトコルです。数百ミリ秒の遅延のまま、数百万人規模の視聴者に届けることを狙っています。

ライブ配信の 3 つの世界

今日のライブ配信は、用途ごとに別々の技術でできています。

低遅延な技術は大規模配信に向かず、大規模に配れる技術は遅い、という状態です。区間ごとにプロトコルも違うので、途中で「RTMP を受けて HLS に変換する」ような再パッケージが必要になります。

MOQT の 4 つの設計目標

MOQT（Media over QUIC Transport）のドラフトは、冒頭で次の 4 つの動機を挙げています。

1. Latency（遅延）: 遅延は、ネットワークの帯域変動を吸収するためにバッファを持つことで生まれます。TCP ベースのプロトコルは輻輳の検知が遅く、HoL ブロッキングもあります。UDP を直接使えば待ちは減りますが、再送や輻輳制御を全部自前で作ることになります。MOQT は QUIC を使って両者の利点を取り、輻輳にすばやく反応することを目指します。
2. Leveraging QUIC（QUIC の活用）: 並列なストリームと柔軟な損失回復を活かします（次章）。
3. Convergence（収束）: 取り込みから配信までを 1 つのプロトコルで行い、再パッケージ用のオリジンを不要にします。
4. Relays（リレー）: 大規模配信には、パブリッシャともサブスクライバとも独立した第三者のネットワーク（CDN）が欠かせません。MOQT はリレーを第一級市民として扱い、配信に必要なメタデータはリレーに見せ、メディアの中身は不透明なまま秘匿できるようにします。

MOQT は「メディア専用」ではない

名前に反して、MOQT は content agnostic（中身を問わない）と明記されています。MOQT が知っているのは「名前の付いたトラックに、番号の付いたバイト列（Object）が流れる」ことだけです。

映像や音声をどう Object に詰めるか、どんなトラックがあるかをどう知らせるかは、別のストリーミングフォーマット仕様が決めます。チャット、ゲームの状態同期、センサーデータ、AI の音声応答なども MOQT に載せられます。

IETF moq WG のドラフト群

これとは別に、moq.dev は MOQT のサブセット「moq-lite」と独自のメディアフォーマット「hang」を実装し、それを使った CDN（moq.pro）も提供しています（13 章）。

flowchart LR
  app["アプリ"] --> fmt["フォーマット<br/>MSF・LOC など"] --> moqt["MOQT<br/>pub/sub"] --> tr["QUIC /<br/>WebTransport"]

🧪 考えてみよう

スポーツのライブ中継で、隣の家の歓声が自分の画面より 10 秒早く聞こえることがあります。HLS でこの「ネタバレ問題」が起きやすいのはなぜでしょう？ HLS は数秒のセグメントが完成してから配るので、「セグメント長 × 数個」分の遅延が積み上がります。MoQ はセグメントを待たず、フレームができた端から流します。

📝 まとめ

• 既存技術には「低遅延 ↔ スケール」のジレンマと、区間ごとのプロトコル分断がある
• MOQT は QUIC の上で動く汎用の pub/sub プロトコルで、リレー（CDN）を前提に設計されている
• メディアの詰め方は LOC / MSF / CMSF など別仕様のレイヤーが担当する

参考

• draft-ietf-moq-transport-22 §1 Introduction
• moq.dev

✅ 理解度クイズ