【実務・中級編】クロージャとスコープの保持 – JavaScript実践ガイド

フロントエンドの現場でコードを書いていると、ふとした瞬間に「なぜこの変数の値が、スコープを抜けた後も生きているんだ？」と混乱することはないだろうか。特に、Reactの`useEffect`のクリーンアップ関数や、非同期処理の連鎖の中でクロージャの挙動に足をすくわれる経験は、誰もが一度は通る道だ。

今日は、教科書的な「関数がスコープを記憶する」という説明を一段掘り下げて、ブラウザの裏側で何が起きているのか、そして実務でどうこの「生存戦略」を操るべきかを紐解いていく。

—

JavaScriptのエンジン（V8など）は、関数が作成されるたびに「その関数が生まれた場所（スコープ）」への参照を、`[[Environment]]`という内部プロパティにひっそりと隠し持たせる。

これがクロージャの正体だ。普通、関数が実行を終えればローカル変数はガベージコレクション（GC）の対象になる。しかし、「そのスコープを外部から参照している関数」が一つでも存在する場合、JavaScriptエンジンは「まだこいつは必要だ」と判断し、メモリから消さずに保持し続ける。

この「メモリをあえて解放しない」という行為こそが、クロージャの本質的なコストであり、強力な武器なんだ。

中級エンジニアがまずマスターすべきは、外部から直接書き換えられたくない変数を、クロージャで「隠蔽（カプセル化）」するテクニックだ。

/
function createCounter(initialValue) {
let count = initialValue; // この変数はクロージャによって保護される

return {
increment: () => ++count,
decrement: () => –count,
getCount: () => count, // 読み取り専用のゲートウェイ
};
}

const myCounter = createCounter(10);

console.log(myCounter.increment()); // 11
console.log(myCounter.getCount()); // 11
// myCounter.count に直接アクセスしても undefined になる（ガードされている）

このコードのポイントは、`createCounter`が終了しても、返された3つの関数が`count`への参照を持ち続けている点にある。これにより、Reactの`useState`に近いような「状態の保持」をバニラJSで自作できるわけだ。

—

クロージャは強力だが、使いすぎるとメモリリークを招く。特に、DOM要素を頻繁に生成・削除するSPAでは要注意だ。

例えば、大きなオブジェクトをスコープ内で保持したまま、そのクロージャをずっと生き残るイベントリスナーに紐付け続けると、GCは二度とそのオブジェクトを回収できない。

現場での鉄則：

不要になったら参照を断つ：大規模なデータを保持したクロージャを使い終わったら、変数を`null`にするか、イベントリスナーを適切に`removeEventListener`する。
「無駄に」クロージャを作らない：単純なデータ受け渡しなら、わざわざ高階関数を使わず、プレーンなオブジェクトやクラスを使う方がメモリ効率が良い場合も多い。

—

クロージャを理解することは、JavaScriptの「メモリ管理の仕組み」を理解することと同義だ。

スコープの生存期間を意識する：今自分が書いている関数は、親のスコープをどこまで引きずっているのか？
意図的に隠蔽する：グローバル変数を減らすために、あえてクロージャでスコープを区切る。
非同期処理での罠を避ける：`setTimeout`や`Promise`内でクロージャを使うとき、変数の参照先が「ループの最後」になっていないか常に確認する。（`var`ではなく`let`を使うべき理由はまさにここにある）

クロージャは決して「難解な仕様」ではなく、「スコープを自在に操作するための道具」だ。
次にコードを書くとき、「この変数は誰が参照しているのか？」「この関数はいつまで生きるべきなのか？」を少し意識するだけで、バグの温床となるメモリリークや意図しない値の書き換えは劇的に減るはずだ。

現場のコードは、こうした「目に見えないメモリの生存戦略」の積み重ねでできている。ぜひ、今日から自分の書く関数を「ただの処理の塊」ではなく「状態を抱える生命体」として捉えてみてほしい。それが、シニアエンジニアへの第一歩だ。