照明のバックアップ卓を上げた瞬間、照明が二重に見えた

2026-09-24

sACN優先度マージとフェイルオーバー設計の勘所

対象読者：撮影・演出・音響・照明・編集・配信・制作進行に関わり、IP伝送技術に関心を持つすべてのプロフェッショナルへ。

予備の卓を上げたのは、念のためだった

授賞式形式の企業イベント、本編が始まって40分ほど経った頃だった。アシスタントオペレーターが「念のため」とバックアップの照明卓を立ち上げ、メインと同じネットワークに接続した。マニュアルどおりの手順だった。数秒後、ステージ中央のムービングライト数台が、今のシーンには出ていないはずの暖色を薄く帯び始めた。フェードは正しく流れている。キューも合っている。なのに、消えているはずの前のシーンの残像のようなものが、ライトの上に薄く重なって見えた。メインオペレーターはキューシートを見直し、照明デザイナーはフィクスチャの故障を疑った。原因はどちらでもなく、2台の卓が同時に同じ命令を出していたことにあった。

2台の卓は、どちらも「自分が正しい」と思っていた

舞台照明のIP制御で広く使われるsACN（ANSI E1.31）には、複数の卓が同じユニバースに送信した場合の優先順位を決める仕組みがある。各パケットには0から200までの優先度が1つ書き込まれており、規定の初期値は100だ（出典：ANSI E1.31-2016、DMPレイヤーのPriorityフィールド定義）。優先度が異なれば、受信側は優先度の高い卓のデータを512アドレスすべてでそのまま採用する。ここまでは単純な多数決ではなく完全な一択で、迷いは生まれない。問題は、2台の卓が同じ初期値100のまま接続されたときに起きる。優先度が同点の場合、規格はアドレスごとに「値の大きい方を採用する」という混合処理（HTPマージ）を行うと定めている。メインの卓が出しているシーンと、バックアップの卓に残っていた古いシーンとで、たまたま値の大小が入れ替わったアドレスだけが、バックアップ側の値に置き換わって出力される。もう一つ、規格上は接続を切る合図となるパケットが3回連続で送られて初めて「正式な終了」と扱われる（出典：同規格6.2.6節）。ケーブルを黙って抜いただけでは、受信側はこの合図を受け取れず、既定の待ち時間である2.5秒間、判断を保留し続ける（出典：同規格附属書A、E131_NETWORK_DATA_LOSS_TIMEOUT）。

あなたが見ていたのは、2枚のフィルムが重なった映像だった

これは、2台の映写機が同じスクリーンに別々のフィルムを重ねて投影しているのに近い。スクリーンのどこを映すかを一括で切り替えるのではなく、画面の位置ごとに「どちらのフィルムが明るいか」を1コマずつ比べて、明るい方だけを残す仕組みだ。両方が同じ場面を映していれば違和感は出ない。だが片方だけ古い場面を映したままだと、画面のあちこちに前の場面の残像が透けて混じる。メインもバックアップも壊れておらず、操作も間違っていない。同じ明るさの優先順位を持つ2つの光源が、同時に同じスクリーンへ投影されただけだ。