【テクニカル・上級編】【中級者・実務】WPFのDispatcherを活用したバックグラウンド処理中のUIフリーズ防止とスレッド間通信 – Visual Basic (VB / VB.NET)解析バイブル

Dispatcherの深淵：WPFにおけるスレッド間通信の極致とUIフリーズの完全排除

序文：UIフリーズという「敗北」

エンジニアとして、ユーザーの目の前でアプリケーションが「応答なし」となり、ウィンドウが白濁する瞬間ほど、プロフェッショナリズムを否定される瞬間はない。

WPF（Windows Presentation Foundation）における開発において、重いデータ処理やネットワークI/Oをメインスレッド（UIスレッド）で実行することは、設計上の致命的な欠陥である。しかし、単に `Task.Run` で処理を逃がせば解決するというほど、マルチスレッドプログラミングは甘くない。

WPFのオブジェクトには「スレッド・アフィニティ（Thread Affinity）」という絶対的な掟がある。UI要素は、それを作成したスレッド（UIスレッド）からしか操作できない。この掟を無視した瞬間、`InvalidOperationException` という名の断罪が下される。

本稿では、単なるコードの書き方ではない。Dispatcherのメカニズム、コンテキストスイッチのコスト、そしてメモリ管理の観点から、極限まで洗練されたバックグラウンド処理の実装術を伝授する。

1. スレッド・アフィニティとDispatcherの正体

WPFのUI要素（Button, TextBox, ProgressBar等）は、すべてUIスレッドのメッセージループによって管理されている。バックグラウンドスレッドからこれらのプロパティを書き換えようとすることは、他人の領土に無断で侵入する行為に等しい。

ここで登場するのが `Dispatcher` だ。Dispatcherは、UIスレッドの「待機列（Message Queue）」に、実行したい処理（Delegate）を送り込むための門番である。

Invoke と BeginInvoke の決定的な差

Dispatcherを利用する際、我々は常に二つの選択肢を迫られる。この選択を誤ると、デッドロック、あるいはパフォーマンスの劇的な低下を招く。

1. `Dispatcher.Invoke` (同期実行)

• UIスレッドに処理を投げ、その処理が完了するまでバックグラウンドスレッドを待機（Block）させる。
• リスク: UIスレッドが他の重い処理を行っている場合、バックグラウンドスレッドも巻き添えで停止する。最悪の場合、相互に待ち合うデッドロックを引き起こす。

2. `Dispatcher.BeginInvoke` (非同期実行)

• UIスレッドに処理を投げ、完了を待たずにバックグラウンドスレッドは即座に次の処理へ進む。
• 推奨: 基本的にはこちらを選択すべきである。スレッド間の疎結合性を保つための鉄則だ。

2. 実戦的実装：安全な進捗報告のアーキテクチャ

以下に、大規模なデータ処理をシミュレートしつつ、UIへ安全にプログレスバーの進捗を反映させる、実務レベルのVB.NETコードを示す。ここでは、現代的な `IProgress(Of T)` を活用しつつ、Dispatcherの挙動を制御する。

Imports System.Threading
Imports System.Threading.Tasks

''' <summary>
''' 業務ロジックを担うエンジンクラス
''' </summary>
Public Class DataProcessingEngine
    ''' <summary>
    ''' 重いデータ処理を実行する。
    ''' </summary>
    ''' <param name="progress">進捗を報告するためのインターフェース</param>
    ''' <param name="ct">キャンセル要求を受け取るトークン</param>
    Public Async Function ExecuteHeavyProcessAsync(progress As IProgress(Of Integer), ct As CancellationToken) As Task
        ' 擬似的な重いループ処理
        For i As Integer = 1 To 100
            ' キャンセル要求のチェック（アーキテクトの作法：こまめなチェック）
            ct.ThrowIfCancellationRequested()

            ' 外部API通信やDBアクセスを模した待機
            Await Task.Delay(50, ct)

            ' 進捗の報告
            ' IProgress(Of T) は内部的に SynchronizationContext を利用しており、
            ' 実装によっては自動的にUIスレッドへコンテキストを戻してくれる。
            progress?.Report(i)
        Next
    End Function
End Class

