eval()とwith文がスコープチェーンを破壊する理由：静的解析が不可能になるコンパイル時の悲劇
JavaScriptエンジニアであれば、`eval()`や`with`文が「アンチパターンである」「パフォーマンスを殺す」という教えを一度は耳にしたことがあるはずだ。Linterを開けば容赦なくエラーや警告が飛び、モジュールシステムが標準化した現代においては、これらの構文を目にすることは稀になった。
しかし、なぜこれほどまでに忌避されるのか。その本質を「V8エンジンのコンパイルパイプライン」「隠しクラス（Hidden Classes）の物理最適化」「静的スコープ（レキシカルスコープ）の破壊」という低レイヤの視点から完全に理解している者は少ない。
今回は、TC39の仕様策定やランタイムの挙動を知り尽くすアーキテクトの視点から、`eval()`と`with`文がJavaScriptの最適化の神髄をいかにして粉砕するか、そのメカニズムを赤裸々に暴く。
—
1. V8エンジンの心臓部：レキシカルスコープと静的解析の幻想
モダンなJavaScriptエンジン（V8、SpiderMonkey、JavaScriptCoreなど）が驚異的な速度でコードを実行できる最大の理由は、「実行前にコードの構造が完全に静的に決定されている（Lexical Scoping）」という前提に立っているからだ。
V8のコンパイルパイプライン（Ignitionによるバイトコード生成から、TurboFanによるJIT最適化への移行）において、関数やブロックがどの変数にアクセスするかは、コードがパースされた瞬間（コンパイル時）に確定していなければならない。
スコープチェーンのコンパイル時解決
通常のコードであれば、変数の参照先（Lexical Environment）は次のように静的に解決される。
function createCounter() {
let count = 0; // スコープチェーン上にバインドされる
return function() {
return ++count; // どのスコープの ‘count’ を指すかコンパイル時に確定している
};
}
V8は、この`count`変数がどの程度のスコープ深度にあり、どのレキシカル環境のどのスロットに格納されているかを事前に把握できるため、メモリアクセスをインデックスによる直接参照（オフセットアクセス）へと最適化できる。
しかし、ここに`eval()`や`with`が持ち込まれた瞬間、この美しく堅牢な最適化の砦は一瞬にして崩壊する。
—
2. eval()：ランタイムの不確実性がJITコンパイラを沈黙させる理由
`eval()`は、文字列として渡された任意のJavaScriptコードをその場で動的にコンパイルし、実行する魔術的な関数である。この「何が飛び出すか分からない」という動的性が、エンジンにとって最大の悪夢となる。
スコープの動的注入とスコープレジスタの無効化
次のコードを見てほしい。
function insecureRuntime(userCode) {
let x = 10;
let y = 20;
// 開発者ですら、この時点で何が起きるかコンパイル時には分からない
eval(userCode);
return x + y;
}
もし引数 `userCode` に `”x = 99; var z = 100;”` という文字列が渡された場合、何が起こるか？
`eval()` の内部で宣言された変数や、既存変数への代入は、呼び出し元のスコープをその場で「改変」する。
これの何が悲劇かといえば、コンパイラが「この関数内の変数 `x` と `y` の値や型が、evalの実行によって書き換わったかどうか」を事前に予測できなくなる点にある。
1. JIT最適化の停止（Deoptimization）: TurboFanは、`eval`が存在するスコープ内では、変数のメモリ位置をレジスタにキャッシュしたり、インラインキャッシュ（Inline Caches）を適用したりすることができなくなる。すべての変数参照が、実行時まで遅延されたプロパティルックアップ（または遅いスコープチェーンの走査）に格下げされる。
2. ストレージのヒープ化: 通常、ローカル変数はスタックフレームや最適化されたレジスタに配置されるが、`eval`が存在すると、すべての変数をいつでも外部から参照・変更できるように「コンテキストオブジェクト（Context object）」としてヒープ上に実体化させざるを得なくなる。これによりGC（ガベージコレクション）のプレッシャーが劇的に跳ね上がる。
—
3. with文：スコープチェーンの汚染と隠しクラスの破壊
`with`文は、指定したオブジェクトをスコープチェーンの最上位に一時的に強制挿入するという、言語設計の歴史における最大の過ちの一つである。
const query = {
x: 1,
y: 2
};
function processWith(obj) {
let a = 10;
with (obj) {
// ここでの ‘x’ は obj.x なのか、外部のスコープ変数なのか？
console.log(x + a);
}
}
隠しクラス（Hidden Classes / Shapes）の最適化を殺す
V8はオブジェクトのプロパティアクセスを高速化するために「隠しクラス（Map）」という概念を使用し、プロパティのメモリ上のオフセットを固定化する。しかし、`with`文の内部では、アクセスされるプロパティが「どのオブジェクトに属しているのか」が実行時まで一切不明になる。
- `obj` がたまたま `x` を持っていれば `obj.x` になる。
- もし `obj` が `x` を持っていなければ、スコープチェーンを遡って外側のスコープの `x` を探す。
- 最悪なことに、`with` ブロック内で動的に新しいプロパティに代入が行われた場合、それが `obj` のプロパティになるのか、それとも新しい変数の宣言になるのかすら、実行するまで確定しない。
この不確実性により、V8のインラインキャッシュ（IC）は完全に無効化され、すべてのプロパティアクセスがハッシュマップ的な動的ルックアップへと退化する。これはパフォーマンスにおいて致命傷である。
—
4. セキュリティの深層：プロトタイプ汚染（Prototype Pollution）とRCEの連鎖
ここまでパフォーマンスの観点から解説したが、`eval`と`with`がもたらす最大の害悪は、セキュリティの文脈、特にサプライチェーン攻撃におけるリモートコード実行（RCE）の踏み台になる点にある。
現代のNode.js環境やフロントエンドにおいて、悪意ある攻撃者がJSONペイロード等を介して `Object.prototype` を汚染する「プロトタイプ汚染（Prototype Pollution）」という脆弱性が度々問題になる。
もしアプリケーションのどこかで `eval()` や動的なコード評価、あるいは `with` 文が使われている場合、このプロトタイプ汚染が致命的なRCEへと直結する。
脆弱性のエクスプロイトシナリオ
// 攻撃者がプロトタイプ汚染によって Object.prototype に悪意あるプロパティを注入したと仮定
Object.prototype.rcePayload = “process.mainModule.require(‘child_path’).execSync(‘id’)”;
function unsafeHandler(userInput) {
// 開発者は安全なオブジェクトを扱っているつもり
let context = { data: userInput };
with (context) {
// ‘rcePayload’ は context には存在しないが、プロトタイプチェーンを遡って発見される！
// もしここで文字列結合や不適切な評価が行われると…
eval(rcePayload);
}
}
`with`文がスコープチェーンの検索をオブジェクトのプロトタイプチェーンと結合させる性質を利用し、本来意図しないグローバルなオブジェクトやプロトタイプ上のプロパティがスコープ内に引きずり出される。そこに `eval` が組み合わさることで、攻撃者は任意のシステムコマンドを実行する権利を手に入れてしまうのだ。
これが、現代のJavaScript仕様（ECMAScript 5以降）の strict mode（厳格モード）において、`with`文が構文エラー（SyntaxError）として完全に排除された理由である。
—
5. まとめ：静的解析の未来を守るために
JavaScriptが「ブラウザのおもちゃ」から、サーバーサイド、デスクトップアプリ、そしてIoTデバイスを駆動する堅牢なプラットフォームへと進化できたのは、V8をはじめとするランタイムエンジニアがJITコンパイラの最適化限界を極限まで押し上げてきたからに他ならない。
そして、その最適化の恩恵を最大限に受けるための最大の盟友が、「静的解析（Static Analysis）」である。
- コードの構造が静的に決まる。
- 変数のスコープがコンパイル時に確定する。
- 隠しクラスが物理メモリ上のオフセットを最適化する。
`eval()` や `with` 文は、この美しく構築された予測可能性の殿堂に泥足で踏み込み、エンジンを「ただの遅いインタプリタ」へと逆戻りさせる劇薬である。
シニアエンジニアたる者、動的な便利さに惑わされず、ランタイムが何を考え、メモリ上で何を行っているのかを常に脳内でトレースせよ。コードの美しさとパフォーマンス、そしてセキュリティは、常に「静的な確実性」の上に成り立っているのだ。