1 つの製品 UI で NDI の設定、検出、ブリッジ、監視を実行

Callaba は、NDI を起点とするライブ制作を、運用可能なクラウドまたはセルフホスト型ワークフローに変えます。制御された境界でソースをブリッジし、ブラウザの Multiview で確認し、番組を録画して、次の送信先へルーティングできます。

API ではなく、製品と信号経路から始めてください。認証済みの Callaba ダッシュボードでは、オペレーターがマシン名、Discovery Server のアドレス、明示的なソース IP を設定し、内蔵の JSON インポート機能とエディターを使って、ターミナルを操作せずに高度な NDI 設定を行えます。NDI は、その強みを最も発揮する管理下の制作ネットワーク内にとどめ、予測しにくい WAN 区間には明示的な SRT または互換ブリッジを使用します。その引き渡し後の受信、監視、録画、ルーティング、再生、復旧は Callaba に任せます。

現在の NDI とは

NDI（Network Device Interface）は、従来の SDI 配線の複雑さを伴わずに、映像と音声のソースを IP 経由で伝送するため、制作や AV のワークフローで広く使われています。実務上の特徴は次のとおりです。

• 管理されたネットワーク内でソースをすばやくルーティングするのに適しています。
• 柔軟なスタジオ制作やリモート制作の構成に対応します。
• 規模が大きくなっても安定性を保つには、規律あるネットワーク設計が必要です。

概要とクラウドでの利用背景については、次をご覧ください： クラウド NDI とは何か、どう使うか。

NDI が最も力を発揮する場面

• 制御された LAN 環境内でのマルチカメラ、マルチソース制作。
• ライブスイッチングと監視のための、手間の少ないソースルーティング。
• 固定配線より高い柔軟性が必要なチームの迅速なセットアップ。
• ソース探索とルーティングの速さが重要になる運用ワークフロー。

NDI で最も障害が起きやすい場面

• 計画されていないネットワーク設計（VLAN、マルチキャスト、帯域幅計画の問題）。
• 過負荷状態のスイッチ、または不安定なアップリンクを安定していると見なすこと。
• 重要なソース経路が停止した際のフォールバックがないこと。
• ブリッジモデルを用意せず、LAN の前提を WAN の状況に無理に当てはめること。

多くの障害を防ぐネットワークの基本については、 動作する NDI ネットワーク構成の設定方法。

実運用における NDI ストリーミング

NDI ストリーミングの信頼性は、ソースの命名、ルートの責任者、事前チェックという 3 点をチームで標準化すると最も高まります。これらが欠けていると、ライブセッション中のトラブルシューティングが混乱します。

運用について詳しくは、次のページをご覧ください。 NDI ストリーミング。

最低限の NDI 事前チェック

• 想定されるすべての NDI ソースが表示され、正しく命名されていることを確認します。
• 主要なシーン経路間の同期動作を検証します。
• すべてのグラフィックとオーバーレイを有効にする前に、ネットワークの余力を確認します。
• 重要なカメラまたはプログラムフィード用のフォールバックソースがあることを確認します。

NDI と SRT：実務上の違い

NDI と SRT の比較は、単純な優劣ではありません。それぞれ異なる伝送環境を解決します。NDI は多くの場合、制御されたネットワーク内の制作環境で優れています。SRT は、パケット損失への耐性が求められる不安定なインターネット経由のコントリビューションで優れていることが一般的です。

ソースが分散している場合や、予測しにくいネットワーク越しにリモート配置されている場合は、WAN 上の純粋な NDI がローカル LAN と同じように動作すると期待せず、ブリッジ方式を採用してください。実践的なブリッジの参考資料： SRT 経由の NDI ブリッジを設定する および SRT からクラウド NDI へ。

NDI と RTMP：異なる役割

NDI と RTMP は通常、直接置き換えるものではありません。NDI は制作内部の伝送レイヤーとして使われることが多く、RTMP は多くの配信経路でインジェストや配信側に使われます。RTMP インジェストについては、 RTMP および RTMP サーバーとは。

多くの実用的な構成では、NDI が内部のソースワークフローを担い、RTMP が外部エンドポイントへの配信を担います。役割を明確に分けることで、混乱とインシデント対応時間を減らせます。

