コードレビューの現場から：`var`の亡霊と`let`がV8エンジン内で起こす静かな革命
フロントエンドのコードレビューを行っていると、未だに「なぜここで`var`を使っているのか」「なぜ即時関数（IIFE）でスコープを切り分けているのか」と首をかしげたくなるコードに出くわすことがある。
「ループカウンターにはとりあえず`let`」――これは現代のJavaScript開発において常識となった。しかし、「なぜ`for (let i = 0; i < 3; i++)`の`let`が、非同期処理やクロージャにおいて`var`のような致命的なバグを防ぎ、かつV8エンジンのメモリ管理にどう影響しているのか」を、ランタイムの挙動レベルで正確に説明できるエンジニアはどれほどいるだろうか。
今回は、JavaScriptのコアメカニズムである「ブロックスコープのクローン」と「ガベージコレクション（GC）」の不可分な関係性にメスを入れ、実務で絶対に外せない堅牢な設計パターンをロジカルに解説する。
—
1. 脳内トレースの罠：なぜ`for (let i = …)`は各イテレーションで生き残るのか
まずは、以下の非同期処理を含むループを見てほしい。シニアエンジニアとしての直感を働かせて、このコードが何を出力するか即答してほしい。
// 非同期処理を伴う典型的なループアンチパターン（または検証用コード）
function executeLegacyLoop() {
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`[var] 経過時間ごとのiの値: ${i}`);
}, 100 (i + 1));
}
}
function executeModernLoop() {
for (let i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`[let] 経過時間ごとのiの値: ${i}`);
}, 100 (i + 1));
}
}
`var`で宣言された`i`は関数スコープ（またはグローバルスコープ）に属する。そのため、コールスタックが空になり、100ms後に`setTimeout`のコールバックが実行される頃には、ループはすでに完了し、変数`i`の値は`3`に到達している。出力結果はすべて`3`だ。
一方、`let`を使用した場合、出力は期待通り`0, 1, 2`となる。
なぜこうなるのか？ 「`let`はブロックスコープだから」という教科書通りの説明では、テクニカルリードとしては不十分だ。V8エンジンの内部挙動ベースで正確にこう言い換えなければならない。
> 「`for (let i = 0; i < 3; i++)`のヘッダー部で宣言された`let`変数は、ループの1イテレーション（反復）ごとに、そのイテレーション専用の新しいレキシカル環境（Lexical Environment）のメモリ空間に『クローン（再バインド）』される」
ECMAScript仕様（ES2015以降）では、`for`ループの頭部にある`let`宣言は、単一の変数ルームを共有するのではなく、ループの各回（Iteration）ごとに新しい変数のインスタンスを暗黙的に生成し、前回のループ終了時の値を初期値としてバインドし直す仕様になっている。
結果として、各イテレーション内で生成されたクロージャ（上記の例では`setTimeout`のコールバック）は、それぞれ異なるスコープインスタンス（`i = 0`の環境、`i = 1`の環境、`i = 2`の環境）への参照を保持し続けることになる。
—
2. V8エンジンのメモリ空間とガベージコレクション（GC）の最適化
ここでパフォーマンスとメモリ管理の話をしよう。「ループごとに変数が生成されるなら、メモリリークや過剰なGCの発生源になるのではないか？」と懸念した読者がいれば、かなりの鋭さを持つエンジニアだ。
V8エンジン（あるいは近代的なJSエンジン）のヒープメモリ管理において、クロージャによってキャプチャされたスコープは、通常はヒープ領域（Heap）に割り当てられる。もしループのイテレーションごとにオブジェクトが生成され、それが延々と保持されれば、GCのプレッシャー（Minor GC / Major GCの頻発）が高まり、フレームレートのドロップやメインスレッドのブロッキングを引き起こす要因になり得る。
しかし、V8のIgnition（インタプリタ）とTurboFan（最適化コンパイラ）は非常に巧妙だ。
静的解析（Scope Analysis）の段階で、「そのスコープ内の変数がクロージャから参照され、かつスコープのライフサイクルを超えて生存する必要があるか（逃げているか：Escaping）」を判定する。
- ケースA：クロージャから参照されない場合
ループ内で完結する通常の`let i`であれば、ヒープではなくスタックフレーム内、あるいは最適化されたレジスタ上で高速に処理され、ループ脱出と同時に瞬時に破棄される。
- ケースB：非同期コールージャ等から参照される場合（今回のテーマ）
参照を維持する必要があるため、該当するイテレーションのスコープはヒープ上にコンテキストとして保持される。しかし、コールバックの実行が完了し、それらの参照が失われた瞬間、V8のジェネレーショナルGC（世代別ガベージコレクション）によって、若年世代（Nursery/Young Generation）のメモリ領域から効率的に回収される。
つまり、`let`によるブロックスコープのクローンは、「メモリ効率の安全性を担保するためにエンジン側が最適化しやすい粒度でスコープを独立させている」のであり、無駄なメモリ消費を恐れて古い`var`や複雑なスコープハックに逃げる必要は一切ない。むしろ、メモリのライフサイクルが明確になるため、予期せぬオブジェクトの停留（メモリリーク）を防ぐ堅牢な設計につながる。
—
3. 実務で即戦力となるプロダクションコード例
非同期APIの連続呼び出し、DOM要素の動的生成とイベントリスナーの割当など、実務で頻出するコンテキストにおいて、このブロックスコープの特性を最大限に活かした美しい設計パターンを提示する。
以下のコードは、複数の非同期タスクを順次または並行で安全に処理し、かつメモリ効率と可読性を極限まで高めた実用的なモジュールだ。
/
- @typedef {Object} TaskItem
- @property {string} id
- @property {string} endpoint
/
/
- 複数リソースの並行フェッチと、要素ごとのスコープを保証したDOMバインド処理
- @param {TaskItem[]} tasks
- @param {HTMLElement} containerEl
/
export async function processAndRenderBatch(tasks, containerEl) {
// フラグメントを使用してDOMの再描画コスト（リフロー・リパイン）を最小化
const fragment = document.createDocumentFragment();
// イテレーションごとに完全に独立したスコープが生成されるため、
// 後続の非同期処理やイベントリスナーでインデックスやIDが混濁する事故がゼロになる
for (let index = 0; index < tasks.length; index++) {
const task = tasks[index];
// DOM要素の生成
const itemEl = document.createElement('div');
itemEl.className = 'task-card';
itemEl.textContent = `タスク ${task.id} を読み込み中...`;
// クロージャとしてイベントリスナーを登録
// index と task は、このループインスタンスのレキシカル環境に安全に閉じ込められる
itemEl.addEventListener('click', async (event) => {
event.preventDefault();
try {
console.log(`[UI Action] タスク ${task.id} (インデックス: ${index}) がクリックされました。`);
// 動的なAPIフェッチなど
await executeTaskAction(task.id);
itemEl.classList.add(‘is-completed’);
} catch (error) {
console.error(`[Error] タスク ${task.id} の処理に失敗しました`, error);
}
});
fragment.appendChild(itemEl);
// 非同期処理を挟む場合でも、letによるスコープクローンにより
// iやtaskの参照ズレが起きないことを保証
fetchTaskData(task.endpoint, index).catch(err => {
console.warn(`バックグラウンド同期エラー [Index: ${index}]:`, err);
});
}
// 一括してDOMツリーにアタッチ（パフォーマンスの最適化）
containerEl.appendChild(fragment);
}
// ダミーのヘルパー関数
async function executeTaskAction(id) {
return new Promise(resolve => setTimeout(resolve, 300));
}
async function fetchTaskData(endpoint, index) {
// 実際のフェッチ処理を想定
return { endpoint, index, status: ‘ok’ };
}
この設計が優れている理由（テクニカルリードの視点）
1. 予期せぬ状態共有の完全な排除:
もしこれが`var`であれば、非同期イベントやクリックハンドラ内で参照される`index`や`task`がループ終了後の最終値を指してしまう、あるいは並行処理中に書き換わるという致命的なバグ（競合状態）の温床になっていた。`let`のスコープクローンがこれを完全にコンパイル・実行レベルでシャットアウトしている。
2. パフォーマンスへの配慮（DOMフラグメント）:
ループ内で直接`containerEl.appendChild()`を呼ぶと、DOMの変更ごとにブラウザのレンダリングエンジンがレイアウト計算（リフロー）を強制され、パフォーマンスが著しく低下する。`DocumentFragment`を活用し、メモリ上でツリーを構築してから一括反映させることで、レンダリングパイプラインの負荷を最小化している。
3. GCフレンドリーなスコープ設計:
各ループブロック内で宣言された変数（`itemEl`, `task`など）は、そのイテレーションのスコープが閉じると同時に参照の連鎖が切れるため、不要になったDOMノードやデータオブジェクトが速やかにガベージコレクションの対象となる。
—
結び：言語の「仕様」を武器にするエンジニアへ
「なぜそう書くのか」を説明できないコードは、いずれ技術的負債という名の爆弾に変わる。
`for`ループ内の`let`が単なる構文の糖衣ではなく、「イテレーションごとのレキシカル環境の独立（クローン）」というV8エンジンのメモリモデルに深く根ざした挙動であると知っていれば、非同期処理が絡む複雑なUIコンポーネント設計においても、迷いなく堅牢なコードを組み上げることができるはずだ。
コードレビューで「なぜここで`let`なのか」と問われたとき、自信を持ってエンジンの内部挙動から語れるエンジニアであれ。その深い知見こそが、プロダクトの品質を極限まで引き上げる最大の武器となる。