【実務・中級編】VB.NETにおけるDisposableパターンとFinalizeの正しい実装：アンマネージドリソース（COMオブジェクトやWin32ハンドル）を確実にかつ安全に解放するためのベストプラクティス – Visual Basic (VB / VB.NET)解析バイブル

VB.NETにおけるDisposableパターンとFinalizeの極意：アンマネージドリソースを完全掌握せよ

開発現場でこんな恐怖を味わったことはないか？
「業務システムの稼働中、なぜか数日に一度のペースでメモリ使用量が右肩上がりになり、突然クラッシュする」
「ExcelやデータベースのCOMオブジェクトを操作したあと、タスクマネージャーに幽霊プロセス（`EXCEL.EXE`など）が延々と居座り続ける」

VB.NET（.NET Framework / .NET 6/7/8）は、ガベージコレクション（GC）がメモリ管理を自動化してくれる極めて優秀なプラットフォームだ。しかし、それはマネージドメモリ（VB.NETのコードで管理される領域）の話であって、WindowsのOS内核が管理するアンマネージドリソース（Win32ハンドル、ファイルストリーム、GDI+オブジェクト、そしてCOMオブジェクト）は別腹だ。

今回は、GC任せでは絶対に防げないリソースリークを根絶し、アプリケーションを鉄壁の要塞へと仕立て上げる「正しいDisposableパターンとFinalizeの実装」を、チーフアーキテクトの視点からロジカルかつシャープに伝授する。

—

1. なぜ「GC任せ」では業務システムが破綻するのか？

初心者はよく「インスタンスが不要になったらGCが回収してくれるのだから、解放処理など不要だ」と誤解する。これが大間違いの元凶だ。

GCが動くタイミングは、マネージドヒープが圧迫された時やシステムが暇な時であり、開発者が意図した瞬間に実行されるわけではない。
特にCOMオブジェクトやOSのハンドルは、数としては少なくても、システム全体の枯渇（ハンドルリークによるOSのフリーズ）を直撃する。数千件のファイルやデータベース接続をループ処理で開閉する業務ツールにおいて、GCの気まぐれを待っていたら、瞬く間にリソースは食い潰される。

ここで登場するのが、開発者が明示的にリソースを返却するための契約である `IDisposable` インターフェイス と、最後の砦である ファイナライザ（`Finalize` / 破壊者） だ。

—

2. 破壊的なアンチパターン：やってはいけない実装

まずは、現場でよく見かける「動くには動くが、地雷原のようなクソコード」を見てほしい。

.net
‘ 【悪手】絶対に真似してはならないアンチパターン
Public Class BadResourceHandler
Private fileHandle As IntPtr

Public Sub New(ByVal filePath As String)
‘ Win32 API等でハンドルを取得したと仮定
Me.fileHandle = CreateFile(…)
End Sub

‘ デストラクタを書けば安心だと思っている素人実装
Protected Overrides Sub Finalize()
If fileHandle <> IntPtr.Zero Then
CloseHandle(fileHandle) ‘ アンマネージドの解放
End If
MyBase.Finalize()
End Sub
End Class

なぜこのコードが「悪手」なのか？

1. ファイナライザのコストが重すぎる：`Finalize`メソッドが存在するオブジェクトは、GCの回収フェーズにおいて「ファイナライザキュー」に積まれ、回収が通常より1世代先送りされる。無駄なGC負荷を生み出す。
2. 決定論的（Deterministic）ではない：いつ呼ばれるか分からない。業務システムにおいて「いつ解放されるか保証されない」のは致命傷である。
3. COMや例外への耐性ゼロ：途中で例外が発生した際、ハンドルがリークする。

—

3. プロが実装する「正しいDisposableパターン」の完全形

.NETの設計ガイドラインに準拠した、安全かつ高性能な完全版の実装を提示する。これをベースクラスやリソースを扱うクラスの標準テンプレートとして採用してほしい。

.net
Imports System
Imports System.Runtime.InteropServices

”’

Public Class RobustResourceManager
Implements IDisposable

‘ 1. アンマネージドリソース（例：Win32ハンドルやCOMオブジェクト）
Private _nativeResourceHandle As IntPtr = IntPtr.Zero

‘ 2. マネージドリソース（例：他のIDisposable実装クラス）
Private _managedStream As System.IO.Stream

‘ 3. 既に解放済みかを示すフラグ（多重解放の防止）
Private _disposed As Boolean = False

Public Sub New(ByVal stream As System.IO.Stream)
_managedStream = stream
‘ _nativeResourceHandle の初期化処理（省略）
End Sub

”’

Public Sub Dispose() Implements IDisposable.Dispose
‘ 実際の解放処理を呼ぶ（disposing = True は明示的解放を意味する）
Dispose(disposing:=True)

‘ GCに対して「もうファイナライザを呼ばなくていいよ」と通知し、パフォーマンスを最適化する
GC.SuppressFinalize(Me)
End Sub

”’

Protected Overridable Sub Dispose(disposing As Boolean)
If Not _disposed Then
If disposing Then
‘ — 【ステップA】マネージドリソースの解放 —
‘ まだ破棄されていないマネージドオブジェクトがあれば、ここでDisposeする
If _managedStream IsNot Nothing Then
_managedStream.Dispose()
_managedStream = Nothing
End If
End If

