Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 明日ウィーンでIETF 126が始まる
MOQTとは何か — pub/subをトランスポート層に下ろした設計
仕様の現在地 — 2か月ごとにワイヤーが変わる
現実チェック1 — 最大のリレーはdraft-07で止まっている
現実チェック2 — 最初の提案者のフォーク、moq-lite
それでは今WebRTCを手放していいか — いいえ
判断 — いつ覗き込み、いつ待つか
おわりに
参考資料

はじめに — 明日ウィーンでIETF 126が始まる

明日(2026年7月18日)からオーストリア・ウィーンでIETF 126が開かれます。アジェンダを見ると、Media over QUIC(MoQ)ワーキンググループは7月20日(月)、23日(木)、24日(金) — 1週間に3回もセッションを確保しています。そして11日前の7月6日、中核文書であるdraft-ietf-moq-transportが19回目のリビジョン(-19)に更新されました。149ページの文書です。

片や標準化がこれだけ駆け足で進んでいる一方、配備された現実は妙な場所にあります。今のインターネットで誰でもつなげる最大のMoQリレー — Cloudflareが2025年8月に起動したもの — は、いまだにdraft-07の部分集合に固定されています。そして、このプロトコルの-00リビジョンの第一著者だったLuke Curleyは、現在moq-liteという別のフォークを作っています。

仕様がどこまで進んでいるか、配備がどこにあるか、そのギャップが何を意味するか — この3つをすべて一次情報(datatrackerのメタデータ、ドラフト原文、ベンダー文書)で確認して整理しました。

MOQTとは何か — pub/subをトランスポート層に下ろした設計

MOQT(Media over QUIC Transport)は、QUICとWebTransportの上で動くpublish/subscribeプロトコルです。-19の要旨の文をそのまま移せば、QUICのストリーム・データグラム・優先度・部分信頼性(partial reliability)を活用し、point-to-pointでも中間リレーを経由しても動作し、これによってスケーラブルで低遅延な配送を狙う、とあります。もう一つ興味深い文があります — 「名前とは裏腹に、MOQTはメディアに依存しない(media agnostic)ものであり、幅広いユースケースに使える」。ところがワーキンググループ憲章(2025年4月改訂)は、ライブストリーミング・ゲーム・メディア会議のためのメディア配信ソリューションとして範囲を定めているので、文書自身が憲章よりも野心が大きくなっているわけです。

データモデルは階層型です。トラック(Track)の中にグループ(Group)があり、グループの中にオブジェクト(Object)があり、グループの中でオブジェクトをサブグループ(Subgroup)としてまとめられます。仕様が挙げる例が設計意図をよく示しています — 時間的スケーラビリティ(temporal scalability)のあるコーデックで高/低解像度の映像を送る場合、解像度ごとにトラックを分け(受信者が帯域に応じて選択できるようにし)、独立復号可能なピクチャー列をグループに(ランダムアクセスポイント=参加点)、時間レイヤーをサブグループに(帯域が足りなければ優先度メカニズムが下位レイヤーを優先する)、1フレームを1オブジェクトとして送ります。

動作は3つに分かれます。SUBSCRIBEはこれから届くオブジェクトを受け取るもの(ライブ視聴)、FETCHは過去の区間を要求するもの(巻き戻し・VOD的アクセス)、PUBLISHは購読要求を待たずにパブリッシャーが押し込むプッシュモデルです。リレーはこの構造のおかげで、メディアの中身を理解しなくても — コーデックも、コンテナも、(設計上は)エンドツーエンドの暗号鍵さえも知らなくても — ファンアウトとキャッシュができます。エンドツーエンドの鍵確立メカニズム自体は、憲章が明示的に範囲外としています。

ここまでが設計の約束です。WebRTCの低遅延な対話性とHLS/DASHのCDNスケーラビリティを一つのアーキテクチャに — この文言はCloudflareの発表文の表現でもあります。問題はここからです。

仕様の現在地 — 2か月ごとにワイヤーが変わる

datatrackerの提出記録から最近のリビジョンのケイデンスを見るとこうです。

リビジョン	提出日
draft-16	2026-01-13
draft-17	2026-03-02
draft-18	2026-05-12
draft-19	2026-07-06

