配信のマイナスワン（n-1）とは — 質疑応答で音を返さない作り方

質疑応答で視聴者を壇上に上げた瞬間、その人が急に話しにくそうになる。言葉が途切れ、進行が止まる。配信の現場で何度も見てきた光景です。

原因のほとんどは、質問者に自分の声が返っていることです。自分の声が少し遅れて耳に戻ってくると、人はまともに喋れなくなります。質問者側のマイクを疑っても、通信環境を疑っても直りません。原因は配信元の卓にあるからです。

結論 — 配信へ送る音と、会話へ送る音は別物

配信エンジンへ送るのは、会場も質問者も全部混ざったオールミックス。会話セッションへ送るのは、質問者自身の声だけを抜いたマイナスワン（n-1）。この2系統を作り分けるところまでが、配信元の仕事です。

同じ音を両方へ送ると、質疑応答が始まった瞬間に破綻します。

配信元には、送出用のPCが2台立つ

会場のスイッチャーとミキサーに対して、送出用のPCが2台つながります。

PC	役割
IVS送信用PC	エンコーダー（OBSなど）。配信の本編を送る
SkyWay接続用PC	ブラウザで質疑応答のセッションに参加する

この2台に違う映像と違う音を送る、というのがこの記事の全体像です。以下、音声から順に見ていきます。

抜くのは「質問者のマイク」ではなく、卓に立てた受けの1ch

配信へ送るオールミックスのほうは、迷うところがありません。視聴者は会場の音も質問者の声も聞きたいので、卓のMAINをそのまま送ります。

問題は会話側です。ここでは1つだけ音を抜きます。抜くのは、会話セッションから戻ってきた質問者の音声です。

質疑応答が始まると、SkyWay接続用PCが受けた質問者の声は、ミキサーの1chとして卓に立ちます。これを立てないと会場のスピーカーから質問が聞こえないので、必ず立てます。ところが同じ卓から会話側へも音を送っているため、何も考えずに送ると、立てたばかりのその1chがそのまま質問者へ返っていきます。

そこで、会話側へ向けたAUX（MIX）センドでは、その1chだけを送らない設定にします。全入力（n）から1つ引くので n-1（マイナスワン） と呼びます。

ここで取り違えが起きやすいのが、抜く対象です。抜くのは「質問者のマイク」ではありません。 質問者は遠隔にいるので、そもそも会場に質問者のマイクはありません。抜くのは、卓に立てた会話セッション受けの1chです。この対象を取り違えると、配線としては正しく見えるのに音が返り続けます。

映像にも同じ構造がある。AUXへ送るのは演者の寄り

同じことが映像側でも起きます。

スイッチャーのPGM——テロップや画面分割を作り込んだ完成映像——は、IVS送信用PCへ送ります。視聴者が見る本編です。

会話側へは、AUXセンドから演者の寄りカメラを送ります。PGMではありません。PGMには質問者がPinPで合成されているので、それをそのまま返すと、質問者は小窓の中の自分を延々と見ることになります。

ただし、現実にはもう一つ理由があります。ライブ配信で使われる多くのスイッチャーは、性能上、AUXセンドにMEを載せられません。 AUXから出せるのは入力ソースをそのまま出す程度で、テロップや画面分割を作り込んだ映像は出せない。つまり「PGMから質問者だけを抜いた映像」は、作りたくても作れないことが多いのです。カメラの撮りきりを送るのが現実解になります。

そして、これは妥協ではありません。質問者のWebカメラは、たいていバストショットになります。そこへ演者の寄りを並べると画角が揃い、対話らしい画になります。引きの絵と寄りの絵を並べても、同じ会話をしている2人には見えません。制約に従った結果が、そのまま画作りとして正しいという、珍しく気持ちのいいケースです。

卓だけでは止まらない。質問者の画面では、音が切り替わっている

卓でマイナスワンを組んでも、それだけではループは止まりません。質問者のブラウザで配信の音が鳴っていれば、結局そこから自分の声が聞こえてくるからです。

SynQNowの視聴プレイヤーでは、指名された瞬間に配信側の音声をミュートし、会話側の音へ切り替えます。映像はそのまま流れ続け、切り替わるのは音だけです。

切り替えのタイミングが「入室時」ではなく「指名時」なのには理由があります。質疑応答は、こう進みます。

挙手 → 会話セッションへ入室（順番待ち）→ 指名 → 発言
                    ↑                        ↑
          この間は配信の音を聞いている   ここで音が切り替わる

