【実務・中級編】eval()とwith文がスコープチェーンを破壊する：なぜ現代開発では絶対に使ってはいけないのか – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

V8エンジンの内部構造から紐解く：なぜ`eval()`と`with`はスコープチェーンを破滅させるのか

JavaScriptの静的スコープ（レキカルスコープ）は、コードが書かれた位置によって変数の参照範囲がコンパイル時に決定されるという、言語仕様の根幹をなす原則の上に成り立っています。V8をはじめとする現代の高度なJavaScriptエンジンは、この「静的確定性」を前提として、命令コードの生成、変数のオフセット計算、そしてJIT（Just-In-Time）コンパイルによる劇的な最適化を行っています。

しかし、歴史的経緯により残された2つの暗黒の遺物——`eval()` と `with` 文は、この静的なスコープ構造を実行時（ランタイム）に動的に改変します。

本記事では、フロントエンドエンジニアおよびアーキテクトに向けて、これら2つの機能がV8エンジンのパイプラインをいかに破壊し、パフォーマンスを壊滅させ、重大なセキュリティホールを生み出すのかを、エンジン内部の挙動まで踏み込んで徹底解説します。あわせて、実務の現場で直ちに適用できる堅牢でパフォーマンスの高い代替設計パターンを提示します。

—

1. 静的スコープ解析のメカニズムとV8の前提条件

JavaScriptエンジンがコードを実行する際、まずソースコードは操舵解析（Parsing）を経てAST（Abstract Syntax Tree: 抽象構文木）へと変換されます。この段階で、V8のスコープ解析器（Scope Analysis）はすべてのスコープと変数の宣言を把握し、どのスコープにどの変数が存在するかを完全な静的構造として決定します。

[Global Scope]
└── [Function Scope: main]
├── localVariable (Context Index: 2)
└── [Closure Scope]

最適化コンパイラ（V8のTurboFanなど）は、この静的解析結果を利用して、スコープの探索を単なる配列のインデックス参照（Context Index）やスタックオフセットへのアセンブリ命令へと変換します。名前による変数の検索（文字列ハッシュテーブルの探索）を実行時に毎回行う必要がないため、JavaScriptはC++に迫る高速な実行速度を獲得できるのです。

しかし、`eval()` や `with` が入ってきた瞬間、この美しい最適化前提が根本から崩壊します。

—

2. `eval()`：レキカル環境への動的インジェクション

`eval()` は、渡された文字列をその場でJavaScriptコードとして評価・実行する関数です。一見便利に見えますが、直近の「レキカル環境（LexicalEnvironment）」を動的に書き換えてしまいます。

V8の内部で何が起きるのか

以下のコードをV8エンジンの視点で追ってみましょう。

function processData(input) {
const x = 10;
eval(input); // inputの中身は実行時まで誰にも分からない！
return x + y;
}

通常、変数 `x` や外部の `y` へのアクセスはコンパイル時に確定します。しかし、`eval()` の呼び出しが存在する場合、コンパイラは以下の事態を考慮せざるを得なくなります。

1. `input` の文字列の中に `var x = 999;` が含まれており、ローカル変数 `x` がシャドーイング（覆い隠し）されるかもしれない。
2. `input` の中に `var y = 500;` が含まれており、未定義だった `y` が突然ローカルに生成されるかもしれない。

この結果、V8コンパイラは該当スコープにおけるすべての変数アクセスに対する最適化（インラインキャッシュやスタック割り当て）を放棄せざるを得なくなります。変数の検索は、低速なハッシュテーブルの動的ルックアップ（`LookupInScope`）へとフォールバックされます。

さらに、`eval()` 内からスコープ外の変数（クロージャ）を参照している場合、エスケープ解析（Escape Analysis）が不可能となり、本来ヒープ領域に確保する必要のない変数まですべてヒープ上の `Context` オブジェクトに退避され、ガベージコレクション（GC）の圧迫を引き起こします。

—

3. `with` 文：スコープチェーンへのオブジェクト挿入という暴走

`with` 文は、指定したオブジェクトを一時的にスコープチェーンの最優先位置に挿入する文法です。

// 悪名高き with文の例
function updateProfile(user) {
with (user) {
name = “Alice”; // user.name への代入？それともグローバル変数 name への代入？
age = 30;
}
}

一見すると `user.name` や `user.age` の入力を省略できるショートカットのように見えますが、内部的な処理は惨劇の一言です。

スコープチェーン破壊のカラクリ

