Danteユニキャストとマルチキャスト:適切な音声フローの選び方
読了目安 10分 · 更新日 2026年9月29日 · システム技術者、FOHおよびモニターエンジニア、放送オペレーター、プロダクションマネージャー、会場技術者、ツアー音響チーム
Danteのユニキャストとマルチキャストのフローを比較し、ファンアウト、帯域、IGMP、テスト、テクニカルライダーへの記載方法まで解説します。
TL;DR — Danteはデフォルトでユニキャストを使います。つまり、1つのメディアフローは1つの受信デバイスに対して使われます。マルチキャストは、1つの設定されたフローを複数の受信側が参加して受け取る方式です。通常の1対1のサブスクリプションにはユニキャストを使い、複数の受信側が同じ送信チャンネルを必要とする場合や、送信フロー容量が制限になる場合にマルチキャストを検討します。マルチキャストはIGMPで適切に管理されないと、すべてのネットワークリンクに広がる可能性があります。受信側、フロー、チャンネル、リンク帯域を数え、ドキュメント化する前に実際の宛先でテストしてください。
ユニキャストとマルチキャストは異なるファンアウト問題を解決する
Danteのサブスクリプションは、受信チャンネルを送信チャンネルに接続します。ネットワークはそれらのサブスクリプションをフローとして運びます。ユニキャストフローは1つの送信元から1つの受信デバイスへ流れます。マルチキャストフローは送信側で作成され、複数の受信デバイスに供給できます。
| 判断 | ユニキャスト | マルチキャスト |
|---|---|---|
| 宛先 | 1フローにつき1つの受信デバイス | 1つのフローに複数の受信デバイスが参加可能 |
| デフォルト動作 | 通常のサブスクリプションで自動作成 | 送信側で意図的に作成 |
| 送信側の負荷 | 受信側が増えると送信フローがさらに必要になる場合がある | 1つのマルチキャストフローで参加中の全受信側をまかなえる |
| ネットワーク範囲 | トラフィックは各受信側への経路に従う | マルチキャストが適切に間引かれないと広範囲に洪水のように流れる可能性がある |
| 適した開始点 | 小規模または通常のポイント・ツー・ポイント配線 | 同じチャンネルを繰り返し配信する場合 |
| 主なリスク | 送信側フローやアップリンク帯域をファンアウトで使い切ること | 制限のあるリンクに不要なトラフィックを流すこと |
メディアのマルチキャストと、Danteのディスカバリーやクロックトラフィックを混同しないでください。ネットワークは、すべてのオーディオサブスクリプションがユニキャストであっても、マルチキャストプロトコルを使うことがあります。ここでの制作上の判断は、特定のメディアチャンネルをDanteのマルチキャスト送信フローに置くべきかどうかです。
通常のサブスクリプションではまずユニキャストから始める
ユニキャストは最もシンプルなデフォルトです。Dante Controllerが、受信側がサブスクライブ/解除するたびに必要なフローを作成・削除するためです。トラフィックは、多数のリスナーへ意図的に配信されるのではなく、受信デバイスに向けて送られます。
ユニキャストを使う場面:
- 1台または2台のデバイスだけがソースを必要とする場合;
- 受信側グループごとに異なるチャンネルセットが必要な場合;
- 送信側に十分なフロー残量がある場合;
- 不要なマルチキャストトラフィックが高くつくリンクをまたぐ場合;
- システムが小さく、自動ルーティングの確認が容易な場合。
ユニキャストフローは通常、1つの送信元から1つの受信側へ複数のオーディオチャンネルを運びますが、正確なフロー数とチャンネル数の上限は送信デバイスとファームウェアに依存します。一般的な数値だけでショー全体を見積もらないでください。Dante Controllerでそのデバイスの公称送信フロー容量を確認し、実機で計画ルートを検証してください。
多数の受信側が同じチャンネルを必要とする場合はマルチキャストを使う
同じプログラムを多数の宛先へ届ける必要があるとき、マルチキャストは送信側のファンアウトを減らせます。設定済みの1つのマルチキャストフローを、アンプ、レコーダー、放送インターフェース、モニタリングデバイスなどが参加して受け取れます。受信側が1台増えても、送信側から新しいコピーを作る必要はありません。
適した候補:
- 多数のアンプ終端へ配信するプログラムL/R;
- 多くのゾーンで必要なアナウンスまたはページングチャンネル;
- 複数の受信デバイスで共有する放送フィード;
- そのままでは送信側のフロー容量を超える繰り返しソース;
- 相互運用設計上、マルチキャストが必要なAES67または他のRTPフロー。
マルチキャストが使えるからといって、1つの巨大なフローを作らないでください。受信側が本当に一緒に必要とするチャンネルだけをまとめます。フロー内の1チャンネルを受けるだけでも、その経路上でフロー全体が運ばれる場合があります。小さく目的が明確なグループのほうが、命名、測定、削除が安全に行えます。
ルートを変える前にファンアウトを数える
マルチキャストを設定する前に、受信マトリクスを作成します:
| ソースチャンネル | 受信側 | 現在の方式 | 判断 |
|---|---|---|---|
| Main L/R | Processor A, recorder | ユニキャスト | ユニキャストを維持; ファンアウトが小さい |
| Announcement | 12 amplifier devices | ユニキャスト | 1つのマルチキャストフローを評価 |
| Record stems 1–16 | One recorder | ユニキャスト | ユニキャストを維持; 宛先は1つ |
| Lobby mix | Three endpoints | ユニキャスト | フロー制限とネットワーク範囲を比較 |
各送信側について、利用可能な送信フロー数、現在のフロー、計画受信側、受信側ごとのチャンネル数、リンク速度、実測帯域を記録します。ファンアウトの警告は、そのルートを見直すべきだという意味であり、マルチキャストが自動的に安全だと証明するものではありません。新しいマルチキャストトラフィックも、必要なすべてのリンクを通過しなければなりません。
スイッチング層でマルチキャストを制御する
マルチキャスト管理がないと、スイッチは要求していないポートへメディアを転送する場合があります。これは、100 Mbpsリンク、Wi-Fiブリッジ、制御用コンピューター、インターフェースが制限されたデバイスで帯域を浪費する可能性があります。
管理されたネットワークでは、スイッチがどのポートがマルチキャストグループを要求したかを学習するために、一般的にIGMP snoopingを使います。ネットワークには、メンバーシップ状態を有効に保つための適切に設計された querier 機能も必要です。設定の詳細はスイッチのプラットフォーム、トポロジー、VLANによって異なるため、1社のベンダーのメニュー設定をそのままコピーするのではなく、承認済みのネットワーク設計に従ってください。
次の境界を確認します:
- どのスイッチまたはルーターがIGMP querierの役割を持つか?
- 関連ネットワーク全体で snooping が一貫して有効か?
- すべてのトランクポートとアクセスポートが意図したグループを通すか?
- 無線、100 Mbps、制御系、アップリンク経路が不要なメディアから保護されているか?
- 冗長ネットワークが必要な設定をそれぞれ独立して再現しているか?
冗長Danteとスイッチドモードのガイドでは、プライマリネットワークとセカンダリネットワークを分離したままにする必要がある理由を説明しています。マルチキャスト設定は、それらを結合する理由にはなりません。
ルートと障害時の挙動をテストする
1. ベースラインを保存する
変更前に、デバイス名、サブスクリプション、アクティブなフロー、サンプルレート、レイテンシー、クロックリーダー、マルチキャストグループ、スイッチ設定、帯域を記録します。
2. ユニキャスト状態を確認する
すべての宛先が正しいチャンネルを受けていることを確認します。主要な各リンクで送信側のフロー使用量と帯域を記録します。
3. 意図したマルチキャストフローだけを作成する
正確な送信チャンネルを選び、目的を名前にし、既存の受信側がユニキャストからマルチキャストへ移る様子を観察します。移行したと決めつけず、サブスクリプションとフローの状態を確認します。
4. すべてのネットワーク区間を確認する
すべての受信側を有効にした状態で、スイッチポートと制約のあるリンクを測定します。設計にIGMP管理を含める場合は、マルチキャストが必要な場所にだけ現れていることを確認します。
5. 受信側を外して戻す
1つずつ宛先を切断またはサブスクライブ解除します。残りの受信側が継続すること、メンバーシップが正しく更新されること、外した終端が予期しないトラフィック状態やルーティング状態を残さないことを確認します。
6. ロールバックをリハーサルする
マルチキャストフローを削除する前に、送信側が結果として生じるすべてのユニキャストフローを再作成できるか計算します。必要に応じて制御された順序でルートを削除し、ベースラインを復元して、再び音声を確認します。
フローの責任分担をRiderに入れる
実用的な引き継ぎでは、送信元、チャンネル、フロー種別、受信側、スイッチの担当者、IGMP設計、制約のあるリンク、帯域ベースライン、テスト時間帯、ロールバックを明記します。"Danteマルチキャストを使う" だけでは実行可能な指示にはなりません。
Techrider.liveでは、フロー名をインプットリストとアウトプットリストに合わせ、システムエンジニアと放送エンジニアを同じRiderに招待し、受け入れ済みの受信マトリクスを保存し、ルーティング変更後に履歴を確認し、ロードイン用に日付入りPDFをエクスポートします。
Danteフローチェックリスト
- 各送信元の実際のフロー容量が分かっている。
- 同じチャンネルを必要とする受信側が一覧化されている。
- ファンアウトが小さい場合やチャンネルセットが異なる場合はユニキャストを維持している。
- マルチキャストグループには、一緒に属するべきチャンネルだけが含まれている。
- 使用している場合、IGMP snooping と querier の責任分担が文書化されている。
- アップリンクと制約のあるインターフェースで帯域を測定している。
- サブスクリプション状態、クロック、レイテンシー、エラー、損失、ロールバックをテストしている。
FAQ
Danteのユニキャストとマルチキャストの違いは何ですか?
ユニキャストは、1つの送信元から1つの受信デバイスへメディアフローを送ります。マルチキャストは、1つの送信側フローを複数の受信デバイスが参加して受け取れるようにします。ユニキャストはデフォルトで自動、マルチキャストは意図的に設定します。
Danteでマルチキャストを使うのはどんなときですか?
複数の受信側が同じチャンネルを必要とする場合、送信側がフロー上限に近づいている場合、または相互運用設計で必要な場合にマルチキャストを検討します。ルートを変える前に、スイッチの挙動と帯域を確認してください。
Danteはデフォルトでマルチキャストを使いますか?
Danteのメディアサブスクリプションはデフォルトでユニキャストを使います。Danteのディスカバリーとクロッキングもマルチキャストを含むネットワークプロトコルを使いますが、それはマルチキャストのメディアフローを選ぶこととは別です。
DanteのマルチキャストにはIGMP snoopingが必要ですか?
snoopingがなくても音声は通りますが、その場合は不要なスイッチポートへマルチキャストが洪水のように流れる可能性があります。管理された制作ネットワークでは、適切に設計されたIGMP snooping と querier によって、メディアを必要なリンクに留めることが一般的です。スイッチとシステム設計に従ってください。
Danteのマルチキャスト音声はどうテストしますか?
ベースラインを保存し、すべての受信側を確認し、フロー状態を点検し、重要な各リンクを測定し、必要に応じてIGMPの間引きが行われていることを確認し、宛先を外して戻し、制御された形でユニキャストへ戻す手順をリハーサルします。
ロードイン前にファンアウトを見える化する
繰り返しのサブスクリプションでネットワークが使い切られる前に、すべてのソースチャンネル、受信側、フロー種別、スイッチ境界、テスト、担当者、ロールバックを明記した1つのRiderを作成してください。
関連ガイド
ライブ音響のアクティブPAスピーカーとパッシブPAスピーカーの違い
アクティブとパッシブのPAスピーカーを、増幅方式、電源、配線、DSP、運用、保守、そしてテクニカルライダーに記載すべき項目まで含めて比較します。
読了目安 10分基礎知識ライブ音響におけるAES3とアナログ音声の違い:正しい接続を選ぶ
ライブ音響向けに、AES3とアナログ音声の接続を比較。チャンネル数、ケーブル、クロック、パッチ、テスト、フォールバック計画まで整理します。
読了目安 11分基礎知識アナログスプリットとデジタルステージボックスの違い:ライブ音響の受け渡しの選び方
FOH、モニター、録音、配信向けに、アナログマイクスプリットとデジタルステージボックスを比較。ゲインの責任分担、冗長性、配線、テクニカルライダーへの記載方法まで解説します。
読了目安 11分