このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
20年以上にわたり、インターネット上のリアルタイムコミュニケーションを、寄せ集めの専用ツールを使って構築してきました。RTMPが取り込みを行いました。HLSとDASHによってスケールが実現しました。WebRTCによってインタラクションが可能になりました。それぞれが時代の特定の問題を解決し、今日私たちが信頼しているグローバルストリーミングエコシステムを支えています。
しかし、2025年にこれらを併用することは、異なる時代のツールを利用して最新のアプリケーションを構築するようなものです。その継ぎ目は、1秒以内のライブオークションから大規模なインタラクティブイベントまで、次世代アプリケーションに必要な複雑さ、遅延、柔軟性に現れ始めています。遅延、スケール、運用の複雑さの間で妥協を強いられることがよくあります。
Cloudflareは本日、330以上の都市にあるデータセンターのすべてのCloudflareサーバーで稼働する、初のMedia over QUIC（MoQ）リレーネットワークを立ち上げました。 MoQは、業界全体のエンジニアによってIETFで開発されているオープンプロトコルであり、Cloudflare独自のテクノロジーではありません。MoQは、WebRTCの低遅延の対話性、HLS/DASHのスケーラビリティ、単一アーキテクチャのシンプルさを組み合わせ、すべて最新のトランスポートレイヤー上に構築されています。当社は、Meta、Google、Ciscoなどと連携して、シームレスに連携して動作する実装を構築し、インターネット上の次世代リアルタイムアプリケーションの共有基盤を構築します。
MoQの将来性を理解するには、まずこれまでの経緯を認識する必要があります。これは、1つの問題を解決するために必然的に別の問題が生まれた一連のアーキテクチャの妥協によって定義されるものです。
RTMPの時代：遅延の克服、規模の妥協
2000年代初頭、RTMP（Real-Time Messaging Protocol）が革新的技術として登場しました。これは、Flashクライアントとサーバーの間に永続的なステートフルなTCP接続を作成することにより、Webでの初期の動画再生のフラストレーションで「ダウンロードして待つ」体験を解決しました。これにより、低遅延（2～5秒）ストリーミングが可能になり、Justin.tv（後にTwitch）などのライブプラットフォームの最初の波が生まれました。
しかし、その強みは弱みでした。そのステートフルな接続は、すべてのビューアーについて維持しなければならず、アーキテクチャの面でスケールに敵対的でした。高価な専用メディアサーバーが必要で、Webの他の部分を支え始めたHTTPベースのコモディティ配信ネットワーク（CDN）は使えませんでした。また、TCPに依存しているため、1つのパケットが失われることでストリーム全体がフリーズする可能性があります。これは、ヘッドオブラインブロッキングと呼ばれる現象で、遅延が急増する事態を引き起こす可能性がありました。業界はカメラからサーバーまでの「ファーストマイル」（取り込み）のためにRTMPを保持しましたが、サーバーから画面（配信）までの「ラストマイル」には新しいソリューションが必要でした。
HLS & DASH時代：拡張性のあるソリューション、遅延について妥協する
次の時代のきっかけとなったのは、iPhoneによるFlashの拒否でした。これを受けて、AppleはHLS（HTTPライブストリーミング）を作成しました。HLSとそのオープンスタンダードであるMPEG-DASHは、ステートフルな接続を放棄し、動画を標準HTTPで配信される小さな静的ファイルのシーケンスとして扱いました。
これにより、スケーラビリティを遥かに高めることができました。基礎となるトランスポートとして、相互運用可能なHTTPのオープンスタンダードに移行することで、動画はあらゆるWebサーバーで配信され、グローバルCDNによってキャッシュされることができるようになり、何百万人もの視聴者に確実に、そして比較的安価に配信できるようになりました。妥協策は、遅延と、大幅なトレードオフ。スムーズに再生するために、プレーヤーは開始する前に少なくとも3つの動画セグメントをバッファする必要がありました。セグメント継続時間は6～10秒ですが、これによりアーキテクチャに直接15～30秒の遅延が生じます。
低遅延HLS（LL-HLS）のような拡張機能が最近登場し、3秒台の遅延を実現しているものの、これらは依然として、プロトコルの基本的な設計と戦う複雑なパッチです。これらの拡張によって、プレイリストのリクエストを開いたままにするなど、賢明な回避策を使用してステートフルなリアルタイム通信のレイヤーが導入されます。これが最終的に、HTTPのスケーラビリティと構成可能性の中心であるステートレスなリクエスト/レスポンスモデルに負担をかけます。
WebRTCの時代：会話型遅延を克服し、アーキテクチャを妥協
同時に、WebRTC（Web Real-Time Communication）が登場し、異なる問題を解決するために登場しました。プラグイン不要の双方向の会話動画で、ブラウザ内での遅延が500ミリ秒未満です。直接的なピアツーピア（P2P）メディアパスを作成し、中央サーバーを方程式から削除することで機能しました。
しかし、このピアツーピアモデルは、基本的にブロードキャストの規模と相反するものです。メッシュネットワークでは、新しい参加者ごとに接続数が二次的に増加します（「N二乗の問題」）。一握りのユーザーにとっては、モデル自身の複雑さの重みに機関が崩壊します。この問題を回避するために、業界は選択的転送ユニット（SFU）やマルチポイント制御ユニット（MCU）などのサーバーベースのトポロジーを開発しました。これらは効果的ですが、本質的にプライベートでステートフルなリアルタイムのCDNを構築する必要があります。これは、インフラストラクチャプロバイダー間で標準化されていない、複雑で費用のかかる作業です。
その結果、特化した相互運用性のないサイロの断片的な状況が残り、開発者は複数のプロトコルをつなぎ合わせ、レイテンシー、スケール、複雑さの間の痛みを伴う3方向の緊張を受け入れざるを得ませんでした。
そこで登場したのがMedia over QUIC（MoQ）です。これは、単なる別のプロトコルではありません。この歴史的なトリレンマを解決するために、一から構築された新しいデザイン哲学です。IETFのオープンなコミュニティ主導の取り組みから生まれたMoQは、独自の製品ではなく、インターネットの基盤となる技術となることを目指しています。
同社は以下を提供することにより、異なるストリーミングの世界を統合することを約束しています。
配信規模で1秒未満の遅延：WebRTCの遅延と、HLS/DASHのスケール、およびRTMPのシンプルさを組み合わせます。
アーキテクチャのシンプルさ：取り込み、配信、インタラクティブなユースケースに単一の柔軟なプロトコルを作成し、異なるテクノロジー間でトランスコーディングを行う必要性を排除します。
トランスポートの効率：TCPヘッドオブラインブロッキング などのボトルネックを排除する、UDPベースのプロトコル、QUICをベースに構築する。
当初の焦点はQUICではなく「メディア」でしたが、コアコンセプト（時間経過による順序付け、独立したデータの名前付きトラック）は非常に柔軟性が高いため、現在ではワーキンググループはプロトコルを単に「MoQ」と呼んでいます。この名前は、抽象化の力を反映しています。これは、効率的かつ大規模に配信する必要があるリアルタイムデータのための汎用的なトランスポートです。
MoQは現在、オーディオ・ビデオ（高帯域幅データ）からスポーツスコアアップデート（低帯域幅データ）まで、データファンアウトまたはパブ/サブシステムと言えるほど汎用的になっています。
MoQの洗練度は、適切なレイヤーで適切な問題を解決することから生まれるのです。基礎から構築して、1秒未満の遅延を大規模に実現する方法を見てみましょう。
MoQの基盤としてのQUICの選択は任意のものではありません。これは、何十年もストリーミングQUICを悩ませてきた問題に対処するものです。
MoQは、QUIC（HTTP/3も動作するトランスポートプロトコル）上に構築することで、いくつかの主要なストリーミング問題を解決します。
ヘッドオブラインブロッキングなし：1つのパケットが失われることで、その背後にあるすべてのパケットがブロックされるTCPとは異なり、QUICストリームは独立しています。1つのストリーム（音声トラックなど）でパケットが失われた場合も、他のストリーム（メイン動画トラックなど）がブロックされることはありません。これだけで、RTMPを悩ませていたスタッキングを解消します。
接続移行：デバイスがWi-Fiからセルラーミドルストリームに切り替えられた場合、接続は中断なく移行されます。再バッファリングも再接続もありません。
高速接続確立：QUICの0-RTT再開は、視聴者が戻ってきたときに瞬時に再生を開始できるのです。
ベイクドインの必須暗号化：すべてのQUIC接続は、デフォルトでTLS 1.3によって暗号化されています。
QUICがトランスポートの問題を解決することで、MoQは主要なイノベーションを導入しています。それは、出版/購読システムにおいて、メディアを購読可能なトラックとして扱うことです。しかし、従来のpub/subとは異なり、これはCDN規模のリアルタイムメディアに特化して設計されています。
複雑なセッション管理（WebRTC）やファイルベースのチャンク（HLS）の代わりに、MoQでは、パブリッシャーはサブスクライバーがリクエストできるメディアの名前付きトラックを発表できます。リレーネットワークは、メディア自体を理解する必要なく、配信を処理します。
メディアがネットワーク上をどのように流れているかを見る前に、MoQがネットワークをどのように構造化しているかを理解しましょう。MoQはデータを階層的に整理します。
トラック：「video-1080p」や「audio-english」など、メディアの名前付きストリーム。サブスクライバーは、名前で特定のトラックをリクエストします。
グループ：独立してデコーディング可能なトラックのチャンク。動画の場合、通常、キーフレームで始まるGOP（グループの写真）を意味します。新規サブスクライバーはどのグループ境界でも参加できます。
オブジェクト ：ネットワーク上で送信された実際のパケット。各オブジェクトはトラックに属し、グループ内での位置を持ちます。
この単純な階層化により、次の2つの機能が実現されます。
サブスクライバーは、次のキーフレームを待たずに、グループ境界で再生を開始できます。
Relayは、メディアフォーマットの解析や理解がなくても、オブジェクトを転送できます。
ネットワークアーキテクチャ：出版業者から購読者まで
MoQのネットワークコンポーネントもシンプルです。
Relayは、上流からトラックを受信するサブスクライバーとして機能し（オリジナルのパブリッシャーのように）、同時にパブリッシャーとして機能して、そのトラックを下流に転送します。このモデルは、MoQのスケーラビリティの鍵となります。1つのアップストリームサブスクリプションが、何千人ものダウンストリームビューアーに配信される可能性があります。
MoQのアーキテクチャは3つの異なるレイヤーとして理解でき、それぞれに明確な役割があります。
トランスポート財団（QUICまたはWebTransport）：これは、すべてが構築される最新の基盤です。MoQTは、ネイティブアプリケーションに理想的な生のQUICまたは、Webブラウザでの使用に必要なWebTransport上で直接実行することができます。重要なのは、WebTransportプロトコルとそれに対応するW3CブラウザAPIにより、QUICの多重化された信頼性のあるストリームと信頼性の低いデータグラムをブラウザアプリケーションに直接アクセスできるようにすることです。これはゲームチェンジャーです。SRTのようなプロトコルは効率的かもしれませんが、ネイティブブラウザサポートの欠如により、取り込み専用の役割を与えられます。WebTransportはWeb上でMoQに第一級の市民権を与え、クライアントへの直接の取り込みや大規模な配信の両方に適しています。
MoQTレイヤー：QUIC（またはWebTransport）の上に位置するMoQTレイヤーは、出版・購読システムの信号と構造を提供します。これは、IETFワーキンググループの最も重要な焦点です。ANNOUNCEやSUBSCRIBEなどのコア制御メッセージと、先ほど説明した基本的なデータモデルを定義します。MoQT自体は意図的に分離されています。移動しているデータがH.264動画、Opus音声、ゲームステート更新のいずれであるかを知ることはできませんし、気にすることもありません。
ストリーミングフォーマットレイヤー：これは、メディア固有のロジックが存在する場所です。ストリーミングフォーマットは、マニフェスト、コーデックメタデータ、パッケージングルールなどを定義します。
WARPは、IETFでMoQTとともに開発されているそのような形式の1つですが、それだけではありません。DASH-IFのような別の標準化団体は、MoQTでCMAFベースのストリーミングフォーマットを定義できます。会社がオリジナルのパブリッシャーとエンドサブスクライバーの両方を制御する場合、トランスポートプロトコルに制約されることなく、独自のストリーミングフォーマットを開発して、新しいコーデックや配信メカニズムを試すことができます。
このようなレイヤーの分離によって、さまざまな企業がストリーミングフォーマットレイヤーでのイノベーションを続けながら、相互運用可能な実装を構築できるのです。
アーキテクチャとデータモデルについて理解したところで、これらの要素がどのように組み合わされてストリームを提供するのかを説明します。プロトコルは柔軟ですが、一般的な配信フローは、ANNOUNCEとSUBSCRIBEのメッセージに依存して、リレーネットワークを通じて、パブリッシャーからサブスクライバーへのデータパスを確立します。
このフローで何が起こるかを段階的に説明しましょう。
接続の開始：プロセスは、クライアントとして機能するエンドポイントがリレーネットワークに接続されたときに始まります。オリジナル出版業者は、最も近いリレー（Relay Aと呼ぶことにします）と接続を開始します。これとは別に、エンドサブスクライバーが自分のローカルリレー（リレーB）との接続を開始します。これらのエンドポイントは、それぞれのリレーとセットアップハンドシェイクを実行し、MoQセッションを確立し、サポートされるパラメーターを宣言します。
ネームスペースのアナウンス：コンテンツを発見可能にするために、発行者はRelay AにANNOUNCEメッセージを送信します。このメッセージは、発行者が所定のトラックネームスペースの権威あるソースであることを宣言します。Relay Aはこれを受信し、共有コントロールプレーン（概念データベース）に登録して、ネットワーク内のこのネームスペースのソースになっているようにします。
トラックの購読：エンドサブスクライバーがメディアの受信を希望する場合、リレーであるRelay Bに向けて、SUBSCRIBEメッセージを送信します。このメッセージは、特定のトラックネームスペース内の特定のトラック名に対するリクエストです。
リレーの接続：Relay BがSUBSCRIBEリクエストを受信し、コントロールプレーンに問い合わせます。要求されたネームスペースを検索し、Relay Aがソースであることを発見します。Relay Bは、Relay Aとのセッションを開始し（まだない場合）、SUBSCRIBE リクエストをアップストリームに転送します。
パスの完了とオブジェクトの転送：Relay Bからサブスクリプションリクエストを受け取ったRelay Aは、それをオリジナルパブリッシャーに転送します。フルパスが確立されると、パブリッシャーはリクエストされたトラックのオブジェクトの送信を開始します。オブジェクトは、パブリッシャーからRelay Aへとフローし、Relay Bに転送され、Relay Bによってエンドサブスクライバーに転送されます。別のサブスクライバーがRelay Bに接続して同じトラックをリクエストした場合、Relay Bは新しいアップストリームサブスクリプションを作成することなく、すぐにオブジェクトの送信を開始できます。
最近のMoQ仕様のドラフトでは、公開を使った代替のプッシュベースモデルが導入されています。このフローでは、パブリッシャーはSUBSCRIBEリクエストを待つことなく、トラックのオブジェクトをリレーに送信する許可を求めることができます。パブリッシャーはPUBLISHメッセージを送信し、リレーのPublicish_OKレスポンスは、オブジェクトを受け入れるかどうかを示します。これは、パブリッシャーがストリームをネットワーク内のエントリーポイントにすぐに送り、最初のサブスクライバーが接続した瞬間にメディアを利用可能にするための、取り込みシナリオに特に有用です。
MoQのメリットは、ネットワークが輻輳した時に特に顕著になります。MoQには、ネットワークトラフィックの現実を処理するメカニズムが含まれています。そのようなメカニズムのひとつが、サブグループです。
サブグループは、グループ内の下位区分で、基盤となるQUICストリームに直接マッピングします。同じサブグループ内のすべてのオブジェクトは、通常、同じQUICストリーム経由で送信され、配信順序が保証されます。サブグループ番号は、優先順位付けをエンコードする機会でもあります。グループ内では、番号の低いサブグループは優先度が高いと見なされます。
これにより、特に階層型コーデック（SVC）：
サブグループ0：ベースビデオ層（360p）- 配信が必要
サブグループ1：720pへの強化 - 帯域幅が許可する場合に配信
サブグループ2：1080pへの強化 - 輻輳を下に最初に低下
リレーが輻輳を検出すると、数の多いサブグループからオブジェクトをドロップし、ベース層を維持することができます。ビューアーにはバッファリングではなく、画質が低下します。
MoQ仕様では、「送信準備完了」のすべてのオブジェクトの順序を決定するスケジューリングアルゴリズムを定義しています。Relayに複数のオブジェクトの準備ができると、まずグループ順序(上昇または降順)で優先順位を付け、次にグループ内でサブグループIDによって優先順位を付けます。私たちの実装は、グループ順序の優先順位付けをサポートしており、低遅延の配信に有用です。視聴者が遅れ、そのサブスクリプションが降順を使用している場合、リレーは最新の「ライブ」グループからのオブジェクトの送信を優先し、古いグループからの未送信のオブジェクトがキャンセルされる可能性があります。これにより、視聴者がライブエッジに素早く追いつくことができ、多くのインタラクティブストリーミングのユースケースにとって非常に望ましい機能です。これらの機能を使用して特定のユースケースでQoEを向上させる最適な戦略は、まだ未解決の研究課題となっています。開発者や研究者の皆様には、当社のネットワークを使って実験し、その答えを見つけることができます。
理論はその1つです。実装することはまた別のことです。プロトコルを検証し、実際の課題を理解するために、私たちは最初のグローバルMoQリレーネットワークの1つを構築しました。コンピューティングとロジックをエッジに配置するCloudflareのネットワークは、これに非常に適しています。
当社のアーキテクチャは、MoQの抽象概念をCloudflareスタックにつないでいます。詳細な説明では、ANNOUNCEネームスペースを発行する場合、リレーはこの可用性を「共有コントロールプレーン」に登録する必要があり、SUBSCRIBEのリクエストが正しくルーティングされるようにする必要があることを述べました。この重要な状態管理には、Durable Objectsを使っています。
パブリッシャーが新しいネームスペースを発表すると、そのリレーはDurable Object（強整合性のシングルスレッドストレージソリューション）を使用して、このネームスペースがその特定の場所で利用可能であることを記録します。パリのサブスクライバーがそのネームスペースからトラックを希望する場合、ネットワークはこの分散状態にクエリを実行して最も近いソースを見つけ、それに応じてSUBSCRIBEリクエストをルーティングすることができます。このアーキテクチャは、Cloudflareのリアルタイムサービスのために開発された技術の上に構築されており、グローバル規模での状態管理の課題に対するソリューションを提供します。
オープンにおける新しいプロトコルの構築は、動いている標的に対して実装するということです。MoQをコミュニティの手に渡すために、私たちは意図的なトレードオフを行いました。現在のリレーの実装は、draft-ietf-moq-transport-07で定義された機能のサブセットに基づいています。このバージョンは、いくつかのオープンソースプロジェクト間での相互運用性の事実上の標的となり、そこで一時停止することで、リレーネットワークの他の側面を展開することに力を注ぐことができました。
このプロトコル草案では、「過去」のコンテンツと「未来」のコンテンツへのアクセスを区別しています。SUBSCRIBEは、トラックの未来のオブジェクトを到着時に受信するために使用されます。ライブ配信にチューニングして、その瞬間からすべてを受信するのと同じです。対照的に、FETCHは、リレーがすでにキャッシュに持っている可能性のある過去のコンテンツにアクセスするメカニズムを提供します。たとえば、今再生された曲の録音を要求するようなものです。
どちらも同じ仕様の一部ですが、低遅延のユースケースにとっては、SUBSCRIBEのパフォーマンスの高い実装が最も重要です。そのため、私たちは初期の取り組みに集中しており、FETCHはまだ実装されていません。
そこで、当社のロードマップは柔軟で、コミュニティが直接影響を与えることができるのです。オンデマンドやキャッチアップの機能を構築するためにFETCHは必要ですか？あるいは、SUBSCRIBEの優先順位付け機能のより完全なサポートが、より完全なユースケースにとってより重要でしょうか？初期の開発者から受け取ったフィードバックは、次に何を構築するかを決定するのに役立ちます。
いつものように、開発を継続していく中で、実装の更新や変更を開発者ドキュメントページで発表していきます。
私たちは、コミュニティにおけるオープンと相互運用性を構築することが重要だと考えています。MoQはCloudflareの技術ではなく、基盤となるインターネット技術です。そのため、今回ご紹介する最初のデモクライアントは、オープンソースのコミュニティの例です。
デモへのアクセスはこちらから：https://moq.dev/publish/
これはプレビューリリースですが、他の本番サービスと同様に、CloudflareのフルスケールでMoQリレーを実行しています。つまり、330以上の都市に広がるCloudflareネットワークの一部であるすべてのサーバーがMoQリレーであることを意味します。
MoQが可能にする、ほぼ瞬時の1秒未満のストリーミング遅延で「すごい！」の瞬間をご体験ください。ビデオ通話の速度とグローバル配信の規模を提供するプロトコルをどう使用したいですか？
私たちはIETF WGコミュニティやそれ以上の関係者と協力し、パブリッシャー、プレイヤー、その他のMoQエコシステムの相互運用性について協力してきました。これまでは、以下を使ってテストしてきました：
インターネットのメディアスタックが再構築されています。20年間、私たちは遅延、スケール、複雑さのどれかを選択することを迫られてきました。当社が採用した妥協は、一部の問題を解決しましたが、同時に断片化されたエコシステムを生み出しました。
MoQは、有望な新基盤であり、サイロを統合し、スケーラブルなプロトコル上で次世代のリアルタイムアプリケーションを構築するチャンスです。私たちは、この基盤をオープンに構築することをお約束します。また、始まったばかりです。
MoQは、将来の保証のためにQUIC上に構築された現実的な方法であり、WebRTCよりも理解しやすく、RTMPとは異なりブラウザと互換性があります。
プロトコルは進化し、実装は成熟し、コミュニティは成長しています。次世代のライブストリーミングの構築、リアルタイムコラボレーションの模索、インタラクティブメディアの境界の押し広げのいずれであっても、MoQが必要な基盤を提供できるかどうかを検討してください。
開発者には今すぐMoQを使って構築を始めてほしいと考えています。それを可能にするために、CloudflareのMoQは技術プレビュー版にあります。これは、（あらゆる規模で）テストに無料で利用できるということです。最新情報や破壊的な変更の可能性については、開発者向けホームページをご覧ください。
インディーズゲーム開発者も大企業も、新技術導入の初期に価格について尋ねます。MoQの価格設定については透明性を保ち、明確にします。一般公開時には、セルフサービスのお客様は、Cloudflareに向けて送信されるトラフィックのコストをかけずに、アウトバウンドに5セント/GBのアウトバウンドを支払うことになります。
Enterpriseのお客様は、通常のメディア配信価格に沿った通常の価格設定が期待され、既存のプロトコルと競合することができます。つまり、すでにCloudflareをメディア配信に使用している場合、コストを理由に新しい技術を採用することを慎重に考える必要はありません。当社がサポートします。
Cloudflareと提携してプロトコルを早期に採用したり、開発に貢献したりしたい方は、moq@cloudflare.comまでご連絡ください。インターネットの未来にワクワクするエンジニア達が待機中です。