`with (user)` が実行されると、V8は現在の `LexicalEnvironment` の先頭に、`user` オブジェクトをラップした `WithEnvironment` を強制的に割り込ませます。

1. `name = “Alice”` を評価する際、エンジンはまず `user` オブジェクト内に `name` というプロパティ（またはゲッター/セッター、プロトタイプチェーン上のプロパティ）が存在するかを探します。
2. もし `user` に `name` が存在しなければ、一つ外側のスコープ（この場合はグローバル）へと探索を進めます。

問題は、`user` オブジェクトの構造が動的である点です。プロトタイプチェーンが変更されたり、動的にプロパティが削除・追加された場合、`name` が `user` のものを指すのか外側のスコープのものを指すのかが実行のたびに変化します。

最適化コンパイラはプロパティのルックアップパスをインライン化（Inline Cache）することが完全に不可能となり、スコープチェーン上のすべての階層を泥臭く巡回する低速パスを強制されます。

※なお、`with` 文は ECMAScript Strict Mode (`’use strict’`) において文法エラー（SyntaxError）として明確に禁止されています。

—

4. セキュリティリスク：コードインジェクションとスコープ汚染

スコープの破滅は、パフォーマンス低下だけに留まりません。セキュリティにおいて致命的な脆弱性をもたらします。

1. DOMベースXSSおよびコードインジェクション

外部から流入する未検証のデータ（APIレスポンス、URLパラメータ、Form入力）を `eval()` に渡すと、悪意ある任意コード実行（Remote Code Execution）に直結します。

2. 意図しないスコープ汚染（Scope Pollution）

非Strict Mode下での `eval()` や `with` は、上位スコープの変数を予期せぬタイミングで上書きします。

// 実際のWebアプリケーションで起きる事故の模倣
function calculateTotal(cart, voucherCode) {
let discount = 0;

// レガシーコードで動的に動的な計算式を計算しようとした愚行
// voucherCode に “discount = 100; delete Object.prototype…” などを仕込まれると全壊する
eval(“discount = ” + voucherCode);

return cart.total – discount;
}

—

5. 実務で使える堅牢な代替設計パターン

実務において `eval()` や `with` を検討したくなる動機の99%は、「動的なプロパティアクセス」または「動的な計算式・ロジックの評価」です。現代のJavaScript/TypeScriptでは、これらを完全に安全かつ超高速に実現するパターンが存在します。

パターンA：`with`文の完全な代替（分割代入と明示的コンテキスト）

`with` 文を使いたくなる場面は、現代ではオブジェクトの分割代入（Destructuring）およびコンテキストの明確化で100%解決できます。

BAD（アンチパターン：`with`文）

function renderComponent(props) {
// スコープが破壊され、V8の最適化が停止する
with (props) {
console.log(`User: ${name}, Role: ${role}`);
}
}

GOOD（プロダクションコード：分割代入＋デフォルト値）

ユーザープロファイルを安全かつ高速に処理する関数
@param {Object} props – コンポーネントのプロパティ
@param {string} props.name – ユーザー名
@param {string} props.role – 権限

/
function renderComponent(props) {
// 静的解析が可能であり、V8はプロパティアクセスを最適化できる
const { name = ‘Anonymous’, role = ‘Guest’ } = props;

console.log(`User: ${name}, Role: ${role}`);
}

—

パターンB：`eval()`の代替（安全な動的プロパティ参照）

文字列を使って動的に深層オブジェクトのプロパティにアクセスしたいケースです。`eval(‘obj.’ + path)` を行うのは自殺行為です。

GOOD（プロダクションコード：Safe Navigation & Reduce）

文字列パスを用いて安全にオブジェクトの深層プロパティを取得する
@param {Record} target – 対象のオブジェクト
@param {string} path – ドット区切りのキーパス (例: “user.profile.address.city”)
@param {any} [defaultValue=undefined] – 取得失敗時のデフォルト値
@returns {any} プロパティの値

/
function getNestedValue(target, path, defaultValue = undefined) {
if (target == null || typeof path !== ‘string’) {
return defaultValue;
}

// ドットで分割し、プロトタイプ汚染（__proto__等）をフィルタリングして安全に探索
const keys = path.split(‘.’).filter(key => key !== ‘__proto__’ && key !== ‘prototype’);

let current = target;

for (const key of keys) {
if (current == null || !Object.prototype.hasOwnProperty.call(current, key)) {
return defaultValue;
}
current = current[key];
}

return current !== undefined ? current : defaultValue;
}

// === 使用例 ===
const state = {
user: {
profile: {
address: { city: ‘Tokyo’ }
}
}
};

