VB.NETのループを極める：ForとFor Eachのメモリ動態と、現場で踏む「地雷」の回避策
レガシーシステムからモダンな.NET環境への移行、あるいは長年稼働し続ける基幹システムの保守において、ループ処理（繰り返し構文）の選択を誤ることは、パフォーマンスの劣化や致命的なバグ（`InvalidOperationException`など）に直結する。
VB.NETにおける `For` 文と `For Each` 文。
この一見して初歩的な構文の裏側で、Common Language Runtime (CLR) はメモリ、ガベージコレクタ（GC）、そしてコレクションのポインタをどのように操作しているか。
本稿では、単なる文法解説に留まらず、オブジェクトのライフサイクルとパフォーマンスの重みを知るエンジニアの視点から、両者の本質的な違いと、現場で生きる実践的知見を解説する。
—
1. 骨組みの理解：For と For Each の内部メカニズム
まずは、両者がCLR上でどのように実行されているかの違いを明確にしておく必要がある。
`For` 文：インデックスによる直接アクセス
`For i = 0 To collection.Count – 1` のような構文は、配列や `List(T)` のようなインデックスベースのデータ構造に対して最も高速に動作する。
ポインタのオフセット計算が非常に単純であり、CPUのキャッシュヒット率も高くなる傾向がある。
`For Each` 文：イテレータ（IEnumerator）の抽象化
一方、`For Each` は糖衣構文（シンタックスシュガー）であり、内部的には対象オブジェクトが実装する `IEnumerable` インターフェイスから `IEnumerator` を取得し、`MoveNext()` と `Current` プロパティをループごとに呼び出している。
‘ For Each の内部で行われていることの概念的等価コード
Dim enumerator As IEnumerator(Of T) = collection.GetEnumerator()
Try
While enumerator.MoveNext()
Dim item As T = enumerator.Current
‘ 実際のループ処理がここに記述される
End While
Finally
‘ IDisposable を実装していれば明示的に破棄される
If TypeOf enumerator Is IDisposable Then
DirectCast(enumerator, IDisposable).Dispose()
End If
End Try
この「ラッパー（イテレータ）の生成」と「インターフェイス経由のメソッド呼び出し」というオーバーヘッドがあるため、純粋な数値カウントのループにおいて `For Each` はわずかに不利になる。しかし、後述する抽象化のメリットと安全性を考慮すれば、その差は多くの場合トレードオフの範囲内である。
—
2. 現場の罠：コレクション走査中の「要素削除」が引き起こす破綻
実務の現場で最も頻発するバグの一つが、「ループを回しながら、そのコレクションの要素を削除する」というアプローチに起因するものだ。
誤った実装：前方からのインデックス削除
以下のコードを見てほしい。一見、正しくリストから条件に合う要素を削除しているように見える。
‘ 【アンチパターン】For文で前方から削除する
Dim numbers As New List(Of Integer) From {1, 2, 3, 4, 5}
For i As Integer = 0 To numbers.Count – 1
If numbers(i) = 3 Then
numbers.RemoveAt(i) ‘ ここでインデックスがズレる！
End If
Next
何が起きるか？
要素 `3` を削除した瞬間、後続の要素（`4` や `5`）が一つずつ前方にシフトする。しかし、ループカウンタ `i` はインクリメントされるため、シフトしてきた新しい要素をスキップしてしまう。さらに、リストのサイズ（`Count`）が動的に減るため、最後には `ArgumentOutOfRangeException` が発生してプロセスが異常終了する。
誤った実装：For Eachでの直接削除
では、`For Each` で試みたらどうなるか。
‘ 【アンチパターン】For Each文の最中にコレクションを変更する
Dim numbers As New List(Of Integer) From {1, 2, 3, 4, 5}
For Each num As Integer In numbers
If num = 3 Then
numbers.Remove(num) ‘ InvalidOperationException が発生！
End If
Next
何が起きるか？
`List(T)` のイテレータは、列挙中にコレクションの構造が変更された（要素が追加・削除された）ことを検知すると、即座に `InvalidOperationException`（コレクションが変更されました。列挙操作は実行されません。）をスローするように設計されている。これは「フェイルファスト（Fail-Fast）」と呼ばれる安全機構である。
—
3. 極限の解決策：安全かつ高速な要素操作のイディオム
では、実務においてコレクションから条件エンティティを安全に排除するにはどうすればよいのか。チーフアーキテクトが推奨する手法は以下の2つだ。
解決策 A：逆順（Descend） `For` ループ
インデックスを用いた削除を行う場合、後ろから前へ向かってループを回せば、インデックスのズレ問題は完全に回避できる。
‘ 【推奨パターン】逆順Forによる安全な削除
Dim numbers As New List(Of Integer) From {1, 2, 3, 4, 5}
‘ Count – 1 から 0 へ向かってデクリメント
For i As Integer = numbers.Count – 1 To 0 Step -1
If numbers(i) = 3 Then
numbers.RemoveAt(i) ‘ 後ろから消すため、前方への影響はゼロ
End If
Next
メモ：この手法は、Windows APIから取得したネイティブな配列や、メモリ効率を極限まで高めたいレガシーな数値処理ループにおいて今なお有効なアプローチである。
解決策 B：`RemoveAll` メソッド（.NET標準の最適化機能）
モダンな .NET (VB.NET) 環境であれば、無駄なループを自分で書くべきではない。`List(T).RemoveAll` を使用する。内部最適化されており、一回の走査とメモリ移動で完結するため圧倒的に高速かつ安全である。
‘ 【モダン・ベストプラクティス】ラムダ式を用いた一括削除
Dim numbers As New List(Of Integer) From {1, 2, 3, 4, 5}
‘ 値が 3 のものを一括削除
numbers.RemoveAll(Function(n) n = 3)
—
4. パフォーマンスとメモリ最適化の知見
最後に、大規模データを扱うシステム（大量のCSVインポート、DBからの数百万件のレコード処理など）におけるメモリマネジメントの鉄則に触れておく。
1. `For Each` 内でのボックス化（Boxing）の回避
もしレガシーな `ArrayList` を未だに使用している場合、`For Each item As Integer In arrayList` と書くだけで、値型である `Integer` が参照型に変換されるボックス化が発生し、GC（ガベージコレクション）のヒープ領域に負荷がかかる。ジェネリックな `List(Of T)` を必ず使用し、型安全かつメモリ効率の良い状態を維持すること。
2. 大規模ループにおけるオブジェクトのライフサイクル
ループ内で毎回インスタンスを生成 (`New`) するコードは、GCの世代別収集（Gen 0）の頻度を跳ね上げ、CPU使用率を圧迫する。
‘ 悪例：ループ内で巨大なオブジェクトを生成破棄し続ける
For i As Integer = 0 To 100000
Dim buffer As New Byte(1048575) ‘ 1MBの配列
‘ 処理…
Next ‘ ループの度にガベージが山のように蓄積される
このようなケースでは、バッファをループの外側で一度だけ確保して再利用する（オブジェクトプールや使い回し）設計思想が不可欠となる。
—
総括
VB.NETの `For` と `For Each` は、単なる「書き方の好み」ではない。
前者はインデックスとメモリレイアウトを意識した「処理速度と低レベル制御の武器」、後者は安全性と可読性を担保する「イテレータによる抽象化の盾」である。
挙動の裏側にあるCLRのメモリ管理、イテレータのライフサイクル、そしてフェイルファストの原則を理解していれば、現場で遭遇する不可解なバグやパフォーマンス劣化の多くは未然に防ぐことができる。
コードの行数や見た目の美しさに惑わされず、ハードウェアとランタイムに負荷をかけない、真に堅牢なアーキテクチャを構築し続けよ。
