【テクニカル・上級編】レキシカル環境と環境レコードの内部構造 – JavaScript実践ガイド

JavaScriptの深淵：レキシカル環境と「見えない変数」の正体

多くのエンジニアが `const` や `let` を「なんとなく」使い分けているが、現場で発生する不可解なメモリリークや、非同期処理におけるクロージャのバグを根本から叩き潰すには、エンジンが裏側でどうやって変数を管理しているかを知る必要がある。

今日は、V8エンジンをはじめとするモダンJSエンジンが変数をどう「環境レコード」に詰め込んでいるのか、その内部構造を解剖していこう。

—

1. 環境レコード：メモリ上の「名前空間」の実体

JavaScriptの変数は、魔法のようにメモリに浮かんでいるわけではない。コードが実行される際、エンジンはレキシカル環境（Lexical Environment）という構造を生成する。これには以下の2つの要素が含まれている。

1. 環境レコード（Environment Record）: 変数と関数の宣言を実際に保持する場所。
2. 外部レキシカル環境への参照: スコープチェーンを遡るためのポインタ。

特に重要なのが「環境レコード」の型だ。`let` や `const` で宣言された変数は、Declarative Environment Record（宣言的環境レコード）に配置される。これは `var` のようにグローバルオブジェクトにプロパティとして付与されるものとは全くの別物だ。

なぜ `let` と `const` は「巻き上げ」られないのか？

`var` は生成フェーズで `undefined` で初期化されるが、`let` は「一時的死域（TDZ: Temporal Dead Zone）」という状態に置かれる。これは、宣言行に到達するまで、その変数へのアクセスが許可されない状態だ。

// TDZのリアルな挙動
{
// ここで console.log(a) を実行すると ReferenceError
// なぜなら、Declarative Environment Recordには存在するが、
// 「初期化されていない」というフラグが立っているからだ。
let a = 42;
console.log(a); // 42
}

この「初期化フラグ」のチェックは、エンジンの最適化パスにおいて非常に高速に行われる。`var` を廃絶すべき最大の理由は、この「初期化フラグ」のチェックをコンパイラに任せず、人間が脳内で管理しなければならない点にある。堅牢なコードは、エンジンに判断を委ねられる構造になっているべきだ。

—

2. 非同期の競合を「環境レコード」から読み解く

非同期処理でよくあるのが、「クロージャが古い変数の値を掴んでしまう」という問題だ。これはレキシカル環境がループのたびに新しく生成されるか、あるいは共有されるかという仕様に起因する。

以下のコードを見てほしい。

// 非同期処理における環境レコードの罠
for (var i = 0; i < 3; i++) { setTimeout(() => console.log(i), 100);
}
// 出力: 3, 3, 3
// なぜか？ varは関数スコープであり、ループごとに新しい環境レコードを作らないから。
// すべてのループが「同じ環境レコード」にある同一の i を参照し、完了時には3になっている。

for (let j = 0; j < 3; j++) { setTimeout(() => console.log(j), 100);
}
// 出力: 0, 1, 2
// なぜか？ letはブロックスコープ。ループの各イテレーションごとに
// 「独立した新しい環境レコード」が生成され、jがキャプチャされるからだ。

この挙動を理解していれば、「非同期処理のループで `var` を使うな」というルールが単なる宗教的な教義ではなく、エンジンのメモリ管理仕様に基づいた合理的な判断であることがわかるはずだ。

—

3. パフォーマンス最適化の観点から：隠しクラスと最適化

エンジンの内部構造を意識したコーディングは、メモリ消費にも直結する。V8エンジンは、同じ構造のオブジェクトを生成する際、Hidden Class（隠しクラス）という内部的なテンプレートを生成してアクセスを高速化する。

変数のスコープを極限まで狭く（ブロックスコープ化）することは、単に可読性を上げるだけではない。「どの変数が不要になったか」をガベージコレクタ（GC）がより迅速に判断できるようになり、メモリ効率が劇的に向上する。

function heavyProcess() {
// 不必要な大きな変数を広域に置かない
{
const bigData = new Array(1000000).fill(0);
// …処理
} // このスコープを抜けた時点で、bigDataはGCの対象になりやすくなる

// スコープ外ではbigDataは到達不能（Unreachable）となり、
// エンジンは速やかにメモリを解放できる。
}

—

結論：プロフェッショナルであるということ

「変数名が被らなければいい」というレベルのコーディングは卒業しよう。

`const` をデフォルトにする（イミュータビリティとスコープの明確化）。
`let` は再代入が必要な場合のみ使用する。
`var` は歴史的遺物として記憶から削除する。

これらの選択は、単なる好みではない。ブラウザエンジンという巨大な機械が、あなたの書いたコードをいかに効率よく、バグなく解釈できるか、その一点に集約される。

コードは計算機のためのものだ。エンジンが内部でどのような環境レコードを構築し、どのタイミングでメモリを解放するのか。そのシミュレーションを頭の中で行えるようになった時、あなたは真の意味で「フロントエンド・アーキテクト」の領域に足を踏み入れているはずだ。

さあ、エディタを開こう。あなたのコードは、まだ最適化できる。