Web Workerのスレッドモデルとメッセージパッシング

なぜWorkerの「分離」を正確に理解する必要があるのか

JavaScript のメインスレッドは、スクリプト実行・DOM 操作・レイアウト・描画をすべて1本で回します。ここで重い計算を同期的に走らせるとイベントループが詰まり、クリックもスクロールも止まる——これが「UI が固まる」の正体です（基礎はイベントループの内部構造を参照）。Web Worker は計算を別スレッドへ逃がす仕組みですが、その設計思想を一言で言えば「メモリを共有しない並行モデル」です。スレッドを足しながらデータ競合（race condition）を原理的に避けるために、Worker は共有メモリではなくメッセージのコピー渡しを前提に設計されました。この前提を取り違えると、「Worker から DOM を触れない」「渡したオブジェクトが別物になっている」といった壁に必ずぶつかります。本記事はその分離モデルとメッセージパッシングの内部を解きほぐします。

メモリ非共有：なぜ変数もDOMも直接触れないのか

OS のネイティブスレッドは既定で同一プロセスのヒープを共有し、複数スレッドが同じメモリを同時に書き換えうるためロックが必須になります。Web Worker はこの逆を選びました。各 Worker は**独立した実行環境（agent／グローバルスコープ）**を持ち、メインスレッドの変数・関数・プロトタイプには一切アクセスできません。共有がなければ、そもそも同時書き換えが起きえないので、ロックなしで安全に並行実行できます。これが Worker モデルの中核にある設計判断です。

この帰結として、Worker からは DOM・window・document に触れません。DOM は単一スレッドからの逐次操作を前提に作られたツリーで、複数スレッドが同時にいじれば整合性が壊れるからです。Worker のグローバルは window ではなく WorkerGlobalScope（専用なら DedicatedWorkerGlobalScope）で、使えるのは fetch・WebSocket・setTimeout・Cache・IndexedDB などスレッド安全な範囲の API に限られます。

3種のWorker：分離の単位と寿命が違う

「Worker」と一括りにされがちですが、専用・共有・サービスの3種は誰と紐づき、どれだけ生きるかがまったく異なります。

専用 Worker は最も単純で、new Worker('w.js') を呼んだそのページだけが所有します。ページが閉じれば Worker も破棄されます。共有 Worker は同一オリジンの複数のコンテキスト（タブ・iframe）から同じ1つのインスタンスへ接続でき、接続はそれぞれ MessagePort として表れます。タブ間で WebSocket 接続や状態を1本に束ねたいときに使います。Service Worker はそもそも計算隔離が目的ではなくネットワークプロキシで、ページとは独立に起動・終了を繰り返す特殊な存在です。ライフサイクルと制御権の詳細はService Workerのライフサイクルで扱っているとおり、上の2つとは寿命の考え方からして別物です。

メッセージパッシング：コピーで渡る、参照では渡らない

Worker との唯一の通信路は postMessage と onmessage です。ここで決定的に重要なのは、渡すデータは参照ではなくコピーだということ。送信値は構造化複製（structured clone）アルゴリズムでシリアライズされ、受信側で別オブジェクトとして再構築されます。だから送信後に送信側で元オブジェクトを書き換えても、受信側には伝わりません。共有していないのですから当然です。

// main.js
const worker = new Worker('w.js');
const data = { nums: [1, 2, 3] };

worker.postMessage(data);   // data はコピーされて渡る
data.nums.push(4);          // この変更は Worker 側には届かない（別オブジェクト）

worker.onmessage = (e) => {
  console.log('結果:', e.data);   // 受信もコピー
};

// w.js（Worker 側）
self.onmessage = (e) => {
  const sum = e.data.nums.reduce((a, b) => a + b, 0);
  self.postMessage(sum);   // 値を返す。これもコピーで戻る
};

構造化複製は Object/Array/Map/Set/Date/ArrayBuffer など広い型を扱い、循環参照も解決します。一方で関数・DOM ノード・Symbol は複製できず、含めると DataCloneError が投げられます。またプロトタイプや getter/setter は引き継がれません——複製されるのは自前の列挙可能プロパティの「値」だけで、結果はプレーンなオブジェクトになります（getter はその時点の戻り値が読まれ、ただのデータプロパティとして写ります）。「メソッドが消えた」「instanceof が偽になった」のはこのためです。

ゼロコピーの逃げ道：TransferableとSharedArrayBuffer

コピーを避ける手段は2つあり、性質がまるで違います。

Transferable（転送可能オブジェクト）は、コピーせず所有権ごと移動します。postMessage の第2引数（転送リスト）に ArrayBuffer 等を渡すと、バイト列は複製されず移動先へ付け替えられ、移動元は detach されて使えなくなります（byteLength が0になる）。ArrayBuffer を被せた TypedArray ビューも巻き添えで無効化されます（背後のメモリが切り替わる原理はArrayBufferのメモリレイアウトと同じ）。ゼロコピーですが、片方しか持てない移動である点が要です。

const buf = new ArrayBuffer(64 * 1024 * 1024);   // 64MB
worker.postMessage({ payload: buf }, [buf]);     // 第2引数で転送（ゼロコピー）
buf.byteLength;   // 0：移動元は detach され空になる

SharedArrayBuffer（SAB）は、唯一物理メモリそのものを複数スレッドで共有する型です。転送のような「片方が失う」移動ではなく、両スレッドが同じバイト列を同時に読み書きできます。これは Worker モデルの非共有原則の例外で、その代わりデータ競合が現実に起き得るため、読み書きの順序と可視性を保証する Atomics（Atomics.add・Atomics.wait・Atomics.notify 等）での同期が必須になります。SAB は強力ですが、Spectre 系攻撃の前提となったため、利用には Cross-Origin-Opener-Policy と Cross-Origin-Embedder-Policy による**クロスオリジン分離（cross-origin isolation）**が必要です。

並行モデルとしての帰結

3つの渡し方は、そのまま3段階の「共有の強さ」になっています。コピーは最も安全だが大きいデータで遅く、転送は速いが片道、共有は最速だが自前同期が要る——この順で安全性と速度がトレードオフになります。多くの実務では、コントロール用の小さなメッセージはコピー、巨大バイナリ（画像・音声・WASM のヒープ）は転送、リアルタイムに双方向で叩き合う領域だけ SAB、と使い分けます。

まとめ