【上級】Application.AlertResponseの活用：バックグラウンド処理でのダイアログ抑制と自動応答
Visio VBAによる大規模な図面自動生成や、深夜バッチによる何千ファイルもの一括変換処理。その最中に、予期せぬ「上書き確認」「フォント置換」「リンク切れの警告」などのモーダルダイアログが突如としてポップアップし、進捗バーが永遠にフリーズしたかのように停止する――。
VBAエンジニアであれば、誰もが一度はこの悪夢を経験しているはずだ。
無人運用が絶対条件であるエンタープライズ環境において、人間による「OK」クリックを前提とするアプリケーション挙動は、システム全体の信頼性を崩壊させる致命傷となる。
本稿では、Visioオブジェクトモデルの深層に位置する `Application.AlertResponse` プロパティを軸に、バックグラウンド処理におけるダイアログ完全抑制と、ミリ秒単位の自動応答制御の極意を解説する。
—
1. ダイアログ暴走のメカニズムと `AlertResponse` の本質
VisioはOfficeスイートのなかでも、極めて独自の図形エンジンとファイルI/Oモデルを持つ。図形の削除、ステンシルの強制更新、古いVSDフォーマットからVSDXへの移行など、操作の過程でVBAの実行スレッドは強制的に中断され、Win32 APIの `MessageBox` またはVisio独自の内製ダイアログがモーダル表示される。
ここで `Application.ScreenUpdating = False` や `Application.Interactive = False` を設定するだけでは不十分なケースが多い。特にファイルを開く・保存する際や、外部データ連携を伴う図形更新時には、Visioのアプリケーションコアが対話的な入力を強制的に待機状態にする。
`AlertResponse` とは何か？
`AlertResponse` は、Visioがユーザーへの確認プロンプトを表示しようとした際、「人間が介在したかのように自動で特定のボタン番号を返す」ためのプロパティである。
- データ型: `Long`
- スコープ: `Visio.Application` インスタンス
- 動作原理: ダイアログが表示されるべきタイミングで、Visioはこのプロパティに設定された数値を「ユーザーの選択値」として即座に受け取り、ダイアログを描画することなく処理を続行する。
しかし、このプロパティの挙動を誤ると、意図しないファイル上書きやデータの不可逆的な喪失を引き起こす。シニアエンジニアには、そのライフサイクルとスコープ管理に対する厳格なアプローチが求められる。
—
2. 実装パターン：安全かつ頑健なバッチ処理の構築
実際のエンタープライズ・バッチ処理において、`AlertResponse` を単に `On Error` と組み合わせて使用するだけでは不十分だ。処理の途中でエラーが発生した場合、あるいは想定外のダイアログIDが返された場合を想定し、「必ず元の状態に復元する（Fail-Safe）」設計が不可欠となる。
以下に、実戦で即座に使える堅牢なラッパー構造を持つコードを示す。
Option Explicit
‘ メイン処理：複数図面のバッチクリーンアップとPDF一括エクスポート
Sub ExecuteEnterpriseBatchProcessing()
Dim vsoApp As Visio.Application
Set vsoApp = Visio.Application
‘ 1. 環境退避（State Preservation）
Dim originalScreenUpdating As Boolean
Dim originalInteractive As Boolean
Dim originalAlertResponse As Long
Dim originalEnableEvents As Boolean
originalScreenUpdating = vsoApp.ScreenUpdating
originalInteractive = vsoApp.Interactive
originalAlertResponse = vsoApp.AlertResponse
originalEnableEvents = vsoApp.EnableEvents
On Error GoTo ErrorHandler
‘ 2. 完全無人化モードへ移行
vsoApp.ScreenUpdating = False
vsoApp.Interactive = False
vsoApp.EnableEvents = False ‘ イベントハンドラによる予期せぬダイアログ発生を断つ
‘ [重要] AlertResponseの設定
‘ 1 = vbOK / IDOK または ダイアログの「はい」「OK」に相当するデフォルト応答
vsoApp.AlertResponse = 1
Dim targetFolder As String
targetFolder = “C:\VisioBatch\Target\”
Dim fileName As String
fileName = Dir(targetFolder & “.vsd”)
Do While fileName <> “”
Dim targetPath As String
targetPath = targetFolder & fileName
Call ProcessSingleDocument(vsoApp, targetPath)
fileName = Dir()
Loop
‘ 3. 正常系クリーンアップ
GoTo Finally
ErrorHandler:
‘ 致命的エラーログの記録（実務ではここに専用のLoggerを記述）
MsgBox “バッチ処理中に重大なエラーが発生しました: ” & Err.Description, vbCritical, “Enterprise Batch System”
Finally:
‘ 4. 環境復元（State Restoration – 例外発生時も必ず実行されること）
vsoApp.EnableEvents = originalEnableEvents
vsoApp.AlertResponse = originalAlertResponse
vsoApp.Interactive = originalInteractive
vsoApp.ScreenUpdating = originalScreenUpdating
‘ 5. 明示的なオブジェクト解放
Set vsoApp = Nothing
Debug.Print “バッチ処理が正常に完了しました。”
End Sub
‘ 個別ドキュメントの処理ロジック
Private Sub ProcessSingleDocument(ByVal app As Visio.Application, ByVal filePath As String)
Dim vsoDoc As Visio.Document
‘ ReadOnlyやコンバージョン警告をAlertResponse(1)で自動突破
Set vsoDoc = app.Documents.Open(filePath)
‘ ここに図形データの最適化、シェイプの走査、メタデータ埋め込み処理を記述
‘ 例: 全ページの不要なガイドライン削除など
Dim vsoPage As Visio.Page
For Each vsoPage in vsoDoc.Pages
‘ 処理…
Next vsoPage
‘ 上書き保存（変更がない場合の無駄なI/Oを防ぐフラグ制御）
If vsoDoc.Saved = False Then
vsoDoc.Save
End If
vsoDoc.Close
Set vsoDoc = Nothing
End Sub
—
3. チーフアーキテクトが指摘する「陥りやすい罠」と回避策
罠1: `AlertResponse` の返却値のミスマッチ
Visioが内部で呼び出すダイアログの種類によって、求められる「応答ID」は異なる。
一般的なWindows標準のメッセージボックスであれば `IDOK (1)` や `IDCANCEL (2)` が機能するが、Visio固有のカスタムダイアログ（例：古いVBAプロジェクトのコンパイルエラー、参照切れ、読み取り専用の競合）では、意図したボタン番号と一致せず、依然として処理がブロックされることがある。
対策:
事前に開発環境（GUIあり）で対象の処理を実行し、どのダイアログがどのタイミングで出るかを完全に洗い出すこと。どうしても捕捉できないモーダルダイアログが存在する場合、VBA単体ではなく、外部の常駐型監視プロセス（VB.NET製コンソールアプリやWindows APIによるウィンドウハンドル監視）を併用するアーキテクチャを採用すべきである。
罠2: エラーハンドリングにおける状態のロスト
VBAの `On Error GoTo` 構造は、スコープを抜けない限りエラーフリック状態が持続する。もし `Error` 発生時に `AlertResponse` や `Interactive` の復元処理をスキップしてしまうと、Visioアプリケーションそのものが「人間からの操作を受け付けない、ダイアログに一切応答しないゾンビ状態」と化し、タスクマネージャーからの強制終了を余儀なくされる。
対策:
前述のサンプルコードのように、`GoTo Finally` パターンを厳格に守り、例外時であっても確実に元のプロパティ値を復元するコードパスを担保すること。
罠3: COMオブジェクトの参照リーク
バックグラウンドで何千ものファイルを処理する際、`Visio.Document` や `Visio.Shape` などのオブジェクト変数をループ内で適切に解放 (`Set xxx = Nothing`) しないと、VBAの背後でCOMラッパーの参照カウントが肥大化し、メモリリーク（OutOfMemory）を引き起こす。
特に `For Each` ループ内でのページやシェイプの走査では、メモリ管理に細心の注意を払う必要がある。
—
4. システム間連携への拡張：Windows APIとの融合
さらに高度な制御を求めるならば、Visio VBAの内部からWindows APIを呼び出し、Visioのウィンドウクラスを直接監視・制御するアプローチが考えられる。
‘ 宣言セクションにWin32 APIを定義（必要に応じたウィンドウメッセージ制御）
If VBA7 Then
Declare PtrSafe Function PostMessage Lib “user32” Alias “PostMessageA” (ByVal hwnd As LongPtr, ByVal wMsg As Long, ByVal wParam As LongPtr, ByVal lParam As LongPtr) As Long
Else
Declare Function PostMessage Lib “user32” Alias “PostMessageA” (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
End If
ただし、チーフアーキテクトとしての見解を述べるならば、Visioのプロセス内部からAPIで無理やりダイアログを叩き潰す手法は、バージョンアップ時の互換性リスク（x86/x64のポインタ問題など）を伴うため最終手段とすべきである。
基本方針としては、`Application.AlertResponse` と `Application.Interactive = False` の組み合わせで制御できる範囲にスコープを絞り込み、それでも制御できないレガシーなダイアログが発生する場合は、Visioをアドイン（COM Add-in / .NET Framework or .NET Core）として外側から制御するアーキテクチャへ移行することを強く推奨する。
—
結言
`Application.AlertResponse` は、単なる「ダイアログを消すためのプロパティ」ではない。それは、デスクトップアプリケーションであるVisioを、「完全無人化されたエンタープライズ・バッチパイプライン」へと昇華させるための鍵である。
プロセスのライフサイクルを支配し、例外時を含めた確実な状態復元を実装すること。この基本原則を遵守する者だけが、巨大な図面アセットを伴うシステムの完全自動化という果実を手にすることができる。
