V8の深淵：forループにおける `let` のレキシカル環境クローンとメモリ消費の物理的真実
JavaScriptエンジニアの多くは、ES2015で導入された `let` と `const` がブロックスコープをもたらし、`var` のような巻き上げ（Hoisting）に起因するバグを駆逐したことを知っている。しかし、ランタイムの内部構造、とりわけV8エンジンがメモリ空間上で何を行っているかという「物理レイヤ」まで踏み込んで理解している者は少ない。
今回は、`for` ループの初期化式における `let` が引き起こす「レキシカル環境のクローン（Per-Iteration Lexical Environments）」に焦点を当てる。なぜ `let` は `var` よりもメモリを消費するのか、V8のヒープ構造とガベージコレクション（GC）のライフサイクルからそのトレードオフを徹底的に解剖する。
—
1. `var` と `let` のメモリ構造における根本的差異
まず、スコープの概念をランタイムのメモリレイアウトに落とし込んでみよう。
`var` は関数スコープ（またはグローバルスコープ）を持つ。そのため、`for` ループ内で `var` を使って変数を宣言した場合、その変数はループの外側のスコープ（あるいは関数スコープ）に属する単一の変数が使い回される。
一方、`let` はブロックスコープを持つ。ECMAScript仕様書（ES2015以降）では、`for` ループの頭部（head）で宣言された `let` 変数について、「ループの各反復（Iteration）ごとに、新しいレキシカル環境（Lexical Environment）が生成されなければならない」と規定されている。
V8エンジン内での挙動
V8（IgnitionインタプリタおよびTurboFanコンパイラ）において、スコープはContext（コンテキスト）と呼ばれるヒープ上のオブジェクトとして表現される。
- `var` の場合: ループ全体でContextは1つ。変数の値が毎ループ上書きされる。
- `let` の場合: 毎ループ、親Contextを参照しつつ、そのイテレーション専用の新しいContext（あるいは環境レコード）がインスタンス化される。
クロージャが絡む場合を想像してほしい。`var` でループを回すと、非同期処理（`setTimeout` や Promise）の中で参照される変数は「最終的な値」に収束してしまう。これを防ぐために、かつては即時実行関数（IIFE）でスコープを切り出すハックが使われていた。`let` は、このスコープの切り出しを言語仕様レベルで、ループのイテレーションごとに自動実行しているのである。
—
2. 実験：`let` ループが生成するメモリ消費の証拠
以下のコードをNode.js環境（V8）で実行し、メモリプロファイラや `process.memoryUsage()` を用いて観測すると、`let` が引き起こすアロケーションのコストが浮き彫りになる。
‘use strict’;
// V8のヒープ統計を強制的に出力するためのヘルパー
const printMemoryUsage = (label) => {
const used = process.memoryUsage();
console.log(`[${label}]
RSS: ${Math.round(used.rss / 1024 / 1024 100) / 100} MB
HeapTotal: ${Math.round(used.heapTotal / 1024 / 1024 100) / 100} MB
HeapUsed: ${Math.round(used.heapUsed / 1024 / 1024 100) / 100} MB
`);
};
function runVarLoop() {
printMemoryUsage(‘Before var loop’);
const arr = [];
for (var i = 0; i < 1_000_000; i++) {
// クロージャを生成して参照を保持
arr.push(() => i);
}
printMemoryUsage(‘After var loop (Allocated)’);
// 参照を断つ
arr.length = 0;
global.gc && global.gc();
printMemoryUsage(‘After var loop (GC)’);
}
function runLetLoop() {
printMemoryUsage(‘Before let loop’);
const arr = [];
for (let i = 0; i < 1_000_000; i++) {
// 各イテレーションごとに新しいレキシカル環境がクローンされる
arr.push(() => i);
}
printMemoryUsage(‘After let loop (Allocated)’);
// 参照を断つ
arr.length = 0;
global.gc && global.gc();
printMemoryUsage(‘After let loop (GC)’);
}
// 実行時は –expose-gc フラグを付与してください
// 例: node –expose-gc script.js
なぜ `let` はメモリ消費が増えるのか？
1. オブジェクトアロケーションの爆発:
`1,000,000` 回のループにおいて、`let` は（クロージャから参照されている場合、あるいはV8の最適化がスコープをスタック上に逃がせない場合）内部的に環境レコード（Contextオブジェクト）をヒープ上に多数アロケートする。
2. GC（ガベージコレクション）への負荷:
生成された無数のレキシカル環境は、マイナーGC（Scavenge GC / 新世代スペース）からメジャーGC（Mark-Sweep-Compact / 旧世代スペース）への昇格対象となりやすく、GCのサイクルタイム（Stop-the-worldのduration）を悪化させる原因となる。
—
3. V8の最適化（Escape Analysis）と現実のトレードオフ
「じゃあ、パフォーマンスとメモリを気にして全部 `var` に戻すべきか？」という疑問が湧くかもしれない。答えは明確に「No」である。
現代のV8エンジン（TurboFan）は非常に洗練されている。もしループ内で宣言された `let` 変数が、ループの各イテレーションを超えて保持されるクロージャから一切参照されない場合、V8のエスケープ解析（Escape Analysis）が働き、ヒープへのContextアロケーションを完全に最適化（スカラー置換やスタック割り当てへのダウングレード）する。
つまり、単に同期的な処理の中で一時変数として `let i` を使っているだけの場合、ランタイムレベルで `var` と同等のパフォーマンスとメモリフットプリントに最適化される。
メモリ消費が問題になる唯一の境界線
問題が顕在化するのは、「ループ内で生成されたレキシカル環境への参照が、ループの外（または非同期のマイクロタスク・マクロタスクキュー）にリークする場合」である。
先ほどのコードのように、各イテレーションの変数をキャプチャするクロージャ配列を作り、それを保持し続けた場合、V8はレキシカル環境をヒープ上に保持し続けざるを得ない。これが「レキシカル環境のクローンがメモリを圧迫する」メカニズムの正体である。
—
4. セキュリティとサプライチェーン：スコープ汚染と脆弱性のリスク
このスコープとメモリの仕組みは、V8の内部挙動に留まらず、セキュリティ、特にプロトタイプ汚染（Prototype Pollution）やスコープチェーンを悪用した脆弱性ハックとも深く結びついている。
Node.jsのバックエンド環境やサードパーティ製ライブラリのバンドルコードにおいて、深層のスコープ汚染や予期せぬ変数キャプチャが発生した場合、アロケートされたレキシカル環境自体が不整合を起こし、メモリ上の機密データ（クロージャが保持する高レイヤのコンテキスト、例えば認証トークンやデータベースのコネクション情報など）が意図せず生存し続ける、あるいは不正に書き換えられる温床となる。
特に、非同期イベントループ（`process.nextTick`, `Promise.resolve().then()`, `setTimeout`）のマイクロタスクキューが高速に消化される現代のNode.jsアーキテクチャでは、肥大化したレキシカル環境がGCされずにヒープ内に残留し続けることで、メモリリークを起因とするDenial of Service (DoS) 攻撃のベクトルになり得る。
—
5. シニアエンジニアが取るべきアーキテクチャ上の防壁
極限のパフォーマンスとメモリ効率が求められる高スループットなMicroservicesや、リアルタイムWebsocketサーバーを構築する際、我々チーフアーキテクトは以下の設計原則を遵守すべきである。
1. 大規模配列・ストリーム処理での不要なクロージャ生成の排除:
`Array.prototype.map` や `for…of` / `for` ループ内で、無名関数やアロー関数を動的に大量生産し、それを外側の配列にプッシュするようなパターンは、レキシカル環境のライフサイクルを不必要に引き伸ばす。イテレータパターンやジェネレータ（`function`）を活用し、遅延評価（Lazy Evaluation）を導入せよ。
2. メモリプロファイリングの常態化:
CI/CDパイプラインやステージング環境において、Heap Snapshotを取得し、`Context` や `Closure` 領域のメモリフットプリントが意図せず肥大化していないか常時監視する仕組みを構築する。
3. 明示的なスコープの破棄:
大量のデータを扱うバッチ処理やメモリ集約型のワーカープロセスでは、不要になったデータ参照を `null` で上書きするだけでなく、大きなスコープを伴う処理を独立した関数（Function Scope）に切り出し、V8のGCが即座にScavengeできるようにコードの物理境界をデザインする。
—
結言
`let` は魔法の構文ではない。それは開発者の認知負荷を下げる代わりに、ランタイムに「レキシカル環境の管理」という明確なコストを支払わせる言語仕様である。
V8のコンパイルパイプライン、メモリ上のContext構造、そしてガベージコレクションの挙動まで見通す視点を持つこと。それこそが、ただ動くコードを書くプログラマと、システムを極限まで最適化するシニアエンジニアを分かつ境界線なのである。