こんにちは！JavaScriptの世界へようこそ。
フロントエンドの裏側からNode.jsのランタイムまで、日々JavaScriptと向き合っていると、「動くけれど、なぜかメモリがじわじわと削られていく……」という不気味な現象に出会うことがあります。
今回は、多くの開発者が一度はハマる「クロージャとスコープチェーンが引き起こすメモリリークの罠」について、V8エンジンのメモリ空間の動きまで一歩踏み込んで、優しく、そして深く解説していきますね。
ここをクリアすれば、変数スコープやメモリ管理の本質がグッと見えてきます。さあ、一緒にJavaScriptの深淵を覗いてみましょう！
—
1. 変数の歴史と「スコープ」の基本をおさらいしよう
私たちが普段何気なく使っている `let` や `const` ですが、これらはJavaScriptの歴史において比較的新しい機能（ES2015で導入）です。それ以前の時代は、変数宣言といえば `var` 一択でした。
まずは、この `var` と `let` の「スコープ（変数の有効範囲）」の違いを整理しておきましょう。
- `var`（関数スコープ）: 変数が宣言された「関数」の中全体で有効になります。もし関数外で宣言されればグローバルスコープになります。
- `let` / `const`（ブロックスコープ）: 変数が宣言された「最も近い `{}`（ブロック）」の中だけで有効になります。
この「スコープの広さ」の違いが、実はメモリ管理（ガベージコレクション：GC）に絶大な影響を与えるんです。
—
2. クロージャとは何か？ そして、なぜメモリを保持し続けるのか
「クロージャ（Closure）」という言葉、聞いたことはありますか？
一言で言えば、「外側のスコープの変数にアクセスし続けられる内側の関数」のことです。
JavaScriptでは、関数もオブジェクトの一つです。関数が作成されるとき、その関数は自分が生まれた環境（スコープチェーン）への参照をこっそり背負い込みます。
ちょっとコードを見てみましょう。
function createCounter() {
let count = 0; // 外側のスコープの変数
return function() {
count++; // 内側の関数から外側の変数を参照（クロージャ）
console.log(count);
};
}
const counter = createCounter();
counter(); // 1
counter(); // 2
`createCounter` の実行が終わった後も、返された無名関数が `count` 変数を覚えている（参照し続けている）のがクロージャの魔法です。
通常、関数が終われば中の変数は不要になり、V8エンジンのガベージコレクタ（GC）がメモリからキレイに消し去ってくれます。しかし、クロージャが存在すると、「まだ後から使われるかもしれない」と判断され、その変数はメモリ上に保持され続けます。これがクロージャの強力さであり、同時にメモリリークの温床になる理由です。
—
3. 【閲覧注意】`var` が引き起こしていた「循環参照とメモリリーク」の罠
さて、ここからが本題です。かつての `var` の仕様が、どのように厄介なメモリリークを引き起こしていたのかを見てみましょう。
`var` は「関数スコープ」です。つまり、同じ関数内や同じブロックレベルであっても、不必要に広いスコープに変数が残り続けます。
以下のコードを見てください。
function setupLeak() {
var largeData = new Array(10000000).fill(‘💥 メモリを食う巨大なデータ’); // 巨大な配列
// DOM要素のイベントリスナーにクロージャを登録
var button = document.getElementById(‘myButton’);
button.addEventListener(‘click’, function() {
// この無名関数は click イベントでのみ使われるはずだが…
console.log(‘ボタンが押されました’);
// 実はこの中では largeData を使っていない！
});
// 万が一、ここで何らかの理由により大元のスコープで
//別のクロージャが別の変数を巻き込んで参照を持ち続けてしまうと…
}
V8エンジンの内部で何が起きているのか？
`var` で宣言された `largeData` は、`setupLeak` 関数全体のスコープに属します。
V8エンジンのクロージャ最適化において、古い `var` の実装や複雑なスコープチェーンでは、「そのスコープ内で宣言されたすべての変数が、同じスコープを共有するクロージャから参照される可能性がある」とみなされ、使っていないはずの `largeData` までがクロージャの「環境（Context）」の一部として丸ごとメモリに保持されてしまうケースがありました。
これが複雑に絡み合い、DOM要素とJavaScriptのオブジェクトがお互いを参照し続ける（循環参照）と、ガベージコレクタは「まだ必要かもしれない」と判断し、メモリが解放されなくなります。これが JavaScriptにおけるメモリリークの正体 です。
—
4. モダンな `let` は、なぜこの罠を解決できるのか？
では、私たちが普段使っている `let` や `const` は、この問題をどうスマートに解決してくれるのでしょうか？
答えは 「ブロック単位での厳密なスコープ（Lexical Environment）の切り分け」 にあります。
function setupSafe() {
// ブロックスコープ 1
{
let largeData = new Array(10000000).fill(‘✨ 安全なデータ’);
// largeData はこのブロックの中だけで生きる
doSomethingWith(largeData);
} // ← このブロックを抜けた瞬間、largeData のスコープは消滅する！
const button = document.getElementById(‘myButton’);
button.addEventListener(‘click’, function() {
console.log(‘ボタンが押されました（largeDataには一切触れない）’);
});
}
V8エンジンのランタイム最適化
モダンなV8エンジンは非常に賢いです。
`let` や `const` を使うことで、変数の寿命（ライフサイクル）とスコープの境界が明確になります。
V8のコンパイラは、内側の関数（イベントリスナーなど）が「本当に外側の変数を必要としているか（参照しているか）」を静的解析します。もし参照していなければ、その変数はクロージャのコンテキストから完全に切り離され（Excision）、ブロックスコープの終了と同時にV8のヒープ領域（Heap）からガベージコレクションによって即座に回収されます。
つまり、「不要になった変数を、不要になったタイミングで確実にメモリから消せる」ようになったのです。これが、`let` がもたらした最大の恩恵の一つです。
—
5. 現場で使える！メモリリークを防ぐための実践的プラクティス
最後に、実務の現場で絶対に知っておくべき、メモリリークを防ぐためのマインドセットとコードの書き方をシェアしますね。
1. `var` は使わない、絶対に
現代のJavaScript開発において `var` を使う理由はもはやありません。常に `const` を基本とし、再代入が必要な場合のみ `let` を使いましょう。これだけで不要な関数スコープによるメモリの居座りを防げます。
2. イベントリスナーやタイマーのクリーンアップを忘れない
DOM要素にイベントを登録したり、`setInterval` を仕掛けたりすると、それが強力な参照（Strong Reference）となり、ガベージコレクションの邪魔をします。不要になったら必ず `removeEventListener` や `clearInterval` で参照を断ち切りましょう。
3. 不要になった大きなデータは明示的に参照を断つ
どうしても長期間生きるクロージャやオブジェクトの中で一時的に大きなデータを扱った場合は、処理の終わりに `largeData = null` のように明示的に代入して、V8に「もうこのメモリ要りませんよ」とシグナルを送るのも有効なテクニックです。
—
まとめ
いかがでしたでしょうか？
今回は、クロージャの仕組みと、`var` から `let` への進化がV8エンジンのメモリ管理にどう影響しているのかを深掘りしました。
- クロージャは強力だが、スコープ内の変数をメモリに保持し続ける性質がある。
- 古い `var` はスコープが広すぎるゆえに、使っていない変数まで巻き込んでメモリリークを引き起こしやすかった。
- モダンな `let` / `const` はブロックスコープによって変数の寿命を極限まで絞り込み、V8のガベージコレクションを最高に効率化してくれる。
仕組みの本質を知っていれば、もうメモリリークを恐れる必要はありません。
自信を持って、美しいモダンなJavaScriptコードを書いていきましょう！バッチリマスターできましたね！