ライブストリーミングチーム向け NDI ワークフロー

定期配信に使える NDI ワークフロー：

1. 事前チェック： ソースの表示、命名、同期、ルートを確認します。
2. ウォームアップ： 実際のシーンを使い、非公開の制作経路を稼働させます。
3. ライブ中： 連続性とソースの安定性を監視します。
4. 復旧： 最初にフォールバックのソースまたはルートを適用します。
5. 振り返り： 最初の障害兆候と、改善点を 1 つ記録します。

この手順はシンプルですが、防止できる運用障害の大半を回避できます。

NDI から YouTube と外部プラットフォームへの配信

NDI を起点とするワークフローを外部プラットフォームへ配信するには、通常、境界での変換が必要です。まず内部の NDI 制作を安定させ、それから外向けの配信経路を割り当てます。参考例： NDI を YouTube に配信する。

内部ソースの安定性を確認する前に、外向け配信を最適化しないでください。多くのチームはこの順序を逆にし、誤ったレイヤーをデバッグしています。

リファレンスアーキテクチャ

アーキテクチャ A：ローカル制作ネットワークを優先

管理されたネットワーク内に NDI ソースを置き、ローカル制作環境でスイッチングと合成を行い、制御された外向け配信経路を使用します。特に 安定した オンプレミス環境やスタジオ型環境に適しています。

アーキテクチャ B：ハイブリッド型リモートコントリビューション

必要な区間ではリモートコントリビューションに SRT を使用し、その後、NDI で探索可能な制作ソースに変換します。インターネットの耐障害性と NDI 制作の柔軟性の両方が必要なチームに有用です。次も参照してください。 SRT をクラウドで探索可能な NDI デバイスに変換する。

アーキテクチャ C：共同制作と通話に NDI を使用

必要に応じて NDI フィードを共同制作や通話のワークフローにブリッジします。対話型の運用を伴う分散制作に有用です。参考資料： NDI をビデオ通話へ配信する および ビデオ通話の参加者から NDI 出力を作成する。

実践的なトラブルシューティング

問題：ソースが不規則に表示されたり消えたりする

ネットワークのセグメント化、スイッチの負荷、探索設定、ホストの安定性を確認します。ソース数を減らした状態で検証してから、再び規模を拡大してください。

問題：ソース間で音声と映像がずれる

同期コントロールとタイムスタンプ戦略を使用します。実践的な参考資料： NDI ストリームを同期し、タイムスタンプオフセットを設定する。

問題：負荷の高い区間で品質が低下する

シーン全体に負荷をかけた状態でネットワークの余力を測定し、ソース負荷を下げて再テストします。一度に多数の変数を変更しないでください。

問題：WAN ブリッジの品質が不安定

不安定な区間を、その用途向けに設計された伝送方式（SRT コントリビューションなど）へ移し、制御された境界で NDI に再割り当てします。

運用上のクイックルール

• すべての NDI ソースに 1 つの命名規則を使用します。
• 重要なソースチェーンごとに 1 つのフォールバック経路を用意します。
• ライブ時間帯のルート変更は 1 人の責任者が担当します。
• 配信後に 1 回振り返り、具体的な改善点を 1 つ決めます。

この 4 つのルールだけでも、繰り返し発生する NDI インシデントの多くを減らせます。

重要な KPI

• 対象クライアント群全体での起動信頼性。
• 連続性の品質と中断時間。
• ソースまたはルートの障害後の復旧時間。
• アラート発生から緩和までのオペレーター応答時間。

これらをイベント種別ごとに追跡します。画一的な KPI ダッシュボードでは、実際の問題が隠れてしまうことがよくあります。

Callaba 製品が NDI ワークフローにもたらすもの

Callaba は、NDI 探索、アダプター、ネットワーク構成、アクセス制御されたダッシュボード設定に加え、Multiview、録画、ルーティング、再生を備えています。オペレーターはホストファイルを編集したりターミナルを操作したりせず、UI で Callaba の NDI レイヤーを構成できます。外部カメラ制御とプロダクションスイッチャーは別の機能です。

