【IIJのクラウドサービス活用】なぜ今、放送システムのクラウド化が進むのか──IIJ GIO × Appearで考える次世代基盤

みなさんこんにちは！
映像配信の話@IIJ 中の人の一人、ワタナベです。

放送設備の更新時期を迎えたとき、多くの放送局やコンテンツ事業者が直面するのが「クラウド化をどう進めるべきか」という課題です。

機器の更改費用や設置スペース、人材不足への対応、リモート制作への対応などを背景に、映像制作・伝送基盤のクラウド利用は急速に広がっています。一方で、

• 何をクラウド化すべきか

• 品質や遅延への影響はないのか

• 現在の設備と共存できるのか

といった不安を抱える方も少なくありません。

本記事では、放送システムのクラウド化を検討する際に押さえておきたいポイントを整理しながら、IIJ GIOインフラストラクチャー P2 Gen.2とAppear VX Platformを活用した構成例をご紹介します。
特に近年は、リモートプロダクションやイベント配信など、必要なときに必要なリソースを柔軟に利用できる環境へのニーズが高まっています。

IIJは昨年のInter BEE 2025において配信で活用できる様々なアプリケーションをIIJが提供するクラウド基盤「IIJ GIOインフラストラクチャーP2 Gen.2」（以下IIJ GIO）に乗せて「メディアクラウド」という形で展示しました。

今後クラウド化が進むにつれてより強く求められる安定したメディアの運用環境の構築に向けた取り組みの一環として、今回はInter BEEでは時間の都合で扱えなかったAppear社の「VX Platform」というサービスを取り上げます。

Appear社「VX Platform」

Appear社は2004年にオスロ（ノルウェー）で放送局出身のメンバーによって設立された会社です。放送局向けのヘッドエンドであるXC Platformや、ライブプロダクションのためにIP伝送に最適化されたX Platform（X20 / X10 / X5）などをリリースしてきました。2026年4月にリリースされた「VX Platform」は、放送業界がオールIP化および柔軟な分散型インフラへと移行する中、既存のハードウェア資産を活かしつつ将来的なクラウド移行をシームレスに行える「未来への投資（Future-proof）」ソリューションとして、位置づけられています。
X PlatformでSDI/SMPTE ST 2110をIPに変換し、VX Platformへ送ることでクラウド上での柔軟なルーティングやマルチフォーマット配信を可能にするといった、オンプレミスとクラウドの境界を無くし、さらに（この記事では触れませんが）MXL（Media Exchange Layer）にも対応することで、ベンダーロックインからの脱却も提案しています。

2025年のIBCでデジキャス合同会社様（以下DIGIcas社）のご好意でAppear社にお話を伺い、さらに国内でのDIGIcas様のセミナーやイベントなどでお会いする機会があり、今回IIJ GIO上での検証にご協力いただけることになりましたので、機能の紹介や動作確認、使用感などをまとめていきたいと思います。

本記事の性質上、専門的な用語が多く含まれています。適宜、補足説明を交えて解説していきますが、すべての用語について説明を尽くせていない点は、何卒ご容赦ください。

「VX Platform」とは

最初にVP Platformについて簡単に説明します。
VXの技術仕様書には以下のように記載されています。

そしてVX PlatformはVX coreをベースとしてその上に構築される階層化された機能群全体を指します。

将来的にはライブプロダクションに必要となるあらゆる要素を冗長化し耐障害性や拡張性を高めて提供する、そんなプラットフォームを目指しているとのこと。

そして2026年4月にVX Media Gateway V1.0がリリースされました。入出力はマルチキャスト、TS、UDP/RTP、SRTに対応。他にはSMPTE ST 2022-7への対応、A/B Failover、IATモニタリング（パケット到着間隔の監視）、RTPカプセル化が可能です。

ワークフローの監視やモニタリングにはPrometheusとGrafanaが採用されていて、全ての機能を網羅的に監視できるようあらかじめ設定されています。VXのメニューから「Statistics」をクリックするとGrafanaにアクセス可能です。

