プロの現場へようこそ。私はこれまで、数え切れないほどのミッションクリティカルな業務自動化システムを設計・構築してきた。
そこで目にしてきたのは、無残にも「メモリリーク」や「ファイルロックの解放漏れ」で自滅していくコードの山だ。多くの初心者は「.NET Framework / .NET Coreにはガベージコレクション（GC）があるから、メモリ管理は自動だ」と盲信している。
だが、それは大きな間違いだ。アンマネージド資源（ファイル、データベース接続、ネットワークソケットなど）は、GCの管轄外にある。 これらを放置することは、蛇口を全開にしたまま家を空けるのと同じだ。
今回は、VB.NETにおける資源解放の生命線である「Usingステートメント」について、表面的なリファレンスを超えた、アーキテクト視点での「鉄則」を伝授する。
—
1. なぜ「Using」が必要なのか？：GCの限界を知る
.NETのガベージコレクション（GC）は非常に優秀だが、欠点がある。それは「いつ動くか分からない（非決定論的）」という点だ。
例えば、Excelファイルを開いてデータを読み取るツールを作ったとしよう。処理が終わった後、資源を明示的に解放しなければ、GCが回るまでの間、そのファイルはOSレベルでロックされ続ける。その結果、次にツールを実行した際に「ファイルが別のプロセスで使用されています」というエラーを吐いて止まる。
これを防ぐためのインターフェースが `IDisposable` であり、その実装を確実に呼び出すための構文が `Using` ステートメントだ。
悪い例：手動でDisposeを呼ぶ（敗北への道）
‘ ❌ 絶対にやってはいけない書き方
Dim reader As New StreamReader(“data.csv”)
Dim content As String = reader.ReadToEnd()
‘ ここで例外（エラー）が発生したら、下のCloseは一生呼ばれない
‘ ファイルはロックされ続け、システムの不安定化を招く
reader.Close()
reader.Dispose()
—
2. Usingステートメント：例外に屈しない堅牢な構文
`Using` ステートメントの真髄は、「スコープを抜ける際に、何があっても必ずDispose（破棄）を呼ぶ」という保証にある。内部的には `Try…Finally` ブロックへとコンパイルされるため、例外が発生しても資源は確実に解放される。
正しい例：単一のリソース管理
”’
”’
Public Sub ReadFileSecurely(filePath As String)
‘ Usingブロックの開始。この変数の寿命はEnd Usingまで。
Using reader As New StreamReader(filePath, System.Text.Encoding.UTF8)
Dim line As String = reader.ReadLine()
‘ 何らかのビジネスロジック
Console.WriteLine(line)
‘ 💡 明示的なCloseは不要。End Usingで自動的にDisposeが呼ばれる。
End Using
End Sub
—
3. 実務で差がつく「ネスト」と「複数宣言」のテクニック
業務自動化の現場では、DBからデータを取得してファイルに書き出すといった「複数のリソース」を同時に扱うケースが多い。ここで初心者は `Using` を深くネスト（入れ子）にしてしまい、コードの可読性を著しく下げる。
効率的な書き方：カンマ区切りによる一括宣言
VB.NETでは、同じ型のオブジェクトであればカンマ区切りで一行にまとめられる。また、異なる型であってもネストを浅く見せる書き方がある。
”’
”’
Public Sub ExportData()
Dim connStr As String = “Your_Connection_String”
‘ 複数のIDisposableオブジェクトをスマートに管理
Using conn As New SqlConnection(connStr),
cmd As New SqlCommand(“SELECT FROM Logs”, conn),
writer As New StreamWriter(“export.log”)
conn.Open()
Using reader As SqlDataReader = cmd.ExecuteReader()
While reader.Read()
writer.WriteLine(reader(“LogMessage”).ToString())
End While
End Using ‘ readerの破棄
End Using ‘ conn, cmd, writer がここで「逆順」に一括破棄される
End Sub
アーキテクトの視点：
この書き方の利点は、リソースの依存関係を明確にしつつ、インデントの地獄（コールバックヘルやネスト地獄）を回避できる点にある。
—
4. VB.NET特有の挙動：暗黙のスコープと型推論
VB.NET 14.0以降、`Using` ステートメントはより洗練された。特に、初期化時の型推論を活用することで、冗長な型宣言を排除できる。
‘ 型を明示せずとも推論される（Option Infer On の場合）
Using client As New HttpClient()
‘ clientはHttpClientとして型安全に扱える
End Using
ただし、注意が必要なのは「戻り値としてリソースを返す場合」だ。
‘ ❌ 誤った設計：呼び出し元に渡す前に破棄されてしまう
Public Function GetStream() As Stream
Using fs As New FileStream(“data.bin”, FileMode.Open)
Return fs ‘ 戻り値を返した瞬間にDisposeされるため、呼び出し元では使えない
End Using
End Function
リソースの所有権（Ownership）をどこに持たせるか。これは設計の根幹だ。関数内で `Using` を使うなら、その関数内で処理を完結させろ。外に渡すなら、呼び出し元に `Using` を強制させる設計にせよ。
—
5. データベース連携における致命的な罠
特に `SqlConnection` を扱う際、`Using` を怠ると「接続プール（Connection Pool）」が枯渇する。これは、DBサーバー自体は生きていても、アプリ側から接続できなくなるという、開発環境では再現しにくい厄介なバグを引き起こす。
鉄則：接続を開いたら、最速で閉じろ。
”’
”’
Public Sub ExecuteDatabaseTask()
Try
Using conn As New SqlConnection(“Your_Conn_String”)
conn.Open()
‘ … 処理 …
End Using ‘ ここで確実に接続がプールに返却される
Catch ex As SqlException
‘ ログ出力など、適切な例外処理
Throw New ApplicationException(“DB操作に失敗しました。”, ex)
End Try
End Sub
—
結論：一流のエンジニアであるために
`Using` ステートメントを使うことは、単なる「作法」ではない。それは、「自分が確保した資源には、最後まで責任を持つ」というプロフェッショナルとしての宣言だ。
1. IDisposableを実装しているクラスか？ と常に疑え（F12キーで定義を確認しろ）。
2. Usingが使える場所では、100% Usingを使え。 Try-Finallyを自分で書くのは、Usingが使えない特殊な状況（クラスのメンバ変数として保持する場合など）だけだ。
3. スコープは最小限に。 資源を掴んでいる時間は短ければ短いほど、システムは堅牢になる。
この規律を守るだけで、君のコードから謎のフリーズやクラッシュは激減するだろう。業務自動化という「止まってはいけない」世界で、真に信頼されるシステムを構築してほしい。
