関数宣言と変数宣言の巻き上げ：V8のAST生成フェーズにおける「優先順位の決定プロセス」とランタイムの真実
JavaScriptエンジニアであれば、誰もが一度は「巻き上げ（Hoisting）」という現象に直面する。そして少し踏み込んだ開発者であれば、同じ識別子に対して関数宣言と変数宣言（`var`）が競合した際、関数宣言が常に勝利するという仕様上の挙動を知っているはずだ。
だが、なぜそんなことが起きるのか？「インタプリタが上から順に読むから」といった表層的な理解で満足しているなら、今日でその認識を捨ててほしい。V8エンジンをはじめとするモダンJSランタイムの内部において、この「優先順位」は、字句解析（Lexical Analysis）から抽象構文木（AST: Abstract Syntax Tree）の生成、そしてスコープバインディングの構築フェーズに至るまでの厳密なアルゴリズムによって決定されている。
本稿では、ECMAScript仕様書（ECMA-262）のアルゴリズムと、V8ランタイム（Ignition / TurboFan）の内部実装の双方の観点から、名前の競合解決のメカニズムを極限まで解き明かす。
—
1. 宣言の正体：ランタイムにおける「巻き上げ」の幻影
まず大前提として、コードが物理的に上へ移動しているわけではない。V8がソースコードを評価する際、コード実行の前に「Creation Phase（生成フェーズ）」と「Execution Phase（実行フェーズ）」が存在する。
生成フェーズにおいて、エンジンのパーサ（Parser）はソースコードをスキャンし、スコープ（Global, Function, Block）内に出現するすべての変数・関数宣言を抽出し、Lexical Environment（レキシカル環境）またはVariable Environment（変数環境）のレコード（Environment Record）にエントリを事前に登録する。これが「巻き上げ」と呼ばれる現象の物理的な正体だ。
では、以下のコードを見てみよう。
// シナリオA: 同じ識別子に変数と関数を定義
var foo;
function foo() {
return ‘I am a function’;
}
console.log(typeof foo); // 出力結果は？
多くの者は、`var foo;` が後から上書きするのではないか、あるいはエラーになるのではないかと考える。しかし、出力は `’function’` となる。なぜ `var` で宣言された `foo` が、関数の存在をかき消せなかったのか。
—
2. AST生成フェーズとスコープ構築のアルゴリズム
ECMAScript仕様書の第14章（Executable Code and Execution Contexts）および第15章（ECMAScript Language: Source Code）を紐解くと、関数コードまたはグローバルコードの評価アルゴリズム（GlobalDeclarationInstantiation / FunctionDeclarationInstantiation）において、識別子のバインディング作成順序が厳密に規定されている。
V8のパーサがASTを構築し、スコープを設定する際、以下の順序でバインディング（識別子と値の結びつき）が処理される。
1. 関数の宣言（Function Declarations）のバインディング
- スコープ内で見つかったすべての関数宣言について、環境レコードに識別子を登録し、その関数オブジェクトへの参照を直ちに割り当てる。
2. 変数（Variable Declarations with `var`）のバインディング
- スコープ内で見つかったすべての `var` 宣言について識別子を登録する。
- ただし、すでに同名の関数バインディングがその環境に存在する場合、変数の宣言は無視（スキップ）される。
これが、「関数が常に勝利する」仕様の決定的な理由である。変数 `var foo;` は、既に生成フェーズで関数オブジェクトがバインディングされているスロットに対し、「お邪魔します」と宣言を試みるものの、ランタイムのアルゴリズムによってその存在を無視されるのだ。
隠された真実：代入式（Assignment）による上書き
ここで注意しなければならないのは、単なる「変数宣言（`var foo;`）」ではなく、「変数への代入（`foo = …`）」が含まれている場合である。代入は実行フェーズ（Execution Phase）で行われるため、コードの記述順序に依存する。
// シナリオB: 宣言ではなく「代入」が絡む場合
var foo = ‘I am a string value’;
function foo() {
return ‘I am a function’;
}
console.log(typeof foo); // 出力: ‘string’
この挙動をV8のランタイム視点で完全に脳内トレースしてみよう。
1. 生成フェーズ:
- 関数 `foo` が見つかり、スコープに `foo -> Function Object` がバインディングされる。
- 変数 `var foo` の宣言が見つかるが、同名のエントリが既に存在するため無視される。
2. 実行フェーズ（上から順に実行）:
- `foo = ‘I am a string value’;` が実行される。
- これにより、スコープ内の `foo` のバインディングが、関数オブジェクトから文字列 `’I am a string value’` への参照へと書き換えられる（Mutation）。
- 結果として、`console.log` の時点では `string` が出力される。
—
3. let / const の世界：Temporal Dead Zone (TDZ) との衝突
モダンなJavaScript（ES6以降）では、`var` ではなく `let` や `const` が主流である。では、`let` と関数宣言が競合した場合はどうなるのか。
let foo = ‘let value’;
function foo() {
return ‘function value’;
}
// SyntaxError: Identifier ‘foo’ has already been declared
見事に構文エラー（SyntaxError）が発生する。これはランタイムの実行時エラーではなく、AST生成フェーズ（パース段階）における静的チェックで弾かれている。
ECMAScriptの仕様では、同一の Lexical Environment 内において、LexicalDeclarations（`let`, `const`, `class`）と FunctionDeclarations の間で識別子の重複がある場合、SyntaxErrorを投げるよう明確に義務付けられている。`var` は歴史的経緯（後方互換性）から同一スコープ内での重複宣言が許容されていたが、`let`/`const` はバグの温床となる曖昧さを排除するため、厳格に禁止されているのだ。
—
4. セキュリティ・サプライチェーンの文脈：プロトタイプ汚染と関数・変数競合のハック
この「変数の巻き上げと関数の優先順位」という一見枯れた言語仕様は、実はフロントエンドのセキュリティ、特にプロトタイプ汚染（Prototype Pollution）やリモートコード実行（RCE）を伴う脆弱性分析において、極めて重要な意味を持つ。
攻撃者が悪意あるペイロードを仕込む際、グローバルスコープやライブラリ内部のスコープ汚染を試みる。ここで、開発者が意図しない変数名と関数名の競合が存在すると、V8のJITコンパイラが最適化の過程（Inline Cachingなど）で想定外の型推論を行い、型混同（Type Confusion）を引き起こすリスクが高まる。
特に、Node.jsのバックエンド環境やElectronアプリのメインプロセスにおいて、サードパーティ製ライブラリが古い `var` ベースのコードを使用しており、グローバル汚染によって同名の関数が上書きされた場合、予期せぬコードパスが実行される。
以下のコードは、スコープの巻き上げとプロトタイプ汚染が交差する危険なパターンの模倣である。
// 脆弱なモジュールのシミュレーション
function executeCommand() {
console.log(‘Safe execution path’);
}
function vulnerableModule() {
// 攻撃者がグローバルまたは親スコープを汚染し、
// 配列やオブジェクトのプロトタイプ経由で変数や関数を捻じ曲げるコンテキスト
if (typeof executeCommand === ‘function’) {
// V8の隠しクラス（Hidden Classes / Maps）がインラインキャッシュを構築中、
// 予期せぬプロパティの挿入によりIC（Inline Cache）がメガモーフィック（Megamorphic）に陥る
try {
executeCommand();
} catch (e) {
console.error(‘Exploit payload intercepted or execution failed:’, e.message);
}
}
}
// 意図しない変数の巻き上げと宣言の競合が、
// モジュール内のスコープ解決フェーズで型を狂わせる温床となる
var executeCommand = ‘malicious_string_payload’;
vulnerableModule();
// 実行結果: TypeError: executeCommand is not a function
この例では、`var executeCommand` が巻き上げられ、関数宣言よりも後置された代入によって文字列に化かされた結果、関数呼び出しが `TypeError` を引き起こしている。攻撃者は、このエラーハンドリングの隙をつくか、あるいはオブジェクトのプロトタイプチェーン上の `constructor` や `__proto__` を操作して、V8のメモリ空間内での関数ポインタの差し替えを狙う。
V8エンジンのヒープメモリ上において、識別子は単なる文字列ではなく、Hidden Class（Map）によってオフセットが管理されている。関数と変数が同じスロットを奪い合うとき、ランタイムの最適化エンジン（TurboFan）は最適化の前提条件（Stability）を失い、Deoptimization（最適化解除）を引き起こす。このパフォーマンスの急低下こそが、DoS攻撃のベクトルになり得ることも忘れてはならない。
—
5. チーフアーキテクトからの提言：コードベースを護るために
エンジニアリングにおいて、「動けばいい」というコードは技術的負債の増殖を意味する。関数宣言と変数宣言の巻き上げ挙動に依存したコードを書くことは、V8のパーサとスコープ解決アルゴリズムの気まぐれに運命を委ねるようなものだ。
以下の原則をチームのコーディング規約として徹底してほしい。
1. `var` の完全な排除:
現代のJavaScriptにおいて `var` を使う理由は1ミリもない。すべてを `const` で宣言し、再代入が必要な場合のみ `let` を使用する。これにより、TDZ（一時的死地）が強制され、巻き上げに起因するバグや予期せぬ競合をコンパイル段階（またはLint段階）で完全に根絶できる。
2. 関数表現（Function Expressions）の活用:
意図しない巻き上げを防ぐため、関数は名前付き、または無名の関数式として `const` に代入する形で定義する。
// 推奨される書き方
const safeFoo = function foo() {
return ‘Predictable and safe’;
};
3. スコープの最小化（IIFEやブロック文の活用）:
グローバル環境や巨大な関数スコープを汚染しないよう、ブロックスコープを活用し、V8のメモリ管理（Garbage Collection）と隠しクラスの最適化を阻害しない設計を貫くこと。
ランタイムの深層を理解した者だけが、真に堅牢で高速なアプリケーションを構築できる。JavaScriptは「おもちゃの言語」などではない。V8の鼓動を感じながら、そのメモリ空間とASTを支配する気概を持ってコードに向き合ってほしい。