コードレビューを思い出してほしい。「なぜこの変数参照で`ReferenceError`が出るのか」「なぜクロージャがメモリリークを引き起こすのか」。その答えの9割は、V8などのJavaScriptエンジンが内部で構築する「実行コンテキスト（Execution Context）」と「スコープチェーン（Scope Chain）」のメカニズムを正確に理解しているかで決まる。
ネット上の記事では「スコープとは変数の有効範囲です」といった表面的なお題目が並ぶが、シニアエンジニアを目指すなら、ランタイムがメモリ空間上でどのように識別子（Identifier）を解決しているのか、その実体をコードレベルで説明できなければならない。
今回は、JavaScriptのスコープチェーンの正体を暴くため、「JavaScript自身でスコープチェーンを解決する簡易インタプリタ」を実装する。このアプローチを取ることで、コードが実行された瞬間にエンジン内部で何が起きているのかが手に取るように理解できるようになる。
—
1. 実行コンテキストとスコープチェーンの正体
JavaScriptエンジン（V8など）がコードを評価・実行するとき、必ず「実行コンテキスト」という抽象的な箱が生成される。これには主に以下の3つが含まれている。
1. LexicalEnvironment（語彙的環境）: 変数や関数宣言のマップ（Environment Record）と、外側への参照（Outer Environment Reference）を持つ。
2. VariableEnvironment: `var`宣言や関数宣言を格納する場所（ES6以降はLexicalEnvironmentが主にその役割を兼ねる）。
3. ThisBinding: `this`の値。
このうち「外側への参照（Outer Environment Reference）」の鎖こそが、スコープチェーンの正体である。
ある変数にアクセスしようとした時、エンジンはまず現在のLexicalEnvironmentを調べる。そこに目当ての識別子がなければ、Outerが指す親のEnvironment Recordへと遡る。これをグローバル環境に達するまで繰り返し、見つからなければ`ReferenceError`を投げる。
この名前解決のアルゴリズムを、そのままJavaScriptのコードとして具現化してみよう。
—
2. 【ハンズオン】スコープチェーンを再現する簡易インタプリタの構築
以下のコードは、ネストしたスコープ構造、変数宣言、そして変数の参照（名前解決）をエミュレートするインタプリタのコア実装である。プロダクションコードではないが、V8の挙動を脳内トレースするための最強のメンタルモデルとなる。
/
- 環境（Environment）クラス
- V8の Environment Record と Outer Environment Reference の概念を再現
/
class Environment {
/
- @param {Environment | null} outer 親スコープへの参照（スコープチェーンの鎖）
/
constructor(outer = null) {
this.store = new Map(); // このスコープが保持する変数・定数のストレージ
this.outer = outer; // 外側への参照（これがスコープチェーンを形成する）
}
/
- 現在のスコープに変数を定義する
- @param {string} name 変数名
- @param {any} value 値
/
define(name, value) {
// 実際のJSの let/const のようなTDZ（一時的死地）の厳密な再現は省くが、
// 同一スコープ内での重複定義チェックなどをここに挟むのがコンパイラ設計の基本
this.store.set(name, value);
}
/
- スコープチェーンを辿って変数を検索する（名前解決の核心）
- @param {string} name 検索する変数名
- @returns {any} 解決された値
/
lookup(name) {
// 1. まず現在のスコープのストレージをチェック
if (this.store.has(name)) {
return this.store.get(name);
}
// 2. 現在のスコープに存在しない場合、親スコープ（outer）へ再帰的に委譲
if (this.outer !== null) {
return this.outer.lookup(name);
}
// 3. グローバルスコープに達しても見つからない場合はエラー
throw new ReferenceError(`[Runtime Error]: 識別子 ‘${name}’ が定義されていません。`);
}
/
- 既存の変数を再代入する（シャドーイングを考慮したスコープチェーンの走査）
- @param {string} name
- @param {any} value
/
assign(name, value) {
if (this.store.has(name)) {
this.store.set(name, value);
return;
}
if (this.outer !== null) {
this.outer.assign(name, value);
return;
}
throw new ReferenceError(`[Runtime Error]: 宣言されていない変数 ‘${name}’ への代入です。`);
}
}
// — 実行シミュレーション —
// 1. グローバル環境の構築
const globalEnv = new Environment(null);
globalEnv.define(‘appName’, ‘Enterprise Dashboard’);
globalEnv.define(‘version’, ‘1.0.0’);
// 2. 関数スコープ（例: ユーザー認証モジュール）の構築
const authEnv = new Environment(globalEnv); // outerにグローバルを指定
authEnv.define(‘currentUser’, ‘Alice’);
authEnv.define(‘isAdmin’, true);
// 3. さらに内側のブロック或いはクロージャスコープ（例: 権限チェック処理）の構築
const permissionEnv = new Environment(authEnv); // outerにauthEnvを指定
permissionEnv.define(‘requiredRole’, ‘admin’);
// — 動作検証 —
try {
console.log(‘— スコープチェーンの名前解決テスト —‘);
// ブロック内から自分のスコープにある変数を引く
console.log(permissionEnv.lookup(‘requiredRole’)); // 출력: ‘admin’
// ブロック内から親（authEnv）の変数を引く（スコープチェーンの遡り）
console.log(permissionEnv.lookup(‘currentUser’)); // 出力: ‘Alice’
// ブロック内から祖父母（globalEnv）の変数を引く
console.log(permissionEnv.lookup(‘appName’)); // 出力: ‘Enterprise Dashboard’
// 存在しない変数を引く -> ReferenceError
console.log(permissionEnv.lookup(‘secretKey’));
} catch (error) {
console.error(error.message);
}
このコードを実行すると、最も内側の `permissionEnv` から外側に向かって `outer` プロパティを伝い、`authEnv`、そして `globalEnv` へと名前解決の旅に出る様子が完璧に再現されていることがわかるはずだ。
—
3. なぜこれが実務のコードレビューで重要なのか？
「動くからいいや」でコードを書いていると、このスコープチェーンの仕組みを無視した実装によって、パフォーマンス低下やメモリリークを引き起こす。テクニカルリードとして現場でよく指摘する2つのアンチパターンを見ていこう。
アンチパターン A: 不必要なクロージャによるメモリの圧迫とV8ガベージコレクション
クロージャは「関数が作成された時点のLexicalEnvironment（外側への参照）」を保持し続ける。もし、グローバルに近いスコープの巨大なオブジェクトを、奥深くの小さな関数スコープから参照しっぱなしにすると、V8のガベージコレクタ（GC）はそのオブジェクトをメモリから解放できなくなる（メモリリーク）。
対策:
コンポーネントのライフサイクルやイベントリスナー内でスコープチェーンを意図せず引き伸ばさないこと。不要になった外部変数の参照は `null` を代入して切断するか、スコープの生存期間（Lifespan）を最小限に設計する。
アンチパターン B: スコープチェーンの深度とパフォーマンス
識別子の解決は、スコープチェーンの階層（depth）が深ければ深いほど、V8がメモリ上を遡るコスト（検索コスト）が増加する。
現代のJSエンジンは非常に高速（形状判定やインラインキャッシュなど最適化が働く）だが、何重にもネストした関数やブロック（例えば5階層以上の深いクロージャ）で頻繁に変数をルックアップするコードは、V8の最適化を阻害し、ホットパス（高頻度で実行される処理）でのボトルネックになり得る。
対策:
頻繁にアクセスする外部変数は、あらかじめローカルスコープの定数にキャッシュ（代入）してからループや高頻度処理を回す。
// 【非効率な例】ループのたびにスコープチェーンを深く遡ってグローバル/上位変数を引いている
function processItems(items) {
return items.map(item => {
// configは外側（親スコープ）にあると仮定
return item.price globalConfig.taxRate globalConfig.currencyMultiplier;
});
}
// 【堅牢な最適化例】スコープチェーンの探索コストを1回に抑える（ローカルキャッシュ）
function processItemsOptimized(items) {
// 頻繁に参照する上位スコープの変数をローカル変数に退避
const { taxRate, currencyMultiplier } = globalConfig;
return items.map(item => {
// ここからはローカル環境（即座に解決）を参照する
return item.price taxRate currencyMultiplier;
});
}
—
4. まとめ：コンパイラ的視点を持つフロントエンドエンジニアへ
変数宣言において `var` が廃れ、`let` と `const` が標準になり、ブロックレベルスコープが当たり前になった現代のモダンJS。しかし、その根底にある「実行コンテキスト」と「スコープチェーン」というV8の心臓部の仕組みは、JavaScriptが誕生した頃から何ら変わっていない。
「なぜここでエラーが出るのか」「この変数はどこから参照されているのか」に迷ったときは、頭の中で今回の `Environment` クラスのようなオブジェクトのツリー構造を思い浮かべてほしい。
コードの裏側にあるランタイムの挙動を解像度高く把握しているエンジニアだけが、バグの温床にならない堅牢で美しいアーキテクチャを構築できる。次のコードレビューでは、ぜひ「スコープチェーンの最適化」という視点をチームに持ち込んでみてほしい。