IBC2026の3つのバズワード：DMF、MXL、MoQ

「Mr. DMF」が語ったDMFとMXL

これらのキーワードの中でも今後の放送システムを語る上で避けて通れないと思ったのが、DMF（Dynamic Media Facility）とMXL（Media eXchange Layer）である。

EBUブースをはじめ、Grass Valley、Sony、AWS、TAG Video Systemsなど多くの展示でMXLの文字を見かけた。EBUのIBC2026公式ページにも多数のDMF/MXLセッションと対応メーカーのデモが並んでいた。

では、DMFとMXLとは一体何なのだろうか。IBCのEBUブースで、「Mr. DMF」との異名もとっているEBU Senior IP Media Technology ArchitectのWillem Vermost氏に話を聞いた。

Vermost氏が最初に語ったのは、「高価な放送機器を購入しているのに、本当にそのハードウェアを有効利用できているのか」という、極めてシンプルな問題提起がDMF検討の発端となったという話である。

放送事業者は、ニュース用設備、スポーツ用設備、ラジオ設備など、それぞれのピークに合わせて専用機器を用意する。しかし、それらが常時フル稼働しているわけではない。このことはSDIをST 2110へ置き換えても根本的には変わらない。伝送路はIPになるが、その両端に特定機能専用のハードウェアが存在していれば、設備利用の考え方は従来と変わらないからだ。

一方、ITの世界では状況が大きく異なる。汎用サーバーを用意し、DockerやKubernetesなどを使って必要なアプリケーションを必要なときだけ起動する。同じ計算資源をさまざまな用途で共有するのは当たり前となっている。

では、放送設備でも同じことができないだろうか？午前中はラジオ制作、昼はニュース、夜はスポーツ中継。その時間に必要なメディア機能をコンテナとして立ち上げ、終了すればそのリソースを解放する。スイッチャー、グラフィックス、EQ、マルチビューアー、エンコーダー、プレイアウトといった「機器」を、汎用コンピュータ上で動く「機能」へ変えていく。これがDMFの基本的な発想である。

EBUもDMFを、「固定的なハードウェア中心の設備から、柔軟でスケーラブル、レジリエントかつ相互運用可能なSoftware Defined Infrastructureへ移行するためのアーキテクチャ」であると定義している。

原点の一つは東京オリンピック

興味深かったのは、Vermost氏がDMFへつながる自身の経験として東京オリンピックを挙げたことだった。

当時ベルギーの公共放送局VRTに在籍していたVermost氏らは、東京から複数の競技ストリームを配信する必要があった。しかしベルギーから見れば競技時間は深夜帯にあたり、従来型の制作設備とスタッフを用意すれば大きなコストがかかる。

そこでソフトウェアを使った制作システムを構築した。

Vermost氏によれば、一人のエンジニアが約30日でソフトウェアを開発。SDIスイッチャーやAudio over IPなど既存技術も組み合わせながら、一人のオペレーターが三つのストリームを扱える環境を作ったという。

この経験から見えてきたのが、「操作するUIと、実際にメディアを処理する機能は同じ場所にある必要がない」という考え方だった。

これは、物理的な操作卓をなくすという話ではない。Vermost氏も「ボタンやTバーをなくしたいわけではない」と強調する。重要なのは、「Control / UIとMedia Functionを分離すること」なのである。

オペレーターは従来通りTバーやボタンを使ってもいい。しかし、その操作によって動くスイッチャー機能は隣のラックではなく、データセンターやクラウド上のコンテナで動いていてもいい。この分離こそがDMF開発の重要な出発点であった。

ST 2110にしただけでは解決しなかったこと

ところが、メディア機能をソフトウェア化していくと新しい問題が見えてきた。

Vermost氏は次のように説明した。

つまり、「Software A → ST 2110 → NIC → Network → NIC → Software B」という経路になる。

Vermost氏らは、ここに不要な処理と遅延が発生することに気付いた。「同じコンピュータ上にあるソフトウェア同士なのに、なぜ映像を一度「外」に出す必要があるのか？」

この問題を解決するために必要になったのが、ソフトウェア間で直接メディアを受け渡す仕組みだった。それこそがMXL（Media eXchange Layer）である。

DMFとMXLの関係

もう一つ、Vermost氏が強調した重要な点がある。「DMFという規格が発表されたわけではない」という点である。「DMFはアーキテクチャであり、ビジョンである」という。

EBUは2026年4月にDMF Reference Architecture v2.0を公開し、汎用コンピュータ、メディア交換、メディア機能、コントロール、オーケストレーションなどの関係を整理した。特にv2.0ではオーケストレーションを複数レイヤーにまたがる機能として明確化している。

EBUとAMWAは2025年9月、ソフトウェア定義型の動的メディア制作環境を実現するための参照アーキテクチャ、ベストプラクティス、仕様、ガイドライン、およびビジネスモデルのフレームワークを作成することを主な目的としてJoint Taskforce on Dynamic Media Facilities（JT-DMF）の設立を発表した。公共放送だけの構想ではなく、商用放送局、メーカー、ITベンダーを含む業界共通の枠組みへ広げようとしている。

