関数宣言と変数宣言の巻き上げ優先順位：AST（抽象構文木）から読み解くV8の静的解析とスコープ解決の真実
JavaScriptエンジンがソースコードを実行する前段階、すなわちV8におけるIgnitionバイトコードへのコンパイル直前、コードは字句解析（Lexical Analysis）と構文解析（Syntax Analysis）を経てAST（抽象構文木）へと変換される。
多くのジュニア、あるいは中堅エンジニアすらも、「巻き上げ（Hoisting）」という言葉を単なる「コードが上部に移動する現象」というマジカルな比喩として片付けている。しかし、シニアエンジニアやランタイムの挙動に挑む者にとって、巻き上げとは「コンパイルフェーズにおけるスコープ環境レコード（Environment Records）への識別子のバインド順序の決定」に他ならない。
本稿では、ASTの構築プロセスとV8の内部挙動を紐解きながら、関数宣言と変数宣言が交錯する極限のスコープ解決メカニズムを暴く。さらに、この仕様の隙を突いた高度なスコープ汚染と、それをランタイムレベルで封殺するための防衛的アーキテクチャについて詳解する。
—
1. V8パーサーとAST：巻き上げの正体は「フェーズ分離」である
JavaScriptは動的言語でありながら、実行前に必ず解析フェーズ（Creation Phase）と実行フェーズ（Execution Phase）の2段階を踏む。V8エンジンは、ソースコードを一文字ずつ読み込み、トークンに分解した上で、文法規則に従ってASTを生成する。
このAST生成の段階で、パーサーはスコープ（グローバル、関数、ブロック）ごとに「何が宣言されているか」を静的にスキャンし、スコープの環境レコードに対して識別子を事前に登録する。これが「巻き上げ」の物理的な実体である。メモリ空間のポインタ確保は実行時ではなく、このパースの瞬間に完了しているのだ。
では、同じスコープ内で「同名の関数宣言」と「変数宣言」が競合した時、ASTとV8のパーサーはどのような優先順位でバインドを確定させるのだろうか。
—
2. 巻き上げの優先順位：AST解決アルゴリズムの深層
以下のコードスニペットを見てほしい。
// 検証用コード：同名識別子の競合
console.log(typeof foo); // “function” と出力されるか、”undefined” か？
var foo = 123;
function foo() {
return ‘I am a function’;
}
console.log(typeof foo); // 出力はどうなるか？
このコードを実行したとき、最初の `typeof foo` は `”function”` を返す。そして `var foo = 123;` を通過した後の2回目の `typeof foo` は `”number”` に変わる。
なぜ `var foo;` が先にあるにもかかわらず、関数宣言である `foo` が勝利するのか？ V8のパーサーがASTを構築し、スコープを初期化する際の厳密な優先順位ルールは以下の通りだ。
1. 関数引数（Parameters）: 最優先でスコープにバインドされる。
2. 関数宣言（Function Declarations）: 引数の次に評価され、既存の同名識別子を上書きして環境レコードに登録される。
3. 変数宣言（Variable Declarations – `var`）: 最後に処理される。もし既に同名の識別子（関数宣言や引数）がスコープ内に存在する場合、変数宣言は既存のバインドを無視（上書きせずスルー）する。
つまり、パース時において `var foo` は「すでに `foo` という関数宣言が存在する」とみなされ、宣言自体の実質的な効果が打ち消されるのだ（ただし、代入文 `foo = 123` は実行フェーズで通常通り評価されるため、後続のログで数値に書き換わる）。
ASTノードの視覚的理解
V8のパーサー内部では、`FunctionDeclaration` ノードは `VariableDeclaration` ノードよりも静的解析の初期段階で処理され、スコープの `Declarations` リストのより深い位置、あるいは特権的なスロットに割り当てられる。
これを擬似的なAST構造として表現すると、以下のようになる。
{
“type”: “Program”,
“body”: [
{
“type”: “FunctionDeclaration”,
“id”: { “type”: “Identifier”, “name”: “foo” },
“body”: { … }
},
{
“type”: “VariableDeclaration”,
“declarations”: [
{
“type”: “VariableDeclarator”,
“id”: { “type”: “Identifier”, “name”: “foo” },
“init”: { “type”: “Literal”, “value”: 123 }
}
],
“kind”: “var”
}
]
}
V8はこのツリーを走査する際、まず `FunctionDeclaration` を検知して `foo` を関数参照で初期化し、その後に `VariableDeclaration` に到達するが、既に同名バインドが存在するため、参照の初期化（`undefined` での上書き）をスキップする。これが、関数宣言が変数宣言に勝利するメカニズムの核心である。
—
3. `let` / `const` と一時的死滅ゾーン（TDZ）の厳密な挙動
ES6以降で導入された `let` および `const` は、`var` のような「巻き上げによる暗黙的な `undefined` 初期化」を行わない。これらはレキシカル環境（Lexical Environment）に登録されるものの、実際の宣言文が評価されるコード上の位置に到達するまで、アクセスが一切禁止される一時的死滅ゾーン（Temporal Dead Zone: TDZ）に置かれる。
{
// TDZの開始
// console.log(bar); // ReferenceError: Cannot access ‘bar’ before initialization
let bar = 456; // TDZの終了
console.log(bar); // 456
}
V8の内部実装において、`let` や `const` の識別子は「未初期化（Uninitialized）」という特別なメタ状態としてヒープ上にマークされる。この状態でアクセスを試みると、V8のランタイムチェックが作動し、即座に `ReferenceError` をスローする。
関数宣言と `let` の衝突
では、ブロックレベルの関数宣言と `let` が同じスコープで競合した場合はどうなるか。
let x = 10;
{
// ここでの x はどう扱われるか？
console.log(x); // エラーになるのか？
function x() {}
}
モジュールスコープや非厳格モード（Sloppy Mode）の挙動は歴史的経緯から複雑を極めるが、現代の ECMAScript 仕様（および strict モード）においては、ブロック内で `let x` と `function x()` が混在する場合、厳格な構文エラー（SyntaxError）として弾かれるか、スコープの分離が行われる。V8は混乱を防ぐため、ブロックスコープ内での同名宣言に対して非常に厳格なガードをかけている。
—
4. セキュリティとランタイムの罠：スコープ汚染からプロトタイプ汚染へ
変数の宣言とスコープ、そして巻き上げのメカニズムを理解することは、単なる言語仕様の把握にとどまらない。悪意ある攻撃者がどのようにJavaScriptのランタイムをハックするかを看破するための必須教養である。
サプライチェーン攻撃において頻発するプロトタイプ汚染（Prototype Pollution）や、関数スコープの隙をついた変数書き換えは、V8のメモリレイアウトとオブジェクトの「隠しクラス（Hidden Classes / Maps）」の仕組みを逆手に取る。
脆弱なコードパターンとASTの悪用
以下の動的コード評価（`eval` や `new Function`、あるいは不安全なオブジェクトのマージ処理）を考えてほしい。
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return {};
}
// 攻撃者が外部入力から原型を汚染
const payload = JSON.parse(‘{“__proto__”: {“polluted”: true}}’);
merge({}, payload);
// グローバル、あるいはすべてのオブジェクトに影響が波及
console.log({}.polluted); // true
この脆弱性は、オブジェクトのプロパティ代入を通じて `Object.prototype` を書き換えるものだが、スコープと巻き上げの文脈においてさらに深刻なのは、動的なスコープ汚染（Dynamic Scope Injection）である。古いコードベースやテンプレートエンジンなどで `with` ステートメントや悪意ある `eval` が使われている場合、巻き上げによって確保された変数スロットが外部からの入力によって予期せぬ上書きを受ける危険性がある。
V8は、オブジェクトのプロパティアクセスを高速化するために「隠しクラス（Map）」を動的に生成し、プロパティのオフセットを最適化する（インラインキャッシュ：Inline Caching）。しかし、プロトタイプ汚染が発生すると、この隠しクラスの構造が強制的に変更（Deoptimization：最適化解除）され、エンジン全体のスループットが急激に低下するだけでなく、予期せぬ型推論のバグを引き起こし、最終的にリモートコード実行（RCE）の踏み台とされる。
—
5. 防衛的プログラミング：ランタイムの防壁を構築する
この極限のレイяにおける脅威に対抗するため、シニアアーキテクトとして講じるべき実践的な防衛策を提示する。
1. 厳格モード（`use strict`）の強制とモジュール化
ES Modules（`type=”module”`）を使用するか、すべてのスクリプトの先頭に `’use strict’;` を明示せよ。これにより、Sloppy Mode特有の曖昧な巻き上げ挙動や、予期せぬグローバル変数の自動生成（Implied Globals）が完全に遮断され、V8はより厳格な静的解析と最適化を行えるようになる。
2. オブジェクトの凍結（Freezing）によるプロトタイプ汚染の無効化
外部からの信頼できないJSON入力をパース・マージする際は、プロトタイプチェーンの根底を保護する必要がある。
// プロトタイプ汚染を根本から防止するセキュアなマージ関数
function secureMerge(target, source) {
const dangerousKeys = [‘__proto__’, ‘constructor’, ‘prototype’];
for (let key of Object.keys(source)) {
if (dangerousKeys.includes(key)) {
// 危険なキーの注入を検知し、即座に拒否または無視
continue;
}
if (source[key] && typeof source[key] === ‘object’) {
if (!target[key]) target[key] = {};
secureMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 組み込みオブジェクトのプロトタイプを事前にフリーズしておく防衛策
Object.freeze(Object.prototype);
3. 変数宣言の規律（`var` の完全な排除と `const` 優先）
コードベースから `var` を完全に駆逐し、再代入が必要な場合のみ `let` を使い、基本はすべて `const` で宣言せよ。これにより、巻き上げによる意図しない `undefined` 参照や、同名識別子による上書きバグ（シャドーイングの事故）をASTパースの段階でコンパイラに検知させることが可能となる。
—
結びにかえて
JavaScriptの「巻き上げ」は、単なる初学者向けの面接問題ではない。それはV8エンジンがソースコードを解釈し、メモリ空間を割り当て、実行効率を極限まで高めるための静的解析のアルゴリズムそのものである。
ASTの構造、スコープの環境レコード、そしてV8の隠しクラスやインラインキャッシュの挙動までを見通す視点を持ったとき、君たちの書くコードは単なる「動くスクリプト」から、堅牢で予測可能、かつ圧倒的なパフォーマンスを誇る「エンジニアリングの芸術品」へと昇華するだろう。ランタイムの深淵を常に意識せよ。