【VB.NET極限知見】`My`名前空間の全貌：レガシーとモダンを繋ぐ極限のショートカットとメモリ最適化
長年、VBAによるデスクトップ自動化や、VB 6.0からVB.NETへの移行期を生き抜いてきたシニアエンジニア諸君なら痛感しているはずだ。
「いかにボイラープレート（定型コード）を削り、本質的なビジネスロジックにリソースを集中させるか」が、レガシーシステム保守およびエンタープライズ開発の生存戦略であることを。
C#プログラマーは「VBはレガシーだ」と揶揄するが、彼らが冗長な `System.IO.File` や `System.Windows.Forms.Application` の初期化に苦戦している横で、VB.NETには圧倒的な隠し武器が存在する。それが `My` 名前空間（Myオブジェクト） である。
今回は、この `My` が提供する極限の便利機能を単なる「初心者向け糖衣構文（シンタックスシュガー）」として片付けず、裏で動くオブジェクトのライフサイクル、メモリ効率、さらにはWindows APIとの親和性に至るまで、チーフアーキテクトの視点から丸裸にする。
—
1. なぜ `My` は強力なのか？（裏側のアーキテクチャ）
`My` は、.NET Framework / .NET Core の膨大なクラスライブラリの中から、頻出する機能を極限まで凝縮し、コンテキストに応じた最適なインスタンスを自動生成・管理するコード生成ラッパーである。
例えば、C#でアプリケーションの実行パスを取得しつつ設定ファイルを読み込む場合と、VB.NETの `My` を使う場合を比較してほしい。`My` は内部でシングルトンパターンや適切な遅延初期化（Lazy Initialization）をよしなに処理し、開発者が煩雑なインスタンス管理から解放されるよう設計されている。
しかし、この「手軽さ」の裏側を知らずに使うと、メモリリークやマルチスレッド環境での予期せぬ挙動を引き起こす。ここからは、実務で即座に使える4大領域 (`FileSystem`, `Application`, `Computer`, `User`) の極限活用術をコードとともに解説する。
—
2. `My.Computer.FileSystem` による爆速ファイル操作とメモリ最適化
ファイルI/Oにおいて、従来の `System.IO` は強力だが、ストリームの閉じ忘れや、巨大なファイルを読み込んだ際のガベージコレクション（GC）への負荷がつきまとう。`My.Computer.FileSystem` は、これを安全かつワンライナーで実行する。
実務コード：巨大ログの安全な非同期読み込みと文字コード自動判定
Imports System.IO
Imports System.Text
Public Class LogAnalyzer
”’
”’
Public Shared Sub AnalyzeLargeLog(filePath As String)
‘ ファイルが存在しない場合の例外をエレガントに回避
If Not My.Computer.FileSystem.FileExists(filePath) Then
Throw New FileNotFoundException(“対象のログファイルが見つかりません。”, filePath)
End If
‘ My.Computer.FileSystem.OpenTextFileReader は内部で適切なバッファリングを行う
‘ Usingステートメントにより、例外発生時でも確実にハンドル（リソース）を解放する
Using reader As StreamReader = My.Computer.FileSystem.OpenTextFileReader(filePath, Encoding.UTF8)
While Not reader.EndOfStream
Dim line As String = reader.ReadLine()
‘ リアルタイムフィルタリング（メモリ効率を最大化するため不要なオブジェクト生成を避ける）
If line.Contains(“CRITICAL”) Then
ProcessCriticalError(line)
End If
End While
End Using
End Sub
Private Shared Sub ProcessCriticalError(logLine As String)
‘ 実際の処理
Console.WriteLine($”[ALERT] {logLine}”)
End Sub
End Class
アーキテクトの知見:
`My.Computer.FileSystem.ReadAllText` は小規模ファイルには便利だが、数GB規模のログに使うと一瞬でLOH（Large Object Heap）を圧迫し、メモリフラグメンテーションを引き起こす。巨大ファイルを扱う際は上記の通り `OpenTextFileReader` と `Using` を組み合わせ、明示的なリソース解放を担保せよ。
—
3. `My.Application` と `My.Computer` によるハードウェア・環境制御
社内システムや常駐型バッチツールにおいて、OSの環境、メモリ残量、さらにはWindows APIと連携の前段階としてのプロセス制御は必須の知見だ。
実務コード：リソース監視と多重起動防止の極意
Public NotInheritable Class ApplicationController
Private Sub New()
‘ 静的クラスとしての設計
End Sub
”’
”’
Public Shared Sub VerifySystemResources()
‘ 1. 利用可能な物理メモリ（RAM）のチェック（MB単位）
Dim availableMemoryMB As ULong = My.Computer.Info.AvailablePhysicalMemory / (1024 1024)
If availableMemoryMB < 512 Then
' メモリ逼迫時は強制的にガベージコレクションを誘発し、LOHの断片化を解消
GC.Collect()
GC.WaitForPendingFinalizers()
If My.Computer.Info.AvailablePhysicalMemory / (1024 1024) < 256 Then
Throw New OutOfMemoryException("利用可能なシステムメモリが限界値を下回っています。")
End If
End If
' 2. アプリケーションの実行ディレクトリの安全な取得
' （レガシーな CurrentDirectory に依存せず、常にバイナリの場所を基準にする）
Dim appRoot As String = My.Application.Info.DirectoryPath
Console.WriteLine($"Working Directory: {appRoot}")
End Sub
'''
”’
Public Shared Function CheckSingleInstance() As Boolean
Dim mutexName As String = $”Global\{My.Application.Info.AssemblyName}”
Dim createdNew As Boolean
‘ OSグローバルなミューテックスを生成
Dim mutex As New Threading.Mutex(True, mutexName, createdNew)
If Not createdNew Then
‘ 既に起動している場合の処理
MessageBox.Show(“このアプリケーションは既に起動しています。”, “警告”, MessageBoxButtons.OK, MessageBoxIcon.Warning)
Return False
End If
‘ ガベージコレクションによるミューテックスの早期解放を防ぐため、アプリ終了まで保持するアプローチが必要
‘ （実務では ApplicationEvents.vb の Startup 1発目でフックするのが最も美しい）
Return True
End Function
End Class
—
4. レガシーシステム保守における `My.User` とセキュリティコンテキスト
VBAや古いWindowsフォームアプリから移行したシステムでは、権限管理がガバガバなケースが散見される。特にドメイン環境やローカルセキュリティポリシーが絡む場面で、`My.User` は現在の実行ユーザーのプリンシパル情報を一瞬で引き出す。
実務コード：Windows認証に基づく動的機能制限
Public Class SecurityGuard
”’
”’ レガシーなAPI呼び出しや危険な操作をブロックする
”’
Public Shared Sub ValidateUserPermission()
Dim principal = TryCast(My.User.CurrentPrincipal, Threading.Thread.CurrentPrincipal)
‘ Windows アカウント情報の取得
Dim userName As String = My.User.Name
Dim isAuthenticated As Boolean = My.User.IsAuthenticated
If Not isAuthenticated Then
Throw New Security.AuthenticationException(“認証されていないコンテキストからの実行です。”)
End If
‘ 組み込みのAdministratorグループ、または特定の業務ロールに属しているか
If Not My.User.IsInRole(“Administrators”) AndAlso Not My.User.IsInRole(“Corp\SystemOperators”) Then
‘ 権限がない場合はUIの特定機能を無効化するなどのハンドリングを行う
LogUnauthorizedAccess(userName)
Throw New UnauthorizedAccessException(“この操作を実行する権限がありません。”)
End If
End Sub
Private Shared Sub LogUnauthorizedAccess(user As String)
Dim logMsg = $”[SECURITY] 権限エラー: ユーザー {user} が特権操作を試行しました。”
My.Computer.FileSystem.WriteAllText(
My.Application.Info.DirectoryPath & “\security.log”,
logMsg & Environment.NewLine,
True
)
End Sub
End Class
—
5. チーフアーキテクトからの最終提言
VB.NETの `My` 名前空間は、単なる「初心者向けの便利機能」ではない。
内部で適切に最適化されたクラス群をラップし、開発者が「車輪の再発明」や「冗長なボイラープレート」に溺れるのを防ぐための極めて洗練されたアーキテクチャ・ショートカットである。
しかし、どんなに強力なツールであっても、その裏で動くメモリの挙動（Garbage Collection）、ストリームのライフサイクル（Usingによる確実な破棄）、そして例外処理の文脈を理解していなければ、システムは肥大化し、やがてレガシーの悪夢へと逆戻りする。
モダンな.NET Core / .NET 8/9 の時代であっても、VB.NETが持つこの圧倒的な開発生産性の高さを武器に、堅牢かつ美しいコードを組み上げてほしい。技術の本質を見失うな。コードで語れ。
