コードレビューをしていて、未だに以下のようなコードを見かけるたびに私は頭を抱えたくなる。
// 【アンチパターン】varが生んだ歴史的呪物
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 100);
}
// 出力: 3, 3, 3 （お馴染みの絶望）
なぜ未だにこんなコードが生まれるのか？ それは「変数の宣言とスコープ、そしてメモリの物理的な挙動」を、単なる「書き方のルール」として表面的な暗記で済ませているからだ。
フロントエンドのテクニカルリードとして、私は今日、あなたにV8エンジンの内部構造（ヒープメモリ空間）の解剖から話を進めたい。ES2015（ES6）で導入された `let` が、forループのイテレーションごとにどのように「レキシカル環境のクローン」を生み出し、非同期処理（クロージャ）と結びついたときにメモリ上で何が起きているのか。その真実をロジカルに紐解いていこう。
—
1. V8エンジンが裏側で行っていること：`var` と `let` のメモリ構造の断絶
まず、JavaScriptランタイム（V8）の視点に立ってみよう。
`var` は関数スコープを持つ。そのため、どれだけ深いネストやループがあっても、変数 `i` が陣取る領域は、その関数コンテキスト（あるいはグローバル）の「変数オブジェクト（Variable Object）」内の単一のスロットだ。ループがどれだけ回ろうとも、参照しているのはただ一つの同じメモリアドレスである。だからこそ、非同期コールバックが実行される頃には、ループを抜けきった最終値（例では `3`）がそのアドレスに上書きされており、すべてのクロージャが「同じ亡霊」を参照するハメになる。
では、モダンな `let` はどうだろうか？
ECMAScript仕様書をめくると、forループにおける `let` の挙動は非常にエレガントに定義されている。
> 「ループの各イテレーション（反復）において、新しいレキシカル環境（Lexical Environment）がインスタンス化され、その中にそのイテレーション用の変数がバインドされる」
つまり、V8のヒープ上では、ループが3回回れば、論理的かつ物理的に独立した3つの変数スコープのインスタンスが生成されている。各イテレーションで生成されたアロー関数やクロージャは、それぞれ自分が生まれた瞬間に存在していた「専用のレキシカル環境」をキャプチャする。これが、`let` が非同期処理やイベントリスナーの登録においてバグを防ぐ根本的な理由だ。
—
2. 実務で直面するメモリリークの罠：クロージャとGCの挙動
「じゃあ、ループごとに環境が作られるなら、メモリを無駄に食いつぶすんじゃないか？」
鋭いエンジニアならそう懸念するだろう。その直感は正しい。
ここでガベージコレクション（GC）とクロージャのライフサイクルに関する重要な知見を共有しよう。
V8のガベージコレクタ（OrinocoやScavengerエンジン）は、マーク・アンド・スイープ方式を基本とし、到達可能性（Reachability）に基づいて不要なメモリを回収する。
もし、forループ内で生成されたレキシカル環境への参照が、ループ終了後にすべて消滅するのであれば、マイナーGC（世代別GCの若い世代の回収）によって瞬時にメモリは開放される。
しかし、もしそのループ内で定義された関数が、外部（グローバルなイベントリスナー、長期生存するキャッシュ、あるいはDOM要素へのアタッチなど）に保持された場合、話は180度変わる。
メモリリークを招く最悪のコンポーネント設計例
以下のコードを見てほしい。一見なんの変哲もない、DOM要素のリストにイベントをバインドする処理だ。
// 【危険なプロダクションコード】
// 巨大なデータを保持するクロージャがメモリに居座り続けるケース
const badRegistry = [];
function initWidget(largeDataSet) {
const container = document.getElementById(‘item-list’);
for (let i = 0; i < largeDataSet.length; i++) {
const itemData = largeDataSet[i]; // 巨大なオブジェクトを想定
const button = document.createElement('button');
button.textContent = `Item ${i}`;
// 各ボタンが、そのイテレーションのレキシカル環境をクロージャとして保持
button.addEventListener('click', () => {
// 意図せず `itemData` だけでなく、このスコープ全体のバインディングが保持される
console.log(itemData.name);
});
// さらに、グローバルな配列にDOMや関数をプッシュしてしまうと…
badRegistry.push({ button, handler: () => console.log(itemData.id) });
container.appendChild(button);
}
}
このコードの問題点がお分かりだろうか？
`let itemData` はループごとに新しく生成されるレキシカル環境にバインドされている。そして、アロー関数（クロージャ）がその環境への参照（スコープチェーン）を保持しているため、ループ内で扱われたすべての `itemData`（巨大なデータセットの一部）が、DOM要素やグローバル配列が生存している限り、V8のヒープ上に永続的に残り続ける。
「不要になったDOMだから破棄しよう」と親要素を `innerHTML = ”` で消したとしても、グローバルな `badRegistry` がハンドラを保持している場合、レキシカル環境全体の参照が切れないため、GCはメモリを回収できない。これが実務で頻発する「クロージャ起因のメモリリーク」の正体だ。
—
3. 堅牢性とパフォーマンスを両立するプロダクション設計パターン
では、どのように設計すべきか。テクニカルリードとして、私がコードレビューで必ずパスを出す「美しく、かつV8のメモリ効率を最大化する設計パターン」を提示しよう。
パターンA：必要なデータだけを切り出し、スコープを最小化する
余計なオブジェクト全体への参照をクロージャに持たせず、プリミティブな値や必要なプロパティのみをローカル変数にコピー、あるいはスコープを明示的に切り分ける。
/
- 【推奨されるプロダクションコード】
- メモリフットプリントを最小限に抑え、GCの回収効率を高めたイベントバインディング
/
function initWidgetOptimized(largeDataSet) {
const container = document.getElementById(‘item-list’);
// DOMの断片化を防ぎ、リフローを抑制するためのDocumentFragment
const fragment = document.createDocumentFragment();
// ループの外側でイベント委譲（Event Delegation）を使うのが最高パフォーマンスだが、
// 個別バインドが必要な場合のメモリ最適化例を示す
for (let i = 0; i < largeDataSet.length; i++) {
// 参照を保持させたくないため、必要なプリミティブ値だけを抽出
const itemId = largeDataSet[i].id;
const itemName = largeDataSet[i].name;
const button = document.createElement('button');
button.textContent = `Item ${itemName}`;
button.dataset.id = itemId; // DOM自身に持たせることでクロージャの依存を断つ
button.addEventListener('click', (event) => {
// スコープ外の巨大なオブジェクトに依存せず、イベントターゲットからデータを引く
handleItemClick(event.target.dataset.id);
});
fragment.appendChild(button);
}
container.appendChild(fragment);
}
function handleItemClick(id) {
console.log(`Clicked item ID: ${id}`);
}
この設計の優れている点は以下の通りである：
1. クロージャの肥大化防止: アロー関数がキャプチャするレキシカル環境内に、巨大な `largeDataSet[i]` オブジェクトがまるごと取り残されることがなくなる。
2. DOMの効率化: `DocumentFragment` を使うことで、DOMツリーの再描画（レンダリングパイプラインのLayout/Paint）を1回に抑制している。
3. イベント委譲（Dataset）の活用: クロージャ自体にデータを閉じ込めず、DOMの属性（`data-`）に状態をオフロードすることで、メモリ管理の主導権をV8のGCからDOMライフサイクル側へと綺麗に調停している。
—
4. プロファイラ（Chrome DevTools）でレキシカル環境のクローンを暴く
言葉だけではなく、実際のパフォーマンスとメモリの動きを検証する方法もお伝えしておこう。
Chrome DevToolsの Memoryタブ を開き、Allocation instrumentation on timeline（タイムライン上の割り当て計測）または Heap Snapshot を取得してほしい。
1. `let` を使った重いループ処理を実行する。
2. ヒープスナップショットを撮影し、コンストラクタフィルターに `Closure` または `system / Context` と入力する。
3. すると、各イテレーションごとに生成された `Context`（レキシカル環境の実体）がツリー状に、あるいは独立して存在している様子が確認できる。
もし、意図しないメモリリークが起きている場合、この `Context` オブジェクトの下層に、解放されるべきはずの巨大な配列やDOMノードがぶら下がっているのが一目でわかるはずだ。プロファイラを見れば、誰がどのスコープを「つかんで放さないのか」が残酷なまでにロジカルに暴かれる。
—
5. チーフアーキテクトからの総括
JavaScriptにおける `let` とブロックスコープは、単に「`var` の巻き上げによるバグを防ぐための便利な糖衣構文」ではない。
それは、V8エンジンのメモリ空間上に、安全かつ予測可能なスコープの境界線を動的に彫り込むための強力なメカニズムである。
しかし、その強力さゆえに、クロージャとの組み合わせ方を誤れば、開発者が意図しないところでメモリが肥大化し、ブラウザのタブをクラッシュさせる原因になり得る。
コードを書くときは常に自問してほしい。
- 「このループ内で生成されるレキシカル環境は、どのスコープへの参照を抱え込んでいるか？」
- 「そのクロージャは、本当にその寿命の長さを必要としているか？」
この問いを常に持ち続けることこそが、ジュニアから真のシニア・フロントエンドエンジニアへと飛躍するための絶対条件である。あなたの書くコードが、美しく、軽量で、堅牢なランタイムの調和を生み出すことを期待している。