先に要点
- WebRTC は `ブラウザ間 / アプリ間で映像・音声・任意データをやり取りするための Web 標準』。Zoom / Google Meet / Discord などのリアルタイム通信の裏側で広く使われている。
- 核となる API は ` getUserMedia(カメラ / マイク取得)』 `RTCPeerConnection(P2P 接続)』 `RTCDataChannel(任意データ送受信)』 の3つ。`ブラウザだけで P2P 通信ができる』 のが他にない強み。
- P2P は理想だが、現実には NAT 越え が必要。` STUN(IP を教えるサーバ)』 `TURN(P2P 失敗時の中継サーバ)』 `シグナリング(接続情報の交換)』 の3つを別途用意する必要がある。
- 規模が大きくなると P2P では限界が来るため、` SFU(Selective Forwarding Unit)』 という中継サーバを挟むのが現実解。3人以上のビデオ会議は事実上 SFU 前提と思っていい。
WebRTC ってよく聞くけど、結局どうやって動いてるの？ Zoom / Meet とは何が違うの？ 自分で簡単なビデオチャットを作れる？』 ── 2010年代から少しずつ広まった WebRTC は、ブラウザだけでビデオ通話ができる』 という画期的な仕組みとして、現代のリアルタイム通信の標準基盤になりました。
ざっくり言うと、WebRTC は ブラウザ同士を直接(可能なら P2P で)つなぎ、映像・音声・データを送受信するための Web 標準技術』</strong> です。サーバを経由せず、ブラウザ同士で直接通信できる』 のが画期的で、Zoom / Google Meet / Discord / Twitter Spaces / Microsoft Teams など、ほぼすべてのリアルタイム通信プロダクトが内部で使っています。
この記事では、2026年5月時点の WebRTC をベースに、仕組み・主要 API・STUN/TURN/シグナリング/SFU・採用判断軸 を整理します。 仕様詳細は 公式 や MDN を参照してください。
WebRTC で何ができるのか
3つのできることを押さえると、全体像が掴めます。
①映像 / 音声の送受信
カメラ / マイクから取った映像 / 音声を、別のブラウザにリアルタイムで送る。`ビデオ通話』 `ライブ配信』 `音声会話』 などの基盤。
② 任意データの P2P 送受信
テキスト・JSON・バイナリを `RTCDataChannel』 で直接送れる。`ゲームのリアルタイム同期』 `ファイル共有』 `共同編集』 などに使える。
③ 画面共有
`getDisplayMedia』 で画面 / ウィンドウを取得して送信。リモートワーク / プレゼン / ペアプロのデファクト基盤。
直接通信の強み
`サーバを経由しない』 → 低遅延、サーバコスト最小、プライバシー確保。`配信元と受け取り側だけが内容を知る』 という構造を組める。
普通の Web 通信は HTTP/WebSocket でサーバ経由が前提』 という世界に、直接通信』 という選択肢を加えるのが WebRTC、と捉えると分かりやすいです。
3つのコア API
WebRTC は数多くの API を持ちますが、コアになるのは3つです。
① `getUserMedia』 — メディア取得
const stream = await navigator.mediaDevices.getUserMedia({
video: true,
audio: true,
});
videoElement.srcObject = stream;
`カメラとマイクを使う許可を求めて、MediaStream を受け取る』 API。ブラウザの権限プロンプトが出るのはここです。
② `RTCPeerConnection』 — P2P 接続の確立
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
});
stream.getTracks().forEach(track => pc.addTrack(track, stream));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// offer を相手に送信(シグナリング)
相手のブラウザと P2P 接続を確立する』 中心 API。offer / answer の交換』 `ICE 候補の交換』 など、ここで全てが起きます。
③ `RTCDataChannel』 — 任意データ送受信
const channel = pc.createDataChannel('chat');
channel.onopen = () => channel.send('hello!');
channel.onmessage = e => console.log('received:', e.data);
P2P 接続の上で任意データを双方向に流す』 API。映像 / 音声以外のデータをサーバ経由なしで送りたい』 ときの選択肢。
なぜ Offer / Answer を交換するのか
P2P 接続を始めるには、`相手の IP / ポート / 暗号化情報 / メディア仕様』 が必要。`SDP(Session Description Protocol)』 という文字列を交換して合意する。
ICE 候補とは
` どの IP : ポートで通信を待ち受けているか』 の候補リスト。複数の候補から最適なものを選んで P2P 接続を試す。NAT 越えの工夫はここで起きる。
暗号化は標準
WebRTC の通信は ` DTLS-SRTP』 で暗号化されるのが必須。`平文の WebRTC』 は存在しない。盗聴対策はプロトコル側で組み込み済み。
ライブラリ選択
生 API を使う必要は基本ない。` simple-peer』 `peerjs』 `livekit-client』 `mediasoup-client』 などのライブラリを使うのが現実的。
生 API は書くと辛い』 が、仕組みを理解する』 ためには知っておく価値があります。
STUN / TURN / シグナリング — 縁の下の力持ち
P2P は理想ですが、現実のインターネットは NAT(Network Address Translation) や ファイアウォール越しの通信が必要で、`そのままでは P2P できない』 のが普通です。 これを解決するのが STUN / TURN / シグナリング という別の仕組みです。
シグナリングサーバ
` Offer / Answer / ICE 候補を相手に届ける』 ための中継。WebRTC 標準には含まれず、自前で WebSocket / HTTP などで実装する必要がある。`誰と誰がつながるか』 を決める部分。
STUN サーバ
` 自分のグローバル IP を教えてくれる』 サーバ。`192.168.1.x』 のような LAN 内 IP しか知らない状態から、`このルーター越しでは XX.XX.XX.XX に見えますよ』 と教える。Google が無料 STUN(`stun.l.google.com』)を運営している。
TURN サーバ
` P2P がどうしても確立できないときの中継』 サーバ。`Symmetric NAT』 や厳しいファイアウォールがあるとき、最後の手段として使う。運用コストが大きい(全データが TURN を経由する)ため、自前で立てる場合は注意。
割合
` 多くの環境では STUN だけで P2P が成立する』 が、`数% のユーザーは TURN にフォールバック』 が必要。`TURN を用意していないと、一部ユーザーで通話できない』 という落とし穴。
P2P と言いつつ、補助サーバが必要』 というのは初学者がよく面食らうポイントです。 これは WebRTC の仕様というより、現代のインターネットが NAT だらけ』 という現実の制約に由来します(グローバル IP とプライベート IP のあたりが背景です)。
P2P の限界と SFU / MCU
1対1』 なら P2P で十分ですが、3人以上のビデオ会議』 になると、P2P は急速に厳しくなります。
P2P の限界
5人会議なら `各人が 4人分の映像を送って 4人分の映像を受け取る』 → ` 帯域とCPUが指数関数的に増える』。10人を超えると個人 PC では成立しなくなる。
SFU(Selective Forwarding Unit)
` 中央に中継サーバを置き、各クライアントは1本だけ送って、サーバが必要な人に振り分ける』 方式。`各人の負荷は 1人分送って N人分受け取る』 で済む。Zoom / Meet / Teams の基本構造。
MCU(Multipoint Control Unit)
` 中央サーバで複数映像をミックスして1本の映像として返す』 方式。`受信側の負荷は最小』 だがサーバ側の負荷が大きい。リアルタイム性が落ちる。実装はあまり見ない。
代表的な SFU 実装
mediasoup / Jitsi / Janus / LiveKit / Pion(Go 製)など。`自前で組む』 のは大変なので、`LiveKit / Daily / Twilio Video のようなマネージドサービスを使う』 のが現実的な選択肢。
Web ブラウザの WebRTC』 と バックエンドの SFU』 を組み合わせるのが、現代の本格的なリアルタイム通信アプリの典型構成です。
採用判断のチェックリスト
`WebRTC を使うか別の選択肢にするか』 の判断軸を整理します。
WebRTC を直接書く』 ことは少なく、WebRTC の上に乗ったライブラリ / サービスを使う』 のが2026年現在の現実的な選択肢です。
どこで詰まりやすいか
実務で踏みやすい注意点も整理します。
①NAT 越え
`STUN だけでつながらない環境』 が一定割合で必ず存在する。TURN を用意せずに本番投入 → `一部ユーザーで繋がらない』 クレーム がほぼ確実。マネージドサービスを使えばここはカバーされる。
② 帯域とCPU
映像エンコード / デコードは負荷が大きい。`低スペック端末で 4 人会議を全員 HD で』 のような無理な構成は、`PCが熱くなる』 `音声が途切れる』 系の問題を起こす。`動的解像度切替』 を SFU 側でサポートしている実装を選ぶのが安心。
③ ブラウザ間差異
` Safari / iOS Safari の WebRTC 挙動差』 が地味に大きい。コーデック対応(VP8 / H.264 / VP9 / AV1)、自動再生制限、画面共有制限など、`主要 OS / ブラウザで実機テスト』 が必須。
④ シグナリングの自前実装
` WebSocket でシグナリング』 を自前で組むときに、`部屋管理』 `再接続』 `タイムアウト』 などの設計を一から考える必要がある。`既存ライブラリの設計』 を参考にする / 既製品を使うほうが安全。
WebRTC を書く』 仕事は、Web の通常スタックでは普通やらない領域(NAT、コーデック、帯域制御)』 に触る必要があるので、`小規模に試して、本格化するときは専門サービスに乗り換える』 のが安全策です。
AI 時代の WebRTC
AI 連携の文脈でも WebRTC は重要な役割を担います。
AI 音声アシスタント
` OpenAI Realtime API』 `Anthropic の音声モデル』 などの音声 AI と統合する際、ブラウザ側は WebRTC を使うことが多い。`音声を低遅延で送って AI 応答を音声で返す』 ユースケース。
AI 文字起こし / 翻訳
WebRTC で取得した音声を AI に流して、リアルタイムで字幕表示 / 翻訳を返す。`Zoom の AI 機能』 系のサービスはこの構造。
アバター AI
` 音声を AI に投げる + AI が応答 + アバターが喋る』 を WebRTC ベースで組む。`AI Tutor』 `AI コーチ』 系のアプリで増えている構成。
低遅延が AI 体験を決める
`AI 応答が3秒遅れる』 と会話として成立しない。WebRTC + Edge AI の組み合わせで、`できるだけ近い場所で AI 推論』 をする設計が増えている。
音声を扱う AI プロダクト』 が増える中で、WebRTC は ブラウザと AI をつなぐ低遅延パイプ』 として、これまで以上に重要な技術になりつつあります。
WebRTC に関するよくある質問
Q. WebSocket と WebRTC、どちらを使うべきですか？
A. 用途で分けます。` テキスト / JSON のやり取りなら WebSocket、映像 / 音声 / 低遅延データなら WebRTC』。WebSocket はサーバ経由が前提で実装がシンプル、WebRTC は P2P 可能だが NAT / シグナリングなど周辺要素が複雑、というトレードオフです。
Q. WebRTC で完全に P2P なら、サーバは不要ですか？
A. シグナリングサーバは必須』</strong>です。誰と誰が繋ぐか』 を決める部分は標準化されていないため、自前で WebSocket / HTTP サーバを立てる必要があります。通信本体はサーバ不要』 と シグナリングはサーバ必要』 は別物です。
Q. Zoom や Google Meet は WebRTC を使っていますか？
A. ` Google Meet は WebRTC をフル活用、Zoom はカスタム実装ベースだが Web 版では WebRTC を使う』です。多くのリアルタイム通信プロダクトが内部で WebRTC のサブセット / 派生を使っています。
Q. 1対1 通話を自前で作るのは難しいですか？
A. MVP 程度なら可能、本番品質は思った以上に大変』</strong>です。音質 / 映像品質 / 接続安定性 / モバイル対応 / 再接続 / 帯域制御』 を真面目に作ると、ライブラリ / SaaS を使うのと比べて時間あたりの価値が大きく劣ることが多いです。
Q. LiveKit / Daily / Twilio Video のどれを選べばいいですか？
A. 無料枠 / コスト重視なら LiveKit(セルフホスト可)』</strong>、<strong> 統合が早い / ドキュメントが整っているなら Daily』、 エンタープライズ実績重視なら Twilio』</strong> という棲み分けです。規模が大きくなれば自前 SFU(mediasoup / Pion)を検討』 も視野に入ります。
Q. WebRTC の通信は安全ですか？
A. DTLS-SRTP で経路は必ず暗号化』</strong>されます。ただし、SFU を経由する場合、サーバで一度復号 → 再暗号化されるので、完全な E2E 暗号化』 ではないことに注意。`E2E が必要』 な案件は、SFU が中身を見ない設計(LiveKit の Insertable Streams / Signal 方式)を選ぶ必要があります。
Q. WebRTC を学ぶ最短ルートは？
A. ① ブラウザだけの 1対1 ビデオ通話サンプル(simple-peer』 や MDN のサンプル)を動かす、② シグナリングサーバを WebSocket で書いてみる、③ STUN / TURN を理解する、④ SFU(LiveKit など)を試す、の4段階が王道です。まず動かして、必要が出てきたら深掘り』 が現実的です。