iR
iReplay.tv

Streaming Cost Optimizer

CDNコストを削減し、超過料金を回避。従量制ストリーミング配信。

無料で試す

MoQとは何か、あなたのストリーミング製品に本当に必要か？

• •
この記事はAIを使用して英語から翻訳されました。 原文を読む

Media over QUIC (MoQ) は、2025年から2026年にかけて最も議論されている新興ストリーミングプロトコルです。ブログ記事は増え続け、カンファレンスでの発表は山積みになり、CDNベンダーはサポートの発表を競い合っています。ライブストリーミングに携わっているなら、おそらくこう聞かれたことがあるでしょう：MoQに切り替えるべきですか？

今日出荷されているほとんどの製品にとって、端的な答えはいいえ, まだです。しかし、MoQが解決しようとしている問題は現実のものであり、本番環境で使えるようになるまでの期間は、もはや年単位ではなく四半期単位で計れるようになっているため、理解しておく価値はあります。

この記事では、MoQとは実際に何なのか、2026年3月時点でどのような状況にあるのか、HLS、WebRTC、SRTと比較して何が変わるのか、そして私たちが実際にデプロイした2つの製品にとって意味があるかどうかを解説します：WeSpeakSports（WebRTCによるライブファンオーディオコメンタリー）とDJing Stream（SRTとHLS LosslessによるブロードキャストグレードのDJオーディオ）。

MoQとは実際に何なのか

MoQはMedia over QUICの略です。2022年に開始されたIETFワーキンググループの取り組みで、QUIC（HTTP/3の背後にあるトランスポート層）の上に構築された新しいメディア配信プロトコルを定義することを目的としています。

コアとなるトランスポート仕様であるdraft-ietf-moq-transportは、2026年3月にバージョン17に達しました。ストリーミングフォーマット仕様（draft-ietf-moq-msf）も進行中で、CMAFパッケージングとヘッダー圧縮に関するコンパニオンドラフトも並行して作業が進んでいます。これらはいずれもまだ最終的なRFCにはなっていません。

MoQの本質は、publish/subscribeプロトコルです。パブリッシャーは名前付きメディアオブジェクト（オーディオフレーム、ビデオフレーム、メタデータ）をリレーに送信し、サブスクライバーは名前付きトラックにサブスクライブすることでそれらを受信します。これは、HLS（セグメントに対するHTTPリクエスト/レスポンス）とWebRTC（SDP/ICEによるピアツーピアセッションネゴシエーション）の両方とは根本的に異なります。

MoQはQUICストリームとデータグラムの上で動作し、ネイティブまたはWebTransport（QUIC用のブラウザAPI）経由で実行されます。これにより、QUICのマルチプレキシング、優先順位付け、部分的信頼性機能にアクセスできます。つまり、プロトコルは設計上、再送信を待ってストリーム全体を停止させるのではなく、遅れたビデオフレームをドロップすることができます。

MoQが置き換えようとしているもの

Ciscoの（MoQワーキンググループ参加者である）Cullen Jenningsが述べているように、ストリーミングの世界には現在2つのサイロがあります。一方では、NetflixやYouTubeのようなサービスがHTTPベースのCDNを通じて大規模にメディアを配信していますが、数秒のレイテンシがあります。もう一方では、ZoomやWebRTCベースのプラットフォームのようなコミュニケーションツールがほぼリアルタイムでメディアを配信していますが、大規模なオーディエンスにコスト効率よくスケールできません。

MoQは、コントリビューション（取り込み）からディストリビューション（視聴者への配信）まで、CDN互換のリレーインフラを間に挟み、リアルタイムとニアリアルタイムの両方のユースケースに対応できる単一のプロトコルで、この2つの世界を橋渡しすることを目指しています。

MoQの現状（2026年3月）

現在の状態を正確に把握しましょう：

仕様は近いが、まだ完成していない。トランスポートドラフトはバージョン17で、急速に反復されています。ストリーミングフォーマットドラフトは2026年1月に公開されました。CMAFパッケージングとヘッダー圧縮に関する活発なコンパニオン作業があります。しかし、批准されたRFCはまだありません。

