1. はじめに
ソーイ株式会社の西浦です。
弊社ではリアルタイム通信を強みとしており、実務で WebRTC（Web Real-Time Communication） を扱う機会が多くあります。
入社当初は「ブラウザ間でビデオ通話ができる技術」程度の認識でしたが、実際に触れてみると、接続を確立させるための手順や、多人数接続のためのサーバー構成など、独自の概念を理解するのに時間を要しました。
今回は、WebRTCの基礎的な仕組みと、実務で重要となる配信方式（P2P・SFU）の違いについて、自分なりに整理した内容をまとめます。
2. WebRTCとは：低遅延を実現する「直接通信」
WebRTCは、ブラウザ同士が中継サーバーを介さずに映像や音声を リアルタイムかつ直接 やり取りするための規格です。
普段私たちが利用しているHTTP通信（クライアント・サーバー方式）では、データは必ず「サーバー」を経由します。これに対し、WebRTCはブラウザ同士を最短距離で結ぶ P2P（Peer-to-Peer） 通信を行います。中継による「寄り道」を排除することで、ビデオ会議などで求められる「サクサクとした双方向のやり取り」が可能になります。
3. なぜ「直接繋ぐ」のが難しいのか：3つの準備
「直接繋ぐ」という構造を実現するには、現実のインターネット環境（ファイアウォールやルーターの存在）を突破するための複雑な準備が必要です。
-
シグナリング（Signaling）：
P2P通信を開始する前に、まず相手がどこにいるか（IPアドレス）や、通信の意思を伝える必要があります。この「お見合い」はWebRTCの規格外で行う必要があり、通常はサーバー（シグナリングサーバー）を介して行われます。 -
STUN/TURNサーバー（NAT超え）：
現代のネットワークはセキュリティ上、外部から直接中の端末にアクセスできません。そこで、自身の「外向きの住所」を特定する STUNサーバー や、どうしても直接繋げない場合にデータを中継する TURNサーバー を使い、接続経路を確保します。 -
SDP（Session Description Protocol）：
「どんな映像形式を使うか」「解像度はどうするか」といった通信の条件をすり合わせる交渉プロセスです。
4. アーキテクチャの比較：P2P と SFU
WebRTCには、データの配り方（アーキテクチャ）として大きく2つの方式があります。それぞれに長所と短所があり、要件に応じて適切に選択することが重要です。
P2P (Mesh) 方式：端末同士が直接データを送り合う
1対1の通信や、少人数のやり取りに特化した方式です。
-
メリット：
- 低コスト：メディアデータを中継するサーバーが不要なため、インフラ費用を大幅に抑えられる。
- 最小限の遅延：端末間を最短距離で結ぶため、理論上最も遅延が少ない。
-
デメリット：
- 端末の負荷が高い：接続人数が増えるほど、各端末が全員分のデータを送り出す必要があり、CPUや帯域を激しく消耗する。
- 実例：Amazon Kinesis Video Streams (KVS) WebRTC など
SFU (Selective Forwarding Unit) 方式：サーバーがデータを中継・複製する
大人数でのビデオ会議など、スケーラビリティが求められる場面で採用される方式です。
-
メリット：
- 端末の負荷が低い：端末はサーバーに映像を1本送るだけで済むため、参加人数が増えても端末側の負荷を一定に保てる。
-
デメリット：
- インフラコストが発生：サーバー側でメディアデータの転送処理を行うため、データ量に応じたサーバー費用がかかる。
- わずかな遅延の増加：サーバーを経由する分、P2Pに比べるとわずかな遅延（レイテンシ）が生じる。
- 実例：Amazon Chime SDK など
5. WebRTCの接続シーケンス
これら一連の動きを時系列で整理すると、以下のようになります。
6. まとめ
WebRTCの仕組みを整理して感じたのは、「直接通信という自由な結果を実現するために、その裏側ではサーバーを介した厳密な準備（シグナリングや経路確保）が行われている」 という点でした。
実務においては、1対1に適した P2P（Amazon KVS等） と、大人数でも安定する SFU（Amazon Chime SDK等） の使い分けが基本となります。
この「データの配り方」の理屈が分かってきたことで、ようやく実務の設計意図が少しずつ見えてきました。まだまだ奥が深い領域なので、これからもさらに深く理解していけるよう、学習を続けていきたいと思います。
お知らせ
技術ブログを週1〜2本更新中、ソーイをフォローして最新記事をチェック！