BroadcastChannelとタブ間メッセージングの仕組み

なぜタブ間通信に専用APIが要るのか

同じサイトを2つのタブで開き、片方でログアウトしたらもう片方も即座にログアウト表示にしたい——この「同一オリジンの複数コンテキスト間で状態を揃える」要求は、Web では驚くほど面倒です。タブは互いに独立したブラウジングコンテキストで、JavaScript のヒープも実行スレッドも別々だからです。古典的には localStorage の書き込みで発火する StorageEvent を流用してきましたが、これは本来ストレージ変更の通知であって、メッセージング用に設計されたものではありません。BroadcastChannel は、この「同一オリジンの兄弟コンテキストへの同報（broadcast）」だけを目的に作られた専用 API です。仕組みを正確に押さえると、配送範囲・順序・落とし穴がはっきり見通せます。

BroadcastChannelは「名前付きの共有バス」

BroadcastChannel は、宛先を名指ししないバス（bus）型の通信路です。各コンテキストは同じチャネル名を指定して BroadcastChannel を生成すると、その名前を共有する全コンテキストが繋がった1本のバスに参加します。あるコンテキストが postMessage で送ると、同じオリジン・同じチャネル名を購読している他のすべてのコンテキストの message イベントとして届きます。

// どのタブ・iframe・Worker でも同じ
const ch = new BroadcastChannel("auth");

ch.onmessage = (e) => {
  if (e.data.type === "logout") location.reload();
};

// ログアウト時：開いている全タブへ同報
ch.postMessage({ type: "logout" });

重要なのは、参加者を事前に列挙する必要がない点です。チャネルは名前で緩く結合されており、後から開いたタブが同名チャネルを作れば自動的にバスへ加わります。接続のハンドシェイクも、相手の参照を握る必要もありません。close() を呼ぶか、コンテキストが破棄されるとバスから外れます。

配送範囲を決めるのは「オリジン」と「エージェントクラスタ」

どこまで届くかは2つの境界で決まります。1つ目はオリジンです。BroadcastChannel は同一オリジン（スキーム・ホスト・ポートが一致）の中だけで通じ、https://example.com と https://sub.example.com は別バスです。これは同一オリジンポリシーが定める信頼境界とまったく同じ線引きで、クロスオリジンに漏れることはありません。

2つ目はエージェントクラスタ（agent cluster）、すなわち同じプロセス群でグループ化される実行単位です。同一オリジンであっても、別のブラウザプロファイルやシークレットウィンドウは異なるストレージパーティション／クラスタに属するため、原則として相互に届きません。受信できるのは「同一オリジン・同一ストレージパーティション内」の、タブ・ウィンドウ・iframe・Web Worker・Service Worker といったあらゆるコンテキストです。

ペイロードは構造化複製でコピーされる

バスへ流すデータは、参照渡しではなく構造化複製（structured clone）アルゴリズムで深くコピーされてから各受信者へ渡されます。これは structuredClone() や Worker への postMessage と同じシリアライズの仕組みです。したがって Object・Array・Map・Set・Date・ArrayBuffer などは送れますが、関数や DOM ノードを含むと DataCloneError になり、class インスタンスを送っても prototype は失われ素の Object になります。

ch.postMessage({ ids: new Set([1, 2, 3]), at: new Date() }); // OK
ch.postMessage({ cb: () => {} }); // DataCloneError（関数は複製不可）

一点だけ Worker 向け postMessage と異なるのは、転送可能オブジェクト（Transferable）を渡せないことです。BroadcastChannel の postMessage は転送リスト引数を取らず、ArrayBuffer は常に「移動」ではなく「コピー」されます。1対多の同報では「所有権を1つの受信者へ移す」という転送の意味が成立しないためで、結果として大きなバイナリを同報すると、サイズに比例した複製コストが受信者の数に応じてかかります。

配送順序の保証——FIFOだが受信者間は非同期

順序の保証は実務で最も誤解されやすい点です。仕様上、メッセージの配送は**同一エージェントクラスタ内で送信順（FIFO）**が保たれます。つまり、ある送信元が A → B → C の順に送れば、各受信者は必ず A・B・C の順で受け取り、追い越しは起きません。各受信者のイベントキューには、その順序でメッセージタスクが積まれます。

ただし保証されるのは「各受信者内での相対順序」までで、受信者どうしの到着タイミングは揃いません。タブ1が B を処理し終える前に、タブ2はまだ A を処理しているかもしれません。配送は受信側ごとに独立したタスクとしてイベントループに積まれる非同期イベントだからです。さらに複数の送信元が混在する場合の全体順序（グローバル順序）は規定されません。送信元 X の A と送信元 Y の P が、どの受信者でも同じ前後関係で届くとは限りません。

postMessage・StorageEventとの違い

同じ「コンテキスト間でデータを動かす」でも、3者は設計思想が異なります。window.postMessage（および MessagePort）は宛先を名指しする1対1の通信で、相手の window 参照や MessagePort を握っている必要があり、その代わりクロスオリジンでも使える（受信側が origin を検証する前提）唯一の手段です。

StorageEvent は本来ストレージ変更の副作用通知です。localStorage への書き込みが、同一オリジンの他のドキュメントで storage イベントを発火させる仕組みで、Web ストレージの章の挙動に依存します。メッセージング目的に流用できますが、書いた本人のタブには発火しない、localStorage を実際に汚すので後始末が要る、同じ値を再代入しても発火しない、といった制約があり、専用バスとしては不格好です。

まとめ