Safari/WebTransportのギャップは縮まりつつある。ブラウザでのMoQはWebTransportに依存しており、WebTransportにはHTTP/3とQUICが必要です。ChromeとFirefoxはすでにWebTransportをサポートしています。SafariがホールドアウトでしたがAppleはSafari 26.4ベータ（2026年2月）でWebTransportサポートを追加し、WebKitの公式Interop 2026コミットメントとなっています。2026年3月時点で、これはまだ安定版Safariリリースには含まれていませんが、もはや実現するかどうかの問題ではなく、次のOSサイクルでいつ実現するかの問題です。ブラウザ経由でiPhoneやiPadのユーザーをターゲットにしている製品にとって、このギャップはほぼ解消されています。

初期の本番デプロイメントは存在するが限定的。NanocosmosはMonteVIDEO Summer Projectでエンドツーエンドの MoQ配信（OBSインジェストからグローバルオーディエンスへ）をデモンストレーションしました。CloudflareはMoQベータを開始しました。Red5は2026年末までにMoQサポートを発表しました。しかし、これらは早期採用者によるデプロイメントであり、メインストリームのインフラではありません。

コミュニティは成熟度について正直である。Twitch（現Discord）で最初期のMoQ実装の1つを構築し、moq-lite簡略化ドラフトの著者であるLuke Curleyでさえ、完全なMoQトランスポート仕様は「複雑になりすぎた」と明言し、「メッセージが多すぎ、オプションモードが多すぎ、中途半端な機能が多すぎる」と述べています。彼のmoq-liteドラフトは、この複雑さに対する回答です。

業界のベテランたちは慎重である。BlogGeek.meのTsahi Levent-Leviは、2026年には開発者はMoQよりもWebRTCについてより多く不満を言うようになると予測しました。これはMoQが優れているからではなく、MoQのユーザーはまだ粗い部分を予期する早期採用者だからです。WebRTCは現実世界の期待の重みを背負って、あらゆる場所で本番稼働しているのです。

MoQがHLSと比較して変えるもの

HLS（HTTP Live Streaming）は、メディアをセグメントに分割し、HTTPサーバーに書き込み、プレイヤーがプレイリストを介して新しいセグメントをポーリングすることで動作します。成熟しており、CDNフレンドリーで、広く展開されており、RFC 8216とAppleのHLS Authoring Specificationで十分に文書化されています。Low-Latency HLS（LL-HLS）はレイテンシをおよそ2〜4秒まで押し下げます。

MoQは配信モデルをいくつかの方法で変えます：

ポーリングからプッシュへ。HLSプレイヤーはセグメントをリクエストします。MoQサブスクライバーはオブジェクトが公開されると同時に受信します。これによりポーリングレイテンシが排除されます。

セグメントからオブジェクトへ。HLSは数秒のセグメント（またはLL-HLSではパーシャルセグメント）で動作します。MoQはフレームレベルで動作できます。単一のビデオフレームまたはオーディオフレームが、個別にアドレス可能で個別に配信可能なオブジェクトになります。

TCPからQUICへ。HLSはHTTP/TCP上で動作します。TCPパケットが失われると、その後ろのすべてが停止します（ヘッドオブラインブロッキング）。MoQはQUIC上で動作し、ストリームは独立しています。あるストリームでのパケットロスが他のストリームをブロックすることはありません。

明示的な優先順位付け。MoQのトランスポートドラフトは、プロトコルレベルで優先度と配信順序を定義しています。輻輳時には、リレーはすべてを均等に遅延させるのではなく、優先度の低いオブジェクト（例：B-frames）をドロップできます。

統一されたインジェストとディストリビューション。現在、ほとんどのライブワークフローでは、コントリビューションに1つのプロトコル（RTMP、SRT、WHIP）を使用し、ディストリビューションに別のプロトコル（HLS、DASH）を使用しています。MoQは潜在的に両方のパスを単一のプロトコルで処理でき、オリジンサーバーでの再パッケージングステップを排除できます。

