【実務・中級編】非同期処理とスコープ：Promiseチェーンにおける変数の共有とクロージャの罠 – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

エンジニアの皆さん、コードレビューをしていて「なぜか非同期処理のコールバック内で、ループの最後の値しか参照されない」「APIレスポンスを待つ間に変数が書き換わり、バグの温床になっている」といったコードに直面したことはないだろうか。

JavaScriptの非同期処理とスコープ、そしてクロージャのメカニズムを正確に理解していないと、プロダクション環境において再現性の低い致命的なバグを生むことになる。今回は、V8エンジンのメモリ空間やスコープチェーンの挙動にまで踏み込み、非同期処理における変数の共有とクロージャの罠を完全にハックする方法を伝授する。

—

1. なぜ非同期処理とスコープの組み合わせはバグを生むのか

JavaScriptはシングルスレッドで動作し、イベントループによって非同期処理を管理している。ここで多くのエンジニアが陥る罠が、「変数が定義された瞬間」と「非同期コールバックが実行される瞬間」の時間軸のズレだ。

V8エンジンの内部において、関数が実行されると実行コンテキスト（Execution Context）が生成され、その中にLexical Environment（字句環境）が作られる。クロージャはこの字句環境への参照を保持し続けるため、非同期処理が完了してコールバックが呼び出される時点ですでに、元の変数が別の値に書き換わっているという現象が起きる。

ありがちなアンチパターン：`var`が生む悲劇

まずは、よくある最悪のコードを見てみよう。

// 【アンチパターン】varによるループと非同期処理の組み合わせ
function processUserBad(users) {
for (var i = 0; i < users.length; i++) { // 意図：各ユーザーのデータを1秒後に非同期で取得して処理したい setTimeout(function() { console.log(`Processing user [${i}]:`, users[i].name); }, 1000); } } // 実行結果（usersの要素数が3の場合）： // 1秒後... // Processing user [3]: undefined // Processing user [3]: undefined // Processing user [3]: undefined なぜこうなるのか？
`var`は関数スコープを持つため、変数 `i` はループごとに新しく作られるわけではなく、関数スコープ（またはグローバルスコープ）全体でただ一つの変数が共有される。`for`ループが瞬時に回り切った時点で `i` の値は `3` になり、1秒後にタイマーが発火した時には、すべてのコールバックが「共有された `i`（＝3）」を参照してしまうのだ。結果として `users[3]` は存在せず、`undefined` となる。

—

2. 現代のJSにおける解決策：ブロックレベルスコープと即時実行関数（IIFE）

ES2015（ES6）で導入された `let` と `const` は、ブロックスコープ（`{}` ごとのスコープ）を提供する。これにより、V8エンジンはループのイテレーションごとに新しい変数のバインド（Lexical Environmentのインスタンス）を生成するようになった。

`let` によるクリーンな解決

先ほどのコードを `let` に書き換えるだけで、バグは消え去る。

// 【推奨アプローチ】letによるブロック単位のスコープ隔離
function processUserGood(users) {
for (let i = 0; i < users.length; i++) { // letにより、このブロック（ループの1回ごと）専用の i が独立して生成される setTimeout(() => {
console.log(`Processing user [${i}]:`, users[i].name);
}, 1000);
}
}

もしレガシーなコードベースで `var` を使わざるを得ない環境（あるいは古いNode.js環境）に遭遇した場合は、即時実行関数（IIFE）を用いてクロージャを強制的に作り、現在の `i` の値をローカル変数としてキャプチャする必要がある。

// 【レガシー環境向け】IIFEによるスコープの切り分け
function processUserLegacy(users) {
for (var i = 0; i < users.length; i++) { (function(currentIndex) { setTimeout(function() { console.log(`Processing user [${currentIndex}]:`, users[currentIndex].name); }, 1000); })(i); // 現在の i の値を引数で渡し、関数スコープ内に閉じる } } ---

3. 実務の現場で直面する「Promiseチェーンと変数の共有」

DOM操作や非同期API連携（Fetch API等）を組み合わせた実務的なコードでは、単なるループだけでなく、Promiseチェーンの途中で変数をいかに安全に引き回すかが設計のキモとなる。

以下のコードは、配列の要素を順番にAPIへ送信し、その結果を累積していく処理の「やってはいけない例」だ。

// 【アンチパターン】外側の変数へ副作用（サイドエフェクト）を与えている例
async function syncDataBad(items) {
let totalProcessed = 0; // 外部スコープの変数
let lastError = null;

const promises = items.map(async (item) => {
try {
const result = await apiCall(item);
// 非同期の完了順序や競合状態（Race Condition）により、
// totalProcessedのインクリメントが正しく同期されないリスクがある
totalProcessed++;
return result;
} catch (err) {
lastError = err; // どのエラーが最後なのか上書きされてしまう
throw err;
}
});

await Promise.all(promises);
return { totalProcessed, lastError };
}

なぜこの設計が脆弱なのか？

1. 競合状態（Race Condition）: `Promise.all` は並列実行されるため、複数の非同期処理がほぼ同時に `totalProcessed++` を書き換えると、メモリアクセスの競合により正確なカウントが失われる可能性がある（JavaScriptはシングルスレッドだが、非同期の挟み込みによって論理的な競合が起きる）。
2. 予測不可能な外部変数の書き換え: 関数内のどこからでもアクセスできるスコープに変数を置くと、コードの可読性が下がり、どの非同期処理がどのタイミングで値を変更したのか追跡不可能になる。

—

4. プロダクション品質の堅牢な設計パターン

非同期処理における変数の共有は、「共有状態を排除し、純粋関数とデータフローで繋ぐ」のが鉄則だ。

以下に、実務のフロントエンド開発やAPI連携でそのまま応用できる、保守性の高い堅牢なコードパターンを提示する。

/

  • 【プロダクションコード例】
  • 非同期処理における変数の共有を排除し、イミュータブルなデータフローを実現した設計

/

// ダミーの非同期API関数
const mockFetchApi = (item) => new Promise((resolve, reject) => {
setTimeout(() => {
if (item.fail) reject(new Error(`Failed for item: ${item.id}`));
else resolve({ id: item.id, status: ‘success’, timestamp: Date.now() });
}, 500);
});

/