序：なぜ `var` はV8ランタイムとアーキテクチャの癌なのか
モダンなJavaScript開発において、ESLintなどの静的解析ツールが `var` の使用に対して容赦なくエラーや警告を発することは、もはや開発インフラストラクチャの常識である。しかし、多くのジュニアからミドルクラスのエンジニアは、これを単なる「ES6のモダンな書き方への移行」や「スタイルの統一」程度に捉えている。
それは致命的な認識不足だ。
V8をはじめとするモダンなJavaScriptエンジン（JavaScriptCore、SpiderMonkeyなど）の内部実装、そしてブラウザのレンダリングパイプラインやNode.jsのイベントループの挙動を深く理解する者にとって、`var` の存在は、メモリ安全性、スコープ解決の決定論（Determinism）、そしてセキュリティアーキテクチャにおける深刻な脅威ベクトルそのものである。
本稿では、`var` が生み出すグローバルスコープの汚染が、なぜ静的解析ツールによって厳しく弾かれなければならないのか。V8のJITコンパイル、隠しクラス（Hidden Classes / Shapes）の物理的崩壊、プロトタイプチェーンのハック、そしてサプライチェーン経由のリモートコード実行（RCE）に至るまでのメカニズムを、低レイヤの視点から完全に解剖する。
—
1. スコープチェーンの探索コストとV8インラインキャッシュの破綻
関数スコープ vs ブロックレベルスコープ
`var` は関数スコープ（Function-scoped）を持つ。これに対し、`let` と `const` はブロックスコープ（Block-scoped）を提供する。この仕様の差は、単に「変数の生存期間が異なる」という抽象的な話ではない。V8エンジンがメモリ上のデータをどのように配置し、最適化（Optimization）を施すかの根幹に関わる。
// 【危険なアンチパターン】 varによるスコープの漏洩と巻き上げ（Hoisting）
function processTransactions(transactions) {
for (var i = 0; i < transactions.length; i++) {
var tx = transactions[i];
// 非同期処理をシミュレート
setTimeout(() => {
console.log(`Processing ID: ${tx.id}, Value: ${tx.value}`);
}, 1000);
}
// ループを抜けた後も ‘i’ と ‘tx’ は関数スコープ全体で生存し続ける
console.log(`Loop finished. Final index: ${i}`);
}
上記のコードにおいて、`i` や `tx` はループブロック内にとどまらず、`processTransactions` 関数の変数オブジェクト（Variable Object）にバインドされる。
V8はコードを実行する際、Ignition（バイトコードインタプリタ）からTurboFan（最適化コンパイラ）へとパイプラインを進める。ブロックスコープであれば、変数の生存期間（Live Range）が限定されるため、JITコンパイラはレジスタ割り当て（Register Allocation）を効率的に行い、不要になったメモリ領域を迅速にガベージコレクション（GC）の対象としてマークできる。
しかし、`var` によって変数が関数スコープ全体へ「巻き上げ（Hoisting）」られると、変数のライブレンジが不当に広がり、V8のヒープメモリ空間（Heap Memory Space）における最適化の余地が狭まる。
スコープチェーンの深さとプロパティアクセス
さらに最悪なのは、`var` をグローバルコンテキスト、あるいは意図しない上位スコープで多用した場合である。
JavaScriptエンジンは、変数が参照された際に見つかるまで「スコープチェーン（Scope Chain）」を上方へ辿る。
[Current Execution Context]
↓ (見つからない)
[Outer Function Context]
↓ (見つからない)
[Global Execution Context (window / global)]
この探索コストは、O(N)（Nはネストの深さ）のオーバーヘッドを生む。さらに、グローバルスコープに `var` で変数を宣言すると、それはグローバルオブジェクト（ブラウザなら `window`、Node.jsなら `global`）のプロパティとして直接アタッチされる。
V8は、オブジェクトのプロパティアクセスを高速化するために「隠しクラス（Hidden Class / Map）」と「インラインキャッシュ（Inline Caching: IC）」という強力な仕組みを持っている。しかし、グローバルオブジェクトのプロパティは、実行時を通じていつでも誰からでも書き換えられる（ExtensibleかつConfigurable）ため、V8はグローバルオブジェクトへのアクセスに対して強力な最適化（Monomorphic ICなど）を適用できず、メガモーフィック（Megamorphic）な遅延したプロパティルックアップへとフォールバックせざるを得なくなる。
—
2. グローバルスコープ汚染と名前衝突の構造的リスク
大規模なWebアプリケーションや、数千のモジュールが依存し合うNode.jsのバックエンドシステムにおいて、`var` によるグローバル汚染は、システム全体の決定論を破壊する時限爆弾となる。
// モジュールA (legacy-module.js)
var CONFIG = { timeout: 5000, debug: true };
// モジュールB (modern-app.js)
// 開発者が意図せず、あるいは古いライブラリの読み込み順序のせいで同名の変数を使用
var CONFIG = { timeout: 1000, debug: false };
function connectDatabase() {
// 意図しないモジュールAのCONFIGが参照される、あるいはその逆が発生
setTimeout(() => {
console.log(`Connecting with timeout: ${CONFIG.timeout}`);
}, CONFIG.timeout);
}
ES Modules（ESM）やCommonJSといったモジュールシステムが普及した現代においても、古いサードパーティスクリプトの直接読み込みや、ビルド設定のミスによってグローバルスコープが共有される環境は依然として存在する。
`var` は、同一の変数名での再宣言（Redeclaration）をエラーなく許容するという、現代の言語設計においては狂気とも言える仕様を持っている。
var appStatus = “initializing”;
// 何千行も離れたコード、あるいは別のスクリプトタグ内
var appStatus = “running”; // エラーにならない！ 既存の値が上書きされる
一方、`let` や `const` は、同一スコープ内での重複宣言に対して `SyntaxError` をスローする。静的解析ツール（ESLintの `no-redeclare` や `no-var`）は、この言語仕様の欠陥をコンパイル前（あるいはCI/CDパイプラインのビルド前）に検知し、名前衝突によるサイレントバグを物理的に阻止するための防壁なのだ。
—
3. サプライチェーンを突く：プロトタイプ汚染からRCE（リモートコード実行）への昇格
ここからが本題であり、セキュリティ研究者およびシニアアーキテクトが最も恐れる領域である。
グローバルスコープの汚染や、不適切な変数管理、そして古いJavaScriptの動的なオブジェクト操作（例：不完全な再帰的マージ関数）は、プロトタイプ汚染（Prototype Pollution）という極めて危険な脆弱性の温床となる。
// 【脆弱性の実例】 危険なディープマージ関数
function maliciousMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
maliciousMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 攻撃者がJSONペイロードを送り込む
const payload = JSON.parse(‘{“__proto__”: {“polluted”: “RCE_TRIGGERED”}}’);
let globalConfig = { env: “production” };
maliciousMerge(globalConfig, payload);
// Object.prototypeが汚染されているかを検証
console.log({}.polluted); // ➔ “RCE_TRIGGERED” が出力されてしまう！
なぜこれがRCEにつながるのか？
`var` や不適切なグローバル管理、そしてオブジェクトの動的拡張によって `Object.prototype` が汚染されると、アプリケーション内のすべてのオブジェクトがその汚染されたプロパティを継承するようになる。
Node.jsのバックエンド環境において、これがどのようにリモートコード実行（RCE）に直結するかを考えてみよう。
例えば、Webフレームワークやテンプレートエンジン、あるいはデータベースのクエリビルダーが、内部で設定オブジェクトをバリデーションやマージする際、次のようなコードが存在すると仮定する。
// 脆弱な内部処理の例
function executeQuery(options) {
// optionsオブジェクトに安全性を期待しているが、Object.prototypeが汚染されている
const queryOptions = Object.assign({ timeout: 1000, logger: defaultLogger }, options);
if (queryOptions.customExecutor) {
// もし `customExecutor` プロパティがプロトタイプチェーン経由で注入されていたら…
return queryOptions.customExecutor();
}
// 通常の処理…
}
攻撃者が `Object.prototype` を介して悪意のある関数を `customExecutor` や、内部で評価されるテンプレートのプロパティとして注入することに成功した場合、V8ランタイムはその汚染されたプロパティを「正当なオブジェクトのメンバ」として信頼し、実行してしまう。
結果として、任意のJavaScriptコード、さらにはNode.jsの `child_process` モジュールなどを悪用したOSコマンドの実行（RCE）へと昇格する。サプライチェーン攻撃において、依存ライブラリの古いコード（`var` の乱用や不安全なオブジェクト操作を含む）が狙われるのは、まさにこのランタイムの根幹を揺るがす脆弱性連鎖を引き起こすからである。
—
4. イベントループのコンテキスト破壊とメモリリーク
最後に、非同期処理とイベントループ（Event Loop）における `var` の悪影響について触れておこう。
Node.jsやブラウザのイベントループは、マクロタスク（setTimeout, I/Oなど）とマイクロタスク（Promise, queueMicrotaskなど）のキューを厳密に処理していく。
// 【メモリリークと非同期バグの温床】
function setupAsyncTasks() {
var heavyData = new Array(10000000).fill(0); // 巨大な配列（約80MB）
setTimeout(function() {
// 非同期コールバックが実行されるまでの間、
// varで宣言された heavyData はスコープチェーン上に保持され続ける
console.log(“Task executed. Data length:”, heavyData.length);
}, 5000);
// 本当はここでheavyDataを解放したい、あるいは別スコープで処理を完結させたいが、
// varの広いスコープと巻き上げにより、ガベージコレクションが効かない
}
`let` や `const` を使用したブロックスコープであれば、そのブロックの実行が完了し、非同期のクロージャが参照していない（あるいはレキシカル環境が破棄可能な）状態になれば、V8のガベージコレクタ（Orinocoコンテナ等）は速やかにメモリを回収する。
しかし、`var` によって意図せず保持された変数は、予期せぬメモリリーク（Memory Leak）を引き起こし、高負荷時にV8ヒープの制限（デフォルトでは64bit環境でも数十GB、しかし制限やGCの頻度増加によるパフォーマンス低下を招く）を圧迫し、アプリケーションの停止（Out of Memory: OOM Crash）を誘発する。
—
結：静的解析の警告は「ランタイムの防壁」である
ESLintが `var` を検知したとき、それは単なる「古い構文の矯正」を求めているのではない。
1. V8のJIT最適化と隠しクラスの崩壊を防ぐ
2. 不必要なスコープの肥大化によるメモリリークとGCの効率低下を防ぐ
3. グローバル汚染による名前衝突と、それに続くプロトタイプ汚染・RCEの脅威ベクトルを断ち切る
これらすべての低レイヤの理不尽とリスクを未然に防ぐための、極めて合理的で技術的な防壁が静的解析ツールなのである。
シニアエンジニアたるもの、コードを書く際には常に「この1行の変数が、V8のヒープメモリ上でどのようなバイトコードに変換され、どのようにガベージコレクションされ、どの程度のセキュリティリスクを孕むか」を脳内でトレースできなければならない。
`var` を過去の遺物として完全に排除し、`const` と `let` による厳格なレキシカルスコープの構築を徹底すること。それこそが、堅牢でスケーラブルな次世代アーキテクチャの絶対条件である。