Broadcast Channel APIは、同じオリジンの複数のタブ・ウィンドウ・iframe・Service Worker・Web Workerの間で、名前付きチャンネルを介してメッセージを送受信するためのWeb APIです。WHATWGがHTML仕様の一部として策定し、2015年末頃にFirefoxが先行実装、その後Chrome（2017年）・Edge・Safari（2022年）と順次対応が進み、現在は全モダンブラウザで利用できます。タブ間通信の手段としては従来localStorageの storage イベントを利用する裏技がありましたが、Broadcast Channelはより明示的かつ高機能な公式ソリューションとして登場した経緯があります。
この記事の目次
- チャンネルを開いて送受信する仕組み
- storage イベントとの違い
- 代表的なユースケース
- 他のメッセージング手段との位置づけ
- まとめ
チャンネルを開いて送受信する仕組み
Broadcast Channelの使い方は驚くほど単純で、const ch = new BroadcastChannel('app-events') のように同じ名前のチャンネルを開けば、その時点で同一オリジン内の他のコンテキストと自動的につながります。メッセージ送信は ch.postMessage({type: 'logout'}) のように構造化複製可能なオブジェクトを渡すだけ、受信は ch.onmessage = e => console.log(e.data) という従来のWeb APIに似た形式です。サーバーやWebSocketを介さず、ブラウザ内部のIPC的な仕組みで直接配信されます。
重要なポイントは「送信者自身には届かない」「同一オリジン限定」「使い終わったら ch.close() で閉じる」の3点です。自身に配信されない設計はエコーループを防ぐ実用的な選択で、必要なら送信側で同じ処理を直接呼べばよく、イベントの二重発火を防げます。オリジン分離はセキュリティ上の境界として厳密に守られており、クロスオリジンでメッセージを受け渡したい場合は別途postMessage＋iframeの仕組みを使う必要があります。
storage イベントとの違い
Broadcast Channelが登場する前は、localStorageを変更すると他のタブで storage イベントが発火する性質を利用してタブ間通信を実現する手法が広く使われていました。しかしこの方法は「文字列しか送れない」「永続化が副作用として発生する」「自身のタブには発火しない仕様だが一部ブラウザで挙動が違う」「セキュリティ上ローカルストレージへ余計なデータを書く必要がある」といった欠点がありました。Broadcast Channelはこの裏技を置き換えるための公式APIとして設計されています。
違いとして大きいのは、構造化複製可能なオブジェクトをそのまま送れる点、永続化の副作用がない点、Service WorkerやWorkerからも対称に使える点です。Service Workerが受け取ったプッシュ通知をクライアント側全てのタブへ即座にブロードキャストする、といった用途で特に威力を発揮します。またチャンネル名は文字列で任意に決められるため、auth-events chat-room-42 のようにドメイン的に意味のある名前空間を作って整理できる柔軟さも持っています。
代表的なユースケース
もっとも一般的な用途は、ログイン状態の同期です。あるタブでユーザーがログアウトボタンを押した瞬間、Broadcast Channelで logout を配信し、他のすべてのタブが認証画面に切り替わるという体験を作れます。Webメール・SaaSダッシュボード・社内ツールなど、同じユーザーが複数タブで作業するアプリで重宝されます。従来は再リクエストで401エラーが返ってからリダイレクトする受動的な仕組みでしたが、Broadcast Channelによってリアルタイムかつ正確な状態同期が実現します。
プッシュ通知との組み合わせも強力です。Service Workerが受け取った通知データをアクティブなタブが存在する場合だけそちらに転送し、ネイティブ通知ではなくアプリ内通知バナーで表示する、というハイブリッド体験が一般的になっています。テーマや言語の即時切替、別タブで追加した未読メッセージの数バッジ更新、フォーム未保存警告の全タブ集約など、「ユーザーが触っているタブをまたいだ即時性」が必要な場面で本領を発揮するAPIです。
他のメッセージング手段との位置づけ
Broadcast Channelは、window.postMessage のように特定の宛先を指定するピンポイント通信ではなく、「チャンネルに接続している全員へ放送する」モデルです。宛先を絞りたい場合や、クロスオリジン通信を行いたい場合は postMessage の方が適切です。また長期間状態を共有したいなら Shared Worker、サーバーを経由する必要があるなら WebSocket や Server-Sent Events と、目的に応じた使い分けがしやすい立ち位置にあります。
実装の選択基準としては、「同一オリジンの複数タブで、軽い通知メッセージをやり取りしたい」場合は迷わずBroadcast Channel、「サーバー経由でリアルタイム同期したい」場合は WebSocket、「状態を共有する場が欲しい」場合は Shared Worker、というのが定石です。Broadcast Channel自体は実装も理解もシンプルで、5分で導入できる手軽さがあり、ユーザー体験の品質を一段引き上げる小回りのよい道具として、現代のWebアプリ開発で頻繁に登場します。
まとめ
Broadcast Channel APIは、同一オリジンの複数タブやワーカー間で軽量にメッセージを配信できるWeb標準APIです。ログアウト同期・通知バッジ更新・テーマ切替反映といった「全タブ即時同期」のユースケースに最適で、従来のstorageイベントを使った裏技を置き換える公式手段として、現代のWebアプリ開発に欠かせない存在になっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント