Zoom・Google Meet はどう動くのか？ リアルタイム通信と WebRTC

Zoom や Google Meet のリンクを 1 つクリックするだけで、ノートパソコンとカメラが自動的に会議室に入っていきます。一度も会ったことのない人と画面越しに、ほとんど途切れずに会話できます。これが当たり前になったのはそれほど昔の話ではありません。10 年前まで、ビデオ会議は別のプログラムをインストールし、カメラ設定をいじっても途中で切れることが珍しくありませんでした。

この記事では、ビデオ会議がその短いクリックの裏でどんな仕事をしているのか、そしてその仕事を標準化した WebRTC とは何かを、コードなしで整理します。

ビデオ会議がしている三つの仕事 #

ビデオ会議ツールは結局、三つのことを同時に処理しています。カメラとマイクから映像・音声を取り込むキャプチャ、その信号をネットワークで送れるように細かく切って圧縮するエンコード、そしてその結果を相手まで素早く届ける伝送です。

カメラが送り出す生の映像は 1 枚あたり数十 MB に達するので、そのまま送ったら 1 秒も持たずに回線が詰まってしまいます。だから映像は H.264・VP9・AV1 のようなコーデックで圧縮され、元の数百分の一のサイズまで縮められ、その小さな断片が 1 秒に 30 回ほど相手に届けられます。

リアルタイムが難しい理由 #

ビデオ会議で一番厳しい条件は、画質でも音質でもなく遅延です。映画は 1 分遅れて届いても、最初からきちんと見れば問題ありませんが、会議では相手の口の動きと声が 1 秒ずれただけで会話が成り立たなくなります。一般的に 100〜200 ms 以内なら人は違和感をほとんど感じず、400 ms を超えると互いの発言がよく重なり始めます。

この短い時間の中で、カメラが 1 枚の映像をつかみ、エンコーダーが圧縮し、インターネットを越えて反対側に到着し、デコーダーがそれを開いて画面に描き出さなければなりません。だからビデオ会議用のコーデックは、画質を少し下げてでも高速に圧縮・展開できる側を選びます。映画用のコーデックが反対のバランスを取っているのと対照的です。

WebRTC ── ブラウザー同士を直接つなぐ取り決め #

長い間、ビデオ会議は別のプログラムをインストールしなければなりませんでした。今はブラウザーで Zoom や Google Meet のリンクを押せばそのまま会議に入れますが、その裏で WebRTC という標準が働いています。WebRTC は「ブラウザー同士で映像・音声・データを直接やりとりさせるための取り決め」程度に理解すれば十分です。カメラの権限を取り、映像をつかんで圧縮し、相手のブラウザーへ送るところまで、必要な部品を一つの標準にまとめて提供している、ということです。

WebRTC が登場する前は、ビデオ会議会社ごとに独自のプロトコルと独自のクライアントをインストールさせていました。だから Zoom と Meet は互いに通話できなかったし、今も基本的に同じです。WebRTC は少なくともブラウザーの中だけは同じ部品を使うようにしました。

伝送中の映像と音声は自動的に暗号化されて盗聴を防ぎます。同じ発想の暗号化がウェブ全体でどう動いているかは アドレスバーの鍵マークは何を守っているのか にまとめてあります。

サーバーがいまだに必要な理由 #

「ブラウザー同士で直接つなぐ」と聞くとサーバーなしで動くように思えますが、実際にはそうではありません。インターネット上にノートパソコンを置いておくだけでは、同じ Wi-Fi 上の機器はすぐ見えますが、別のオフィスの Wi-Fi 越しの友人のノートパソコンは互いの住所が見えません。ルーターの後ろに隠れているからです。だから会議が始まる前に「二人とも同じ部屋に入った」という事実を知らせ、互いの住所を伝える仲介役が必要です。この役割を担うのがシグナリングサーバーです。

その次に STUN と TURN というサーバーが登場します。STUN は「あなたはインターネットからどんな住所に見えている」と教える鏡の役割で、TURN は最終的に二つのブラウザーが直接つながれない場合に映像を自分経由で迂回させる中継役です。会社のファイアウォールが厳しい環境では、TURN を経由する割合が意外と高くなります。

人数が増えると構造が変わる #

1 対 1 通話なら二人が直接つながれば終わりです。ところが会議に 5 人が入ると話が変わります。それぞれが他の 4 人に自分の映像をすべて送る必要があるので、ひとりあたりのアップロード負担が人数に比例して増えます。8 人、10 人にもなれば一般家庭のインターネット回線では耐えきれなくなります。

だからほとんどの会議サービスは SFU というメディアサーバーを中央に置きます。それぞれは自分の映像を SFU に一度だけアップロードし、SFU がそれを残りの参加者に適切に振り分けて配信します。カメラを切っている人の映像は送らず、画面上で小さく表示されている人には低画質のみを送る、という形でデータを節約します。Zoom・Google Meet・Teams も結局は SFU 構造の上に各社のクライアントと会議機能を載せたものです。

見えないところでの連携 #

リンクをクリックして会議が始まる短い瞬間の裏では、カメラ・コーデック・シグナリング・STUN・TURN・SFU が順に手を取り合っています。ユーザーから見れば 1 クリックがすべてですが、その 1 回のために何種類ものサーバーと標準が順番に協調しているわけです。次に会議が切れたり画質が落ちたりしたら、カメラの問題だけを疑うのではなく、この鎖のどこかで道が狭くなっていないか一度思い浮かべてみてもよいでしょう。