業務でWebRTCを含め、Agora、SkyWay、Amazon Chime SDK等の実装検証をやってきたエンジニアです。
なお、WebRTCは単一技術ではなく仕様群です。本記事では「ブラウザ標準API（RTCPeerConnection）を利用した通信」を"WebRTCを使っている"と定義します。この点は社内でも議論になったため、あらかじめ定義を明確にしています。
同僚と話していて「ビデオ会議って全部WebRTCでしょ？」と言われることが結構あります。実はこれ、半分正解で半分間違いです。4大ビデオ会議サービスの通信プロトコルを調べてみたら、それぞれ全く違うアプローチを取っていて面白かったのでまとめます。
結論から
| サービス | メディアプロトコル | WebRTC利用 | アーキテクチャ |
|---|---|---|---|
| Google Meet | WebRTC（Webクライアント） | Webで最も標準に近い | SFU |
| Microsoft Teams | ICE/SRTP（WebRTC構成要素） | Web版:使用 / デスクトップ:独自実装 | クラウド集中型 |
| Zoom | 独自プロトコル → WebRTC移行中 | SDK限定（2024/12〜） | 独自メディアサーバー |
| Skype | 独自P2P → Azure集中型 | 未移行のまま終了 | （2025/5終了） |
「全部WebRTC」ではないどころか、Webクライアントにおいて最も標準WebRTCに近いのはGoogle Meetだけです。
Google Meet — WebRTCの「本家」
Google MeetがWebRTCをネイティブに使っているのは当然と言えば当然です。WebRTC自体がGoogleが2011年にオープンソース化した技術だからです。
なお、ここで言う「WebRTCネイティブ」は主にWebクライアントの話です。モバイルネイティブアプリはGoogle独自の最適化を含むメディアスタックを使っており、標準WebRTCそのものとは異なる部分もあります。
技術スタック
- シグナリング: SDP offer/answer（内部シグナリング基盤経由。Meet Media APIではREST経由でのSDP交換も可能）
- NAT越え: ICE（STUN/TURN）
- メディア暗号化: DTLS-SRTP
- 映像コーデック: VP8/VP9/AV1（AV1は段階的に展開中）
- 音声コーデック: Opus（WebRTC標準）
- データチャネル: SCTP（RFC 8831）
アーキテクチャ: SFU
グループ通話ではP2Pではなく、SFU（Selective Forwarding Unit）を使っています。SFUはサーバー側のWebRTCクライアントとして動作し、各参加者のストリームを必要なクライアントに選択的に転送します。
P2Pだと参加者が増えるたびに接続数がN×(N-1)で爆発しますが、SFUなら各参加者はサーバーとの1接続で済みます。100人規模の会議が成立するのはこの仕組みのおかげです。
Google公式のMeet Media APIドキュメントを見ると、SDP offer/answer、ICE candidates、DTLSハンドシェイクなど、WebRTCの標準的なフローがそのまま記述されています。
余談: Lyra — 3kbpsで通話できるAIコーデック
Google Researchが2021年に発表したAIベースの超低ビットレート音声コーデック「Lyra」にも触れておきます。わずか3kbpsで自然な音声を再現でき、2G回線レベルの帯域でもビデオ会議が成立する技術です。
ただし、現時点ではChromeのlibwebrtc（WebRTCエンジン）にLyraは統合されていません。RTCPeerConnectionのSDP negotiationでOpusやG.711のように自動的にネゴシエーションすることはできず、WebRTC標準コーデック（RFC 7874）にも含まれていません。Google Duoのネイティブアプリでは低帯域環境向けに活用された実績がありますが、ブラウザ版Meetで標準的に使えるわけではないのが現状です。
WebRTCの業務をやっていると、低帯域環境での音声品質は常に課題になります。Opusでも十分優秀ですが、3kbpsで実用レベルの音声が出せるコーデックがブラウザ標準で使えるようになったら、新興国向けサービスや災害時通信など、適用範囲が一気に広がるはずです。libwebrtcへの統合を期待したいところです。
Microsoft Teams — WebRTCの「部品」を使う独自スタック
Teamsは「WebRTCを使っている」とも「使っていない」とも言える、微妙な立ち位置にいます。
WebRTCとの関係
Teamsのメディアスタックは、WebRTCの構成要素であるICE、STUN、TURN、SRTPを使用しています。Microsoft公式ドキュメントにも明記されています。
Teams media flows connectivity is implemented using standard IETF Interactive Connectivity Establishment (ICE) procedures. — Microsoft Teams call flows - Microsoft Learn
技術スタック
- メディアトランスポート: RTP/SRTP
- NAT越え: ICE（STUN/TURN、IETF標準準拠）
- ポート構成: UDP 3478(STUN/TURN)ほか、動的ポートレンジも使用
- シグナリング: HTTPS REST / SIP（Direct Routing時）
- トランスポート優先度: UDP → TCP → HTTP（TCPは品質劣化するため非推奨）
「標準WebRTCそのもの」ではない理由
ブラウザ版Teams（teams.microsoft.com）はWebRTCのRTCPeerConnectionを使用しています。一方、デスクトップクライアントは独自のメディアエンジンを持っており、ICEやSRTPといった「WebRTCと同じRFC標準」を独自実装しています。
VDI（Azure Virtual Desktop）環境ではWebRTC Redirector Serviceを介してメディア処理をローカルデバイスにオフロードする仕組みがあり、この場合は720p上限などの制約があります。
Teamsはクラウドネイティブでゼロから設計されたマイクロサービスアーキテクチャですが、通話・VoIP部分の一部にはSkype由来のプロトコルの影響が見られます。Skype for Businessの「後継製品」という位置づけではあるものの、コードベースとしては別物です。WebRTCの標準プロトコルを採用しつつも、独自のメディアパイプラインを維持しています。
参考: Microsoft Teams call flows - Microsoft Learn 参考: Security guide for Microsoft Teams - Microsoft Learn
Zoom — 独自最適化を優先してきた会社
Zoomの技術的選択は、4サービスの中で最も興味深いです。
独自路線の歴史
Zoomのネイティブクライアントは、独自のコーデックと独自のメディアトランスポートで動作しています。WebRTCが業界標準になっていく中で、Zoomは独自最適化を優先する選択をしてきました。
Webクライアントの実装を見ると、そのこだわりがよくわかります。
- getUserMediaでカメラ・マイクにアクセス（これだけはWebRTCのAPI）
- WebAssemblyでZoomネイティブのC/C++コーデックをブラウザ上で実行
- メディアデータをWebSocket等経由でサーバーに送信（時期によりWebTransportやQUICベースの実験も行われている）
つまり、ブラウザ上でもWebRTCの標準的なRTCPeerConnection経路を使わず、独自のコーデックをWASMで動かして独自トランスポートでメディアを転送するという、かなり異例のアプローチです。
webrtcHacksによる詳細な技術分析では、chrome://webrtc-internalsを開いてもRTCPeerConnectionが存在しないことが確認されています。
DataChannelへの進化
WebSocket（TCP）でリアルタイムメディアを送ると、パケットロス時にTCPの再送制御が入り、遅延が悪化します。この問題を解決するため、ZoomはWebRTCのDataChannel（SCTP over DTLS）を採用しました。
技術的にはDataChannelはRTCPeerConnectionの一部ですが、Zoomの実装では標準的なWebRTCメディアフロー（RTCPeerConnectionでの映像・音声トラック送受信）は使わず、DataChannel経由で独自エンコードしたメディアデータを転送するという使い方をしています。WebSocketはフォールバックとして維持されています。
2024年12月の転換点
2024年12月31日、ZoomはVideo SDK v2 for webでWebRTCの採用を発表しました。
Zoom's proprietary video stack has historically been distinct from WebRTC, relying on custom implementations of codecs and media transport. [...] With the release of Video SDK v2 for web, Zoom has added WebRTC support to its stack. — WebRTC.ventures
WebRTCのadaptive bitrateやcongestion controlの方が、独自スタックよりもブラウザ上での品質が高いことが認められた形です。
ただし、これはVideo SDKの話であり、Zoomミーティング本体のネイティブクライアントは引き続き独自スタックです。
Zoomが独自にこだわった理由
- コーデック制御: 独自コーデックでCPU負荷・ネットワーク適応を細かく最適化
- ファイアウォール越え: WebSocket経由なら認証プロキシも通過できる（WebRTC TURNでは長年問題だった）
- 統一体験: ネイティブとWebで同一コーデックを使用
これらは合理的な判断でした。特にファイアウォール越えは企業環境では切実な問題です。
私自身、複数の企業でWebRTCの導入検証をやってきましたが、毎回頭を悩ませるのがポートの問題です。WebRTCでは公開が必要なポート数が多く、企業のセキュリティポリシーとの調整に時間がかかります。TURN/TLSで443番ポートに集約する方法もありますが、認証プロキシを挟んでいる環境ではそれすら通らないケースがありました。
Zoomが「WebSocketで443番ポート1つだけ」という割り切った設計にしたのは、この現場の痛みをよく理解していたからでしょう。企業向けに強かった理由の一つです。
Skype — 独自技術のまま幕を閉じたサービス
Skypeの技術的変遷は、ビデオ会議の歴史そのものです。
プロトコルの変遷
| 時期 | アーキテクチャ | 特徴 |
|---|---|---|
| 2003〜2012年 | 完全P2P | ユーザーPCがスーパーノードとして機能 |
| 2012〜2017年 | Microsoft管理SuperNode | ルーティングのみ集中化、P2P基盤は維持 |
| 2017〜2025年 | Azure集中型 | P2P完全廃止、全トラフィックがクラウド経由 |
| 2025年5月5日 | サービス終了 | Microsoft Teamsに統合 |
WebRTCとの関係
MicrosoftはORTC（Object RTC）APIをSkype for Business Webクライアントで実装し、WebRTCの代替として推進しました。ORTCは2013年にHookflashが創設したW3C Community Groupで策定されたもので、WebRTCより低レベルなAPIを提供する設計でしたが、広く採用されるには至りませんでした。
WebRTCへの段階的移行（まずコーデックの互換性から）が計画されていましたが、結局はTeamsへの集約が優先され、Skypeは2025年5月5日にサービスを終了しました。
参考: The next chapter: Moving from Skype to Microsoft Teams - Microsoft公式
技術的な比較まとめ
NAT越え
| サービス | 方式 |
|---|---|
| Google Meet | ICE（STUN/TURN） — WebRTC標準 |
| Teams | ICE（STUN/TURN） — IETF標準準拠の独自実装 |
| Zoom | WebSocket（TCP）→ DataChannel（SCTP）→ WebRTC ICE（SDK） |
| Skype | 独自ホールパンチング → Azure経由 |
メディア暗号化
| サービス | 方式 |
|---|---|
| Google Meet | DTLS-SRTP（WebRTC必須） |
| Teams | SRTP / DTLS-SRTP（クライアント間構成により異なる） |
| Zoom | TLS + AES-GCM → オプションE2EE対応 |
| Skype | 独自（AES-256 + RSA） → Azure TLS |
Webクライアントの実装
| サービス | 方式 |
|---|---|
| Google Meet | WebRTC RTCPeerConnection |
| Teams | WebRTC RTCPeerConnection（VDI環境はRedirector Service） |
| Zoom | getUserMedia + WASM + DataChannel |
| Skype | — |
なぜこんなに違うのか
各サービスが異なるアプローチを取った背景には、それぞれの事情があります。
Google Meet: WebRTCの開発元なので、自社技術をそのまま使うのが合理的。ChromeブラウザとWebRTCの両方を開発しているため、最適化も容易。
Microsoft Teams: ゼロから設計されたクラウドネイティブアーキテクチャで、IETF標準に準拠。企業向けの電話システム（PSTN）との接続にSIPが必要なため、WebRTCだけでは完結しない。ブラウザ版はWebRTC（RTCPeerConnection）を使用し、デスクトップクライアントは独自メディアエンジン。
Zoom: 独自技術で品質と安定性を追求してきたが、ブラウザ対応の市場要求とWebRTCの成熟により方針転換。ただし完全移行はまだ先。
Skype: 20年間のアーキテクチャ変遷の末、独自技術のまま終了。WebRTCが成熟する前に設計された技術的負債を解消できなかった。
まとめ
「ビデオ会議は全部WebRTC」ではありません。
- Webクライアントで最も標準WebRTCに近い: Google Meet
- ブラウザ版はWebRTC、デスクトップは独自実装: Microsoft Teams
- 独自スタックからWebRTCに移行中: Zoom（SDK限定）
- 独自技術のまま終了: Skype
WebRTCは「ブラウザでリアルタイム通信をするための標準」として確立しましたが、ネイティブクライアントではまだ独自実装が残っています。
ただ、Zoomの2024年末の方針転換が象徴するように、流れは明らかにWebRTCへの収束に向かっています。独自スタックを維持するコストよりも、WebRTCの標準に乗る方が合理的になってきた。Skypeの終了は技術要因だけでなく事業戦略の結果でもありますが、独自プロトコルの技術的負債が移行の足かせになったのは事実です。
参考文献
- Meet Media API concepts - Google for Developers
- Microsoft Teams call flows - Microsoft Learn
- How Zoom's web client avoids using WebRTC - webrtcHacks
- Zoom's WebRTC-Powered Video SDK - WebRTC.ventures
- How Zoom's Video SDK stacks up on web - Zoom公式
- When will Zoom use WebRTC? - BlogGeek.me
- The next chapter: Moving from Skype to Microsoft Teams - Microsoft
