Windows Formsの呪縛を解く：BackgroundWorkerの墓場と、`ValueTask`・`IAsyncEnumerable`による極限の非同期ストリーミング
レガシーなWindows Formsアプリケーションの寿命を延ばす戦いは、常に「UIスレッドの防衛戦」であった。
かつて我々は、DBからの数百万件のレコード取得や、肥大化したREST APIとの通信でUIが完全に凍結（フリーズ）する現象に頭を悩ませてきた。その救世主として現れたのが `BackgroundWorker` であり、コンポーネントトレイにドラッグ＆ドロップして `DoWork` イベントを書く日々は、VB.NET開発者にとって馴染み深いものだったはずだ。
しかし、シニアエンジニアよ、現実を見据えなければならない。
`BackgroundWorker` は、すでに過去の遺物である。`object` 型のキャスト地獄、例外ハンドリングの隠蔽、そして何より「メモリの無駄なアロケーションと、バッファリング完了までUIに1件もデータを流せない遅延」という構造的欠陥を抱えている。
本稿では、.NETのモダン非同期構文である `ValueTask` と `IAsyncEnumerable
—
1. なぜ BackgroundWorker はモダン開発の足かせとなるのか？
`BackgroundWorker` の本質は、ThreadPoolのラッパーに過ぎない。しかし、そのAPIデザインは古臭く、今日の高スループットなシステム要件には耐えられない。
1. バッファリングの強制: データをすべてメモリ上に集めてから一括で `ReportProgress` や `RunWorkerCompleted` に引き渡すため、最初の1件を表示するまでに巨大なレイ The latency が発生する。
2. GC（ガベージコレクション）への悪影響: イベント駆動モデルにおけるボックス化（Boxing）と、頻繁なイベント引数の生成は、LOH（Large Object Heap）の断片化を誘発し、UIの微小なカクつき（Jank）を引き起こす。
3. キャンセレーションの煩雑さ: `CancellationToken` のような統一された非同期キャンセレーション機構がなく、`WorkerSupportsCancellation` フラグのポーリングに依存している。
これらを打破するのが、「非同期ストリーミング（Async Streams）」である。
—
2. 設計の中核：`IAsyncEnumerable` によるゼロバッファリング・ストリーミング
データソース（例えば、数百万行を返すSQL ServerのDataReaderや外部WebAPI）から、データを「全件取得してから返す」のではなく、「1件生成されるごとにUIスレッドへ流し込む」。これが `IAsyncEnumerable
さらに、呼び出し側のオーバーヘッドを極限まで削ぎ落とすため、通常の `Task
実装コード：モダン非同期データプロバイダ
以下に、データベースまたはAPIからの大規模データストリームを模擬したリポジトリ層のコードを示す。
.net
Imports System.Collections.Generic
Imports System.Runtime.CompilerServices
Imports System.Threading
Imports System.Threading.Tasks
Public Class EnterpriseDataRepository
‘ 大規模データを非同期ストリームとして遅延評価（Yield）で返却する
Public Async Function StreamLargeDatasetAsync(
ByVal batchSize As Integer,
) As IAsyncEnumerable(Of DataEntity)
‘ 外部リソース（DBコネクション等）の模擬
For i As Integer = 1 To 1000000
‘ キャンセレーションチェック
cancellationToken.ThrowIfCancellationRequested()
‘ 非同期I/Oの模擬（ネットワーク遅延やDBフェッチ）
Await Task.Delay(1, cancellationToken).ConfigureAwait(False)
‘ エンティティの生成
Dim entity As New DataEntity With {
.Id = i,
.RecordName = $”Record_No_{i}”,
.Timestamp = DateTime.UtcNow
}
‘ 1件ごとにストリームへ流す（メモリ上に全件保持しない）
Yield entity
Next
End Function
End Class
Public Class DataEntity
Public Property Id As Integer
Public Property RecordName As String
Public Property Timestamp As DateTime
End Class
> アーキテクトの知見: `.ConfigureAwait(False)` の使用に注目してほしい。ライブラリ層やデータプロバイダ層では、UIコンテキストに固執する必要はない。スレッドプールに戻すことで、Windows Formsのメッセージループスレッドを汚染せず、スレッドPoolの枯渇を防ぐ。
—
3. Windows Forms UI層での極限の非同期イテレーション
UIスレッド側では、`await foreach` 構文を用いてストリームを順次処理する。ここで重要なのは、「いかにUIの描画更新頻度をコントロールし、UIスレッドを殺さないか」という点である。
1件ごとに `DataGridView` の `Rows.Add` を呼び出すと、メッセージキューがUI描画イベントで飽和し、アプリが死亡する。そのため、「バッチ＆スロットリング（間引き）」の概念を導入する。
実装コード：UIフォームでのストリーム消費とスレッド保護
.net
Imports System
Imports System.Collections.Generic
Imports System.Threading
Imports System.Threading.Tasks
Imports System.Windows.Forms
Public Class MainForm
Inherits Form
Private ReadOnly _repository As New EnterpriseDataRepository()
Private _cts As CancellationTokenSource
‘ UI描画用のスレッドセーフなバッファ（UIの応答性を維持するため一定間隔でフラッシュ）
Private ReadOnly _uiBatchQueue As New List(Of DataEntity)()
Private WithEvents _gridData As DataGridView
Private WithEvents _btnStart As Button
Private WithEvents _btnCancel As Button
‘ コンストラクタやコントロール初期化は省略（標準的なWinFormsデザイナを想定）
Private Async Sub _btnStart_Click(sender As Object, e As EventArgs) Handles _btnStart.Click
_btnStart.Enabled = False
_btnCancel.Enabled = True
_uiBatchQueue.Clear()
_cts = New CancellationTokenSource()
Try
‘ UIスレッドから非同期ストリームを安全に購読開始
Await ConsumeDataStreamAsync(_cts.Token)
Wrench Catch ex As OperationCanceledException
MessageBox.Show(“処理はユーザーによってキャンセルされました。”, “情報”, MessageBoxButtons.OK, MessageBoxIcon.Information)
Catch ex As Exception
MessageBox.Show($”致命的なエラーが発生しました: {ex.Message}”, “エラー”, MessageBoxButtons.OK, MessageBoxIcon.Error)
Finally
_btnStart.Enabled = True
_btnCancel.Enabled = False
‘ リソースの確実な破棄
If _cts IsNot Nothing Then
_cts.Dispose()
_cts = Nothing
End If
End Try
End Sub
Private Sub _btnCancel_Click(sender As Object, e As EventArgs) Handles _btnCancel.Click
If _cts IsNot Nothing Then
_cts.Cancel()
End If
End Sub
‘ ストリームを非同期でイテレートし、UIスレッドをブロックせずにデータを回収する心臓部
Private Async Function ConsumeDataStreamAsync(token As CancellationToken) As Task
‘ SynchronizationContext.Current を自動キャプチャし、await 後は自動的にUIスレッドに戻る
Dim stream = _repository.StreamLargeDatasetAsync(100, token)
Dim lastFlushed As DateTime = DateTime.UtcNow
Const flushIntervalMs As Integer = 100 ‘ 100ms ごとにUIへ反映（描画スパイクの防止）
Async For Each entity In stream
‘ 内部バッファに蓄積
SyncLock _uiBatchQueue
_uiBatchQueue.Add(entity)
End SyncLock
‘ 一定時間が経過、またはバッファが溜まったらUIを更新
If (DateTime.UtcNow – lastFlushed).TotalMilliseconds >= flushIntervalMs Then
Await FlushQueueToUiAsync()
lastFlushed = DateTime.UtcNow
End If
Awaiting End Async For
‘ 残りのバッファをフラッシュ
If _uiBatchQueue.Count > 0 Then
Await FlushQueueToUiAsync()
End If
End Function
‘ UIスレッドへバッチデータを一括投入し、DataGridViewの描画負荷を最小化する
Private Async Function FlushQueueToUiAsync() As Task
Dim localCopy As List(Of DataEntity)
SyncLock _uiBatchQueue
If _uiBatchQueue.Count = 0 Then Return
localCopy = New List(Of DataEntity)(_uiBatchQueue)
_uiBatchQueue.Clear()
End SyncLock
‘ UIコントロール操作は必ずメインスレッドで行われる（ConfigureAwaitにより保証される）
‘ DataGridViewの仮想モード（Virtual Mode）や一括追加を用いるとさらに高速化するが、
‘ ここでは簡潔さのためにAddRangeを使用
‘ 実際のUIコンポーネントへのバインド処理
For Each item In localCopy
_gridData.Rows.Add(item.Id, item.RecordName, item.Timestamp.ToLocalTime().ToString(“yyyy-MM-dd HH:mm:ss”))
Next
End Function
End Class
—
4. レガシーシステム保守・相互運用における極限の知見
このモダンな非同期パターンを既存の巨大なWindows Formsソリューションに導入する際、シニアエンジニアが直面する罠と、その処方箋を共有しておく。
A. Windows APIのメッセージポンプとのデッドロック回避
`Task.Wait()` や `.Result` を絶対にVB.NETコードのUIスレッド上で呼んではならない。シングルスレッドアパートメント（STA）モデルで動作するWindows Formsにおいて、同期ブロックは即座にUIデッドロックを引き起こす。
常に `Async / Await` チェーンをエントリポイント（ボタンクリック等）から最深部まで途切れさせずに接続すること。
B. COMオブジェクトおよびアンマネージドリソースの明示的解放
大量のデータをストリーミング処理する際、DBコネクション（OLEDB / ODBC / ADO.NET）やExcel/Word等のCOMオブジェクトが背後で絡んでいる場合、GCの自動解放を待っていてはメモリリークを起こす。
`IAsyncEnumerable` の中で外部リソースを利用する場合は、`IAsyncDisposable` インターフェイスを実装し、`await using` 構文を用いて確実かつ即座にハンドルを返却しなければならない。
.net
‘ 例: 非同期リソースの確実な破棄
Public Async Function ProcessWithUnmanagedResourceAsync() As Task
Await Using var connection = New System.Data.SqlClient.SqlConnection(“…”)
Await connection.OpenAsync()
‘ … ストリーミング処理 …
End Using ‘ ここで自動的に DisposeAsync が呼ばれる
C. WinForms固有のペインティング最適化
数万行のレコードを一気に `DataGridView` に突っ込む場合、描画のたびにレイアウト計算が走る。これを防ぐために、以下のWinForms固有のAPIを駆使せよ。
.net
‘ 大量データ投入前のフリーズ防止策
_gridData.SuspendLayout()
‘ — データ追加処理 —
_gridData.ResumeLayout(True)
さらに、極限のパフォーマンスが求められる現場では、`DataGridView` の `VirtualMode = True` を有効にし、独自のデータキャッシュ構造体（`List(Of DataEntity)`）を直接参照させるモデルへ移行すべきである。
—
総括
`BackgroundWorker` は、シングルスレッド全盛期のノスタルジーに過ぎない。
現代のエンタープライズWindows Forms開発において、システム間連携の非同期化とUIスレッドの保護は、`ValueTask` と `IAsyncEnumerable
メモリの無駄なアロケーションを断ち切り、UIの滑らかさとスループットを極限まで高めること。それこそが、レガシーとモダンを融合させるシニアエンジニアの技量である。あなたのコードベースから、今すぐ `BackgroundWorker` を排除し、真の非同期の領域へ踏み出してほしい。
