VB.NETにおける「IDisposable」パターンの完全実装：資源枯渇を防ぐライフサイクル管理の極意
レガシーなVB6（VBA）システムから現代の.NET（.NET Core / .NET 8）に至るまで、業務アプリケーション開発において最も見落とされがちなのが「資源のライフサイクル管理」だ。
「ガベージコレクション（GC）があるからメモリ管理は不要」――この神話を信じ込んでいるプログラマーは、実務の現場において重篤な障害を引き起こす。GCはメモリの回収は行うが、OSから直接割り当てられたファイルハンドル、ソケット、COMオブジェクト、そしてネイティブヒープ（アンマネージド資源）の存在など知ったことではない。これらを放置すれば、確実にハンドルリークを引き起こし、システムは突如として「リソース不足」でクラッシュする。
今回は、自作クラスにおいて `IDisposable` インターフェイスを完全に実装し、マネージド資源とアンマネージド資源を完璧に調停・解放するための極限の知見を授ける。
—
1. なぜ「標準のDisposeパターン」が必要なのか？
VB.NETにおけるオブジェクト破棄は、単に `Nothing` を代入することと同義ではない。`Nothing` は単に参照を切るだけであり、即座に資源が解放される保証はない（GCの世代別収集に依存する）。
確実かつ即時的にリソースを解放するためには、以下の3要素を満たす標準Disposeパターン（Standard Dispose Pattern）を実装しなければならない。
1. 二重解放の防止（既に破棄済みのインスタンスに対する多重呼び出しのガード）
2. GCへのファイナライザ抑制（`GC.SuppressFinalize` によるパフォーマンス最適化）
3. マネージドとアンマネージドの分離（解放順序の厳密な制御）
—
2. 実践：完璧な `IDisposable` 実装コード
以下に、Windows APIの呼び出し（アンマネージド資源）と、マネージドなストリームを同時に抱えるカスタムクラスの完全実装を示す。このままプロダクションコードとして投入可能な堅牢性を持たせている。
Imports System
Imports System.Runtime.InteropServices
Imports System.IO
Namespace Enterprise.MemoryManagement
”’
”’
Public Class PerfectResourceHandler
Implements IDisposable
‘ — 1. フィールドの定義 —
‘ 【マネージド資源】 .NETが管理するストリーム
Private m_fileStream As FileStream
‘ 【アンマネージド資源】 Windows APIが発行するハンドル（例としてファイルハンドルを使用）
Private m_safeNativeHandle As IntPtr = IntPtr.Zero
‘ 【状態管理フラグ】 既にDisposeが呼ばれたかを示す
Private m_disposed As Boolean = False
‘ P/Invoke: アンマネージドなハンドルを閉じるためのWindows API
Private Shared Function CloseHandle(ByVal hObject As IntPtr) As
End Function
”’
”’
Public Sub New(ByVal filePath As String)
Try
‘ マネージド資源の初期化
m_fileStream = New FileStream(filePath, FileMode.OpenOrCreate, FileAccess.ReadWrite)
‘ アンマネージド資源のモックとして、APIから何らかのハンドルを取得したと仮定
‘ （実務では CreateFile などのAPI結果が入る）
m_fileStream.SafeFileHandle.DangerousAddRef()
m_safeNativeHandle = m_fileStream.SafeFileHandle.DangerousGetHandle()
Catch ex As Exception
‘ 初期化途中で例外が発生した場合、中途半端に残った資源を自ら掃除する
Me.Dispose(False)
Throw New ApplicationException(“リソースの初期化に失敗しました。”, ex)
End Try
End Sub
‘ — 2. パブリックな Dispose メソッド（IDisposableの実装） —
”’
”’
Public Sub Dispose() Implements IDisposable.Dispose
‘ 1. 管理下の解放処理を実行
Dispose(True)
‘ 2. ファイナライザ（Finalizer）による二重のGCコストを発生させないよう登録を解除
GC.SuppressFinalize(Me)
End Sub
‘ — 3. プロテクトされた実効 Dispose メソッド（オーバーライド可能） —
”’
”’
”’ True: マネージド+アンマネージド / False: アンマネージドのみ
Protected Overridable Sub Dispose(ByVal disposing As Boolean)
‘ すでに破棄済みの場合は二重実行を防止
If m_disposed Then
Return
End If
If disposing Then
‘ ==========================================
‘ 【マネージド資源の解放】
‘ ==========================================
‘ 他のマネージドオブジェクトを参照してメソッドを呼べるのはこのブロックのみ
If m_fileStream IsNot Nothing Then
m_fileStream.Dispose()
m_fileStream = Nothing
End If
End If
‘ ==========================================
‘ 【アンマネージド資源の解放】
‘ ==========================================
‘ disposingの値に関わらず（ファイナライザから呼ばれても）必ず実行する
If m_safeNativeHandle <> IntPtr.Zero Then
‘ Windows APIによるハンドル解放
CloseHandle(m_safeNativeHandle)
m_safeNativeHandle = IntPtr.Zero
End If
‘ 破棄完了フラグを立てる
m_disposed = True
End Sub
‘ — 4. ファイナライザ（デストラクタ） —
”’
”’
Protected Overrides Sub Finalize()
‘ disposing = False として呼び出す
‘ ※ファイナライザスレッドから実行されるため、マネージドオブジェクトに触れてはならない
Dispose(False)
MyBase.Finalize()
End Sub
‘ — 5. 防御的プログラミング：生存確認 —
”’
”’
Private Sub CheckDisposed()
If m_disposed Then
Throw New ObjectDisposedException(Me.GetType().FullName, “このオブジェクトは既に破棄されています。再利用はできません。”)
End Sub
End Sub
”’
”’
Public Sub DoSomething()
CheckDisposed()
‘ ビジネスロジックの実行
End Sub
End Class
End Namespace
—
3. チーフアーキテクトが解説する「実装の急所」
上記のコードには、レガシー開発者が陥りがちな罠を防ぐための高度な知見が凝縮されている。
① `disposing` パラメータの本質
`Protected Overridable Sub Dispose(ByVal disposing As Boolean)` の引数 `disposing` は、「誰がこの破棄を命じたか」を意味する。
- `disposing = True`: ユーザーコード（`Dispose()` メソッド）から呼ばれた。マネージド資源もアンマネージド資源も両方とも安全に破棄できる。
- `disposing = False`: ファイナライザ（`Finalize()`）から呼ばれた。マネージドオブジェクトはすでにGCによって順序不取締に回収されている可能性があるため、マネージド資源に触れてはならない（触るとNullReferenceExceptionやメモリ破壊を引き起こす）。アンマネージド資源のみを解放する。
② `GC.SuppressFinalize(Me)` の重要性
`Dispose()` が明示的に呼ばれた場合、CLR（共通言語ランタイム）に対して「このオブジェクトのファイナライザを呼び出す必要はない」と通知しなければならない。
これを怠ると、オブジェクトは無駄にファイナライザキューに繋がり、GCの世代別回収のサイクルを1回分無駄に遅延させる（世代昇格が発生する）。パフォーマンスチューニングの観点から、`SuppressFinalize` の省略は万死に値する。
③ `ObjectDisposedException` による防御的設計
一度 `Dispose()` が走ったインスタンスを誤って再利用しようとすると、予測不可能なバグ（アクセス違反など）の原因になる。メソッドの先頭に `CheckDisposed()`（内部で `m_disposed` をチェック）を挟むことで、フェイルセーフな設計を実現している。
—
4. 現場で使うための鉄則：`Using` 構文の徹底
VB.NETで `IDisposable` を実装したクラスを使うときは、手動で `obj.Dispose()` を書くべきではない。例外発生時に `Dispose` がスキップされるリスクがあるためだ。
必ず `Using` ステートメント（または `Using` 宣言）を使用すること。
‘ 【推奨】Usingブロックによる確実なスコープ破棄
Sub ProcessBusinessData()
‘ スコープを抜けた瞬間に、例外の有無に関わらず自動的に Dispose() が呼び出される
Using handler As New PerfectResourceHandler(“C:\Logs\operation.log”)
handler.DoSomething()
End Using ‘ ここで確実に解放される
End Sub
—
総括
メモリリークやハンドル枯渇は、システムが本番稼働して長期間経過した後に突如として牙をむく、最も悪質なバグの一つである。
「動けばいい」という妥協を捨て、マネージドとアンマネージドの境界線を正確に理解した上で `IDisposable` パターンをコードに定着させること。それこそが、レガシーの呪縛を断ち切り、真に堅牢なエンタープライズシステムを構築するための唯一の道である。
