モジュールスコープとグローバルスコープの境界：ブラウザのscriptタグとES Modulesのメモリ空間の物理的実態
JavaScriptの実行モデルは、長年にわたる仕様の拡張とともに「いかにしてグローバル汚染を防ぎ、モジュール性を担保するか」という戦いの歴史であった。`var`の関数スコープに端を発し、ES2015（ES6）の`let`/`const`によるブロックレベルスコープ、そして`type=”module”`およびES Modules（ESM）による完全な名前空間の隔離へと進化した。
本稿では、ブラウザの伝統的なクラシカルな`
// app.js
const modulePrivateVar = "Secret";
console.log(this); // undefined （クラシック・スクリプトの window とは異なる）
1. グローバルオブジェクトへの自動アタッチの排除
モジュール内のトップレベルで宣言された`const`、`let`、`var`、さらには関数宣言であっても、それらは`window`オブジェクトのプロパティには一切ならない。これらはV8のヒープ上において、そのモジュールインスタンス専用の「Module Environment Record（モジュール環境レコード）」のなかに閉じ込められる。
2. 静的解析（Static Analysis）とリンケージ
ESMの最大の特徴は、コードの実行前（パース時）に依存関係のグラフが完全に確定する点にある。
V8はAST（抽象構文木）を構築する段階で、`import`および`export`を静的に解決する。これにより、実行時の動的な名前解決コストがゼロになり、JITコンパイラ（Turbofan）は変数のメモリアドレスを極限まで最適化（レジスタへの直接割り当てなど）できる。
---
3. Node.jsにおけるCommonJS (CJS) とのメモリ空間の比較
サーバーサイドJavaScriptのデファクトであるNode.jsにおけるCommonJSと、ネイティブESM（`.mjs` または `"type": "module"`）のメモリ空間の構造的な違いを整理する。
CommonJSの裏側：モジュールラッパー関数
Node.jsでCommonJSを用いる際、すべてのファイルは実行前にランタイムによって以下の関数ラッパーで包み込まれる。
// Node.jsが内部的に生成するラッパー関数の概念モデル
function (exports, require, module, __filename, __dirname) {
// 開発者が書いたコードはここにスコープされて注入される
const localVariable = "CJS local";
module.exports = { localVariable };
}
このラッパーのおかげで、CJSファイル内のトップレベル変数もグローバルスコープを汚染せず、各ファイル固有のスコープに閉じ込められる。しかし、これはあくまで「関数スコープによるカプセル化」であり、ESMのような厳密な静的リンク（Live Binding）とは異なる。
Live Binding vs コピー値
CJSの`module.exports`は、オブジェクトのプロパティや値の「コピー」または「参照（非ライブ）」を渡す。一方、ESMの`export`はLive Binding（ライブバインディング）という極めて強力な仕組みを採用している。
// counter.js (ESM)
export let count = 0;
export function increment() {
count++; // エクスポート元の変数が書き換わると、インポート側でも即座に値が連動する
}
インポート側でこの変数を読み込むと、値のコピーではなく、モジュール環境レコード内のメモリセルへのポインタが直接共有される。これにより、循環参照（Circular Dependency）が発生した際にも、CJSのような部分的な未初期化オブジェクトの露呈を防ぎ、安全に状態を共有できる。
---
4. セキュリティ的脅威：プロトタイプ汚染とモジュールスコープの防壁
シニアエンジニアやセキュリティ研究者が最も注視すべき領域が、このスコープとメモリ空間の隙間を突く攻撃ベクター、特にプロトタイプ汚染（Prototype Pollution）とリモートコード実行（RCE）の関係性である。
プロトタイプ汚染のメカニズム
JavaScriptのすべてのオブジェクトは、プロトタイプチェーンを通じて`Object.prototype`につながっている。不適切なオブジェクトのマージ処理（Deep MergeやJSONの不安全なパース）により、`Object.prototype`に任意のプロパティが注入されると、アプリケーション全体に影響が波及する。
// 脆弱なマージ関数のシミュレーション
function maliciousMerge(target, source) {
for (let key in source) {
if (typeof source[key] === 'object') {
if (!target[key]) target[key] = {};
maliciousMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
}
// 攻撃ペイロードの投入
const payload = JSON.parse('{"__proto__": {"polluted": "RCE_VECTOR"}}');
maliciousMerge({}, payload);
// すべてのオブジェクトが汚染される
console.log({}.polluted); // "RCE_VECTOR"
なぜESM環境はこの脅威に対する強固な防壁となるのか？
クラシックなスクリプトやCJS環境、あるいはグローバル変数に依存したコードベースでは、意図しないプロトタイプへのアクセスや、グローバルオブジェクトを介した意図しないプロパティの書き換えが容易に発生する。
しかし、厳格モード（Strict Mode）が強制され、変数がモジュールスコープという изолиされたメモリ空間に閉じたES Modulesでは、グローバルオブジェクトやビルトインオブジェクトのプロトタイプチェーンに依存した暗黙的なバインディングが大幅に排除される。
さらに、import/exportされる識別子はコンパイル時に検証されるため、動的なプロパティインジェクションによる名前空間の乗っ取りが極めて困難になる。これが、モダンなフロントエンドアーキテクチャおよびセキュアなNode.jsアプリケーションにおいて、ネイティブESMへの移行が強く推奨されるアーキテクチャ上の根拠である。
---
5. チーフアーキテクトからの提言
JavaScriptの変数の挙動を「そういう仕様だから」と表面的に理解しているうちは、大規模なプロダクトのメモリリークや、巧妙なサプライチェーン攻撃の兆候を見抜くことはできない。
- ブラウザの `