CommonJS vs ESM：Node.jsモジュールローダーの裏側と、スコープの迷宮を断つアーキテクチャ設計
コードレビューをしていて、いまだに `require` と `import` を「なんとなく、時代の流れだから」「BabelやTypeScriptがよしなにしてくれるから」という理由で混在させ、モジュールスコープの挙動を理解しきれていないコードに出会うことがある。
テクニカルリードとして言わせてほしい。この2つのモジュールシステムの本質的な違い、すなわち「V8のランタイムレベルでモジュールがどのようにラップされ、変数のスコープが分離されるのか」を理解していないと、プロダクション環境で不可解なメモリリーク、循環参照による `undefined` の嵐、そして非同期境界のデバッグ地獄に直面することになる。
今回は、Node.jsのモジュールローダー（CJS/ESM）が水面下で何を行っているのか、そのメカニズムをV8エンジンの挙動とスコープの観点から徹底的に解剖し、現場で即座に使える堅牢な設計パターンを授けよう。
—
1. CommonJS (`require`) の正体：関数ラッパーと動的スコープ
まずは、長年Node.jsを支えてきたCommonJS（CJS）だ。多くの開発者は `require` を単なるファイルの読み込み関数だと思っているが、それは解像度が甘い。
V8エンジンがCJSファイルをロードするとき、Node.jsは実行前にそのコードを特定の関数ラッパーで包み込む（Wrapする）。概念的には以下のような形だ。
// Node.js内部で実行されるラッパー関数のイメージ
function (exports, require, module, __filename, __dirname) {
// ── あなたが書いたモジュールコードはここに挿入される ──
const path = require(‘node:path’);
let internalState = ‘secret’;
exports.getData = () => internalState;
// ──────────────────────────────────────────────────
}
スコープと変数の見え方の真実
このラッパーのおかげで、CJSモジュール内のトップレベルで宣言された変数（`let`, `const`, `var`）は、グローバルスコープではなく、このラッパー関数のローカルスコープに閉じ込められる。そのため、別ファイルから `require` しても、エクスポート（`module.exports`）に明示的に紐付けない限り、内部変数を外から覗き見ることはできない。
しかし、CJSには致命的な設計上の弱点がある。「同期的な読み込み」と「オブジェクトの参照コピー（浅いコピー）」だ。
// 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` だ。`require` 時に取り出された `count` は、プリミティブ値であるため値そのものがコピーされている。モジュール内の `count` がどれだけインクリメントされようとも、一度分割代入で受け取った変数の値は更新されない。これがCJSにおける状態管理のバグを生む温床となる。
—
2. ECMAScript Modules (`import`) の正体：ライブバインディングと静的解析
一方、モダンな標準規格であるESM（ECMAScript Modules）は、ランタイムの挙動がCJSとは根本から異なる。
ESMはコードの実行前に静的解析（Static Analysis）が行われる。これにより、依存関係のツリーがビルド時に確定し、V8は高度な最適化（Dead Code Eliminationなど）を行うことができる。
そして、ESM最大の武器が 「ライブバインディング（Live Binding）」 である。
先ほどと同様の例をESMで書いてみよう。
// 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` だ。ESMのインポートは単なる値のコピーではなく、エクスポート元モジュールの変数への「ライブな参照（ポインタのようなもの）」としてバインドされる。そのため、エクスポート側で変数が書き換わると、それをインポートしている側のスコープでもリアルタイムに値が変化する。
この挙動の違いを理解していないと、非同期処理やステート管理ライブラリを自作する際に、意図しないデータの不整合（ミュータビリティに起因するバグ）を引き起こすことになる。
—
3. 現場で即座に使える！CJS/ESM混在環境のアンチパターンと正解
実務では、レガシーなCJSライブラリとモダンなESMコードベースが混在するカオスなプロジェクトに遭遇することが多々ある。ここで最もやりがちなのが、`import` 内での `require` の誤用や、`__dirname` の消失によるエラーだ。
❌ ありがちな非効率・脆弱なコード
// .mjsファイル内（ESM）でCommonJSのグローバル変数を使おうとして撃沈する例
import path from ‘node:path’;
// エラー: ReferenceError: __dirname is not defined in ES module scope
const currentDir = __dirname;
const config = require(‘./config.json’); // 拡張子や環境によってはトランスパイルエラーの原因に
⭕ 保守性の高いプロダクションコード（ESM環境のベストプラクティス）
ESM環境において、CJSの `__dirname` や `__filename` に相当する安全なパス解決、およびJSONファイルの安全な読み込みを行うには、以下のように `import.meta.url` と `module` を駆使する。
// server.mjs (テクニカルリードが推す堅牢なモジュール初期化パターン)
import { readFile } from ‘node:fs/promises’;
import { fileURLToPath } from ‘node:url’;
import { dirname, join } from ‘node:path’;
// 1. ESM環境で __dirname と __filename を完璧にエミュレート
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
// 2. 独自のモジュールスコープを持つ設定ローダー関数
async function loadApplicationConfig() {
try {
const configPath = join(__dirname, ‘config’, ‘production.json’);
// 静的解析と非同期I/Oを組み合わせた堅牢な読み込み
const rawData = await readFile(configPath, { encoding: ‘utf8’ });
const config = JSON.parse(rawData);
return Object.freeze(config); // オブジェクトを凍結し、スコープ外からの意図せぬミューテーションを完全防御
} catch.error (err) {
console.error(`[FATAL] 設定ファイルの読み込みに失敗しました: ${err.message}`);
process.exit(1);
}
}
export const appConfig = await loadApplicationConfig();
このコードの美しい点は、`top-level await`（ES2022の機能）を活用してモジュールの初期化と非同期処理を同期させつつ、`Object.freeze` によってモジュールスコープを越えて共有されるデータのイミュータビリティ（不変性）を担保している点だ。
—
4. パフォーマンスとV8ヒープメモリの視座
最後に、モジュールシステムがV8エンジンのメモリ空間とパフォーマンスに与える影響について触れておこう。
1. 循環参照（Circular Dependencies）の耐性
- CJS: 循環参照が発生した場合、途中で不完全な（プロパティがまだ代入されていない）`module.exports` のオブジェクトが返されるため、意図しない `TypeError: Cannot read properties of undefined` が多発する。
- ESM: ライブバインディングのおかげで、循環参照であってもモジュールの評価順序が正しく解決されれば、後から代入される値に正しくアクセスできる（ただし、初期化タイミングの巻き上げ問題には注意が必要）。
2. バンドルサイズとツリーシェイキング（Tree Shaking）
- フロントエンド（Vite, Webpack, Rollup等）やサーバーサイドバンドラーにおいて、CJSは動的な構文（条件分岐の中での `require` など）が許容されるため、静的解析が不可能であり、ツリーシェイキングが効きにくい。
- 一方、ESMは構造が完全に静的であるため、プロダクションビルド時に未使用のコード（Dead Code）をV8のヒープに乗せないよう綺麗に削ぎ落とすことができる。バンドルサイズを劇的に削減したいのであれば、コードベースの完全なESM化はもはや必須条件なのだ。
—
結びにかえて
変数の宣言（`var` / `let` / `const`）がブロックスコープを形作るのと同様に、`require` と `import` はファイルという単位でアプリケーション全体のスコープ境界を定義する極めて重要なアーキテクチャの要石である。
「動けばいい」という実装から脱却し、V8のランタイム挙動、ライブバインディングの特性、そしてメモリ上のスコープ汚染を防ぐイミュータビリティの設計思想を持つこと。それこそが、プロダクションの荒波に耐えうる、真に堅牢なJavaScriptコードを生み出す唯一の道である。
明日のコードレビューでは、チームメンバーの `import` と `require` の使い方に、ぜひ鋭いメスを入れてみてほしい。