こんにちは！日々の開発、本当にお疲れ様です。
今回は、JavaScriptという言語の深淵に踏み込み、V8エンジンやモダンなJSランタイムがどのようにコードを解釈し、最適化しているのかという「コンパイルの裏側」を覗いてみましょう。
テーマは「`eval()`と`with`文がスコープチェーンを破壊する理由：静的解析が不可能になるコンパイル時の悲劇」です。
「難しそう…」と感じたかもしれませんが、安心してください。ここをクリアすれば、JavaScriptの変数がメモリ上でどう扱われているのかの本質が見えてきます。さあ、一緒にエンジニアとしての解像度を一段階引き上げていきましょう！
—
1. モダンJavaScriptの心臓部：V8エンジンは「先読み」で最適化している
私たちが普段何気なく書いているJavaScriptのコードは、そのままブラウザやNode.jsで実行されているわけではありません。裏側では、V8などのエンジンがコードを読み込み、機械語に翻訳し、さらに実行速度を極限まで高めるために「JIT（Just-In-Time）コンパイル」と「最適化（Optimization）」を行っています。
この最適化において最も重要な鍵が「静的解析（Static Analysis）」です。
現代のJavaScriptエンジンは、コードを実行する前に、次のようなことをあらかじめ予測します。
- 「この変数は関数スコープ内のどこで宣言されているか？」
- 「このプロパティは、どのオブジェクトのどのメモリ番地（オフセット）にあるか？」
これにより、変数を探すためにわざわざスコープチェーンを上へ上へと辿るコストを削り、ダイレクトにメモリへアクセスするコードを生成できるのです。これが、JavaScriptが昔に比べて圧倒的に高速化した理由なんですよね。
—
2. スコープチェーンの破壊者：`eval()` の正体
しかし、この美しく高速な最適化の仕組みを、一瞬で木端微塵に破壊する「禁断の機能」が存在します。それが `eval()` です。
まずは、次のコードを見てみましょう。
function calculate(x, y) {
// 文字列としてコードを動的に生成・実行する
const code = “console.log(x + y);”;
eval(code);
}
calculate(10, 20); // 30 が出力される
一見すると、「文字列からコードを実行できて便利だな」と思うかもしれません。しかし、コンパイラの視点に立ってみてください。
コンパイラは、コードを解析している段階（コンパイル時）では、`eval` の中身に何が書かれているかを絶対に知ることができません。 なぜなら、`eval` の引数は「実行時」にならないと確定しない文字列だからです。
`eval` が引き起こすコンパイル時の悲劇
1. 変数の名前隠蔽（Shadowing）の可能性：
`eval` の中身で突然 `const x = 999;` のようなコードが実行されるかもしれません。もしそうなると、元の関数内にある変数 `x` の意味合いやスコープが完全に書き換わってしまいます。
2. 最適化の完全放棄：
エンジンは、「いつ、どこで、どの変数が書き換えられるか分からない」という恐怖（不確実性）に直面します。結果として、V8エンジンは「この関数の中身は最適化を諦めよう（Deopt / スローダウン）」という判断を下さざるを得なくなります。
—
3. もう一つの悪夢：`with` 文によるスコープの乗っ取り
`eval` と並んで、スコープチェーンを完全に狂わせるのが `with` 文です。
`with` は、オブジェクトのプロパティをスコープチェーンの先頭に一時的に追加するための構文ですが、これがコードの可読性とパフォーマンスを致命的に破壊します。
const user = {
name: “Alice”,
age: 25
};
function printUserInfo() {
let name = “Bob”; // ローカル変数
// with文を使うと、userオブジェクトのプロパティがスコープの最上位に割り込む
with (user) {
console.log(name); // “Alice” が出力される（user.nameがローカル変数nameを隠蔽する）
}
}
printUserInfo();
ここで一体何が起きているのでしょうか？
通常、`console.log(name)` と書いたとき、エンジンは「現在の関数のスコープに `name` があるな」と即座に判断できます。しかし `with` 文の内部にいると、エンジンは「今アクセスしている `name` は、ローカル変数なのか？ それとも動的に渡された `user` オブジェクトのプロパティなのか？」を、実行時まで判断できなくなります。
これが、コンパイラにとってどれほどの悪夢か分かりますよね。
静的に変数の位置を特定できないため、エンジンは毎回「このオブジェクトの中に `name` というプロパティが存在するかどうか」をハッシュルックアップ（動的なプロパティ検索）し続けることになります。これにより、パフォーマンスは急降下します。
—
4. 厳格モード（`use strict`）とモジュールの世界
こうした背景があるため、現代のJavaScript開発において `eval` や `with` を使うことは、文字通り「百害あって一利なし」とされています。
特に、ES Modules（`import` / `export`）や、ファイルの先頭に記述する `”use strict”;`（厳格モード）の世界では、`with` 文は構文エラー（SyntaxError）として完全に禁止されました。また、`eval` についても、独自のスコープ（EvalError スコープ）を持つように制限され、外側のスコープを汚染しないような対策が取られています。
“use strict”;
const data = { x: 100 };
// 厳格モードで with文 を使おうとすると、即座にSyntaxErrorが発生します
/
with (data) {
console.log(x);
}
/
モダンなフレームワーク（ReactやVueなど）や、最新のビルドツール（ViteやWebpackなど）が生成するコードに、`with` や無秩序な `eval` が一切含まれていないのは、こうしたランタイムの最適化を最大限に活かすためなのです。
—
ここをクリアすれば、JavaScriptの基本はバッチリマスターできますよ！
今回は少しディープなコンパイラの内部事情まで踏み込みましたが、いかがでしたでしょうか？
- JavaScriptエンジンは、実行前の「静的解析」を頼りにコードを爆速に最適化している。
- `eval()` や `with` 文は、中身や挙動が「実行時」まで分からないため、エンジンの予測を裏切り、最適化を破壊する。
- そのため、モダンなJS開発（厳格モードやESモジュール）ではこれらが厳しく制限・禁止されている。
このメカニズムを頭の片隅に置いておくだけで、パフォーマンスを意識したクリーンなコードを書く視点がグッと養われます。日々のコーディングで「なぜこの書き方はダメなのか」を論理的に説明できるようになると、フロントエンドエンジニアとしての自信も深まりますよね。
それでは、次回の記事でもさらにディープで実用的なJavaScriptの世界へご案内します。お楽しみに！