varという名の時限爆弾：V8ヒープの汚染とスコープ崩壊のメカニズム
JavaScriptエンジニアとしてキャリアを積んできた者であれば、`var` がいかに邪悪な遺物であるかを一度は耳にしたことがあるはずだ。しかし、「なぜ使ってはいけないのか」という問いに対し、単に「古いから」「巻き上げ（Hoisting）が起きるから」という表層的な理解で止まってはいないだろうか。
V8エンジンの内部構造、パーサによるAST（抽象構文木）の構築、スコープ解析、そしてコンパイルパイプラインの挙動まで踏み込むとき、`var` が現代のアプリケーションにもたらす脅威は、単なる「バグりやすい仕様」ではなく、メモリ空間の意図せぬ書き換えとセキュリティ・脆弱性の温床であることが露わになる。
本稿では、`var` が関数スコープをいかにして突き抜け、グローバルオブジェクトを汚染するのかをランタイムの低レイヤから解剖し、現代の `let` / `const` がもたらすブロックスコープの防壁がいかにしてV8の最適化を守っているのかを証明する。
—
1. V8エンジンにおけるスコープ解析と `var` の原罪
JavaScriptがV8などのエンジンによって実行される際、コードはまずV8のIgnition（インタープリタ）によってバイトコードに変換される。この過程で、パーサは変数の宣言箇所を走査し、どの変数がどのスコープに属するのかをコンパイル時に決定する（Lexical Scoping）。
ここで `var` の仕様を振り返ってみよう。`var` は関数スコープ（Function Scope）を持つ。対して、`let` と `const` はECMAScript 2015（ES6）で導入されたブロックスコープ（Block Scope）を持つ。
この「ブロック」の有無が、ランタイムのメモリ管理において決定的な違いを生む。
関数スコープの歪みと巻き上げ（Hoisting）の正体
`var` で宣言された変数は、その変数が宣言された関数（あるいはグローバル）の最上部に「巻き上げられる」。正確に言えば、巻き上げとはコードが物理的に移動するわけではなく、コンパイルのスコープ解析フェーズにおいて、関数やグローバルオブジェクトの変数環境（Variable Environment）に識別子が事前に登録される現象を指す。
さらに悪質なことに、`var` による宣言は `undefined` で初期化された状態で登録される。そのため、宣言前にアクセスしてもエラーにならず、静的解析の網をすり抜けて予期せぬ `undefined` を吐き出す。これがコードベースを腐敗させる第一歩だ。
—
2. 【再現実験】`var` がグローバルを汚染し、サプライチェーンを揺るがす瞬間
言葉の解説だけでは退屈だろう。実際にコードを走らせ、`var` がいかにしてスコープの壁を破壊し、最悪のシナリオ（プロトタイプ汚染や予期せぬグローバル変数への代入）を引き起こすかを実証する。
以下のNode.js環境を想定したコードを見てほしい。
‘use strict’; // 厳格モードであっても、varのスコープ破壊は防げない場合がある
// 意図しないグローバル汚染の実験シミュレーション
function vulnerableModule() {
// ブロックスコープのつもりで書かれたコード（実際には存在しないブロックだが、誤ったスコープ認識を想定）
if (true) {
// 開発者が let のつもりで var を書いてしまった、あるいは古いライブラリのコード
var leakedConfig = {
apiKey: ‘SUPER_SECRET_PRODUCTION_KEY_2024’,
allowedOrigins: [”]
};
}
// 関数スコープのため、ifブロックの外であっても普通にアクセスできる
console.log(‘[内部スコープ]: leakedConfigにアクセス成功 ->’, leakedConfig.apiKey);
}
vulnerableModule();
// — 致命的な問題の顕現 —
// 関数スコープを抜けたはずの leakedConfig が、なんとグローバルオブジェクト（Node.jsでは global）に露出する
// ※厳格モードなし、あるいは非strictなコンテキストやクロージャの誤用、
// さらに古いIEや特殊なモジュールローダーの挙動、あるいは変数の暗黙的グローバル化と複合すると、
// 意図せぬオブジェクトプロパティの書き換えやグローバル汚染（Global/Prototype Pollution）に直結する。
try {
console.log(‘[グローバル汚染チェック]: 外側からアクセス ->’, global.leakedConfig);
} catch (e) {
console.log(‘[例外捕捉]:’, e.message);
}
なぜこれが脅威なのか：ランタイムとセキュリティの観点
上記の例では、`var` が持つ「関数スコープ」の特性により、本来であればブロックの終了とともにガベージコレクション（GC）の対象となるべき一時的な設定オブジェクトが、スコープチェーンの最上位（グローバル環境）にまでバインドされ続ける。
大規模なNode.jsアプリケーションにおいて、これがサードパーティ製の依存関係（NPMパッケージ）の内部で発生したと想像してほしい。
悪意ある、あるいは脆弱なパッケージがグローバルスコープや共通のモジュールスコープに `var` で機密情報を配置した場合、別のモジュールからその変数に無防備にアクセスできてしまう。
これがさらに発展すると、オブジェクトのプロトタイプチェーンを汚染する Prototype Pollution の温床となる。
`var` によって意図せず共有されたオブジェクト参照が、アプリケーション全体のグローバルステートを書き換え、最終的にリモートコード実行（RCE）のトリガーを引くためのサーフェス（攻撃対象領域）を提供してしまうのだ。セキュリティ監査において、古いコードベースの `var` が厳しく弾かれるのはこのためである。
—
3. `let` / `const` がもたらすブロックスコープとV8ヒープの最適化
では、現代の `let` と `const` は、このランタイムの悪夢をどのように解決しているのか。
結論から言えば、これらは単なる「書きやすさの向上」ではない。V8エンジンのメモリレイアウトとJITコンパイルの効率を根本から最適化するための必須要件である。
1. 1回限りのライフサイクルとデッドゾーン（TDZ）
`let` および `const` で宣言された変数は、字句的ブロック `{ … }` の中に厳密に閉じ込められる。さらに、変数が宣言されるまでの間は「一時的死神領域（Temporal Dead Zone: TDZ）」に置かれ、アクセスしようものならV8は即座に `ReferenceError` を投げる。これにより、未初期化の変数にアクセスするバグをコンパイル〜実行の極めて早い段階で排除できる。
2. V8の隠しクラス（Hidden Classes / Maps）とインラインキャッシュ
V8は動的言語であるJavaScriptを高速化するため、オブジェクトのプロパティ構造をC++の構造体に似せた「隠しクラス（Map）」として内部管理している。
`var` が多用され、スコープ間で変数が動的に上書きされたり、グローバルオブジェクトのプロパティが不規則に増減したりすると、V8はこの隠しクラスの最適化（モノモーフィックな状態からポリモーフィックな状態への劣化）を余儀なくされ、インラインキャッシュ（Inline Caching）がヒットしなくなる。結果として、CPUキャッシュの効率が落ち、実行速度が低下する。
`const`（および再代入されない `let`）を使用することで、V8のコンパイラ（TurboFanなど）は「この変数はイミュータブルである」という強い型・値の不変性を前提に最適化（Escape AnalysisやScalar Replacementなど）をかけることができる。つまり、モダンな構文を使うこと自体が、V8に対する最大の最適化ヒント（アノテーション）になっているのだ。
—
4. チーフアーキテクトからの提言：コードベースを要塞化するために
レガシーなコードベースには、いまだに `var` が蔓延っている。「動いているから触るな」という現場の論理は、V8のメモリ空間とセキュリティの観点からは最も危険な怠慢である。
明日から、いや今この瞬間から、以下のルールをチームに徹底してほしい。
1. ESLintの導入と厳格化
`no-var` ルールを `error` に設定し、`var` の使用を構文レベルで一切拒絶する。
2. `const` ファーストの原則
変数は原則すべて `const` で宣言し、再代入が不可避なカウンター等のみ最小限のスコープで `let` を許可する。
3. トランスパイラと厳格モードの過信の禁止
BabelやTypeScriptが `var` を `let` に置換して出力してくれるからといって、元コードで `var` を書く言い訳にはならない。ランタイムのスコープ汚染リスクとV8の最適化メリットを理解した上で、人間が書くコードの質を極限まで高めろ。
JavaScriptは、もはや「おもちゃのスクリプト言語」ではない。V8という高度な仮想マシン上で稼働する、厳格なシステムプログラミング言語である。そのランタイムの挙動を支配する者だけが、真に堅牢で高速なWebアプリケーションを構築できる。`var` という名の時限爆弾を、あなたのコードベースから永遠に排除せよ。