【VB.NET】二重起動防止の極致：Mutexによる堅牢なプロセス排他制御
業務アプリケーションにおいて「多重起動」は、単なるユーザーの操作ミスでは済まされない。データベースのロック、ログファイルの競合、そして何より「どのプロセスが正当な処理を行っているのか」という責任の所在が曖昧になる。
中級エンジニアであれば、「プロセス名で検索して終了させる」といった泥臭い手法を一度は思いつくだろう。だが、それはプロの解ではない。今回は、OSレベルの排他制御メカニズムである`Mutex`を用い、実務で絶対にバグらせない「真の二重起動防止」を伝授する。
—
1. なぜ「プロセス名検索」では不十分なのか
多くの初学者は `Process.GetProcessesByName` を使って実行中のプロセスを探そうとする。しかし、これには明確な欠陥がある。
- 競合のリスク: アプリケーション起動直後の「起動チェック」と「実際の処理開始」の間に、別のプロセスが割り込む隙間（Race Condition）が存在する。
- 権限の問題: 異なるユーザー権限で実行されている場合、プロセス情報の取得に失敗することがある。
- リソースの浪費: ループでプロセスリストを走査するのは、アーキテクチャとしてエレガントではない。
Mutex（相互排他オブジェクト）は、OSのカーネルが管理する同期プリミティブだ。名前付きミューテックスをシステム全体で一意に確保することで、OSに「この名前の処理は今、世界で一つしか存在してはならない」と宣言する。これが最も堅牢でパフォーマンスの高い解法だ。
—
2. 実装コード：プロダクションレベルの「守り」
単にMutexを置くだけでは足りない。アプリケーション終了時に適切に解放しなければ、最悪の場合、OSの再起動までアプリが二度と立ち上がらなくなる。
以下は、`ApplicationEvents.vb` または `Main` メソッドで実装すべき、枯れたパターンだ。
Imports System.Threading
Public NotInheritable Class AppController
‘ ミューテックスを保持するための変数
‘ GCによって回収されないよう、スコープを広げて保持する
Private Shared _mutex As Mutex
Public Shared Sub Main()
‘ アプリを一意に識別するためのユニークな文字列（GUIDを推奨）
Dim mutexId As String = “Global\MyCompany_BusinessTool_2023_V1”
Dim createdNew As Boolean
‘ ミューテックスを要求
_mutex = New Mutex(True, mutexId, createdNew)
If Not createdNew Then
‘ 他のプロセスが既にMutexを所有している場合
MessageBox.Show(“既にアプリケーションが起動しています。”,
“起動エラー”, MessageBoxButtons.OK, MessageBoxIcon.Warning)
Return
End If
Try
‘ メインフォームの起動
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
Application.Run(New MainForm())
Finally
‘ 終了時は必ず解放する（忘れるとOSのメモリリークを招く）
If _mutex IsNot Nothing Then
_mutex.ReleaseMutex()
_mutex.Dispose()
End If
End Try
End Sub
End Class
—
3. 実務で「事故」を起こさないための設計指針
A. グローバル名前空間の罠
`Global\` プレフィックスを付けることで、ターミナルサービス（リモートデスクトップ等）環境下でも、ユーザーセッションを超えて排他制御が可能になる。業務ツールをサーバー上で運用する場合、この指定は必須だ。
B. 異常終了時の挙動
OSのクラッシュやプロセス強制終了時、Mutexはどうなるのか？
結論から言えば、.NETのMutexは「所有者が解放せずに終了した場合」に、OS側で適切に破棄される。そのため、前述の `Try…Finally` をしっかり記述しておけば、デッドロックに陥る心配はまずない。
C. データベースとの連携
多重起動を防止しても、データベース側の接続は別問題だ。
- 接続文字列の統一: どのインスタンスから見ても一意なDBファイル/サーバーを参照すること。
- ロックファイルの活用: もしSQLite等を使うのであれば、Mutexと併用して物理的なロックファイル（.lock）を生成し、二重の防御壁を作るのが、大規模開発における私の定石だ。
—
結論：コードは「防御」である
プログラムを書くとは、単に仕様を実現することではない。「起こりうる最悪の事態（バグ）」を事前に遮断することだ。
Mutexによる制御は、コード行数こそわずかだが、その背後にある排他制御の思想は極めて重い。あなたが書くその1行が、現場のデータ破損を防ぎ、管理者の深夜のトラブルシューティングを未然に防ぐ。
「動けばいい」という考えは卒業しよう。「落ちるはずのないコード」を書くことこそが、エンジニアとしての真の価値である。
