先に要点
- 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 標準技術 です。 「サーバを経由せず、ブラウザ同士で直接通信できる」 のが画期的で、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. シグナリングサーバは必須です。「誰と誰が繋ぐか」 を決める部分は標準化されていないため、自前で WebSocket / HTTP サーバを立てる必要があります。「通信本体はサーバ不要」 と 「シグナリングはサーバ必要」 は別物です。
Q. Zoom や Google Meet は WebRTC を使っていますか？
A. Google Meet は WebRTC をフル活用、Zoom はカスタム実装ベースだが Web 版では WebRTC を使うです。多くのリアルタイム通信プロダクトが内部で WebRTC のサブセット / 派生を使っています。
Q. 1対1 通話を自前で作るのは難しいですか？
A. MVP 程度なら可能、本番品質は思った以上に大変です。「音質 / 映像品質 / 接続安定性 / モバイル対応 / 再接続 / 帯域制御」 を真面目に作ると、ライブラリ / SaaS を使うのと比べて時間あたりの価値が大きく劣ることが多いです。
Q. LiveKit / Daily / Twilio Video のどれを選べばいいですか？
A. 無料枠 / コスト重視なら LiveKit(セルフホスト可)、統合が早い / ドキュメントが整っているなら Daily、エンタープライズ実績重視なら Twilio という棲み分けです。「規模が大きくなれば自前 SFU(mediasoup / Pion)を検討」 も視野に入ります。
Q. WebRTC の通信は安全ですか？
A. DTLS-SRTP で経路は必ず暗号化されます。ただし、SFU を経由する場合、サーバで一度復号 → 再暗号化されるので、「完全な E2E 暗号化」 ではないことに注意。「E2E が必要」 な案件は、SFU が中身を見ない設計(LiveKit の Insertable Streams / Signal 方式)を選ぶ必要があります。
Q. WebRTC を学ぶ最短ルートは？
A. ① ブラウザだけの 1対1 ビデオ通話サンプル(「simple-peer」 や MDN のサンプル)を動かす、② シグナリングサーバを WebSocket で書いてみる、③ STUN / TURN を理解する、④ SFU(LiveKit など)を試す、の4段階が王道です。「まず動かして、必要が出てきたら深掘り」 が現実的です。