なぜループ内のlet宣言は「ブロックスコープのクローン」を生成するのか：メモリ消費とガベージコレクションの挙動
JavaScriptの言語仕様がES2015（ES6）で`let`と`const`を獲得した日、我々フロントエンド・バックエンドを問わないエンジニアは、`var`が引き起こす関数スコープの呪縛から解放された。しかし、その糖衣構文の裏側で、V8をはじめとするモダンなJavaScriptエンジンがどのようなメモリの魔術を行っているか、その物理レイヤにまで踏み込んで思考したことがあるだろうか。
特に`for (let i = 0; i < N; i++)`という、一見して枯れ切ったイディオムの内部では、V8のランタイムが単なる「変数の上書き」ではなく、反復ごとに独立したレキシカル環境のインスタンス化（実質的なクローニング）を行っている。
本稿では、このループ内`let`がV8エンジンのヒープメモリ空間やガベージコレクション（GC）、ひいてはJITコンパイルの最適化パイプラインにどのような負荷と恩恵をもたらすのか、その深層を解き明かす。
—
1. V8の内部構造：なぜ `let` はループ内で「生き続ける」のか
`var`を使った古典的なループを思い出してほしい。
// 古典的な var によるループ
for (var i = 0; i < 3; i++) {
setTimeout(function() {
console.log(i); // 出力: 3, 3, 3
}, 100);
}
このコードが `3, 3, 3` を出力するのは、関数スコープを持つ `i` がただ一つのメモリ領域（レキシカル環境の外側、あるいは変数環境）に存在し、ループの終端ですでに `3` に達したその値が、非同期のクロージャから参照され続けるからだ。
対して、`let` を用いた場合、仕様（ECMAScript Specification）は厳格に異なる振る舞いを要求する。
// モダンな let によるループ
for (let i = 0; i < 3; i++) {
setTimeout(function() {
console.log(i); // 出力: 0, 1, 2
}, 100);
}
なぜ `0, 1, 2` が得られるのか。仕様書（ECMAScript 2015以降）の `ForBodyEvaluation` 抽象操作を読むと、ループの各イテレーション（反復）の開始時に、新しいレキシカル環境（Lexical Environment）が生成され、前回のイテレーションにおける変数の値で初期化されることが規定されている。
V8エンジンの内部表現（Ignition / TurboFan）において、これは単なるシンタックスシュガーではない。各反復は、物理的に分離されたスコープオブジェクト（Context）をヒープ上に生成している。つまり、ループが回るたびに、`i` という変数は「名前が同じ別のメモリ領域」へとバインドし直されているのだ。
—
2. メモリ消費とヒープの物理挙動：隠しクラス（Hidden Classes / Maps）の生成コスト
シニアエンジニアとして懸念すべきは、「反復のたびにスコープが作られるなら、メモリリークやアロケーションのオーバーヘッドが深刻化するのではないか？」という点だ。
V8は、JavaScriptの動的なオブジェクト構造を高速化するために Hidden Class（V8内部では `Map` と呼ばれる） とインラインキャッシュ（IC）を使用する。ループ内で生成されるブロックスコープも、内部的にはプロパティを持つ特殊なコンテキストオブジェクトとして扱われる。
以下の実験的なコードで、V8のメモリ空間の変化を追ってみよう。
// Node.js環境でのメモリプロファイリングを意識したベンチマーク的コード
function heavyLoopAllocation(n) {
const closures = [];
for (let i = 0; i < n; i++) { // 各イテレーションで独立したレキシカル環境が生成され、 // クロージャによってキャプチャされるため、GCの対象外としてヒープに残留する const captured = i; closures.push(function() { return captured; }); } return closures; } // 実行時のメモリ使用量を強制的に確認するため、グローバルに参照を保持 global.leakedClosures = heavyLoopAllocation(1000000); console.log(`Heap Used: ${process.memoryUsage().heapUsed / 1024 / 1024} MB`);
V8エンジンの最適化とGCの挙動
1. アロケーションの最適化（Escape Analysis）:
もしループ内で生成された `let` 変数が、そのスコープの外（クロージャなど）に持ち出されない場合、V8のJITコンパイラ（TurboFan）のエスケープ解析（Escape Analysis）が働き、このスコープオブジェクトのヒープアロケーションを完全に排除する。変数 `i` は単なるCPUレジスタ上の値、あるいはスタック上のプリミティブとして扱われ、メモリ消費は `0` に等しくなる。
2. クロージャによるヒープ残留:
しかし上記のコードのように、クロージャが変数をキャプチャして外部に「逃げた（Escaped）」場合、エスケープ解析は失敗する。V8は各イテレーションごとのコンテキストをヒープ上に確保せざるを得なくなる。
結果として、100万回のループであれば、100万個の独立したコンテキストオブジェクトがV8の老齢世代（Old Generation）または若年世代（New Generation）のメモリ空間を圧迫する。
—
3. ガベージコレクション（GC）のライフサイクルとスイープ
V8のガベージコレクタ（Orinoco）は、世代別GC（Generational GC）を採用している。
- Scavenger（新生代GC）:
ループ内で一時的に生成され、すぐにスコープが消滅する `let` 変数（クロージャにキャプチャされていないもの）は、新生代のセミスペース（Semi-space）に高速に割り当てられ、次のイテレーション、あるいはブロック抜けた瞬間に瞬時に回収（あるいは無視）される。このコストは極めて低い。
- Mark-Sweep-Compact（老齢世代GC）:
先ほどのように、クロージャによってループ内の `let` 変数が参照され続けた場合、それらのスコープコンテキストは新生代から老齢世代へ昇格（Promotion）する。ここで注意すべきは、「1つのループから生成された複数のクロージャが、それぞれ異なるレキシカル環境のインスタンスを保持しているため、メモリの局所性が分断される」という点だ。
これにより、CPUキャッシュのヒット率が低下し、GCのマークフェーズにおける走査コストが増大する。
—
4. セキュリティとランタイム防壁：スコープクローンが防ぐ脆弱性
この「ブロックスコープのクローン」挙動は、単なるメモリ効率の話に留まらない。サプライチェーン攻撃やプロトタイプ汚染（Prototype Pollution）のコンテキストにおいて、スコープの分離がどのようにセキュリティ防壁として機能するかを理解することは、チーフアーキテクトとして必須の素養である。
古典的な `var` やグローバルスコープの共有は、非同期処理の競合状態（Race Condition）だけでなく、意図しない変数の上書き、さらには高度なスコープインジェクションの脆弱性を生む温床となっていた。
非同期処理における意図しない状態共有の排除
セキュリティインシデントの多くは、「非同期コールバックが実行される頃には、共有変数の値が改ざんされていた」という仕様の誤認から起きる。例えば、リクエストごとのコンテキストを処理するNode.jsのミドルウェアで `var` を使った場合、並行処理（Concurrency）の中で変数が汚染されるリスクがある。
// 脆弱なパターン（varによる状態共有の危険性）
function handleRequestsVulnerable(requests) {
for (var i = 0; i < requests.length; i++) {
// 非同期I/Oを模擬
setTimeout(() => {
// 意図したリクエストIDとは異なる、ループ終了後の値が参照されるリスク
processRequest(requests[i]);
}, 1050);
}
}
`let` を用いたブロックスコープのクローンは、各イテレーションの変数をイミュータブルに近い形でカプセル化する。これにより、スコープ外からの意図しない干渉や、非同期境界を越えた値の意図せぬ書き換えを防ぎ、メモリ安全性を高める防壁として機能する。
—
5. 実戦的アーキテクチャ設計：高パフォーマンスなループ記述の極意
このランタイム特性を踏まえ、我々エンジニアはプロダクションコードにおいてどう振る舞うべきか。
アンチパターン：不必要なクロージャ生成によるGCプレッシャー
// 【悪手】数百万件の巨大配列を処理するループ内で、毎回クロージャとletスコープを爆発させる
const results = [];
for (let i = 0; i < massiveData.length; i++) {
const processed = heavyCompute(massiveData[i]);
// 無名関数をプッシュすることで、エスケープ解析が無効化され、
// 毎回のループでヒープアロケーションが発生する
results.push(() => processed);
}
最適化されたパターン：スコープの巻き戻しとアロケーションの抑制
もしクロージャが必要ないのであれば、あるいはパフォーマンスが極限まで求められるホットパス（Hot Path）であれば、変数のスコープをループの外側に引き出す、あるいは伝統的な配列イテレーションや手続き型のアプローチを適用し、V8のJITがレジスタ割り当てを最大限最適化できるようにする。
// 【推奨】ホットパスにおける最適化されたループ
// クロージャを作らず、プリミティブ値のみで完結させることで、
// V8はエスケープ解析によりスタック/レジスタ上でこの処理を完結させる。
const results = new Float64Array(massiveData.length);
let currentData;
for (let i = 0; i < massiveData.length; i++) { currentData = massiveData[i]; results[i] = heavyComputeOptimized(currentData); } ---
終わりに
JavaScriptの `let` は、単に「ブロックスコープを提供する便利な `var` の代用品」ではない。それはV8エンジンのメモリ管理、JITコンパイルのエスケープ解析、そしてガベージコレクションのライフサイクルと密接に結合された、緻密なランタイム制御機構である。
仕様の裏側にある物理レイヤの挙動を看破し、CPUキャッシュとヒープメモリに敬意を払ったコードを書くこと。それこそが、真のシニアエンジニア、そしてアーキテクトに求められる極限の知見なのである。