こんにちは！フロントエンドからNode.jsの深部まで、JavaScriptの生態系を隅々まで愛するチーフアーキテクトの私です。
今回は、JavaScriptの学習者が必ず一度は耳にする、しかし普段のモダンな開発では絶対に封印すべき「禁断の魔術」、`eval()` と `with`文 についてお話しします。
「動的にコードを組み立てられるなんて便利そう！」
「オブジェクトのプロパティアクセスを短く書けてスマートじゃない？」
そう思って手を出した瞬間、あなたの書いたコードはV8エンジン（JavaScriptの実行エンジン）にとっての「悪夢」へと変貌します。なぜこれらがV8の最適化を破壊し、パフォーマンスを地の底まで落とすのか。コンパイルの裏側で何が起きているのかを、一緒に紐解いていきましょう。ここをクリアすれば、JavaScriptのランタイム挙動の理解は一段と深まりますよ！
—
1. 変数の居場所がわかる「静的スコープ」の仕組み
まずは、通常のJavaScriptがどのように変数を見つけているのかをおさらいしておきましょう。
JavaScriptは「レキシカルスコープ（静的スコープ）」という仕組みを採用しています。これは、「コードを書いた場所（構造）によって、変数の意味がコンパイル時に完全に決まる」というルールです。
const globalVar = “地球”;
function outer() {
const outerVar = “大気圏”;
function inner() {
const innerVar = “地表”;
// どの変数にアクセスするかは、コードを書いた時点で100%確定している
console.log(innerVar, outerVar, globalVar);
}
inner();
}
outer();
V8のようなモダンなJIT（Just-In-Time）コンパイラは非常に優秀です。コードを実行する前に、この静的構造を解析し、「変数 `innerVar` は現在の関数のローカル領域のオフセット（メモリ上の位置）0番地にある」「`outerVar` はスコープチェーンを1つ遡った場所にある」ということをコンパイル時にあらかじめ計算（最適化）してしまいます。
だからこそ、JavaScriptは高速に動作するのです。
—
2. 破壊者その1：`eval()` — 文字列をコードに変える魔術
では、ここに `eval()` が登場するとどうなるでしょうか。
`eval()` は、引数に渡した「文字列」をその場でJavaScriptのコードとして実行してしまう関数です。
function calculate(userCode) {
let x = 10;
let y = 20;
// 渡された文字列がどんな内容なのか、書いた時点では誰にもわからない
return eval(userCode);
}
// 実行例
console.log(calculate(“x + y”)); // 30 が返る
一見すると便利に見えますが、ここに「コンパイル時の悲劇」が潜んでいます。
なぜ `eval()` は静的解析を破壊するのか？
V8エンジンは、コードをコンパイルする際に「この関数の中にはどんな変数があって、どうメモリを割り当てればいいか」を計画します。しかし、`eval(userCode)` の中身は、プログラムが実際に実行される瞬間まで何が書かれているかわかりません。
もしかしたら、その文字列の中には `let x = 999;` や `eval` の外側のスコープをごっそり書き換えるコード（例: `with` と同様の変数汚染や、変数の削除・再定義）が含まれているかもしれないのです。
そのため、V8はこうせざるを得なくなります。
> 「おい、`eval` があるぞ！ コンパイル時の最適化なんてやってられん。この関数の中の変数がどこにあるか、事前の予測はすべて破棄だ。実行時に毎回、変数の名前を文字列として探しに行こう（スロースコープ・ルックアップ）」
結果として、CPUキャッシュは効かなくなり、メモリ上の変数の直接アクセスは失われ、パフォーマンスは急降下します。これが、`eval()` が「悪（eval is evil）」と呼ばれる技術的な理由です。
—
3. 破壊者その2：`with`文 — スコープチェーンを無理やり歪める異端児
もう一つの破壊者が `with`文 です。
`with`文は、オブジェクトのプロパティをスコープチェーンの最上位に一時的に追加し、オブジェクト名を省略してプロパティにアクセスできるようにするための構文でした（※現在の strict モードでは構文エラーとして完全に禁止されています）。
const person = {
name: “Taro”,
age: 28,
country: “Japan”
};
// with文を使ったコード
with (person) {
// person. を付けなくてもプロパティにアクセスできる…ように見える
console.log(name); // “Taro”
console.log(age); // 28
console.log(country); // “Japan”
}
一見するとタイポが減ってコードがすっきりするように思えますよね。しかし、これもコンパイラの頭を抱えさせる大問題を引き起こします。
予期せぬ名前衝突とコンパイル時の絶望
以下のコードを見てください。
let message = “グローバルなメッセージ”;
function showInfo(obj) {
let message = “ローカルなメッセージ”;
with (obj) {
// さて、この “message” は一体どれを指しているでしょうか？
// 1. 関数のローカル変数 “message” か？
// 2. 引数で渡された obj のプロ “.message” か？
console.log(message);
}
}
答えは、「`obj` が実際に実行時にどんな形をしているかによって変わる」 です。
もし `obj` が `{ message: “オブジェクトのメッセージ” }` というプロパティを持っていればそれが優先され、持っていなければローカル変数の `message` が使われます。
つまり、コンパイルの時点では、`console.log(message)` の `message` がメモリのどこにあるのか、人間にもコンパイラにも絶対に特定できないのです。
V8は、`with`文の中に入った瞬間から、変数の位置をメモリ上のアドレスで即座に引き当てる最適化を諦め、文字列ベースの動的なプロパティ検索（ハッシュマップ引き）に切り替えざるを得なくなります。これが、V8のJITコンパイラにとっての二度目の悲劇です。
—
4. モダンJavaScriptの選択：Strictモードと安全な世界
私たちが普段書いているモダンなJavaScript（ES6以降、特に `use strict` が強制される環境やModules）では、これらの問題に対して極めて厳格なアプローチをとっています。
1. `with`文の完全な死滅
- ECMAScript 5以降の Strictモード では、`with`文を使用すると構文エラー（SyntaxError）が発生します。言語仕様のレベルで、スコープチェーンを破壊する危険な構文が排除されたのです。
2. `eval()` の隔離と最適化の制限
- `eval()` 自体は言語仕様として残っていますが、Strictモード内では独自のスコープ（Eval環境）を作り、外側のスコープを汚染しないように隔離されるようになりました。それでもなお、V8の最適化を阻害するため、実務で使うことはご法度です。
—
まとめ：今回の極限知見の総括
ここをクリアすれば、JavaScriptのランタイム挙動のマスターはもうすぐです！今日の重要ポイントを振り返りましょう。
- レキシカルスコープの恩恵: JavaScriptが高速に動作するのは、変数の位置がコンパイル時に静的に確定しているから。
- `eval()` の罪: 文字列から動的にコードを生成するため、コンパイラが変数の位置を予測できなくなり、実行時ルックアップ（低速化）に堕ちる。
- `with`文の罪: オブジェクトのプロパティをスコープチェーンに強制挿入し、変数の名前解決をランタイム依存にするため、最適化が完全に無効化される。
「動的に何でもできる柔軟さ」と引き換えに、私たちはパフォーマンスと予測可能性を失います。プロとしてコードを書くときは、V8エンジンが喜ぶ「予測可能で、静的に解析しやすいコード」を常に心がけましょう。
それでは、また次の深淵な世界でお会いしましょう！バッチリマスターできましたね！