また他ではあまり見ない機能としてSRTのマルチコネクションをサポートしています。通常は1つの出力に対して1つのコネクションのみ接続可能ですが、VXは1つの出力（Listener）に対して複数のコネクション（Caller）を繋ぐことができるようになっています。

これらの機能を放送局が求めるレベルの耐障害性を兼ね備えた形で提供するアプリケーション（VX 技術仕様書より）となっています。

VX Media Gatewayとは

メディアゲートウェイは通常、映像・音声などのメディアの中継機能を持った機器、サービスを指すことが多いです。プロトコルやコーデックの変換、出力先のルーティングなどを担います。
ロゴにある通り今回リリースされた「VX」はメディアゲートウェイです。現地からの映像を受け取り複数の宛先へ配信するツールであり、現状は限られたプロトコルのみ利用可能な形ですが、自社で開発しているX Platformからの入力が容易なことでVXへの接続や伝送の安定性は非常に高いのではと思われます（X Platformは未検証）。

では実際にワークフローを作ってみます。

使い方

まずは事前準備が必要

VXはワークフローを作る前に事前の準備として

• Networks

• Compute Resource Types

• Compute Resource Instances

を設定する必要があります。

Networksの設定では、ワークフローの各工程で使用する「論理ネットワーク」を決めます。これを続くリソース作成時に実際の物理ネットワークインターフェース」へマッピングしていくのです。「ストリーム用」「管理用」といった役割のラベルを作り、実際に通信する際に使うネットワークインターフェースを割り当てる、という形です。

Compute Resource Typesの設定では、ワークフローの構築で利用可能な機能、アクセス可能なネットワークを決めていきます。

さらにCompute Resource Instancesでは、サーバ上のリソースをあらかじめ確保する宣言をします。コンサートで席を予約する、というようなイメージです。ワークフローを実行するときに、必要な条件を満たす席（リソース）の中から、利用可能な席が順次使用されていきます。

複雑そうに見えますが、簡単に言うと

• 利用するネットワークに名前をつける

• 実際に通信する物理ネットワークインターフェースと紐付ける

• どのリソースの種類でどのネットワークを使うかを決める

• 実際にワークフローで使うリソースを確保しておく

という流れです。
この辺りはマニュアルにも記載されていますが、少々わかりにくい部分でもあります。

これで実際にワークフローを作る準備が整いました。

ワークフローを作ってみる

ワークフローの作り方は至ってシンプルです。
それぞれの機能を画面上にノードとして配置し、それらを繋いでいくだけでワークフローが完成します。

まずはシンプルにSRTのストリームを2本入力し、それをRTPカプセル化しつつ、A/B Failoverに繋いでいきます。入力される2本の映像はどちらもSRTである必要はなく、SRTとRTPでも構いません。
RTPカプセル化をすることで映像・音声をRTPヘッダ（タイムスタンプやシーケンス番号など）で包み、IPネットワーク上で効率的に伝送を可能にします。ジッタ（遅延の揺らぎ）を吸収する制御なども行えるようになります。
A/B Failoverは入力された2本のストリームを監視しつつ、正常なストリームを次のノードへ出力する機能を持っています。ストリームの切り替えは自動で行われます。
そしてA/B Failoverから出力されるストリームを最後にSRT出力ノードに繋いでいきます。

今回は試せませんでしたが、SMPTE ST 2022-7による冗長化にも対応しています。

IIJ GIO上での動作

今回検証のために必要となるサーバのスペックは以下の通りです。これはAppear社より指定されたスペックです。

それほど高スペックではありませんし、昨今何かと値上がりや入手困難性が話題になるGPUも利用しません。
今回はIIJ GIOのフレキシブルサーバリソースで近しいスペックのサーバインスタンスを用意しVXをインストールしています。
もちろん扱うストリームの数や解像度、ビットレートなどによってはより高スペックなサーバが必要になるとのことですが、シンプルなワークフロー2つを1週間〜2週間程度動かす程度では上記スペックで全く問題なく非常に安定しており、不安になるような挙動は全くありませんでした。