HLSがまだ勝つとき

このことは、HLSが時代遅れであることを意味しません。HLSは以下の場合に依然として強い選択肢です：

  • 数秒のレイテンシが完全に許容できる場合
  • 幅広いデバイス互換性が不可欠な場合（すべてのスマートフォン、テレビ、セットトップボックスがHLSを再生できます）
  • 既存のCDNとツールへの投資がうまく機能している場合
  • 運用の簡素さと実戦で証明された信頼性が、レイテンシをさらに下げることよりも重要な場合

標準的なOTTのライブおよびVOD配信 (ストリーミングトラフィックの圧倒的大部分を占めます) において、HLSは壊れておらず、MoQが修正すべき問題は存在しません。

MoQがWebRTCと比較して変えるもの

WebRTCはリアルタイムのピアツーピア通信のために設計されました：ビデオ通話、画面共有、1対1または小グループの会話です。業界はWebRTCをその本来のスコープをはるかに超えて拡張し、SFU（Selective Forwarding Unit）アーキテクチャを使用してWebRTCをより大きなオーディエンスにスケールさせてきました。

MoQはいくつかの重要な点でWebRTCと異なります：

アーキテクチャ。WebRTCは基本的にセッション指向のピアツーピアプロトコルであり、SFUを介する場合でもそうです。MoQは、最初からリレーとCDNスタイルの配信を中心に設計されたクライアント・サーバー型のpublish/subscribeプロトコルです。

スケーラビリティモデル。WebRTCのスケーリングには、専用に構築された高価なSFUインフラが必要です。MoQリレーは既存のCDNインフラとの統合を目的として設計されています。HTTP/3サーバーを拡張してMoQトラフィックを処理できるため、AkamaiやYouTubeなどのCDNベンダーが積極的に関与しています。

複雑さ。WebRTCはかなりの複雑さを伴います：SDPオファー/アンサーネゴシエーション、ICEキャンディデート収集、NATトラバーサルのためのSTUN/TURNサーバー、暗号化のためのSRTP、データチャネルのためのSCTP。MoQの接続セットアップはよりシンプルです. QUICハンドシェイクの後にsubscribe/publishメッセージが続きます。

コーデックの柔軟性。WebRTCのコーデックネゴシエーションはプロトコルと密結合しています。MoQはトランスポートレベルではコーデックに依存しません. メディアフォーマットはアプリケーション層（MSF、LOC、またはカスタムコンテナ）で処理されます。

ブラウザ依存性。両方のプロトコルは、Webベースの配信にブラウザAPIに依存しています。WebRTCはユニバーサルなブラウザサポートを持っています。MoQはWebTransportに依存しており、Safariはベータ版（26.4、2026年2月）でようやく追加したばかりで、安定版はまだ出荷されていません。このギャップは縮まりつつありますが、現時点でのMoQにとっては依然として実際的な考慮事項です。

WebRTCがまだ勝つとき

WebRTCは以下の場合に依然として良い選択肢です：

  • 真の双方向リアルタイム通信が必要な場合（ビデオ通話、コンファレンシング）
  • Safari/iOSを含むすべてのプラットフォームでのブラウザ互換性が求められる場合
  • ユースケースがピアツーピアまたは小グループで、CDNスケールの配信が不要な場合
  • 実績のある本番グレードのツールとSDKの成熟度が重要な場合

MoQがSRTと比較して変えるもの

SRT（Secure Reliable Transport）は、予測不可能なネットワーク上でポイントAからポイントBへ高品質なメディアを移動させることに優れています。AES暗号化、ARQ（Automatic Repeat Request）によるパケットロス回復、アダプティブビットレートサポートを提供します。SRTはインジェストワークフロー（カメラからスタジオへ、リモートプロダクションからクラウドエンコーダーへ）に広く採用されていますが、DJing Streamが実証しているように、ポイントツーポイントの配信プロトコルとしても機能します。

