序章：コードレビューの現場から
「なぜ、このコードは初期化前にアクセスしてエラーになるはずなのに、`undefined`を吐き出してサイレントバグを引き起こしているんだ？」
プルリクエストのレビュー中、ジュニアエンジニアが書いた旧態依然とした`var`のコードを見つけ、私は思わずため息をついた。現代のフロントエンド開発において、もはや`var`を使う理由など1ミリたりとも存在しない。しかし、「なぜ`let`や`const`を使うべきなのか」を問うと、多くのエンジニアは「スコープがブロック単位になるから」「再代入を防げるから」といった、入門書の最初のページに書いてある表層的な理由しか答えてくれない。
V8エンジンがJavaScriptのソースコードをどのようにパースし、メモリ空間を割り当て、実行コンテキストを構築しているのか。その深部まで理解していなければ、複雑な非同期処理やクロージャが絡み合う大規模SPA（Single Page Application）のメモリリークや、意図しない変数の上書きを防ぐことはできない。
今回は、JavaScriptエンジンがコードを解釈する「2つのフェーズ」を解体し、`var`の巻き上げ（Hoisting）の正体と、`let`/`const`がまとう不可視の障壁「TDZ（一時的死区間：Temporal Dead Zone）」のメカニズムを、ランタイムのメモリ管理の視点から完全に剥き出しにして解説しよう。
—
1. V8エンジンを支配する「2つのフェーズ」
JavaScriptは「インタプリタ言語だから一行ずつ気楽に上から実行されている」などと考えていたら、プロダクション環境のパフォーマンスチューニングで痛い目を見る。V8をはじめとするモダンなJSエンジンは、コードを実行する前に必ず「コンパイル（Creation / 解析）フェーズ」と「実行（Execution）フェーズ」という明確な2段階のステップを踏んでいる。
[ ソースコード ]
│
▼
1. コンパイルフェーズ (Creation Phase)
- 構文解析・AST生成
- 実行コンテキストの作成
- 変数・関数のメモリ割り当て（ここで「巻き上げ」が発生）
│
▼
2. 実行フェーズ (Execution Phase)
- 上から順にコードを実行
- 値の代入・関数の呼び出し
コンパイルフェーズ（Creation Phase）
エンジンがコードを実行する直前、スコープ（グローバル、関数、ブロック）ごとに「実行コンテキスト（Execution Context）」が生成される。このフェーズでは、コード内の文はまだ1行も実行されていない。エンジンが行っているのは、コード全体の構造をスキャンし、変数や関数宣言の識別子をメモリ（変数環境 / Lexical Environment）に登録する作業だ。
実行フェーズ（Execution Phase）
コンパイルフェーズが完了し、メモリ上に変数の器（スロット）が確保された後で初めて、コードが上から順に実行され、実際の値が代入されていく。
この「フェーズの分離」こそが、JavaScript特有の「巻き上げ（Hoisting）」という現象のすべての元凶であり、同時に`let`/`const`の安全性を担保するメカニズムの核心なのだ。
—
2. `var`の巻き上げの正体と、メモリ空間の闇
では、`var`で宣言された変数は、コンパイルフェーズで何を引き起こしているのだろうか。
結論から言えば、`var`の宣言は、コンパイルフェーズにおいてメモリ上の変数領域を確保すると同時に、初期値として強制的に`undefined`をバインドする。
以下のコードを見てほしい。
console.log(currentUser); // 1. ここで何が出力されるか？
var currentUser = “Alice”;
console.log(currentUser); // 2. ここでは？
これを「2つのフェーズ」の観点から脳内トレースしてみよう。
1. コンパイルフェーズ:
エンジンがコード全体をスキャンし、`var currentUser`を見つける。メモリ上に`currentUser`というスロットを確保し、自動的に初期値 `undefined` を書き込む。
2. 実行フェーズ:
1行目の `console.log(currentUser)` が実行される。メモリを覗きに行くと、すでにそこには`undefined`が存在しているため、エラーにならずに`undefined`がコンソールに出力される。
2行目で初めて `”Alice”` という値がメモリ上のスロットに代入（上書き）される。
3行目では `”Alice”` が出力される。
これが`var`の巻き上げの正体である。変数名だけが上に「引っ越す」のではなく、コンパイル時にメモリ確保と`undefined`の初期化が同時に行われているだけなのだ。この仕様は、意図しないバグ（初期化前の変数を参照してしまう事故）を量産する最大の温床となってきた。
—
3. TDZ（一時的死区間）の正体：なぜ`let`と`const`は安全なのか
現代的なJavaScript（ES6以降）で導入された`let`と`const`は、この`var`の緩慢な仕様を根底から覆した。
`let`や`const`も実はコンパイルフェーズで「巻き上げ（宣言の登録）」は行われている。しかし、`var`との決定的な違いは、「メモリの確保は行うが、初期化（値のバインド）を行わない」という点にある。
この、「メモリ領域は確保されたが、値が初期化されていない（アクセス不能な）状態の期間・空間」こそが、TDZ（Temporal Dead Zone：一時的死区間）の正体である。
// — ここからTDZの開始 —
console.log(apiKey); // ReferenceError: Cannot access ‘apiKey’ before initialization
// — ここまでTDZ —
let apiKey = “secret_12345”;
// この宣言の評価が行われた瞬間にTDZが終了し、メモリに値がバインドされる
V8エンジンの内部挙動
エンジンはコンパイルフェーズで`let apiKey`の存在を認識し、レキシカル環境にスロットを作る。しかし、フラグとして「未初期化（Uninitialized）」のマークを立てておく。
実行フェーズにおいて、コードがその変数の宣言行に到達する前に変数にアクセスしようとすると、エンジンは「おっと、このスロットはまだ未初期化マークがついている（＝TDZ内だ）」と検知し、即座に`ReferenceError`をスローして実行を強制停止する。
これにより、「初期化されていないゴミデータや`undefined`を誤って読み込んでしまう」という、`var`時代に頻発した致命的なバグがコンパイル・実行レベルで完全に遮断されることになった。
—
4. 実務で即座に役立つ設計パターンとプロダクションコード
テクニカルリードとして、私はチームメンバーに次のコーディング規約を徹底している。
1. `var`の完全な廃止（ESLintで`no-var`をエラーに設定）
2. 基本はすべて`const`で宣言し、再代入が不可避な場合のみ`let`を使用する
3. 変数のスコープを極限まで狭め、TDZの恩恵を最大限に受ける
ここでは、非同期API連携とDOM操作が絡む、実務で頻出するコンポーネント初期化処理の「美しいプロダクションコード例」を示す。
悪い例：`var`とスコープ汚染、巻き上げによるバグ温床コード
// 【アンチパターン】保守性が最悪なレガシーコード
var retryCount = 0;
function initializeDashboard() {
var data = fetchUserData(); // 非同期なのにvarで受けてしまっている
if (!data) {
var errorMessage = “データ取得失敗”;
console.warn(errorMessage);
} else {
// varは関数スコープのため、ifブロックの外でもerrorMessageにアクセスできてしまう（バグの元）
console.log(errorMessage);
}
for (var i = 0; i < 3; i++) { // ループカウンタiが関数スコープ全体に漏れ出す setTimeout(function() { console.log("リトライ回数: " + i); // すべて「3」が出力されるクロージャの罠 }, 1000 i); } }
模範例：TDZとブロックスコープを活かした堅牢なプロダクションコード
/
- ユーザーダッシュボードを初期化する堅牢な非同期処理
- @param {string} userId
- @returns {Promise
}
/
async function initializeDashboardSecure(userId) {
// 定数はconstで。再代入不可のイミュータブルな設計にする
const MAX_RETRIES = 3;
let currentRetry = 0;
// 入力値のバリデーション（早期リターン）
if (!userId || typeof userId !== ‘string’) {
throw new TypeError(‘有効なuserIdが指定されていません。’);
}
try {
// TDZの保護下で安全にAPIコールを待機
const response = await fetchUserData(userId);
// ブロックスコープを活用し、このブロック内だけで有効なエラーメッセージを定義
if (!response.ok) {
const blockScopedErrorMsg = `APIエラー: ${response.statusText}`;
console.warn(blockScopedErrorMsg);
return;
}
const userData = await response.json();
renderUserProfile(userData);
} catch (error) {
// ネットワークエラー等のハンドリング
console.error(‘ダッシュボードの初期化に失敗しました:’, error.message);
// 適切なエラーバウンダリへの伝播やフォールバック処理
handleInitializationFailure();
}
}
/
- モックAPI関数
/
async function fetchUserData(id) {
// 実際のフェッチ処理を想定
return { ok: true, json: async () => ({ id, name: “Taro Dev” }) };
}
function renderUserProfile(data) {
console.log(`レンダリング完了: ${data.name}`);
}
function handleInitializationFailure() {
// フォールバックUIの描画など
}
このコードでは、すべての変数が最小限のスコープ（ブロックスコープ）に閉じ込められており、意図しない変数の再利用や巻き上げによるバグが入り込む余地が1ナノメートルも存在しない。
—
5. パフォーマンスとレンダリングパイプラインへの影響
「変数の宣言方法ごとの違いが、ブラウザのパフォーマンスやDOMレンダリングに影響するのか？」という疑問を持つシニアエンジニアもいるかもしれない。
結論から言えば、V8エンジンのJIT（Just-In-Time）コンパイラは、`let`や`const`が「再代入されないこと（Constancy）」を検知した場合、強力な最適化（定数畳み込みやインライン展開など）を適用しやすい。
また、ブロックスコープを適切に使用し、不要になった変数が速やかにガベージコレクション（GC）の対象となるメモリ構造を作ることは、シングルページアプリケーション（SPA）におけるメモリリークを防ぎ、長時間のセッションでもスムーズなDOMレンダリングパイプライン（レイアウト・ペイントの高速化）を維持するために極めて重要である。
`var`を排除し、`const`と`let`でコードの意図を厳格に縛ることは、人間にとって読みやすいだけでなく、V8エンジンにとっても最も最適化しやすい（高速に実行できる）コードを書いていると同義なのだ。
—
結びにかえて
JavaScriptの仕様の歴史は、時として複雑な“負債”を私たちに残してきた。その代表格が`var`の巻き上げ挙動である。
しかし、その裏にあるコンパイルフェーズと実行フェーズのメカニズム、そしてTDZがなぜ生まれたのかというランタイムの文脈を深く理解していれば、もはやバグは偶然の産物ではなく、防ぐべき論理的な必然に変わる。
コードレビューで曖昧な記述を見かけたら、こう問いかけてほしい。
「その変数、本当にそのスコープで初期化前にアクセスされるリスクを考慮していますか？」と。
確かな知見に裏打ちされた美しいコードこそが、プロダクションの未来を救う。明日からのあなたのコーディングが、V8エンジンにとっても、チームの仲間にとっても、美しく最適化されたものであることを願う。