ネットワーク（帯域/QoS/FW）
ネットワーク要件は、ビデオ会議の相互接続が安定するかどうかを左右する最大の要因です。私たちメディアプラスの経験では、接続品質のトラブルの多くは、帯域不足・QoS未設定・ファイアウォールの設定漏れに起因しています。
PoCに入る前に、このページの帯域目安とファイアウォールチェックリストを確認しておくと、検証がスムーズに進みます。
解像度別の帯域の目安
ビデオ会議の帯域は解像度と参加者数で決まります。以下は1参加者あたりの帯域目安です。
| 接続品質 | 必要帯域 | 推奨帯域 | 用途の目安 |
|---|---|---|---|
| HD（1080p） | 1.5〜2.0Mbps | 2.5〜3.0Mbps | 大画面表示、役員会議室 |
| HD（720p） | 0.8〜1.2Mbps | 1.5〜2.0Mbps | 一般的な会議室端末 |
| SD（480p） | 0.5〜0.8Mbps | 1.0〜1.5Mbps | 帯域が限られる拠点、SD端末 |
| 音声のみ | 64〜128kbps | 128〜256kbps | 音声参加、電話ゲートウェイ |
実務のポイント
帯域は「平均値」ではなく「ピーク時に確保できるか」で考えてください。月曜朝や会議集中時間帯に回線が逼迫する拠点では、SDでの運用も現実的な選択肢です。複数の会議が同時に走る場合は、同時接続数×帯域で合算して見積もります。
QoS（Quality of Service）の
考え方
QoSとは、ネットワーク上で特定のトラフィック（ここではビデオ会議）を優先的に処理する仕組みです。帯域が十分でも、QoS未設定だと映像・音声が途切れることがあります。
QoSで押さえる3つのポイント
- 会議トラフィックの優先設定：DSCP値（Differentiated Services Code Point）で会議パケットを識別し、優先度を付与します
- 混雑する時間帯の品質を想定：ネットワーク負荷がピークになる時間帯に、会議品質が維持できるか。負荷テストはPoCで確認するのが確実です
- 拠点間のボトルネック特定：WAN回線（拠点間）の帯域が細い場合、QoSだけでは解決しません。回線増強か、解像度の調整（HD→SD）で対応します
QoS設計のチェックリスト
- ビデオ会議のDSCP値を決めているか
- ルーター/スイッチでQoSポリシーを設定済みか
- 拠点間WAN回線の帯域を把握しているか
- ピーク時間帯の帯域利用率を測定済みか
- VPNを経由する場合、QoSが維持されるか確認済みか
- 同時接続数のピーク想定と帯域の合算を計算しているか
ファイアウォール（FW）の
確認事項
相互接続では、ファイアウォールのポート開放が不足していると「設定は合っているのに接続できない」という事態になります。PoCの前に、以下を確認してください。
主要プロトコル別の通信要件
| プロトコル | シグナリング | メディア（映像/音声） | 備考 |
|---|---|---|---|
| H.323 | TCP 1720 | 動的ポート（RTP/RTCP） | 動的ポートの範囲をFWで許可する必要あり |
| SIP | UDP/TCP 5060（暗号化時5061） | RTPポート範囲 | TLS使用時は5061 |
| WebRTC | TCP 443（HTTPS） | UDP（TURN/STUN） | ブラウザ参加。443で通るケースが多い |
| Teams連携 | TCP 443 | UDP 3478-3481 | Microsoft 365の通信要件も確認が必要 |
NAT/DMZの確認ポイント
- Pexipサーバの配置場所（DMZ/内部LAN/クラウド）によって、NAT設定が変わります
- DMZ配置：外部・内部の双方から通信できるよう、FWルールを設計
- クラウド配置：端末からクラウドへの通信経路（直接 or VPN）を確認
- NATトラバーサル：端末が社内LAN、PexipがDMZ/クラウドの場合に必要。Pexip Infinityはビルトインのトラバーサル機能を持っています
ログ取得と監査対応
- 通信ログの保管：接続成功/失敗、品質データ（パケットロス、遅延）の記録は、障害切り分けだけでなく監査対応にも必要です
- 保管期間：統制が強い業界では、ログ保管期間をセキュリティポリシーに合わせて設計してください
- 閲覧権限：ログへのアクセス権を明確にし、エスカレーションフローと合わせて整備します
Pexipの分散アーキテクチャと
ネットワーク設計
Pexip Infinityは分散型アーキテクチャを採用しており、ネットワーク設計にも特有の考え方があります。
分散配置のメリット
| WAN帯域の削減 | 会議ノードを拠点に近い場所に配置することで、拠点間の通信量を減らせます。従来3Mbps×10拠点が必要だった構成を、分散配置で1.5Mbps×10拠点に削減した事例もあります |
|---|---|
| 遅延の低減 | 参加者に近いノードで映像・音声を処理するため、体感品質が向上します |
| 冗長化 | ノードが複数あるため、1台が停止しても他のノードで会議を継続可能です |
設計で注意する点
| 管理ノードとカンファレンスノードの分離 | 管理ノード（設定・管理用）とカンファレンスノード（会議処理用）を別サーバに配置するのが一般的です |
|---|---|
| ノード間通信 | ノード間のシグナリングに必要な帯域と通信要件を確認してください |
| クラウド/オンプレ混在 | ハイブリッド構成では、クラウドノードとオンプレノード間の通信経路設計が重要です |
よくある失敗と対策
失敗パターン1：帯域見積もりの誤り
- 症状：映像が止まる、音声が途切れる、接続が不安定
- 原因：「1拠点あたりの帯域」だけで見積もり、同時接続数を考慮していなかった
- 対策：同時接続数×解像度別帯域で合算する。PoCでは本番に近い時間帯にテストを行い、実環境での品質を確認する
失敗パターン2：FW設定の漏れ
- 症状：「シグナリングは通るがメディアが流れない」（映像/音声が出ない）
- 原因：シグナリングポート（TCP 1720 / 5060）は開けたが、RTP（メディア）の動的ポート範囲を開放していなかった
- 対策：シグナリングとメディアの両方のポートをセットで確認する。H.323は特に動的ポートの扱いに注意
失敗パターン3：VPN経由でのQoS喪失
- 症状：VPN経由の拠点だけ品質が悪い
- 原因：VPNトンネル内でDSCPタグが剥がされ、QoSが機能していなかった
- 対策：VPN機器のQoSパススルー設定を確認。VPN経由でQoSが維持できない場合は、会議トラフィックだけVPNを迂回させる（スプリットトンネル）も選択肢
失敗パターン4：NAT環境での片通話
- 症状：片方向の映像/音声しか流れない
- 原因：NATの変換でRTPパケットの戻り経路が確保できていなかった
- 対策：Pexip InfinityのNATトラバーサル機能を有効化する。DMZ配置の場合はFWのステートフルインスペクション設定も確認
よくあるご質問
帯域が足りない拠点がある場合、どうすればいいですか?
- 3つの選択肢があります。(1) 解像度をSD（480p）に落として帯域を抑える、(2) 回線を増強する、(3) Pexipの分散配置で拠点近くにノードを置き、WAN帯域を削減する。PoCの段階で各拠点の帯域を実測し、最適な組み合わせを設計するのがお勧めです。
QoSの設定は必須ですか?
- 必須ではありませんが、推奨します。帯域に余裕がある環境でも、バックアップやファイル転送と会議トラフィックが競合すると品質が落ちます。特に拠点間WAN回線が細い場合や、同時接続数が多い場合は、QoS設定が品質安定の鍵になります。
ファイアウォールのポート開放は、セキュリティ上のリスクになりませんか?
- 必要最小限のポートを、必要な通信先に限定して開放するのが基本です。Pexipの通信要件は事前に明確に定義できるため、FWルールを「全開」にする必要はありません。また、通信ログの取得と監視を合わせて設計することで、セキュリティリスクを管理できます。
その他の技術・要件ページ
PoC前のネットワーク確認、一緒に進めませんか？
帯域・QoS・ファイアウォール設定の確認事項を整理するところからお手伝いします。何から確認すればいいか分からない段階でもどうぞ。