Callaba UI から NDI ネットワークを構成する

メニューの NDI Tools → NDI configuration で、マシン名、1 つ以上の Discovery Server アドレス、Callaba がバインドする明示的なソース IP アドレスを設定します。高度な SDK オプションでは、JSON または TXT の構成をインポートするか、同じ画面で JSON を編集して、ダッシュボードから保存できます。

ダッシュボード認証とアプリケーションロールによって、これらの設定を変更できるユーザーを制御します。NDI の受信グループと送信グループでは探索の可視範囲を限定できますが、グループはユーザー認証、暗号化、ファイアウォールの代わりにはなりません。ネットワーク ACL とセグメンテーションは維持してください。

次のレイヤーについては、 NDI ネットワーク構成ガイド または NDI 構成 API リファレンス をご覧ください。

• クラウドまたはセルフホスト型の導入： すばやく起動するか、自社で管理するインフラ上に受信とメディア運用のレイヤーを維持できます。
• ブラウザ Multiview： 利用可能な映像と音声の証明として緑色のソケット表示だけに頼らず、オペレーター同士で共有できる映像確認手段を提供します。
• 録画と再生： 受信した番組を保存し、ライブプレビューとは別に成果物を検証できます。
• ルーティングとプロトコルの境界： ローカル NDI、耐障害性のある WAN コントリビューション、プラットフォーム配信、視聴者向け再生を、それぞれ適切なレイヤーに保ちます。

2 つの製品起動方法

メニューの クラウド起動ガイド は、迅速さとマネージドインフラを優先する場合に使用します。 Linux セルフホスト版インストールガイド は、インフラ、データの所在地、ネットワーク近接性を自社の管理下に置く必要がある場合に使用します。どちらの方法でも、同じ実際の NDI 起点ソースを検証してください。

Multiview を受け入れ確認画面として使用する

まず ライブ Multiview デモ を開いてオペレーター向けの概念を確認してから、制作フィード用の非公開の受け入れ確認ビューを構築します。映像、音声、ソース識別、連続性、録画、および少なくとも 1 つの下流送信先を確認してください。

API 自動化は第 2 レイヤー

製品ワークフローを検証した後、 Callaba Engine API を使用して、エンドポイント、ルート、録画、プレーヤー、運用コントロールを自動化します。ソースの責任分担、伝送境界、復旧動作について一通りのリハーサルが完了するまでは、API オブジェクトから始めないでください。

よくある質問

NDI はリモートのインターネットコントリビューションに適していますか？

NDI は制御されたネットワークで最も力を発揮します。不安定なインターネット経由のコントリビューションには、リモート区間で耐障害性のある伝送を使うブリッジモデルを採用してください。

すでに NDI を使用している場合も SRT が必要ですか？

常に必要なわけではありません。リモートコントリビューションの状況が変動しやすく、インターネット経路上でより強力な復旧動作が必要な場合に使用します。

NDI は RTMP より優れていますか？

通常、それぞれ異なるレイヤーを担います。NDI は内部制作の伝送、RTMP はインジェストまたは配信境界の伝送に使われることが一般的です。

NDI の信頼性を最も早く改善する方法は？

ソースの命名を標準化し、毎回事前チェックを実施し、重要なフィードごとに 1 つの フォールバック ソース経路を定義します。

NDI の運用をどのように拡張すべきですか？

まずプロセスを拡張します。役割の責任者、変更可能な時間帯、一貫した配信後レビューのサイクルを定めてください。

次のステップ

この NDI ハブから 1 つの分岐を選び、実際のソース負荷で一通りのリハーサルを行い、実セッションの連続性指標を改善する変更だけを本番へ昇格させます。

チーム運用の実践メモ

チームが成長すると、NDI インシデントの多くは技術的な謎ではなくなります。原因は、一貫しない命名、不明確な責任分担、ライブ時間帯直前の未検証のルート変更です。運用モデルはシンプルかつ厳格に保ってください。多くの場合、それだけで不安定な実験から予測可能な本番運用へ移行できます。

NDI の帯域幅と容量計画

