フロントエンドのコードレビューを行っていると、未だに「`var`の代わりに何となく`let`を使っている」エンジニアのなんと多いことか。非同期処理やイベントリスナーが絡むループ処理において、`let`が内部でどのようにスコープを生成し、V8エンジンのメモリ空間でどう振る舞うかを理解していないがために、プロダクション環境で致命的なバグを生む現場を数多く目にしてきた。
今回は、ループ内における`let`宣言が真価を発揮するメカニズム、すなわち「各反復ごとのブロックスコープのクローン」と、それに伴うクロージャ・スコープチェーンの生成タイミングについて、V8のランタイム挙動の深部まで踏み込んで解剖する。
—
1. なぜ「`var`」ではループの非同期処理で破綻するのか？
まず、敵を知るためにレガシーな`var`の挙動を振り返ろう。以下のコードを見てほしい。
// 【アンチパターン】varを用いた非同期ループ
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`[var] 経過時間インデックス: ${i}`);
}, 100 (i + 1));
}
このコードを実行すると、コンソールには何と出力されるだろうか？ 期待値としては `0`, `1`, `2` だろう。しかし、実際の出力は以下のようになる。
[var] 経過時間インデックス: 3
[var] 経過時間インデックス: 3
[var] 経過時間インデックス: 3
V8エンジン内部で何が起きていたのか？
`var`には関数スコープ（またはグローバルスコープ）しか存在しない。そのため、ループ変数 `i` はループの外側（この場合はグローバル、または囲む関数スコープ）にただ1つの変数として確保される。
1. ループが高速に回し切られ、`i` の値は `3` に到達する。
2. `setTimeout` のコールバック関数が非同期タスクキューから実行されるタイミングでは、すでに `i` の値は `3` に固定されている。
3. すべてのクロージャが、同じ単一のメモリ領域を参照しているため、同じ値がキャプチャされてしまう。
これを回避するために、かつては即時実行関数（IIFE）を使って新しいスコープを強制的に作っていた。しかし、モダンなJavaScriptにおいて、そんなハックはもはや技術的負債でしかない。
—
2. `let`がもたらす「ブロックスコープのクローン」の正体
ES2015で導入された`let`は、この問題を言語仕様レベルで解決した。しかし、単に「スコープが狭くなった」という表層的な理解では不十分だ。
ECMAScript仕様（TC39）およびV8の実装において、`for (let i = 0; i < 3; i++)` のヘッダー部で宣言された `let` 変数は、ループの各反復（Iteration）ごとに、裏側で全く新しい独立した変数として再束縛（Re-binding）される。
// 【モダンなアプローチ】letを用いたループ
for (let i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`[let] 経過時間インデックス: ${i}`);
}, 100 (i + 1));
}
出力結果:
[let] 経過時間インデックス: 0
[let] 経過時間インデックス: 1
[let] 経過時間インデックス: 2
メモリ空間とクロージャの生成タイミング
V8エンジンの視点から、このループの内部で何が起きているかを紐解こう。
1. 反復0回目: エンジンはブロックスコープ環境を生成し、変数 `i`（値: `0`）のメモリ領域を確保する。ループ本体内のクロージャはこの環境（Lexical Environment）への参照を保持する。
2. 反復1回目: 前回の `i` とは全く別の、新しいメモリ上の変数 `i`（値: `1`）が新たにクローン（生成）される。ループ本体内のクロージャは、この「新しく生まれた環境」を新しくキャプチャする。
3. 反復2回目: 同様に、新しい変数 `i`（値: `2`）の環境が生成される。
つまり、各反復で生成される無名関数（クロージャ）は、それぞれ異なる世代のスコープ環境（Lexical Environment）をスコープチェーン経由で指し示している。これが、ループ内`let`が「各反復ごとに新しい変数を生成する」と言われる所以である。
—
3. 実務の現場で直面する「罠」とパフォーマンスの勘所
テクニカルリードとしてコードレビューを行う際、この仕様にまつわる「よくある誤解とアンチパターン」にしばしば遭遇する。
罠1: ループ「外」で定義されたletの誤認
以下のコードを見てほしい。
// 【危険な実装】letをループの外で宣言しているケース
let i;
for (i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`[External let] ${i}`);
}, 100);
}
// 出力結果: 3, 3, 3
`let`を`for`の初期化文ではなく、外側で宣言してしまった場合、スコープはループ全体で共有される単一の変数に戻ってしまう。`let`の効果を発揮させるためには、必ず`for`文の構文内（ヘッダー部）で宣言しなければならない。
パフォーマンスに関するV8の最適化
「各反復ごとに変数が生成されるなら、メモリやCPUの負荷が高いのではないか？」という疑問を持つ鋭いエンジニアもいるだろう。
安心してほしい。現代のV8エンジン（および他のモダンJSエンジン）は、逃げ解析（Escape Analysis）を行っている。クロージャから参照されなかったり、メモリの生存期間が限定されているスコープ変数については、ガベージコレクションの負荷を最小限に抑えるため、スタック領域への最適化やインライン展開が行われる。
ただし、巨大なオブジェクトやDOM要素をループ内のスコープで無駄に大量キャプチャし続ける設計は、V8のヒープメモリを圧迫し、マイナーGC（Scavenge GC）の頻度を高めてフレームドロップ（カクつき）の原因になる。不要になった参照は速やかに手放す、あるいはループのスコープを適切に分割する意識が不可欠だ。
—
4. プロダクションコードで即座に使える堅牢な設計パターン
ここでは、実際のフロントエンド開発（非同期APIのバッチ処理、動的なDOMイベントアタッチメント）を想定した、保守性の高いプロダクションコードを示す。
/
- @typedef {Object} TaskItem
- @property {string} id
- @property {string} label
/
/
- 複数要素に対して安全に非同期イベントリスナーをバインドし、
- 各要素固有のスコープを完全に担保するユーティリティクラス
/
class InteractiveListController {
/
- @param {string} containerSelector
- @param {TaskItem[]} items
/
constructor(containerSelector, items) {
this.container = document.querySelector(containerSelector);
this.items = items;
this.abortController = new AbortController();
}
/
- DOMを構築し、各要素に独立したスコープを持つイベントハンドラを登録する
/
mount() {
if (!this.container) {
throw new Error(`Container element not found: ${containerSelector}`);
}
const fragment = document.createDocumentFragment();
// 【ベストプラクティス】
// for…of文におけるletも、各反復ごとに新しい変数の束縛を生成する。
// 配列の要素やインデックスは各クロージャに安全にカプセル化される。
for (const [index, item] of this.items.entries()) {
const button = document.createElement(‘button’);
button.textContent = `${index + 1}: ${item.label}`;
button.className = ‘task-action-btn’;
// クロージャが各反復の `item` と `index` を安全に保持する
button.addEventListener(‘click’, async (event) => {
await this.handleItemClick(item, index, event);
}, { signal: this.abortController.signal });
fragment.appendChild(button);
}
this.container.appendChild(fragment);
}
/
- 独立したスコープ変数を受け取る非同期ハンドラ
- @private
/
async handleItemClick(item, index, event) {
try {
console.log(`タスク開始: ID = ${item.id}, Index = ${index}`);
// 非同期APIコールのシミュレーション
const response = await fetch(`/api/tasks/${item.id}`, {
method: ‘POST’
});
if (!response.ok) throw new Error(‘APIリクエストに失敗しました’);
const data = await response.json();
console.log(‘APIレスポンス成功:’, data);
} catch (error) {
console.error(`[Error] タスク処理失敗 (Index: ${index}, ID: ${item.id}):`, error);
}
}
/
- メモリリークを防ぐためのクリーンアップ
/
destroy() {
// AbortControllerにより、登録したすべてのイベントリスナーを一度に破棄
this.abortController.abort();
if (this.container) {
this.container.innerHTML = ”;
}
}
}
// — 使用例 —
/
const tasks = [
{ id: ‘t-001’, label: ‘ユーザーデータの同期’ },
{ id: ‘t-002’, label: ‘キャッシュのクリア’ },
{ id: ‘t-003’, label: ‘アナリティクス送信’ }
];
const controller = new InteractiveListController(‘#app-container’, tasks);
controller.mount();
// ライフサイクル終了時（例: SPAのページ遷移時）
// controller.destroy();
/
このコードの優れた設計ポイント
1. `for…of` と `entries()` における `let` の活用: ループ変数として宣言された `item` と `index` は、反復ごとに完全に独立したメモリ空間（ブロックスコープのクローン）を持つ。そのため、非同期の `click` イベントが後から発火しても、クリックされた瞬間に正しい `item.id` が保証される。
2. メモリリークの根絶 (`AbortController` の採用): 動的に生成された数多くのDOM要素にイベントリスナーを付与した場合、適切なクリーンアップを行わないとDOMノードがガベージコレクションされずメモリリークの原因になる。`AbortController` を用いることで、スコープをまたいだリスナーの破棄を確実に行えるようにしている。
3. 副作用の局所化: 非同期処理（`fetch`）のパラメータとして、クロージャがキャプチャした不変のローカル変数（`item`, `index`）を直接渡しているため、予期せぬ外部変数の書き換え（シャドーイングやグローバル汚染）を防いでいる。
—
5. チーフアーキテクトからの提言
JavaScriptの言語仕様は日進月歩で進化しているが、その根底にある「変数のスコープ」と「メモリのライフサイクル」の本質を理解しているか否かで、書くコードの堅牢性は天と地ほどの差を生む。
「なぜ動くのか」を説明できないコードは、いずれプロダクション環境の負荷や非同期処理の競合によって崩壊する。`let` がループ内で生み出すブロックスコープのクローンという挙動は、単なるシンタックスシュガーではなく、非同期プログラミングを安全に行うためのV8からの強力なプレゼントだ。このメカニズムをコードの隅々にまで浸透させ、美しく堅牢なフロントエンドアーキテクチャを構築してほしい。