LINQの「遅延実行」という名の劇薬：VB.NETアーキテクトが語るパフォーマンスの真実
長年、VB6の`Collection`や`Recordset`の挙動に翻弄され、.NETへの移行期に血の涙を流してきたエンジニア諸君。君たちは今、LINQという強力な武器を手にしている。しかし、その「遅延実行（Deferred Execution）」という特性を理解せず、ただ便利に使っているだけならば、それはシステムに時限爆弾を仕掛けているのと同じだ。
今日は、中級者が陥りやすい「クエリの再評価」の罠と、それを回避してメモリとCPUを最適化する「確定（Materialization）」の作法について、アーキテクトの視点から深掘りする。
—
1. なぜ「遅延実行」はあなたのシステムを殺すのか
LINQにおける `IEnumerable(Of T)` ベースのクエリは、定義した瞬間には何も実行されない。`For Each` で回されるその瞬間に初めて、クエリが評価される。
‘ 一見、効率的に見えるコード
Dim query = context.Orders.Where(Function(o) o.Status = “Pending”)
‘ 1回目：ここでSQLが発行される
For Each item In query
Console.WriteLine(item.Id)
Next
‘ 2回目：ここでもう一度SQLが発行される（無駄な通信！）
Dim count = query.Count()
この挙動を理解していないと、ループの中で何度も同じクエリを走らせたり、本来メモリ上に保持すべきデータを何度も再計算させたりする。Windows APIを直接叩いてメモリを管理していた時代の我々からすれば、この「見えないオーバーヘッド」は耐え難いコストだ。
2. ToList()：最適化への第一歩、あるいは諸刃の剣
この「遅延」を断ち切り、結果をメモリ上に確定させるのが `ToList()` や `ToArray()` だ。これを使うことで、クエリは一度だけ実行され、結果はリストとしてメモリに保持される。
実践的な最適化の指針
- 反復が必要な場合： 迷わず `ToList()` で確定させろ。メモリ消費とトレードオフだが、不必要なAPI呼び出しやSQL発行を避ける方が遥かに安上がりだ。
- 大量データを扱う場合： `ToList()` は全件をメモリにロードする。数百万件のレコードがあるなら、それはメモリリーク（あるいは`OutOfMemoryException`）への招待状だ。その場合は、`IEnumerable`のままストリーム処理するか、`Skip`/`Take`でページングを実装せよ。
3. レガシー・システムとの融合：IDisposableの責務
VB.NETで特に注意すべきは、`IDisposable` を実装したオブジェクトの扱いだ。LINQでデータベース接続やファイルストリームを扱う際、クエリの結果を確定させずにスコープを抜けると、接続の解放が遅延し、コネクションプールを枯渇させる。
Public Function GetActiveUsers() As List(Of User)
‘ Usingブロックで接続を強制解放する
Using context As New DataContext()
‘ ToList()で結果を確定させることで、
‘ このスコープを出た瞬間に安全にDisposeできる
Return context.Users.Where(Function(u) u.IsActive).ToList()
End Using
End Function
アーキテクトとして言わせてもらえば、「遅延実行をスコープ外に持ち出すな」。これが鉄則だ。戻り値として `IEnumerable` を返す設計は、呼び出し元がいつクエリを実行するかを制御できないため、極めて危険な設計となる。
4. チーフアーキテクトの結論：現場で生き残るための「型」
私が現場で指導する際、以下のルールを徹底させている。
1. クエリの多重実行を禁止する： 同じ結果を2回以上参照するなら、必ず `ToList()` で変数にキャッシュせよ。
2. 寿命を制御せよ： `IEnumerable` をクラスのメンバ変数にするな。クエリの実行タイミングと接続のライフサイクルが乖離し、デバッグ不可能なバグを生む。
3. 計測なき最適化は罪： `Stopwatch` クラスを使って実行時間を計測しろ。直感に頼るな。`ToList()` を入れた結果、逆にメモリ負荷が増えてGCが頻発することもある。
最後に
VB.NETは、適切に扱えば極めて堅牢で効率的なシステムを構築できる言語だ。LINQの便利さに溺れ、裏側で何が起きているのかという「オブジェクトの重み」を忘れてはならない。
君たちが書くその一行が、数年後の保守エンジニアの命を救うことになる。あるいは、地獄のトラブルシューティングを強いることになる。常にメモリとプロセッサの呼吸を感じながら、コードを書いてほしい。
以上だ。コードの裏側の真実を見極める目を持て。
