東京と富山をブラウザでつなぐ ― IVS リモートプロダクション【準備編】

2026-10-21 2026-10-21

UchinoKiyotaka

投稿者：ウッチーノ・ジョブズ

東京と富山。二つの拠点を、ブラウザを開くだけで双方向につなぐ。富山の映像を東京に送り、東京で切り替えて配信する、いわゆるリモートプロダクションです。今回はその仕組みを、中継車も専用回線も使わずに組んだ記録です。

きっかけは、定期的に開いている勉強会「PERCHスクール」です。梅ノ木文化計畫、ライブオフィスPERCH、ベクターデザインの3者で開いている講座・ワークショップで、「教えあい、学びあう。」を掲げ、写真やプログラミングの入門から編集、ボイトレまで、毎回テーマを変えています。これまでは東京のオフィスだけで開いてきましたが、今回は弊社のもう一つの拠点である富山から、講義をしてもらうことになりました。そのために考えたのが、この仕組みです。

使うのは、AWS が提供する Amazon Interactive Video Service（以下「IVS」）の Real-Time Streaming です。サーバーは Railway に置き、現場は両拠点ともノート PC のブラウザで、カメラの映像は ATEM から USB で入れます。利用者は運用者と現地スタッフだけという、小さな体制を前提にしています。

準備編では、なぜ IVS を選んだのか、どんな仕組みにしたのか、本番の前に何を整えたのかを順に書きます。

なぜ IVS なのか

IVS が候補に上がったのは、ふだんから業務で AWS を積極的に使っていたことと、IVS ならリアルタイムのストリーミングを比較的簡単に組めそうだと感じていたからです。

ただ、最初から IVS だけを考えていたわけではありません。もう一つの候補が、Blackmagic Cloud の Stream Router でした。SRT や RTMP の映像をクラウド経由でつなぎかえるサービスで、送る側は ATEM スイッチャーから直接出せることもわかりました。アプリを作らなくても構築できるのは、大きな魅力でした。

しかし Stream Router は、映像の流れが一方向です。東京と富山を双方向につなぐには2回線分が要り、それに合わせた送信の仕組みも拠点ごとに用意しなければなりません。遅延も IVS より大きい。比べていくうちに、結果的に IVS になりました。とはいえ Blackmagic Cloud の手軽さは魅力的で、一方向で済む現場など、どこかで業務として使ってみたいと思っています。

IVS の強みは、「低い遅延で双方向」を、自分でメディアサーバーを持たずに手に入れられることでした。

今回は、富山の講師と東京の会場がやり取りしながら進めます。映像と音声が数秒遅れると、そのやり取りが成り立ちません。IVS には配信向けと双方向向けの2種類があり、今回使うのは後者です。

	Low-Latency Streaming	Real-Time Streaming（今回）
仕組み	チャンネルに配信し、HLS で視聴	ステージに参加し、WebRTC で双方向
遅延	数秒	300ms 以下（AWS の公称値）
向いている用途	一方向の配信	会議、拠点間のやり取り

Real-Time Streaming を選ぶと、次のものが一度に手に入ります。

ブラウザだけで参加できる。 Web Broadcast SDK を CDN から読み込むだけで、現場にアプリを入れる必要がない
メディアサーバーを自分で運用しなくてよい。 映像の中継は AWS 側が引き受ける。こちらのサーバーがやるのはトークンの発行だけ
入る人をトークンで絞れる。 トークンがなければステージに入れない。発行の権限も、IAM でそのステージだけに限定できる
2拠点に限らない。 ステージには複数の映像を同時に送れる（映像を送れる参加者は、AWS によれば1ステージ最大12）。拠点を増やすことも、1拠点から複数台のカメラを送ることもできる
将来広げられる。 同じ API の延長線上で、機能を広げていける

「それ、Zoom でよくない？」

この話をすると、たいてい最初にこう聞かれます。筆者自身、まだそう思うところがあります。

会議ツールを IVS の代わりにする考えは、最初からありませんでした。考えていたのはむしろ、Zoom のような会議ツールとどう差をつけるかです。

先に認めておくと、二つの拠点が顔を見て話すだけなら Zoom で十分です。誰でも使い方を知っていて、画面共有も録画もチャットも最初からそろっている。ここで作った仕組みには、そのどれもありません。

