こんにちは。プロジェクトのテクニカルリードだ。
今日のコードレビューで、また「なんとなく`var`や`final`を使い、クロージャの中でループ変数をそのままキャプチャしてバグらせたコード」を見かけた。
フロントエンド開発や非同期API連携で、状態管理やイベントハンドラを組み立てる際、スコープとクロージャの挙動を理解していないと、「なぜか最新の値ではなくループ最終時の値がすべてのコールバックに渡る」「不要なオブジェクトがメモリに居座り続け、GC（ガベージコレクション）が圧迫される」といった、プロダクションで致命傷になるバグを踏むことになる。
今日は、Dart VMが変数をどう扱い、クロージャがメモリ上でどう振る舞うのか。その「コンパイラとランタイムの裏側」まで踏み込んで、堅牢で美しい設計パターンを伝授しよう。
—
1. Dartの変数スコープとメモリ寿命の基本
Dartはレキシカルスコープ（静的スコープ）を採用する言語だ。変数の寿命（Lifespan）は、それが宣言されたブロック（`{}`）の境界によって厳密に決定される。
しかし、ここで意識しなければならないのは、「ブロックを抜けても、メモリから即座に消えない例外ケースがある」という点だ。それがクロージャによる変数のキャプチャ（捕捉）である。
なぜクロージャは変数を保持できるのか？
関数が別の関数を返す、あるいはオブジェクトの外部スコープの変数を参照する場合、Dart VMはその変数を単なるスタック上のローカル変数としては扱えなくなる。スタックフレームは関数がリターンした瞬間に破棄されてしまうからだ。
そのため、Dartコンパイラ（およびVM）は、クロージャから参照されるローカル変数を検出すると、自動的にその変数をヒープ上の「Context（コンテキスト）オブジェクト」へと昇格（ボックス化）させる。
[通常時] ローカル変数 -> スタック領域に存在（関数終了時に消滅）
[キャプチャ時] 変数 -> ヒープ上の Context オブジェクトに移動（参照がなくなるまで生存）
この仕組みを知っていれば、「この軽い気持ちで書いたクロージャのせいで、巨大なデータ構造のメモリ寿命が意図せず延びている」という非効率な設計に気づけるはずだ。
—
2. 実務で頻出：ループとクロージャの罠
次のコードを見てほしい。UIのリストアイテムや、非同期で連続するAPIリクエストのコールバックを動的に生成する際によくあるミスだ。
// 【アンチパターン】ループ内クロージャのキャプチャ問題
List
var actions =
for (var i = 0; i < 3; i++) { // ⚠️ 危険：変数 i はループの外側（またはスコープ全体）で1つだけ生成され、 // すべてのクロージャが「同じ変数 i への参照」を共有してしまう。 actions.add(() { print('Index: $i'); }); } return actions; } void main() { var handlers = createHandlers(); for (var action in handlers) { action(); } }
このコードの実行結果はどうなるか？
君たちが期待したのは `0`, `1`, `2` だろう。だが、実際の出力はこうなる。
Index: 3
Index: 3
Index: 3
なぜこうなるのか？
Dartの `for (var i = 0; …)` ループにおいて、変数 `i` はループブロックの外側に一度だけ実体化される。クロージャがキャプチャしたのは「その時点の値」ではなく、「変数 `i` 自体の参照」だからだ。ループが終了した時点で `i` は `3` になっているため、どのクロージャを実行しても最終値の `3` が参照されてしまう。
—
3. 解決策：シャドーイングとイミュータブルなスコープ設計
この問題を美しく解決し、プロダクションコードとして耐えうる堅牢な実装にするにはどうすればいいか。
答えは簡単だ。「ループのイテレーションごとに新しい不変（`final`）のスコープ変数を切り直す」こと。Dartのモダンなコンパイラは、ブロックごとに新しい変数を宣言すれば、それぞれのスコープに応じた安全なキャプチャを行ってくれる。
以下に、実務で即座に使える美しいコンポーネント生成の設計パターンを示す。
プロダクション品質のコード例
/// 非同期API連携やUIコンポーネントのイベントハンドラ生成を想定した堅牢な設計
class ActionDispatcher {
/// 複数の非同期タスク用コールバックを安全に生成する
static List
final handlers =
for (var i = 0; i < endpointIds.length; i++) {
// 💡 対策：ループ内ブロックで final 変数を宣言し、現在の id をシャドーイング（または別名で固定）する。
// これにより、各クロージャは独立した Context を持ち、変数の共有によるバグが完全に防がれる。
final currentIndex = i;
final currentId = endpointIds[i];
handlers.add(() async {
await _mockApiCall(currentIndex, currentId);
});
}
return handlers;
}
static Future
// ネットワーク遅延のシミュレーション
await Future.delayed(const Duration(milliseconds: 100));
print(‘[API Success] Index: $index, Endpoint ID: $id’);
}
}
void main() async {
print(‘=== 非同期ハンドラの安全な実行テスト ===’);
final endpoints = [‘users/v1’, ‘posts/v2’, ‘settings/v3’];
final dispatchers = ActionDispatcher.buildApiHandlers(endpoints);
// すべてのハンドラを並行実行
await Future.wait(dispatchers.map((handler) => handler()));
}
実行結果
=== 非同期ハンドラの安全な実行テスト ===
[API Success] Index: 0, Endpoint ID: users/v1
[API Success] Index: 1, Endpoint ID: posts/v2
[API Success] Index: 2, Endpoint ID: settings/v3
意図した通り、各インデックスとIDが正確にキャプチャされ、非同期処理であっても期待通りの挙動を担保できている。
—
4. パフォーマンス上の注意点：メモリリークとGCプレッシャー
クロージャが変数をキャプチャする際、開発者が最も注意すべきは「不要なオブジェクトの寿命延長」だ。
例えば、数MBある巨大なJSONデータを保持するローカル変数が、ごく小さなウィジェットのタップイベント用クロージャ（匿名関数）の内部で参照されていたとする。そのウィジェットが画面から破棄（Dispose）され、本来ならガベージコレクションされるはずのタイミングであっても、クロージャが生きている限り、その巨大なJSONデータはヒープ上に居座り続ける。
テクニカルリードからの設計指針
1. 必要なものだけをキャプチャする
オブジェクト全体（`this` や大きなステート）をクロージャ内で暗黙的にキャプチャするのではなく、必要なプリミティブ値や特定のプロパティだけをローカルの `final` 変数に切り出してキャプチャせよ。
2. 不要になったリスナー・コールバックは確実に解放する
Flutterであれば `ChangeNotifier` や `StreamSubscription`、Webフロントエンド的なイベントリスナーなど、クロージャを登録したあとは、ライフサイクル（`dispose` など）のタイミングで必ず参照を断ち切ること。これを行わないと、コンテキストツリー全体がメモリリークの温床となる。
3. `const` を極限まで活用する
もしクロージャや変数がコンパイル時定数として定義できるなら、`const` を付与せよ。Dart VMは定数をヒープに何度もアロケートせず、メモリ効率を最大化する。
—
スコープとクロージャの挙動は、言語の表面的な文法を覚えただけでは見えてこない。しかし、ここを完全に掌握しているエンジニアが書くコードは、バグがなく、メモリ効率が洗練されており、大規模開発でも破綻しない。
今日のレビューから、君たちのコードにおける「変数とクロージャの寿命」を見直してほしい。美しく堅牢なアーキテクチャは、こうしたミクロな理解の積み重ねの上にしか成り立たないのだから。