NDI の品質問題は、容量不足が別の形で現れていることがよくあります。重要な配信の前に、ソース数、想定ビットレート範囲、切り替え時のピーク負荷を見積もります。容量計画には、制御トラフィック、監視のオーバーヘッド、ネットワークリソースを共有するバックグラウンドサービスなど、映像以外の要素も含めてください。

実用的な容量チェック：

• 番組の切り替え操作がない状態で、ネットワーク使用量の基準値を測定します。
• シーン変更の全サイクル中に、ピーク使用量を測定します。
• 負荷時に パケット損失 が最初に現れる箇所を記録します。
• 理論上の最大スループットだけでなく、安全な運用余力を設定します。

これにより拡張を予測可能にし、イベントのピーク時に起こる「原因不明」の品質低下を減らせます。

セキュリティとアクセス管理

NDI の議論はパフォーマンスに集中し、アクセス制御を見落としがちです。本番システムでは、ソースの露出や許可されていないルート変更が、品質とコンプライアンスの両方にリスクをもたらします。ソースの可視範囲は、必要なオペレーターと環境に限定してください。

• ルートとソースの構成ツールには、ロールベースのアクセス制御を使用します。
• テスト用と本番用のソース名前空間を分離します。
• 重要なルート変更を、時刻と担当者とともに記録します。
• 影響の大きいイベントの前にアクセス権限を見直します。

こうした小さな制御によって、後の大規模なインシデント期間を防げます。

24/7（24 時間 365 日）運用と長時間チャンネル向け NDI

長時間運用のチャンネルでは、機能の多さより信頼性を保つ規律が重要です。シーングラフを簡潔に保ち、再起動手順を標準化し、長時間稼働中のずれを示す指標を監視します。チャンネルを一度限りの放送ではなく、繰り返し提供するサービスとして扱うと、継続運用の戦略を実務に落とし込みやすくなります。

長時間運用チェックリスト：

• ソースの存在とタイムスタンプの一貫性を定期的に確認します。
• 視聴者への影響が少ない時間帯に、所定の再起動枠を設けます。
• ソース停止と継続的な連続性低下を自動通知します。
• 正常と確認済みのプロファイルセットへ戻す経路を 1 つテストしておきます。

オペレーターのトレーニングモデル

多くのチームは、トレーニングが信頼性を高める効果を過小評価しています。新人オペレーターを断片的な資料だけで業務に就かせてはいけません。ソースの命名規則、ルートの責任者、事前チェックカード、フォールバック手順、配信後レポートの形式を含む、簡潔なオンボーディングフローを 1 つ構築してください。これにより、回避可能なライブ運用上のミスを大幅に減らせます。

短い実践訓練を行います。

• 重要なソースが 1 つ欠けた状態から復旧します。
• 目標応答時間内にフォールバックルートを適用します。
• 制御側と視聴者側の両方の確認で復旧を検証します。

本番昇格前のデプロイチェックリスト

1. すべてのソース名が標準に従い、ランブックと一致していることを確認します。
2. 実際のオーバーレイと複数種類のクライアント確認を含む、一通りのリハーサルを行います。
3. 該当する場合は、リモートコントリビューション用のブリッジ経路を確認します。
4. 担当者を割り当て、フォールバックと復旧の所要時間を検証します。
5. イベント時間帯の前に、重要でない変更を凍結します。

このチェックリストを使わずに本番へ昇格すると、初回稼働が不安定になり、緊急修正のサイクルを繰り返すことになりがちです。

配信後レビューのテンプレート

• 最初にユーザーから見えた問題は何でしたか？
• 最初に停止したソースまたはルートはどれですか？
• どの対応で最も早くサービスを復旧できましたか？
• 連続性の目標へ戻るまでに、どのくらいかかりましたか？
• 次の配信までに変更するワークフロールールは何ですか？

このレビューは短く保ち、必ず実施してください。繰り返すことで信頼性が生まれます。

簡易判断マトリクス

計画時には、次の簡易マトリクスを使用します。

• ローカルスタジオ、制御されたネットワーク： 通常、NDI を優先するワークフローが効率的です。
• 不安定なリモートコントリビューション： 伝送の耐障害性を高めるため、SRT でブリッジします。
• 対話性が重要な経路： 必要な場合は WebRTC の分岐へルーティングします。
• プラットフォーム配信の互換性： 必要な箇所には RTMP 境界を残します。

