ブロックスコープの境界線：V8エンジンのメモリ空間から紐解く `let`/`const` の実像
JavaScriptの歴史は、スコープという「見えない防壁」との戦いの歴史であった。ES2015（ES6）で `let` と `const` が導入されて以来、私たちは `var` が引き起こしてきた数々の暗黒面――変数巻き上げ（Hoisting）による予期せぬ値の書き換えや、グローバル汚染の恐怖から解放された……はずだった。
しかし、シニアエンジニアやセキュリティ・アーキテクトであれば、文法的な使い方の表面をなぞるだけでは不十分だ。この「ブロックスコープ」という境界線が、V8エンジンのJITコンパイラ、ヒープメモリ上のガベージコレクタ（GC）、そして最悪のセキュリティ脆弱性であるプロトタイプ汚染やサプライチェーン攻撃において、どのように機能し、あるいは牙を剥くのかを完全に理解していなければならない。
今回は、初学者から一歩進み、ランタイムの深層までを網羅する視点から、ブロックスコープの真実を解剖する。
—
1. 関数スコープとブロックスコープのランタイム挙動
まずは基本の復習から始めるが、ここではV8エンジンのスコープ解析（Scope Analysis）の視点を取り入れる。
`var` は「関数スコープ」を持つ。つまり、どれだけ深い `if` 文や `for` 文のブロック内で宣言されても、その変数は最も近い関数（あるいはグローバル）のスコープチェーンに属する。一方、`let` と `const` は「ブロックスコープ」を持ち、中括弧 `{}` が作る境界線の外側からは物理的にアクセスできなくなる。
コード例：スコープの境界線と生存領域
‘use strict’;
function evaluateRuntimeScope() {
if (true) {
var functionScopedVar = “I am visible throughout the function”;
let blockScopedLet = “I am trapped inside this block”;
const blockScopedConst = “Me too, locked in the block”;
}
// var は関数スコープのため、ブロック外でもアクセス可能（値はundefinedではなく保持されている）
console.log(functionScopedVar); // => “I am visible throughout the function”
try {
// let / const はブロックスコープのため、ブロック外から参照するとReferenceError
console.log(blockScopedLet);
} catch (e) {
console.log(`Error caught: ${e.name} – ${e.message}`);
// => “Error caught: ReferenceError – blockScopedLet is not defined”
}
}
evaluateRuntimeScope();
V8エンジンの内部挙動：Context Allocation と Scope Info
V8はコードを実行する前に、まずパース（解析）を行い、AST（抽象構文木）を生成する。この段階で、どの変数がどのスコープに属するか（Scope Analysis）が静的に決定される。
- `var` の場合: 変数宣言は関数全体のスコープに巻き上げられ、関数オブジェクトが生成されるタイミングで、その関数コンテキストの変数オブジェクト（Variable Object）のスロットに割り当てられる。
- `let`/`const` の場合: ブロックごとに独立した語彙的環境（Lexical Environment）が構築される。さらに、これらは「一時的デッドゾーン（TDZ: Temporal Dead Zone）」というランタイムの防壁によって守られており、宣言文が評価される前にメモリアドレスにアクセスしようとすると、V8のパーサー／インタプリタが即座に `ReferenceError` をスローする。
—
2. 制御構造（`for` 文）におけるクロージャとメモリの物理最適化
初学者が最も陥りやすい罠であり、かつV8のメモリ管理を語る上で欠かせないのが `for` 文の中での非同期処理とスコープの関係だ。
罠：`var` を使ったループとクロージャの参照問題
// 危険なアンチパターン：var によるループ
function dangerousLoopWithVar() {
for (var i = 0; i < 3; i++) {
setTimeout(() => {
console.log(`var loop index: ${i}`);
}, 1005);
}
}
dangerousLoopWithVar();
// 出力結果（1秒後）：
// => var loop index: 3
// => var loop index: 3
// => var loop index: 3
なぜ `3` が3回出力されるのか？ `var i` は関数スコープ（あるいはグローバル）に1つしか存在しないため、ループが高速に完了した時点で `i` の値は `3` になり、`setTimeout` のコールバックが実行される時には、すでに書き換わった最終値まりの `3` を参照してしまうからだ。
解決策：`let` による反復ごとの環境バインディング
// 堅牢なモダンパターン：let によるブロックごとのスコープ生成
function robustLoopWithLet() {
for (let i = 0; i < 3; i++) {
// ES2015の仕様では、for(let i...) はループの反復ごとに
// 新しい Lexical Environment（語彙的環境）を生成し、
// 前回のループの値を保持した新しい変数 i をインスタンス化する。
setTimeout(() => {
console.log(`let loop index: ${i}`);
}, 1000);
}
}
robustLoopWithLet();
// 出力結果（1秒後）：
// => let loop index: 0
// => let loop index: 1
// => let loop index: 2
V8エンジンはこの挙動を実現するために、ループの反復ごとに裏側で新しいメモリ領域（Context）を割り当て、変数をクローン・バインドしている。この最適化により、意図しない変数の共有（データ競合やバグ）を完全に防ぐことができる。
—
3. イベントループとマイクロタスクキューの厳密な消費メカニズム
ブロックスコープで定義された変数の寿命（Lifespan）は、ガベージコレクション（GC）のライフサイクルと密接に関係している。ここでイベントループのタスクキューの仕組みを織り交ぜて考えてみよう。
以下のコードを見てほしい。
‘use strict’;
function processAsyncPipeline() {
console.log(‘1. 同期処理の開始’);
if (true) {
const heavyPayload = new Array(10000000).fill(0).map((_, idx) => ({ id: idx, data: ‘secure’ }));
// マイクロタスク（Promise）の登録
Promise.resolve().then(() => {
console.log(`3. マイクロタスク実行: ペイロード長 = ${heavyPayload.length}`);
});
}
// この時点でブロックは終了しているが、
// heavyPayload は Promise のクロージャ（Microtask）にキャプチャされているため、
// ガベージコレクションの対象外（生き残り）となる。
console.log(‘2. 同期処理の終了（ブロック外）’);
}
processAsyncPipeline();
実行順序の厳密なトレース
1. `1. 同期処理の開始` がコンソールに出力される。
2. `if` ブロック内で巨大な配列 `heavyPayload` がヒープ上にアロケートされ、`Promise.resolve().then(…)` によってマイクロタスクがマイクロタスクキューにエンキューされる。
3. `2. 同期処理の終了（ブロック外）` が出力される。コールスタックが空になる。
4. イベントループはコールスタックが空になったことを検知し、即座にマイクロタスクキューの処理へ移行する。
5. `3. マイクロタスク実行…` が出力される。
メモリの観点からの極限の知見
ブロックスコープを抜けたからといって、その中にある変数が即座にメモリから解放されるわけではない。クロージャによって外部から参照され続けている場合、その変数はV8のヒープ領域（Young Generation / Old Generation）に保持され続ける。
不用意にスコープをまたいだ非同期処理やコールバックに関数を渡すと、意図せぬメモリリークを引き起こす主原因となる。シニアエンジニアは「スコープの境界」だけでなく、「参照の寿命（Reference Lifetime）」を常に脳内でシミュレートしなければならない。
—
4. セキュリティ：ブロックスコープとプロトタイプ汚染（Prototype Pollution）の防壁
最後に、セキュリティ研究者およびアーキテクトの視点から、変数スコープと脆弱性について踏み込む。
近年、Node.jsエコシステムにおけるサプライチェーン攻撃として「プロトタイプ汚染（Prototype Pollution）」が猛威をふるっている。悪意あるペイロードが `Object.prototype` を書き換えることで、アプリケーション全体に影響を及ぼし、最悪の場合はリモートコード実行（RCE）へと繋がる。
ここで、適切にスコープ管理されたコードが、いかにして脆弱性の影響範囲（Blast Radius）を最小限に抑え込めるかを示す。
‘use strict’;
// 脆弱な外部ライブラリを模したマージ関数（プロトタイプ汚染の危険性あり）
function unsafeDeepMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
unsafeDeepMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
function handleUserData(userInputJSON) {
// ブロックスコープで入力データを安全に隔離
try {
const parsedInput = JSON.parse(userInputJSON);
const safeConfig = {};
// 危険なマージの実行（もし parsedInput に “__proto__” が含まれていれば汚染される可能性）
// ただし、safeConfig はこのブロックスコープ内のローカル変数であり、
// 外部のグローバルなオブジェクト汚染の連鎖を最小限に食い止める防壁となる。
unsafeDeepMerge(safeConfig, parsedInput);
console.log(“Config processed safely within block:”, safeConfig.theme || “default”);
} catch (err) {
console.error(“Malicious payload or invalid JSON rejected:”, err.message);
}
}
// 攻撃者が送り込んだペイロードのシミュレーション
const maliciousPayload = ‘{“__proto__”: {“polluted”: “RCE_PAYLOAD_ACTIVE”}}’;
handleUserData(maliciousPayload);
// ブロックスコープ外への影響確認
// （※Object.prototype自体が汚染された場合はグローバルに波及するため、
// 本当の対策は nullプロトタイプオブジェクト Object.create(null) の使用や入力バリデーションが必要）
console.log(`Global Object prototype check: ${{}.polluted}`);
アーキテクトの教訓：スコープは「脆弱性のコンテインメント（封じ込め）」である
もし変数やオブジェクトが `var` やグローバルスコープの汚染されたコンテキストに無防備に晒されていた場合、たった一つの脆弱なオブジェクトがアプリケーション全体のメモリ空間を侵食する。
現代のセキュアコーディングにおいて、`const` によるイミュータビリティの強制と、厳格なブロックスコープによる変数の生存期間・可視性の最小化（Principle of Least Privilege）は、単なる「コードを綺麗に保つための作法」ではない。それは、V8ランタイムの防壁を固め、サプライチェーン攻撃による爆風を最小限に食い止めるための、最前線のセキュリティエンジニアリングなのだ。
—
結びにかえて
たかが `let` と `const`、されど `let` と `const`。
私たちが何気なく記述している中括弧 `{}` と変数宣言は、V8エンジンのJITコンパイル、ヒープメモリのGCアルゴリズム、そして複雑な非同期イベントループの緻密な調和の上で成り立っている。
表面的な記法に甘んじることなく、ランタイムの鼓動を感じながらコードを紡ぎ出すこと。それこそが、真に信頼性の高い、堅牢なシステムを構築する唯一の道である。