つまり、DMFは「設計思想/Reference Architecture」であり、MXLは「その中で最初に実装された共通技術」という関係である。

SDK提供による「Implement-Fist」アプローチ

EBUはMXLを規格としてまとめているのではなく、仕様書とオープンソースのSDKとして提供している。従来は規格書を作り、各メーカーがその仕様を読んでそれぞれ実装するという段取りが必要だった。そして最後にPlugfestなどを行って「A社とB社は本当につながるのか」を確認する必要があった。

しかしMXLはそれとは異なるアプローチをとっている。メーカー各社が同じオープンソースコードをベースに製品を開発する、「implement-first」とEBUが説明するアプローチである。MXLのコードはLinux Foundationのもとで公開されている。

Grass Valleyも独自方式からMXLへ

DMF/MXLの文脈で興味深かったのがGrass Valleyで聞いた話だった。

同社はDMFという言葉が登場する以前から、スイッチャー、マルチビューアー、グラフィックス、プレイアウトなどをソフトウェアとして動かすAMPP Platform環境を提供してきた。いわばDMFに近い世界をすでに商用化していたメーカーである。

しかしAMPPはもともとMXLを使っていたわけではない。Grass Valley Japanの三輪氏によれば、AMPPにはソフトウェア間でメディアを交換する独自の仕組みがあり、その考え方自体はMXLに近かったという。ところがEBUを中心にMXLが業界共通の仕組みとして立ち上がり、多くのメーカーが参加するようになった。そこでGrass Valleyも独自方式に閉じるのではなく、MXLへ乗る判断をしたとのことだ。

IBC2026ではAMPPがMXL v1.1をネイティブサポートするという発表があった。MXLフローの機器発見と制御にはNMOSを利用し、SDI、ST 2110、MXL、AMPPアプリケーションを同じ環境で動作させた。

つまり、「AMPPをMXLに置き換えたのではなく、AMPPがMXLを取り込んだ」という説明であった。

一方、Vermost氏とのインタビューでは興味深い指摘もあった。彼が描くDMF/MXLの理想は、特定メーカーのプラットフォームに依存しない環境である。汎用コンピュータとKubernetesなどのIT基盤があり、その上でSony、Grass Valley、Lawo、Riedel、あるいは将来登場するAIベンダーのソフトウェアを自由に組み合わせる。MXLはそのための共通メディア交換レイヤーであるという考え方だ。

Vermost氏は一例としてSonyのM2 Liveを挙げ、コンテナとして展開できるような実装をDMFの考え方に近いものとして評価する一方、AMPPについてはGrass Valleyのプラットフォームとしての閉鎖的な性格が残っている点を指摘した。ここにはEBUが描く完全にオープンなDMFという理想と、Grass ValleyがAMPPという既存商用プラットフォームをMXL対応させていくという現実的な実装との違いがある。

この点についてGrass Vallleyの三輪氏は、「MXLが共通化するのは、ソフトウェア間でメディアを交換する部分だが、その上で、どのアプリケーションを起動するか、 どこにコンピュータリソースを割り当てるか、いつ停止させるか、システムをどう監視するか、 利用料金をどう管理するかというオーケストレーション機能は依然として必要になる」と語っていた。

AMPPの場合、必要なソフトウェアモジュールを追加・停止でき、使用を止めれば課金も止まる。

三輪氏によれば、AMPPでは本番とは別にテストモードも用意されており、ウォーターマークは入るものの課金なしでシステムを立ち上げることができる。事前の構築やリハーサルはテストモードで行い、本番時だけ必要な機能を有効にするといった運用も可能になる。

したがって、MXLが「メディア交換の共通レイヤー」であるのに対して、AMPPは「アプリケーションやコンピュータ資源、運用、課金を束ねる商用プラットフォーム」という関係だという。

DMF/MXLで実現されるSDB（Software-Defined Broadcast）

筆者がNAB2026の前に訪問したカナダのCBC/Radio-Canadaのモントリオール本部や、IBC2026の後に訪問したFrance Télévisionsなどではいち早くDMF/MXLの導入の検討に取り組んでおり、JT-DMFによる仕様が確定してベンダーが対応してくればすぐにも導入すると語っていた。France TélévisionsではMoIP対応の放送機器の本体は局舎から離れたデータセンターに置き、操作関連のUI部分のみを本社に設置するという仕組みをすでに実現している。ST 2110に続いてDMF/MXLが一般化すれば、SDB（Software-Defined Broadcast）が一歩実現に近づくだろう。

ソニーはInterBEEのソニーブースで、「『MXL』をソニーはどう捉えているのか？ソニーが描くライブ制作の未来」と題したセミナーを行い、ソニーが推進するSDBの将来像を語ると予告している。（11月20日金曜日14時〜14時30分、https://x.gd/J3LNW）

もうひとつのバズワード「MoQ」

