structuredCloneと転送可能オブジェクトの内部

なぜコピーの「仕組み」を知る必要があるのか

Web Worker にデータを渡したら巨大な配列のコピーで固まった、structuredClone で複製したら関数プロパティが消えていた、postMessage 後に元の ArrayBuffer が空になった——これらはすべて構造化複製（structured clone）アルゴリズムという一つの仕組みから説明できます。structuredClone()・postMessage()・IndexedDB への保存・history.pushState は、いずれも同じこのアルゴリズムを内部で使います。何が複製でき、循環参照がどう解かれ、どの型が「コピー」ではなく「移動」になるのかを正確に押さえると、Worker 通信の性能設計と落とし穴回避が一気に見通せます。

構造化複製は「深いコピー」だが万能ではない

構造化複製は、対象オブジェクトをグラフとしてたどり、各ノードを再帰的に深くコピーして新しいオブジェクトグラフを作るアルゴリズムです。JSON.parse(JSON.stringify(x)) のような素朴なコピーより遥かに広い型を扱えますが、コピーするのは値（データ）であって挙動ではありません。ここが最大の境界線です。

複製できない代表は関数とDOM ノードで、これらを含むと DataCloneError という例外（postMessage でも structuredClone でも同じ）が投げられます。理由は単純で、関数はコードと閉じたスコープ（クロージャ）への参照を持ち、DOM ノードは特定の文書ツリーに結び付いた状態を持つため、それらを別のグラフや別スレッドへ意味を保ったまま移すことが定義できないからです。

循環参照とエイリアスの解決

素朴な深いコピーが循環参照（a.self = a）で無限再帰に陥るのに対し、構造化複製はメモ（memoization）でこれを解決します。アルゴリズムは「すでに複製したオブジェクト→その複製先」を対応付ける内部マップ（仕様上は memory と呼ばれる）を持ち、グラフをたどる過程で既出のオブジェクトに再会したら、新たに複製せず記録済みの複製先を再利用します。

const a = {};
a.self = a;                 // 自己参照（循環）
const b = structuredClone(a);
b.self === b;               // true（循環構造がそのまま保たれる）

この memory は循環だけでなく共有参照（エイリアス）も正しく保ちます。同じオブジェクトを2か所から指している入力は、複製後も1つの複製を2か所が指す形になり、別々のコピーには分裂しません。これが JSON 経由のコピーとの決定的な違いです（JSON は循環で例外、共有参照は重複コピーに化けます）。

const shared = { v: 1 };
const src = { x: shared, y: shared };
const dst = structuredClone(src);
dst.x === dst.y;            // true（共有関係が維持される）

Transferable：コピーではなく所有権の移動

ここまでは「コピー」の話でした。対して Transferable（転送可能オブジェクト）は、構造化複製の中で扱いが反転します。Transferable に指定されたオブジェクトは中身をコピーせず、所有権ごと移動します。移動元は detach（切り離し） され、以降そのオブジェクトは使えなくなる代わりに、移動先はバイト列を一切複製せずゼロコピーで受け取ります。巨大なバイナリを渡すときの性能はここで決まります。

Transferable になれるのは限られた型です。代表は ArrayBuffer、MessagePort、ImageBitmap、OffscreenCanvas、ReadableStream/WritableStream 等で、いずれも「移動しても意味が壊れない、所有者が1つであるべき資源」です。ArrayBuffer の転送は、その上に被せた TypedArray/DataView ビューも巻き込んで無効化します（裏の領域が切り替わるとビューも死ぬという原理はTypedArrayとArrayBufferのメモリレイアウトと同じです）。

const buf = new ArrayBuffer(1024 * 1024);   // 1MB
const view = new Uint8Array(buf);

// 第2引数の「転送リスト」に渡したものだけが移動（ゼロコピー）
worker.postMessage({ payload: buf }, [buf]);

buf.byteLength;    // 0（移動元はdetach、空になる）
view.byteLength;   // 0（元ビューも無効化）

コピーと転送の使い分け

同じデータを渡すのでも、コピーと転送では性能と後始末がまるで違います。10MB の ArrayBuffer をコピーすれば送受で計20MB相当の確保とバイト複製が走り、転送ならポインタの付け替えに近いコストで済みます。一方で転送は移動元が即座に使えなくなるため、送った後も元データを参照する設計とは両立しません。

postMessageとstructuredCloneの関係

structuredClone() と postMessage() は別物に見えて、同じ構造化複製アルゴリズムを共有する兄弟です。違いは「どこへ渡すか」と「同期か非同期か」にあります。

• structuredClone(value, options) は同一 realm（同じスレッド・同じ JS 環境）内で同期的に深いコピーを返す関数です。options.transfer に転送リストを渡せば、コピーの中で一部を転送扱いにもできます。
• postMessage(message, transferList) はスレッド/コンテキストの境界（メインスレッド⇄Worker、ウィンドウ間、MessagePort 間）を越えてメッセージを送ります。送信時に構造化複製でシリアライズし、受信側で再構築（デシリアライズ）します。

つまり postMessage は「構造化複製＋スレッド越えの配送」、structuredClone は「構造化複製だけを同期で取り出す API」と捉えると関係が整理できます。両者とも複製不可な値で DataCloneError を投げ、両者とも転送リストを受け付けます。同じアルゴリズムはService Workerのキャッシュでのメッセージ受け渡しや、IndexedDBへの値の保存でも使われており、「保存できる値＝構造化複製できる値」という制約はストレージ層にも一貫しています。

まとめ