MoQとSRTは重なりつつも異なる目的を持っています：

SRTはポイントツーポイント、MoQはpublish/subscribe。SRTは1つの送信者と1つの受信者を接続します。MoQはリレーを通じたワンツーメニーの配信をネイティブにサポートします。

SRTは配信を保証する、MoQは保証しないことを選択できる。SRTのARQメカニズムはすべての失われたパケットを再送信し、ロスレスな配信を保証しますが、パケットロス時にはレイテンシが増加します。MoQは部分的信頼性のために構成できます (遅れたオブジェクトを再送信する代わりにドロップします) これはライブのレイテンシに敏感な配信には適していますが、すべてのサンプルが重要な場合には受け入れられません。

SRTは成熟しデプロイされている、MoQは新興である。SRTは幅広いハードウェアとソフトウェアのサポートがあります（OBS、vMix、FFmpeg、Haivision、すべての主要なエンコーダー）。MoQは初期段階の実装があります。

SRTがまだ勝つとき

SRTは以下の場合に強い選択肢です：

  • ユースケースがポイントツーポイントの場合（ソースからエンコーダー、エンコーダーからオリジン、または会場への直接配信）
  • ロスレス配信が絶対的な最小レイテンシよりも重要な場合
  • ワークフローにSRTを既にサポートするプロフェッショナルなブロードキャスト機器が含まれる場合
  • ビットレベルでのオーディオの忠実度が交渉の余地のない要件である場合

ケーススタディ：WeSpeakSports: WebRTCによるライブファンコメンタリー

WeSpeakSportsは、ライブファンオーディオコメンタリープラットフォームです。ファンはスポーツの試合中にリアルタイムのオーディオコメンタリーを作成または聴取します. サッカー、バスケットボール、ラグビー、F1など。アプリはiPhone、iPad、Mac（Apple Silicon）、Vision Proで利用可能です。

現在のアーキテクチャは、オーディオストリーミングにWebRTCを使用しています。ファンのコメンテーターがデバイスからオーディオを配信し、リスナーがほぼリアルタイムでそれを受信します。オーディオは音楽品質ではなく音声品質です. オーディオマニア的な忠実度よりも、明瞭性と低レイテンシがはるかに重要です。

MoQはWeSpeakSportsにとって意味がありますか？

理論上は、はい. このユースケースには非常に適しています。WeSpeakSportsは、リアルタイムの期待を持つ1対多のライブオーディオブロードキャストです。これはまさにMoQが埋めるように設計されたギャップです：効率的なWebRTCスケーリングには多すぎるリスナーですが、HLSにはレイテンシに敏感すぎます。

MoQのpublish/subscribeモデルは、WeSpeakSportsのアーキテクチャに自然にマッピングされます：コメンテーターがオーディオトラックをパブリッシュし、リスナーがそれにサブスクライブし、CDNリレーが配信を処理します。これはWebRTC SFUインフラよりもシンプルで、スケーリングコストが低くなります。

実際には、まだです. 2つの困難な理由があります：

  1. Safari/iOSはもう少しだが、まだ到達していない。WeSpeakSportsはiOS 18.0を必要とします。アプリの主要なオーディエンスはiPhoneにいます。ブラウザでのMoQはWebTransportに依存しており、AppleはSafari 26.4ベータで追加しましたが、安定版リリースにはまだ含まれていません。ネイティブiOSアプリに関しても、Appleプラットフォーム向けの本番対応MoQ SDKは現在存在しません。iOS上のWebRTCスタック（Appleの組み込みWebKitサポートと成熟したサードパーティSDK経由）は実証済みで機能しています。
  2. 成熟度。WeSpeakSportsは実際のユーザーがいる出荷済み製品です。実績のあるプロトコルからプレ1.0仕様にトランスポート層を置き換えることは時期尚早です。WebRTCは現在のスケールに対応しています。移行の複雑さのコストは、現在のユーザーベースでは正当化されません。

