実行コンテキストを自作する：V8スコープチェーンの物理的実体を暴く
JavaScriptのエンジン――特にV8において、「スコープ」とは単なる抽象的な構文規則ではない。それはメモリ空間の管理であり、ポインタのチェーニングであり、さらにはJITコンパイラ（IgnitionとTurboFan）がインラインキャッシュ（Inline Caches）を構築するための物理的なアドレス解決メカニズムそのものである。
多くの開発者は `let` や `const`、クロージャについて「変数がどこからアクセスできるか」という高レイヤな文脈で語る。だが、シニアエンジニアやセキュリティ・リサーチの領域に踏み込むのであれば、実行コンテキスト（Execution Context）とLexical Environmentが、V8のヒープ上でどのように構築され、どのように探索されているのかをレイヤ下層から正確に把握していなければならない。
今回は、JavaScript自身を使って「簡易インタプリタ」を実装し、スコープチェーンの正体を完全に自作・再現する。その過程で、V8の内部挙動、隠しクラス（Hidden Classes / Maps）、さらにはスコープ構造の不備を突いたプロトタイプ汚染（Prototype Pollution）からRCEに至る攻撃の深層まで、ランタイムの防壁を貫く極限の知見を紐解いていく。
—
1. V8ランタイムにおける「実行コンテキスト」とスコープチェーンの物理構造
JavaScriptコードがV8エンジンに投入されると、ParserがAST（抽象構文木）を生成し、Bytecode GeneratorがIgnition用のバイトコードにコンパイルする。この過程で、変数や関数の宣言は静的に解析され、どのスコープ（Lexical Environment）に属すべきかが決定される。
実行時、関数が呼び出されるたびに実行コンテキスト（Execution Context）がコールスタックにプッシュされる。実行コンテキストの内部構造をC++（V8の内部実装）の概念で分解すると、主に以下の要素で構成されている。
1. LexicalEnvironment（語彙的環境）: `let`, `const`, 関数宣言などが束縛（Binding）される領域。
2. VariableEnvironment（変数環境）: `var` 宣言や関数宣言が巻き上げ（Hoisting）の文脈で格納される領域。
3. ThisBinding: `this` キーワードの参照先。
4. Outer Lexical Environment Reference（外部環境への参照）: これこそが「スコープチェーン」の正体である。
ある識別子（変数名）へのアクセスが発生した時、V8は現在のLexicalEnvironmentのEnvironment Recordを確認し、そこに存在しない場合は、`Outer Lexical Environment Reference`を辿って親の環境を再帰的に探索する。このポインタの鎖こそがスコープチェーンである。
これを言語仕様（ECMAScript Specification）およびV8のメモリモデルに忠実に、純粋なJavaScriptで完全に再現してみよう。
—
2. 実装：純粋なJavaScriptによる実行コンテキストとスコープチェーンのシミュレータ
以下のコードは、Environment Record、Lexical Environment、そしてコールスタックとしての実行コンテキストをオブジェクトモデルとして自作したインタプリタのコアである。変数のシャドーイング（Shadowing）やクロージャによる外側環境のキャプチャ（Closure / [[Environment]]）も完全に再現している。
/
- Environment Record (変数の実体を保持するストレージ)
/
class EnvironmentRecord {
constructor(parent = null) {
// 変数のバインディングを保持するハッシュマップ
// V8の辞書モードオブジェクトやプロパティアクセスの挙動を模倣
this.bindings = new Map();
// 外部環境への参照（スコープチェーンのリンク）
this.outer = parent;
}
/
- 変数を現在のスコープに定義する
/
define(name, value) {
if (this.bindings.has(name)) {
throw new SyntaxError(`Identifier ‘${name}’ has already been declared`);
}
this.bindings.set(name, { value, initialized: true });
}
/
- 変数の値を取得する（スコープチェーンを遡る）
/
get(name) {
if (this.bindings.has(name)) {
const binding = this.bindings.get(name);
if (!binding.initialized) {
// Temporal Dead Zone (TDZ) の検出
throw new ReferenceError(`Cannot access ‘${name}’ before initialization`);
}
return binding.value;
}
// 現在の環境に存在しない場合、スコープチェーンを辿る
if (this.outer !== null) {
return this.outer.get(name);
}
throw new ReferenceError(`${name} is not defined`);
}
/
- 変数の値を更新する（シャドーイングを考慮し、最も近いスコープを探す）
/
set(name, value) {
if (this.bindings.has(name)) {
const binding = this.bindings.get(name);
if (!binding.initialized) {
throw new ReferenceError(`Cannot access ‘${name}’ before initialization`);
}
binding.value = value;
return;
}
if (this.outer !== null) {
this.outer.set(name, value);
return;
}
throw new ReferenceError(`${name} is not defined`);
}
}
/
- 実行コンテキスト (Execution Context)
/
class ExecutionContext {
constructor(lexicalEnv, variableEnv) {
this.lexicalEnvironment = lexicalEnv;
this.variableEnvironment = variableEnv;
}
}
/
- 簡易インタプリタのエンジン本体
/
class MiniJSInterpreter {
constructor() {
// グローバルスコープの構築
this.globalEnv = new EnvironmentRecord(null);
this.executionStack = [];
// グローバルオブジェクトの初期化 (例: console.logの注入)
this.globalEnv.define(‘console’, {
log: (…args) => console.log(‘[Interpreter Output]:’, …args)
});
}
/
- スコープを作成して関数を実行するシミュレーション
/
executeFunction(fn, closureEnv, args) {
// 1. 関数のローカル環境を作成（親は「関数が定義された環境(closureEnv)」＝クロージャのメカニズム）
const localEnv = new EnvironmentRecord(closureEnv);
// 2. 引数をローカル環境にバインド
fn.params.forEach((paramName, index) => {
localEnv.define(paramName, args[index]);
});
// 3. 新しい実行コンテキストをスタックに積む
const context = new ExecutionContext(localEnv, localEnv);
this.executionStack.push(context);
try {
// 4. 関数本体のバイトコード（抽象化されたASTノード）を実行
let result = null;
for (const statement of fn.body) {
result = this.evaluate(statement, context);
}
return result;
} finally {
// 5. 実行終了後、コールスタックからポップ
this.executionStack.pop();
}
}
/
- 式や文を評価するディスパッチャ
/
evaluate(node, context) {
const currentEnv = context.lexicalEnvironment;
switch (node.type) {
case ‘VariableDeclaration’:
currentEnv.define(node.name, node.init ? this.evaluate(node.init, context) : undefined);
return;
case ‘Identifier’:
return currentEnv.get(node.name);
case ‘Literal’:
return node.value;
case ‘Assignment’:
currentEnv.set(node.name, this.evaluate(node.value, context));
return;
case ‘FunctionExpression’:
// クロージャとして親の環境(currentEnv)をキャプチャする
return {
type: ‘Function’,
params: node.params,
body: node.body,
closure: currentEnv // [[Environment]] 内部スロットの再現
};
case ‘CallExpression’:
const fnObj = this.evaluate(node.callee, context);
const evaluatedArgs = node.args.map(arg => this.evaluate(arg, context));
if (fnObj.type === ‘Function’) {
return this.executeFunction(fnObj, fnObj.closure, evaluatedArgs);
} else if (typeof fnObj === ‘function’) {
return fnObj(…evaluatedArgs);
}
throw new TypeError(‘Target is not a function’);
case ‘BlockStatement’:
// ブロックスコープ（let/constのブロック単位の隔離）の再現
const blockEnv = new EnvironmentRecord(currentEnv);
const blockContext = new ExecutionContext(blockEnv, currentEnv);
this.executionStack.push(blockContext);
try {
let lastVal = null;
for (const stmt of node.body) {
lastVal = this.evaluate(stmt, blockContext);
}
return lastVal;
} finally {
this.executionStack.pop();
}
default:
throw new Error(`Unknown AST node type: ${node.type}`);
}
}
}
このコードを動かすことで、JavaScriptエンジンがいかに厳密にスコープを管理しているかが視覚化できる。特筆すべきは、関数オブジェクトが生成された瞬間に `closure` プロパティ（ECMAScript仕様上の `[[Environment]]` 内部スロット）としてその時点での LexicalEnvironment への参照を包み込んでいる点である。これこそが、スコープ外に持ち出された後も変数が生存し続ける「クロージャ」の物理的実体である。
—
3. V8の最適化メカニズム：隠しクラス（Maps）とスコープ最適化の罠
ここで視点をV8エンジンの内部実装に戻す。私たちが日常的に書くスコープチェーンの探索は、そのままでは毎回ハッシュマップをルックアップするため、パフォーマンス上有利ではない。
V8は、実行速度を極限まで高めるために以下の最適化を施している。
1. 隠しクラス（Hidden Classes / Maps）とインラインキャッシュ（IC）
オブジェクトのプロパティアクセスにおいて、V8はオブジェクトの形状（プロパティのレイアウトとオフセット）を管理する「Map」を割り当てる。スコープチェーン上のオブジェクトやEnvironment Recordに対しても、V8はJITコンパイル時にオフセット（メモリ上の相対位置）をハードコードし、ハッシュマップの検索をバイパスする最適化を行う。
2. スコープのコンパイル時最適化とEscapes Analysis
もし変数がクロージャによってキャプチャされていない（外部関数から参照されない）ことが静的解析で判明した場合、V8はそれをヒープではなくコールスタック上のローカルスロットに配置する。さらに、”Escapes Analysis”（エスケープ解析）により、オブジェクトが関数外に漏出しないと判定されれば、ヒープアロケーションそのものを排除してレジスタやスタック上に展開する（Object Stacking）。
しかし、この最適化構造を狂わせるアンチパターンや、悪意あるコードがランタイムの防壁を突き破る脆弱性が存在するのがセキュリティの現実である。
—
4. セキュリティの深層：プロトタイプ汚染（Prototype Pollution）とサプライチェーンRCE
スコープチェーンやオブジェクトのプロパティ探索メカニズムの脆弱性を突いた代表例が、プロトタイプ汚染（Prototype Pollution）である。
JavaScriptのすべてのオブジェクトは、内部プロトタイプ `[[Prototype]]` （一般に `__proto__` または `Object.getPrototypeOf()`）を通じて親のプロパティを継承する。もし、このプロトタイプチェーンの根元（`Object.prototype`）が外部からの安全でない入力（ディープマージ関数やJSONの不安全なパース処理など）によって汚染された場合、アプリケーション全体のスコープやオブジェクト解決の挙動が歪められる。
脆弱なディープマージの例と、汚染が引き起こす連鎖
以下は、よくある脆弱な再帰的マージ関実装である。
// 脆弱なディープマージ関数（よくあるOSSライブラリのアンチパターン）
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;
}
攻撃者が以下のようなJSONペイロードをAPI経由で送信し、この関数に処理させたとしよう。
{
“__proto__”: {
“polluted”: “RCE_PAYLOAD_ACTIVE”,
“shellCommand”: “node -e ‘require(\”child_process\”).execSync(\”id\”)'”
}
}
`unsafeMerge({}, payload)` が実行された瞬間、`target.__proto__` は `{ polluted: ‘RCE_PAYLOAD_ACTIVE’, … }` に書き換わり、JavaScriptの全オブジェクトのプロトタイプが汚染される。
なぜこれがサプライチェーンにおけるRCE（リモートコード実行）に直結するのか？
大規模なNode.jsバックエンドアプリケーションでは、テンプレートエンジン（HandlebarsやEJSなど）、ODM（Mongoose）、あるいはルーティングライブラリが、内部設定やオプションオブジェクトを結合する際に `Object.prototype` を参照することが多々ある。
もしテンプレートエンジンが描画オプションを探索する際、次のようなコードを実行していたとする。
// テンプレートエンジンの内部処理の擬似コード
function render(template, options) {
// もし options に ‘shellCommand’ が明示的に渡されていなくても、
// Prototype Pollutionによって Object.prototype.shellCommand が存在してしまう
const cmd = options.shellCommand || template.defaultCommand;
if (cmd) {
// 危険なevalやchild_processの実行に繋がるロジック
return require(‘child_process’).execSync(cmd).toString();
}
return template.compile(options);
}
攻撃者は、アプリケーションコードが直接想定していないにもかかわらず、`Object.prototype` を経由してスコープチェーンの末端（グローバル汚染）から変数を「注入」し、V8のプロパティ探索メカニズムをハックして任意のコード実行（RCE）を達成してしまうのだ。
—
5. チーフアーキテクトが推す防壁：ランタイム防御とイミュータビリティの極意
この種のレイヤ深層を突く攻撃やメモリ・スコープの不整合を防ぐため、現代の堅牢なNode.js/フロントエンドアーキテクチャでは、言語ランタイムの防壁を以下のように構築する必要がある。
1. プロトタイプの凍結 (`Object.freeze`):
アプリケーション起動時に、コアとなるグローバルプロトタイプを凍結する。
Object.freeze(Object.prototype);
Object.freeze(Array.prototype);
Object.freeze(Function.prototype);
これにより、万が一脆弱なマージ関数が実行されても、`TypeError` が発生して汚染を防ぐことができる。
2. Nullプロトタイプオブジェクトの活用:
ハッシュマップや辞書データ構造としてオブジェクトを使用する場合、`Object.create(null)` を用いて `[[Prototype]]` を持たない（`__proto__` が存在しない）オブジェクトを強制する。
// プロトタイプチェーンを持たない純粋なハッシュマップ
const safeMap = Object.create(null);
safeMap[‘__proto__’] = ‘safe’; // 単なる独自のキーとして安全に処理される
3. 厳格なスキーマ検証（Zod / JSON Schema）:
外部から流入するすべての入力値に対し、実行時型チェックと未知のプロパティの厳格な排除（`strip` もしくは `strict` モード）を徹底し、不審なキー（`__proto__`, `constructor`, `prototype`）の混入をパースの段階でシャットアウトする。
—
結び
JavaScriptの「スコープ」や「変数解決」は、単なる文法上のルールではない。それはV8という超高速ランタイムがメモリ空間を効率的に支配するための緻密な物理メカニズムであり、同時に、一歩誤ればシステム全体を崩壊させる脆弱性の交差点でもある。
表層的なAPIの使い方に留まらず、言語のコンテキスト構造、メモリのチェーニング、そしてランタイムの防壁を深く理解したエンジニアこそが、真にセキュアで高パフォーマンスなモダンWebシステムを構築できる。コードの1行がV8のヒープとCPUキャッシュにどう影響するか、その感覚を常に研ぎ澄ませておいてほしい。