【実務・中級編】eval()とwith文がスコープチェーンを破壊する技術的理由：静的解析が不可能になるコンパイル時の悲劇 – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

コードレビューをしていて、もし後輩のプルリクエストに `eval()` や `with` が含まれていたなら、私は即座にマージを差し戻す。なぜなら、それらの記述は単なる「コーディング規約の違反」ではなく、JavaScriptエンジンが何十年かけて築き上げてきた最適化の神殿に対する冒涜だからだ。

現代のWebフロントエンドは、複雑なコンポーネントツリーの差分検出、膨大な配列・ストリームデータの高速処理、そしてミリ秒単位の応答性が求められるアニメーションや非同期API連携の嵐だ。その根底を支えるV8などの高パフォーマンスなJSエンジンは、コードが実行される「前」にコンパイルと最適化を行い、変数の物理的なメモリ上の位置を決定している。

だが、`eval()` と `with` は、その静的な予測可能性を根底から破壊する。これらがコードのパフォーマンスを文字通り「死に至らしめる」技術的理由と、実務で絶対に避けるべき理由を、V8の内部挙動の視点から解き明かしていこう。

—

1. V8エンジンの静的解析とスコープチェーンの真実

まず、モダンなJavaScriptエンジンがどのように変数を見つけているかを理解する必要がある。

通常、`let` や `const` で宣言された変数は、ブロックスコープや関数スコープに紐づき、Lexical Environment（レキシカル環境）を形成する。V8はコードをパースし、AST（抽象構文木）を生成する段階で、「この変数がどのスコープの、どのスロット（オフセット）に格納されるべきか」を完全に静的に追跡する。

これにより、関数実行時に変数を探索するコスト（スコープチェーンを遡るコスト）は最小限に抑えられ、インラインキャッシュ（IC）やHidden Class（隠しクラス）といった強力な最適化の恩恵を受けることができる。

悪魔の召喚：`eval()` がスコープを破壊する瞬間

ここに `eval(str)` が登場した瞬間、エンジンの平穏は崩れ去る。

function calculateTax(price) {
let taxRate = 0.1;
// 外部から渡された文字列をその場で実行する
return eval(“price (1 + taxRate)”);
}

「大したことないじゃないか」と思うかもしれない。しかし、V8のコンパイラ視点では、この `eval` の中に何が書かれているかを実行するまで絶対に予測できない。
`eval` の内部から、親スコープの変数（`price` や `taxRate`）が書き換えられたり、全く新しい変数（`let evilVar = …`）が動的にそのスコープへ注入されたりする可能性がゼロではないからだ。

結果として何が起きるか？
V8は「この関数内では、すべての変数の静的解析を諦めざるを得ない」と判断する。

変数の位置をコンパイル時に確定できなくなったV8は、レキシカル環境へのポインタを維持したまま、実行時に名前ベースでメモリをルックアップする「スローダウン・モード（Slowness Mode）」に強制的にフォールバックする。コード全体のJIT最適化（TurboFanによる最適化）がそのブロック単位で剥奪され、パフォーマンスは桁違いに低下する。

—

2. `with` 文：最悪のスコープ汚染メカニズム

`with` 文は、オブジェクトのプロパティをそのスコープの変数として直接扱えるようにする、かつて多用されたシンタックスシュガーだ（モダンでは厳格モード `use strict` により構文エラーとなる）。

// 絶対に書いてはならないアンチパターン
function updateUI(state) {
with (state) {
// user, theme, permissions が state のプロパティなのか、
// それとも外部の変数なのか、エンジンには静的に判別がつかない
title.innerText = user.name;
applyTheme(theme);
}
}

`with` の罪深さは、スコープチェーンの先頭に、実行時まで構造が分からないオブジェクトを強制的に割り込ませる点にある。

エンジンの立場になって考えてみてほしい。`title` という識別子にアクセスしようとしたとき、それが関数のローカル変数なのか、グローバル変数なのか、あるいは `state` オブジェクトの動的なプロパティなのかを、実行時のその瞬間まで誰も断定できない。
当然、コンパイラはレジスタ割当やメモリのオフセット最適化を行うことができず、すべての変数アクセスが「動的プロパティルックアップ」という極めて重い処理に化ける。

これが、「`eval` と `with` は静的解析を不可能にするコンパイル時の悲劇である」と言い切る理由だ。

—

3. 実務における堅牢な代替設計とプロダクションコード

テクニカルリードとして、チームのメンバーには「動的な文字列評価やスコープのハッキングに頼らず、言語仕様の正しいプリミティブとモダンな機能で解決する」ことを徹底させている。

ここでは、非同期API連携や複雑なデータ処理を行うフロントエンド環境において、`eval` や `with` を使わずに安全かつ高速に処理を完結させるためのリファレンス実装を示す。

実装例：安全で最適化されたコンテキストバインディングとデータ処理

以下のコードは、APIから取得した複雑なユーザー権限や設定情報（DTO）を安全に評価し、DOM操作や配列処理を行うモジュールのプロダクションコードだ。

/

  • @fileoverview 動的コード評価を排除し、V8の最適化を最大限に活かす堅牢なデータ処理モジュール

/

‘use strict’; // 厳格モードの強制により、with文や暗黙的なグローバル汚染をコンパイルエラーにする

/

  • 許可されたホワイトリストに基づき、安全にオブジェクトから値を取り出す
  • eval() の代わりに、安全なプロパティアクセッサとマッピングを使用する
  • @param {Object} dataStore – APIから取得した生のデータオブジェクト
  • @param {Array} allowedKeys – 抽出を許可するキーのリスト
  • @returns {Object} サニタイズされた安全なビューモデル

/
export function sanitizeAndTransformState(dataStore, allowedKeys) {
// V8のインラインキャッシュ（IC）を効かせるため、
// 生成するオブジェクトの形状（Hidden Class）を常に一定に保つ
const sanitized = {
isValid: false,
payload: null,
timestamp: Date.now()
};

if (!dataStore || typeof dataStore !== ‘object’) {
return sanitized;
}

const payload = {};
for (let i = 0; i < allowedKeys.length; i++) { const key = allowedKeys[i]; // 動的な with や eval を使わず、厳密なhasOwnでプロパティを安全に取得 if (Object.prototype.hasOwnProperty.call(dataStore, key)) { payload[key] = dataStore[key]; } } sanitized.isValid = true; sanitized.payload = payload; return sanitized; } /