V8エンジンの鉄律：`let`と`var`がスタックとヒープの物理メモリレイアウトを書き換える瞬間
JavaScriptを単なる「手軽なスクリプト言語」と侮っているならば、現代のWebアプリケーション、そしてNode.jsランタイムの底知れぬ挙動の9割を見誤っていることになる。ブラウザのレンダリングパイプラインを1フレーム単位で最適化し、数百万リクエストをさばくマイクロサービスのメモリフットプリントを極限まで削るためには、コードがV8エンジン（あるいはJavaScriptCore）の内部でどのようにバイトコードにコンパイルされ、物理メモリ（スタックとヒープ）のどの領域に配置されるかを完全に掌握していなければならない。
今回は、変数の宣言に用いられる`var`と`let`が、V8エンジンのメモリレイアウト、スコープチェイン、そしてガベージコレクション（GC）のライフサイクルにいかなる決定的な違いをもたらすのか。その低レイヤの真実を、チーフアーキテクトの視点から解き明かしていく。
—
1. プリミティブとオブジェクト：V8ヒープとスタックの物理的実態
JavaScriptのデータ型はプリミティブ（Number, String, Boolean, Symbol, BigInt, null, undefined）とオブジェクト（Object, Array, Function等）に大別される。よくある誤解として「プリミティブはすべてスタックに乗り、オブジェクトはヒープに乗る」というものがあるが、これはV8の内部実装を完全に無視した俗説に過ぎない。
V8エンジン（Ignition / TurboFan）において、実行コンテキスト（Execution Context）のコールスタックフレームには、プリミティブ値そのもの、あるいはヒープ上のメモリを指すポインタ（参照アドレス）が格納される。
[ Call Stack Frame ]
+————————-+
| let a = 42; | -> 42（生の値がスタックに直接常駐）
+————————-+
| let obj = { x: 10 }; | -> [Heap Pointer 0x7fff…] （参照値のみスタックに置き、本体はヒープへ）
+————————-+
では、`var`と`let`はこのメモリ配置に対してどのような干渉を行うのか。その答えは、変数の「巻き上げ（Hoisting）」と「レキシカル環境（Lexical Environment）」の構造にある。
—
2. `var`の関数スコープと、`let`のブロックスコープがもたらすメモリの生死
`var`：関数スコープと巻き上げの代償
`var`で宣言された変数は、関数スコープ（またはグローバルスコープ）に属する。V8がコードをパースし、AST（抽象構文木）からバイトコードを生成する際、`var`変数はその関数の実行コンテキストの生成と同時に`undefined`で初期化され、Variable Environmentにスロットとして組み込まれる。
この挙動が意味するのは、不要になったスコープ内であっても、クロージャや不適切な参照によってガベージコレクション（GC）の回収対象から外れ続けるリスクである。
`let`：Temporal Dead Zone（TDZ）とブロックスコープの最適化
一方、ES2015で導入された`let`（および`const`）は、ブロックスコープ `{}` ごとにLexical Environmentを形成する。
V8のコンパイラ（Ignition）は、`let`で宣言された変数のライフサイクルがそのブロック内に厳密に閉じていることを静的解析で検知できるため、不要になったブロックを抜けた瞬間に、スタック上の領域やヒープの参照を切断し、世代別GC（Minor GC / Scavenger）の回収効率を劇的に向上させる。
さらに、`let`は「Temporal Dead Zone（一時的死空間）」を強制する。宣言前にアクセスするとReferenceErrorをスローするこの仕様は、単なる言語仕様の安全弁ではなく、V8が変数の初期化漏れによるメモリアクセス違反や、不正なポインタ参照をコンパイル段階・実行初期段階で完全に封じるための防壁なのだ。
—
3. 隠しクラス（Hidden Classes / Maps）とインラインキャッシュの最適化破壊
変数の宣言方法とスコープの管理は、オブジェクトの物理最適化にも直結する。V8は動的言語であるJavaScriptのオブジェクトプロパティアクセスを高速化するため、「隠しクラス（V8内部では Maps と呼ばれる）」と「インラインキャッシュ（Inline Caches: IC）」を駆使する。
以下のコードを見てほしい。
// パターンA: varによる動的なプロパティ追加
function createUserVar(name) {
var user = {};
user.name = name;
if (Math.random() > 0.5) {
user.age = 30; // 実行時の条件によってHidden Classが分岐・遷移する
}
return user;
}
// パターンB: letとconstによるブロック内での構造化
function createUserLet(name, age) {
// スコープを限定し、イミュータブルに近い形でオブジェクトの初期形状を確定
const user = {
name: name,
age: age ?? 20 // 形状を事前に確定させ、V8のMap遷移を単一に保つ
};
return user;
}
パフォーマンスの分かれ道
`var`を多用し、あちこちのブロックで場当たり的にプロパティを追加・変更するコードは、V8のMapを何度も遷移（Transition）させ、インラインキャッシュを「メガモーフィック（Megamorphic：多態性状態）」に叩き落とす。結果として、プロパティアクセスはJITコンパイルされたネイティブコードから、低速な辞書引き（Dictionary Mode）へとフォールバックし、CPUキャッシュヒット率を著しく低下させる。
`let`や`const`を活用し、ブロックスコープ内でオブジェクトの初期形状（Shape）を一度に定義しきることが、V8のTurboFanに「このオブジェクトの構造は変化しない」という強力なヒントを与え、最適化されたマシン語へのコンパイルを誘発する絶対条件なのだ。
—
4. イベントループとメモリリーク：非同期処理におけるスコープの罠
Node.jsやブラウザのイベントループ（マクロタスクとマイクロタスク）において、`var`と`let`のスコープ特性の理解不足は、致命的なメモリリークを引き起こす。
以下の極悪なコードアンチパターンを分析しよう。
// 【アンチパターン】varを使用した非同期ループ
function processBadRequests(requests) {
for (var i = 0; i < requests.length; i++) {
// varは関数スコープのため、変数iはループの外（関数全体）に漏れ出し、
// クロージャによって参照され続ける。
setTimeout(function() {
console.log(`Processing request: ${requests[i].id}`);
}, 1000 i);
}
}
このコードでは、`var i`は関数スコープ全体で共有される単一のメモリ領域を指し続ける。ループが瞬時に完了した後も、非同期タイマー（マイクロ/マクロタスクキュー）が保持するクロージャのコンテキスト内に`i`および`requests`配列の参照が残り続けるため、GCが機能せず、巨大なヒープ領域が幽霊のように居座り続ける（メモリリークの発生）。
これを`let`に置き換えるだけで、V8のランタイム挙動は一変する。
// 【推奨パターン】letによるブロックスコープとイミュータブルな束縛
function processOptimalRequests(requests) {
for (let i = 0; i < requests.length; i++) {
// letはループの反復（Iteration）ごとに新しいLexical Environment（ブロックスコープ）を生成する。
// これにより、各タイマーは独自の変数iのインスタンスをスタック/ヒープ上に独立して保持する。
setTimeout(() => {
console.log(`Processing request: ${requests[i].id}`);
}, 1000 i);
}
}
`let`を使用した場合、V8はループの各イテレーションごとに新しいレキシカル環境のインスタンスを生成する。これにより、タスク完了後のスコープ解放と同時に、GCが安全かつ迅速にメモリを回収できるようになる。
—
5. セキュリティ・フロンティア：プロトタイプ汚染とランタイムの防壁
最後に、シニアエンジニアやセキュリティ研究者が最も直視しなければならない「プロトタイプ汚染（Prototype Pollution）」と変数スコープの関係について踏い込もう。
モダンなJavaScriptアプリケーション（特にNode.jsのバックエンド）において、JSONのパースやディープマージ処理の脆弱性を突いたプロトタイプ汚染は、サプライチェーン攻撃の常套手段である。
// 脆弱なマージ関数の例（プロトタイプ汚染の温床）
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 target;
}
// 攻撃者がペイロードを送り込む
const maliciousPayload = JSON.parse(‘{“__proto__”: {“polluted”: true}}’);
unsafeMerge({}, maliciousPayload);
// グローバルなObjectプロトタイプが汚染される
console.log({}.polluted); // true が出力され、全オブジェクトの挙動が書き換わる
ランタイム防壁の構築
この脆弱性に対し、単に`let`や`const`を使うだけでは直接的な防御にはならない。なぜならプロトタイプ汚染はヒープ上の大元のコンストラクタ（`Object.prototype`）を書き換えるからだ。
しかし、`let`やブロックスコープを活用してグローバル汚染の影響範囲を局所化し、さらにV8の機能やモダンなNode.jsのAPIを活用してランタイムを硬化させることは可能である。
1. オブジェクトの凍結（Object.freeze）: 重要な設定オブジェクトやプロトタイプチェーンの末端を凍結し、V8に書き込み禁止のメモリ保護（Read-only memory flags）を意識させる。
2. 汚染不可能な構造の強制: `Map`や`Set`オブジェクトを活用する。これらはプレーンオジェクト（`{}`）と異なり、プロトタイプチェーンを持たないため、プロトタイプ汚染の攻撃ベクトルから完全に切り離された安全なヒープ領域を構築できる。
// Mapを使用したセキュアなキーバリューストレージ
const secureStore = new Map();
secureStore.set(‘safeKey’, ‘value’);
// プロトタイプ汚染を試みてもMapの内部構造は絶対に侵されない
console.log(secureStore.get(‘__proto__’)); // undefined
—
結言
変数宣言という、一見して最も基礎的なJavaScriptの構文。しかし、その背後にある`var`と`let`の選択は、V8エンジンのJITコンパイル結果、インラインキャッシュの効率、ヒープメモリの断片化、GCの回収効率、そしてアプリケーションのセキュリティ境界線そのものを決定づけている。
「動くからいいや」という妥協を捨て、ランタイムの物理レイアウトを脳内で完全にトレースしながらコードを紡ぎ出すこと。それこそが、真にスケーラブルで堅牢なシステムを構築するエンジニアに求められる唯一にして最高の素養である。