この記事の要点

WebRTC はブラウザやアプリ同士が、サーバを介さず直接 (P2P) 音声・映像・任意データをリアルタイムにやり取りする技術 メディアは UDP ベースで低遅延に送られ、暗号化された SRTP/DTLS で保護される NAT 越え (互いにプライベート IP の端末をつなぐ) のために STUN・TURN・ICE という仕組みを使う 通信相手を見つけて接続情報 (SDP) を交換する「シグナリング」は WebRTC の規格外で、WebSocket などで自前実装する ビデオ会議・音声通話・画面共有・P2P ファイル転送・クラウドゲームの低遅延配信などに使われる

概要

WebRTC (Web Real-Time Communication) は、ブラウザやアプリ同士が、間にサーバを挟まず直接 (P2P: ピアツーピア) 音声・映像・任意のデータをリアルタイムにやり取りするための技術です。プラグイン無しでブラウザ標準 API として使え、ビデオ会議や音声通話、画面共有などを Web 上で実現します。低遅延が命のメディア通信のため、配送には信頼性より速度を優先できる UDP を土台に使う点が特徴です。親セクションは Web通信プロトコル です。

仕組み

WebRTC の難しさの大半は「インターネット上の 2 台を、互いにプライベート IP (NAT の内側) のまま直接つなぐ」ことにあります。これを解決するために複数の要素が連携します。

• シグナリング: まず接続したい相手を見つけ、自分の接続情報 (SDP: 対応コーデックやネットワーク候補) を交換します。この「出会いの仲介」は WebRTC の規格外で、開発者が WebSocket などで自前実装します。
• STUN: 自分が NAT 越しにどのグローバル IP・ポートで見えているか (外から見た自分の住所) を教えてくれるサーバ。
• TURN: 直接 P2P が張れない厳しい NAT の場合に、通信を中継してくれるサーバ。最後の手段。
• ICE: STUN/TURN で集めた複数の接続候補を試し、実際につながる最良の経路を選び出す枠組み。

接続が確立したら、音声・映像は SRTP (暗号化された RTP) で、任意データは データチャネル で送られます。鍵交換と暗号化には DTLS が使われ、通信は常に暗号化されます。

実用例

ブラウザの WebRTC API は、カメラ/マイク取得・接続オブジェクト生成・SDP 交換という流れで使います。下記はカメラ映像を取得し、ピア接続を作る最小例です (シグナリングは WebSocket 経由を想定)。

// カメラ・マイクを取得
const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});

// ピア接続を作成 (STUN サーバを指定)
const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});

// 自分の映像を相手へ送るトラックとして追加
stream.getTracks().forEach((track) => pc.addTrack(track, stream));

// ICE 候補が見つかるたびシグナリング経由で相手へ送る
pc.onicecandidate = (e) => {
  if (e.candidate) signaling.send({ ice: e.candidate });
};

// 発信側: オファー (SDP) を作って相手へ送る
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signaling.send({ sdp: offer });

受信側は受け取ったオファーを setRemoteDescription し、アンサーを返します。両者が SDP と ICE 候補を交換し終えると、メディアが直接流れ始めます。

主な用途

• ビデオ会議・オンライン通話: ブラウザだけで多人数の音声・映像通信を行う。
• 画面共有・リモートサポート: デスクトップ映像を低遅延で相手に届ける。
• P2P ファイル転送: データチャネルでサーバを介さずファイルを直接送る。
• クラウドゲーム・ライブ配信: 超低遅延が要る映像配信の伝送路として使う。

他のリアルタイム手段との比較

技術	経路	土台	得意なデータ	遅延
WebRTC	P2P (必要時のみ中継)	UDP (SRTP/DTLS)	音声・映像・データ	最小
WebSocket	クライアント↔サーバ	TCP	テキスト・小さなデータ	小
HTTP/2 ストリーム	クライアント↔サーバ	TCP	要求-応答	中

注意点

• シグナリングは自前: WebRTC 自体は接続確立後の通信を担うだけで、相手探しと SDP/ICE 交換のサーバは別途用意する必要がある。
• TURN のコスト: 厳しい NAT 環境では P2P が張れず TURN 中継になり、サーバの帯域コストがかかる。完全な P2P を常に期待しない。
• 多人数で破綻しやすい: 純粋な P2P メッシュは参加者が増えると接続数・帯域が急増する。大規模会議は SFU/MCU といったメディアサーバを併用する。
• IP アドレスの露出: P2P の性質上、相手にグローバル IP が知られうる。プライバシー要件によっては TURN 経由を強制する設計にする。
• ブラウザ差・端末差: コーデックや実装の差で相互接続に注意が要る。対応コーデックのネゴシエーションを確認する。

関連リンク

• Web通信プロトコル
• WebSocket
• UDP
• HTTP/3(QUIC)
• プロトコル