‘ — 【ステップB】アンマネージドリソースの解放 —
‘ disposingの値に関わらず（ファイナライザから呼ばれても）必ず実行する
If _nativeResourceHandle <> IntPtr.Zero Then
‘ 例：Win32APIの解放関数を呼び出す
‘ CloseHandle(_nativeResourceHandle)
_nativeResourceHandle = IntPtr.Zero
End If

_disposed = True
End If
End Sub

”’

Protected Overrides Sub Finalize()
‘ disposing = False として呼び出す（マネージドオブジェクトには触ってはいけない！）
Dispose(disposing:=False)
MyBase.Finalize()
End Sub

”’

Public Sub DoWork()
If _disposed Then
Throw New ObjectDisposedException(Me.GetType().FullName)
End If
‘ ビジネスロジック…
End Sub
End Class

—

4. この設計のキモとアーキテクトの視点

上記のコードには、現場で生き残るための高度な知見が凝縮されている。

① `disposing` 引数の意味

• `disposing = True` の時（明示的な `Dispose()` からの呼び出し）：

マネージドオブジェクトもアンマネージドオブジェクトも両方安全に解放できる。他のマネージドオブジェクトのメソッドを叩いても安全。

• `disposing = False` の時（ファイナライザからの呼び出し）：

GCによってどの順序で他のオブジェクトが破棄されているか分からないため、他のマネージドオブジェクトにアクセスしては絶対にならない。アンマネージドリソース（ポインタやハンドル）の解放のみに徹する。

② `GC.SuppressFinalize(Me)` の重要性

明示的に `Dispose()` が呼ばれた場合、OSハンドルはすでに解放されているため、後からGCがファイナライザを呼ぶ必要がなくなる。このメソッドを呼ぶことで、オブジェクトがファイナライザキューから除外され、メモリ管理のパフォーマンスが劇的に向上する。

—

5. 現場で使える！ファイル・DB連携における実践テクニック

VB.NETで最もリソースリークが起きやすいのが、ファイル読み書きとデータベース（ADO.NET）だ。ここに `Using` ステートメントを組み合わせることで、バグの入り込む余地を完全に断つ。

`Using` ステートメントによる糖衣構文の活用

VB.NETでは、`Using`ブロックを抜ける際に自動的に `Dispose()` が呼ばれる。例外が発生しようとも確実に実行されるため、try-finallyを書く手間が省ける。

.net
‘ 優れた業務ツールのコード例：ファイル処理
Public Sub ExportDataReport(ByVal data As String, ByVal filePath As String)
‘ Usingブロックを使うことで、スコープを抜けた瞬間に確実かつ自動的にファイルストリームが閉じられる
Using fs As New System.IO.FileStream(filePath, System.IO.FileMode.Create, System.IO.FileAccess.Write),
writer As New System.IO.StreamWriter(fs, System.Text.Encoding.UTF8)

writer.Write(data)
writer.Flush()
End Sub ‘ <-- ここで自動的に writer.Dispose() と fs.Dispose() が走り、ハンドルが即座に解放される End Sub

データベース接続（ADO.NET）の鉄則

ADO.NETの `SqlConnection` や `SqlCommand` も `IDisposable` を実装している。

.net
Public Function GetUserData(ByVal userId As Integer) As String
Dim query As String = “SELECT UserName FROM Users WHERE UserId = @Id”

‘ Connection, Command, DataReader すべてを Using で多重包囲する
Using conn As New SqlClient.SqlConnection(“Server=myServer;Database=myDB;…”)
Using cmd As New SqlClient.SqlCommand(query, conn)
cmd.Parameters.AddWithValue(“@Id”, userId)

conn.Open()

‘ ExecuteReaderにもCommandBehavior.CloseConnectionなどを渡すか、
‘ 各々をUsingで確実に閉じることが、プール枯渇を防ぐ唯一の道である
Using reader As SqlClient.SqlDataReader = cmd.ExecuteReader()
If reader.Read() Then
Return reader(“UserName”).ToString()
End If
End Using
End Using
End Using

Return String.Empty
End Function

コネクションプールがあるから大丈夫、と油断してはならない。`Dispose` を怠ると、プールへの返却遅延やガベージコレクションの圧迫を招き、高負荷時に接続エラー（Timeout）を引き起こす原因となる。

—

総括

プロフェッショナルとアマチュアの決定的な違いは、「動くコードを書くか」「エラーが起きず、長期間安定稼働し続ける堅牢なコードを書くか」の点にある。

1. アンマネージドリソースやCOMを扱うクラスは `IDisposable` を実装しろ。
2. 明示的解放（`Dispose`）と安全弁（`Finalize`）の責務を `disposing` フラグで明確に分離しろ。
3. `GC.SuppressFinalize(Me)` で不要なGCコストを排除しろ。
4. 日常のコーディングでは `Using` ステートメントを徹底し、リソースリークの芽を物理的に摘み取れ。

この知見をあなたのチームにインストールし、リソースリークの恐怖から永遠に解放された強靭なシステムを構築してほしい。