再検討のタイミング

以下の条件が揃ったとき、WeSpeakSportsにとってMoQの評価が価値あるものになります：

  • WebTransportが安定版Safariで出荷される (Safari 26.4ベータを考慮すると今やそれは目前です) そして成熟したネイティブiOS/macOS向けMoQ SDKが登場する
  • ユーザーベースが成長し、WebRTC SFUのコストが実質的な制約となるスケールに達する
  • MoQリレーインフラが少なくとも2つのCDNプロバイダーからSLAコミットメント付きで利用可能になる
  • MoQトランスポート仕様がRFCステータスに到達する

その時点で、MoQは配信アーキテクチャを意味のある形で簡素化し、リスナーあたりのコストを削減できるでしょう。コメンテーターからリレーを経由してリスナーへというモデルは、MoQの教科書的なユースケースです。これはタイミングの問題であり、適合性の問題ではありません。

ケーススタディ：DJing Stream: SRTによるブロードキャストグレードDJオーディオ

DJing Streamは、非常に特定のユースケースのために設計されたmacOSアプリです：DJのセットアップから会場のサウンドシステムへ、インターネットを介してリアルタイムでブロードキャストグレードのオーディオをストリーミングします。アーキテクチャはオーディオ品質を何よりも優先しています。

現在のスタックは、リアルタイム配信にSRTを使用しています. 48kHzの24ビットPCMステレオオーディオ（約2.3 Mbps）をDJのMacから会場のサウンドシステムに配信します。リモートリスナーへのより広い配信には、ロスレスオーディオ付きのHLSで配信することもできます。設計思想全体は、DJのオーディオが物理ケーブル接続と同じ忠実度に値するということです。

MoQはDJing Streamにとって意味がありますか？

いいえ. そしてこれはタイミングの問題ではありません。MoQはDJing Streamの要件と根本的に整合していません。

その理由は以下の通りです：

  1. ロスレス配信は交渉の余地がない。DJing Streamは非圧縮PCMオーディオを送信します。すべてのサンプルが重要です。SRTのARQ再送信はすべてのパケットの到着を保証します, パケットロス時にはオーディオをドロップするのではなくレイテンシを追加します。MoQの部分的信頼性モデルは、ライブビデオにとっては主要な利点の1つですが、ブロードキャストグレードのオーディオにとってはまさに間違ったトレードオフです。ドロップされたオーディオフレームは、クラブのサウンドシステムでは聞こえるグリッチになります。それは許容できません。
  2. ポイントツーポイントが主要なユースケースである。DJing Streamの中心的なシナリオは、1人のDJが1つの会場にストリーミングすることです。これはポイントツーポイントのリンクであり、配信の問題ではありません。MoQのpublish/subscribeリレーモデルは、このトポロジーに対しては利点なく複雑さを追加します。
  3. ブラウザの要件がない。DJing Streamは会場のハードウェアに接続するネイティブmacOSアプリです。ループの中にWebブラウザはありません。WebTransport/Safariのギャップは無関係ですが、ブラウザネイティブ配信というMoQの主要な利点も同様に無関係です。
  4. SRTはすでに正しいツールである。SRTはまさにこのために設計されました：予測不可能なネットワーク上での高品質メディアの信頼性のある暗号化された低レイテンシトランスポート。ブロードキャストプロダクションで実戦テスト済みです。すべてのエンコーダーとメディアサーバーがSRTを話します。DJから会場への配信リンクにおいてSRTをMoQに置き換えることは、意味のあるゲインなしに保証された配信を放棄することを意味します。
  5. HLS Losslessが配信サイドを処理する。より広いオーディエンス（Webリスナー）への配信という二次的なユースケースについては、ロスレスオーディオコーデック付きのHLSは実績があり、すべてのデバイスと互換性があります。リモートリスナーに対するレイテンシ許容度は会場自体よりも高いため、HLSのセグメントベースのモデルは完全に適切です。

再検討のタイミング

