【ITニュース解説】How our broadcast graphics left vMix, one bottleneck at a time

スポーツ放送の現場で使われるグラフィックシステムは、どのように進化してきたのだろうか。この記事は、ある企業が７年かけて、オンエアグラフィックのシステムを段階的に改善し、抱えていた課題（ボトルネック）を一つずつ解消していった物語である。システムエンジニアを目指す皆さんにとって、実際の開発現場でどのように問題を見つけ、解決策を検討し、それがまた新たな課題を生み出すのかという、実践的な思考プロセスを理解する良い機会となるだろう。

最初の段階では、多くの放送現場と同じように、vMixという映像ミキサーソフトウェアと、その専用グラフィック形式であるgtzipファイルが使われていた。オペレーターは、グラフィックテンプレートが詰め込まれたgtzipファイルをvMixに読み込み、試合ごとに手動でスコアやチーム名などのデータを設定していた。もちろん、vMixにはGoogle SheetsやExcelなどのデータソースと連携してグラフィックを自動更新する機能もあった。しかし、この機能は単一のグラフィックのバリエーションを扱うのには適していたが、スコアボード、選手紹介、統計情報など、２０〜５０種類もの異なるグラフィック要素で構成されるスポーツ放送のパッケージ全体には対応しきれなかった。手動での設定作業は依然として多く、グラフィックを修正するたびにエディタを開く必要があったため、ワークフローの改善には繋がらなかった。また、vMix自体をクラウドに移行しても、グラフィックの作成や管理方法が変わるわけではないため、根本的な問題解決にはならなかった。

そこで、最初の大きな変革として、オンエアグラフィックをWebページとして作り、それをvMixの入力レイヤーとして利用する独自のグラフィック制御プラットフォームを構築した。これにより、グラフィック自体はもはやvMixの内部ではなく、外部のWebページとして存在することになった。この変更はいくつかの重要な効果をもたらした。まず、vMixのメモリ負荷が大幅に軽減された。従来のgtzip形式では、追加するグラフィックテンプレートが増えるほどvMixのメモリ使用量も増大し、特に高解像度のアニメーションでは数ギガバイトものグラフィックスメモリを消費することがあった。しかし、Webページを単一の入力として扱うことで、グラフィックパッケージの大きさに関わらずvMixのメモリ使用量が一定になり、システム全体の安定性が向上した。次に、グラフィックのテストが容易になった。Webページであれば、一般的なWeb開発で行われる自動テスト手法を適用できるため、人が目視で確認し、エラーがないことを祈る従来の検証方法から脱却できた。さらに、グラフィックの背後にあるデータがこの新しいプラットフォームに集約され、構造化された形で管理されるようになったため、オペレーターはgtzipファイル内で個別にデータを設定する必要がなくなり、作業負担が軽減された。しかし、この改善は新たなボトルネックを生み出した。それは、すべてのグラフィックをWeb開発者がコードを書いてWebレイアウトとして構築しなければならなくなったことである。

この新しいワークフローでは、一つのグラフィック要素をgtzipから手書きのWebレイアウトに移植し、アニメーションを実装するのに平均で１日半もの開発者の時間が必要になった。クライアントから依頼されるグラフィックパッケージには２０〜５０もの要素が含まれるため、新しいクライアントを獲得するたびに、開発者の工数が膨大にかかることになった。何よりも問題だったのは、その予測不可能性である。新規クライアントからのグラフィック制作依頼が急に入ると、既存の開発計画が崩壊し、本来開発すべき機能の実装が遅れてしまう事態が頻発した。リソースやアイデアが不足しているわけではなく、グラフィック制作が原因で開発スケジュールを約束できないという状況に陥っていたのである。

このボトルネックを解消するため、次にRiveというグラフィック作成ツールを導入した。Riveでは、デザイナーがグラフィックを直接描き、アニメーションの状態遷移を定義する。開発者の役割は、スコアやチーム名などのデータを、デザイナーが作成したグラフィックの特定のフィールドにマッピングする作業に限定された。この変更により、一つのグラフィックを作成するのにかかっていた開発者の工数は、約１日半から、デザイナーによる約半日の作業へと大幅に削減された。結果として、１日に４〜８個のグラフィックを制作できるようになり、生産性が劇的に向上した。また、デザイナーによる作業になったことで、外部のデザイナーに委託することが可能になり、コスト効率も向上した。これにより、これまで開発計画を阻害していたグラフィック制作のボトルネックは解消され、開発者は本来の製品機能開発に集中できるようになった。Riveの導入当初、Webサイドとの連携で３０〜４０ミリ秒の遅延が発生するという問題があったが、これを検出し、修正することで、グラフィックレイヤー全体の処理時間は４０〜５０ミリ秒に落ち着いた。これは単一のグラフィックではなく、パッケージ全体を処理する時間である。さらに、Riveはメモリ使用量の問題にも対処した。Rive自体もラスター画像（ビットマップ画像）を扱うとメモリを消費するが、重要なのはアニメーションの作成方法が変わった点である。Riveではアニメーションを録画するのではなく、「描画」する。つまり、アニメーションが図形、キーフレーム、状態遷移のデータとして表現されるため、ファイルサイズが数百キロバイト程度に抑えられ、アニメーションの長さやフレームレートに依存してメモリが膨大に増えることがなくなった。これにより、アニメーションのフットプリントは大幅に削減され、ステップ１で課題となったアニメーションのメモリ問題も解決された。

このように、各ステップでの改善は、その時点のボトルネックを解消すると同時に、次の新たな課題を生み出してきた。Webオーバーレイの導入は、グラフィックをvMixのメモリから解放し、テスト可能にしたが、開発者による手作業でのレイアウトというボトルネックを生んだ。Riveの導入は、このレイアウトのボトルネックを解消し、同時にグラフィックをブラウザや特定のツールに依存しない「ポータブルなファイル」へと変貌させた。

特に最後の点は、当初は意図していなかった予期せぬ成果であった。グラフィックがファイルと状態遷移、そしてデータから構成されるようになり、ブラウザを必要とせず、またそもそもGPU（グラフィック処理装置）も必要としないという事実が明らかになったのである。この発見は、放送現場にある、高価なGPUワークステーションの存在意義そのものに疑問を投げかけるものだった。次のステップでは、この疑問の答えを探ることになるだろう。