だいたい2か月に一度、IETFの会期に合わせて回っています。重要なのは頻度ではなく中身です。文書に含まれる変更履歴(Appendix A)を読むと、この段階でもワイヤーフォーマットとメッセージ集合が動き続けていることが分かります。

-18から-19にかけて(2026年5月→7月)、購読にRange Filterが追加され、1つのトラックに対する同時購読が複数許可され、PUBLISH_BLOCKEDメッセージがPUBLISH_SKIPPEDに改名され、リレーがオブジェクトを並べ替え・破棄できた例外条項が削除されました。1つ前の-17から-18はもっと大きな変更でした — moqt:// URIスキームの統合、SUBSCRIBE_NAMESPACEをSUBSCRIBE_NAMESPACEとSUBSCRIBE_TRACKSに分離、PUBLISH_OKメッセージ型の削除(REQUEST_OKの別名として吸収)、FETCH応答へのデルタエンコーディング導入、7バイトvarintの許可まで。名前が変わり、メッセージが消え、エンコーディングが変わる。制御メッセージは-19時点でSETUPからPUBLISH_SKIPPEDまで18種類です。

バージョンネゴシエーションのポリシーも知っておく必要があります。最終的なRFCのALPNはmoqtになりますが、ドラフト実装はmoqt-19のようにドラフト番号を付けたALPNを使います。そして-15より前のドラフトは全部moq-00という1つのALPNを使い、SETUPメッセージの中でバージョンを交渉していました。要するに、ドラフト世代が違えばALPN文字列の時点で分岐するので、サーバーがわざわざ複数世代を同時実装しない限り、ドラフト間の相互運用は構造的に存在しません。

スケジュール目標は明示されています。WGマイルストーンは、トランスポートプロトコル(MOQT)とCommon Access Tokenベースの認証のIESG提出を2026年12月31日に、その上に乗るWARPストリーミングフォーマット・LOCコンテナフォーマット・Privacy Pass認証を2027年3月31日に定めています。目標日はあくまで目標日ですが、少なくともワーキンググループ自身は今年中に基盤プロトコルをロックする計画だということです。

現実チェック1 — 最大のリレーはdraft-07で止まっている

Cloudflareは2025年8月22日にMoQリレーネットワークの立ち上げを発表しました。自社発表によれば、330以上の都市のすべてのCloudflareサーバーがリレーとして動作する最初のMoQリレーネットワークであり、relay.cloudflare.mediaoverquic.comエンドポイントに誰でもつなげる技術プレビュー(現在は無料)です。「1秒未満」といった遅延の数値も発表文にありますが、これはベンダー自己記述であり、測定条件が明示されたベンチマークは公開されていません。

発表文で本当に重要な文は別にあります。Cloudflareのリレー実装はdraft-ietf-moq-transport-07の部分集合であり、彼らの表現で言えばこのバージョンが「複数のオープンソースプロジェクト間の事実上(de facto)の相互運用ターゲット」になったということです。発表時点の最新ドラフトはすでにかなり先を行っていたにもかかわらず-07で止まった理由を、Cloudflareは率直に記しています — 動く標的を追い続ける代わりに、そこで止まってリレーネットワークの配備自体に力を注ぐことにした、と。

この状態は今も変わりません。CloudflareのMoQドキュメント(2026年4月21日更新)は今もdraft-07部分集合のサポートを明記しています。さらに興味深いのは同じ文書のKnown Issues項目です。Cloudflare実装のサブグループヘッダーには、draft-07にはないSubscribe IDフィールドが1つ余分に入っています。

draft-ietf-moq-transport-07の定義:         Cloudflare実装が実際にやり取りするもの:

STREAM_HEADER_SUBGROUP Message {           STREAM_HEADER_SUBGROUP Message {
  Track Alias (i),                           Subscribe ID (i),      <- 余分なフィールド
  Group ID (i),                              Track Alias (i),
  Subgroup ID (i),                           Group ID (i),
  Publisher Priority (8),                    Subgroup ID (i),
}                                            Publisher Priority (8),
                                           }

