ラピットくん 
Web アプリでリアルタイム同期を実装したい。チャット、共同編集、ライブ配信のスコアボード、オンライン会議……。「リアルタイムに同期したい」という要件は同じでも、選ぶべき技術はまったく違います。
この記事では、ブラウザのリアルタイム通信技術を3つに整理し、「どんな場面でどれを選ぶか」を実例付きで解説します。
結論: 3つの技術と選び方
まず結論から。ブラウザでリアルタイム同期を実現する主要な技術は3つです。
| BroadcastChannel | WebSocket | WebRTC | |
|---|---|---|---|
| 通信範囲 | 同じブラウザ内 | どこでも | ユーザー同士（P2P） |
| サーバー | 不要 | 必要 | シグナリングのみ必要 |
| 遅延 | ほぼゼロ | 数ms〜 | 最小（直接接続） |
| データ形式 | テキスト / オブジェクト | テキスト / バイナリ | 音声 / 映像 / データ |
| 代表的な用途 | タブ間同期 | チャット、ダッシュボード | ビデオ通話、画面共有 |
判断フローチャート
技術選定で迷ったら、この2つの質問で判断できます。
「ブラウザの外に出るか」がすべての分岐点です。この判断を間違えると、不要なサーバーを立てたり、逆に同期できないアプリを作ることになります。
BroadcastChannel — 同じブラウザ内で完結する同期
仕組み
BroadcastChannel API は、同じブラウザ・同じオリジン内のタブやウィンドウ間でメッセージを送受信する仕組みです。ブラウザのメモリ内で完結するため、サーバーは一切不要です。
// 送信側（タブA）
const ch = new BroadcastChannel('my-app')
ch.postMessage({ score: 3, inning: 5 })
// 受信側（タブB）— 同じブラウザ内なら即座に届く
const ch = new BroadcastChannel('my-app')
ch.onmessage = (e) => console.log(e.data) // { score: 3, inning: 5 }向いているケース
- EC サイトで別タブのカートを同期
- ログアウトしたら全タブに反映
- 同一ブラウザ内の複数画面を連動させるツール
- OBS のカスタムドックとブラウザソースの連携（同じ CEF 内）
限界
別のブラウザ、別のデバイスとは通信できません。Chrome で開いたタブと、OBS の内蔵ブラウザ（CEF）は別プロセスなので、BroadcastChannel のメッセージは届きません。「同じ URL なのに同期しない」のはこれが原因です。
WebSocket — ブラウザの壁を越える同期
仕組み
WebSocket は、ブラウザとサーバーの間に常時接続のトンネルを張る技術です。HTTP のように「リクエスト → レスポンス」ではなく、双方向にいつでもデータを送れます。
サーバーが中継役になるため、異なるブラウザ、異なるデバイス、異なるネットワークにいるユーザー同士を繋げます。
向いているケース
- リアルタイムチャット
- 共同編集ドキュメント（Google Docs 型）
- ライブダッシュボード（株価、IoT センサー値）
- オンラインゲームの状態同期
- スマホから操作して PC に反映
トレードオフ
サーバーの運用が必要になります。Node.js のサーバーを立てるか、Cloudflare Workers や AWS API Gateway のようなマネージドサービスを使うか。いずれにしても、静的ホスティングだけでは完結しません。
WebRTC — ユーザー同士を直接つなぐ同期
仕組み
WebRTC は、ブラウザ同士がサーバーを介さずに直接通信する技術です。主に音声・映像のリアルタイム伝送に使われます。
向いているケース
- ビデオ通話（Zoom, Google Meet 型）
- 画面共有
- P2P ファイル転送
- 低遅延が求められるリアルタイム通信
実際の使われ方
多くのアプリは WebRTC 単体ではなく、WebSocket と組み合わせて使います。接続の確立（シグナリング）や参加者管理、テキストチャットなどの制御系は WebSocket で、音声・映像の本体は WebRTC で、という役割分担です。
実例 1: 野球配信アプリで BroadcastChannel を選んだ理由
筆者が開発した野球ライブ配信用スコアボード「yakyuu」では、BroadcastChannel を採用しました。
要件
- コントロール画面（スコア入力）とオーバーレイ画面（スコア表示）のリアルタイム同期
- 操作するのは1人（スコアキーパー）
- サーバーを立てたくない（GitHub Pages で完結させたい）
判断
フローチャートに当てはめると「通信はブラウザの外に出るか？ → NO」。OBS のカスタムドックとブラウザソースは同じ CEF 内なので、BroadcastChannel で同期可能。サーバー不要で最速の選択肢です。
ぶつかった壁
ところが、ユーザーから「Chrome で操作して OBS のブラウザソースに反映させたい」という要望が来ました。これは「ブラウザの外に出る」パターンです。Chrome と OBS CEF は別プロセスなので、BroadcastChannel では対応できません。
解決策として、WebSocket を追加する代わりに、OBS 内で完結する構成を推奨することにしました。OBS のカスタムドックにコントロール画面を表示し、ブラウザソースにオーバーレイを表示する。この構成なら同じ CEF 内なので BroadcastChannel で同期できます。
さらに、OBS 環境特有の課題にも対処しました。
- パネル配置の調整: OBS ブラウザソース内ではドラッグ操作ができないため、コントロールパネルから座標・倍率を数値入力で調整可能に
- 接続検知: ハートビート（1秒間隔）+ Cookie フォールバックで、オーバーレイの接続状態を表示
- 点滅防止: 同期メッセージによるパネル位置の巻き戻りを、グローバルフラグで制御
実例 2: オンラインもくもく会が WebSocket + WebRTC を必要とする理由
比較として、知人が開発しているオンラインもくもく会アプリ（mokumoku.app）を見てみます。
要件
- 複数人がリアルタイムに参加
- 音声通話・画面共有
- 参加者の入退室管理
- 会話ログの同期
なぜ BroadcastChannel では不可能か
「複数人がインターネット越しに繋がる」時点で、ブラウザの外に出ています。さらに音声・映像のやり取りもある。フローチャートに当てはめると「Q1: YES → Q2: YES → WebRTC + WebSocket」です。
| 用途 | 技術 |
|---|---|
| 参加者の入退室通知 | WebSocket |
| テキストチャット・ログ同期 | WebSocket |
| 音声通話 | WebRTC |
| 画面共有 | WebRTC |
| 接続確立（シグナリング） | WebSocket |
このように、1つのアプリの中でも機能ごとに技術を使い分けているのが実際のリアルタイムアプリの姿です。
まとめ: 最初は一番シンプルな技術から始める
リアルタイム通信の技術選定で大切なのは、「いま必要な通信範囲」に対して最小の技術を選ぶことです。
- 同じブラウザ内で済む → BroadcastChannel（サーバー不要・実装3行）
- ブラウザの外に出る → WebSocket（サーバー必要だが汎用的）
- 音声・映像が必要 → WebRTC + WebSocket（最も高機能だが複雑）
最初から WebSocket を入れる必要はありません。BroadcastChannel で作って、「ブラウザの外に出る必要がある」と分かった時点で WebSocket を追加する。この段階的なアプローチが、特にプロトタイプや個人開発では有効です。
技術選定に「正解」はありませんが、「判断基準」はあります。通信がブラウザの外に出るかどうか。この1つの質問が、選択を明確にしてくれるはずです。
この記事で紹介した野球配信スコアボード「yakyuu」は無料で公開しています。
リアルタイム通信の技術選定や、配信ツールの開発についてのご相談は、こちらのお問い合わせフォームからお気軽にどうぞ。
