V8の深淵：forループにおける `let` のメモリ幾何学とブロックスコープ・クローンの実相
JavaScriptのランタイム、特にGoogle V8エンジンにおいて、言語仕様の進化は単なる「糖衣構文（シンタックスシュガー）」の追加ではない。それはV8のヒープ（Heap）構造の再定義であり、JIT（Just-In-Time）コンパイラが生成する機械語の最適化パスを根底から書き換える営みだ。
今回は、ES6で導入された `let` が、特に `for` ループのイテレーション内においてどのようにV8のメモリ空間を物理的に支配し、なぜ古の `var` がガベージコレクション（GC）やメモリ消費の観点で「悪手」となり得るのかを、V8の内部実装レベルから徹底的に解剖する。
—
1. 伝統的悪夢：`var` が関数スコープを汚染し続けるメカニズム
まずは、多くのJavaScript開発者が無意識に通り過ぎてきた、しかしランタイムにとっては残酷な現実から始めよう。
// 【アンチパターン】varによるループカウンタとクロージャの生成
function createDangerousCallbacks() {
var callbacks = [];
for (var i = 0; i < 3; i++) {
callbacks.push(function() {
return i;
});
}
return callbacks;
}
const cbs = createDangerousCallbacks();
console.log(cbs[0]()); // 3
console.log(cbs[1]()); // 3
console.log(cbs[2]()); // 3
このコードが `3, 3, 3` を出力することは誰もが知っている。だが、V8のヒープメモリ上で何が起きているかを正確に把握している者は少ない。
`var i` は関数スコープ（またはグローバルスコープ）を持つ。つまり、V8はこのループのために新しいメモリ空間を毎イテレーションで確保するのではなく、関数コンテキスト（Context）内にたった1つの変数 `i` のスロットを割り当てる。ループが回るたびにその値が `0` から `1`、`2`、そして終端条件の `3` へと上書きされていく。
生成された3つの無名関数（クロージャ）は、すべて同一の変数 `i` への参照（Context Slot Reference）を保持してヒープ上に生き続ける。結果として、ループが終了した時点で `i` の値は `3` で固定され、すべてのクロージャがその残骸を参照し続けることになる。
ここでのメモリの非効率性は、単なる「値の上書き」にとどまらない。V8は、クロージャが外部変数を参照していると検知した瞬間、その変数をレジスタ上ではなくヒープ上に割り当てられたContextオブジェクト（コンテキストオブジェクト）へ強制的にエスケープ（Escape Analysisの失敗）させる。これにより、本来であればインライン展開やレジスタ最適化の恩恵を受けられたはずの変数が、無駄なヒープ割り当ての対象となり、後の世代別GC（Generational GC）に不要なプレッシャーを与える原因となるのだ。
—
2. `let` の福音：forループにおける「暗黙のレキシカル環境クローン」
では、`let` を用いた現代的なループを見てみよう。仕様書（ECMAScript Specification）の `ForStatement` および `ForIn/OfStatement` の評価アルゴリズムにおいて、`let` 宣言を持つループヘッダーは、各イテレーションごとに新しいLexical Environment（レキシカル環境）のインスタンスを作成することが義務付けられている。
// 【モダンアプローチ】letによるブロックスコープの独立
function createSafeCallbacks() {
const callbacks = [];
for (let i = 0; i < 3; i++) {
// 各ループのイテレーションごとに、iの「新しいインスタンス」が生成される
callbacks.push(function() {
return i;
});
}
return callbacks;
}
const safeCbs = createSafeCallbacks();
console.log(safeCbs[0]()); // 0
console.log(safeCbs[1]()); // 1
console.log(safeCbs[2]()); // 2
V8（IgnitionインタプリタおよびTurboFanコンパイラ）は、この仕様を次のように物理実装している。
1. 初期化フェーズ: ループ外（またはループのブロック外）に、ループ用の初期レキシカル環境が構築される。
2. イテレーション毎のクローン生成: ループの各反復（Iteration）の開始時、V8のランタイムは前回のループの変数値と独立した、新しい環境レコード（Environment Record）をヒープ上に動的に生成（クローン）する。
3. 副作用の遮断: ループ内で定義された関数（クロージャ）は、そのイテレーション固有の環境レコードへのポインタを保持する。したがって、次のループで `i` がインクリメントされても、前のイテレーションの環境レコード内の `i` は不変のまま保持される。
V8ヒープメモリ空間の変遷
これをV8のヒープ構造の視点から視覚化すると、以下のようになる。
[Function Context]
│
└── (Loop Block Environment – Iteration 0) ──> [ variable: i = 0 ] <── (Closure 0 points here)
│
└── (Loop Block Environment - Iteration 1) ──> [ variable: i = 1 ] <── (Closure 1 points here)
│
└── (Loop Block Environment - Iteration 2) ──> [ variable: i = 2 ] <── (Closure 2 points here)
「ループごとにオブジェクト（環境レコード）を生成するなら、`var` よりもメモリ消費が増加するのではないか？」という鋭い疑問を持つシニアエンジニアもいるだろう。理論的にはその通りだ。各イテレーションでメモリ割り当てが発生するため、単純なアロケーションコストは微増する。
しかし、「意図しないメモリリークの防止」と「JITコンパイラの最適化パスの精度向上」という圧倒的なメリットが、この微小なアロケーションコストを完全に凌駕する。 `var` のように共有された可変状態（Shared Mutable State）が存在しないため、TurboFanは変数が不変（Immutable）であるとみなして、よりアグレッシブな定数畳み込み（Constant Folding）や型推論を適用できるのだ。
—
3. ベンチマークとJIT・GCの挙動解析
この挙動が実際のランタイムに与える影響を、Node.js環境下を想定したコードで検証する。
const { performance } = require(‘perf_hooks’);
function benchmarkVar() {
const start = performance.now();
let total = 0;
for (var i = 0; i < 1_000_000; i++) {
let val = i;
total += val;
}
return performance.now() - start;
}
function benchmarkLet() {
const start = performance.now();
let total = 0;
for (let i = 0; i < 1_000_000; i++) {
let val = i;
total += val;
}
return performance.now() - start;
}
// ウォームアップ（V8のJIT/Crankshaft/TurboFanを最適化状態に持ち上げる）
for (let i = 0; i < 10; i++) {
benchmarkVar();
benchmarkLet();
}
console.log(`Var benchmark: ${benchmarkVar().toFixed(4)} ms`);
console.log(`Let benchmark: ${benchmarkLet().toFixed(4)} ms`);
実行結果の考察
最新のV8エンジン（Node.js v18+ / v20+以降）において、単純なプリミティブ値のループカウンタであれば、`var` と `let` の実行速度にほとんど差は見られない。なぜなら、TurboFanコンパイラは、ループ内でクロージャが生成されず、変数がスコープ外にエスケープしない（Escape Analysisの結果、ヒープに置く必要がないと判明した）場合、`let` のイテレーションごとの環境クローンを最適化によって完全に「消し去る（Scalar Replacement of Aggregates）」からだ。
つまり、V8は賢い。クロージャによってキャプチャされない限り、`let` のブロックスコープはスタック上のただのレジスタ操作へと昇華される。しかし、クロージャが絡んだ瞬間、V8は安全性を最優先し、ヒープ上に真のブロックスコープ・クローンを生成する。この「必要に応じた遅延アロケーション」こそが、V8の真骨頂である。
—
4. セキュリティ・サプライチェーンの文脈：ブロックスコープの欠如が招く脆弱性
ここで視点を変え、セキュリティとサプライチェーン攻撃の文脈に踏み込もう。
悪名高い「プロトタイプ汚染（Prototype Pollution）」や、非同期処理におけるスコープ汚染の多くは、変数のスコープ管理の甘さ、すなわち `var` の濫用やグローバル汚染に起因する。特に、非同期タスク（Promiseやマクロタスクキュー）が絡むループ内処理で `var` を使用した場合、意図せぬ変数の共有がセキュリティ上の致命傷になることがある。
以下の非同期処理を含むループを見てほしい。
// 【脆弱なコード】varのスコープ共有による非同期処理の競合（Race Condition）
function processUserRequests(userIds) {
for (var i = 0; i < userIds.length; i++) {
setTimeout(async function() {
// varのため、すべての非同期コールバックが「最後のiの値」を参照する
// もしくは、ループが瞬時に完了するため予期せぬインデックスにアクセスする
await fetchUserData(userIds[i]);
}, 100 i);
}
}
このコードにおいて、`i` は関数スコープであるため、非同期の `setTimeout` が発火する頃には、同期的な `for` ループはすでに完走し、`i` は配列の最大値に達している。結果として、意図したユーザーデータではなく、範囲外や最後のユーザーデータに対する不正なリクエストが連続して発生し、認可バイパスやロジックの破綻（RCEの前段階となる状態異常）を誘発する温床となる。
防壁としての `let` とイミュータビリティ
`let` を用いることで、各非同期タスクは固有のレキシカル環境への参照を確実に保持し、スコープの密閉性が保たれる。
// 【堅牢なコード】letによるスコープの完全なカプセル化
function processUserRequestsSecure(userIds) {
for (let i = 0; i < userIds.length; i++) {
setTimeout(async function() {
// 各イテレーションのiがクロージャによって安全に保たれる
await fetchUserData(userIds[i]);
}, 100 i);
}
}
近年のNode.js環境を狙ったサプライチェーン攻撃（悪意あるnpmパッケージの混入など）では、グローバルオブジェクトやビルトインのプロトタイプを書き換えるだけでなく、非同期コンテキストやクロージャの隙を突き、非同期処理の競合を利用してモジュールの内部状態をハッキングする手口が存在する。V8のランタイムレベルでスコープが厳密にクローンされ、他から干渉不能な空間として隔離されていることは、アプリケーションレベルのセキュリティにおける最後の砦なのだ。
---
5. チーフアーキテクトからの提言：モダンJSのメモリ幾何学を制する
JavaScriptは、もはや「ブラウザでおもちゃを動かすための簡易言語」ではない。V8という世界最高峰の仮想マシン上で動作する、極めて高度なメモリ管理システムを持つランタイムだ。
1. `var` は過去の遺物として完全に排除せよ: 可変スコープの漏洩とメモリ効率の悪化を招くだけであり、現代の開発において使う理由は1ミリも存在しない。
2. `let` と `const` による「意図の明文化」: 変数を宣言する際は、まず `const` でイミュータブルに保ち、再代入が不可避なカウンター等でのみ `let` を使用する。これにより、V8のJITコンパイラに対して「この値は変化する/しない」という強力なヒントを与え、最適化の恩恵を最大化できる。
3. クロージャとスコープクローンのコストを意識せよ: ループ内での関数生成（クロージャ）は、V8ヒープ上での環境レコードのクローン生成を伴う。パフォーマンスクリティカルなホットパス（Hot Path）では、不要な関数生成を避け、構造化されたデータフローを設計すること。
言語仕様の裏側にあるV8の挙動、ヒープの物理的変化、そしてランタイムの防壁の仕組みを完全に掌握した者だけが、真にスケーラブルで堅牢なシステムを構築できる。コードの1行がV8のエンジン内部でどう解釈されるか——その想像力を絶やさないことだ。