それでも IVS で組む意味があるとすれば、つなぎたいのが「会議」ではなく「番組の素材」だという点です。違いは次の3つです。

画面が、そのまま映像素材になる。 受けた富山の映像は、東京の ATEM に入れて YouTube に出します。会議ツールの画面には、名前の表示やボタン、他の参加者のタイルが重なりがちです（設定である程度は消せます）。このアプリは相手の映像1枠だけを出す作りで、全画面にもできるので、余計なものが写りません。
音声の設定を、拠点ごとに固定できる。 Zoom にも「ミュージシャン向けのオリジナルサウンド」があり、エコーキャンセルなどを切ること自体はできます。ただ、設定は各 PC の Zoom アプリ側にあるので、拠点ごとに担当者が正しく選んでおく必要があります。このアプリでは、東京は OFF、富山は ON が拠点の URL で決まり、現場で誰かが触って変わることがありません。
会議を「開く」人がいらない。 ミーティング ID もホストも待機室もなく、拠点ごとの URL を開けば入れます。Zoom の無料プランには 40 分の時間制限もあります（有料プランなら問題になりません）。

もう一つ、仕組みを自分たちで持っていることも大きい。たとえば監視カメラのような機材も、中継用の PC を1台置けば、ステージの参加者として直接入れられます。どこまで手を入れるかを、こちらで決められます。

業務用のリモートプロダクションも加えて並べると、次のようになります。

	業務用のリモートプロダクション	Zoom	今回の仕組み（IVS）
映像の運び方	専用回線や、映像伝送用のエンコーダーとデコーダー	会議アプリ	ブラウザ（WebRTC）
遅延	低い（回線と機材による）	会話向けに低く抑えられている	300ms 以下（AWS の公称値。未実測）
画質	高い。カメラごとに別の映像を送れる	回線に合わせて自動で変わる	回線に合わせて変わる
映像の扱い	番組の素材として送る	会議の画面（名前やボタンが重なりがち）	相手の映像だけを出せる
音声	業務用の機材で管理する	既定で会議向けの処理が入る（切ることもできる）	拠点ごとに処理を固定できる
導入の手間	機材と回線の手配が要る	アプリを入れるだけ	開発が要る。現場はブラウザだけ
費用	機材・回線・人員がかかる	月額のプラン（無料は 40 分まで）	使った時間に応じた AWS の料金と、サーバー代
向いている場面	放送、大規模なイベント	会議、打ち合わせ	小規模な配信や勉強会
弱み	高価で、準備が大がかり	番組の素材としては使いにくい	自分で作って保守する。安定性はまだ未検証

業務用は構成によって大きく変わるので、ここでは一般的な傾向として書いています。

逆に、まだ言い切れないこともあります。遅延や画質が Zoom より良いのかは、同じ条件で比べていません。「わざわざ作った価値があったか」は、実際につないでみた次回に、数字で答えたいと思います。

仕組みの全体像

構成は、拠点が2つ、IVS のステージが1つ、自前のサーバーが1つだけです。

自前のサーバーは、映像には触れません。ブラウザからアクセスキーを受け取り、正しければ IVS に参加用のトークンを発行させて返すだけです。トークンには拠点名を入れ、東京と富山で別々に発行します。開くたびに新しいトークンを取るので、期限切れも起きません。

準備でやったこと

準備は大きく4つです。どれも一度やれば、あとは URL を開くだけで使える状態になります。

ステージを作る（AWS）。ステージは1つだけです。拠点ごとに作ると、お互いが見えなくなります。
トークン発行だけができる IAM ユーザーを作る（AWS）。許可するのは ivs:CreateParticipantToken だけで、対象もこのステージに限ります。クラウドに置く認証情報なので、万一漏れてもトークン発行しかできないようにしています。
GitHub と Railway をつなぐ。リポジトリは Private です。main に push すると Railway が自動でデプロイし、HTTPS の URL も Railway が発行します。カメラとマイクは HTTPS でないと使えないので、ここが大きい。
アクセスキーを決める。openssl rand -hex 24 で長いランダム文字列を作り、Railway の環境変数に入れます。このキーを知らないと、トークンは取れません。

