Node.jsモジュールスコープの正体：CommonJSのラッパー関数とESMのモジュールレコードのメモリ管理
JavaScriptの歴史を紐解く時、私たちは常に「スコープの境界」と「メモリ上の表現形式」の進化の歴史を目撃してきた。ブラウザのグローバル汚染という原罪から逃れるため、CommonJSはIIFE（即時実行関数式）の力でモジュールスコープを偽装し、ECMAScript Modules (ESM) はV8エンジンのモジュールレコード（Module Record）とライブバインディングという洗練された物理構造によって、真のモジュール性を手に入れた。
本稿では、`require` と `import` で変数の見え方や挙動が根本的に異なる理由を、Node.jsのソースコードとV8エンジンのメモリ管理の低レイヤから徹底的に解剖する。
—
1. CommonJSの正体：隠されたラッパー関数とV8コンパイルパイプライン
多くのエンジニアは「CommonJSではファイルごとにスコープが作られる」と知っている。しかし、それがV8エンジンの内部でどのように構築されているかを正確に理解している者は少ない。
Node.jsがCommonJSの `.js` ファイルをロードする際、V8へソースコードを渡す前に、エンジンは文字列の先頭と末尾に特定のラッパーコードを動的に付加している。
// Node.js内部でCommonJSファイルがラップされる実態
(function (exports, require, module, __filename, __dirname) {
// ユーザーが記述したソースコードがここに挿入される
});
このラッパー関数の存在こそが、`require` や `module`、`__filename` といった識別子が、グローバルオブジェクト（`globalThis`）を汚染することなく、各ファイル内で「あたかもグローバル変数のように」存在できる理由の正体である。
V8のスコープ解析とコンテキスト生成
V8はソースコードをパースする際、この外側のラッパー関数が作る関数スコープ（Function Scope）を検出し、クロージャのメカニズムを利用してローカル変数領域を割り当てる。
// cjs-internal.js (概念的なV8スコープ解析の挙動)
const mod = { exports: {} };
// ラッパー関数を生成して即時実行する
runInThisContext(wrappedCode)(mod.exports, require, mod, filename, dirname);
ここで重要なのは、CommonJSの `module.exports` はただの「オブジェクトの参照コピー」に過ぎないという点だ。
// counter.js (CommonJS)
let count = 0;
function increment() {
count++;
}
module.exports = { count, increment };
// main.js (CommonJS)
const { count, increment } = require(‘./counter’);
increment();
console.log(count); // 出力は何になるか？
答えは `0` である。`increment()` は `counter.js` 内部のローカル変数 `count` をインクリメントしているが、`module.exports` に渡されたのはプリミティブな `0` の値そのもの（あるいはオブジェクトのプロパティ値）のコピーであり、参照のバインディング（結合）ではない。そのため、呼び出し元で分割代入された変数は、元のモジュール内の変数の変化を追跡できない。
—
2. ESMのモジュールレコードとライブバインディングのメモリ構造
これに対し、ECMAScript Modules (ESM) は、V8エンジンおよびJavaScript仕様（ECMA-262）のレベルで全く異なるメモリ管理モデルを採用している。
ESMでは、ソースコードはパースされた後、Module Record（モジュールレコード）というV8内部の構造体に変換される。さらに、複数のモジュールが依存関係を結ぶと、Module Namespace Exotic Object（モジュール名前空間特殊オブジェクト）が生成される。
ここでの最大の違いは、エクスポートされた値が「値のコピー」ではなく、ライブバインディング（Live Binding）、すなわちメモリアドレスへの参照として維持される点にある。
// counter.mjs (ESM)
export let count = 0;
export function increment() {
count++;
}
// main.mjs (ESM)
import { count, increment } from ‘./counter.mjs’;
increment();
console.log(count); // 出力は 1 になる
V8のメモリ空間における挙動
V8のヒープ上において、ESMのインポート・エクスポートは以下のように処理される：
1. リンキングフェーズ (Linking Phase):
V8はコードを実行する前に、すべてのモジュールグラフを走査し、インポート側とエクスポート側の変数が同じメモリスロット（またはスロットへの間接ポインタ）を指すようにシンボルを解決する。
2. ライブバインディングの実装:
ESMの `import { x } from ‘mod’` は、実質的に `mod.x` へのゲッター（Getter）関数アクセスとしてコンパイルされる。そのため、エクスポート側のモジュールで変数が再代入され、V8のヒープ上の値が書き換わると、インポート側もその変更を即座に（次の評価時に）観測できる。
この挙動は、プログラマが意図しない共有状態を生むリスクと表裏一体であるが、モジュール間の整合性を保証するうえでV8の最適化パイプライン（Hidden Classes / Inline Caching）と非常に相性が良い。
—
3. イベントループとモジュール評価の厳密な同期
Node.jsにおけるCommonJSとESMのロードメカニズムの差異は、非同期イベントループのフェーズにも深く影響を与える。
- CommonJS (`require`):
同期的にファイルシステムからファイルを読み込み、`vm.runInThisContext` を用いてその場でパース・評価（Evaluation）する。これはメインのイベントループの実行をブロックするため、巨大な依存ツリーを持つアプリケーションでは起動時のボトルネック（いわゆるコールドスタートの遅延）となる。
- ESM (`import`):
フェーズが厳密に分離されている。
1. Construction（構築）: すべてのファイルをフェッチし、パースしてModule Recordを構築。
2. Instantiation（インスタンス化）: メモリを割り当て、インポート・エクスポートのライブバインディングを解決。
3. Evaluation（評価）: コードを実行し、トップレベルの `await` (Top-Level Await) を含む非同期処理を解決。
この違いにより、ESMは非同期的なモジュール解決グラフを構築可能にし、V8のJITコンパイラに対してより効率的なコード最適化のヒントを与える。
—
4. セキュリティ・ハック：サプライチェーンを突くプロトタイプ汚染とモジュールスコープ
シニアエンジニアやセキュリティ研究者として避けて通れないのが、モジュールスコープの境界をいかにして突破・防御するかという問題だ。
JavaScriptの動的な性質、特にプロトタイプチェーン（Prototype Chain）の仕組みは、悪意あるサードパーティ製ライブラリがサプライチェーン攻撃の踏み台として悪用する格好の標的となる。
プロトタイプ汚染（Prototype Pollution）のメカニズム
CommonJSであれESMであれ、すべてのオブジェクトは最終的に `Object.prototype` を継承している。もし依存ライブラリの脆弱なマージ関数（深層オブジェクトの結合処理など）に以下のような入力を与えた場合：
// 悪意のあるペイロードの例
const payload = JSON.parse(‘{“__proto__”: {“rcePayload”: “maliciousCode”}}’);
// 脆弱なマージ関数が実行されたとする
utils.merge({}, payload);
V8エンジンのヒープメモリ上では、`Object.prototype` の隠しクラス（Hidden Class / Map）構造が書き換わり、すべての新規オブジェクト、さらにはモジュール間で共有されるビルトインオブジェクトのプロトタイプにまで汚染が伝播する。
ランタイム防壁の構築：不変性とオブジェクトの凍結
このサプライチェーン攻撃を防ぐための決定的な対策が、モジュールスコープ内での厳格なオブジェクト防衛、すなわち `Object.freeze()` や `Object.seal()`、そしてV8の機能を活用したプロトタイプの切断である。
// 安全なモジュール設計の極限
‘use strict’;
// 1. プロトタイプを持たないオブジェクトの生成
const secureConfig = Object.create(null);
secureConfig.apiEndpoint = ‘https://api.internal’;
// 2. オブジェクトの完全な凍結（V8のマップをイミュータブルに固定）
Object.freeze(secureConfig);
// 万が一、Object.prototypeが汚染されても影響を受けない
console.log(secureConfig.toString); // undefined (prototypeが存在しないため)
さらに、Node.jsの起動時に `–frozen-intrinsics` フラグを有効にすることで、ビルトインのプロトタイプ（`Array.prototype`, `Object.prototype` など）自体を変更不可能にし、V8ランタイムのレイヤでプロトタイプ汚染を完全に無力化することが可能だ。
node –frozen-intrinsics app.mjs
—
5. 結び：ランタイムの物理法則を掌握せよ
JavaScriptは、もはや「おもちゃのスクリプト言語」ではない。V8エンジンという高度なJITコンパイラとメモリ管理機構の上で稼働する、厳格なシステムプログラミング言語である。
CommonJSのラッパー関数がもたらすスコープの隠蔽と、ESMのモジュールレコードが実現するライブバインディングのメモリ構造。これらの違いを単なる「書き方の違い」として片付けるのではなく、V8のヒープとイベントループの物理挙動として脳内にトレースできるか否か。そこに、真のフルスタック・チーフアーキテクトと、単なるコードの書き手との決定的な境界線が存在する。
コードの1行がV8のどのコンパイルフェーズを通過し、メモリのどの領域にマッピングされるのか。その解像度を極限まで高めた者だけが、セキュアでスケーラブルな次世代のWebインフラストラクチャを構築できる。