Visioを幽霊（ゴースト）化するな：完全バックグラウンドPDF変換とプロセス要塞化の極意
バックグラウンド処理において、Microsoft Office製品の制御ほどエンジニアを絶望させる領域はない。特にVisioは、WordやExcelとは異なり、MDI（マルチドキュメントインターフェイス）の系譜を引きずる独特のセッション管理と、COMオブジェクトの異常なまでのしぶとさを持っている。
「`Visio.Application.Visible = False` にしてPDFを出力するだけの簡単な仕事」
そう考えて実装に着手した開発者は、決まってタスクマネージャーの深淵でゾンビ化した無数の `VISIO.EXE` がメモリを喰らい尽くしている悪夢に直面する。画面に出ていないだけで、裏ではCOMサーバーが生死の境界をさまよい続け、ファイルロックをかけ、やがてOSのメモリリソースを枯渇させる。
今回は、エンタープライズ環境のシステム間連携や、社内サーバーでの自動帳票生成パイプラインにおいて「絶対にプロセスを残さない」ための、Visio VBAプロセスマネジメントの極限の知見を公開する。
—
1. Visioバックグラウンド起動のメカニズムと罠
通常、Visioを起動すると、デフォルトのドキュメントテンプレート生成やUIの初期化シーケンスが走る。これをコードから制御する場合、単に `Visible = False` を叩くだけでは不十分だ。
罠の正体：アプケーションの可視性とライフサイクルの乖離
`Visible` プロパティは、あくまで「ウィンドウハンドルの表示状態」を切り替えているに過ぎない。VisioのCOMオブジェクトモデルは、インスタンス生成直後の初期化フェーズにおいて、特定のモーダルダイアログ（テンプレート選択やライセンス確認など）を内部的にスピンさせることがある。バックグラウンド実行（ヘッドレス実行）では、これらがユーザーの目に触れないままバックグラウンドで無限待ちに入り、プロセスがハングアップする。
これを防ぐためには、インスタンス生成直後に「UIを介さない実行コンテキスト」を明示的に構築し、警告やアラートを完全抑制（`ScreenUpdating` および `AlertsEnabled` の無効化）する必要がある。
—
2. ゾンビプロセスを根絶する「完全終了処理（Try-Finally パターン）」
VBAにはC#の `using` ステートメントや、Pythonの `with` ような構文糖衣による自動リソース解放がない。したがって、エラーが発生しようとも、例外がスローされようとも、必ずCOMオブジェクトの参照カウントをデクリメントし、最終的に `Quit` メソッドを叩くための厳格な例外ハンドリング（防御的プログラミング）が求められる。
以下のコードは、実務の現場で耐えうる、メモリリークゼロを目指した完全版のモジュールである。
Option Explicit
‘ エラーハンドリングとプロセス確実消滅を担保したVisioバックグラウンドPDF変換エンジン
Public Sub ExecuteBackgroundPdfConversion(ByVal targetVsdxPath As String, ByVal outputPdfPath As String)
Dim appVisio As Object ‘ Late Binding（レイトバインディング）によるバージョン差異の吸収
Dim docVisio As Object
Dim isAppStarted As Boolean
‘ 予期せぬエラーによるゾンビ化を防ぐため、必ずエラーハンドラを定義
On Error GoTo ErrorHandler
‘ 1. Visio Applicationのバックグラウンド起動
‘ CreateObjectは既存セッションに影響を与えない独立したプロセスを生成する
Set appVisio = CreateObject(“Visio.Application”)
isAppStarted = True
‘ 【極限知見】バックグラウンド処理における必須の最適化フラグ
‘ 描画更新、アラート、警告ダイアログを完全鎮圧する
appVisio.ScreenUpdating = False
appVisio.AlertsEnabled = False
appVisio.Visible = False ‘ 画面描画を完全に排除
‘ 2. ドキュメントのサイレントオープン
‘ ReadOnly:=True, Invisible:=True でメモリ効率を最大化
Set docVisio = appVisio.Documents.OpenEx(targetVsdxPath, &H4 & &H20) ‘ visOpenRO & visOpenHidden
‘ 3. PDFのエクスポート（VisioのネイティブExport機能を使用）
‘ フォーマットID: PDF = 1 (固定値)
docVisio.ExportAsFixedFormat 1, outputPdfPath, 1, 1 ‘ 1:visFixedFormatPDF, 1:visDocExIntentPrint
‘ 4. 正常系クローズ処理
docVisio.Close
Set docVisio = Nothing
‘ アプリケーションの明示的終了
appVisio.Quit
Set appVisio = Nothing
isAppStarted = False
Exit Sub
ErrorHandler:
‘ 致命的なエラーログの記録（実環境ではDebug.PrintをLoggerに置き換えること）
Debug.Print “【Critical Error】Visio PDF Conversion Failed: ” & Err.Description
‘ 5. 異常系クローズ処理（Fail-Safe）
‘ どんなエラーが発生しても、ここで必ずCOMの残骸を掃除する
On Error Resume Next
If Not docVisio Is Nothing Then
docVisio.Close False ‘ 変更を破棄して強制クローズ
Set docVisio = Nothing
End If
If Not appVisio Is Nothing Then
appVisio.Quit
Set appVisio = Nothing
End If
isAppStarted = False
‘ 呼び出し元へエラーを再送出
On Error GoTo 0
Err.Raise Err.Number, “ExecuteBackgroundPdfConversion”, “Visioプロセス処理中にエラーが発生しました: ” & Err.Description
End Sub
—
3. シニアエンジニアが知るべき「メモリ最適化」と「COMの寿命管理」
上記のコードには、単なる「動くコード」を超えた、COMアーキテクチャの急所を突く設計思想が組み込まれている。
レイトバインディング（Late Binding）の採用
コード内では `New Visio.Application` ではなく `CreateObject(“Visio.Application”)` を用いたレイトバインディングを採用している。
企業のデスクトップ環境では、Visio 2013, 2016, 2019, 2021, そしてMicrosoft 365版が混在している。アーリーバインディング（参照設定）を行うと、コンパイル時に特定のType Library（GUID）に縛られ、別バージョンの環境で「Type mismatch」や「Automation error」という致命的なクラッシュを引き起こす。システム間連携やサーバーサイドでの実行を想定する場合、レイトバインディングによるバージョン非依存性の確保は絶対条件である。
参照の完全解放（`Set … = Nothing`）の順番
VBAのガベージコレクションは参照カウント方式（Reference Counting）に依存している。
オブジェクト変数を解放する際は、「子から親へ（ドキュメントからアプリケーションへ）」の順序を厳守しなければならない。
1. `docVisio.Close` の後に `Set docVisio = Nothing`
2. `appVisio.Quit` の後に `Set appVisio = Nothing`
この順序を誤ると、Visioの内部COMサーバーが「まだドキュメントを参照している親プロセスがある」と誤認し、`Quit` を実行してもプロセスがメモリ上に残存する現象（ゾンビ化）を引き起こす。
—
4. 万が一ゾンビ化したプロセスを強制刈り取りする防衛策
どれほど完璧なVBAコードを書いたとしても、Windowsのタスクスケジューラからの強制終了や、ネットワーク切断、メモリパリティエラーなどにより、VisioプロセスがOSの闇に取り残されるリスクはゼロにはならない。
もし、バッチ処理やサーバーサイドで本機能を常時稼働させるのであれば、VBAの実行前後に Windows PowerShell または WMI / Win32_Process を用いたプロセスの強制クレンジング（孤児プロセスの刈り取り） をフックとして組み込むのが、真に堅牢なシステムアーキテクチャというものである。
例えば、VBA実行の直前に以下のロジックを挟む（またはVBScript/PowerShellのオーケストレータ側で制御する）。
PowerShellによるVisioゾンビプロセスの強制殺戮（参考）
Get-Process -Name “VISIO” -ErrorAction SilentlyContinue | Where-Object { $_.MainWindowHandle -eq 0 } | Stop-Process -Force
ウィンドウハンドルを持たない（＝完全にバックグラウンドで迷子になった）`VISIO.EXE` だけを狙い撃ちで消滅させるこの一手間が、システムを数ヶ月間ノンストップで稼働させるための秘訣となる。
—
総括
Visioをバックグラウンドで操り、美しく正確なPDFを出力する――この一見シンプルな要件の裏には、COMのライフサイクル、OSのプロセス管理、そして例外時のフェイルセーフという、ソフトウェアエンジニアリングの基本原則が凝縮されている。
「動けばいい」の境界線を越え、プロセスの生死を完全に掌握したコードを書くこと。それこそが、レガシーとモダンが混在する現場を支える我々インフラ・自動化エンジニアのプライドである。
