拠点間のテレビ会議は、2〜3拠点のうちは、たいてい何の問題も起きません。端末を置いて、つないで、終わり。ところが拠点が5つ、6つと増えたあたりで、急に話が変わります。映像がカクつく。音が遅れる。ある拠点をつなぐと別の拠点が落ちる。
この「拠点が増えると会議体験が不安定になってしまう」現象の正体が、本記事のテーマである多地点接続装置（MCU・SFU）の有無です。数地点での接続のうちは要らないのに、ある規模を超えると突然必要になる。しかもその選び方は「MCU」「SFU」「多地点接続サーバー」と、聞き慣れない言葉が飛び交って分かりにくい。
この記事では、まず「なぜ拠点が増えると専用の装置が要るのか」を説明し、MCUとSFUの違い、オンプレミス型とクラウド型の選び方、調達で外さないためのチェックリスト、そして代表的な製品までを順に整理します。
この記事の要点
- 多地点接続装置が必要になるのは、おおむね5拠点以上の多地点会議。4拠点までは端末同士の直接接続で足りることが多い。
- 方式は大きくMCU（サーバーで合成して返す）とSFU（サーバーで選んで配る）の2つ。相互接続を重視するならMCU、拡張性とコスト効率ならSFUが向く。
- 映像を社外に出せない組織（官公庁・金融・医療）では、オンプレミス型が選ばれている。
- 製品は方式だけで決まらない。「誰が構築・運用するのか」が、実は最大の分かれ目になる。
多地点接続装置(MCU・SFU)とは｜「5拠点目の壁」を越えるための装置
数拠点の接続なら要らない。拠点が増えると、端末だけでは支えきれなくなり、間に立つ装置が必要になる。
多地点接続装置とは、ひとことで言えば、複数の拠点の映像・音声を1つの会議としてまとめるための、間に立つサーバーです。英語では MCU（Multipoint Control Unit）と呼ばれ、近年は SFU（Selective Forwarding Unit）という方式も広く使われます。製品によっては「多地点接続サーバー」とも表記されます。
なぜこんな装置が要るのか。それを理解するには、装置がない場合に何が起きるかを見るのが早道です。
装置を使わない「メッシュ接続」は、なぜ少人数までしか持たないのか
サーバーを使わず、端末同士が直接つながり合う方式をメッシュ（フルメッシュ／P2P）と呼びます。各拠点が、自分の映像を相手全員へ直接送り、相手全員から直接受け取ります。
シンプルで、サーバーが要らず、経路上で映像を加工しないので遅延も小さい。少人数の臨時会議には、むしろこれが一番手軽です。
問題は、拠点が増えたときの負荷です。メッシュでは「各端末が自分の映像を（参加拠点数−1）か所へ個別に送り、（参加拠点数−1）か所ぶんを個別に受け取って描画」する必要があります。つまり拠点が1つ増えるたびに、すべての端末の負担が積み上がっていきます。
1拠点あたりの映像を1Mbpsとして、ざっくり試算するとこうなります。
- 4拠点：各端末が3か所へ送るため、上り側におよそ3Mbpsが必要。一般的な回線でも、ここまではどうにか持ちます。
- 5拠点：各端末が4本の接続を抱え、上下それぞれ約4Mbps。全体では10本の接続が走ります。
- 15拠点：全体でおよそ210Mbps。これはもう、現実的な数字ではありません。
メッシュが実用に耐えるのは概ね2〜4拠点までで、それを超えると映像品質が不安定になります。そこで、5拠点目あたりを境に、各端末の負担を一定に抑えてくれる「間の装置」＝多地点接続装置が必要になります。次の章で、その必要ラインをもう少し具体的に見ていきます。
どんなときに多地点接続装置が必要になるか｜目安は5拠点以上
4拠点までは端末だけで足りることが多い。5拠点を超えると、端末の帯域とCPUが追いつかなくなる。
4拠点までは端末同士の直接接続で足りることが多い
本社と支社2つ、工場1つ——といった4拠点程度までの会議なら、多くのケースでメッシュ接続のまま運用できます。専用のサーバーを置かずに済むぶん、構成もシンプルで、コストもかかりません。
「うちは当面、多くても4拠点まで」という場合は、無理に大がかりな多地点接続サーバーを導入する必要はない、というのが正直なところです。
5拠点を超えると、各端末の帯域とCPUが悲鳴を上げる
前章で見たとおり、メッシュは拠点数が増えると各端末の負荷がふくらみます。5拠点を超えるあたりから、上り帯域の不足、端末CPUの処理落ち、それに伴う映像の乱れや音ズレが目立ち始めます。
ここを境に、端末の上り送信を「1本」に固定してくれるサーバー方式（MCU／SFU）へ切り替えることで、拠点数が増えても各拠点の負担を現実的な範囲に収められるようになります。これが「5拠点以上で多地点接続装置」と言われる理由です。
なお「5拠点」はあくまで目安です。実際のラインは、端末の性能・回線の太さ・映像の解像度・コーデックによって前後します。規格で決まった厳密な数字ではない、という点は押さえておいてください。
自分のケースで必要かを見分ける、3つの問い
- 同時につなぐ拠点は、いくつになりそうか。 5つ以上を恒常的につなぐなら、多地点接続装置を前提に考えるのが安全です。
- 今後、拠点は増える見込みか。 いま4拠点でも、来年8拠点になるなら、最初からサーバー方式を見据えておくと買い直しを避けられます。
- 古いテレビ会議専用機や、他社の会議システムともつなぐ必要があるか。 異なる機器をまたいで1つの会議にする用途では、後述するMCUの相互接続性が効いてきます。
MCUとSFUの違い｜「サーバーで作る」か「サーバーで配る」か
MCUはサーバーが映像を合成して1本にまとめて返す方式。SFUはサーバーが合成せず、必要な映像を選んでそのまま配る方式。
多地点接続装置には、大きく2つの方式があります。違いは「サーバーが映像に対して何をするか」です。
MCU＝サーバーが映像を合成して1本で返す（従来型・相互接続に強い）
MCU（Multipoint Control Unit）は、各拠点から届いた映像をサーバーがいったんすべて受け取り、1つの画面レイアウトに合成し直してから、各拠点へ「合成済みの1本」として送り返す方式です。
この方式の利点は、端末側がとにかく軽いこと。各端末は、合成された1本を受け取って表示するだけなので、拠点が何か所に増えても端末の負担はほぼ変わりません。回線の細い拠点や、性能の低い機器でも参加しやすい。さらに、サーバー側で映像を一度「正規化」するため、古いテレビ会議専用機や規格の異なる機器を、同じ会議に収容する相互接続（ゲートウェイ）に強いのも特長です。
弱点は、サーバー側の負荷とコストです。全拠点の映像を復号し、合成し、再び符号化し直す——この処理はサーバーのCPUを大きく消費します（SFUと比べて100〜300%重いとする解説もあります）。そのぶん大きなサーバーが必要になり、再エンコードを挟むため遅延もやや増えがちです。レイアウトをサーバー側で固定的に作るので、拠点ごとに「誰を大きく映すか」を自由に変えにくい、という制約もあります。
SFU＝サーバーは合成せず、選んで配る（効率的・拡張に強い）
SFU（Selective Forwarding Unit）は、各拠点が自分の映像をサーバーへ「上り1本」だけ送り、サーバーはそれを合成せず、必要な相手へストリームを選んでそのまま転送する方式です。
サーバーが映像を作り直さないぶん、サーバーの負荷が低く、拠点数や人数を増やしてもスケールさせやすい。コスト効率に優れ、5拠点以上の多くの用途でバランスが良いとされます。各端末が個別の映像を受け取るため、表示レイアウトを端末側で自由に組めるのも利点です。映像を書き換えないため、エンドツーエンド暗号化とも両立しやすく、合成処理がないぶん遅延も抑えやすい。
弱点は、端末側の下り負荷です。各端末は、見たい相手の数だけ映像を受信・描画する必要があるため、MCUよりは重くなります（メッシュよりは、はるかに軽い）。下り帯域も拠点数とともに増えます。また、サーバー側で1本に合成しないので、録画や外部配信のために映像を1本化したい場合は、別途その処理が必要になります。
一覧表：MCUとSFU、どちらが何に向くか
| 比較する軸 | MCU（合成して返す） | SFU（選んで配る） |
|---|---|---|
| サーバーの負荷 | 非常に高い（全映像を合成・再符号化） | 低〜中（転送するだけ） |
| 端末側の負荷 | 最小（1本を表示するだけ） | 中（下りは拠点数ぶん受信） |
| 端末側の帯域 | 拠点数によらずほぼ一定・最小 | 上りは一定、下りは拠点数で増える |
| 遅延 | やや増えやすい | 抑えやすい |
| 異種機器との相互接続 | 強い（既存TV会議・電話とつなぎやすい） | 別途ゲートウェイが必要なことが多い |
| 画面レイアウト | サーバー側で固定的に合成 | 端末側で自由に変えられる |
| 拡張性（多拠点・大人数） | サーバーがボトルネックになりやすい | 拡張しやすい |
| コスト傾向 | サーバーCPUコストが高くなりがち | 総じてコスト効率が良い |
| エンドツーエンド暗号化 | 両立しにくい | 両立しやすい |
結局どちらを選べばいいのか
ざっくり言えば、古いテレビ会議専用機や異なる機器をまたいで集約したい・端末を限界まで軽くしたいならMCU、拠点や人数の拡張性とコスト効率を重視するならSFU、という整理になります。
ただし、ここで強調しておきたいことがあります。実際の製品選びでは、「MCUかSFUか」という方式の名前そのものは、ユーザーが意識しなくてよい場面が増えています。 重要なのは方式の呼び名ではなく、「自社の拠点数・用途・セキュリティ要件に合うか」「導入と運用を誰が担うか」です。この点は、製品を見る段（後半）でもう一度触れます。
オンプレミス型 vs クラウド型｜映像を「どこに通すか」で選ぶ
手軽さならクラウド型。映像を社外に出せない・止められない事情があるならオンプレミス型。
多地点接続装置は、「どこに置くか」でも性格が変わります。大きくは、事業者のクラウド上にあるサービスを使うクラウド型と、自社のサーバーや閉域網の中に置くオンプレミス型に分かれます。
クラウド型：手軽だが、映像は社外を経由する
クラウド型は、事業者が用意したサーバーを使うため、自前でサーバーを構築・運用する必要がなく、すぐに始められるのが最大の利点です。多くの企業の一般的な会議には、これで十分に力を発揮します。
一方で、映像・音声は事業者のサーバーを経由します。「映像がどこを通り、どこに保存されるのか」を社内外に説明する必要がある組織や、機微な情報を扱う会議では、ここが論点になります。また、サービスの提供が続くかどうかは事業者次第、という事業継続上の依存も残ります。
オンプレミス型：自社・閉域網で完結し、外に出さない
オンプレミス型は、多地点接続のサーバーを自社のネットワーク（社内LAN・VPN・専用線などの閉域網）の中に置き、映像のやりとりをその中で完結させる方式です。
映像が外部のサーバーを経由しないため、情報漏えいや傍受のリスクを構造から小さくできるのが最大の強みです。インターネットの状況に左右されにくく、事業者のサービス終了によって自社の会議が止まる、という事態も避けやすい。そのぶん、サーバーの設置・運用を自社（または導入を支援するベンダー）が担う必要があります。
こういう組織が、オンプレミス型を選んでいる
実際にオンプレミス型が選ばれているのは、「映像を社外に出せない」「会議を止められない」事情を抱える組織です。具体的には——
- 中央省庁・自治体：閉域網やLGWAN（自治体専用の行政ネットワーク）の要件があり、住民の機微な情報を扱う。
- 金融機関：顧客情報・取引情報を扱い、外部経由を避けたい。
- 医療機関：患者情報を扱い、セキュリティ要件が厳しい。
- 警察・防衛・重要インフラ：そもそも外部ネットワークにつなげない領域がある。
こうした組織では、利便性よりも「映像をどこにも漏らさず、自分たちの管理下で完結させる」ことが優先されます。多地点接続装置をオンプレミス型で持つのは、その要件への、ごく自然な答えです。
失敗しない選定基準チェックリスト
方式（MCU／SFU）と置き場所（オンプレ／クラウド）の当たりがついたら、いよいよ具体的な製品を見る段階です。ここで、調達で「あとから困らない」ための確認項目をチェックリストにまとめました。RFP（調達仕様書）やベンダーへの質問票に、そのまま転用できる形にしています。
特に⑤の「EOL（提供終了）になったとき」は、見落とされがちですが重要です。次章で代表的な製品を見ていくと分かるように、長年使われてきた定番のMCU製品の中には、すでに提供終了の段階に入っているものもあります。新規に選ぶなら、まだ十分に提供が続く製品か、提供終了後の移行先まで描けているかを必ず確認してください。
代表的なMCU製品
ここからは、実際の製品を、方式ごとに見ていきます。まずは従来型のMCU製品から。いずれも自社設置（オンプレミス）で導入できる製品です。
Cisco Meeting Server（シスコ）
シスコが提供する、オンプレミス設置型の多地点会議サーバー（MCU）です。専用アプライアンスに加え、VMware上の仮想マシンや仕様準拠サーバーへのソフトウェア導入にも対応します。
最大の特長は、相互接続性とスケーラビリティの高さです。SIP/H.323のテレビ会議端末、Microsoft Teams、WebRTC対応ブラウザなどを1つの会議に収容でき、既存のシスコUC基盤（Unified Communications Manager／Expressway）を持つ大規模・高セキュリティ環境で力を発揮します。
一方で、シスコのコールコントロール基盤や専門的な構築・運用の知識を前提とする構成のため、小規模で手軽に1台だけ導入したい、という用途には過剰になりがちです。なお、ソフトウェアは現行で活発に開発が続いていますが、ハードウェアは世代交代が進んでおり（旧世代機の発注終了と後継機への移行が進行中）、導入時には現行プラットフォームの確認が必要です。
代表的なSFU製品
続いて、近年広く使われるSFU方式の製品です。ここで1つ、選定上大事なポイントが見えてきます。
Jitsi
WebRTCベースの、オープンソースの多地点会議基盤（SFU）です。Apache-2.0ライセンスのもと、自社サーバーへ無償でセルフホストできるのが大きな特長です。コストを抑えたい組織や、自分たちで作り込みたい開発者に支持されています。
箱から出してすぐ使える完成品というより、複数の部品（Jitsi Videobridge、Jicofo、Prosody など）を組み合わせて、ドメインや証明書の設定から日々の保守・アップデート・トラブル対応までを自前で担う、開発者・インフラ運用者向けの基盤です。保証付きの商用サポートが必要なら、別途マネージド版が用意されています。
製品選びの本当の分かれ目は、「方式」ではなく「誰が運用するか」
ここまで2つの製品を見てきて、気づかれた方もいるかもしれません。
MCUは、高機能だが大がかりで、専門知識を要し、定番製品の一部は提供終了が進む。SFUは、効率的で先進的だが、自社で構築・運用することが前提。
つまり、現実の製品選びでは、「MCUかSFUか」という方式の名前以上に、「導入と運用を、誰がどこまで担えるのか」が効いてきます。自社に開発・インフラの専任体制があり、作り込みの自由度が欲しいなら、Jitsiのような基盤型は強力な選択肢です。一方で、「方式の細かいことは抜きにして、設置すればすぐ会議が始められる、運用の手離れのよい完成品が欲しい」——そうしたニーズは、これらの基盤型では満たしきれません。
その「完成品」のニーズに応えるのが、次にご紹介するLoopGateです。
オンプレミス型テレビ会議システム「LoopGate」のご紹介
国産・オンプレミス対応のリモートコミュニケーションシステム
私たちRTCテックソリューションズが提供する LoopGate（ループゲート） は、まさにこの「運用の手離れのよいオンプレミス完成品」という考え方の製品です。現場はワンタッチで会議を始められ、テクニカルサポートも年末年始などを除きますと基本毎日つながりますので、情報システム部門・システムインテグレータも安心して導入することが可能です。
「うちは何拠点を、どのネットワークで、どうつなぎたいか」。そこを一緒に整理するところから、お手伝いできます。古くなったテレビ会議システムの更新（リプレイス）、5拠点以上の多地点会議の新規導入、閉域網・オンプレミスでの構築まで、現場に合わせてご提案します。多地点接続でお悩みでしたら、どうぞお気軽にご相談くださいませ。
よくある質問（FAQ）
Q. 何拠点から多地点接続装置（MCU・SFU）が必要になりますか？ A. 目安はおおむね5拠点以上です。4拠点までは、端末同士の直接接続（メッシュ）で足りることが多いのですが、5拠点を超えると各端末の帯域・CPU負荷が大きくなり、間に立つサーバー（MCU／SFU）が必要になります。ただし、端末の性能・回線・解像度によって前後する目安で、規格で定まった数字ではありません。
Q. MCUとSFU、結局どちらを選べばいいですか？ A. 古いテレビ会議専用機や異なる機器をまたいで集約したい・端末を限界まで軽くしたいならMCU、拠点や人数の拡張性とコスト効率を重視するならSFUが向きます。ただし実際の製品選びでは、方式の名前よりも「自社の要件に合うか」「導入と運用を誰が担うか」のほうが重要になります。完成品として方式を意識せず使える製品もあります。
Q. クラウド型ではだめなのですか？ A. だめではありません。手軽に始められ、一般的な会議には十分です。ただし映像は事業者のサーバーを経由するため、「映像を社外に出せない」「会議を止められない」事情がある組織（官公庁・金融・医療・閉域網など）では、自社・閉域網で完結するオンプレミス型が選ばれています。
Q. 拠点が今後増えても対応できますか？ A. サーバー方式（MCU／SFU）であれば、拠点の増加に対応できます。導入時に、現在の拠点数だけでなく数年後の見込みも伝え、拠点が増えたときのサーバー増強や追加費用がどうなるかを確認しておくと、買い直しを避けられます。
Q. 古いテレビ会議システムが使えなくなりそうです。多地点接続も含めて更新できますか？ A. できます。メーカーの提供終了（EOL）に伴う更新（リプレイス）は、いま多くの組織で進んでいる課題です。多地点接続のしくみも含めて、現行で提供が続く製品へまとめて移行するのが安全です。後継選びでお困りの場合は、ご相談ください。