IBCで話題になっていたもうひとつのバズワードが「MoQ（Media over QUIC）」であった。このテーマについてはフランスのエンコーダーメーカー、Atemeと、オーストリア公共放送ORFの関連会社であるBig Blue Marbleで話を聞いた。

OTTの「15〜20秒」を1秒以下へ

MoQは、Googleが開発した通信プロトコルの第三世代「HTTP/3」の基盤でもあるUDPベースのトランスポート「QUIC」の上で、映像・音声を「オブジェクト」として配送する仕組みだ。標準はオープンで、RTPパケットやDASHセグメントなど、運ぶオブジェクトを柔軟に定義できる。

HTTP/2（TCP+TLS）では1つのTCP接続で複数のデータ（画像やCSSなど）を並列送信できたが、パケットが1つでも欠損すると、TCPの仕組み上すべてのデータの到着が停止する問題（Head of Line Blocking）があった。HTTP/3（QUIC）では各データストリームが独立して処理されるため、一部のパケットが消えても他のデータの読み込みが止まらない。

また、従来（TCP + TLS）の手順では通信を始める前に何度も往復するやり取り（ハンドシェイク）が必要であったが、HTTP/3では輸送層の確立と暗号化（TLS 1.3）を一度に行うため、遅延（RTT）を大幅に削減し、一度接続した相手なら0-RTT（往復なし）でデータ送信を開始することができる。

Big Blue Marbleによれば、一般的なOTT配信では遅延は15〜20秒発生し、低遅延構成でも約5秒にとどまるのに対し、MoQでは、カメラのレンズから視聴者のディスプレイまで（グラス・トゥ・グラス）で約1秒、あるいはそれ以下を実現できたという。

Ateme：WebRTCの後継として、まずB2Bから

AtemeはMoQを「WebRTCの置き換え/後継を目指す技術」と位置づけた。当面はコンテンツプロバイダーとディストリビューター間のB2B用途が先行し、1秒未満の遅延が効くスポーツのインタラクションやベッティングなどを想定。将来的には同じ基盤をOTT/B2C規模へ広げる構想だ。

ブースでは、同社のTitan Gatewayでエンコードした映像をMoQリレー経由でデコーダーに届け、約600msの遅延で再生するデモが示された。TS/CMAFいずれのオブジェクトにも対応し、DRM暗号化の統合など、現在HTTP配信で実現している機能をMoQ上でも提供する方向だという。

興味深いのはパーソナライズの発想だ。一度エンコードしたストリームを複数の受け手に届け、後段でそれぞれがグラフィックやニュースを差し込む。1対1のB2Bにとどまらず、1対多や端末別の個別化へ発展させる展望が語られた。なお600msはあくまで当日のデモ値であり、大規模なB2C環境で同等の性能が確認されたわけではない。

Big Blue Marble：F1中継で実証、5G Broadcastとの冗長化も

Big Blue MarbleはMoQについては製品投入前の開発・社内ラボテスト段階としながらも、遅延1秒以下を保ったまま最大5,000の同時接続を確認した試験結果を紹介した。ORFのF1中継を用いた検証では、衛星放送に対して約1秒、地上波に対して約5秒の遅れという数値も示された。

同社が強調したのは、MoQ自体はビットレートやフレームレートを規定しないという点だ。実際の遅延は前段のエンコーダー設定や圧縮、処理速度に左右され、画質とのトレードオフもある。1秒前後の遅延を実現するには、配信系全体の設計が欠かせないという。

さらに同社は、5G BroadcastとMoQを組み合わせた冗長化構成も提案した。両方に対応した端末であれば、5G放送の受信が途切れた際に端末側でインターネット経由のMoQへ自動的に切り替え、モバイル視聴の連続性を確保できるという。ただし、この連携は実験・検証中で、ブースで切替そのものの実演はなかった。

MoQの標準化と実装は今後の注目点

両社の説明から見えたことは、MoQが「放送並みの遅延をインターネット配信で実現する」現実的な選択肢になりつつある一方、現時点ではB2B伝送やラボ検証が中心であり、大規模なB2C配信での実績はこれからだという点だ。

2025年9月には、Akamai、CDN77、Cisco、Synamedia、YouTube、Red5などが中心となり、業界コンソーシアム「OpenMOQ Software Consortium」が発足した。IETFで標準化が進むMoQ Transportプロトコルについて、インジェスト、リレー、再生を担うオープンソース実装を共同で開発し、ベンダー間の相互運用性を確保することが目的だ。

その後もBitmovin、EZDRM、MainStreamingなどが参加し、今回取材したAtemeもメンバーに名を連ねている。各ベンダーが独自に実装を進めるのではなく、共通の土台の上で互換性を担保する枠組みが整いつつあることは、MoQの採用を検討する放送事業者にとって重要な判断材料となるだろう。MoQの標準化と実装がどこまで進み、既存のCDNやDRM、広告挿入の仕組みとどう統合されていくのか。2027年に向けて注視すべきテーマの一つだ。

MoQの標準化と実装がどこまで進み、既存のCDNやDRM、広告挿入の仕組みとどう統合されていくのか。2027年に向けて注視すべきテーマの一つだろう。