VB.NETを掌握する極限の知見：`My`名前空間の全貌 — 冗長なボイラープレートを駆逐し、実務コードを極限まで洗練させる方法
開発現場を見渡すと、いまだに `System.IO.Directory.GetFiles` や `System.Environment.GetFolderPath` といった長大なフルパス記述、あるいはスレッドコンテキストを意識しすぎた冗長なアプリケーション情報取得コードをあちこちに散りばめているエンジニアを見かける。
ハッキリ言おう。それは車輪の再発明であり、保守性を自らドブに捨てる行為に等しい。
VB.NETには、言語仕様の歴史が生んだ最高の隠し味——いや、最強の武器である `My` 名前空間（Myオブジェクト） が標準で用意されている。.NETの膨大なクラスライブラリの海から、実務で頻出するオブジェクトを極限までカプセル化し、「最も直感的で、最も安全なAPI」として我々に提供してくれているのがこの `My` である。
今回は、この `My` 名前空間の深淵を覗き、業務自動化ツールやデスクトップアプリケーション開発において、コードを圧倒的に美しく、かつ鉄壁の堅牢性を持たせるための極意を伝授する。
—
1. なぜ「`My`」を使うべきなのか？ ―― アーキテクチャの視点
多くのC#出身者や、ベテランのVB.NET開発者ですら、「`My` は初心者向けの糖衣構文（シンタックスシュガー）に過ぎない」と誤解して敬遠しがちだ。だが、それは大きな間違いである。
`My` が提供する機能の本質は、以下の3点に集約される。
1. ボイラープレート（定型コード）の徹底的な排除:
インスタンス化の必要性、例外処理のラップ、リソース解放の配慮など、本来ビジネスロジックに関係のない「お作法」を内部で隠蔽している。
2. コンテキストの自動解決:
現在のスレッド、アプリケーションの実行環境、ユーザーのセキュリティコンテキストを自動で検知し、最適なオブジェクトを返す。
3. レジリエンス（回復力）の向上:
例えばファイル操作やネットワーク疎通において、開発者がミスしやすい境界条件（Null参照や権限不足など）を安全にハンドリングする設計があらかじめ組み込まれている。
それでは、実務で即座に使える主要な `My` オブジェクトの具体的な活用法を見ていこう。
—
2. `My.Computer.FileSystem`：ファイル・ディレクトリ操作の決定版
業務自動化ツールにおいて、ファイルシステムとの対話は避けて通れない。`System.IO` を直接叩くコードは、パスの結合ミスや例外処理の漏れを引き起こしやすい。`My.Computer.FileSystem` を使えば、これらを安全かつエレガントに記述できる。
実務での活用例：安全なログファイル出力とディレクトリ監視
以下のコードは、日別ログの出力、古いログの自動削除、および安全なファイルコピーを `My.Computer.FileSystem` によって極限まで簡潔に実装したプロダクションコードである。
.net
Imports System.IO
Public NotInheritable Class FileOperationManager
‘ プライベートコンストラクタでインスタンス化を抑止（静的クラスとしての設計）
Private Sub New()
End Sub
”’
”’
”’ 書き込むメッセージ
Public Shared Sub WriteLog(logMessage As String)
‘ アプリケーションの実行フォルダ基準でログディレクトリを特定
Dim logDirectory As String = Path.Combine(My.Application.Info.DirectoryPath, “Logs”)
‘ ディレクトリが存在しない場合は自動作成（System.IOだと確認が必要だがMyなら1行）
If Not My.Computer.FileSystem.DirectoryExists(logDirectory) Then
My.Computer.FileSystem.CreateDirectory(logDirectory)
End If
‘ 本日のログファイルパス
Dim logFileName As String = $”Log_{DateTime.Now:yyyyMMdd}.log”
Dim logFilePath As String = Path.Combine(logDirectory, logFileName)
‘ タイムスタンプを付与して追記 (Append = True)
Dim formattedMessage As String = $”[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] {logMessage}”
Try
‘ My.Computer.FileSystem.WriteAllText は内部で適切な排他制御とファイル閉塞を行う
My.Computer.FileSystem.WriteAllText(logFilePath, formattedMessage & Environment.NewLine, append:=True)
Catch ex As Exception
‘ ログ書き込み失敗時のフォールバック（イベントログやコンソールへ）
System.Diagnostics.Trace.WriteLine($”ログ書き込み致命的エラー: {ex.Message}”)
End Try
End Sub
”’
”’
Public Shared Sub ArchiveFile(sourceFilePath As String, targetDirectory As String)
If Not My.Computer.FileSystem.FileExists(sourceFilePath) Then
Throw New FileNotFoundException($”対象ファイルが見つかりません: {sourceFilePath}”)
End If
If Not My.Computer.FileSystem.DirectoryExists(targetDirectory) Then
My.Computer.FileSystem.CreateDirectory(targetDirectory)
End If
Dim fileName As String = Path.GetFileName(sourceFilePath)
Dim destFilePath As String = Path.Combine(targetDirectory, fileName)
‘ 同名ファイルが存在する場合は上書きを許可しつつ、コピー処理を実行
‘ overwrite:=True を指定することで例外を防ぐ
My.Computer.FileSystem.CopyFile(sourceFilePath, destFilePath, overwrite:=True)
‘ コピー成功後に元ファイルを削除
My.Computer.FileSystem.DeleteFile(sourceFilePath)
End Sub
End Class
> プロの知見:
> `System.IO.File.Copy` でも上書き指定は可能だが、ディレクトリの自動作成や存在チェックを組み合わせた場合のコード量は `My.Computer.FileSystem` の方が圧倒的に少ない。特に保守フェーズにおいて、「余計なコードがないこと」は最大の正義である。
—
3. `My.Application`：アプリケーション情報の掌握と多重起動防止
デスクトップ自動化ツールを作る際、最も厄介なバグの一つが「多重起動によるリソース競合（データベースのロックやファイルアクセス違反）」である。
`My.Application` を利用すれば、OSレベルのミューテックス（Mutex）制御を意識することなく、スマートに多重起動を検知・防止できる。
実務での活用例：Windowsアプリケーションの堅牢な起動制御
.net
Imports Microsoft.VisualBasic.ApplicationServices
Public Class ApplicationInitializationManager
”’
”’
Public Shared Sub ValidateSingleInstance()
‘ My.Application.Info を使えば、AssemblyMetadataに依存せずアセンブリ情報を一発取得
Dim appTitle As String = My.Application.Info.Title
Dim versionStr As String = My.Application.Info.Version.ToString()
System.Diagnostics.Trace.WriteLine($”起動中: {appTitle} (Version: {versionStr})”)
‘ 現在のユーザー名やコンピュータ名もMyから瞬時に取得可能
Dim currentUser As String = My.User.Name
Dim machineName As String = My.Computer.Name
‘ ログや監査証跡にこのコンテキストを自動付与するアーキテクチャが望ましい
End Sub
End Class
実際の多重起動防止は、プロジェクトのプロパティから「シングル インスタンス アプリケーションを作成する」にチェックを入れるだけで、`My.Application` が裏側で `StartupNextInstance` イベントを発火させ、既存のインスタンスを前面に持ってくる処理を自動代行してくれる。これを自前で実装しようとすると数十行のWin32 APIやMutexコードが必要になるが、VB.NETなら一瞬で完結する。
—
4. `My.Computer.Network`：死活監視とリモート連携
業務自動化ツールが社内サーバーやWebAPIと連携する際、「ネットワークが切断されている状態」で処理を実行し、未処理例外でクラッシュするトラブルは後を絶たない。
`My.Computer.Network` を使えば、リクエストを投げる前の「事前の死活確認（Ping）」を極めて低コストで実装できる。
実務での活用例：API連携前のネットワーク疎通チェック
.net
Public Class NetworkGuard
”’
”’
”’ IPアドレスまたはホスト名
”’
Public Shared Function CanConnectToServer(hostOrAddress As String) As Boolean
Try
‘ タイムアウトを1000ms（1秒）に設定してPingを送信
‘ My.Computer.Network.Ping は内部でICMPパケットを飛ばす安全なラッパー
Dim isReachable As Boolean = My.Computer.Network.Ping(hostOrAddress, timeout:=1000)
If Not isReachable Then
System.Diagnostics.Trace.WriteLine($”警告: サーバー {hostOrAddress} へのPingがタイムアウトしました。”)
End If
Return isReachable
Catch ex As System.Net.NetworkInformation.PingException
‘ ネットワークアダプタが無効な場合などの例外をキャッチ
System.Diagnostics.Trace.WriteLine($”ネットワークエラー: {ex.Message}”)
Return False
Catch ex As Exception
‘ その他の予期せぬ例外
Return False
End Try
End Function
End Class
—
5. 堅牢な設計のためのアンチパターンと注意点
ここまで `My` 名前空間の素晴らしさを説いてきたが、伝説的なアーキテクトとして、誤った使い方（アンチパターン）についても厳重に警告しておかなければならない。
アンチパターン1: マルチスレッド環境での `My.Application` への過度な依存
`My.Application` や `My.User` の一部のプロパティは、現在のスレッドコンテキスト（UIスレッドやメインスレッド）に強く結びついている場合がある。バックグラウンドのワーカースレッド（`Task.Run` や `BackgroundWorker` 内）から無闇に `My` の特定プロパティを呼び出すと、予期せぬコンテキスト消失やスレッド競合を引き起こすことがある。
- 解決策: バックグラウンド処理に移行する前に必要な値（パスやユーザー名など）をローカル変数に退避させ、その変数を渡す設計にすること。
アンチパターン2: 例外を握りつぶす設計への悪用
`My` のメソッドは安全性を高めるために内部で例外処理を適切に行っているものが多いが、だからといって「エラーハンドリングを一切書かなくてよい」わけではない。特にファイルI/Oやネットワーク操作では、最終的なビジネスロジック側で「失敗したときにどうリカバリするか（リトライするのか、処理を中断するのか）」のポリシーを必ずコードで明示すべきである。
—
総括：開発生産性を極限まで高めるために
Visual Basic / VB.NETという言語は、その歴史の長さゆえに「古い言語」と誤解されがちだ。しかし、現場の課題を最速で解決し、堅牢な業務自動化ツールを組み上げるスピードにおいては、C#や他のどのモダン言語をも凌駕するポテンシャルを秘めている。
そのポテンシャルの核となるのが、今回解説した `My` 名前空間 である。
冗長なコードを書く時間は、ビジネスの価値を生み出さない。
`My` を使いこなし、ボイラープレートをコードベースから駆逐せよ。そして、あなたにしか書けない本質的なビジネスロジックと堅牢なアーキテクチャの構築に、全リソースを集中させるのだ。それこそが、真のプロフェッショナルエンジニアの仕事である。