これは以前のドラフトから残った不具合であり、今後のリリースで修正すると文書に記されています。つまり現在の「事実上の標準」はdraft-07そのものではなく、draft-07に特定実装の差分が乗った何かです。これが2026年7月、標準化4年目のプロトコルの相互運用の現実です — 発表文に列挙された相互運用テストの相手(Luke Curleyのmoq.dev、Lorenzo Miniero のimquic、Metaのmoxygen、moq-rs、moq-js、Norsk、Vindral)も、このdraft-07近辺をターゲットに合わせた結果です。

仕様の節で見たALPNポリシーと突き合わせると結論は明確です。今日の最新仕様(-19)通りにクライアントを実装しても、唯一の規模のあるパブリックリレーとは接続交渉すらできません。

現実チェック2 — 最初の提案者のフォーク、moq-lite

datatrackerでdraft-ietf-moq-transport-00(2023年7月)を開くと、第一著者はL. Curley(当時Twitch)です。-19の著者リストはCiscoのNandakumar、GoogleのVasilievとSwett、Metaのfrindell — Curleyの名前はありません。彼は現在draft-lcurley-moq-liteという個人ドラフトを維持しており、最新のリビジョン(-05)は2026年6月30日付、40ページです。MOQTの149ページと並べると、それ自体がメッセージになります。

フォークの論拠は、moq-liteドラフトのRationale節に異例なほど率直に書かれています。要点を移すと — MoQの動機と潜在力は全面的に信じているが、この種の実験的プロトコルを委員会で設計するのは難しく、MoqTransportは複雑になりすぎた。メッセージが多すぎ、選択的モードが多すぎ、生煮え(half-baked)の機能が多すぎる。標準化プロセスがむしろ実戦での実験を妨げており、仮説上のアプリケーションを議論する代わりに実際のアプリケーションを作るべきだ、と。だからmoq-liteは「WebRTCを置き換えようとするリアルタイムアプリケーションに必要な最小限」だけを残して全部削ぎ落とした、というわけです。グループ順序(group order)のように彼自身は良いアイデアだと認めるものも「必要になったらそのとき」と言って外し、ドラフト自身が「この文書は現状であって最終形ではない」と明言しています。

実際にどれだけ構造が異なるか見ると:

データモデルはBroadcast → Track → Group → Frameで、MOQTのサブグループ階層はなく、オブジェクト(Object)はメディア用語に合わせてフレーム(Frame)に改名されています。
双方向ストリーム型はAnnounce、Subscribe、Fetch、Track、Probe、Goawayの6つで全部です。MOQTの制御メッセージ18種と対照的です。
一方でMOQTにないものもあります — -05はQUIC、WebTransportに加えてQmux over TCP/TLSとQmux over WebSocketまで、4種類のトランスポートバインディングを定義しています。QUICが塞がれるネットワークとWebTransportがないブラウザ(Safari)のためのTCPフォールバックが仕様の中にあるわけです。データグラムはQUIC/WebTransportバインディングでのみサポートされます。

Cloudflareの発表の翌日にCurleyが書いたThe First MoQ CDNは、この見方をさらに露骨に示しています。彼の集計(2025年8月時点)ではmoq-transportリポジトリにイシュー650件+、PR 500件+が積み上がっており、基盤となるネットワーキング層がRFCになるまで「少なくともあと3年」はかかると見ています。彼が挙げる比較対象がQUICです — Googleは2012年に配備を開始し、2015年に標準化を開始し、RFCは2021年に出た。そしてQUICには仕様を磨くための本番データが山ほどあったが、MoQにはまだデモレベルの利用経験しかない、というのです。ちなみにCloudflareのリレーコード自体が彼のRust実装をフォークしたものだと彼は明かしています(彼の主張であり、Cloudflareの発表文はコードの系譜を明記していません)。発表時点で認証がなく、ANNOUNCE未対応のため配信の開始・終了のディスカバリができず、Safariが使えないという限界も彼の記事に整理されています。

まとめると、今のMoQエコシステムには2つの分岐があります。IETFトラック(MOQT、2026年末のIESG提出を目標)とmoq-liteトラック(個人ドラフト+実動実装+彼が運営するデモ群)です。両者は概念と用語を共有していますが、ワイヤーでは互換性がありません。

