ASTから読み解く巻き上げの優先順位：関数宣言と変数宣言が衝突した時のランタイム真実
JavaScriptエンジンがソースコードを受け取ってから、最初の機械語（またはバイトコード）を吐き出すまでの間に何が起きているか。多くの開発者は「巻き上げ（Hoisting）」という言葉を、初学者向けのふんわりとした概念として理解している。`var`や`function`がスコープの先頭に引き上げられる、と。
しかし、シニアエンジニアやランタイムの挙動に挑むセキュリティリサーチャーにとって、この「巻き上げ」は単なる言語仕様の解説ではなく、V8のParserとIgnition（バイトコードジェネレータ）が構築するAST（抽象構文木）のスコープ解決フェーズにおける厳密なアルゴリズムの帰結に他ならない。
今回は、関数宣言と変数宣言が同一識別子で衝突した際、ASTとスコープの位相空間において何が優先され、それがV8のメモリ空間やJITコンパイルにどう影響するのかを、極限の低レイヤ視点から解剖する。
—
1. 巻き上げの正体：ランタイムにおけるスコープ変数の物理的実体
JavaScriptの実行コンテキスト（Execution Context）が生成される時、V8はコードを実行する前に「Creation Phase（生成フェーズ）」を設ける。ここで発生するのが、LexicalEnvironmentとVariableEnvironmentの構築だ。
変数の巻き上げとは、メモリ上の物理アドレスが実際に移動するわけではない。パーサーがコード全体を走査し、識別子（Identifier）をスコープのシンボルテーブル（VariableMap）にあらかじめ登録するプロセスそのものを指す。
ここで重要なのは、宣言の種別（`function`、`var`、`let`、`const`）によって、シンボルテーブルへの登録順序と初期化のフェーズが完全に分断されているという点だ。
// このコードをV8はどう解釈しているか？
console.log(typeof foo); // “function” なのか “undefined” なのか？
var foo = 123;
function foo() {
return 456;
}
console.log(typeof foo); // “number” (123)
このコードの挙動を正確に予測できるか？ 答えは最初の`console.log`が `”function”` を返し、2番目が `”number”` を返す。なぜ`var foo = 123;`が上にあるにもかかわらず、関数宣言が勝利するのか。これをASTの構造から紐解く。
—
2. AST構造とパーサーの解析アルゴリズム：関数vs変数の衝突ルール
V8のパーサー（parser.cc）は、ソースコードをトークン化し、ASTを構築する際、スコープ（Scope）オブジェクトに対して変数をバインドしていく。
1. 関数宣言（Function Declaration）の巻き上げ
パーサーが `function foo() {}` を検知すると、スコープの変数マップに識別子 `foo` を登録し、その値（ポインタ）に即座に関数オブジェクトへの参照を割り当てる。つまり、生成フェーズの時点で「名前＋実体」が完全に結びつけられる。
2. 変数宣言（`var`）の巻き上げ
パーサーが `var foo` を検知すると、シンボルテーブルに `foo` を登録する。しかし、初期化値は `undefined` であり、もし既に同名の識別子がスコープ内に存在する場合（特にそれが関数宣言であれば）、既存のエントリ（関数オブジェクトへの参照）を上書きせず、無視（あるいは既存のバインディングを維持）する。
ASTノードの優先順位の数学的（論理的）順序
パーサーの内部処理を抽象化すると、以下の優先順位でスコープのバインディングが確定する。
1. Formal Parameters（仮引数）
2. Function Declarations（関数宣言） ── ここで最強の優先度を持つ
3. Variable Declarations (`var`) ── 既存の同名バインディングがあれば上書きされない
4. Lexical Declarations (`let` / `const`) ── Temporal Dead Zone (TDZ) の対象
先ほどのコードのASTレベルでの挙動をシミュレートするコードを見てみよう。
// ランタイムが裏側で行っている巻き上げと衝突解決のシミュレーション
function 内部実行コンテキスト生成() {
// 1. 関数宣言が最初にスコープを占有し、実体をバインド
var foo = function foo() {
return 456;
};
// 2. var foo の宣言は、既に ‘foo’ が存在するため無視される（再宣言の排除）
// 3. ただし、代入式 (foo = 123) は実行フェーズ（Execution Phase）で評価される
console.log(typeof foo); // “function”
// 実行フェーズにおける代入
foo = 123;
console.log(typeof foo); // “number”
}
この仕様の隙を突くことで、コードの意図しない書き換えや、古いES5時代のコードベースにおける奇妙なバグ、さらには高度な難読化コードの解析を困難にするトリックが生まれる。
—
3. V8の最適化パイプラインへの影響：インラインキャッシュ（IC）の汚染リスク
このような変数名と関数名の衝突、あるいは同一スコープ内での過剰な再宣言は、V8のJITコンパイラ（Maglev / TurboFan）による最適化に悪影響を及ぼす。
V8は、変数の型がスコープ内で安定している（Monomorphic）と仮定して機械語を生成する。しかし、次のようなコードを書いた場合：
var data = function() { return { x: 1 }; };
function data() {
return { x: 2 };
}
// 実行フェーズで後から書き換えられる
data = “string_payload”;
このパターンは、VariableEnvironment内の識別子 `data` が指すヒープ上のオブジェクトの型を、`Function` から `String` へと劇的に変化させる（Megamorphicな状態への転落）。
V8の隠しクラス（Hidden Class / Map）やインラインキャッシュ（Inline Cache）は、このような頻繁な型変動に対して「Deoptimization（最適化解除）」を引き起こす。結果として、CPUのパイプライン効率が低下し、ガベージコレクタ（GC）への負荷が増大する。
チーフアーキテクトとして断言するが、「巻き上げの挙動をハックしてコードを短くする」ようなテクニックは、モダンなV8ランタイムの最適化恩恵を自ら捨てる行為に等しい。コードは常に予測可能で、単一の識別子が一つの意味と型を維持するよう設計すべきだ。
—
4. セキュリティ・サプライチェーンの脅威：プロトタイプ汚染とスコープの罠
変数宣言と巻き上げ、そしてスコープの挙動を深く理解することは、フロントエンドのパフォーマンスチューニングだけでなく、Node.jsバックエンドやElectron環境におけるセキュリティ脆弱性（RCE等）の防御に直結する。
近年のサプライチェーン攻撃では、依存ライブラリ（NPMパッケージ）の脆弱性を突いた「プロトタイプ汚染（Prototype Pollution）」が猛威を振るっている。
// 危険な再帰的マージ関数（簡易版）の例
function deepMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
deepMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 攻撃者が外部入力経由で以下のようなペイロードを送り込むと…
const maliciousPayload = JSON.parse(‘{“__proto__”: {“rce_payload”: “require(\’child_process\’).execSync(\’id\’);”}}’);
let config = {};
deepMerge(config, maliciousPayload);
// この瞬間、Object.prototype に汚染されたプロパティが付与される
// もしアプリケーション側が、グローバルスコープや不安全なeval/Functionコンストラクタと組み合わせて動的評価を行うと…
ランタイムの防壁を突破・防御する極限の知見
関数宣言の巻き上げやグローバルスコープの汚染、そして `var` による予期せぬ巻き上げの衝突は、攻撃者が「意図しない変数の上書きやプロパティの乗っ取り」を行う際の土壌となる。
サプライチェーンを防御するための決定的な対策は以下の通りである。
1. `var` の完全な廃止と `strict mode` (`”use strict”;`) の強制
`let` と `const` を使用することで、Temporal Dead Zone (TDZ) が強制され、巻き上げによる意図しない暗黙の初期化や関数・変数間の衝突を構文レベルでエラーとして弾くことができる。
2. オブジェクトの凍結（Object.freeze）によるプロトタイプ汚染の無効化
アプリケーション起動時、あるいはグローバルオブジェクトに対して `Object.freeze(Object.prototype)` を適用し、プロトタイプチェーンへの不正なプロパティインジェクションを物理的に不変（Immutable）にする。
3. ASTトランスフォーマー（Babel / SWC）による静的解析の厳格化
ビルドパイプラインの段階でASTを走査し、危険なパターン（同名変数の重複宣言や、不安全なスコープ共有）をリントエラーとして検知・排除するカスタムプラグインを導入する。
—
結びにかえて
JavaScriptの「巻き上げ」という現象は、単なる仕様のトリビアではない。それはブラウザやNode.jsが起動し、V8エンジンがソースコードを解釈してメモリ空間を構築するその瞬間に、ASTとスコープが繰り広げる厳格な秩序そのものである。
関数宣言が変数宣言を圧倒する優先順位の裏には、言語の歴史的背景と、パーサーの緻密な設計がある。そのメカニズムをコードの表層だけでなく、V8のランタイムとセキュリティの文脈まで見通して理解した時、あなたの書くコードは、単に動くものから「堅牢で最適化された芸術品」へと昇華するはずだ。