挙手した人は、まず会話用の部屋に入って順番を待ちます。この間に聞いているのは配信の音です。ここで会話側へ切り替えてしまうと、指名されるまでのあいだ、挙手した人だけが議事を見失うことになります。かといって切り替えないまま指名すれば、その瞬間にループが起きる。

卓のマイナスワンと、プレイヤー側の切替が噛み合って、初めて音が止まります。 片方だけでは止まりません。

画面の配置も、この延長にあります。中央に配信映像、その下に演者と自画面が並びます。演者の画は会場のAUXから届いたもので、自画面はこれから会場のスイッチャーへ戻り、本編にPinPで合成されるものです。卓で組んだ2系統が、そのまま質問者の画面に見えているわけです。

それでも音が戻るなら、ループとエコーを切り分ける

ここまでやっても音が戻ることがあります。このとき現場で起きやすいのが、ループとエコーの混同です。どちらも「発言した本人に音声が戻ってくる」という同じ症状で現れるので、まぎらわしい。ただ、原因がまったく違うため、対策も変わります。

	原因	起きている場所
ループ	マイナスワンができていないなど、ミキサーやPCの設定	配信元の卓・PC
エコー	質問者の声が会場PAで拡声され、それを演者などのマイクが集音する	会場の空間

エコーのほうは、質問者が話す → 会場のスピーカーから出る → 演者のマイクが拾う → その音がまた会話側へ乗る、という経路をたどって本人に戻ります。卓の設定はどこも間違っていません。

聞き分けは、リハでやる

原因は違いますが、症状は「戻ってくる」で同じです。切り分けは、戻ってきた音の質で行います。

• ループ — はっきりした音がそのまま戻ってくる
• エコー — 会場の遠くで鳴っているような、輪郭のぼやけた音が戻ってくる

これはリハーサルでやることです。そして、この耳は実際に必要になります。マイナスワンを組むのが自分とは限らないからです。会場によっては、卓は別の乗り込み業者が担当します。設定済みだと聞いていても、戻ってくる音を自分で確かめておかないと、分かるのは本番中になります。

ループは、リハ前に潰しておく

ループは設定の問題なので、再現性があります。裏を返せば、事前に必ず潰せるということです。リハーサル前の確認項目に入れておきます。本番中に出てくるようなら、それは事前確認の漏れです。

会場側で先に潰しておけるものが、もう一つあります。会話用PCのスピーカーから音を出さないこと。 出せば会場のマイクが拾い、確実に戻ります。モニターはヘッドホンか、ミキサー経由に統一します。

エコーは、出たり出なかったりする

やっかいなのはエコーのほうです。リハで潰せることもありますが、質問者側の環境や音量によって、発生したりしなかったりします。 リハで問題が出なかったからといって、本番で出ないとは限りません。

Web会議システムには、エコーキャンセラ（エコキャン）を搭載したものもあります。ただし、イベント現場での多用は禁物です。 エコキャンは戻ってきた音を消す仕組みなので、音楽や拍手といった現場の音まで一緒に消してしまうことがあります。会場の熱量を届けるための配信で拍手が消えるのは、エコーより重い損失です。

現場で効きやすいのはオートミキサーです。発言していないマイクのレベルが自動で下がるので、拾い直しの経路そのものが細くなります。

そして、オートミキサーの無い卓で残る最後の手が、「人間エコキャン」と呼んでいる手動操作です。

本番中に何を見て、何を触るかという話は、配信オペレーターは、本番中に何を見て判断しているのかにもまとめています。

まとめ

• 配信エンジンへはオールミックス（n）、会話セッションへはマイナスワン（n-1）を送る。この2系統の作り分けが配信元の仕事
• 抜くのは「質問者のマイク」ではなく、卓に立てた会話セッション受けの1ch。取り違えると、配線は正しく見えるのに音が返り続ける
• 映像も同じ構造。AUXへ送るのは演者の寄り。多くのスイッチャーはAUXにMEを載せられないという制約があり、同時にそれが画角を揃えるための正しい選択にもなっている
• 卓だけでは止まらない。視聴プレイヤー側で配信の音を止めて、初めて音は返らなくなる
• 音が戻るときはループとエコーを切り分ける。ループは設定が原因で再現性があるのでリハ前に潰す。エコーは会場PAと演者マイクの経路で起き、質問者の環境によって出たり出なかったりする。エコキャンは拍手や音楽まで消すため多用せず、オートミキサーを使う

配信と会話を別のサービスに分けている理由そのものは、AWS IVSとSkyWayを選んだ理由に書いています。1対多の配信と少人数の会話では、最適化の方向が逆になるという話です。