WebRTCとは、「Web Real-Time Communication」の略称で、APIを経由して、ウェブブラウザやモバイルアプリでリアルタイム通信を実現する技術のこと。WebRTCのプロジェクトに参画しているのは、Apple、Google、Microsoftなど名だたるIT企業ばかりです。
実運用では端末間のP2Pに加え、シグナリングサーバーや STUN/TURN/SFU などのwebrtc サーバー群を組み合わせて、接続確立・NAT越え・多拠点配信を安定させます。
対応しているブラウザは、PCでは、Google Chrome、Microsoft Edge、Mozilla Firefox、Safari、Operaになります。多くの人が日常的に使っている主要なブラウザでは、ほぼ対応していると言ってよいでしょう。
またスマートフォンなどモバイル環境で使用するOSでは、AndroidはGoogle Chrome、Mozilla Firefox、Opera Mobile、iOSはSafariです。
WebRTCは様々なシーンで利用されています。例えば、Web会議、Web面接、オンライン営業などのビジネスシーンではもちろん、オンライン教育、ボイスチャット、オンラインクレーンゲームなどでもWebRTCの仕組みが利用されています。
また、遠隔医療（オンライン診療）、オンラインフィットネス、IoT映像配信、VRライブ配信などにもその活用が広がってきています。
WebRTCは、様々なサーバーなどを組み合わせ、利用できるようにしています。
その1つに「シグナリングサーバー」があります。シグナリングサーバーは「通信相手に関する情報を得る」のが役割で、WebRTCにおいて欠かせないサーバーです。
そもそも相手とやり取りをしようにも、相手が誰でどこにいるのか判別できなければ、やりようがありません。そこで、シグナリングサーバーは相手のユーザー名を伝えることで、その他通信に必要な情報を収拾できるようにしているのです。
WebRTCシグナリングでは、SDP（コーデック/ビットレート等）と ICE 候補を WSS/HTTPS 経由で安全に交換します。扱うのは「誰と、どう繋ぐか」というメタ情報で、シグナリングサーバー自体はメディアを中継しません。認証（短命トークン）やルーム権限、再接続戦略、接続ログ収集などの運用機能を揃えると信頼性が大きく向上します。
WebRTCを理解するうえで、とても重要な概念があります。それが「P2P」です。P2PはPeer to Peerの略になります。P2Pの基本的な概念は「サーバーを介さず、端末同士が直接通信できるようにする」というものです。
とはいえ、WebRTCの接続確立にはシグナリングサーバーや STUN/TURN が必要です。1対1や少人数はP2Pで十分な場面が多い一方、参加者が増える会議・配信では SFU といったWebRTCサーバーを用いて帯域と端末負荷を最適化するのが実務的です。
"P2Pのような"やり取りを実現するために、必要となるのはシグナリングサーバーだけではありません。その他にも「STUNサーバー」や「TURNサーバー」などを利用します。
なぜ、これらのサーバーが必要となるのか。その理由は「NAT(=Network Address Translation)」の存在があります。
NATは、ネットワークアドレスを変換する機能です。
例えば、自宅でWi-Fiをつないだ際、端末にグローバルIPアドレスが付与されていないケースがあります。これは、プロバイダーから割り振られるIPアドレスが一つのため、複数の端末がインターネットに接続できるよう、ルーターがIPをLANの端末へ振り分けているためです。
そのため、端末で表示されるIPアドレスがグローバルIPアドレスと異なることがあります。しかし、これでは情報を送りたい側は困ってしまいます。なぜなら、通信したい先の本当のIPアドレスが変換されているため、わからないからです。
そこで、NATによって変換されたアドレスをセキュアに関連づける「NAT越え」が必要となります。その際に必要となるのが、STUNサーバーとTURNサーバーです。
STUNサーバーは外部ネットワークから見た際の自身のIPアドレスを教えてくれます。そのアドレスと自身のPCのアドレスを比較してNAT越えが必要かを判断します。
経路選定は ICE（Interactive Connectivity Establishment） で行われ、端末はhost/srflx/relayなど複数候補を提示して最適経路を自動確立します。企業ネットワークやキャリア網では UDP/任意ポート制限 があり、STUNだけでは成立しないことも多いため、TURN の準備を早期から検討しましょう。
STUNサーバーを使えば、NAT超えが必要かどうかがわかります。実際に企業で導入しているネットワークにはNAT越えが必要な場合が多く、且つ、Firewallを超える必要もでてきます。
Firewallは、ほとんどのパソコンに組み込まれた基本的なセキュリティ対策の1つです。特に、企業においては、サイバー攻撃などのリスクを防ぐため、ポート制御やウイルス感染を防ぐ役割を担います。
しかし、Firewallをセキュアに超えられる仕組みがなければ、ビジネスシーンでP2Pのような通信ができません。そこで、考えられたのが「TURNサーバー」です。
TURNサーバーは、もともとVoIPやオンラインゲームで使用されていた仕組みです。TURNサーバーでは、通信の際に発生するストリームデータの受け渡しをするブリッジの役割を担います。
TURNは、NAT環境下で端末間の直接接続が難しいときに、中継サーバーが介在してメディア通信を成立させるためのプロトコルです。TURNはメディアを中継（relay）して厳しいNAT/Firewall環境でも接続を成立させます。実装時は TLS と短命資格情報（TTL付き）、そして 接続成功率・RTT・再送率 などのモニタリングをセットで整えると、ユーザーは仕組みを意識せずに安定して使えます。
SFU(Selective Forwarding Unit)サーバーは、音声や映像をP2Pではなく、サーバー経由で行う技術です。配信者が直接相手に通信するのではなく、サーバーを間に挟むことで、動画の視聴者増加などによる、端末への負荷軽減を可能にします。これにより、リアルタイムで多くの視聴者に音声や動画を配信できます。
現代では、多拠点に同時に動画を届ける必要があります。YouTubeなどの動画サイトでもライブ配信が行われ、大量のユーザーが同時に視聴するケースが多々あります。
このような処理を行うには、一般ユーザーが使用する端末では不可能です。よりハイスペックで、大量の同時接続にも耐えうるような強力なサーバーが求められ、その傾向は今後もさらに続くでしょう。
多拠点同時配信を行う技術として、MCU（Multipoint Control Unit）があります。MCUは、SFUで用いるサーバーよりさらにハイスペックなマシンを用いて、音声や映像を合成したり、回線が細いユーザーに対してはビットレートを落として映像を送るなどができます。
しかしその分、処理の負荷がかかり、特にCPUのコア数が必要です。
運用の目安は 1対1/少人数＝P2P、5〜20人規模＝SFU、合成や録画要件＝MCU。特に SFUは選択転送で上り帯域を節約でき、Simulcast/SVC による適応配信も取り入れやすいことから、WebRTCサーバーの中でも汎用的に採用されています。
SFUやMCUよりもさらに多くの拠点と接続できる仕組みとして、「仮想広域ネットワーク」を使ったサービスも存在します。
例えば、ライブ配信・ビデオ通話・音声通話API/SDKのAgoraは、HLSやFlashを使用せず、独自のプロトコルで超低遅延を実現。世界中のデータセンターにノードを構築し、自動で最適な経路を選択するアルゴリズムを備えています。世界中のデータセンターを介した最適ルーティングを実現し、サブ秒レベル（約300 ms）～最大でも1秒程度という超低遅延通信を可能にしています。
またWebRTCとも互換性を持ち、SFU型よりさらに規模が大きい通話などにも対応。P2Pより安定した通信を実現しています。
1〜3、4名を目安とします（5名は端末性能や映像ビットレート次第）。クライアント⇄シグナリング＋STUNで接続し、必要に応じてTURNを利用します。企業ネットワークでは常時TURN経由となる場合があります。遅延とコストは最小化できますが、CPUと上り帯域は参加人数に比例して増加する点に注意が必要です。
クライアント⇄シグナリング＋STUN/TURN⇄SFU。Simulcast/SVCで端末負荷と回線を最適化。録画や権限管理をサーバー側に集約。
クライアント⇄シグナリング＋STUN／TURN⇄SFUで構成します。Simulcast／SVCを用いて端末負荷と回線を最適化します。録画や権限管理はサーバー側に集約します。
地理的に近いノードへ自動ルーティングし、障害時は最短経路へ迂回します。国・地域ごとのデータ取り扱いと録画保存域も明示します。
上記の通り、WebRTCを利用したシステムを自社開発するには、様々なサーバーの構築・管理が必要です。しかし、最近ではSDKを使って自社開発を極力少なくすることができます。
また、自前運用は、ピーク時のスケール対応・国際間の遅延対策・監視（getStats／接続成功率の見える化）・SLA対応までコストがかさみます。SDK／クラウドなら、WebRTCシグナリングから多拠点配信までを短期間で立ち上げ、プロダクトの体験改善に集中できます。
とはいえ、SDKにも様々な種類があり、選ぶのに迷うケースもあるでしょう。その際は、WebRTCの商用サービスについてまとめた記事がありますので、こちらをご覧ください。
STUNはクライアントのパブリックIP/ポートを教える仕組みで、P2P接続を助けます。TURNはメディアをサーバー経由で中継し、P2Pが通らない環境でも接続を保証します。
企業ネットワークやキャリア網などで厳しいNAT/Firewallがある場合や、接続率を保証したい時はTURNを用意します。
SFUはメディアを混合せずに転送するため、MCUより低遅延でスケールしやすい一方、中継分のわずかな遅延は加わります。
はい。オファー/アンサーやICE候補の交換に必要ですが、方式は規定されていないためWebSocketやHTTPなど任意の手段で実装できます。
クライアント↔シグナリング、STUN/TURN（必ずTURNを用意）、SFUを組み合わせ、用途に応じて録画・監視を追加します。
ここまで、WebRTCの基本的な仕組みからサーバーの構成までお伝えしました。
動画・音声サービスは今後さらに発展していくと予想されます。
単なる1:Nの配信だけでなく、参加型ライブ配信などに代表される双方向性の高い映像配信や、ウォッチパーティのような仲間同士で楽しめるサービス、また、パフォーマー側にもオーディエンスの気持ちが伝わる熱量可視化のサービスなど、オンラインならではの体験が加速しています。
また近年では、会話型AIを組み込んだリアルタイム通信の活用も進んでいます。
こうした新しいサービスを実現する際には、WebRTCの実装が重要な役割を果たします。その際は本記事を参考にしていただければ幸いです。