JavaScriptの実行コンテキストを自作する：インタプリタの仕組みから学ぶスコープチェーンの正体
JavaScriptのコードが1行実行されるとき、裏側で何が起きているか。`let`と`const`が導入されてから「変数の巻き上げ（Hoisting）やスコープは怖くない」という顔をする開発者が増えたが、V8エンジンのヒープメモリ空間やコールスタック、そしてレキシカル環境（Lexical Environment）の物理的な実体を正確に説明できる者は少ない。
世の中の入門書は「スコープとは変数の有効範囲です」と抽象的な概念でお茶を濁す。しかし、シニアエンジニアやランタイムの挙動に挑む者にとって、スコープとは「メモリ上の連鎖したオブジェクト構造であり、変数ルックアップコスト（O(n)の探索）を伴う動的なハッシュマップのリンクリスト」に他ならない。
本稿では、V8エンジンのECMAScript仕様に準拠した挙動を模倣するため、独自のスコープ管理オブジェクト（インタプリタ）を自作する。これにより、ネストされた関数が外側の変数を参照するクロージャのメカニズムと、その裏にあるパフォーマンスの代償を完全に解剖する。
—
1. 実行コンテキストとレキシカル環境の正体
JavaScriptエンジン（V8など）は、コードの評価（Evaluation）と実行（Execution）を行う際、実行コンテキスト（Execution Context）をコールスタックに積み上げる。実行コンテキストの内部には、主に以下の3つが存在する。
1. LexicalEnvironment（レキシカル環境）：変数宣言や関数宣言の位置（構文上のコンテキスト）を記録する。
2. VariableEnvironment（変数環境）：`var`宣言や関数宣言を保持する（レキシカル環境のサブセットだが、歴史的経緯で分離されている）。
3. ThisBinding：`this`キーワードの参照先。
レキシカル環境は、物理的には以下の2つの要素から構成される。
- Environment Record（環境レコード）: スコープ内の識別子（変数名や関数名）と値の対応を保持するハッシュマップ。
- Outer Lexical Environment Reference（外部レキシカル環境への参照）: 外側のスコープへのポインタ。これが連鎖することで、いわゆるスコープチェーンが形成される。
この構造を、生のJavaScriptオブジェクトを使って完全に自作してみよう。
—
2. 実装：自作インタプリタによるスコープチェーンの可視化
以下のコードは、ECMAScriptの仕様書（ES2020+）における環境レコードの振る舞いを模倣した、純粋なJavaScriptによるスコープチェイン管理システムである。変数を探索する際のコスト（ルックアップの深さ）を計測できるように設計している。
/
- 環境レコード（Environment Record）の模倣
- スコープごとの変数ストレージと外部スコープへのポインタを持つ
/
class EnvironmentRecord {
constructor(outer = null, name = ‘anonymous’) {
this.store = new Map(); // 変数を保持する高速ハッシュマップ
this.outer = outer; // 外側のレキシカル環境への参照（スコープチェーンの要）
this.name = name; // デバッグ用のスコープ名
}
/
- 変数を現在のスコープに定義する（ホイスティングや宣言に対応）
/
define(identifier, value) {
// 実際のV8ではここでTemporal Dead Zone (TDZ) のフラグ管理なども入る
this.store.set(identifier, value);
}
/
- スコープチェーンを遡りながら変数を探索する（O(n)のルックアップ）
- @param {string} identifier – 探す変数名
- @param {number} depth – 探索コスト（深さ）計測用
/
get(identifier, depth = 0) {
if (this.store.has(identifier)) {
return {
value: this.store.get(identifier),
resolvedScope: this.name,
cost: depth // スコープチェーンを何段階遡ったか
};
}
// 自前のスコープに存在しない場合、外側のスコープへ再帰的に委譲
if (this.outer !== null) {
return this.outer.get(identifier, depth + 1);
}
// グローバルスコープの端に達しても見つからない場合
throw new ReferenceError(`ReferenceError: ${identifier} is not defined`);
}
/
- 変数を書き換える（スコープチェーンを遡って最初にヒットしたものを更新）
/
set(identifier, value) {
if (this.store.has(identifier)) {
this.store.set(identifier, value);
return;
}
if (this.outer !== null) {
this.outer.set(identifier, value);
return;
}
throw new ReferenceError(`ReferenceError: ${identifier} is not defined`);
}
}
// — 検証：ネストされたスコープの構築と変数探索コストの測定 —
// 1. グローバルスコープの作成
const globalEnv = new EnvironmentRecord(null, ‘Global Scope’);
globalEnv.define(‘config’, { env: ‘production’ });
globalEnv.define(‘version’, ‘1.0.0’);
// 2. 関数スコープ（outer: Global）の作成
const functionEnv = new EnvironmentRecord(globalEnv, ‘Function Scope (getUser)’);
functionEnv.define(‘userId’, 42);
functionEnv.define(‘version’, ‘2.0.0’); // シャドーイング（外側の同名変数を隠す）
// 3. ブロックスコープ（outer: Function）の作成（if文やブロックなど）
const blockEnv = new EnvironmentRecord(functionEnv, ‘Block Scope (if-statement)’);
blockEnv.define(‘token’, ‘xyz-secret-token’);
// 【テストケース 1】ブロックスコープから直近の変数を引く（コスト 0）
console.log(‘— テスト 1: ローカル変数の参照 —‘);
console.log(blockEnv.get(‘token’));
// 出力: { value: ‘xyz-secret-token’, resolvedScope: ‘Block Scope (if-statement)’, cost: 0 }
// 【テストケース 2】ブロックスコープから1階層外の関数スコープの変数を引く（コスト 1）
console.log(‘\n— テスト 2: 1階層外の変数参照 —‘);
console.log(blockEnv.get(‘userId’));
// 出力: { value: 42, resolvedScope: ‘Function Scope (getUser)’, cost: 1 }
// 【テストケース 3】変数シャドーイングの検証（関数スコープの version が優先されるか）
console.log(‘\n— テスト 3: シャドーイングとスコープチェーンの優先順位 —‘);
console.log(blockEnv.get(‘version’));
// 出力: { value: ‘2.0.0’, resolvedScope: ‘Function Scope (getUser)’, cost: 1 }
// ※ globalEnv にもある ‘1.0.0’ ではなく、より近い functionEnv の ‘2.0.0’ がヒットする
このコードから明白なように、ネストが深くなればなるほど、`get()` メソッドが外側のポインタを辿る回数（`depth`）が増大する。これが「スコープチェーンの探索コスト」の本質である。
—
3. V8エンジンにおける最適化：なぜスコープチェーンのコストを意識すべきか
素朴なインタプリタであれば、上記のコードのように毎回ハッシュマップを線形探索（あるいはポインタのトラバーサル）することになる。しかし、現代のV8エンジンはJITコンパイラ（Sparkplug, Maglev, TurboFan）を備えており、この非効率な動的ルックアップを劇的に最適化している。
1. 隠しクラス（Hidden Classes / Maps）とインラインキャッシュ（IC）
V8はオブジェクトのプロパティアクセスを高速化するため、オブジェクトの構造を「隠しクラス」として管理する。しかし、スコープ（レキシカル環境）内の変数アクセスは、通常のオブジェクトプロパティとは異なり、クロージャや`eval`の存在によって動的に変化するため、最適化が難しい。
特に、`eval`や`with`文が存在すると、静的なスコープ解析（Lexical Scope Analysis）が破壊され、V8はコンパイル時の最適化を諦めて遅い動的ルックアップ（Sllo Mode）にフォールバックせざるを得なくなる。これが「`eval`を使うな」と言われる低レイヤの物理的理由である。
2. コンパイル時スコープ解析とコンテキスト割り当て（Context Allocation）
V8はコードをバイトコードにコンパイルする際、どの変数が「外側の関数から参照される（＝クロージャによってキャプチャされる）か」を静的に解析する。
- ローカル変数: ヒープではなく、スタックフレーム上に直接配置される（非常に高速）。
- キャプチャされた変数: ヒープ上に確保された「Context（コンテキストオブジェクト）」に割り当てられる。
ネストされた関数が外側の変数にアクセスする場合、スコープチェーンを毎回辿るのではなく、コンパイル時に確定した「コンテキストのインデックス（Slot Index）」を用いて、O(1)の配列アクセスに近い形で直接メモリからフェッチされる。
—
4. セキュリティの闇：プロトタイプ汚染とスコープチェインの脆弱性
スコープチェーンやオブジェクトのプロトタイプ機構は、JavaScriptの柔軟性を生み出す源泉であると同時に、サプライチェーン攻撃の最大の温床でもある。
悪意のあるパッケージが依存関係に混入した際によく使われるプロトタイプ汚染（Prototype Pollution）は、このオブジェクトのプロパティ探索機構の脆弱性を突く。
/
- 危険な再帰的マージ関数（よくある脆弱な実装）
/
function unsafeMerge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
unsafeMerge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
return target;
}
// 攻撃者がペイロードとして以下を送り込んだとする
const maliciousPayload = JSON.parse(‘{“__proto__”: {“polluted”: “RCE_PAYLOAD_ACTIVE”}}’);
const benignObject = {};
unsafeMerge(benignObject, maliciousPayload);
// Object.prototype が汚染される
console.log({}.polluted);
// 出力: ‘RCE_PAYLOAD_ACTIVE’
なぜこれが脅威なのか？
すべてのオブジェクトの根源である `Object.prototype` が汚染されると、アプリケーション内のあらゆるオブジェクトが、意図しないプロパティを継承することになる。
もしフレームワークやテンプレートエンジンが、オブジェクトのプロパティ存在確認（`hasOwnProperty` を使わずに `if (obj.someKey)` のような安全でないチェック）を行っている場合、制御フローが乗っ取られ、最終的にリモートコード実行（RCE）へと繋がる。
防御の要塞：ランタイムのハードニング
1. プロトタイプの凍結: アプリケーション起動時に `Object.freeze(Object.prototype)` を実行し、グローバルなプロトタイプロードを物理的に不変にする。
2. Null原型オブジェクトの使用: ハッシュマップや辞書データ構造を扱う際は、必ず `Object.create(null)` を使用し、原型チェーンを持たない（`__proto__`を持たない）純粋なコンテナを作成する。
// 安全な辞書オブジェクトの作成
const safeMap = Object.create(null);
safeMap[‘foo’] = ‘bar’;
console.log(safeMap.__proto__); // undefined (原型チェーンが存在しない)
—
5. 結び：シニアエンジニアが持つべき「ランタイムの目」
私たちが日常的に書く `const x = 10;` という何気ないコードの裏で、V8エンジンはレキシカル環境を構築し、スコープチェーンを張り巡らせ、JITコンパイルを通じてCPUのネイティブコードへと翻訳している。
「なぜこの書き方が遅いのか」「なぜこのパターンがメモリリーク（クロージャによる不要なコンテキストの保持）を引き起こすのか」。その答えは、言語仕様の表面ではなく、常に実行コンテキストとメモリ空間の物理的挙動のなかにある。
表面的なAPIの使い方を覚えるだけのエンジニアリングから脱却し、ランタイムの防壁の裏側までを完全に掌握した者だけが、真に堅牢で高速なモダンWebアプリケーションをアーキテクトできる。