【VB.NET極限知見】Sharedの罠：マルチスレッド時代の静的メンバー設計とスレッドセーフの極意
業務自動化ツールやバックグラウンド処理エンジンをVB.NETで構築していると、ついつい便利で多用したくなるのが `Shared` メンバー（静的メンバー） だ。
インスタンスを生成することなく `ClassName.MethodName()` で呼び出せる手軽さは、ユーティリティクラスを作る上で非常に魅力的である。
しかし、開発現場で中級者から上級者へステップアップする過程において、この `Shared` は「最も静かに、そして確実に見えないバグを引き起こすパンドラの箱」へと変貌する。
今回は、マルチスレッド環境（タスク並列ライブラリや非同期処理）が当たり前となった現代の .NET 開発において、`Shared` 変数やメソッドが引き起こす競合状態（レースコンディション）のメカニズムを解剖し、実務で絶対に破綻しないスレッドセーフなクラス設計の極意を伝授する。
—
1. なぜ `Shared` メンバーはマルチスレッドで凶器と化すのか？
VB.NETの `Shared` キーワードは、メモリ上にそのクラスのメンバーを「ただ一つだけ」存在させる。アプリケーションドメイン（プロセス）のライフサイクルと完全に同期し、どこからでもアクセスできる。
これが単一スレッドのシーケンシャルな処理であれば何の問題もない。だが、以下のようなモダンな業務システムではどうだろうか。
- `Parallel.For` や `Task.Run` を使ったファイルの並列一括処理
- 複数スレッドから同時にリクエストを受け付けるWindowsサービスやWCF/Web API
- UIスレッドとバックグラウンドワーカースレッドの同時アクセス
複数のスレッドが「同一のメモリ領域（Shared変数）」に対して、同時に読み書きを行った瞬間、競合状態（Race Condition）が発生する。値が上書きされる、不整合な状態のオブジェクトが読み出される、最悪の場合はアプリケーション全体がクラッシュする。
非効率かつ危険な「アンチパターン」の例
まずは、現場でよく見かける「やってはいけない」コードを見てみよう。
‘ 【絶対に真似してはいけないアンチパターン】
Public Class ProcessCounter
‘ 共有カウンタ（Shared変数）
Public Shared CurrentCount As Integer = 0
‘ 処理を実行するSharedメソッド
Public Shared Sub IncrementAndProcess(dataId As Integer)
‘ ① 値の読み取り
Dim temp As Integer = CurrentCount
‘ ［ここでコンテキストスイッチが発生する可能性がある］
‘ ② 値のインクリメント
temp += 1
‘ ③ 値の書き戻し
CurrentCount = temp
Console.WriteLine($”DataID: {dataId}, Count: {CurrentCount}”)
End Sub
End Class
このコードを複数スレッドから同時に呼び出すと、①〜③の間に他のスレッドが割り込み、実際の処理回数よりも `CurrentCount` が大幅に小さくなる「ロストアップデート（更新損失）」が確実に発生する。
—
2. 排他制御の基本：`SyncLock` によるクリティカルセクションの保護
この競合を防ぐための最もプリミティブかつ確実なVB.NETの構文が `SyncLock` だ。
`SyncLock` は、指定したオブジェクトのロックを獲得したスレッド以外をブロックし、クリティカルセクション（排他制御すべきコード領域）への同時侵入を防ぐ。
正しい排他制御の実装例
Public Class SafeProcessCounter
Private Shared _currentCount As Integer = 0
‘ ロック専用のプライベートな参照型オブジェクト（外部から触らせないのが鉄則）
Private Shared ReadOnly _lockObject As New Object()
Public Shared Sub IncrementAndProcess(dataId As Integer)
‘ ロック取得
SyncLock _lockObject
‘ このブロック内は同時に1つのスレッドしか実行できない
_currentCount += 1
Console.WriteLine($”DataID: {dataId}, Safe Count: {_currentCount}”)
End SyncLock
‘ ブロックを抜けると自動的にロックが解放される
End Sub
End Class
アーキテクトからの重要アドバイス：
- ロックオブジェクトは必ず `Private Shared ReadOnly` で専用に用意すること。 `Me` や `GetType(SafeProcessCounter)`、文字列リテラルをロックに使うと、外部のコードやフレームワーク内部とロック競合を起こし、予期せぬデッドロックの原因となる。
—
3. ファイル・データベース連携における `Shared` の落とし穴
業務自動化ツールで最も多いのが、「ログファイルへの書き込み」や「DB接続プールの管理」を `Shared` メソッドで行うケースだ。
例えば、複数のスレッドから同時に1つのログファイルへ `Shared Sub WriteLog` で書き込もうとすると、.NETランタイム側で `IOException`（ファイルが別のプロセスによって使用されています）が即座に発生する。
これを防ぐためには、単なる排他制御だけでなく、そもそも `Shared` に頼らない設計（インスタンスベースの設計への移行）を検討すべきである。
プロダクションコード：スレッドセーフなロギング & ファイル処理クラス
どうしても `Shared` ユーティリティとして提供する必要がある場合の、スレッドセーフな実装パターンを示す。
Imports System.IO
Imports System.Text
Public NotInheritable Class ThreadSafeLogger
‘ インスタンス化を禁止（ユーティリティクラスの鉄則）
Private Sub New()
End Sub
Private Shared ReadOnly LogLock As New Object()
Private Const LogFilePath As String = “C:\Automation\logs\app.log”
”’
”’
Public Shared Sub Write(message As String)
Dim logLine As String = $”{DateTime.Now:yyyy-MM-dd HH:mm:ss.fff} [{Thread.CurrentThread.ManagedThreadId}] {message}”
‘ ファイル書き込みを排他制御
SyncLock LogLock
Try
‘ ディレクトリが存在しない場合の考慮
Dim dir = Path.GetDirectoryName(LogFilePath)
If Not Directory.Exists(dir) Then
Directory.CreateDirectory(dir)
End If
‘ 追記モードで安全に書き込む
Using sw As New StreamWriter(LogFilePath, True, Encoding.UTF8)
sw.WriteLine(logLine)
End Using
Catch ex As Exception
‘ ログ書き込み失敗時のフォールバック（イベントビューア等への出力）
System.Diagnostics.Trace.WriteLine($”Log Error: {ex.Message}”)
End Try
End SyncLock
End Sub
End Class
—
4. `Shared` を排除せよ：依存性注入（DI）とインスタンス指向へのシフト
ここまで `Shared` の安全な扱い方を解説したが、現代のエンタープライズ開発および堅牢な業務ツール開発の結論は、「極力 `Shared` 変数を使わないこと」である。
なぜなら、`Shared` メンバーはグローバル変数と何ら変わりなく、以下のデメリットを抱えるからだ。
1. 単体テスト（Unit Test）が困難になる（状態がグローバルに保持されるため、テスト間の独立性が保てない）。
2. モック化（Mocking）ができない（インターフェースを通じたポリモーフィズムが適用できない）。
実務中級者からシニアへ進むための最大のパラダイムシフトは、「すべてを `Shared` で済ませる悪癖を断ち切り、インスタンスを生成して依存関係を注入する（DI）設計」へ移行することだ。
リファクタリング例：インスタンスベースで設計された安全なプロセッサ
‘ インターフェースの定義
Public Interface IDataProcessor
Sub ProcessData(dataId As Integer)
End Interface
‘ 実装クラス（状態を持たせる、あるいはDIコンテナで管理する）
Public Class DatabaseDataProcessor
Implements IDataProcessor
Private readonly _connectionString As String
‘ コンストラクタインジェクション
Public Sub New(connectionString As String)
_connectionString = connectionString
End Sub
Public Sub ProcessData(dataId As Integer) Implements IDataProcessor.ProcessData
‘ インスタンスごとの接続文字列を使用するため、マルチスレッドでも安全
Console.WriteLine($”Processing {dataId} with DB: {_connectionString}”)
End Sub
End Class
この設計であれば、マルチスレッド環境下で複数のインスタンスが並列動作しても、内部のスコープが完全に分離されているため、`SyncLock` による重い排他制御すら不要になるケースが多い。
—
5. まとめ：現場の信頼を勝ち取るためのアーキテクチャ判断
VB.NETにおける `Shared` メンバーは、正しく使えばコードを簡潔にする強力な武器だが、マルチスレッドの文脈を無視して導入すれば、「原因特定が極めて困難なランダムバグ」の温床となる。
今日のポイントを改めて胸に刻んでほしい。
1. Shared変数への書き込みは必ず競合する前提で動け：マルチスレッド下ではロストアップデートが必ず起きる。
2. 排他制御には専用のロックオブジェクトを使え：`SyncLock _lockObject` を徹底し、`Me` や文字列ロックは絶対に行わない。
3. ファイル・DB操作を伴うならSharedを疑え：スコープの汚染やリソース競合を防ぐため、可能な限りインスタンスベースの設計（DI）へ舵を切る。
「動けばいいや」で作られたツールは、データ量が増え、非同期処理を取り入れた瞬間に崩壊する。
プロフェッショナルなエンジニアとして、堅牢性・保守性の高いスレッドセーフなコードをデザインし、現場の業務インフラを支える強固なシステムを構築してほしい。