このシンプルなマトリクスにより、プロトコルの誤用を防ぎ、実際の制約に基づいてアーキテクチャを判断できます。

最後の実践ルール

NDI は、規律ある運用を行う管理ネットワーク上の柔軟なソースワークフローという、最も得意な領域で使用してください。あらゆるリモート伝送の問題を NDI だけで解決しようとしないでください。境界を明確にし、ランブックを短く保ち、フォールバック経路をテスト済みにします。この組み合わせによって、NDI は強力なデモ用ツールから安定した本番システムになります。

5 分間の配信開始直前チェック

重要なセッションを開始する前に、短い確認を 1 回行います。重要な NDI ソースが存在することを確認し、少なくとも 2 つの送信先で音声を検証し、負荷をかけて計画済みのシーン切り替えを 1 回実行し、フォールバックソースを 1 つテストし、2 台目のクライアントから視聴者側の再生開始を確認します。数分で済むこの手順により、気付かないうちに生じたソースのずれやルートの設定ミスによる、多くの配信開始障害を防げます。

迅速な復旧手順

ライブ制作中に NDI 経路の品質が低下したら、順序を固定して対応します。フォールバックソースへ切り替え、視聴者側の連続性を確認してから、ネットワークとソースの診断情報を調べます。視聴者に影響が出ている最中に、細かな再調整を始めないでください。まず復旧し、その後で最適化します。この 1 つのルールにより、実際のセッションにおけるインシデント時間を大幅に短縮できます。

製品選定ガイド

クラウド NDI サーバーを制御された制作境界として扱う

この Callaba NDI 製品 は、NDI 中心の制作と、ルーティングされたコントリビューション、監視、復旧をブリッジします。ローカル探索がそのまま公共インターネットを越えると保証するものではありません。ネットワーク境界を定義し、拠点間では SRT などの適切な伝送方式を使用してください。

NDI ゲートウェイワークフローで検証すべき項目

• 探索ドメイン： 各ネットワーク区間で探索可能にする必要がある NDI ソースを文書化し、制御されていない WAN リンク越しのマルチキャスト探索に依存しないでください。
• 伝送の引き渡し： ローカルで帯域幅と損失を測定し、映像が拠点、クラウドネットワーク、ファイアウォールを越える必要がある場合は、監視されたコントリビューション経路を使用します。
• オペレーターによる受け入れ確認： Callaba でソースの命名と探索を確認し、フィードをライブ制作の進行表に組み込む前に、下流の制作ツールで音声、同期、復旧を検証します。

自動化は第 2 段階です。 まず Callaba 製品でブリッジを構築し、検証します。ネットワークと命名規則が安定した後、再利用可能なルートの第 2 レイヤーとして API 自動化を使用してください。

NDI サーバーとブリッジに関する質問

クラウドワークフローで NDI サーバーは何をしますか？

制作フィードをブリッジ、ルーティング、監視するための制御された地点を提供します。特にソースとオペレーターが別の拠点にいる場合、ネットワーク探索と伝送には引き続き明確な設計が必要です。

NDI ブリッジは公共インターネット越しに動作しますか？

ローカルの NDI 探索がインターネットを越えるとは想定しないでください。SRT など WAN に適した経路でメディアを伝送し、送信先で目的の NDI ドメインへ公開します。

NDI ゲートウェイのサイジング方法は？

同時使用するソース、形式、帯域幅、および変換や録画の処理を洗い出します。アイドル状態のソース 1 つから推測せず、余力を確保した状態でピーク時の番組構成をテストしてください。

該当するワークフローへ進む

• クラウド NDI の基礎
• SRT をクラウド NDI デバイスに変換する

実際のソースで NDI 境界を検証する

1 つの制作フィードを Callaba 経由でルーティングし、探索とルートの状態を確認します。次に、独立した Multiview デモで Callaba のライブ運用インターフェースを確認してから、クラウド配置か Linux 配置かを選びます。

Callaba をクラウドで起動 · Callaba を Linux にインストール · ライブ Multiview デモを開く