// 安全かつ高速（JITインライン化可能）な参照
console.log(getNestedValue(state, ‘user.profile.address.city’, ‘Unknown’)); // -> “Tokyo”
console.log(getNestedValue(state, ‘user.profile.age’, 20)); // -> 20
console.log(getNestedValue(state, ‘__proto__.polluted’, null)); // -> null (安全にブロック)

—

パターンC：`eval()`の代替（安全な動的計算エバリュエーター）

ユーザー定義のルールや数式（例：「`price 1.1 + shipping`」など）を計算させたい場合、`eval()` ではなく操舵解析器（Parser）の導入または制限された抽象構文木（AST）評価器を自作するのがアーキテクチャとして正解です。

以下は、安全に動的数式を評価する軽量な数式評価エンジンの実装例です。

安全な簡易数式評価クラス（ASTライクな再帰下降パーサーの簡略版）
evalを一切使わず、トークナイズと安全な演算のみで計算を行う

/
class SafeMathEvaluator {
/

単純な算術式を評価する
@param {string} expression – 評価対象の数式 (例: “100 (1 + 0.1)”)
@param {Record} [context={}] – 変数コンテキスト
@returns {number}

/
static evaluate(expression, context = {}) {
// 1. 許容されるトークン（数値、演算子、カッコ、識別子）のみか正規表現で検証
const sanitized = expression.replace(/\s+/g, ”);
if (!/^[a-zA-Z_][a-zA-Z0-9_]|[\d.]+|[+/()-]+$/.test(sanitized)) {
throw new Error(“Invalid characters in expression”);
}

// 2. トークン列に分解
const tokens = sanitized.match(/[a-zA-Z_][a-zA-Z0-9_]|[\d.]+|[+/()-]/g) || [];
let position = 0;

// トークンの取得と消費
const peek = () => tokens[position];
const consume = () => tokens[position++];

// 優先度：プライマリ（数値、カッコ、変数）
const parsePrimary = () => {
const token = consume();
if (!token) throw new Error(“Unexpected end of expression”);

// カッコの処理
if (token === ‘(‘) {
const result = parseExpr();
if (consume() !== ‘)’) throw new Error(“Missing closing parenthesis”);
return result;
}

// 数値リテラル
if (!isNaN(Number(token))) {
return Number(token);
}

// 変数（Contextからの参照）
if (Object.prototype.hasOwnProperty.call(context, token)) {
return context[token];
}

throw new Error(`Unknown token or undefined variable: ${token}`);
};

// 優先度：乗除算 (, /)
const parseTerm = () => {
let left = parsePrimary();
while (peek() === ” || peek() === ‘/’) {
const op = consume();
const right = parsePrimary();
left = (op === ”) ? left right : left / right;
}
return left;
};

// 優先度：加減算 (+, -)
const parseExpr = () => {
let left = parseTerm();
while (peek() === ‘+’ || peek() === ‘-‘) {
const op = consume();
const right = parseTerm();
left = (op === ‘+’) ? left + right : left – right;
}
return left;
};

—

6. テクニカルリードとしての結論とチーム運用方針

チームのコードベースから `eval()` や `with` を撲滅し、V8エンジンにとって最も効率的な静的スコープを維持するために、以下の3つのガードレールをプロジェクトに設定してください。

1. Strict Modeの徹底とES Modulesの採用
ES Modules（`import`/`export`）は自動的に Strict Mode で実行されるため、`with` 文の使用は言語仕様レベルで即座にビルドエラーとなります。
2. ESLintルールの厳格化
`.eslintrc`（またはビルトインのlinter）で以下のルールを `error` に設定します。

`no-eval`: `eval()` の使用を完全禁止。
`no-implied-eval`: `setTimeout(“code”, 1000)` などの暗黙的evalを禁止。
`no-with`: `with` 文の使用を完全禁止。
`no-new-func`: `new Function(‘code’)`（グローバルスコープで評価されるevalの親戚）の使用を原則禁止。

3. 動的計算の要件に対するアーキテクチャレビュー
「ビジネスロジックを動的に評価したい」という要件が発生した場合は、コードの直接評価ではなく、JSONスキーマ、ASTパーサー、あるいはWebAssemblyモジュールによる砂場（サンドボックス）化を設計の基本としてください。

コンパイラ（V8）の思考を理解し、彼らが最もパフォーマンスを発揮できる「確定された静的な構造」をコードとして書き下ろすこと。それこそが、超高速で堅牢なフロントエンドアプリケーションを構築するための極意です。