ループ内での `let` 宣言が生成する「ブロックスコープのクローン」の物理的実態：V8エンジンとスコープチェーンの深層
JavaScriptの歴史において、`var` から `let` / `const` への移行は、単なる「ブロックスコープの導入」という表層的な文法変更に留まらない。V8をはじめとするモダンJSエンジンにおけるメモリ管理、JITコンパイル、そしてクロージャのライフサイクルにパラダイムシフトをもたらした。
特に、`for (let i = 0; i < 3; i++)` というイディオムが内部でどのように処理されているかを知ることは、シニアエンジニアとしてランタイムの挙動を完全に脳内トレースするための必須条件である。 本稿では、ループ内における `let` 宣言がV8エンジンのメモリ空間とスコープチェーンにどのような物理的変化をもたらすのか、その深層を解き明かす。 ---
1. 伝統的悪夢：`var` と関数スコープの限界
まず、比較対照として `var` が抱えていた根本的な構造的欠陥を振り返る。`var` は関数スコープまたはグローバルスコープしか持たない。
for (var i = 0; i < 3; i++) { setTimeout(function() { console.log(i); // 何が出力されるか？ }, 100); } // 出力: 3, 3, 3 なぜ `0, 1, 2` ではなく `3` が3回出力されるのか。 V8のメモリモデルにおいて、`var i` はループの外側（親スコープ、あるいはグローバル）にたった1つの変数スロットしか確保しない。非同期の `setTimeout` コールバックが実行される頃には、ループは既に完了しており、共有された単一の変数 `i` の値は `3` に達している。
これを回避するために、かつて我々は即時実行関数（IIFE: Immediately Invoked Function Expression）を駆使して強制的にスコープを生成し、クロージャを通じて値をとじ込めるという冗長なハックを強いられていた。
—
2. `for (let i = …)` の隠された仕様：反復ごとの「環境クローン」
ES2015（ES6）で導入された `let` は、この問題を言語仕様（ECMAScript Specification）のレベルで根底から解決した。スペック上、`for` 文の頭で宣言された `let` は、「ループの各反復（Iteration）ごとに、新しい束縛（Binding）が作成される」と定義されている。
これをV8エンジンの内部実装（Ignition / TurboFan）の観点から見ると、以下のような物理現象が起きている。
1. ヘッドスコープの生成: `for` ループの初期化部で宣言された `let i` は、ループブロック全体を包む「Outer Loop Environment（外側ループ環境）」を形成する。
2. 反復ごとの環境レコード（Environment Record）のインスタンス化: ループが1回回る（Iteration）たびに、V8のヒープ上には新しいLexical Environment（レキシカル環境）のインスタンスが動的に生成（クローン）される。
3. 値のキャプチャ: そのイテレーション時点における `i` の値が、新しく生成された環境レコードの中に安全に保存される。
コードによる検証とメモリの挙動
以下のコードを見てほしい。
const funcs = [];
for (let i = 0; i < 3; i++) { // 各反復で生成されるブロックスコープをキャプチャするクロージャ funcs.push(function() { console.log(i); }); } funcs[0](); // 0 funcs[1](); // 1 funcs[2](); // 2 V8のヒープ（Heap）上では、`funcs` アレイに格納された3つの無名関数（クロージャ）は、それぞれ異なるメモリ番地を指す別個の Lexical Environmentへの参照（[[HomeObject]] や Outer Context リンク）を保持している。
そのため、関数が実行されるタイミングで、それぞれの環境レコードから正しい `i` の値（0, 1, 2）がスレッドのレジスタへとロードされるのである。
—
3. V8エンジン（Ignition / TurboFan）の最適化とスコープの隠蔽
「反復ごとに変数を生成する」と聞くと、ガベージコレクション（GC）の負荷やメモリ消費量が跳ね上がるのではないかと懸念するアーキテクトも多いだろう。しかし、V8のパイプラインは非常にスマートにこれを最適化している。
1. 逃げ解析（Escape Analysis）とスタック割り当て
もしループ内で生成されたクロージャがそのスコープの外に「逃げない（Escapeしない）」場合、TurboFan（最適化コンパイラ）は、ヒープではなくスタック領域（あるいはレジスタ上）にインライン展開、またはスカラー置換（Scalar Replacement）を行う。これにより、ヒープアロケーションのオーバーヘッドは完全に相殺される。
2. コンテキスト割り当て（Context Allocation）
逆に、前述の例のようにクロージャによって変数がスコープ外に「逃げる」場合、V8はコンテキストオブジェクト（Context Object）をヒープ上に構築する。
`var` の場合は全反復で「1つのコンテキストの値を書き換え続ける」のに対し、`let` の場合は「反復回数分、コンテキストオブジェクトのシャローコピー（あるいは独立したインスタンス）が生成される」ことになる。
ここで注意すべきは、過剰なクロージャの生成はV8のマイナーGC（Scavenger）に負担をかけるという点だ。極限までパフォーマンスが要求されるホットパス（Hot Path）では、ループ内での無闇な関数定義やクロージャの生成は避けるべきである。
—
4. サプライチェーンとセキュリティ：ブロックスコープの誤解が招く脆弱性
シニアエンジニアやセキュリティ研究者として見逃せないのが、このスコープとクロージャのメカニズムを誤認したことに起因する、非同期処理における状態管理のバグ、およびそれに伴う脆弱性リスクだ。
近代的なNode.jsバックエンドやフロントエンドのビルドツールチェーンにおいて、非同期イベントループ（Event Loop）とクロージャの組み合わせは、非同期リクエストのコンテキスト汚染や、競合状態（Race Condition）を引き起こしやすい。
非同期ループとスコープ汚染の危険なパターン
以下のコードは、非同期処理（Promise / async-await）を含むループ内で `let` のスコープを過信、あるいは誤用した際に発生するアンチパターンである。
// 危険なパターン：非同期処理の順序とクロージャの捕捉
async function processItems(items) {
for (let i = 0; i < items.length; i++) {
// 非同期I/Oを伴う処理
await doSomethingAsync(items[i]);
// このクロージャは「各反復の let i」を正しくキャプチャしているが...
setImmediate(() => {
console.log(`Processed index: ${i}`);
});
}
}
一見、`let`のおかげで `i` は安全に保たれているように見える。しかし、もしこのループが「並行（Concurrent）」ではなく「直列（Sequential：`await` が各イテレーションをブロックする）」である場合、意図した並行処理になっておらず、I/Oのボトルネックを踏むことになる。
逆に、`await` を外して `Promise.all` と `let` を組み合わせる場合、ブロックスコープのクローンが正しく機能していなければ、各タスクが同じ変数を参照してデータ破壊（Data Corruption）を起こす。
// 正しく並行処理され、かつ各letが独立したスコープを持つケース
async function processConcurrently(items) {
const promises = items.map(async (item, i) => {
// 矢印関数の引数スコープとletの特性により、iは完全に隔離される
await doSomethingAsync(item);
return `Item ${i} done`;
});
return Promise.all(promises);
}
もしここで `let` ではなく `var` を使った古いコードベースをリファクタリングし忘れていた場合、非同期のマイクロタスクキュー（Microtask Queue）が消化される頃にはすべての `i` が最終値に書き換わっており、予期せぬデータ漏洩や、マルチテナント環境における別ユーザーのコンテキストへのデータ混入（クロスコンタミネーション）といった深刻なセキュリティインシデントに繋がりかねない。
—
5. チーフアーキテクトからの提言：ランタイムを支配せよ
JavaScriptは「おもちゃの言語」から、数百万行規模の大規模分散システム、SSRフロントエンド、そしてサーバーレス（FaaS）のエッジランタイムを支える屈強なインフラストラクチャへと進化を遂げた。
その心臓部であるV8エンジンは、私たちが書いたコードの1行1行を解釈し、隠しクラス（Hidden Classes / Maps）を構築し、インラインキャッシュ（Inline Caches）を効かせ、ヒープ上にレキシカル環境のクローンを緻密に配置している。
ループ内での `let` 宣言が単なるシンタックスシュガーではなく、「反復ごとの環境レコードの動的生成」という物理的なメモリ管理の差違を生んでいることを深く理解せよ。ランタイムの挙動を解剖し、CPUキャッシュとV8のGCアルゴリズムに愛されるコードを書くことこそが、真のプロフェッショナルエンジニアの姿である。