生放送の音声品質監視

メディア運用チーム向けの生放送音声品質管理 · ゼロから単独で、設計からデプロイまで担当

更新日2026年10月

導入前

解説音声は手作業での確認で、見逃した異常が視聴者に届きかねませんでした。

導入後

1時間

の測定値を、ネットワーク障害中も現地に保持して一度だけ再送。ラウドネスはEBU基準で測定します。

仕組み

1ソフトウェア:会場
解説音声を多数のチャンネルで送出します。
2ソフトウェア:現地エージェント
すべてのチャンネルをEBUラウドネス基準で測定します。
3ソフトウェア:現地エージェント
測定値をディスクに保存し、ネットワーク断の後に再送します。
4ソフトウェア:クラウドサービス
異常が一定時間続いたらアラートを発報します。
5人:オペレーター
コンソールでアラートとインシデントを確認します。

常時動作

クラウドは重複した測定値を無視するため、再送しても二重計上されません。

課題

解説音声は手作業で監視され、見逃すと視聴者の苦情、規制上の罰金、評判の低下を招くおそれがありました。

原因の分析

アラートは、漏れがなく静かでなければ役に立ちません。通信断で測定値が失われ、不安定な検出器は誤検知アラートの洪水を招きます。

検討した選択肢

クラウドとの接続が切れても、測定値を失わないためにはどうしますか？
採用
測定値を現地のディスクに保存して再送し、クラウド側は重複を無視する
1時間分の測定値と1日分のイベントは障害後も残り、再送しても二重にカウントされません。代償は、現地のマシンの構成要素が増えることです。
- 不採用
  測定値をメモリに保持し、満杯になったら古いものから捨てる
  障害中、つまり最も重要なときにデータが失われます。
検出器がオンとオフを繰り返すとき、アラートはいつ出しますか？
採用
異常が最低限の時間続いた場合のみ出し、その後はクールダウンを置く
1つの不安定なチャンネルからアラートが殺到することはありません。
- 不採用
  切り替わるたびにアラートを出す
  1つの不安定なチャンネルが、誤検知アラートでオペレーターを埋もれさせます。

ソリューション

現地のエージェントが各チャンネルを測定してクラウドに送信します。オペレーターはプロジェクト、しきい値、アラートを扱うWebコンソールを使います。

現地エージェント: Python
EBU R128 loudness
ONNX Runtime
PyTorch
SpeechBrain
Windows build
クラウドAPI: FastAPI
SQLAlchemy
Alembic
PDF reports
データ: TimescaleDB
PostgreSQL 17
オペレーターコンソール: Next.js
React
TanStack Query
WebSockets
uPlot
Zustand
品質とデリバリー: Docker Compose
GitHub Actions
uv
Ruff
mypy
pytest
Playwright
axe

数値: エージェントのバッファ設定