【重複起動時のフォーカス制御】AppActivate を用いた二重起動検知と既存アプリケーションウィンドウの最前面化
レガシーシステムの保全、あるいはRPA前段のランチャー制御において、スクリプトやラッパーアプリケーションの「二重起動の排除」は避けて通れない課題だ。
素朴な実装であれば、プロセスリストを総なめにして判定するWMI（Windows Management Instrumentation）クエリを組むことになる。だが、限られたリソース環境や、ミリ秒単位の応答速度が求められる現場において、重厚長大なおのおののプロセス監視は悪手である。
今回は、WSH（Windows Script Host）のネイティブメソッドである `AppActivate` を極限までチューニングし、システムリソースを食いつぶさずに「重複起動の検知」と「既存ウィンドウの最前面化（フォーカス奪還）」を完結させるためのアーキテクチャを提示する。
—
1. なぜ WMI や外部ツールではなく `AppActivate` なのか
多くのエンジニアは、二重起動防止と聞くと `Win32_Process` を思い浮かべる。しかし、WMIはCOMプロキシを介したプロセス間通信が発生するため、実行コスト（オーバーヘッド）が非常に高い。さらに、スクリプト実行のたびにインスタンスを生成・破棄することは、メモリリークの温床となる。
一方、`AppActivate` は、ウィンドウのタイトルバー文字列、あるいはプロセスの持つウィンドウハンドル（HWND）を直接ターゲットにして、OSのウィンドウマネージャ（User32.dll配下）に働きかける。
ここで重要となるのは、`AppActivate` の二面性だ。
1. 指定したタイトル（またはPID）を持つウィンドウが存在するかを判定し、存在すれば自動的にアクティブ化（最前面化）する。
2. その成否を真偽値（`True` / `False`）で返すため、そのまま二重起動の排他制御フラグとして機能する。
余計なプロセス列挙ループを回す必要はない。OSのウィンドウ管理機構を直接叩く、これが最もエレガントかつローコストな解法である。
—
2. 実装コード：極限まで最適化された排他制御スクリプト
以下のコードは、実務の現場でそのまま投入できる堅牢性を備えたVBScriptである。タイトルの一意性を担保しつつ、多重起動を完全にブロックする。
‘ ==============================================================================
‘ Script Name : SingleInstanceController.vbs
‘ Description : AppActivate を活用した二重起動検知と既存ウィンドウの最前面化
‘ Author : Chief Architect
‘ ==============================================================================
Option Explicit
‘ 定数定義（マジックナンバーの排除）
Const APP_TITLE = “【業務自動化コンソール】Core-System v2.4”
Const ERR_TIMEOUT = 100
Call Main()
Sub Main()
Dim wshShell
Set wshShell = CreateObject(“WScript.Shell”)
‘ 【重要】
‘ AppActivate はウィンドウタイトル（部分一致、または完全なウィンドウ名）を引数にとる。
‘ 既に同名のウィンドウが起動している場合、OSはそれを最前面に持ち上げ、Trueを返す。
‘ 起動していない場合は False を返す。
Dim isActivated
isActivated = wshShell.AppActivate(APP_TITLE)
If isActivated Then
‘ — [ケースA: 既に起動している場合] —
‘ 既存インスタンスにフォーカスを譲り、自身は静かに終了する。
‘ 必要であればここでWshPopup等でオペレーターに警告を出すことも可能。
‘ ログ出力やデバッグが必要な場合はここに記述
‘ Call WriteLog(“重複起動を検知しました。既存ウィンドウをアクティブ化します。”)
Set wshShell = Nothing
WScript.Quit(0)
End If
‘ — [ケースB: 新規起動の場合] —
‘ ここから本来のメイン処理を開始する
‘ ウィンドウタイトルを変更して、次回のAppActivateのターゲットとして認識させる
wshShell.AppTitle = APP_TITLE
‘ メモリの明示的解放（VBScriptにおけるセーフティプラクティス）
Set wshShell = Nothing
‘ メイン処理の実行
Call RunApplicationCore()
End Sub
Sub RunApplicationCore()
‘ 実際の業務ロジックや、他のGUIアプリケーションの起動処理をここに記述
Dim wshShell
Set wshShell = CreateObject(“WScript.Shell”)
wshShell.Popup APP_TITLE & ” を正常に起動しました。”, 2, “起動完了”, 64
‘ 実運用を想定した無限ループ（あるいはメインの処理待機状態）
‘ ※サンプルとしてWScript.Sleepで代用
Do
WScript.Sleep 1000
Loop
Set wshShell = Nothing
End Sub
—
3. シニアエンジニアが押さえるべき「罠」と回避策
`AppActivate` をレガシー環境やモダンなWindows 10/11環境で運用する際、いくつかの強烈なトラップが存在する。これらを事前に潰しておくことが、真に安定したシステムを構築する条件となる。
① 部分一致による誤爆（タイトルのユニーク性）
`AppActivate` は、指定した文字列がウィンドウタイトルに含まれている（部分一致）場合、最初にヒットしたウィンドウをアクティブにしてしまう。もし汎用的なタイトル（例: “エラー” や “システム”）を指定した場合、全く関係のない他のアプリケーションにフォーカスが奪われる惨劇が起きる。
- 対策: タイトルには必ず一意かつ特殊なプレフィックスやバージョン識別子を含めること（例: `【業務自動化コンソール】Core-System v2.4`）。
② プロセス権限の壁（UACと完全整合性レベル）
VBScriptを実行するプロセスが標準ユーザー権限であり、既存のターゲットアプリケーションが「管理者として実行」されている場合、Windowsのセキュリティ境界（UIPI: User Interface Privilege Isolation）により、`AppActivate` はサイレントに失敗（Falseを返すか、フォーカス奪還に失敗）する。
- 対策: システム全体で実行権限のコンテキストを統一する。タスクスケジューラ経由で起動する場合は、実行ユーザーの権限レベルに細心の注意を払うこと。
③ タイミング問題（Race Condition）
アプリケーション起動直後は、ウィンドウハンドル（HWND）が完全に初期化されていない、あるいはタイトルが動的に書き換わっている最中であることがある。この瞬間に `AppActivate` を叩くと、ウィンドウが存在するにもかかわらず失敗することがある。
- 対策: プロセス起動直後のスクリプトであれば、わずかなウェイト（`WScript.Sleep 200` 等）を挟むか、リトライロジックを実装して堅牢性を高める。
—
4. オブジェクトのライフサイクル管理とメモリ最適化
VBScriptのランタイム（`vbscript.dll`）は、COMコンポーネントの参照カウントによってメモリ管理を行っている。ガベージコレクタは存在しない。
スクリプトが肥大化したり、常駐型のラッパーとして組み込まれる場合、`CreateObject` で生成したオブジェクトを放置すると、確実にメモリリーク（VBScript特有のメモリ肥大化現象）を引き起こす。
- ローカル変数の徹底: オブジェクト変数はグローバルスコープに置かず、必ずプロシージャ（Sub/Function）のローカルスコープで宣言する。
- 明示的解放: プロシージャの脱出前、あるいは不要になった時点で必ず `Set object = Nothing` を実行し、参照カウントをデクリメントする。
この規律を破るエンジニアの書いたコードは、数日間稼働させただけでメモリを食い潰し、Windows Serverのタスクマネージャを赤く染め上げる原因となる。
—
総括
`AppActivate` によるフォーカス制御は、レガシーとモダンが混在するWindows環境において、最も軽量かつダイレクトに目的を達成できる手法の一つだ。
APIの挙動、OSのセキュリティ仕様、そしてVBScriptのメモリモデル。これらすべてを熟知した上で構築されたコードだけが、現場の過酷な自動化要求に長期間耐え抜くことができる。車輪の再発明をする前に、OSが標準で備えているプリミティブな機能を極限まで研ぎ澄ませて使い倒すこと。それこそが、真のプロフェッショナルエンジニアの仕事である。
