本番中、映像が止まった。でも「なぜ止まったか」は誰もわからなかった
中継先でSRT回線の映像が突然止まった。回線業者に確認しても「異常なし」の一言。スイッチのランプも全部緑。ラックの中を確認しても、エラーランプは一つも点いていない。5分後に復旧したが、なぜ止まったのか、誰にも説明できなかった。
翌週、同じ現場でまた同じことが起きた。
あの沈黙を経験したことがある人には、この状況の重さがわかるはずだ。
「見えない」から怖い——IP伝送のリスク構造
SDIケーブルの時代は、トラブルの原因がほぼ物理的だった。ケーブルが断線する、コネクタが抜ける、シンクが外れる。どれも目で見て、手で触って確認できた。
IP伝送になると、話が変わる。映像データはネットワーク上を小さなパケットの束として流れ、スイッチやルーターを何段も経由して届く。その途中で何が起きているか、画面を見ているだけでは絶対にわからない。
問題の構造は3層に分かれている：
第1層：物理回線の揺らぎ
パケットが一定の間隔で届かない「ジッター」、途中で消えてしまう「パケットロス」、そして往復にかかる時間「RTT（ラウンドトリップタイム）」。これらはSRTやSMPTE ST 2110など、どのプロトコルを使っていても根底に存在するリスクだ。
第2層：プロトコル固有の挙動
SRTは自動再送（ARQ）でパケットロスを補う仕組みを持つが、補償できる量には上限がある。パケットロス率が1%を超え始めると再送トラフィックが帯域を圧迫し始め、3%を超えると映像が止まる可能性が急激に高まる（SRT Alliance公式ドキュメント）。SMPTE ST 2110環境では、PTPクロックのズレがマイクロ秒単位で映像・音声の同期に影響する。
第3層：アプリケーション品質の劣化
上記2層が複合的に悪化すると、最終的に視聴者の目に届く映像品質（QoE）が落ちる。VMAF（Video Multimethod Assessment Fusion）スコアで80を下回ると、色ノイズやモスキートノイズが静止部分に現れ始める（Netflixが開発・公開した品質評価モデル、github.com/Netflix/vmaf）。
健康診断のないまま手術する怖さ
IP伝送の現場で「感覚」だけを頼りにしている状態は、心電図モニターを外したまま手術室に入るようなものだ。数値が出ていれば「異常の予兆」は必ず先に現れる。止まってから気づくのでは、遅い。
Prometheusというオープンソースの監視システムを使うと、ネットワーク上で何が起きているかを数値として記録・可視化できる。設定ファイルを書けばすぐ動き始め、Grafanaという可視化ツールと組み合わせることでリアルタイムのダッシュボードを構成できる。
「こういうツールはエンジニアのもの」と思われがちだが、実際には違う。映像プロとして「自分のシステムが今どんな状態か」を数値で語れることは、現場での信頼につながる。
この記事で得られること
有料部では、以下を完全に解説する：
- Prometheusの初期構築手順（ゼロからGrafana連携まで）
- SRT品質の読み方と限界値（RTTマルチプライヤー計算、帯域オーバーヘッドの実数値）
- SMPTE ST 2110環境でのPTPクロック監視（ナノ秒単位の計測方法）
- PromQLによる動的アノマリー検知式（Zスコアを使った「静的閾値に頼らない」アラート設計）
- SLO達成率の定量評価クエリ（「99.9%以内に収める」をクエリで証明する方法）
- よくある設定ミスと正解（現場で実際に踏んだ罠とその回避手順）
ここから先は「見える現場」をつくる人のために
「見えなかったから仕方ない」は、これからの中継現場では通じなくなる。クライアントはログを求めるし、障害報告には数値が必要だ。
私が45年の現場で学んだ判断軸を、ここに集約した。次の配信から即使える。
コメント