VB.NETにおけるShared（静的）メンバーの罠：マルチスレッド環境を制するスレッドセーフ設計の極意
VBAの標準モジュールにある`Public`変数や、VB.NETの`Shared`（C#における`static`）メンバー。インスタンスを生成せずともどこからでも呼び出せるその手軽さから、多くの開発者が思考停止で多用してきた。
しかし、長年レガシーシステムからモダンな.NET環境への移行を見続けてきたアーキテクトの視点から言わせてもらえば、`Shared`の安易な使用は、マルチスレッド環境における時限爆弾に他ならない。
今回は、複数スレッドからの同時アクセスが引き起こすメモリ上の競合（データ競合）のメカニズムと、それを完全に制御するための排他制御、そして現場で即座に使えるスレッドセーフなクラス設計の極意を、一切の妥協なく解説する。
—
1. なぜ `Shared` メンバーはマルチスレッドで凶器と化すのか？
メモリ空間の共有と「スレッドセーフ」の幻想
VB.NETにおいて、`Shared`修飾された変数やプロパティは、アプリケーションドメイン（メモリ空間）内でたった一つのインスタンスのみが共有される。
単一スレッドの古いVBAアプリケーションやシーケンシャルな処理であれば、これほど便利なものはない。しかし、現代のタスクベース非同期処理やマルチスレッド環境（`Task`クラスや`Parallel`クラスなど）では話が別だ。
複数のスレッドが同時に同一の`Shared`変数に対して「読み取り」と「書き込み」を行った場合、何が起きるか？
CPUのレベルで命令の実行順序がインターリーブ（入り交じる）し、一方が書き込んだデータをもう一方が予期せぬタイミングで上書きする「競合状態（Race Condition）」が発生する。
実例：カウントアップ処理における致命的なデータ破損
以下のコードを見てほしい。一見、何の問題もないように見えるカウンタクラスだ。
Public Class UnsafeCounter
‘ 共有変数
Public Shared CurrentCount As Integer = 0
‘ カウントを進めるメソッド
Public Shared Sub Increment()
‘ 以下の処理はアトミック（不可分）ではない！
‘ 1. 現在値の読み取り
‘ 2. 1を加算
‘ 3. 変数への書き戻し
CurrentCount += 1
End Sub
End Class
この `UnsafeCounter.Increment()` を、10個のスレッドから同時に10,000回ずつ呼び出したとしよう。最終的な `CurrentCount` は「100,000」になるはずだ。
しかし、実際にマルチスレッドで実行すると、値は必ず100,000より小さくなる。複数のスレッドが「同じ古い値」を同時に読み込み、同じ値を上書きしてしまうからだ。これが `Shared` メンバが孕む最大の罠である。
—
2. `SyncLock` による排他制御の極意
この競合を防ぐための基本にして最強の武器が、`SyncLock` ステートメント（C#の `lock`）である。
`SyncLock` は、特定のリソースに対するアクセスを「一度に一つのスレッドのみ」に制限する（相互排他：Mutual Exclusion）。
正しいロックオブジェクトの選び方
排他制御を行う際、最もやってはいけないのが「型そのもの」や「Me（あるいは文字列）」をロックの目印（モニター）にすることだ。
‘ 【悪手】Publicな型や文字列をロックするとデッドロックや予期せぬ干渉の原因になる
SyncLock GetType(MyClass)
‘ 処理…
End SyncLock
外部からアクセス可能なオブジェクトをロックに使うと、アプリケーションの別の場所で同じオブジェクトがロックされた際に予期せぬデッドロック（膠着状態）を引き起こす。
ロック用オブジェクトは、必ずクラス内部に隠蔽された専用の `Private Shared` インスタンスとして用意しなければならない。
スレッドセーフなカウンタの実装例
以下に、`SyncLock` を正しく適用したスレッドセーフな実装を示す。
Public Class ThreadSafeCounter
‘ 外部から隠蔽された、排他制御専用のロックオブジェクト
Private Shared ReadOnly _lockObj As New Object()
‘ 共有変数はPrivateにして、直接アクセスさせない
Private Shared _currentCount As Integer = 0
”’
”’
Public Shared Sub Increment()
‘ ロック領域の範囲は最小限に絞る（パフォーマンス劣化を防ぐため）
SyncLock _lockObj
_currentCount += 1
End SyncLock
End Sub
”’
”’
Public Shared ReadOnly Property CurrentCount As Integer
Get
SyncLock _lockObj
Return _currentCount
End SyncLock
End Get
End Property
End Class
—
3. レガシーシステム・外部API連携における応用：Windows API呼び出しの落とし穴
現場のVB.NETエンジニアが頭を悩ませるのが、レガシーなWindows APIや、C言語で作られたサードパーティ製DLL（COMコンポーネント含む）との連携だ。
多くの古いDLLは、そもそも「マルチスレッド安全（Thread-Safe）」に設計されていない。
例えば、内部で静的バッファを使用しているAPIや、グラフィックコンテキストを共有するAPIを複数スレッドから同時に呼び出すと、メモリーアクセス違反（Access Violation）による突然のプロセス墜落を引き起こす。
APIラッパーにおける Shared と排他制御の活用
レガシーAPIを安全にラップする場合も、`Shared` メソッドの内部で `SyncLock` を使い、API呼び出しを直列化（シリアライズ）するのが定石だ。
Imports System.Runtime.InteropServices
Public NotInheritable Class LegacyApiWrapper
‘ 非スレッドセーフなAPIを保護するためのロック
Private Shared ReadOnly _apiLock As New Object()
Private Shared Function NativeDoSomething(ByVal inputData As IntPtr) As Integer
End Function
”’
”’
Public Shared Function SafeExecute(ByVal data As IntPtr) As Integer
SyncLock _apiLock
‘ ネイティブ側がマルチスレッド非対応であるため、
/ ここを排他制御で保護し、同時に複数のスレッドがネイティブ関数に入らないようにする
Return NativeDoSomething(data)
End SyncLock
End Function
End Class
※ `NotInheritable`（C#の `sealed`）を付与し、意図しない継承による構造の破壊を防ぐのも、堅牢なアーキテクチャ設計の基本技法である。
—
4. メモリ最適化とオブジェクトのライフサイクル管理
`Shared` メンバーを使用する際にももう一つ、メモリ管理上の重大な注意点がある。
それは、`Shared` 変数に格納されたオブジェクトは、アプリケーションが終了するまでガベージコレクション（GC）の対象外になるという点だ。
メモリリークを防ぐための鉄則
`Shared` なコレクションやキャッシュに巨大なオブジェクトやデータセットを際限なく格納し続けると、Generation 2 ヒープを圧迫し続け、最終的に `OutOfMemoryException` を引き起こす。
- キャッシュのサイズ制限（LRUキャッシュなどの導入）
- 不要になった段階での明示的なクリア (`.Clear()`, `= Nothing`)
- IDisposable実装パターンの適用
これらを怠った `Shared` メンバーは、静かなるメモリリーク製造機と化す。
—
5. まとめ：チーフアーキテクトからの提言
`Shared` メンバーは、正しく使えばコードを簡潔にし、パフォーマンスの向上にも寄与する強力な機能だ。しかし、その裏にあるメモリ共有の仕組みとマルチスレッドの挙動を理解していない者にとっては、システムを崩壊させる劇薬にもなり得る。
1. 安易に `Shared` 変数を書き換えない。
2. 書き込み・読み取りが競合する箇所には、必ず専用の `Object` による `SyncLock` を張る。
3. レガシーAPIや外部連携のラッパーでは、排他制御による直列化を徹底する。
4. `Shared` 領域に置くオブジェクトのライフサイクル（寿命）に常に気を配る。
この原則を遵守できるか否かが、あなたの書くコードが「動くおもちゃ」で終わるか、それとも「ミッションクリティカルな現場に耐えうる堅牢なシステム」になるかの分かれ目である。
プロフェッショナルたるもの、メモリとスレッドの動きを常に脳内で視覚化しながらコードを紡ぎ出すべし。
