こんにちは！フロントエンドからNode.jsの深層まで、日夜JavaScriptと向き合っているシニアアーキテクトです。
JavaScriptを学び始めると、`let`や`const`といった変数の宣言方法や、関数が外側の変数にアクセスできる「クロージャ」という仕組みに出会いますよね。これらは非常に強力で便利な反面、「非同期処理」と組み合わせた途端に、意図せずメモリを消費し続ける（メモリリークを起こす）という罠に足を踏み入れてしまいがちです。
今回は、Promiseチェーンを使った非同期処理の中で変数がどのように生き残り、なぜメモリリークが起きるのか、そしてそれをどう防げばいいのかを、V8エンジンの裏側の動きも交えながら優しく紐解いていきましょう。ここをクリアすれば、JavaScriptのメモリ管理とスコープの基本はバッチリマスターできますよ！
—
1. 非同期処理とクロージャ：変数はどこへ消えるのか？
まずは、JavaScriptの非同期処理（Promise）が変数とどう関わっているのか、基本の形を確認してみましょう。
JavaScriptの世界では、関数が実行されるとき、その関数が生まれた環境（スコープ）を「バックパック」のように背負って持ち歩きます。これがクロージャの本質です。
次のコードを見てください。
// 重いデータ（巨大な配列）を生成する関数
function fetchUserData(userId) {
// この巨大なデータがスコープ内に存在します
const heavyData = new Array(10000000).fill(`ユーザー ${userId} の機密データ`);
return new Promise((resolve) => {
// 3秒後に非同期で処理を実行するタイマー
setTimeout(() => {
// ここで heavyData を参照している（クロージャの成立）
resolve(`取得完了: ${heavyData.length} 件のデータ`);
}, 3000);
});
}
// 処理を実行
fetchUserData(42).then((result) => {
console.log(result);
});
このコードでは、`fetchUserData`関数が呼ばれたときに作られた `heavyData` という巨大な変数が、3秒後の `setTimeout`（非同期処理）の完了を待つ間、ずっとメモリ上に保持され続けます。
なぜメモリに残り続けるのか？（V8エンジンの視点）
JavaScriptのエンジン（V8など）は、「この変数は将来的にまだ使われる可能性があるか？」を常に監視しています。
上記のコードでは、`setTimeout` のコールバック関数が `heavyData` を参照しているため、エンジンは「3秒間は、この `heavyData` をゴミ箱（ガベージコレクション）に捨ててはいけないな」と判断し、メモリ空間（ヒープ領域）に留め置きます。
非同期処理が無事に終われば、参照が断たれてメモリは解放されます。ここまでは正常な挙動です。
—
2. 陥りやすい罠：Promiseチェーン内でのメモリリーク
問題は、「非同期処理が終わらない」、あるいは「不要になったのに参照が残り続ける」というシチュエーションです。
初学者の方がよくやってしまう、典型的なメモリリークのパターンを覗いてみましょう。
// アプリケーション全体でデータを保持し続けるマネージャー的なオブジェクト
class DataManager {
constructor() {
this.cache = [];
}
loadAndCache(id) {
const hugePayload = new Array(5000000).fill(‘メモリを圧迫する巨大な文字列’);
return fetch(`https://api.example.com/item/${id}`)
.then(response => response.json())
.then(data => {
// うっかり、スコープ内の hugePayload をエラーログ等に含めてしまったとする
console.log(`アイテム取得成功:`, data);
// 【メモリリークの元凶】
// Promiseチェーンのスコープ（クロージャ）の中に hugePayload が存在し続けるため、
// この Promiseチェーン自体がどこかに保持されていると、hugePayload も消えない！
if (data.hasError) {
throw new Error(hugePayload[0]); // エラー時に参照保持が長引く
}
return data;
});
}
}
ここで恐ろしいのは、「Promiseチェーンが完了するまでの間、またはその参照がどこかに残り続けている間、チェイン内のスコープにある変数がすべてV8のメモリ上にロックされる」という点です。
もし、ユーザーがボタンを何度も連打してこの非同期処理を何十回も走らせたらどうなるでしょうか？ 解放されない巨大な配列がヒープ領域に積み重なり、タブがフリーズしたり、「JavaScript heap out of memory」という残酷なエラーと共にブラウザがクラッシュしたりします。これが非同期処理におけるメモリリークの正体です。
—
3. メモリリークを防ぐための適切なスコープ設計
では、どうすればこのメモリリークを防ぎ、クリーンなコードを書けるのでしょうか？
答えはシンプルです。「不要になった変数は、非同期のスコープ内に長く閉じ込めない」「必要なデータだけを最小限のスコープで渡す」ことです。
先ほどのリスクを回避した、洗練されたコードを見てみましょう。
// 改善版：スコープを最小限にし、不要な参照を残さない
function fetchUserDataSafely(userId) {
// 1. 巨大なデータは、非同期処理の「外」で無駄に宣言せず、
// 必要なタイミングで局所的に生成するか、すぐに参照を断つ工夫をする。
return apiCall(userId)
.then((response) => {
// レスポンスを受け取ったら、必要なデータだけを抽出し、
// 閉じたスコープ（クロージャ）の中に巨大なオブジェクトを持ち込まない。
const summary = {
id: response.id,
name: response.name
};
return summary;
})
.catch((error) => {
console.error(‘エラーが発生しました’, error.message);
// エラー時も巨大な変数をスコープ内に抱え込まないようにする
throw error;
});
}
// 模擬的なAPIコール関数
function apiCall(id) {
return Promise.resolve({ id: id, name: `ユーザー${id}` });
}
設計上の3大原則
1. スコープの寿命を短くする
変数を宣言する際は、なるべくその変数が使われるブロック（`{}`内）だけに閉じ込めましょう。`var`を使わず、ブロックスコープを持つ `let` や `const` を使うことは、意図しない変数共有を防ぐための第一歩です。
2. Promiseチェーンには「必要最小限のデータ」だけを流す
`.then()` の引数に渡す関数の中で、外側の巨大な変数を安易に参照（キャプチャ）しないように意識してください。データを引き渡すときは、プリミティブ型（文字列や数値）や、必要なプロパティだけに絞ったオブジェクトを渡すのが鉄則です。
3. キャンセル可能な非同期処理を取り入れる
現代のモダンな開発では、`AbortController` などの仕組みを使って、コンポーネントの破棄や画面遷移と同時に非同期通信そのものをキャンセルし、メモリとリソースを即座に解放するアプローチが標準的になっています。
—
まとめ
いかがでしたでしょうか？
- 非同期処理（PromiseやsetTimeout）のコールバックは、外側の変数を「クロージャ」として抱え込む。
- 非同期処理が完了するまで、その変数はV8エンジンのヒープメモリ上に保持され続ける。
- 不要な変数をクロージャ内に残してしまうと、メモリリークやアプリのパフォーマンス低下を招く。
- 対策として、変数のスコープを極力小さくし、必要なデータだけをチェーンに流す設計を心がける。
JavaScriptの非同期処理とメモリの関係性が頭の中で一本の線で繋がると、コードを書くときの視界が劇的にクリアになります。「あ、この書き方だとメモリに残り続けそうだな」と自分でコードの匂いを嗅ぎ取れるようになるはずです。
この基本さえ押さえておけば、どんなに複雑な非同期フローを構築しても、メモリリークに怯えることはもうありません。自信を持ってモダンなJavaScript開発を楽しんでいきましょう！