TDZ（一時的死域）の深層：なぜ `let` と `const` は初期化前のアクセスを許さないのか
JavaScriptのランタイム、とりわけV8エンジンをはじめとするモダンJSエンジンにとって、変数の宣言とスコープの解決は、単なるシンタックスシュガーの処理ではなく、メモリ安全性とJITコンパイルの効率を極限まで高めるための緻密な最適化プロセスの一部である。
中級者からシニアへのステップアップにおいて、`var` と `let` / `const` の最大の違いを「ブロックスコープがあるかないか」だけで片付けているうちは、V8のヒープアロケーションやIgnition/TurboFanパイプラインの挙動を半分も見誤っていると言わざるを得ない。
今回は、ECMAScript仕様の深部とV8の内部実装（ランタイムライフサイクル）の視点から、TDZ（Temporal Dead Zone：一時的死域）がなぜ設計され、エンジン内部でどのような物理的防壁として機能しているのかを、コードと仕様の整合性を完全に紐解きながら解説する。
—
1. `var` の「巻き上げ（Hoisting）」と悲劇的な動的スコーピングの歴史
まずは、悪名高き `var` の挙動を思い出してほしい。JavaScriptの創世記において、変数の宣言は実行コンテキスト（Execution Context）の生成フェーズ（Creation Phase）において、Lexical Environment（字句環境）へ即座に登録され、同時に `undefined` で初期化されていた。
console.log(legacyVar); // ➡ undefined（エラーにならない）
var legacyVar = ‘ECMAScript 5’;
console.log(legacyVar); // ➡ “ECMAScript 5”
この「宣言前にアクセスしても `undefined` が返る」という挙動は、動的言語としての柔軟性を演出した一方で、バグの温床であった。意図しないグローバル汚染、巻き上げによる変数の上書き、そしてコードの意図とは異なる非直感的な制御フローを生み出した。
とりわけ、非同期処理やクロージャが絡んだ際、`var` の関数スコープと巻き上げは、エンジニアに深刻な認知負荷を強いてきた。V8エンジンは、この動的で予測不可能な変数の振る舞いを最適化するために、内部のHidden Class（隠しクラス）やInline Caching（インラインキャッシュ）の構築において余分なガードコードを挟まざるを得なかったのである。
—
2. TDZ（一時的死域）の本質：仕様とV8ランタイムの物理的防壁
ES2015（ES6）で導入された `let` と `const` は、このカオスに終止符を打った。
仕様書（ECMA-262）において、`let` や `const` で宣言された変数は、「宣言文（LexicalBinding）が評価されるまで、メモリ上のスロットに実体が紐づかない（Uninitialized状態）」と定義されている。
この「宣言から実際の初期化文の評価に至るまでのコード上の領域」こそが TDZ（一時的死域） である。
{
// — ここからTDZ —
// console.log(strictLet); // ➡ ReferenceError: Cannot access ‘strictLet’ before initialization
let strictLet = ‘ES2015+’; // — ここで初期化・TDZ終了 —
console.log(strictLet); // ➡ “ES2015+”
}
なぜエラーを投げる必要があるのか？（設計思想の根幹）
「なぜ `undefined` を代入するのではなく、わざわざ `ReferenceError` を投げるのか？」という疑問を持つシニアエンジニアは多い。答えは「イミュータビリティの保証」と「静的解析（Static Analysis）の極限化」にある。
もし `let` や `const` が初期化前に `undefined` を許容した場合、`const` で定数として宣言したはずの変数が、初期化文に到達するまでの間に暗黙的に `undefined` という「値」を持ってしまうことになる。これは `const` のセマンティクス（定数性）を根本から破壊する。
さらに、V8のJITコンパイラ（TurboFan）は、変数が「初期化済みであること」をコンパイル時の型推論とフロー解析の前提条件にしている。未初期化の状態をランタイムエラーとして厳格に弾くことで、エンジンは「このスコープ内の変数は、初期化された後は型が変化しない、あるいは安全にレジスタやスタックへ直接アロケートできる」という強力な仮説（Optimized Machine Code）を組み立てることができるのだ。
—
3. 仕様の深層：Environment Records と Binding のライフサイクル
ECMAScript仕様のレイヤで、何が起きているのかを厳密に追ってみよう。
JavaScriptの実行コンテキストは、変数や関数を管理するために Lexical Environment（字句環境） を持つ。Lexical Environmentは、内部に Environment Record（環境レコード） を保持しており、`let` や `const` は Declarative Environment Record（宣言的環境レコード） によって管理される。
Declarative Environment Record におけるバインディングのライフサイクルは、以下の3つのフェーズに分かれている。
1. Instantiation（生成フェーズ）:
スコープに入った際、識別子は環境レコードに登録される。しかし、`var` とは異なり、値（Value）スロットはアロケートされず、「Uninitialized（未初期化）」というメタ状態がマークされる。
2. Evaluation（評価フェーズ / 宣言文の実行）:
コードの実行フローが実際の `let x = …` や `const x = …` の位置に到達した瞬間、値が評価され、バインディングに実体が書き込まれ、状態が「Initialized」に遷移する。
3. TDZの消滅:
初期化が完了した瞬間から、その変数へのアクセスが許可される。
ここで重要なのは、TDZは「時間（Time）」ではなく「空間（Scope/Position）」の問題であるという点だ（そのため Temporal Dead Zone と呼ばれる）。コード上の物理的な位置（行番号）において、スコープの開始から初期化文の記述位置に至るまでの間がTDZとなる。
`typeof` 演算子における例外的な挙動の仕様
興味深いことに、`var` や存在しない変数に対して `typeof undeclaredVar` を実行しても、安全に `”undefined”` が返る。しかし、TDZにある `let` や `const` に対して `typeof` を実行すると、なんと ReferenceError が発生する。
console.log(typeof nonExistent); // ➡ “undefined” （安全）
{
// console.log(typeof tdzLet); // ➡ ReferenceError!
let tdzLet = 10;
}
これは、TC39の仕様策定時に「安全でない未初期化変数へのアクセスを完全に検知し、バグを早期に発見するため」にあえてこのような厳格な仕様が選択されたためである。V8のパーサーは、スコープ内で宣言されている変数に対して `typeof` が使われた場合であっても、それがTDZ内であれば容赦なく例外をスローするバイトコードを出力する。
—
4. 高度なトラップ：クロージャとTDZの相互作用
中級者が最もハマり、かつV8のクロージャ解析の深淵を垣間見るのが、デフォルト引数やクロージャとTDZが交錯する瞬間だ。
以下のコードを見てほしい。
const x = ‘global’;
function checkScope(x = x) {
console.log(x);
}
// checkScope(); // ➡ ReferenceError: Cannot access ‘x’ before initialization
なぜこのコードはエラーになるのか？
関数のパラメータリスト（Default Parameter）は、関数本体のスコープとは異なる独自のスコープ（Parameter Lexical Environment）を持つ。
`x = x` という式において、右側の `x` は、まだ初期化が完了していない（あるいは外側のスコープをシャドウイングしている）パラメータの `x` を指してしまっている。この瞬間、右側の `x` はTDZ内に存在するため、参照した瞬間に `ReferenceError` が発火する。
V8は、このパラメータ評価フェーズにおいて、一時的なスコープチェインを構築し、外側へのフォールバックが発生する前に内側の同名変数（未初期化）をヒットさせてしまう。この挙動を知っていれば、関数引数のデフォルト値で自分自身の名前をうっかり参照してしまうバグを未然に防ぐことができる。
—
5. セキュリティとランタイム防壁：サプライチェーン攻撃への耐性
最後に、この厳格なTDZと変数管理が、現代のWebアプリケーションセキュリティ、特にプロトタイプ汚染（Prototype Pollution）やサプライチェーン攻撃に対する強力な防壁となっている点に言及しておこう。
悪意あるサードパーティ製パッケージがグローバルオブジェクトや `Object.prototype` を汚染し、動的なプロパティアクセスや `eval()` / `new Function()` を用いてコードインジェクションを試みる手法は後を絶たない。
しかし、モダンなESモジュール（ESM）環境下では、すべてのコードはデフォルトで厳格モード（`use strict`）かつトップレベルスコープがモジュール固有のLexical Environmentに閉じ込められている。`var` のようにグローバルオブジェクトのプロパティとしてホイスティングされないため、意図しないグローバル変数の乗っ取りや、巻き上げを利用した変数偽装の攻撃ベクトルが根本から断たれている。
V8エンジンレベルでも、`let` や `const` のスコープ変数は、動的なハッシュマップ（Dictionary Mode）ではなく、固定オフセットを持つFast Properties（固定プロパティレイアウト）やスタック上のローカルスロットとして直接管理されるため、プロトタイプ汚染によるプロパティルックアップのハイジャックの影響を受けにくい。
—
結言：ランタイムの仕様を味方につける
`let` や `const` のTDZは、決して開発者を縛るための窮屈なしつけではない。
それは、JavaScriptというダイナミックな言語が、静的な安全性とV8エンジンによる極限のJIT最適化（高速な機械語生成）を両立させるために勝ち取った、極めて洗練されたアーキテクチャの結実である。
変数のライフサイクル、スコープの物理的構造、そしてV8のメモリモデルを脳内に完全に同期させた時、あなたの書くコードは単なる「動くスクリプト」から、ランタイムの防壁と完全に調和した「堅牢なシステムアーキテクチャ」へと昇華する。仕様の裏側にあるコンパイラの意図を看破し続けよ。