それでは今WebRTCを手放していいか — いいえ

MoQ陣営の目標自体がWebRTCの置き換えであるのは事実です(moq-liteドラフトが明示的にそう書いています)。しかし2026年7月時点で乗り換えられない理由が3つあります。

第一に、ブラウザのカバレッジ。MOQTはブラウザ側にWebTransportを要求しますが、SafariのWebTransportはまだ完全ではありません。Cloudflareの文書が整理するところでは、Safari 18.4(2025年3月31日)から開発者フラグの裏に早期の(まだ完全には動作しない)実装が入っただけです。同じ文書の結論が象徴的です — Safariが完全なWebTransportを備えるまで、一部のMoQユースケースはWebRTCやWebSocketにフォールバックしなければならない。置き換えるはずの相手にフォールバックしなければならない間は、置き換えではなく併存です。

第二に、運用の成熟度。パブリックリレーは認証なしの技術プレビューであり(推測不能なパス名がすなわちアクセス制御です)、標準は上で見た通りまだメッセージ名が変わる段階です。ビデオ会議やライブコマースのようにSLAがかかったトラフィックを載せる段階ではありません。

第三に、静かについてくるコスト。QUICでメディアを受け取るということは、受信経路のCPUコスト構造がTCP+TLSとは変わるということでもあります。このテーマは昨日書いたQUIC受信側のCPUコストとカーネルQUIC編で測定データとともに扱ったので、MoQをサーバー側で検討するなら合わせて読むことをお勧めします。

一方、今日のリアルタイムスタックがどこにあるかはすでに整理した記事があります — WebRTCメディアインフラとWHIP/WHEPエコシステムはWebRTC メディアインフラ 2026編で、WebTransportを含むリアルタイムWeb転送の選択肢は2026 年の realtime web編で扱いました。音声AIのように双方向の対話遅延が命であるスタックが今日WebRTCの上に立っている理由もAI音声 2026編の文脈とつながっています。MoQがこれらを置き換えるには、標準の完成、ブラウザカバレッジ、認証・課金といった運用機能のすべてが揃う必要があり、そのどれもまだ終わっていません。

判断 — いつ覗き込み、いつ待つか

今すぐ実験する価値がある場合:

ライブストリーミングパイプライン(インジェスト→ファンアウト)を自分で所有していて、WebRTC SFUのスケーリングコストやLL-HLSの遅延の下限に実際にぶつかっている。無料プレビューリレーとオープンソース実装で、概念実証までは今日でも可能です。
プロトコル自体に利害関係がある — 今がフィードバックが仕様に反映されうる最後の区間です。WGマイルストーン通りなら今年末にIESGへ移ります。

待つのが正しい場合:

プロダクションのSLAがかかったメディアトラフィック。認証なしのプレビューリレー、2か月ごとに変わるワイヤー、ドラフト間の非互換 — このうちの1つだけでも十分な理由です。
Safariを含む全ブラウザのカバレッジが必須のサービス。WebTransportフォールバック計画なしには始められません。
「MoQはWebRTCより遅延が良い/悪い」を根拠に意思決定しなければならない場合 — 条件が明示された公開比較測定はまだありません。ベンダー発表文の遅延の記述はマーケティング文として読むべきです。

おわりに

まとめるとこうです。MOQT仕様は-19まで来て、ワーキンググループは今年中のIESG提出を目標にしていますが、ワイヤーフォーマットはいまだにリビジョンごとに動いています。一方、配備の重心はdraft-07あたりにあります — 最大のパブリックリレーがそこで止まって事実上の相互運用ターゲットになり、それすら文書化されたワイヤーの差分を抱えています。そしてプロトコルの最初の提案者は「実験が標準より先であるべきだ」として、6分の1の分量のフォークを回しています。

この構図は失敗の兆候というより、プロトコル標準化の正常な陣痛に近いものです — QUICも配備とRFCの間に9年がありました。ただ、エンジニアとしての実用的な結論は明確です。今のMoQは観察し実験する対象であって、乗り換える対象ではありません。次の確認時点は2つ決めておけばよいでしょう — 来週のIETF 126でのMoQセッションの結果、そして2026年末のIESG提出が実際に行われるかどうかです。