forループ内での `let` 宣言が生成する「ブロックスコープのクローン」とV8メモリ最適化の真実
JavaScriptの言語仕様（ECMAScript）が `var` の呪縛から解放され、`let` と `const` によるブロックスコープを獲得してから久しい。しかし、シニアエンジニアやランタイムの挙動にこだわるアーキテクトであっても、「`for` ループのヘッド部で宣言された `let` が、イテレーションごとにどのようにスコープを生成し、メモリ上に保持されているか」を正確に説明できる者は少ない。
世にある解説記事は「`var` は関数スコープだから巻き上げられてバグる、`let` はブロックごとに独立するから安全」という表層的な説明に終始している。だが、V8エンジンをはじめとするモダンJavaScriptエンジンの中身を覗けば、そこにはコンパイラ最適化、環境レコード（Environment Record）の動的生成、そしてガベージコレクション（GC）のライフサイクルを最適化するための極めて洗練された物理構造が存在する。
本稿では、`for (let i = 0; i < N; i++)` が内部で何を行っているのかをV8のランタイムレベルで解剖し、メモリ消費とパフォーマンスの真実を暴く。 ---
1. `var` の悪夢：クロージャと非同期処理の罠
まず、比較対象として `var` が抱えていた構造的欠陥をV8のメモリモデルの観点から復習しておこう。
// 【アンチパターン】varによるスコープ共有の弊害
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`var index: ${i}`);
}, 100 (i + 1));
}
// 出力結果: 3, 3, 3
このコードが `3, 3, 3` を出力することは有名だ。なぜこうなるのか？ V8の視点では、`var i` は関数スコープ（あるいはグローバルスコープ）に属するたった1つの変数スロットとしてアロケートされる。ループが高速に回り終えた時点で、メモリ上の変数 `i` の値は `3` に書き換わっている。
後から非同期で実行される `setTimeout` のコールバック関数群は、この単一の変数 `i` への参照（Lexical Environment）を共有しているため、実行時には既に最終値となった `3` を参照してしまうのだ。これを回避するために、かつて我々は即時関数（IIFE: Immediately Invoked Function Expression）を駆使してスコープを強制的に切り分けていた。
—
2. `let` が生成する「隠されたスコープのクローン」
では、`for` ループの初期化式で `let` を使った場合はどうなるのか。ECMAScript仕様（ES2015以降）およびV8の挙動は、開発者の直感をはるかに超えた洗練されたアロケーションを行う。
// 【モダンアプローチ】letによるイテレーションごとのスコープ独立
for (let i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`let index: ${i}`);
}, 100 (i + 1));
}
// 出力結果: 0, 1, 2
なぜ、こちらは正しく `0, 1, 2` が出力されるのか。「ループのブロックごとに新しい変数 `i` が作られている」というのが一般的な説明だが、V8の内部実装（Ignition / TurboFan）においては、もう少し動的かつ効率的なメカニズムが働いている。
イテレーションごとの「環境レコード（Environment Record）」の生成
V8は、`for` ループの本体（Body）が実行されるたびに、あるいはより正確には、ループの各イテレーション（反復）において、そのイテレーション専用の宣言的環境レコード（Declarative Environment Record）を新しくインスタンス化する。
1. ループ開始時（ヘッド部での宣言）:
ループの初期化で宣言された `let i` のための「Outer Environment」が作成される。
2. 各イテレーションの開始時:
V8は前回のイテレーションの変数の状態をキャプチャ（あるいはコピー）し、そのイテレーション固有の「Inner Environment」をヒープ上に構築する。
3. クロージャによるキャプチャ:
ループ内で定義されたアロー関数などのクロージャは、そのイテレーション専用に生成された環境レコード（の中にある変数 `i` のインスタンス）への参照を保持する。
結果として、メモリ上には `i = 0` を持つスコープ、`i = 1` を持つスコープ、`i = 2` を持つスコープという「3つの独立したインスタンス」が物理的に共存することになる。
—
3. V8の最適化とガベージコレクション（GC）の挙動
「それなら、ループを回すごとに新しいオブジェクトやスコープがヒープに生成され、GCの負荷（マイナーGC / Scavenge）が跳ね上がるのではないか？」という懸念を持つ読者は非常に鋭い。
ここでV8のJITコンパイラと最適化パイプラインの真骨頂が現れる。
1. エスケープ分析（Escape Analysis）によるスタック割当
TurboFan（V8の最適化コンパイラ）は、エスケープ分析を実施する。もしループ内で宣言された `let` 変数が、ループ外部やクロージャ（`setTimeout` など）に「エスケープ」しない場合、V8はその変数をヒープ上の独立した環境レコードとしてではなく、CPUレジスタや関数のスタックフレーム上に直接インライン展開する。これにより、メモリの動的アロケーションコストは完全にゼロになる。
2. クロージャが存在する場合のGCライフサイクル
一方で、先ほどの `setTimeout` の例のように、非同期コールバックが変数をキャプチャしてスコープを「エスケープ」させる場合、環境レコードはヒープ上に配置されざるを得ない。
ここで重要なのがガベージコレクションの挙動である。
- 従来の `var` では、関数スコープ全体が生き続ける限り、単一の変数スロットは解放されなかった。
- `let` のブロックスコープクローンでは、各イテレーションのスコープはそのイテレーションの処理が完了し、かつクロージャからの参照が失われた瞬間に、世代別GC（Scavenger）の回収対象となる。
つまり、メモリ消費の観点からも、`let` は「必要な期間だけスコープを生存させ、不要になったら即座にトポロジカルに切り離す」という、極めてモダンでクリーンなメモリ管理を実現しているのだ。
—
4. パフォーマンスとメモリフットプリントの実測的検証
百聞は一見に如かず。Node.js環境下で、`var` と `let` の大規模ループにおけるメモリ挙動とスコープ生成コストを検証するコードを提示する。
// memory-benchmark.js
// 実行コマンド: node –expose-gc memory-benchmark.js
function measureMemory(label, fn) {
if (global.gc) {
global.gc(); // 正確な測定のために強制GC実行
}
const initialMemory = process.memoryUsage().heapUsed;
const start = process.hrtime.bigint();
fn();
const end = process.hrtime.bigint();
const finalMemory = process.memoryUsage().heapUsed;
console.log(`[${label}] 実行時間: ${Number(end – start) / 1_000_000} ms`);
console.log(`[${label}] ヒープ増加量: ${(finalMemory – initialMemory) / 1024} KB\n`);
}
const ITERATIONS = 1_000_000;
// 1. var によるループ（クロージャキャプチャあり）
measureMemory(‘Var Loop with Closure’, () => {
const callbacks = [];
for (var i = 0; i < ITERATIONS; i++) {
// 意図的にクロージャを作成してスコープをエスケープさせる
callbacks.push(() => i);
}
// すべてのクロージャが同一のグローバル/関数スコープの ‘i’ (最終値 1,000,000) を参照する
});
// 2. let によるループ（クロージャキャプチャあり）
measureMemory(‘Let Loop with Closure’, () => {
const callbacks = [];
for (let i = 0; i < ITERATIONS; i++) {
// イテレーションごとの環境レコードが生成され、それぞれ異なる 'i' をキャプチャする
callbacks.push(() => i);
}
});
実行結果から読み解くランタイムの現実
このコードを実行すると、`let` を使用したケースの方が、ヒープメモリの消費量がわずかに増加することが確認できる。これは、100万個の独立した環境レコード（Lexical Environmentオブジェクト）がヒープ上にインスタンス化され、各クロージャから参照されるためである。
しかし、これは「バグを防ぎ、期待された正しい挙動（各イテレーションの値を保持すること）を得るため」の必要最低限のコストである。もし `var` でこれを正しく行おうとすれば、開発者が手動で IIFE を書いて同等のオブジェクト（クロージャ用スコープ）を強制生成しなければならず、コードの可読性を損なうだけでなく、V8の最適化エンジンにとっても解析しにくい複雑なAST（抽象構文木）を生み出すことになる。
—
5. シニアエンジニアが押さえるべきセキュリティ・アーキテクチャ上の知見
変数のスコープとメモリ管理のメカニズムを深く理解することは、単なるパフォーマンスチューニングに留まらない。サプライチェーン攻撃の温床となるプロトタイプ汚染（Prototype Pollution）や、クロージャを悪用したメモリリークの検知においても、この知識が強力な武器となる。
スコープ汚染とクロージャの安全な隔離
巨大なモノリシックなフロントエンドアプリケーションや、マルチテナントなNode.jsマイクロサービスにおいて、不適切な変数共有（特に `var` や意図しないグローバル汚染）は、異なるリクエスト間で機密データがリークする脆弱性（CWE-Rosetta的なコンテキスト混入）を誘発する。
`let` と `const` がもたらす「ブロック単位の厳格な環境レコードの分離」は、変数の生存期間（Lifetime）を最小限に絞り込み、プリンシプル・オブ・レースト・プリビレッジ（最小権限の原則）をメモリ空間レベルで強制するものに他ならない。
// 安全なイテレーション処理のアーキテクチャ例
function processTenantData(tenants) {
// 各テナントの処理コンテキストを完全に隔離
for (let i = 0; i < tenants.length; i++) {
const tenant = tenants[i];
// 非同期パイプライン処理
setTimeout(async () => {
// このクロージャからアクセスできる tenant および i は、
// 他のイテレーションと物理的に完全に隔離された環境レコード内にある
await secureExecute(tenant);
}, 0);
}
}
このように、V8の内部構造やスコープのクローンメカニズムを解剖視点を持って理解していれば、「なぜこの書き方が安全であり、なぜランタイムがこれを高速に処理できるのか」を確信を持って設計に組み込むことができる。
JavaScriptはもはや「おもちゃのスクリプト言語」ではない。V8という世界最高峰の仮想マシン上で動作する、厳格なメモリ管理とJIT最適化が施されたコンパイル言語としての側面を持つ。そのランタイムの鼓動を常に意識し、コードの一行一行がV8のヒープとスタックにどう作用するのかをイメージしながら、最高峰のアーキテクチャを構築し続けてほしい。