コードレビューの場で、もし後輩エンジニアが `eval()` や `with` 文を書いているのを見つけたら、私は席から立ち上がって即座にその手を止めさせる。なぜなら、それらの構文は単なる「レガシーな書き方」というレベルを超えて、現代のJavaScriptランタイムが誇る最適化の仕組みそのものを根底から破壊する「静的解析の天敵」だからだ。
今回は、V8などのモダンなJavaScriptエンジンが内部でどのようにコードを解釈し、なぜ `eval()` や `with` がそのパイプラインを急停止させるのか、ランタイムの深淵からロジカルに紐解いていこう。
—
1. なぜモダンJSは「静的スコープ」で爆速なのか
現代のJavaScriptエンジン（V8、SpiderMonkey、JavaScriptCoreなど）は、コードを実行する前に、レキシカルスコープ（静的スコープ）を前提とした強固な最適化を行う。
JavaScriptのコードがエンジンに読み込まれると、パーサーが構文木（AST）を作り、スコープチェーンを事前に確定させる。これにより、V8のJITコンパイラ（IgnitionやTurboFan）は、「ある変数（Identifier）がメモリ上のどの位置、あるいはどのコンテキスト（Context / Scope）に存在するのか」をコンパイル時に完全に把握できる。
// 【静的スコープの例】
function createCounter() {
let count = 0; // スコープチェーンのどこにあるかがコンパイル時に確定する
return function() {
return ++count;
};
}
const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
このコードにおいて、`count` 変数がどこにバインドされているかは一目瞭然だ。エンジンはこの変数アクセスを、インラインキャッシュ（Inline Caching）や Hidden Class（形状）の最適化によって、C/C++レベルの高速なメモリアクセスへと昇華させている。
しかし、この静的な美しさを木端微塵に粉砕するのが、`eval()` と `with` 文である。
—
2. `eval()` がスコープチェーンを破壊するメカニズム
`eval()` は、任意の文字列をその場でJavaScriptコードとしてコンパイルし、実行する魔術的な関数だ。しかし、この「何が起きるか実行時まで分からない」という特性こそが、エンジンの最適化を殺す最大の原因となる。
function calculate(x, y) {
// 開発者ですら、実行時にこの文字列が何をするか静的には分からない
eval(“var result = x + y;”);
return result; // どこからやってきた変数なのか？
}
calculate(10, 20);
V8の悲劇：レキシカルな予測可能性の喪失
V8は、コード内のどこかに `eval()` が存在した瞬間、「この関数内（あるいはスコープ内）の変数は、実行時に文字列として挿入されるコードによって、突然名前を書き換えられたり、新しい変数が勝手に追加されるかもしれない」と判断せざるを得なくなる。
1. スコープの固定化の崩壊: 本来、どの変数がどのスコープに属するかはコンパイル時に確定するが、`eval` があると、実行時まで変数の実体を特定できなくなる。
2. 最適化の巻き戻し (Deoptimization): JITコンパイラは安全な最適化を諦め、変数ルックアップを遅い「動的な名前解決（Dictionary Mode / Hash Lookup）」にフォールバックさせる。
3. クロージャ解析の麻痺: どの変数をヒープに保持し、どの変数をレジスタやスタックに載せるべきかの判断（Escapes Analysis）ができなくなり、メモリ効率が著しく悪化する。
—
3. `with` 文が引き起こすランタイムの混乱
`with` 文は、オブジェクトのプロパティをスコープチェーンの最上位に一時的に追加するという、さらに悪名高い構文だ。
const user = { name: “Alice”, age: 30 };
with (user) {
console.log(name); // “Alice” と出力されるが…
console.log(age); // 30
// ここで問題発生：これはローカル変数か？それとも user.active のことか？
active = true;
}
動的スコープの悪夢
`with` 文の内部では、識別子（変数名）に出会ったとき、それが本当にローカル変数なのか、あるいは `with` で指定されたオブジェクトのプロパティなのかを、コンパイル時には絶対に判定できない。
実行時にオブジェクトのプロパティを舐め回すように探しに行かなければならず、これまたV8のインラインキャッシュを完全に無効化する。モダンブラウザの厳格モード（`use strict`）において、`with` 文が構文エラー（SyntaxError）として完全に弾かれるのは、こうしたランタイムのパフォーマンス低下とバグの温床を断つための必然なのだ。
—
4. プロダクションコードにおける実用的な設計と代替案
テクニカルリードとしてコードレビューを行う際、「なぜ `eval` や `with` を使ってはいけないのか」を説明できた上で、では「どう書くべきか」というモダンで堅牢な代替案を示せなければ意味がない。
実務でやりがちな「動的なプロパティアクセス」や「動的な式評価」を、安全かつV8最適化フレンドリーに実装するプロダクションコードのパターンを提示しよう。
アンチパターン：動的処理を eval で書いた最悪の例
// 【絶対にしてはいけない実装】
function getNestedValueUnsafe(obj, pathString) {
// eval や new Function による動的コード評価はセキュリティ脆弱性（XSS等）の温床であり、最適化も殺す
let result;
try {
result = eval(`obj.${pathString}`);
} catch (e) {
result = undefined;
}
return result;
}
ベストプラクティス：静的解析可能で安全なモダンJavaScript設計
配列のプロパティパスを安全に走査するには、`eval` ではなく、標準的な配列メソッド（`reduce` など）を用いた純粋な関数型アプローチを採用する。これならV8は完全にスコープとオブジェクトの形状を把握できるため、インプレースな最適化を維持できる。
/
- 安全かつ高速にネストされたオブジェクトのプロパティを取得するユーティリティ
- @param {Object} obj – 走査対象のオブジェクト
- @param {string} path – ドット区切りのパス (例: ‘user.profile.name’)
- @returns {any} 取得した値、存在しない場合は undefined
/
export function getNestedValue(obj, path) {
// 予期せぬ入力に対するガード節（フェイルファスト）
if (!obj || typeof obj !== ‘object’ || typeof path !== ‘string’) {
return undefined;
}
// パスをドットで分割し、静的なループ/reduceで安全にアクセスする
// V8はこのパターンを極めて高速に最適化する
const keys = path.split(‘.’);
let current = obj;
for (let i = 0; i < keys.length; i++) {
const key = keys[i];
// プロパティが存在するか、あるいはnull/undefinedにアクセスして落ちないか厳格にチェック
if (current === null || current === undefined || !Object.prototype.hasOwnProperty.call(current, key)) {
return undefined;
}
current = current[key];
}
return current;
}
// --- 使用例 ---
const state = {
user: {
profile: {
name: "Ken",
role: "Chief Architect"
}
}
};
console.log(getNestedValue(state, 'user.profile.name')); // "Ken" (高速かつ安全に取得)
console.log(getNestedValue(state, 'user.settings.theme')); // undefined (安全にフォールバック)
---
5. チーフアーキテクトからのメッセージ
JavaScriptは「動的な言語」として産声を上げたが、現代のWebアプリケーション、ひいてはNode.jsやDeno、Cloudflare WorkersといったサーバーサイドランタイムにおけるJSは、「極限まで静的解析され、JITによって最適化されたハイパフォーマンス言語」として稼働している。
`eval()` や `with` 文を使うということは、エンジンが築き上げた壮大な最適化の城壁を、自らの手で内側から爆破するようなものだ。パフォーマンスの低下だけでなく、コードの可読性を落とし、セキュリティ上の脆弱性（Code Injection）を生み出す元凶でしかない。
型安全、スコープの明確性、そしてランタイムの挙動への敬意。これらを意識したコードを書くことこそが、プロダクトの寿命を延ばし、ユーザーに最高の体験を届けるプロフェッショナルの仕事である。次のコードレビューでは、動的な魔術に頼るのではなく、美しく堅牢な静的コードでチームを圧倒してほしい。