【実務・中級編】Node.jsのモジュールスコープ（CommonJS vs ESM）のメモリ管理：ラッパー関数とモジュールレコードの違い – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

Node.jsモジュールスコープの深層：CommonJSのラッパー関数とESMモジュールレコードがV8ヒープに刻む痕跡

テックリードの私だ。コードレビューの現場で、未だに「CommonJSとESMって、書き方が違うだけでしょ？」という認識でコードを書いているエンジニアを見かける。

ハッキリ言おう。その認識のままだと、大規模なNode.jsアプリケーションや、SSR（サーバーサイドレンダリング）を行うフロントエンド基盤において、メモリリークや意図せぬグローバル汚染という致命傷を負うことになる。

今回は、V8エンジンのメモリ空間とモジュールローダーの挙動に焦点を当て、CommonJSの「ラッパー関数」とESMの「モジュールレコード」がランタイム上でどう違うのか、そして我々エンジニアがどうコードを設計すべきかを徹底的に解説しよう。

—

1. 根本的な違い：V8ヒープとスコープの物理的実体

まず、JavaScriptが実行されるとき、変数はどこに生き、どう消えていくのか。Node.jsにおけるモジュールシステムの最大の違いは、「コードがどのようにカプセル化され、V8のメモリ上に保持されるか」にある。

CommonJS (CJS) の正体：即時実行関数（IIFE）の幻影

CommonJSファイルを実行するとき、Node.jsはそのままコードを評価しているわけではない。V8に渡す直前に、Node.jsのモジュールローダー（`Module._wrapper`）は、あなたの書いたコードを以下のようなラッパー関数で包み込む。

// Node.jsが内部的に生成するラッパー関数の概念モデル
(function (exports, require, module, __filename, __dirname) {
// === ここにあなたの書いたCJSモジュールのコードが挿入される ===
const internalData = ‘leak-risk’;
exports.getData = () => internalData;
});

この設計により、CJSモジュール内のトップレベルで宣言された変数（`const`, `let`, `var`）は、グローバルオブジェクト（`global`）ではなく、このラッパー関数のローカルスコープに閉じ込められる。

しかし、ここに大きな罠がある。
もしあなたが関数スコープの特性を理解せず、不適切にクロージャを形成したり、モジュールキャッシュ（`require.cache`）に巨大なオブジェクトを保持させ続けたりすると、ラッパー関数への参照が残り続け、GC（ガベージコレクション）の対象外となりメモリリークを引き起こす。

ECMAScript Modules (ESM) の正体：静的モジュールレコードとLexical Scope

一方、ESM（`.mjs` または `”type”: “module”`）は、V8およびJavaScript仕様（TC39）に準拠した全く異なるアプローチを取る。

ESMでは、コードは実行前にパース（解析）され、「モジュールレコード（Module Record）」と呼ばれる静的なデータ構造に変換される。
ここでの変数は、ラッパー関数の引数やローカル変数ではない。「モジュール環境レコード（Module Environment Record）」という、独立したメモリ空間に厳格に隔離される。

  • グローバル汚染の完全な遮断: ESMのトップレベルにおける `this` は、CJSのように `module.exports` を指さず、`undefined` である。
  • ライブバインディング（Live Binding）: ESMのインポートは値のコピーではなく、エクスポート元のメモリ空間への「ライブな参照」である。

このアーキテクチャの違いが、プロダクション環境のパフォーマンスと堅牢性に直結する。

—

2. 【プロダクションコード比較】メモリ管理とスコープ汚染を防ぐ設計

実務でよくあるアンチパターンと、それを防ぐためのモダンな設計パターンを見ていこう。

アンチパターン：CJSでのキャッシュ汚染と意図せぬグローバルスコープの共有

CJSで「シングトンパターン」を実装しようとして、誤ってモジュールスコープ上のミュータブルなオブジェクトを共有してしまうケースだ。

// 【危険なCJSモジュール例】 cache-leak.js
const state = {
users: [] // モジュールスコープ上に存在
};

// リクエストごとに配列が肥大化し、V8ヒープを圧迫する
exports.addUser = (user) => {
state.users.push(user);
};

exports.getUsers = () => state.users;

なぜ非効率なのか？
CJSのモジュールは初回 `require` 時に一度だけ評価され、その結果が `require.cache` に永続的に保持される。`state` 変数はプロセスが生存している限りV8のオールドスペース（Old Space）に居座り続け、ガベージコレクションされない。サーバーサイドアプリケーション（ExpressやNestJSなど）において、これはメモリリークの温床となる。

—

推奨される堅牢な設計：ESMによるイミュータブルなカプセル化とカプセル化ファクトリー

上記の問題を解決するため、ESMの静的解析のメリットを活かし、状態管理を完全にコントロールするプロダクションコードの例を示す。

// 【堅牢なESMモジュール例】 user-store.mjs

// 外部から直接アクセスできないモジュールスコープのプライベート空間
let userCache = Object.freeze([]);

/