''' <summary>
''' メインウィンドウのコードビハインド
''' </summary>
Public Class MainWindow
    Private _engine As New DataProcessingEngine()
    Private _cts As CancellationTokenSource

    ' UI要素の定義（XAML側で定義されている想定）
    ' ProgressBar1, StatusLabel, StartButton, CancelButton

    ''' <summary>
    ''' 処理開始ボタンのイベントハンドラ
    ''' </summary>
    Private Async Sub StartButton_Click(sender As Object, e As RoutedEventArgs) Handles StartButton.Click
        ' UIの状態管理（二重押し防止）
        SetUiState(isProcessing:=True)
        _cts = New CancellationTokenSource()

        ' 進捗報告用のオブジェクト作成
        ' ここで Dispatcher を明示的に扱う手法を解説する
        Dim progressReporter = New Progress(Of Integer)(Sub(value)
                                                              ' Progress(Of T) はコンテキストを保持しているが、
                                                              ' 複雑なUI操作が必要な場合は Dispatcher を明示的に呼ぶ
                                                              UpdateUiProgress(value)
                                                          End Sub)

        Try
            ' バックグラウンドスレッドでの実行を開始
            Await _engine.ExecuteHeavyProcessAsync(progressReporter, _cts.Token)
            StatusLabel.Content = "完了しました。"
        Catch ex As OperationCanceledException
            StatusLabel.Content = "キャンセルされました。"
        Catch ex As Exception
            StatusLabel.Content = $"エラーが発生しました: {ex.Message}"
        Finally
            SetUiState(isProcessing:=False)
            _cts.Dispose()
        End Try
    End Sub

    ''' <summary>
    ''' UI要素を安全に更新する
    ''' </summary>
    Private Sub UpdateUiProgress(value As Integer)
        ' DispatcherのBeginInvokeを使用し、UIスレッドのキューに処理を積む
        ' 引数に DispatcherPriority.Background を指定することで、
        ' 他の重要なUI描画（マウス操作など）を妨げないように制御する。
        Application.Current.Dispatcher.BeginInvoke(Sub()
                                                       ProgressBar1.Value = value
                                                       StatusLabel.Content = $"処理中... {value}%"
                                                   End Sub, System.Windows.Threading.DispatcherPriority.Background)
    End Sub

    Private Sub SetUiState(isProcessing As Boolean)
        StartButton.IsEnabled = Not isProcessing
        CancelButton.IsEnabled = isProcessing
        If isProcessing Then ProgressBar1.Value = 0
    End Sub

    Private Sub CancelButton_Click(sender As Object, e As RoutedEventArgs) Handles CancelButton.Click
        _cts?.Cancel()
    End Sub
End Class

3. 極限の知見：アーキテクトが留意すべき3つの罠

コードが動いたからといって、満足してはいけない。真のシニアエンジニアは、その裏側にある「重み」を見ている。

① Dispatcher Saturation（Dispatcherの飽和）

バックグラウンドスレッドから `BeginInvoke` を秒間数千回呼び出すような実装は、破滅を招く。Dispatcherのキューが処理しきれなくなり、UIスレッドのメッセージループが埋め尽くされ、結果としてマウス操作すら受け付けない「実質的なフリーズ」を引き起こす。

• 対策: 進捗報告には「間引き（Throttling）」を導入せよ。例えば、`If i Mod 10 = 0 Then progress.Report(i)` のように、一定間隔でのみ報告を行う。

② メモリリークとオブジェクトのライフサイクル

`Dispatcher.BeginInvoke` に渡すラムダ式（匿名関数）は、クロージャを形成する。もしその中で、破棄されるべき大規模なオブジェクトや、ViewModelのインスタンスを不適切に参照し続けていると、ガベージコレクション（GC）がそのオブジェクトを回収できず、メモリリークを引き起こす。

• 対策: Dispatcherに渡すデータは、可能な限り「値型」または「不変（Immutable）なDTO（Data Transfer Object）」に限定せよ。生の実体（Entity）を渡してはいけない。

③ コンテキストスイッチのオーバーヘッド

スレッド間通信は、CPUにとって「安価な処理」ではない。コンテキストスイッチが発生し、キャッシュのフラッシュが起こる。頻繁すぎる通信は、バックグラウンド処理自体のスループットを低下させる。

• 対策: 「細かな更新を何度も」ではなく、「まとまったデータを一度に」送る設計思想を持て。

結言：技術の真髄

WPFにおけるマルチスレッド制御の本質は、「UIスレッドをいかに自由にさせておくか」、そして「バックグラウンドスレッドをいかに孤独にさせるか」という、二つの相反する要素の調和にある。

`Dispatcher` は単なる道具ではない。それは、異なる時間軸（スレッド）で動くプロセス同士を繋ぐ、極めて繊細なインターフェースである。このインターフェースの挙動を完全に掌握して初めて、君は「動くシステム」ではなく、「信頼に足るソフトウェア」を構築できるのだ。