ループと非同期処理のランタイム解剖学：`var`が引き起こす破滅と、`let`がV8ヒープに刻む不可視の防壁
JavaScriptエンジニアであれば、一度は踏み抜いたことがある罠がある。
非同期処理を伴う`for`ループの中で`var`を使い、意図せずすべてのコールバックが最終的なインデックス値まりを指してしまうというバグだ。
// すべての非同期処理が「3」を出力する、歴史的かつ陳腐なバグ
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(i); // 0, 1, 2ではなく、3, 3, 3 が出力される
}, 100);
}
「`let`を使えばブロックレベルスコープになるから解決する」。チュートリアルにはそう書いてある。だが、シニアエンジニアやランタイムの挙動に命をかけるアーキテクトであれば、こう問い直さなければならない。
「V8エンジンの内部で、一体何が生成され、スコープチェーンはどう書き換わり、イベントループのキューとどう絡み合ってその挙動の差異が生まれているのか？」
本稿では、`var`と`let`の非同期ループにおける挙動の激変を、V8エンジンのメモリ空間、実行コンテキスト（Execution Context）、そしてLexical Environmentの物理的生成タイミングの観点から極限まで深掘りする。表面的な挙動の暗記ではなく、ランタイムの底層で起きている物理現象を完全に掌握しよう。
—
1. 実行コンテキストとLexical Environmentの二大モデル
JavaScriptがコードを評価・実行する際、V8エンジンは「実行コンテキスト（Execution Context）」を生成し、コールスタックに積んでいく。この中身は、ECMAScript仕様のバージョンによって劇的に進化してきた。
`var`の正体：関数スコープとVariable Environment
`var`で宣言された変数は、関数スコープ（またはグローバルスコープ）に属する。
V8の内部表現において、`var`変数は実行コンテキスト内の Variable Environment（変数環境） にバインドされる。重要なのは、`var`は「巻き上げ（Hoisting）」が発生した際、スコープの先頭で`undefined`で初期化される点だ。
先の`for`ループで`var i = 0`と書いた場合、変数`i`はループのブロック外（関数またはグローバルスコープ）にたった1つだけ存在する。
[ グローバル / 関数スコープ ]
└─ Variable Environment: { i: 3 } <-- ループ終了時には「3」に書き換わっている
ループが高速に回し切られ、`i`が`3`になった瞬間、ヒープ（またはスタックフレーム）上に存在する唯一の変数`i`の値はすでに`3`である。100ミリ秒後に`setTimeout`のコールバックが実行され、クロージャ経由で参照される`i`は、その時点の「グローバルな`i`」を指し示す。そのため、すべてが`3`を出力する。
`let`の正体：ブロックスコープとLexical Environment
一方、`let`や`const`は、ECMAScript 2015（ES6）で導入された Lexical Environment（字句環境） によって管理される。Lexical Environmentは、識別子と値のバインドを保持するだけでなく、コードブロック（`{}`）単位で独立したスコープ空間を形成する能力を持つ。
さらに重要なのは、`for (let i = 0; i < 3; i++)` という構文における仕様上の特例だ。 ES6仕様では、`for`ループのヘッド（条件部）で宣言された`let`変数は、ループの反復（iteration）ごとに、まったく別個の新しいLexical Environmentが暗黙的に生成されると定義されている。
反復 0 の Lexical Environment: { i: 0 }
反復 1 の Lexical Environment: { i: 1 }
反復 2 の Lexical Environment: { i: 2 }
V8は、それぞれの反復で生成された非同期コールバック（クロージャ）に対し、その反復時点専用のLexical Environmentへの参照（Outer Lexical Environment Reference）をキャプチャさせる。これが、`let`を使うことで意図した値（0, 1, 2）が保持される根本的な理由である。
—
2. V8エンジン内部におけるメモリレイアウトと最適化
では、このLexical Environmentの生成は、V8のヒープメモリ空間やJITコンパイル（TurboFan）においてどのようなコストと構造変化をもたらすのだろうか？
隠しクラス（Hidden Classes / Maps）とインラインキャッシュ
V8は動的言語であるJavaScriptを静的言語並みに高速化するため、オブジェクトのプロパティアクセスに「隠しクラス（Map）」を割り当てる。しかし、スコープ内のローカル変数やクロージャによってキャプチャされた変数は、通常のオブジェクトプロパティとは異なり、コンテキスト（Context）と呼ばれる内部データ構造の固定スロットに格納される。
`var`の場合、コンテキスト内のスロットは1つであり、V8のオプティマイザ（TurboFan）はこれをレジスタやスタック上のローカル変数として簡単に最適化（Scalar Replacement）できる。
しかし、`let`による反復ごとのスコープ生成は、一見すると「毎回オブジェクトやコンテキストをヒープ上にアロケーションしているため、GC（ガベージコレクション）の負荷が高いのではないか？」という懸念を生む。
実際、古いバージョンのV8では、ループごとのスコープ生成がマイナーGC（Scavenge）のトリガーとなるパフォーマンスボトルネックになることがあった。しかし、近年のV8（IgnitionインタプリタおよびTurboFanコンパイラ）は非常に高度なエスケープ解析（Escape Analysis）を行っている。
もし非同期処理（`setTimeout`など）がループ内でキャプチャされず、同期的にスコープが消滅することが分かっている場合、V8はヒープへのアロケーションを完全に回避し、単なるレジスタ上のインデックス操作へとインライン展開する。
逆に、今回のように`setTimeout`によって変数がスコープ外へ「エスケープ」する場合のみ、V8はヒープ上にコンテキストオブジェクトを実体化（Materialize）させ、クロージャから参照できるように保持する。
—
3. イベントループとマクロタスク・マイクロタスクの厳密な相互作用
ループ内で非同期処理を扱う際、もう一つの主役である「イベントループ」のキューイングメカニズムを無視することはできない。
for (let i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`Timeout: ${i}`);
}, 0);
Promise.resolve().then(() => {
console.log(`Promise: ${i}`);
});
}
console.log(‘Loop End’);
上記のコードを実行した際の出力順序を正確に脳内トレースできるだろうか？
V8ランタイムおよびHTML5仕様に準拠したイベントループの挙動は以下の通りである。
1. 同期コードの実行：
- `i = 0`の反復：`setTimeout`（マクロタスク）がタイマーキューへ登録。`Promise.resolve().then()`（マイクロタスク）がマイクロタスクキューへ登録。
- `i = 1`の反復：同様にマクロタスクとマイクロタスクがそれぞれのキューへ。
- `i = 2`の反復：同様にキューへ。
- `’Loop End’`が同期出力される。
2. コールスタックが空になった瞬間、イベントループはマイクロタスクキューを優先して完全に空にする（Drain the microtask queue）。
- ここで、各反復のLexical Environmentからキャプチャされた`i`の値（0, 1, 2）が使われ、`Promise: 0`、`Promise: 1`、`Promise: 2`が連続して出力される。
3. マイクロタスクが空になると、イベントループはレンダリングフェーズ（ブラウザ環境の場合）を経由し、マクロタスクキュー（`setTimeout`）の処理に移る。
- `Timeout: 0`、`Timeout: 1`、`Timeout: 2`が出力される。
もしここで`let`ではなく`var`を使っていたらどうなるか。
マイクロタスクであれマクロタスクであれ、コールバックが実行される時点ですでに変数`i`は`3`に書き換わっているため、すべての出力が`3`になるという悲劇が起きる。
—
4. セキュリティ・サプライチェーンの文脈：プロトタイプ汚染とスコープの罠
シニアアーキテクトとして、言語仕様の挙動をただ理解しているだけでは不十分だ。この「変数スコープとクロージャの生成タイミング」に関する脆弱性は、現代のNode.jsエコシステムにおけるサプライチェーン攻撃、特にプロトタイプ汚染（Prototype Pollution）や非同期処理を悪用したセキュリティインシデントと密接に結びついている。
以下の脆弱なコードを見てほしい。大規模なOSSライブラリのオブジェクトマージ関数やクエリパーサでよく見られるアンチパターンだ。
// 危険な再帰的オブジェクトマージ（プロトタイプ汚染脆弱性を持つ例）
function unsafeMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
unsafeMerge(target[key], source[key]);
} else {
// ユーザー入力が検証なしにプロパティとして代入される
target[key] = source[key];
}
}
return {};
}
// 攻撃者が外部入力（JSON等）を通じて以下を送り込むとする：
// JSON.parse(‘{“__proto__”: {“polluted”: “RCE_PAYLOAD”}}’)
このループ内で`let`ではなく誤ったスコープ管理や非同期処理のハンドリングが行われていたり、あるいはオブジェクトのプロトタイプチェーンを汚染された状態で非同期のタスクキューに処理を委譲した場合、ランタイム全体が汚染される。
サプライチェーンを突くRCE（リモートコード実行）への布石
攻撃者はプロトタイプ汚染によって`Object.prototype`にカスタムプロトタイプや悪意あるセッターを仕込む。その後、アプリケーションが非同期処理やテンプレートエンジン（例: Pug, Handlebarsなど）、あるいは内部のダイナミックコード評価（`eval`や`vm`モジュール）を実行した際、汚染されたプロパティが予期せぬスコープ解決を通じて参照される。
特に、非同期ループ内で動的に生成される設定オブジェクトやルーティングハンドラーが、意図せず汚染されたプロトタイププロパティを継承してしまった場合、以下のような深刻な問題が発生する。
1. コンテキストの乗算汚染：
非同期処理のキューイング（`setTimeout`や`Promise`）の過程で、V8がヒープ上にコンテキストオブジェクトを実体化する際、プロトタイプチェーンが汚染されていると、スコープ内のプロトコル解決やプロパティルックアップがハイジャックされる。
2. ガベージコレクション回避の悪用：
攻撃者が意図的にクロージャに長寿命のオブジェクトをキャプチャさせ続けることで、メモリリークを引き起こしつつ、汚染されたプロトタイプを持つオブジェクトをV8のヒープ空間に常駐させ、後続のセキュリティ・サンドボックス（Node.jsの`vm`モジュールなど）の脱獄（Sandbox Escape）の足がかりとする。
防衛策として、私たちは常に以下を徹底しなければならない。
- ループ内での非同期処理には必ず`let`（または`const`）を使用し、Lexical Environmentの分離を保証する。
- 外部入力を処理する際は、`Object.create(null)`を用いたプロトタイプを持たないオブジェクト（Dictionary）を使用する。
- Node.jsの起動時に `–frozen-intrinsics` や `–disallow-code-generation-from-strings` などのV8セキュリティフラグを活用し、ランタイム自体の防壁を高める。
—
結び：コードの挙動をランタイムの物理法則として捉えよ
私たちが書くたった行のJavaScriptコード、`var`から`let`への書き換えは、単なる「バグ修正の呪文」ではない。それは、V8エンジンのメモリレイアウトを変え、Lexical Environmentという名の物理的防壁を構築し、イベントループの非同期キューイングにおけるデータの整合性を担保する、極めて厳密なエンジニアリング行為なのだ。
言語の仕様書を読むこと。そして、その仕様がランタイムの底層でどう実装されているかを脳内で完全にシミュレーションすること。それこそが、真に信頼性の高い、安全でモダンなWebアプリケーションを構築するための唯一の道である。