正直に言うと？コアのDJから会場へのリンクについては、おそらく決してないでしょう。SRTはDJing Streamが必要とすることをまさに実行しており、MoQの設計目標（輻輳時に許容できる品質低下を伴うスケーラブルな配信）はDJing Streamの設計目標（すべてのオーディオサンプルのゼロロス配信）とは対極にあります。

MoQがDJing Streamに関連するようになる唯一のシナリオは、製品がより低い忠実度の期待を持つ大規模なファン配信に拡大する場合です. 例えば、DJセットの圧縮バージョンを数千人のリスナーに同時にストリーミングするような場合です。その場合でも、HLSまたはLL-HLSの方がよりシンプルで広く互換性があるでしょう。

判断フレームワーク

MoQを徹底的にリサーチした結果. IETFドラフト、Broadpeak、Red5、BlogGeek.me、webrtcHacks、Meetecho、Nanocosmosからの業界コメンタリー. 私が提供できる最もシンプルな判断ルールは以下の通りです：

現在のスタックを維持すべき場合

  • 製品が今日出荷されており、現在のプロトコルが機能している
  • 今日Safari/iOSブラウザサポートが必要（WebTransportはSafariベータにあるがまだ安定版ではない）
  • 数秒のレイテンシが許容できる（→ HLS/LL-HLS）
  • 保証されたロスレス配信が必要（→ SRT）
  • 真の双方向リアルタイム通信が必要（→ WebRTC）

MoQの評価を始めるべき場合

  • 大規模なオーディエンスへの超低レイテンシが製品価値の核心である場合（ライブベッティング、オークション、同期セカンドスクリーンエクスペリエンス）
  • インジェストからプレイバックまでフルスタックを制御でき、新しいプロトコルを吸収できる場合
  • WebRTCのスケーリングコストが実際のビジネス上の問題になりつつある場合
  • 2026年後半または2027年まで出荷されない新しい製品を構築している場合
  • 仕様がRFCに達する前にまだ変更される可能性があることを受け入れられる場合

MoQを注視すべき場合

  • CDNまたはリレーインフラを運用している場合（MoQはHTTP/3 CDNと連携するように設計されている）
  • 同期要件のあるライブスポーツ製品を構築している場合
  • インジェストとディストリビューションを単一のプロトコルに集約したい場合
  • RTMP/SRTインジェスト → HLSディストリビューションの再パッケージングオーバーヘッドに不満がある場合

結論

MoQは現実のものであり、よく設計されており、今日のストリーミングプロトコル環境の真の制限に対処しています。その野心 (リアルタイムとニアリアルタイムの両方のための単一プロトコル、インジェストからディストリビューションまで、CDNスケールのリレーサポート付き) は説得力があります。

しかし、野心は準備完了と同じではありません。仕様は最終化されていません。SafariはWebTransportをベータで搭載していますが、安定版リリースにはまだ含まれていません。本番デプロイメントは早期採用者に限定されています。HLS、WebRTC、SRTを本番環境で信頼性のあるものにしているSDK、ツール、運用知識のエコシステムは、MoQにはまだ存在しません。

2026年に出荷されるほとんどのストリーミング製品にとって、MoQは追跡すべきもの. 採用すべきものではありません。成熟したとき、そしてそれは実現するでしょう、現在複数のプロトコルを再パッケージング層でつなぎ合わせているアーキテクチャを簡素化する可能性を持っています。

それまでは：HLSが配信に機能しているなら、そのまま使い続けてください。WebRTCがリアルタイムのニーズに機能しているなら、そのまま使い続けてください。SRTがポイントツーポイントのリンクに機能しているなら、そのまま使い続けてください。最高のプロトコルは、出荷されて機能しているものであり、カンファレンスのスライド上で最もエキサイティングなものではありません。

出典

ストリーミングコストを削減

Streaming Cost Optimizer

CDN帯域幅の過払いをやめましょう。従量制配信で予期しない超過料金を排除し、ストリーミングコストを削減します。

節約額を計算