eval()とwith文がスコープチェーンを破壊する技術的理由：静的解析が不可能になるコンパイル時の悲劇
JavaScriptのエンジン――特にGoogle ChromeやNode.jsを駆動するV8は、ただの「スクリプト解釈器」ではない。それは動的言語であるJavaScriptを、C++やRustに匹敵する実行速度へと引き上げる、高度なJIT（Just-In-Time）コンパイルの要塞である。
V8がこれほどの高速化を達成できる最大の理由は、「静的スコープ（Lexical Scoping）の前提に基づく最適化」にある。コードが実行されるよりはるか前、すなわちパース（解析）とコンパイルのフェーズにおいて、変数や関数がメモリ上のどこに配置されるべきかを完全に特定できるという前提が、V8の最適化パイプラインを支えている。
しかし、その鉄壁の要塞をいとも簡単に内側から崩壊させる禁忌の存在がある。それが `eval()` と `with` 文だ。
これらは単に「コードが読みにくくなる」といったコードスタイルの問題ではない。V8のコンパイラが持つ静的解析の保証を完全に粉砕し、エンジンを強制的に「低速な遅延評価モード」へと叩き落とすランタイムの致命傷である。本稿では、なぜ `eval()` と `with` がスコープチェーンを破壊するのか、そのコンパイル時の悲劇とV8の内部挙動を低レイヤの視点から徹底的に解剖する。
—
1. 静的スコープの美学：V8がいかにして変数の位置を特定するか
現代のJavaScriptエンジンが実行速度を稼ぐメカニズムを理解するには、まず通常のコードがコンパイル時にどのように扱われるかを知る必要がある。
V8のパーサーは、ソースコードを抽象構文木（AST）に変換し、スコープ解析（Scope Analysis）を行う。この段階で、すべての変数が「どこで宣言され、どこで参照されるか」が静的に決定される。
function createCounter() {
let count = 0; // スコープ解析により、この変数がコンテキストのどこに属するか確定する
return function() {
return ++count;
};
}
このコードにおいて、`count` という変数は、親スコープの「コンテキスト（Context）」と呼ばれるヒープ上の構造体の特定のオフセット（インデックス）に割り当てられることがコンパイル時に決定している。
JITコンパイラ（IgnitionインタプリタからTurboFanオプティマイザに至るパイプライン）は、このオフセットをハードコードし、機械語レベルで直接メモリアドレスを引くことができる。変数名による動的なルックアップ（プロパティ検索）は、コストの高いハッシュマップアクセスを伴うため、コンパイル時にこれが「配列のインデックスアクセス」へと変換されることが、V8の爆速を担保している。
—
2. `with` 文によるスコープチェーンの動的汚染と隠しクラスの破綻
この静的な美学を最初に踏みにじるのが `with` 文だ。`with` 文は、指定したオブジェクトを一時的にスコープチェーンの最上位に強制挿入する。
function getOffset(obj) {
let x = 10;
with (obj) {
// x は 10 なのか、それとも obj.x なのか？
return x + y;
}
}
コンパイル時の悲劇：レキシカルな変数の固定化の崩壊
上記のコードを見たとき、コンパイラは絶望する。`x` という識別子に遭遇したとき、それがローカル変数 `x` なのか、それとも引数として渡された `obj` のプロパティ `obj.x` なのかを、コンパイル時には一切判断できないからだ。
`obj` がどのような形状（Shape）をしているのか、あるいは実行時にどのようなプロパティが動的に追加・削除されるのかは、実際にそのコードが実行されるまで分からない。V8は、オブジェクトのプロパティアクセスを高速化するために「隠しクラス（Hidden Class / Map）」という概念を使い、プロパティのメモリ上のオフセットをキャッシュしている。
しかし、`with` 文の内部では、このキャッシュの前提がすべて覆る。
1. 静的オフセットの消失: 変数名からメモリ位置への直接マッピングができなくなり、ランタイムはスコープチェーンを上に向かって線形探索（あるいはハッシュテーブル検索）せざるを得なくなる。
2. Holey / Dictionary モードへの強制移行: V8はオブジェクトを高速な配列ベースのレイアウトから、低速な辞書モード（Dictionary Mode）へ格下げせざるを得なくなる。
結果として、`with` 文の内側にあるコードは、JITコンパイラの最適化パスから完全に外され、常に遅いインタプリタの解釈実行に依存することになる。
—
3. `eval()` がもたらす静的解析の完全崩壊とスコープのフリーズ
`eval()` の破壊力は、`with` 文の比ではない。`eval()` は、任意の文字列をその場でJavaScriptコードとしてコンパイル・実行する機能だが、これが存在した瞬間、V8のオプティマイザは白旗を上げる。
function evaluateUserCode(userString) {
let secret = “VERY_SECURE_TOKEN”;
// 悪意のある、あるいは予測不能な文字列が渡される可能性がある
eval(userString);
return function() {
// コンパイラは、このスコープの変数が安全に保持されているか確証を持てない
console.log(secret);
};
}
なぜ `eval()` は最適化を殺すのか？
1. スコープの凍結（Scope Extension）:
`eval()` の内部から、外側のスコープの変数にアクセスできる（あるいは変更できる）。さらに悪質なことに、`eval(“var newVar = 42;”)` のように、実行時に新しい変数を外側のスコープに突発的に生やすことが理論上可能になる。
2. エスケープ解析（Escape Analysis）の無効化:
コンパイラは、変数がヒープに逃げる（エスケープする）か、レジスタやスタック上に留まるかを解析してメモリを割り当てる。しかし `eval()` があると、「どの変数がどこで参照されるか」を静的に追跡することが不可能になるため、すべてのローカル変数をヒープ上のコンテキストオブジェクトに割り当て、かつ変数を遅延削除（または保持）せざるを得なくなる。
3. デオプティマイゼーション（Deoptimization）の嵐:
もしJITが誤って最適化（例えば、変数をレジスタに割り当てるなど）を行った後に `eval()` が呼び出された場合、V8は即座に実行を中断し、最適化された機械語を捨ててインタプリタモードへフォールバックする（Deopt）。このオーバーヘッドは、アプリケーションのレイテンシを致命的に悪化させる。
—
4. サプライチェーンを穿つ：プロトタイプ汚染と `eval()` の悪夢
このスコープの破壊、そして静的解析の不全は、単なる「パフォーマンス低下」だけに留まらない。セキュリティの観点から見れば、リモートコード実行（RCE）へと直結する致命的な脆弱性の温床となる。
近年の Node.js エコシステムにおいて猛威を振るうプロトタイプ汚染（Prototype Pollution）は、まさに動的なオブジェクトのプロパティ解決の隙を突く攻撃手法である。
// 攻撃者が入力を操作し、Object.prototypeを汚染する例
const maliciousPayload = JSON.parse(‘{“__proto__”: {“polluted”: “RCE_PAYLOAD”}}’);
// 深いオブジェクトのマージ処理などで汚染が波及
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
}
もし、この汚染された環境の近くで、動的な文字列評価やテンプレートエンジン、あるいはORMのクエリ構築などで `eval()` やそれに類する仕組み（`new Function()` など）が使われていた場合、どうなるか。
静的解析が効かず、動的なプロトタイプチェーンのルックアップに依存しきったコードベースでは、攻撃者が混入させたプロパティが予期せぬスコープにバインドされ、意図しないコード実行を引き起こす。V8が「最適化を諦めた領域」こそが、セキュリティ上の最大のブラックボックスであり、攻撃者にとって格好の侵入経路となるのだ。
—
5. 現代のJavaScriptランタイムにおける防壁：厳格モード（Strict Mode）の英知
TC39（ECMAScriptの仕様策定委員会）およびV8の開発者たちは、この言語の持つ「ダイナミックすぎる毒」をコントロールするため、大きな決断を下した。それが ECMAScript 5 で導入された 厳格モード（Strict Mode: `’use strict’;`） である。
厳格モードにおいて、`eval` と `with` は以下のように厳しく制限・無力化されている。
- `with` 文の完全な禁止: 厳格モード内で `with` を使用すると、シンタックスエラー（SyntaxError）としてコンパイル自体が拒絶される。
- `eval` のスコープ隔離: 厳格モード内の `eval()` は、独自の独立したスコープ（Lexical Environment）を持つようになり、呼び出し元のローカルスコープを汚染・変更することができなくなった。
‘use strict’;
function secureFunction() {
let x = 10;
// 厳格モードでは、eval内での変数宣言は外側に漏れない
eval(‘let x = 20; console.log(x);’); // 20
console.log(x); // 10 (外側のxは破壊されない)
}
// with (‘test’) { … } // 構文エラー: Strict mode code may not include a with statement
これにより、V8のコンパイラは `eval` が存在していても、その影響範囲を限定的に抑えることができ、静的解析の完全な崩壊を回避できるようになった。
—
結言：低レイヤを知る者のみが書けるコードへ
JavaScriptは「初心者にも優しく、動的で書きやすい言語」として語られがちだ。しかし、ひとたびNode.jsやブラウザのV8エンジンという巨大なランタイムの内部構造に目を向ければ、その下にはC++のメモリ管理、JITコンパイラのヒューリスティック、そして緻密な静的解析のロジックが幾重にも張り巡らされていることが分かる。
`eval()` や `with` 文を使用することは、V8エンジンの心臓部に泥を投げ入れるようなものだ。コンパイラから最適化の特権を奪い、アプリケーションを低速で脆弱な状態へと引きずり下ろす。
真にスケーラブルで、予測可能かつ高速なフロントエンド・バックエンドアーキテクチャを構築したいのであれば、言語の仕様表面的ではなく、ランタイムの物理的な挙動――コンパイル、スコープ解析、隠しクラス、そしてイベントループの裏側までを脳内にトレースしなくてはならない。
コードを書くとは、V8と対話することだ。その対話を阻害するノイズを、今日からあなたのコードベースから完全に排除せよ。