【VB.NET極限知見】MyNamespaceの全貌：レガシーの呪縛を断ち切る「My」の美学と最適化
多くのシニアエンジニアやアーキテクトは、VB.NETを語る際になぜか及び腰になる。C#の洗練された構文や、昨今のモダンな言語仕様と比較して「VBはレガシーだ」と一刀両断する者も少なくない。
しかし、現場を見渡せばどうか。製造業、金融、そして我が国の社会インフラを裏で支える基幹システムの多くは、今なおVB.NETのコードベースで稼働している。そして、VBAから移行してきたエンジニアたちが作り上げたカオスなオブジェクト生成の残骸が、メモリリークやパフォーマンス低下を引き起こしている。
ここで問いたい。VB.NETが持つ最大の隠し武器『MyNamespace（Myオブジェクト）』の本質を、あなたは本当の意味で理解し、使いこなしているか？
今回は、冗長なコードを排除し、Windows APIの直接叩き込みやレガシーなCOM相互運用すらスマートに包み込む「My」の極限活用術を、チーフアーキテクトの視点から叩き込む。
—
1. なぜ「My」なのか？ — シニアが知るべき背後のオーバヘッドと実態
`My.Computer`, `My.Application`, `My.User`。これらは単なる「初心者向けの便利ラッパー」ではない。その実体は、コンパイラが裏で最適化されたインスタンス管理やスレッドコンテキストへのアクセスを安全に行うための高抽象化ファサードである。
C#erは「こんなものはSystem.IOやSystem.Environmentで書けばいい」と嘲笑するかもしれない。だが、レガシーシステムの保守や、極限まで開発工数を削らなければならないエンタープライズ領域において、コードの「視認性」と「記述量の少なさ」は正義である。
ただし、「便利だからといって何も考えずに呼びまくる」のは素人の所業だ。
オブジェクトのライフサイクル、内部での遅延初期化（Lazy Initialization）、そしてガベージコレクション（GC）のプレッシャーを意識した者だけが、「My」を真にコントロールできる。
—
2. `My.Computer.FileSystem` による極限のファイルI/Oとメモリ最適化
ファイル操作において、VB.NETプログラマーの多くが犯す最大の過ちは、巨大なファイルを読み込む際に `File.ReadAllText` や `ReadAllBytes` を安易に使い、Large Object Heap (LOH) を圧迫してメモリフラグメンテーションを引き起こすことだ。
`My.Computer.FileSystem` は非常にシンプルだが、内部では適切にストリームを管理している。しかし、数GB単位のログファイルやCSVを扱う場合、我々はさらなる一手、すなわち「メモリを枯渇させないストリーム処理」と「Myの簡潔さ」を融合させる必要がある。
実践：巨大ログの安全な非同期走査と例外処理
以下のコードは、`My.Computer.FileSystem` を用いながら、メモリ消費を極限まで抑えて巨大ファイルを安全に処理する実例だ。
.net
Imports System.IO
Imports System.Text
Public Class LogAnalyzer
”’
”’
”’ 対象ファイルのパス
”’ 検索キーワード
Public Shared Function SearchLogEfficiently(filePath As String, keyword As String) As List(Of String)
Dim matchedLines As New List(Of String)
‘ ファイルが存在するかどうかをMyでセキュアに確認
If Not My.Computer.FileSystem.FileExists(filePath) Then
Throw New FileNotFoundException($”指定された監査ログが存在しません: {filePath}”)
End If
‘ System.IO.StreamReaderを直接叩くが、パス解決にはMyの恩恵を受ける
‘ 厳密なリソース解放のため Using ステートメントを強制する（メモリリークの完全撲滅）
Using fs As New FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite),
sr As New StreamReader(fs, Encoding.UTF8)
While Not sr.EndOfStream
Dim line As String = sr.ReadLine()
‘ ヌルチェックとキーワード一致
If line IsNot Nothing AndAlso line.Contains(keyword) Then
matchedLines.Add(line)
‘ 1000件超えたら即座に打ち切る（メモリ保護）
If matchedLines.Count >= 1000 Then Exit While
End If
End While
End Using
Return matchedLines
End Function
End Class
【アーキテクトの知見】
`My.Computer.FileSystem.OpenTextFieldParser` なども強力だが、パフォーマンスがクリティカルなバッチ処理においては、上記の通り `FileStream` とのハイブリッドで実装するのが正解だ。「My」で存在確認や簡易的なテキスト書き込み（`My.Computer.FileSystem.WriteAllText`）を行い、重い処理はネイティブなストリームに委ねる。これが現場における「適材適所」である。
—
3. `My.Application` と Windows API の優雅なる融合
レガシーシステムでは、多重起動の防止、アプリケーション情報の動的取得、さらには独自のエラーハンドリングなど、OSの低レイヤーに触れる必要がある場面が多い。ここで `My.Application` を使うと、面倒なボイラープレートコードをゴッソリ削減できる。
さらに、`My.Application.Info` からはアセンブリのメタデータに一瞬でアクセスできるため、バージョン管理や著作権表示の動的生成が極めて容易になる。
実践：単一インスタンス（Mutex）制御とWindows APIの連動
VB.NETのアプリケーションフレームワーク機能と `My.Application` を組み合わせ、多重起動を完全にブロックしつつ、既存のウィンドウをアクティブ化するプロフェッショナルなコードを示す。
.net
Imports System.Threading
Imports System.Runtime.InteropServices
Namespace My.Internal
‘ ApplicationEvents.vbなどで拡張されることを想定したアーキテクチャ
Public NotInheritable Class StartupGuard
Private Shared Function SetForegroundWindow(hWnd As IntPtr) As Boolean
End Function
Private Shared Function ShowWindow(hWnd As IntPtr, nCmdShow As Integer) As Boolean
End Function
Private Const SW_RESTORE As Integer = 9
”’
”’
Public Shared Sub EnsureSingleInstance(appName As String, targetFormHandle As IntPtr)
Dim mutex As Boolean
Dim sMutex = New Mutex(True, appName, mutex)
If Not mutex Then
‘ 既に起動している場合の処理
My.Application.Log.WriteEntry($”アプリケーション [{appName}] の多重起動が検知されました。処理を中断します。”,
Diagnostics.TraceEventType.Warning)
‘ 既存のプロセスを探して前面に持ってくる高度な処理のフック
Dim currentProcess = Process.GetCurrentProcess()
For Each p As Process In Process.GetProcessesByName(currentProcess.ProcessName)
If p.Id <> currentProcess.Id Then
ShowWindow(p.MainWindowHandle, SW_RESTORE)
SetForegroundWindow(p.MainWindowHandle)
Exit For
End If
Next
‘ 自身は即座に終了（リソースを汚さない）
Environment.Exit(0)
End If
‘ ガベージコレクションによるMutexの早期解放を防ぐため、参照を保持し続ける
GC.KeepAlive(sMutex)
End Sub
End Class
End Namespace
【アーキテクトの知見】
`My.Application.Log` を使うことで、設定ファイル（app.config）と連動したファイル出力やイベントログへの書き込みが驚くほど簡単になる。独自のエラーロガーを車輪の再発明する前に、まずは `My.Application.Log` の拡張性を検討すべきだ。
—
4. レガシー保守における「My」の罠と、シニアが守るべき鉄則
ここまで「My」の素晴らしさを語ってきたが、チーフアーキテクトとして警鐘を鳴らさなければならない点もある。それはスレッドセーフティとインスタンスの寿命だ。
1. `My.Computer.Network` のタイムアウト設定忘れ
ネットワーク通信を行う際、`My.Computer.Network.DownloadFile` は非常に手軽だが、デフォルトのタイムアウトが存在しない（無限待機になる）ケースがある。社内システム連携などで相手サーバーが沈黙した際、スレッドプールが枯渇する致命的な障害に直結する。本番環境で使う場合は、必ずタイムアウトを明示的に指定するか、`HttpClient` への移行を検討すること。
2. UIスレッドと `My.Forms` のアンチパターン
VB.NETには `My.Forms` という、フォームのインスタンスをグローバルに暗黙的参照できる魔術が存在する。VBAの「フォーム名でそのままアクセスできる」仕様を引きずったものだが、これを使うべからず。 マルチスレッド環境や、依存性注入（DI）を前提としたモダンなアーキテクチャにおいて、グローバルなフォーム参照はテスタビリティを完全に破壊する。
—
5. 総括：レガシーとモダンを繋ぐエンジニアの矜持
Visual Basic (VB.NET) は、決して「過去の遺物」などではない。
言語の歴史や背景にあるVBAの血統をリスペクトしつつ、今回解説した `MyNamespace` のような強力な抽象化レイヤーを正しく理解し、パフォーマンスの急所（メモリ管理、ストリーム、API連携）を抑えて実装すれば、C#にも劣らない堅牢かつハイパフォーマンスなシステムを構築できる。
冗長なコードに別れを告げよ。「My」の真の力を引き出し、保守性に優れた美しいコードベースをあなたの手で実装し続けろ。それが、真のプロフェッショナルエンジニアの姿なのだから。
