VB.NETアプリケーションの二重起動防止：Mutexを用いた安全な排他制御と多重起動ハンドリング
現場の業務自動化や社内ツールの開発において、「アプリケーションの二重起動」は単なるユーザーの操作ミスでは済まされない重大な障害原因となります。
複数のプロセスが同時に起動し、同一のローカルファイル（SQLite, CSV, XML）や基幹系データベース、あるいは共有ネットワーク上のリソースに対して同時に書き込みを行えば、デッドロックやデータの破損、サイレントなデータ欠損が発生します。
「VB.NETで二重起動を防ぐ」という要件に対し、未だに `Process.GetProcessesByName` で自プロセス名を検索するような脆弱な実装を見かけることがあります。プロダクション環境で耐えうる堅牢なシステムを構築するためには、OSカーネルレベルでの排他制御メカニズム（Mutex）と、既存インスタンスへフォーカスを遷移させるWin32 APIの正確な理解が不可欠です。
本稿では、数多くのミッションクリティカルな業務システムを設計してきたアーキテクトの視点から、バグを一切排除した完璧な二重起動防止機構の実装手法を伝授します。
—
1. なぜ `Process.GetProcessesByName` による判定は「素人実装」なのか？
まず、なぜプロセス名を検索するロジックが業務アプリケーションで絶対に使ってはならないアンチパターンなのかをロジカルに説明します。
‘ 【絶対NG】脆弱な二重起動チェックの例
Dim stProcessName As String = Process.GetCurrentProcess().ProcessName
If Process.GetProcessesByName(stProcessName).Length > 1 Then
MessageBox.Show(“既に起動しています。”)
End
End If
この実装には、アーキテクチャ上以下の4つの深刻な脆弱性が存在します。
1. タイム・オブ・チェック / タイム・オブ・ユース（TOCTOU）競合状態（TOCTOU Race Condition）
ユーザーがアイコンをダブルクリック、または連続クリックした場合、2つのプロセスが「ほぼ同時に」上記判定ラインを通過します。結果として両者が「他プロセスは存在しない」と判断し、二重起動を許します。
2. 実行ファイル名の変更に対する脆弱性
ユーザーや運用者が `.exe` ファイルの名前を変更（例: `App_old.exe`）した場合、プロセス名が変わり判定を回避できてしまいます。
3. ターミナルサービス / RDP マルチユーザー環境での誤判定
Windows Server環境等で複数のユーザーがリモートデスクトップ接続している場合、他ユーザーの同名プロセスを検知して起動が阻害される、あるいは逆にユーザーセッションを跨いだ排他制御が機能しない事態に陥ります。
4. `Process.GetProcessesByName` の重いオーバーヘッド
OS全プロセスの列挙と名前の比較は、カーネルリソースの消費と処理遅延を引き起こします。
プロフェッショナルが選ぶべき解は、OSのカーネルオブジェクトである`System.Threading.Mutex`（ミューテックス）の一者択一です。
—
2. Mutex（ミューテックス）による排他制御のメカニズムと落とし穴
`Mutex` は、Windows OSのカーネルレベルで提供される同期オブジェクトです。システム全体で一意な名前を持つ Named Mutex を作成することで、ミリ秒以下の精度で確実にアトミックな（不可分の）所有権判定が行えます。
しかし、`Mutex` を使えば無条件で安全というわけではありません。VB.NET開発者が必ずハマる2つの落とし穴が存在します。
落とし穴①：ガベージコレクション（GC）による「勝手な解放」
`Mutex` のインスタンスをローカル変数として生成し、参照を保持しなかった場合、.NETのガベージコレクタ（GC）が「この変数はもう使われていない」と判断して解放（Finalize）してしまいます。結果として、アプリが起動中であるにもかかわらずMutexが滅失し、二重起動が可能になるという謎のバグが発生します。
> 対策: `Mutex` の参照は、アプリケーションの生存期間全体にわたって静的（`Static` / `Shared`）領域に保持し続ける必要があります。
落とし穴②：スコープ指定（`Global\` vs `Local\`）の理解不足
Mutexの名前の先頭につける接頭辞によって、影響範囲が明確に分かれます。
- `Local\MyAppName`（デフォルト）: ログインセッション内でのみ一意。同一ユーザーの二重起動のみ防ぐ。
- `Global\MyAppName`: OS全体（全セッション）で一意。RDP環境や別ユーザーでの起動も含めて全システムで二重起動を防ぐ。
業務ツールにおいて、システム全体で1つしか動かしてはならないプロセスであれば、必ず `Global\` 接頭辞を明示する必要があります。
—
3. UXを最大化する：既存ウィンドウのアクティブ化（Win32 API）
二重起動を検知した際、単にメッセージを出してサイレント終了するだけでは、ユーザーは「なぜアプリが開かないのか」戸惑います。
正解の振る舞いは、「後から起動しようとしたプロセスは即座に終了し、既に起動している既存インスタンスのウィンドウを前面（フォアグラウンド）に移動・復元させる」ことです。
これを実現するためには、Windows APIの `SetForegroundWindow` および `ShowWindowAsync` を正確にP/Invoke（プラットフォーム呼び出し）する必要があります。
—
4. プロダクション環境対応：完全版ソースコード
以下に、そのまま実用プロジェクトへ導入できる、堅牢で保守性の高いVB.NETのプロダクションコードを示します。
WinFormsプロジェクトの「アプリケーションフレームワークを無効化」し、独自の `Sub Main` をエントリーポイントとして設定して使用します。
【実装コード】`Program.vb`
Imports System.Diagnostics
Imports System.Reflection
Imports System.Runtime.InteropServices
Imports System.Threading
Imports System.Windows.Forms
”’
”’
Module Program
Region “Win32 API Declarations”
Private Function SetForegroundWindow(ByVal hWnd As IntPtr) As Boolean
End Function
Private Function ShowWindowAsync(ByVal hWnd As IntPtr, ByVal nCmdShow As Integer) As Boolean
End Function
Private Function IsIconic(ByVal hWnd As IntPtr) As Boolean
End Function
Private Const SW_RESTORE As Integer = 9
End Region
‘ MutexインスタンスをGCに回収されないよう静的参照として保持
Private _appMutex As Mutex = Nothing
”’
”’
Sub Main()
‘ 1. アプリケーション固有のGUIDをAssemblyから取得（または一意の文字列を直接指定）
Dim appGuid As String = GetApplicationGuid()
‘ OS全セッションで一意とするために Global\ を付与
Dim mutexName As String = $”Global\{appGuid}”
Dim createdNew As Boolean = False
Try
‘ 2. Mutexの生成と所有権の初期取得を試みる
‘ 引数: (初期所有権を要求するか, Mutex名, 新規作成されたかのフラグ)
_appMutex = New Mutex(True, mutexName, createdNew)
Catch ex As AbandonedMutexException
‘ 前回のプロセスが異常終了（クラッシュ等）してMutexを解放せずに死んだ場合、
‘ OSから AbandonedMutexException が投げられるが、所有権自体は自プロセスに移る。
createdNew = True
Catch ex As Exception
MessageBox.Show($”システム同期オブジェクトの作成に失敗しました。{vbCrLf}{ex.Message}”,
“起動エラー”, MessageBoxButtons.OK, MessageBoxIcon.Error)
Return
End Try
‘ 3. 二重起動の判定
If Not createdNew Then
‘ 既に別インスタンスが起動している場合
ActivateExistingInstance()
‘ Mutexの破棄と即時終了
If _appMutex IsNot Nothing Then
_appMutex.Close()
_appMutex = Nothing
End If
Return
End If
‘ 4. 正常起動シークエンス
Try
Application.EnableVisualStyles()
Application.SetCompatibleTextRenderingDefault(False)
‘ メインフォームの起動（ご自身のメインフォーム名に変更してください）
Application.Run(New MainForm())
Finally
‘ 5. アプリケーション終了時の確実なリソース解放
If _appMutex IsNot Nothing Then
Try
‘ 所有権を所有している場合のみ解放を実行
_appMutex.ReleaseMutex()
Catch ex As Exception
‘ すでに解放されている場合などの例外は安全に無視またはログ出力
End Try
_appMutex.Close()
_appMutex = Nothing
End If
End Try
End Sub
”’
”’
Private Sub ActivateExistingInstance()
Dim currentProcess As Process = Process.GetCurrentProcess()
‘ 自分以外の同名プロセスを検索（アクティブ化の対象特定のため）
Dim processes As Process() = Process.GetProcessesByName(currentProcess.ProcessName)
For Each proc As Process In processes
‘ 自分自身のPID以外かつ、メインウィンドウハンドルを持っているプロセスを探す
If proc.Id <> currentProcess.Id AndAlso proc.MainWindowHandle <> IntPtr.Zero Then
Dim hWnd As IntPtr = proc.MainWindowHandle
‘ ウィンドウが最小化されている場合は元に戻す
If IsIconic(hWnd) Then
ShowWindowAsync(hWnd, SW_RESTORE)
End If
‘ 最前面に移動してフォーカスを当てる
SetForegroundWindow(hWnd)
Break
End If
Next
End Sub
”’
”’
Private Function GetApplicationGuid() As String
Dim assembly As Assembly = Assembly.GetExecutingAssembly()
Dim attributes As Object() = assembly.GetCustomAttributes(TypeOf GuidAttribute, False)
If attributes.Length > 0 Then
Return CType(attributes(0), GuidAttribute).Value
Else
‘ 万が一GUIDが設定されていない場合のフォールバック（固定の文字列）
Return “YOUR_DEFAULT_FALLBACK_GUID_HERE_12345”
End If
End Function
End Module
—
5. 設計者が知っておくべき「ファイル/DB連携」の注意点
`Mutex` で二重起動をOSレベルで防止しても、外部リソースとの連携部分で設計が甘いと障害を引き起こします。以下のポイントを必ず設計に組み込んでください。
① ネットワーク共有フォルダ上のSQLite / Accessの使用回避
二重起動を防いだとしても、別端末（別PC）から同一のローカルDB（SQLiteやMS Access）を参照された場合、ファイルロック競合が発生します。
- 対策: 複数端末からアクセスされる可能性がある業務ツールの場合、サーバー型DB（PostgreSQL, SQL Server等）を採用するか、Web API経由でのアクセスに設計を変更してください。
② 一時ファイル（Temp File）の衝突防止
アプリケーション内部で `C:\Temp\work.csv` のような固定パスの一時ファイルを作成する設計にしていると、別ユーザーや別端末からの同時実行でファイルロックエラーが発生します。
- 対策: `Path.GetTempFileName()` や `Guid.NewGuid()` を用い、プロセスごとに完全に隔離された一意なパスを動的に生成・使用してください。
③ `AbandonedMutexException` の理解
前回のアプリ実行時に、タスクマネージャーから強制終了されたり、未処理の例外でプロセスがクラッシュしたりすると、Mutexは「放棄された状態（Abandoned）」になります。
上記コードでは `Catch ex As AbandonedMutexException` を明示的に捉えて `createdNew = True` として処理を続行させることで、次回起動不能に陥るゾンビ化現象を回避しています。
—
まとめ
業務ツールの開発において、「動けばいい」という甘い考えで二重起動対策を怠ると、データ破損という最悪の形で代償を払うことになります。
1. プロセス名検索は絶対NG。OSカーネルの `Named Mutex` を使用する。
2. `Global\` スコープを明示し、GC対策のために参照を静的フィールドに保持する。
3. 二重起動時はWin32 APIで既存のUIを前面化し、UXを損なわずに静かに終了する。
4. `AbandonedMutexException` をハンドリングし、クラッシュ後の再起動を担保する。
この設計パターンをチームの標準コーディング規約とし、すべてのVB.NETプロジェクトに適用してください。堅牢なシステム基盤こそが、業務自動化の信頼性を担保する唯一の道です。
