eval()とwith文がスコープチェーンを破壊する理由：V8エンジン最適化の死角とランタイム防壁の崩壊
JavaScriptという言語の進化は、V8をはじめとする高速なJIT（Just-In-Time）コンパイラの歴史そのものだ。かつて「おもちゃのスクリプト言語」と嘲笑われた動的言語が、今やC++やRustに肉薄する実行速度を叩き出せるのは、「静的解析が容易であること」を大前提とした数々の極限的最適化（Hidden Class, Inline Caching, Escape Analysis等）がエンジン内部で泥臭く行われているからに他ならない。
しかし、その強固な最適化の城壁をいとも簡単に内側から爆破し、JITコンパイラを絶望的なスローダウン（あるいは最適化の放棄＝Deoptimization）へと追い込む禁忌の存在がある。それが `eval()` と `with` 文だ。
本稿では、これらふたつの構文がなぜJavaScriptのスコープチェーンを根底から破壊し、V8エンジンの最適化を無効化するのか。そして、それがセキュリティの文脈においていかに致命的なサプライチェーン・ハック（リモートコード実行：RCE）を誘発するのかを、ランタイムの低レイヤの挙動から徹底的に解剖する。
—
1. スコープチェーンとレキシカルスコープの前提
モダンなJavaScript（ES2015以降）は、レキシカルスコープ（静的スコープ）をベースに成り立っている。コードを書いた時点で、どの変数がどのスコープに属しているかは一意に決まる。
V8エンジンのコンパイラ（IgnitionからTurboFanへのパイプライン）は、この「変数の物理的な配置（レキシカル環境）」がコンパイル時に確定しているという前提のもとで、以下のような最適化を施す。
- コンパイル時変数バインド: 変数へのアクセスを、メモリ上の固定オフセット（またはコンテキスト内のスロット番号）に対するO(1)の直接参照に変換する。
- レジスタ割り当て: 頻繁にアクセスされる変数をCPUレジスタに直接アロケートする。
この美しい決定論的世界を粉砕するのが、実行時までコードの内容が隠蔽される `eval()` と、名前空間の解決を動的に歪める `with` 文である。
—
2. `eval()` がV8の静的解析を殺すメカニズム
`eval()` は、任意の文字列をその場でJavaScriptコードとしてパースし、実行する魔術的な関数だ。この「何が起きるか実行するまで分からない」という性質が、JITコンパイラの最大の敵となる。
スコープの動的拡張（Dynamic Scope Injection）
通常、関数内のローカル変数は、その関数に対応するコンテキスト（Context）の中に静的に保存される。しかし、関数内で `eval()` が呼ばれた瞬間、V8は最悪のシナリオを想定せざるを得なくなる。
function vulnerableFunction(userInput) {
let x = 10;
let y = 20;
// 完全に動的なコード実行
eval(userInput);
return x + y;
}
もし `userInput` に `”x = 100;”` という文字列が渡された場合、`eval` の中からローカル変数 `x` の値が書き換えられる可能性がある。さらに悪質なケースでは、`eval` 内で新しい変数が宣言されたり、外側のスコープの変数を隠蔽（シャドーイング）するコードが動的に挿入されたりする。
最適化の放棄：Deoptimizationとスローダウン
V8は、`eval` が含まれるスコープを見つけた瞬間、そのスコープ内のすべての変数アクセスに対する最適化を完全に放棄（あるいは遅延）する。
1. インラインキャッシュ（IC）の無効化: オブジェクトのプロパティアクセスや変数参照を高速化するICが機能しなくなる。すべての参照が、ハッシュマップ的な動的ルックアップにフォールバックする。
2. スコープオブジェクトのヒープアロケーション: 本来であればCPUレジスタやスタックフレーム上で完結するはずの変数群が、ガベージコレクションの対象となるヒープ上の「Contextオブジェクト」として強制的に実体化される。これによりメモリ消費量が増大し、GCのプレッシャーが跳ね上がる。
—
3. `with` 文：スコープチェーンのハッキング
`with` 文は、オブジェクトのプロパティを一時的にローカル変数としてスコープチェーンの最上位に強制的にねじ込む構文である。
const obj = { a: 1, b: 2 };
function calculate(obj) {
let a = 10;
with (obj) {
// ここで参照される ‘a’ は、ローカル変数 ‘a’ なのか、
// それとも obj.a なのか？
console.log(a + b);
}
}
なぜ `with` が悪なのか？
1. 静的解析の完全な崩壊: コンパイラは、`a` という識別子が指し示す実体が「ローカル変数」なのか「引数 `obj` のプロパティ」なのかを、コンパイル時に決定できなくなる。実行時に `obj` がどのような形状（Hidden Class）を持っているかによって解決先が変わるためである。
2. プロトタイプチェインの動的探索: `with` ブロック内で未定義の識別子にアクセスした場合、検索は `obj` 自体だけでなく、そのプロトタイプチェーンを延々と遡ることになる。これがコードの実行パスを予測不能にし、CPUのパイプラインハザードや分岐予測のミスを誘発する。
事実、Strict Mode（`”use strict”;`）において、`with` 文は構文エラー（SyntaxError）として完全に禁止されている。これは言語仕様レベルで「現代のランタイムにおいて存在してはならない構文」であることの証明に他ならない。
—
4. セキュリティの深層：プロトタイプ汚染とRCEの連鎖
パフォーマンスの低下だけでも採用理由としては十分すぎるほど致命的だが、セキュリティの観点から見ると、`eval` と `with` はリモートコード実行（RCE）の直通エレベーターへと変貌する。
近代のJavaScriptエコシステムにおいて、サプライチェーン攻撃の常套手段となっているのがプロトタイプ汚染（Prototype Pollution）だ。悪意ある攻撃者が `Object.prototype` を汚染し、任意のプロパティ（例: `output` や `Command` など）を注入することに成功したとする。
ここで、もしアプリケーションコードのどこかに以下のような脆弱な実装が存在していたらどうなるか。
// 危険なアンチパターン：プロトタイプ汚染とevalの結合
function unsafeExecute(userConfig) {
// 汚染されたプロトタイプチェーンのプロパティがスコープに侵入する
with (userConfig) {
// もし userConfig に該当プロパティがなくても、
// Object.prototype からプロパティがスキャンされる可能性がある
eval(executableCode);
}
}
攻撃者は、汚染されたプロトタイプチェーンや細工された入力オブジェクトを介して、`eval` に渡る文字列変数を自由自在に書き換えることができる。結果として、Node.js環境であれば `child_process` モジュールを呼び出してシステムコマンドを直撃させることが可能となり、コンテナの完全な乗っ取り（RCE）へと直結する。
—
5. 現代のランタイムにおける防壁とまとめ
V8エンジンをはじめとするモダンJSランタイムは、セキュリティとパフォーマンスの二面から、これらの動的スコープ破壊構文を徹底的に排除する方向で進化してきた。
- Strict Modeの義務化: モジュール（ES Modules）やクラスの内部では、デフォルトでStrict Modeが強制され、`with` は構文レベルで排除されている。
- CSP（Content Security Policy）: ブラウザ環境においては、`unsafe-eval` を許可しないCSPヘッダーを設定することで、仮に脆弱性からインジェクションが発生しても、`eval()` によるコード実行をブラウザのランタイム防壁が強制ブロックする。
シニアエンジニアとしての結論
コードを書くとき、私たちは常に「V8エンジンの脳内」をシミュレートしなければならない。
「なんとなく動くから」「動的にプロパティをバインドできて便利だから」という安易な理由で `eval()` やそれに類する動的コード評価（`new Function()` の乱用など）に手を出すことは、自らランタイムの最適化エンジンを破壊し、アプリケーションをセキュリティの崖っぷちに立たせることに等しい。
真に堅牢で、CPUのポテンシャルを極限まで引き出すコードとは、「コンパイル時にすべての形が決定している、静的で予測可能なコード」である。その鉄則を破るコードは、プロダクション環境のコードベースに一行たりとも存在してはならない。