V8エンジンの最適化を阻害する `var`：コンパイル時の静的解析とスコープ汚染のコスト
JavaScriptの歴史を紐解く時、`var` というキーワードは原罪であり、同時に言語の柔軟性を担保してきた諸刃の剣である。ECMAScript 2015 (ES6) において `let` と `const` が導入されて以来、モダンなコードベースから `var` は駆逐されるべきレガシーとして扱われてきた。
しかし、「なぜ `var` を使ってはいけないのか」という問いに対し、「巻き上げ（Hoisting）が起きるから」「ブロックスコープがないから」という教科書通りの回答だけで満足していないだろうか。
シニアエンジニアやランタイムの挙動にこだわるアーキテクトであれば、その問いをV8エンジンの内部構造、特に JITコンパイルの最適化パイプライン、Hidden Class（隠しクラス / Maps）の構造変化、そしてスコープチェーンのメモリレイアウト の観点から深く理解していなければならない。
本稿では、`var` がいかにしてV8エンジンの静接入力を狂わせ、最適化の壁となり、さらにはセキュリティリスクとしての側面をも併せ持つのかを、極限の低レイヤ視点から解き明かす。
—
1. V8コンパイルパイプラインとスコープの静的解析
V8エンジンがJavaScriptコードを実行する際、ソースコードはまずParserによって抽象構文木（AST）に変換され、その後 Ignition（インタプリタ）によってバイトコードにコンパイルされる。この初期段階において、変数が `var` で宣言されているか、あるいは `let` / `const` で宣言されているかは、コンパイラの最適化戦略を根本から分かつ決定的な分岐点となる。
スコープチェーンとコンパイル時スコープ決定（Scope Allocation）
`let` や `const` はブロックスコープ（Lexical Scoping）を持ち、TDZ（Temporal Dead Zone：一時的死ゾーン）という厳格な制約が存在する。これにより、V8のパーサーとスコープアナライザは、変数がどのブロック、どの関数スコープに属し、どこでライフサイクルが終了するのかをコンパイル時に完全に静的解析（Static Analysis）できる。
コンパイル時に変数の位置とスコープが完全に特定できると、V8は以下のメリットを享受できる。
1. レジスタ割り当ての最適化: 変数をヒープではなく、スタックフレームやCPUレジスタに直接割り当てることが可能になる。
2. Context Allocationの回避: クロージャーによってキャプチャされない限り、変数を保持するための余計なヒープオブジェクト（Contextオブジェクト）を生成する必要がなくなる。
一方で、`var` は関数スコープ（Function Scoped）を持ち、巻き上げ（Hoisting）によって変数の宣言がスコープの先頭に引き上げられる。さらに、`eval` や `with` ステートメント、あるいは予期せぬ巻き上げの挙動が存在すると、V8のスコープアナライザは「この変数のスコープをコンパイル時に確定させることは不可能である」と判断する。
これが何を意味するか。V8は安全策として、そのスコープ全体の変数を静的なレジスタやスタックではなく、動的なヒープ上のコンテキスト（Context Object）へと退避させざるを得なくなる。
// 【V8の内部挙動を狂わせる var の例】
function processTransaction(isVip) {
// var で宣言された変数は、関数スコープ全体のコンテキストに割り当てられる
var discountRate = 0.05;
if (isVip) {
// ブロック内であっても、var は関数スコープ全体に漏れ出す
var discountRate = 0.20;
console.log(“VIP割引適用: ” + discountRate);
}
// discountRate は静的レジスタに常駐できず、常にヒープ上のコンテキストからルックアップされる
return 1000 (1 – discountRate);
}
この動的なルックアップは、V8の実行時オーバーヘッドを確実に増大させる。数百万回実行されるホットパス（Hot Path）において、ヒープからのプロパティアクセスは、レジスタアクセスと比較して絶望的なまでのレイテンシの差を生む。
—
2. 隠しクラス（Hidden Classes / Maps）とインラインキャッシュ（IC）の破壊
V8が動的言語であるJavaScriptを高速に実行できる最大の理由は、Hidden Class（V8内部では `Map` と呼ばれる） と Inline Caches (IC) の存在にある。
オブジェクトのプロパティアクセスを行う際、V8はオブジェクトの形状（どのプロパティがどのオフセットに存在するのか）を追跡するマップを付与する。これにより、C++やJavaのような静的言語の構造体アクセスと同等の速度を実現している。
しかし、`var` が引き起こすスコープ汚染や、巻き上げられた変数に対する動的な代入・再宣言は、この隠しクラスの安定性を破壊する。
最適化を阻害するメカニズム
以下のコードを見てほしい。
// モジュールやグローバルスコープでの var の挙動
var config = { env: ‘production’ };
function updateConfig() {
// var はグローバルスコープ（ブラウザなら window、Node.jsなら global）のプロパティとしてアタッチされる
var config = { env: ‘development’, debug: true };
return config;
}
トップレベル（グローバルスコープ）における `var` の宣言は、グローバルオブジェクトのプロパティの作成・上書きを引き起こす。グローバルオブジェクトはアプリケーションのライフサイクル全体を通じて常に拡張・変形され続けるため、V8はグローバルオブジェクトに対する隠しクラスの最適化を諦め、ディクショナリモード（Dictionary Mode / ハッシュテーブルベースのストレージ）へと格下げする。
ディクショナリモードになったオブジェクトに対するプロパティアクセスは、O(1)の高速なオフセット参照ではなく、ハッシュのキー探索（O(N)またはそれに近いコスト）を伴うため、インラインキャッシュ（IC）が完全にミス（Megamorphic IC）する。
Turbofan（V8の最適化コンパイラ）は、このような不確定要素が多いコードに対しては最適化（Optimized Code生成）を見送り、メガモーフィックなコードとしてインタプリタに近い状態で実行し続けることになる。
—
3. イベントループとメモリ管理（Garbage Collection）におけるコスト
`var` のもう一つの見過ごせないコストは、そのスコープの広さ（Function Scoped）に起因する ガベージコレクション（GC）への悪影響 である。
現代のV8ガベージコレクタ（Orinoco）は、世代別GC（Generational GC）や並行マーキング（Concurrent Marking）を駆使して高速にメモリを回収する。しかし、変数の生存期間（Lifetime）が意図せず長くなることは、GCの負荷をダイレクトに引き上げる。
スコープ汚染とメモリリークの温床
`let` や `const` であれば、ループやブロックスコープの終了と共に変数はスコープ外になり、参照が絶たれればすみやかにスイープの対象となる。しかし、`var` は関数スコープ全体にわたって生存し続けるため、不要になった巨大なオブジェクトや配列が、その関数がリターンするまでの間、メモリ空間（Young Generation / Old Generation）に居座り続ける。
function heavyDataProcessing(items) {
for (var i = 0; i < items.length; i++) {
var massivePayload = computeExpensiveData(items[i]);
// 何らかの処理...
}
// 警告: 変数 i および massivePayload は、この関数のスコープ終端まで
// ヒープ上のコンテキストに保持され続け、GCの即時回収を阻害する
return i;
}
この「意図しない生存期間の長期化」は、マイクロタスクキューや非同期処理のコンテキストと組み合わさった時、深刻なメモリリーク（Memory Leak）を引き起こす引き金となる。
---
4. セキュリティレイヤの崩壊：プロトタイプ汚染と `var` の闇
ランタイムの最適化だけでなく、セキュリティの観点からも `var` は悪名高い。特にサプライチェーン攻撃や、悪意あるペイロードによるリモートコード実行（RCE）を誘発する プロトタイプ汚染（Prototype Pollution） の文脈において、レガシーなスコープ仕様は脆弱性の温床となる。
グローバルスコープとプロトタイプ汚染の連鎖
JavaScriptの脆弱性において、意図しないプロトタイプへのプロパティ追加がアプリケーション全体に波及する問題は後を絶たない。
// 脆弱なマージ関数の例（サプライチェーンを狙う攻撃の模倣）
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 target;
}
// 攻撃者が ‘__proto__’ を経由してグローバル/親スコープを汚染する試み
// var が使われているコードベースでは、グローバル変数の意図しない上書きや
// スコープチェーンの突き抜けが発生しやすい
`var` を多用した古いコードベースや、`with` ステートメントが混在するコードでは、変数のルックアップがスコープチェーンを遡る際に見知らぬプロトタイプ上のプロパティを拾ってしまう「スコープハイジャック」のリスクが高まる。静的解析ツール（ESLint等）で `no-var` や `no-redeclare` を厳格に強制することは、パフォーマンス向上だけでなく、ランタイムの防壁を維持するためのセキュリティ要件なのだ。
—
5. 結論：モダンJSエンジニアが取るべきアプローチ
V8エンジンは進化を続け、JITコンパイラ（Turbofan）や新しいベースラインコンパイラ（Maglev）は、人間には予測困難なレベルでコードを最適化しようとする。しかし、そのV8の足かせとなるのが、言語仕様の歴史的負債である `var` である。
1. `var` を完全に排除し、`const` をデフォルト、再代入が必要な場合のみ `let` を使用する。
- これにより、コンパイラは変数の生存期間とスコープを完全に静的解析でき、レジスタ割り当てやインラインキャッシュの最適化恩恵を最大限に引き出せる。
2. ブロックスコープを活用し、GCの効率を最大化する。
- 変数のスコープを最小限に絞ることで、メモリのライフサイクルを短縮し、GCのポーズタイムを最小化する。
3. 静的解析の徹底。
- TypeScriptやESLintを通じ、ランタイムの最適化を阻害するコードパターンをビルドパイプラインの段階でシャットアウトする。
「動くからいいや」という妥協の積み重ねが、V8エンジンのポテンシャルを削ぎ落とし、クラウドのインフラストラクチャコストを無駄に増大させ、セキュリティの脆弱性を生む。チーフアーキテクトとして、私たちはコードの1行がコンパイラとハードウェアに与える影響を常に想像し続けなければならない。