JavaScriptの「黒魔術」を暴く！インタプリタ自作で紐解くスコープと変数宣言の深淵
皆さん、こんにちは！伝説のフルスタックチーフアーキテクト、そしてJavaScriptの奥深さをこよなく愛する先輩として、今日も皆さんの学習を全力でサポートさせていただきます。
JavaScriptを学び始めた皆さん、あるいは他の言語から来た皆さんにとって、「変数」の宣言や「スコープ」の概念は、ときに魔法のように感じられることはありませんか？特に`var`、`let`、`const`の使い分けや、いわゆる「巻き上げ（Hoisting）」といった現象は、最初は少し混乱しますよね。
でも、安心してください。今日は、それらの現象が一体なぜ起こるのか、JavaScriptの「心臓部」とも言えるインタプリタが内部でどのように動いているのかを、まるで私たちが簡易的なJavaScriptインタプリタを自作するかのようにシミュレーションしながら、その正体を徹底的に解き明かしていきます。
この記事を読み終える頃には、あなたは単に`var`、`let`、`const`を使えるだけでなく、その裏側で何が起きているのかを深く理解し、自信を持ってコードを書けるようになっているはずです。さあ、一緒にこの謎を解き明かす旅に出かけましょう！
—
目次
1. なぜ今さら「スコープ」と「変数宣言」なのか？
2. JavaScriptの「実行コンテキスト」とは何か？
3. インタプリタを自作する視点：Environment Recordの誕生
4. `var`の「巻き上げ」をインタプリタがどう処理するか
5. `let`と`const`の「ブロックレベルスコープ」と「TDZ」の正体
6. 実践！スコープチェーンと変数の解決メカニズム
7. V8の視点：メモリとパフォーマンスへの影響
8. まとめ：JavaScriptの基本を掌握したあなたへ
—
1. なぜ今さら「スコープ」と「変数宣言」なのか？
JavaScriptの基本的な文法である「変数の宣言」。`var`、`let`、`const`という3つのキーワードがあることはご存知ですよね。でも、これらを選び間違えると、意図しないバグの温床になったり、コードの保守性が著しく低下したりする可能性があるんです。
例えば、
- 「あれ？この変数、どこからでもアクセスできちゃうぞ？」
- 「なんでこの変数、宣言する前に使えてるのに`undefined`なんだ？」
- 「`let`で宣言したのに、なんで`ReferenceError`が出るんだろう？」
といった経験はありませんか？これらはすべて、JavaScriptのスコープと変数宣言のメカニズムを深く理解することで解決できる問題ばかりなんです。
表面的な知識だけでなく、その裏側にある「なぜそうなるのか」を理解することは、トラブルシューティングの能力を飛躍的に向上させ、より堅牢で高品質なコードを書くための土台となります。今日はその本質に迫っていきましょう。
2. JavaScriptの「実行コンテキスト」とは何か？
皆さんが書いたJavaScriptコードが実行されるとき、それは単に上から下に一行ずつ処理されているわけではありません。実は、コードは特定の「環境」の中で実行されています。この環境こそが、実行コンテキスト（Execution Context）と呼ばれるものです。
イメージとしては、JavaScriptのコードが実行されるたびに、そのコードのために「専用の作業部屋」が用意される、と考えてみてください。この作業部屋には、次のような重要な情報が収められています。
- Lexical Environment（レキシカル環境）: 変数や関数がどこに宣言されているか、つまり「スコープ」に関する情報が詰まった「設計図」のようなものです。
- Variable Environment（変数環境）: 基本的にはLexical Environmentと同じですが、`var`で宣言された変数や関数宣言の「巻き上げ」に関する初期設定は、このVariable Environmentで行われます。
- ThisBinding: その実行コンテキストにおける`this`が何を指すか、という情報です。
今日の主役は、この中のLexical Environment、そしてその中核をなすEnvironment Recordです。
Lexical Environment と Environment Record：変数を記憶する「箱」
JavaScriptのインタプリタがコードを読み込むとき、各実行コンテキスト（作業部屋）ごとに一つ、Lexical Environmentという「スコープの設計図」が作られます。そして、このLexical Environmentの中には、Environment Record（環境レコード）という特別な「変数を記憶する箱」が存在するんです。
イメージしてください。
- Environment Record: そのスコープ内で宣言されたすべての変数や関数が「名前」と「値」のペアとして登録される「辞書」や「棚」のようなもの。
- Outer Environment Reference: そのEnvironment Recordが、親となるLexical Environment（つまり、外側のスコープ）を指し示す「ポインタ」のようなもの。これによって、ネストされたスコープから外側のスコープの変数にアクセスできるようになります。これがスコープチェーンの基盤となります。
私たちが簡易インタプリタを「自作」するとしたら、このEnvironment Recordがどのように構築され、変数が登録・解決されていくかをシミュレーションすることになります。
3. インタプリタを自作する視点：Environment Recordの誕生
では、実際にJavaScriptのコードが実行される際、インタプリタが内部でEnvironment Recordをどう構築していくのか、そのプロセスを追体験してみましょう。
シミュレーションの準備：グローバル実行コンテキスト
皆さんのJavaScriptコードが最初に実行されるとき、まずグローバル実行コンテキスト（Global Execution Context）が作成されます。これは、プログラム全体を包括する一番外側の「作業部屋」ですね。
このグローバル実行コンテキストが作られると、当然、それに紐づくグローバルLexical Environmentが作られ、その中にグローバルEnvironment Recordが用意されます。
イメージはこんな感じです。
[グローバル実行コンテキスト]
|
+– [グローバルLexical Environment]
|
+– [グローバルEnvironment Record] <- ここにグローバル変数が登録される！
+-- [Outer Environment Reference] -> null (親はいない)
このグローバルEnvironment Recordは、まるで私たちのインタプリタが持っている「グローバル変数台帳」のようなもの。ここに`var`や関数宣言で定義された変数が登録されていきます。
4. `var`の「巻き上げ」をインタプリタがどう処理するか
さあ、いよいよ`var`の「巻き上げ」の秘密に迫ります。
インタプリタは、コードを実行する前に、まずそのコードを「解析（パース）」するフェーズを持っています。このパースフェーズで、`var`宣言と関数宣言は特別な扱いを受けるんです。
インタプリタの「パースフェーズ」シミュレーション
次のコードを見てみましょう。
console.log(myVar); // ①
var myVar = “Hello, JavaScript!”; // ②
console.log(myVar); // ③
皆さんはこのコードを実行するとどうなるか、ご存知ですよね？
// 実行結果:
// undefined
// Hello, JavaScript!
なぜ`①`の時点で`myVar`が`undefined`になるのでしょうか？「巻き上げ」という言葉は知っていても、その具体的な仕組みをインタプリタの視点から見ていきましょう。
1. インタプリタがコードを読み込む（パースフェーズ）:
インタプリタは、コードを実行する前に、まずファイル全体をスキャンします。このとき、`var`で宣言された変数と、`function`キーワードで宣言された関数を探し出します。
// インタプリタがコードをスキャン中…
// myVar が var で宣言されているのを発見！
// console.log はまだ実行しない。
2. Environment Recordへの登録:
`myVar`を発見すると、インタプリタは現在のLexical Environment（この場合はグローバルLexical Environment）のEnvironment Recordに、その変数の「名前」を登録します。このとき、値はまだ設定されていません。代わりに、JavaScriptの特殊な値である`undefined`が仮の初期値として設定されます。
// グローバルEnvironment Recordの状態（パースフェーズ終了時）
{
myVar: undefined, // ここで myVar が登録され、初期値 undefined が設定される！
// …他のグローバル変数や関数…
}
どうですか？この時点で`myVar`は`undefined`として存在しているのが分かりますね。これが「巻き上げ」の正体です。宣言自体はコードの先頭に「移動」したかのように振る舞いますが、初期値は`undefined`なんです。
3. インタプリタがコードを実行する（実行フェーズ）:
パースフェーズが終わると、いよいよコードが上から順に実行されます。
console.log(myVar); // ① myVar は既に Environment Record に undefined として存在するので、undefined が出力される。
var myVar = “Hello, JavaScript!”; // ② ここで myVar に “Hello, JavaScript!” が代入される。
// Environment Record の myVar の値が更新される。
// グローバルEnvironment Recordの状態（②実行後）
// {
// myVar: “Hello, JavaScript!”,
// // …
// }
console.log(myVar); // ③ myVar は “Hello, JavaScript!” なので、その値が出力される。
このように、`var`の巻き上げは、インタプリタがコードを「解析」する段階で、変数名だけを先にEnvironment Recordに登録し、初期値として`undefined`を設定することで実現されています。だから、宣言よりも前に変数名を知っていても、値はまだセットされていないので`undefined`になる、というわけですね。
V8の視点：`var`とヒープメモリ
少しだけV8エンジンの話にも触れておきましょう。V8は、このEnvironment Recordをメモリ上に「オブジェクト」として構築します。`var myVar = “…”`のような宣言は、グローバルオブジェクト（ブラウザなら`window`、Node.jsなら`global`）のプロパティとして、あるいは実行コンテキストに紐づくEnvironment Recordオブジェクトのプロパティとして、ヒープメモリ上に格納されます。
巻き上げの際、V8はコードをスキャンし、識別子（変数名）と、それがどのEnvironment Recordに属するかを特定します。そして、そのEnvironment Recordオブジェクトにプロパティとして`myVar: undefined`を追加するんです。これは、メモリ上に変数のための領域を確保し、初期値を書き込む作業に他なりません。このプロセスが、Webページの初期ロード時や関数呼び出し時に行われるため、不必要な変数宣言や大きなオブジェクトのグローバル宣言は、初期起動パフォーマンスに影響を与える可能性もあります。
5. `let`と`const`の「ブロックレベルスコープ」と「TDZ」の正体
ES2015（ES6）で導入された`let`と`const`は、`var`とは大きく異なる挙動を示します。特に重要なのが「ブロックレベルスコープ」と「TDZ（Temporal Dead Zone：一時的デッドゾーン）」です。
インタプリタの「ブロックレベルスコープ」シミュレーション
`let`と`const`は、`{}`（ブロック）で囲まれた範囲内でのみ有効なスコープを持ちます。これもインタプリタのEnvironment Recordの構築方法と密接に関わっています。
次のコードを見てください。
{
let blockVar = “I’m in a block!”;
const blockConst = 123;
console.log(blockVar);
console.log(blockConst);
}
console.log(blockVar); // ここはどうなる？
皆さんがお察しの通り、最後の`console.log(blockVar);`は`ReferenceError`になりますよね。なぜでしょう？
1. ブロックの発見と新たなLexical Environmentの生成:
インタプリタが`{}`ブロックを発見すると、そのブロックのために新しいLexical Environmentを生成します。この新しいLexical Environmentは、親のLexical Environment（この場合はグローバルLexical Environment）をOuter Environment Referenceとして参照します。
[グローバル実行コンテキスト]
|
+– [グローバルLexical Environment]
|
+– [グローバルEnvironment Record]
+– [Outer Environment Reference] -> null
|
V
[ブロックのLexical Environment] <- ブロックが始まったときに生成！
|
+-- [ブロックEnvironment Record] <- ここに let/const 変数が登録される！
+-- [Outer Environment Reference] -> グローバルLexical Environment
このように、ブロックごとに専用のEnvironment Recordが用意されるため、そのブロック内で宣言された`let`/`const`変数は、そのブロックのEnvironment Recordにのみ登録され、ブロックの外からは見えなくなるんです。
TDZ（Temporal Dead Zone）の正体
`let`や`const`には、`var`のような巻き上げはありません。しかし、宣言されたスコープの先頭から、実際に宣言文が実行されるまでの間、その変数にはアクセスできません。この期間をTDZ（Temporal Dead Zone：一時的デッドゾーン）と呼びます。
次のコードでシミュレーションしてみましょう。
console.log(tdzVar); // ①
let tdzVar = “Hello from TDZ!”; // ②
console.log(tdzVar); // ③
このコードは、`①`の行で`ReferenceError`になりますよね。
1. インタプリタのパースフェーズ:
`var`と同様に、インタプリタはコードをスキャンします。`let`や`const`で宣言された変数も見つけますが、`var`のようにすぐに`undefined`でEnvironment Recordに登録するわけではありません。
`let`や`const`変数は、そのスコープのEnvironment Recordには「存在している」とマークされますが、まだ「初期化されていない（uninitialized）」状態として管理されます。この「初期化されていない」状態の変数にアクセスしようとすると、`ReferenceError`が発生するようにインタプリタは設計されています。この状態がTDZの正体です。
// グローバルEnvironment Recordの状態（パースフェーズ終了時、TDZの状態）
{
// …他の変数…
tdzVar:
}
2. インタプリタの実行フェーズ:
console.log(tdzVar); // ① 環境レコードに tdzVar は存在するが、
// ここで処理が中断されます。
もし`①`でエラーにならなかったら、`②`の行で`tdzVar`が初期化され、`”Hello from TDZ!”`が代入されます。この時点から`tdzVar`にアクセスできるようになるわけです。
このように、`let`と`const`は、`var`の曖昧な挙動（宣言前の`undefined`アクセス）をなくし、より厳密な変数管理を可能にしています。宣言前にアクセスさせないことで、予期せぬバグを防ぎ、コードの健全性を高めることを目的としているんですね。
V8の視点：`let`/`const`とヒープメモリ、レンダリングパイプライン
`let`や`const`も同様に、V8エンジンはEnvironment Recordオブジェクトをヒープメモリに構築し、そこに変数情報を格納します。しかし、TDZの管理は異なります。V8は、`let`/`const`変数が宣言されるまでは、そのメモリ領域を「初期化されていない」状態として内部的にマークします。アクセスがあった場合、このマークをチェックして、初期化前であれば`ReferenceError`をスローします。
これは単なる文法の違いだけでなく、V8のJITコンパイル（Just-In-Time Compilation）や最適化にも影響を与えます。`let`/`const`による厳密なスコープは、V8が変数の生存期間をより正確に推論しやすくなり、結果としてメモリ管理（ガベージコレクション）の効率化や、より最適化された機械語の生成に繋がることがあります。
また、フロントエンド開発においては、大量のDOM操作やイベントハンドラの登録時に、`let`や`const`で適切にスコープを区切ることで、メモリリークのリスクを減らし、レンダリングパイプライン全体のパフォーマンス向上に寄与します。例えば、ループ内で大量の要素にイベントリスナーを貼る際に`var`を使うと、意図せず変数が共有されてしまい、参照が残り続けることでガベージコレクションの妨げになる可能性があります。`let`を使えば、ループのイテレーションごとに新しいスコープが作られ、不要になった変数は適切に解放されやすくなるわけです。
6. 実践！スコープチェーンと変数の解決メカニズム
これまで、インタプリタがEnvironment Recordをどう構築するかを見てきました。では、変数を参照するとき、インタプリタはどのようにしてその変数を見つけるのでしょうか？これがスコープチェーンのメカニズムです。
インタプリタの「変数解決」シミュレーション
次のコードは、関数がネストしている典型的な例です。
const globalName = “世界”;
function outerFunction() {
const outerName = “地球”;
function innerFunction() {
const innerName = “日本”;
console.log(`${innerName}、${outerName}、${globalName}`); // ①
}
innerFunction();
}
outerFunction();
`①`の行で、インタプリタはどのようにして`innerName`、`outerName`、`globalName`を見つけるのでしょうか？
1. `innerFunction`の実行コンテキスト生成:
`innerFunction`が呼び出されると、新しいFunction Execution Contextが作られます。これには、`innerFunction`専用のLexical Environmentとその中のEnvironment Recordが含まれます。
// innerFunctionのEnvironment Record
{
innerName: “日本”,
// …
}
// Outer Environment Reference は outerFunction の Lexical Environment を指す
2. 変数を探す旅の始まり:
`console.log`が実行され、インタプリタは`innerName`を探します。
- ステップ1: まず、現在のLexical Environment（`innerFunction`のLexical Environment）のEnvironment Recordを探します。
- 「あった！`innerName`は`”日本”`だ！」
- ステップ2: 次に`outerName`を探します。現在のEnvironment Recordにはありません。
- インタプリタは、`innerFunction`のLexical Environmentが持つOuter Environment Referenceを辿り、親である`outerFunction`のLexical Environmentに移動します。
- `outerFunction`のEnvironment Recordを探します。
- 「あった！`outerName`は`”地球”`だ！」
- ステップ3: 最後に`globalName`を探します。現在の`outerFunction`のEnvironment Recordにはありません。
- インタプリタは、`outerFunction`のLexical Environmentが持つOuter Environment Referenceを辿り、親である`グローバルLexical Environment`に移動します。
- `グローバルEnvironment Record`を探します。
- 「あった！`globalName`は`”世界”`だ！」
この「現在のEnvironment Recordになければ、Outer Environment Referenceを辿って親のEnvironment Recordを探しに行く」という連鎖的な仕組みこそが、スコープチェーンなんです。この鎖は、一番外側のグローバルEnvironment Recordにたどり着くまで続きます。もしグローバルEnvironment Recordにも変数がなければ、そこで初めて`ReferenceError`がスローされるわけです。
V8の視点：スコープチェーンとパフォーマンス
V8エンジンにとって、このスコープチェーンの解決は非常に重要なプロセスです。変数を参照するたびにチェーンを辿るのはコストがかかるため、V8は様々な最適化を行います。
例えば、関数のクロージャ（外側のスコープの変数を参照する関数）を分析し、どの変数がどのスコープから参照されるかを事前に把握します。これにより、頻繁にアクセスされる変数は、スコープチェーンを深く辿らずに直接アクセスできるような最適化を施すことがあります。
もしスコープチェーンが非常に長く、深いネスト構造になっている場合、変数の解決には時間がかかり、パフォーマンスに悪影響を与える可能性があります。そのため、必要以上に深いネストは避け、変数が必要なスコープに近い場所で宣言することが、コードの可読性だけでなく、実行効率の面からも推奨されるわけです。
7. V8の視点：メモリとパフォーマンスへの影響
私たちがここまで見てきたEnvironment Recordの構築やスコープチェーンの解決は、すべてV8エンジンの内部で行われ、メモリ資源を消費します。
- Environment Recordのオブジェクト化: 各実行コンテキストやブロックが作られるたびに、V8はヒープメモリ上にEnvironment Recordを表すオブジェクトを生成します。そのオブジェクトの中に、変数名と値のペアがプロパティとして格納されます。
- メモリ管理（ガベージコレクション）: 変数がスコープから外れ、もうどこからも参照されなくなったとき、V8のガベージコレクタがそのEnvironment Recordオブジェクトや変数自体が占めていたメモリを解放します。`let`や`const`によるブロックレベルスコープは、変数の生存期間を短く明確にするため、ガベージコレクションがより効率的に行われやすくなります。
例えば、大きなデータを持つ変数を関数内で`let`で宣言すれば、関数実行が終わるとその変数はスコープから外れ、メモリがすぐに解放されやすくなります。もし`var`でグローバルに宣言してしまうと、プログラムが終了するまでメモリに残り続けることになり、不必要なメモリ消費につながる可能性があります。
- JITコンパイルと最適化: V8はJavaScriptコードを直接実行するのではなく、高速な機械語にコンパイルして実行します（JITコンパイル）。スコープの構造が明確であるほど、V8はどの変数がどこからアクセスされるかを予測しやすくなり、より効率的な機械語を生成できます。これは、コードの実行速度に直結します。
私たちが書く一行のコードが、V8エンジンの内部でこのような複雑なプロセスを経て、ヒープメモリを確保したり解放したりしている、ということを知ると、より「重み」を感じませんか？適切な変数宣言とスコープ設計は、単にバグを防ぐだけでなく、アプリケーション全体のメモリ効率やパフォーマンスにも大きく貢献する、ということをぜひ覚えておいてください。
8. まとめ：JavaScriptの基本を掌握したあなたへ
皆さん、お疲れ様でした！今日は、普段私たちが何気なく使っている`var`、`let`、`const`の裏側にある、JavaScriptインタプリタの深淵なメカニズムを、インタプリタを自作する視点からシミュレーションしてきました。
- 実行コンテキストとLexical Environment、そしてEnvironment Recordが、変数や関数を管理する「台帳」であることを理解しました。
- `var`の巻き上げが、インタプリタの「パースフェーズ」で変数名が`undefined`としてEnvironment Recordに登録されることで起こる現象であることを知りました。
- `let`と`const`がブロックレベルスコープを持ち、宣言されるまではTDZ（Temporal Dead Zone）という状態でアクセスを拒否し、より厳密な変数管理を実現していることを確認しました。
- スコープチェーンが、変数を解決するためにインタプリタがEnvironment Recordを辿る仕組みであることを学びました。
- そして、これらの内部挙動が、実際のV8エンジンのメモリ管理やパフォーマンスにどのように影響するのか、その片鱗にも触れることができました。
これからは、コードを読み書きする際に、頭の中で「インタプリタは今、この変数をどのEnvironment Recordに登録しようとしているだろう？」「この変数を参照するとき、スコープチェーンをどう辿るだろう？」と、インタプリタの視点で考えてみてください。
この視点を持つことで、JavaScriptの挙動がよりクリアに見えるようになり、未解決のバグが起こった際にも、その原因を深く掘り下げて特定できるようになるはずです。
`var`、`let`、`const`の使い分けも、もはや単なるルールではなく、その裏にある深い理由を理解した上で選択できるようになったのではないでしょうか。
ここをクリアすれば、JavaScriptの基本はバッチリマスターできますよ！今日の学びを活かして、さらに一段上のJavaScriptエンジニアを目指していきましょう。これからも皆さんの学習を全力で応援しています！