こんにちは！フロントエンドからNode.jsの内部挙動まで、日夜JavaScriptと向き合っているシニアエンジニアです。
JavaScriptの変数宣言（`var`、`let`、`const`）やスコープの基本、そして「巻き上げ（ホイスティング）」の仕組みについては、もうすっかりバッチリマスターできましたよね。
「変数はブロックの生存期間に合わせて適切にスコープを閉じ、安全に管理する」――これがプログラミングの基本中の基本です。しかし、現代のJavaScriptには、その「スコープの常識」の境界線を完全にブチ破る、極めて強力で少し危険な仕組みが存在します。それが、今回テーマにする `SharedArrayBuffer` と `Atomics` です。
今回は、初学者や他言語出身の方が必ずと言っていいほどハマる「Workerスレッド間でのメモリ共有」と、そこで求められる低レイヤなスコープ管理の真実について、V8エンジンの裏側の動きも交えながら、優しく、そして徹底的に解説していきますね。
ここをクリアできれば、あなたのJavaScriptマスターとしての解像度は一段と跳ね上がりますよ！
—
1. なぜ「Worker間でのメモリ共有」が必要なのか？
通常のJavaScriptにおいて、Web WorkerやNode.jsのWorkerThreadsを使う場合、メインスレッドと子スレッドの間でデータのやり取りをするには `postMessage()` というメソッドを使っていましたよね。
これはイメージとしては「手紙のコピーを相手に送る」ようなものです。
メインスレッド側で持っているデータ（オブジェクトなど）を直に共有することはできず、シリアライズ（直列化）されてコピーが渡されます。データが大きい場合、この「コピーとパース」のコストがメインスレッドのブロッキング（カクつき）を引き起こす原因になります。
そこで登場するのが、`SharedArrayBuffer`（共有配列バッファ）です。
これは、メインスレッドとWorkerスレッドが、文字通り「同じメモリ空間（RAM上の同じ場所）」を直接指し示すための仕組みです。手紙のコピーを送るのではなく、同じホワイトボードを複数人で囲んで、そこに直接書き込むようなイメージですね。
コードの基本：SharedArrayBufferを作ってみよう
まずは、実際にメモリを共有する基本的なコードを見てみましょう。
// メインスレッド側のコード例
// 4バイト（32ビット整数1つ分）の共有メモリ領域を確保する
const sharedBuffer = new SharedArrayBuffer(4);
// どの型のデータとしてそのメモリを解釈するかを「ビュー（TypedArray）」で定義する
const sharedArray = new Int32Array(sharedBuffer);
console.log(“初期値:”, sharedArray[0]); // 0 出力されます
この `sharedBuffer` をWorkerスレッドに `postMessage` で渡すと、両方のスレッドから「同じメモリ領域」を読み書きできるようになります。
—
2. スコープの境界線が消える恐怖：データ競合（Data Race）
さて、ここからが本題であり、初心者が最も陥りやすい罠です。
通常の変数（`let` や `const`）は、関数スコープやブロックスコープの中に閉じ込められており、他のスレッドから勝手に書き換えられることはありません。JavaScriptは基本的に「シングルスレッド」で動く言語だったため、変数の値が予期せぬタイミングで書き換わる心配をする必要がなかったのです。
しかし、`SharedArrayBuffer` を使った瞬間、「スコープの壁」が消滅します。
メインスレッドとWorkerスレッドが、全く同じミリ秒に、同じメモリの場所を書き換えようとすることが起こり得ます。これをコンピュータサイエンスの世界で データ競合（Data Race） と呼びます。
脳内イメージ：共有口座の悲劇
想像してみてください。
銀行の同じ口座（`SharedArrayBuffer`）に対して、あなた（メインスレッド）と家族（Workerスレッド）が同時に「残高に100円足す」という作業をしようとしています。
1. あなた: 現在の残高（0円）を読み取る
2. 家族: 現在の残高（0円）を読み取る
3. あなた: 0 + 100 = 100円 を口座に書き込む
4. 家族: 0 + 100 = 100円 を口座に書き込む
本来なら200円になっているはずが、残高は100円になってしまいました。これがプログラミングの世界で起きたら、データは破損し、アプリはクラッシュするか、原因不明のバグを生み出します。
—
3. Atomicsによる低レイヤな同期手法：スコープを守る盾
このカオスなデータ競合を防ぐために用意されたのが、`Atomics` オブジェクトです。
`Atomics` は、共有メモリ上の操作を「不可分（Atomic＝これ以上分割できない一連の処理）」にするための低レイヤなAPIです。先ほどの銀行の例で言えば、「私が計算し終わるまで、誰もこの口座を見るな！」と鍵をかける（ロックする）ようなイメージですね。
実践：Atomics.add と Atomics.wait / notify
それでは、具体的なコードで安全な変数操作を見てみましょう。
// — メインスレッド側 —
// 4バイトの共有バッファと、それを扱うInt32Arrayを作成
const buffer = new SharedArrayBuffer(4);
const int32 = new Int32Array(buffer);
// Workerスレッドを生成してバッファを渡す
const worker = new Worker(‘worker.js’);
worker.postMessage(buffer);
// 1秒後にWorker側で何が起きているか確認
setTimeout(() => {
// Atomics.loadを使って、安全に最新のメモリ上の値を取得する
console.log(“Workerでの処理後の値:”, Atomics.load(int32, 0));
}, 1000);
// — worker.js (Workerスレッド側) —
onmessage = function(e) {
const sharedBuffer = e.data;
const int32 = new Int32Array(sharedBuffer);
// 複数スレッドから同時にアクセスされても安全に「1」を加算する
// Atomics.add は、加算前の元の値を返しながら、安全に値を更新する
Atomics.add(int32, 0, 1);
console.log(“Workerスレッドで安全に加算完了しました”);
};
ここがポイント！
通常のJavaScriptであれば `int32[0]++` と書きたくなるところですが、共有メモリに対してこれをやるとデータ競合の温床になります。必ず `Atomics.add()` や `Atomics.store()`、`Atomics.load()` といったメソッドを介してアクセスしなければなりません。
—
4. 陥りやすい文法エラーと落とし穴
`SharedArrayBuffer` と `Atomics` を使い始めるとき、開発者が必ずと言っていいほど躓くポイントがいくつかあります。
落とし穴その1：普通の代入演算子（`=`）を使ってしまう
// ❌ 危険：データ競合を防げない、通常の配列のような代入
int32[0] = 42;
// ⭕ 安全：メモリバリアを張りながら値を書き込む
Atomics.store(int32, 0, 42);
JavaScriptの通常の構文である `=` は、V8エンジンの最適化やCPUのキャッシュの都合上、即座に他のスレッドから見えるとは限りません。必ず `Atomics.store` を使って明示的にメモリを同期させましょう。
落とし穴その2：メインスレッドで `Atomics.wait()` を使って画面がフリーズする
`Atomics.wait()` は、指定したメモリの値が特定の値と一致するまで、スレッドの実行を完全にストップさせる強力なメソッドです。
しかしこれをメインスレッド（UIスレッド）で実行すると、ブラウザの描画パイプラインが完全に凍結し、ページがクラッシュ（フリーズ）します。
> ⚠️ 鉄則: `Atomics.wait()` は、メインスレッドで使用してはなりません。必ず Workerスレッド側でのみ使用してください。
—
まとめ：変数のスコープから「メモリの共有」の時代へ
今回は、Workerスレッド間での変数共有と、`SharedArrayBuffer` / `Atomics` による低レイヤなスコープ管理の難しさについて解説しました。
- 通常の変数： `let` / `const` やブロックスコープで安全にカプセル化される。
- SharedArrayBuffer： スコープの境界線を越えて、複数スレッドでメモリを直に共有する。
- Atomics： 共有メモリへのアクセスを調停し、データ競合を防ぐための必須の盾。
普段私たちが何気なく書いている JavaScript の裏側では、V8エンジンやOSのメモリ管理がこのように緻密に連携しています。ここを理解できれば、パフォーマンスに妥協しない、重厚なマルチスレッドアプリケーション（リアルタイムゲームや高度な画像処理など）も自信を持って設計できるようになりますよ。
ここをクリアしたあなたなら、もうJavaScriptのコアメカニズムを恐れるものは何もありません。
次のステップへ向けて、一緒に進んでいきましょう！