今回は全体で50〜60Mbps程度の入力、25〜30Mbps程度の出力で検証していましたが、連続稼働にも関わらず、CPU負荷にスパイクなどもなく、メモリの使用量も安定していました。

ただ、入力された映像の目視確認はできず、オーディオ周りの情報も無く、入力されたストリームおよび出力されるストリームの状態が把握できないというのは少々辛いものがあります。せめて入出力される映像の詳細情報は表示して欲しいところです。Alarmsについては時系列でデータ取得可能（CSVを）ですが、もう少し入出力周りの詳細なログ情報もUIから取得できると良いかなと思いました。この辺りは利用者によってどこまで必要となるかは変わってくるかと思います。

監視については１つのモジュールに対して個別のDashboardがデフォルトで用意されていて必要なパラメータの状況をすぐ確認できるようになっています。もちろん必要なパラメータを自由に配置して監視するためのオリジナルDashboardを自分で構築することもできるのでニーズに合った監視、モニタリングができるようになっています。

１つ気になったのは、ワークフロー一覧のAlarms表示についてでした。下のワークフロー（２つ目）では特に何も発生していないはずですが、なぜか"Critical"なアラートが発生していると表示されていました。過去のものが残っている可能性もありますが、期間中には調査できずでした。

「VX Platform」の今後のロードマップ

ここまでにも書いてきた通りリリースされたばかりのVX Media Gateway V1.0はVX PlatformのベースであるVX Coreに近い機能です。今後、より上位階層の機能のリリースも楽しみですが、VX Platformとして、今年は以下の機能の実装・リリースが予定されているそうです。

• HEVC / AVC デコード機能

• マルチビューアー

• HEVC / AVC エンコード機能

今回リリースされた部分については、もう少し幅広いプロトコルへの対応、ストリームの詳細（コーデック、解像度、オーディオ情報、プロトコルなど）表示、映像の目視確認、ウォーターマークや蓋被せ機能などが実装されると、使い勝手が上がるように思いましたが、MXLなどの新しい技術への対応なども積極的に取り組まれているので今後の発展が楽しみなプラットフォームです。

放送システムをクラウド化する際に考えるべき3つのポイント

ここまでVX Media Gatewayについて見てきましたが、放送システムのクラウド化は、単なる設備の置き換えではなく、運用の考え方そのものを見直す取り組みです。

本記事でご紹介した構成例を踏まえると、クラウド化を検討する際には次の3つのポイントが重要になります。

1. 何をクラウド化し、何を現場に残すのか

すべての機能を一度にクラウドへ移行する必要はありません。制作、伝送、エンコード、配信などのワークフローを整理し、クラウド化によって柔軟性や効率化の効果が得られる部分を見極めることが重要です。

2. 放送品質を維持できる設計になっているか

放送・配信システムには安定性や品質が求められます。クラウド基盤だけでなく、ネットワーク構成や冗長性、運用方法まで含めて設計することで、従来と同等あるいはそれ以上の品質を実現できます。

3. 将来の変化に対応できるか

映像制作現場では、リモートプロダクションやイベント配信など新たなニーズが増え続けています。設備を保有する前提から、必要なリソースを柔軟に利用する前提へ移行できるかどうかが、今後のシステム選定における大きなポイントとなります。

IIJ GIOインフラストラクチャー P2 Gen.2とAppear VX Platformは、こうした要件に応えながら、放送システムの次世代化を支える選択肢の一つと言えるでしょう。

クラウド化の目的は設備を単にクラウドへ移行することではなく、変化に強く柔軟な映像基盤を実現することにあります。本記事が今後のシステム検討の参考になれば幸いです。

謝辞

最後に、IIJ GIO上での検証機会を快諾し、貴重な技術的知見、資料や素材を提供してくださったAppear社の皆様、そしてフォローしてくださったDIGIcas社の皆様に、心より感謝申し上げます。

※本記事に掲載しているロゴ画像は、Appear社より提供を受け、許諾を得て使用しているものです。また、画面イメージも許諾を得て使用しているものです。無断転載は固くお断りいたします。