Railway の便利なところは、手間の少なさです。GitHub のリポジトリをつなぐだけで、Dockerfile などの設定を書かなくても Node のアプリとして動きます。その後は push するたびに新しい版に入れ替わり、秘密の値は管理画面の Variables に入れるだけなので、コードには書きません。

アクセスキーは、初回だけ URL に付けて開きます。開いた瞬間にブラウザに保存し、URL からは消えます。画面共有やスクリーンショットに写らないための工夫です。キーが漏れたときは、Railway の環境変数を変えるだけで古いキーを無効にできます。

音声は、あえて拠点ごとに変える

設計で一番特徴的なのは音声です。東京と富山で、ブラウザの音声処理を正反対にしています。

	東京	富山
音の通り道	マイク → MG10 → AUX（ミックスマイナス）→ PC のマイク入力	会議スピーカー（USB）で入出力
相手の声	PC のヘッドホン出力 → MG10 に戻す	会議スピーカーから出す
エコーキャンセル・ノイズ抑制・自動ゲイン	すべて OFF	すべて ON

東京では、富山の声も MG10 に入れて東京のマイクと混ぜ、ATEM 経由で YouTube に出します。ただし富山へ返す AUX には、富山の音を入れません。入れると、富山の声が富山に戻ってエコーになります。これがミックスマイナスです。

音はミキサーで作り込んでいるので、東京ではブラウザに音声処理をさせません。富山は逆で、スピーカーから出た東京の声を同じ機器のマイクが拾うので、ブラウザのエコーキャンセルに頼ります。なおヘッドホンとマイクが共通の端子になっている PC では、分岐用のアダプタが必要です。

「そろえた方がきれい」に見えても、統一しない。このルールは、開発メモにも「変えてはいけないこと」として残しています。

現場の機材構成

両拠点とも、IVS につなぐのはノート PC のブラウザです。カメラの映像は、スイッチャーの ATEM を USB でつなぎ、Web カメラとして入れます。

	東京	富山
IVS につなぐ端末	ノート PC	ノート PC
カメラ入力	ATEM Mini Pro ISO（USB）	ATEM Mini Pro（USB）
カメラ	BirdDog P200、ビデオカメラ	BirdDog P200
マイク	DJI のワイヤレスマイク、ハンドマイク（MG10 経由）	会議スピーカー（USB）
スピーカー	ヘッドホン出力を MG10 へ	会議スピーカー
その他	YouTube への配信、モニター	PC の画面も ATEM に入力

東京の ATEM Mini Pro ISO は、番組全体の中心です。東京の映像の出入りは、すべてここを通ります。

富山 → 東京： IVS で受けた富山の映像を、東京の PC の HDMI 出力から ATEM に入れる
東京 → 富山： ATEM の出力を USB の Web カメラとして PC に入れ、IVS で富山に送る
配信： ATEM で東京のカメラと富山の映像を切り替え、YouTube に出す

つまり富山に届くのは、YouTube に出しているのと同じ、ATEM で切り替えた後の映像です。入力が足りなければ ATEM SDI Extreme ISO を使う想定です。

「富山に何を返すか」は、準備で一番悩んだところです。配信の映像には富山の映像も入るので、本来は富山に送る用の映像を、配信とは別に切り替えるのが筋です。ただそうすると、

東京の各カメラの映像を分岐させる必要がある
分岐した映像を受ける ATEM が、もう1台要る
切り替えが2系統になり、オペレーションが煩雑になる

そして何より、今回はテストを兼ねています。そこで、配信と同じ映像をそのまま返す、シンプルな形にしました。

なお IVS の画面は Web アプリなので、ノート PC でなくても使えます。iPad でも Safari で開けばそのまま参加でき、ホーム画面に追加すれば全画面のアプリとして起動できます。

Tailscale で、拠点の機材をつなぐ

両拠点に旅行用ルーター GL-MT3000 を置き、Tailscale で拠点間をつないでいます。これで東京の PTZ コントローラーから、富山の BirdDog P200 も操作できます。富山にカメラマンがいなくても、東京から画角を作れます。

