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本更新中、ソーイをフォローして最新記事をチェック！