JavaScriptのスコープ階層を可視化する：Lexical EnvironmentとEnvironment Recordの構造
こんにちは。長年JavaScriptランタイムの挙動と向き合ってきた者として、今日あなたと共有したいのは、日々の開発で何気なく使っている「変数スコープ」の正体です。
多くのエンジニアは、`let`や`const`、あるいは閉包（Closure）を「なんとなく変数が見える範囲」として理解しています。しかし、V8をはじめとするモダンなJavaScriptエンジンが内部で構築しているLexical Environment（語彙的環境）とEnvironment Record（環境レコード）の物理構造にまで踏み込んでいる人はそう多くありません。
この記事では、ECMAScript仕様書の奥底にある抽象概念を剥ぎ取り、ランタイムがメモリ上でどのように変数を解決（Resolution）しているのか、その全貌を解き明かします。V8のJITコンパイル、隠しクラス（Hidden Class）、そしてプロトタイプ汚染がスコープやオブジェクトモデルにどう影響するのかまで、妥協のない低レイヤの知見をお届けします。
—
1. ECMAScript仕様書が定義するスコープの物理実体
JavaScriptのコードが実行される時、ランタイムは単に変数をハッシュマップに放り込んでいるわけではありません。ECMAScript仕様（ES2015以降）では、スコープはLexical Environmentという概念によって厳密にモデル化されています。
Lexical Environmentは、以下の2つの主要な要素で構成されています。
1. Environment Record（環境レコード）: スコープ内で宣言された識別子（変数名、関数名、引数など）と値の対応関係を実際に保持する領域。
2. Outer Lexical Environment Reference（外部語彙的環境への参照）: 外側の（ネストされた祖先の）Lexical Environmentへのポインタ。これがスコープチェーンの正体です。
Environment Recordの内部継承ツリー
Environment Record自体も、仕様上ではいくつかのサブタイプに分岐しています。
- Declarative Environment Record: `let`、`const`、`class`、`import`、そして関数宣言やcatch節の引数を管理します。変数名と値のバインドを直接保持します。
- Object Environment Record: 主にグローバルスコープ（`window`や`global`）や`with`文の内部で使用されます。識別子のバインドを、通常のJavaScriptオブジェクト（Binding Object）のプロパティとしてマップします。
- Function Environment Record: 関数の実行コンテキストのために生成され、`this`のバインド、`super`の参照、そしてアロー関数ではない通常の関数であれば`arguments`オブジェクトの管理を行います。
—
2. V8エンジンにおけるスコープチェーンの解決アルゴリズム
コード内で変数が参照されたとき、V8（IgnitionインタプリタおよびTurboFanコンパイラ）はどのようにその変数を特定しているのでしょうか。
Identifier Resolution（識別子解決）のステップ
1. カレントのEnvironment Recordの走査:
現在実行中のコードが属するLexical EnvironmentのEnvironment Recordに、目的の識別子が登録されているかを確認します。
2. TDZ（Temporal Dead Zone: 時間的デッドゾーン）のチェック:
もし識別子が`let`または`const`で宣言されており、まだ初期化（Initialization）の文に到達していない場合、V8は`ReferenceError`をスローします。これは、Declarative Environment Recordが持つ「uninitialized（未初期化）」という内部状態フラグによって厳密に制御されています。
3. 外部参照の辿り（Scope Chaining）:
カレントのEnvironment Recordに見つからない場合、`Outer Lexical Environment Reference`を辿って親のLexical Environmentへ移動します。このプロセスを、変数がヒットするか、あるいは外部参照が`null`（グローバル環境の外側）になるまで再帰的（あるいはイテレーティブ）に繰り返します。
// スコープチェーンとEnvironment Recordのネストを体感する極限のコード
const globalSecret = “V8-Root-Secret”;
function createSecureVault(masterKey) {
// Function Environment Record が生成される
const vaultId = Math.random().toString(36);
let accessCount = 0; // Declarative Environment Record に保持
return {
access: function(inputKey) {
// この関数オブジェクトは [[Environment]] 内部スロットを通じて
// createSecureVault の Lexical Environment をキャプチャ（クロージャ）する
accessCount++;
if (inputKey === masterKey) {
return `Access Granted. Vault ID: ${vaultId}, Count: ${accessCount}, Secret: ${globalSecret}`;
}
return “Access Denied”;
}
};
}
const vault = createSecureVault(“1234”);
console.log(vault.access(“1234”));
// 変数探索の軌跡:
// 1. access 関数の Function Environment Record
// 2. createSecureVault の Lexical Environment (vaultId, accessCount, masterKey がある)
// 3. グローバル Lexical Environment (globalSecret がある)
—
3. 隠しクラス（Hidden Class / Map）とインラインキャッシュ（IC）の最適化
V8は、動的言語であるJavaScriptの変数アクセスを高速化するため、Hidden Class（V8内部用語では `Map` と呼ばれる）とInline Caching（インラインキャッシュ）という強力な最適化機構を持っています。
オブジェクトプロパティの高速化とスコープの類似性
Object Environment Record（グローバルスコープや`with`文）や通常のオブジェクトにおいて、プロパティのオフセット（メモリ上の物理的な位置）はHidden Classによって管理されます。
// V8の Hidden Class / Map の遷移を意識したコード
function Point(x, y) {
this.x = x; // ここで Hidden Class 0 が生成され、プロパティ ‘x’ のオフセットが決定される
this.y = y; // ここで Hidden Class 1 に遷移し、’y’ のオフセットが追加される
}
const p1 = new Point(1, 2);
const p2 = new Point(3, 4);
// p1 と p2 は同じ Hidden Class を共有するため、V8のICはプロパティアクセスをネイティブコードレベルで高速化（単なるメモリのオフセット加算）する
しかし、スコープチェーンの途中に `with` 文や `eval` が存在すると、V8はコンパイル時にどのEnvironment Recordにどの変数が紐づいているかを静的に静的解析（Scope Analysis）できなくなります。これをコンパイル時の最適化の破壊（Optimization Bailout）と呼びます。動的なスコープ拡張は、V8に「スロースタック（Slow-path）」を通わせるため、パフォーマンスが劇的に低下します。
—
4. プロトタイプ汚染（Prototype Pollution）とスコープ・オブジェクトモデルの脆弱性
変数の解決メカニズムやオブジェクトのプロパティ探索の仕様を悪用した最も深刻な攻撃の一つが、プロトタイプ汚染（Prototype Pollution）です。
JavaScriptでは、すべてのオブジェクトが `__proto__` （あるいは `Object.prototype`）を介してプロトタイプチェーンを持っています。もし、再帰的なマージ関数やJSONパースの脆弱性により、不特定のユーザー入力から `Object.prototype` に任意のプロパティを挿入できてしまった場合、どうなるでしょうか。
// プロトタイプ汚染の概念実証（PoC）とその影響範囲
const payload = JSON.parse(‘{“__proto__”: {“isAdmin”: true}}’);
// 安全ではない再帰的マージのシミュレーション
function unsafeDeepMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
unsafeDeepMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
const benignObject = {};
unsafeDeepMerge(benignObject, payload);
// 恐るべきことに、すべてのオブジェクトのプロトタイプが汚染される
const anotherObject = {};
console.log(anotherObject.isAdmin); // true が出力されてしまう！
サプライチェーンとRCE（リモートコード実行）への跳躍
このプロトタイプ汚染がなぜサプライチェーン攻撃におけるRCEに直結するのか。それは、多くのサードパーティ製ライブラリ（テンプレートエンジン、ORM、ルーターなど）が、オブジェクトの設定オプションを処理する際に `Object.prototype` に影響を受けるためです。
例えば、テンプレートエンジンが内部で `options` オブジェクトを走査し、そこに `debug: true` や `execPath` などの設定プロパティを動的に探す処理があったとします。プロトタイプが汚染されていると、開発者が意図しない設定値が勝手にインジェクトされ、テンプレート内での任意のコード実行（SSTI）や、Node.jsの内部モジュール（`child_process`など）のパラメータ改ざんを通じたリモートコード実行（RCE）の踏み台となります。
防御策:
1. `Object.freeze(Object.prototype)` を用いてプロトタイプの改ざんをイミュータブルにする。
2. オブジェクトのマージを行う際は、キーが `__proto__`、`constructor`、`prototype` であるものを厳格に弾く（Sanitization）。
3. Mapオブジェクトを活用し、プロトタイプチェーンを持たない純粋なキーバリューーストレージを使用する。
—
5. まとめ
JavaScriptの変数の振る舞いは、単なる「書き方のルール」ではありません。それはECMAScriptという厳格な仕様書に裏打ちされたLexical EnvironmentとEnvironment Recordというデータ構造によって正確に計算されています。
シニアエンジニアやセキュリティ研究者として私たちが持つべき視点は、コードの表面的な美しさだけではなく、そのコードがV8エンジンのメモリ空間でどのように解釈され、どのような隠しクラスを生み出し、どのパス（高速パスか最適化除外パスか）を通るのかを脳内で完全にトレースできる能力です。
ランタイムの深淵を掌握し、堅牢かつ極限まで最適化されたアーキテクチャを構築していきましょう。