離れた拠点の PTZ カメラを操作するのは、これまでは業務用のリモートプロダクションで組むのが普通でした。それを、旅行用のルーターと Tailscale という手軽な組み合わせで実現できたのは、今回の大きな収穫です。

もちろん、インターネット越しに PTZ を操作できるサービスはあります。BirdDog の「BirdDog Cloud」や、PTZOptics の「Hive」などです。ただいずれも年額制で、米国の販売店の価格を見ると、BirdDog Cloud は2拠点分の年間ライセンスが 995 ドル、Hive は上位プランが年 999 ドルです。どちらも映像の伝送などを含むサービスなので、単純な比較はできませんが、操作だけが目的なら、今回の組み合わせの方がずっと身軽です（Tailscale の Standard プランで、1ユーザーあたり月 8 ドル）。

拠点	ルーター	サブネット（例）
東京	GL-MT3000	192.168.10.0/24
富山	GL-MT3000	192.168.20.0/24

ここで使っているのが、Tailscale の「サブネットルーター」という機能です。意外と知られていませんが、今回の構成の要です。

Tailscale は普通、パソコンやスマホにアプリを入れて、その端末同士をつなぎます。つないだ端末には、それぞれ 100. で始まる Tailscale 用の IP アドレスが割り振られます。ところが P200 や ATEM のような機材には、アプリを入れられません。

そこで、各拠点の GL-MT3000 を窓口にします。GL-MT3000 は Tailscale に対応しているので、ルーター自体が Tailscale の端末になり、100. で始まるアドレスを持ちます。さらに、自分の配下のネットワーク（東京なら 192.168.10.0/24）を、Tailscale のネットワーク全体に知らせられます。Tailscale の管理画面でその経路を許可すると、同じ Tailscale のネットワークにいる端末ならどこからでも、東京の 192.168.10.xx の機材に届くようになります。両拠点のルーターがお互いの経路を受け入れれば、拠点の機材同士もつながります。

こうしておくと、ルーターの配下につないだだけの機材が、アプリを入れなくても Tailscale の端末のように扱えます。東京の PTZ コントローラーから、富山の P200 にふだんの IP アドレスのまま届くのは、この仕組みのおかげです。サブネットを拠点ごとに分けているのは、番号が重なると、どちらの拠点の機材か区別できなくなるためです。表の数字は説明用の架空のものです。

逆に言えば、同じ Tailscale のネットワークに入っている端末からは、拠点の機材にも届いてしまいます。Tailscale に入れる端末は関係者のものだけにしておきます。Tailscale のアクセス制御で、届く範囲を絞ることもできます。

実は最初、P200 の映像そのものも Tailscale で送ろうと考えました。P200 は NDI に対応しているので、NDI のまま東京に届ければよい。ところが、ここで壁に当たりました。

NDI は、同じネットワークにいる機器を自動で見つけるのに、mDNS というマルチキャスト（一斉送信）の仕組みを使います。一方 Tailscale は端末どうしを一対一でつなぐ仕組みで、マルチキャストを通しません。そのため、東京からは富山の P200 が NDI の映像として見えないのです。

NDI には、相手の IP アドレスを手で指定したり、Discovery Server という仕組みを使ったりして、別のネットワークの機器とつなぐ方法もあります。ただ NDI はもともと LAN の中で使う前提の規格です。そこで、映像はインターネット越しの伝送を前提に作られた IVS に任せ、Tailscale は機材の操作に使う、と役割を分けました。

準備中にもう一つ発見がありました。Tailscale 越しに富山の ATEM Mini Pro へ ATEM Software Control をつなぐと、東京から富山のスイッチングまでできてしまいます。カメラの遠隔操作と合わせれば、リモート先の人手をさらに減らせそうです。

次回

準備が整ったところで、後編では実際に東京と富山をつないだ話を書きます。通話の遅延はどれくらいか。富山に返す映像は、今のシンプルな形で足りるのか。準備でつまずいたことや、出力を増やす実験についても書く予定です。

なおこの仕組みは、今回の勉強会だけで終わらせず、将来的にはサービスとして提供することも視野に入れて開発を進めています。

出典

カテゴリー: コラム

タグ: IVS Tailscale リモートプロダクション