Visio VBAを掌握する極限の知見：`EventsEnabled`で無限ループの悪夢を断ち切る安全なイベント駆動設計
開発プロジェクトの現場で、こんな恐怖を体験したことはないだろうか。
「図形のテキストを書き換えるマクロを書いた。よし、ついでにテキストが変更されたら自動で別の図形の色も連動するようにイベントハンドラを仕掛けよう」――そしてF5キーを押した瞬間、Visioのプロセスが完全にフリーズし、ファンの音が爆音に変わり、タスクマネージャーでの強制終了を余儀なくされる。
これが、素人が陥る「イベント連鎖の無限ループ地獄」だ。
Visio VBAにおけるイベント駆動型プログラミングは、高度な自動化ツールを作る上で不可欠な武器だが、オブジェクトモデルの挙動を深く理解していないと、一瞬でシステムを破壊する諸刃の剣となる。
今回は、Visioの深部を知り尽くしたチーフアーキテクトの視点から、`Application.EventsEnabled`プロパティを完全制御し、実務で絶対に破綻しない堅牢なイベント駆動アーキテクチャの構築手法を伝授する。
—
なぜ無限ループが発生するのか？（本質的な原因）
Visioのイベントモデルは、ユーザーの操作だけでなく、VBAコードによるプロパティの変更（`Shape.Text`や`Cell.Formula`の書き換えなど）に対しても容赦なくトリガーされる。
例えば、以下のような処理を組んだとする。
1. ユーザーが図形Aのテキストを変更する。
2. `ShapeChanged` イベントが発火し、イベントハンドラが呼び出される。
3. イベントハンドラ内で、図形Aのテキストを「処理済み」に書き換えるコードを実行する。
4. この書き換え自体が再び `ShapeChanged` イベントを引き起こす。（1に戻る）
これが無限ループのメカニズムだ。 Visioのイベントキューはシングルスレッドで処理されるため、イベント処理の最中に自身を発火させる変更を加えると、スタックオーバーフローやハングアップを引き起こす。
ここに立ち向かうには、「どのタイミングでイベントの監視を遮断し、どのタイミングで安全に復旧させるか」というライフサイクルの制御が不可欠となる。
—
堅牢な設計の要：`Application.EventsEnabled`
この無限ループを物理的に遮断するための唯一無二のプロパティが、`Application.EventsEnabled` である。
‘ イベントの検知を完全に無効化
Application.EventsEnabled = False
‘ — この間に行われたVBAによる図形変更は、一切イベントを発火させない —
‘ イベントの検知を再有効化
Application.EventsEnabled = True
このプロパティを適切に配置することで、VBA自身による変更と、ユーザーによる手動変更を明確に切り分けることができる。
しかし、実務の現場では、ここで大きな落とし穴がある。「エラーハンドリングを怠ると、エラー発生時に `EventsEnabled = False` のままになり、Visio全体がイベント無効のままフリーズ状態になる」という問題だ。
これを防ぐためには、VBAのエラーフック（`On Error Goto`）を組み合わせた「確実な復旧保証パターン」が必須となる。
—
【プロダクションコード】安全なイベント駆動型プログラみの実装例
ここからは、実務の現場でそのままコピペして使える、堅牢なイベント実装の模範コードを提示する。
この実装では、以下の要件を満たしている。
1. 図形のテキストが変更されたことを検知する。
2. その変更がプログラムによるものでない場合のみ、別の図形（ログ用テキストボックスなど）の値を安全に更新する。
3. 万が一のエラー時でも確実に `EventsEnabled` を復旧させる。
1. クラスモジュール：`clsEventSink` （イベントの受け皿）
まず、Visioのアプリケーションイベントを捕捉するためのクラスモジュールを作成する。
‘ =================================ヤマモト・アーキテクチャ・グループ================================
‘ クラスモジュール名: clsEventSink
‘ 概要: Visioのアプリケーションイベントを安全にフックするクラス
‘ ====================================================================================
Option Explicit
‘ WithEventsキーワードを使い、Applicationオブジェクトのイベントを捕捉
Public WithEvents VisApp As Visio.Application
‘ イベントハンドラ: 図形が変更された瞬間に発火
Private Sub VisApp_ShapeChanged(ByVal Sheet As Visio.IVShape)
‘ 無限ループ防止フラグ（多重実行ガード）
Static isProcessing As Boolean
‘ すでに処理中の場合は、再入を即座にブロック
If isProcessing Then Exit Sub
‘ アプリケーション全体のイベントが有効かチェック
If Not VisApp.EventsEnabled Then Exit Sub
On Error GoTo ErrorHandler
isProcessing = True
‘ —————————————————-
‘ ここから実際のビジネスロジック（安全な領域）
‘ —————————————————-
‘ 例: 「TargetShape」という名前の図形以外が変更された場合、処理をスキップ
If Sheet.NameU <> “TargetShape” Then GoTo Finally
‘ 【重要】プログラムからプロパティを変更する前に、必ずEventsEnabledを落とす
VisApp.EventsEnabled = False
‘ 業務ロジック: 別の図形（LogBox）のテキストを更新する
Dim targetPage As Visio.Page
Set targetPage = Sheet.ContainingPage
Dim logShape As Visio.Shape
Set logShape = targetPage.Shapes.Item(“LogBox”)
‘ テキストの書き換え（通常ならこれでイベントが連鎖するが、EventsEnabled=Falseなので安全）
logShape.Text = “最終変更図形: ” & Sheet.Name & ” / 時刻: ” & Format(Now, “hh:nn:ss”)
Finally:
‘ 確実にイベントを再有効化
VisApp.EventsEnabled = True
isProcessing = False
Exit Sub
ErrorHandler:
‘ 異常終了時でも必ずイベントとフラグを復旧させる（これがないとVisioが死にます）
VisApp.EventsEnabled = True
isProcessing = False
MsgBox “イベント処理中にエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
End Sub
2. 標準モジュール：`modEventManager` （イベントのライフサイクル管理）
次に、クラスのインスタンスを生成し、Visioセッションに紐付ける標準モジュールを記述する。
‘ ====================================================================================
‘ 標準モジュール名: modEventManager
‘ 概要: イベントシンクのライフサイクル（有効化・破棄）を制御する
‘ ====================================================================================
Option Explicit
‘ グローバル変数として保持することで、イベントのリスニングを維持する
Public EventSink As clsEventSink
‘ イベント監視を開始するエントリーポイント
Sub StartEventMonitoring()
‘ すでに起動している場合は二重起動を防ぐ
If Not EventSink Is Nothing Then
MsgBox “すでにイベント監視は稼働中です。”, vbInformation
Exit Sub
End If
Set EventSink = New clsEventSink
Set EventSink.VisApp = Visio.Application
‘ Visioのイベント有効化
Visio.Application.EventsEnabled = True
MsgBox “Visioイベント監視システムが正常に稼働を開始しました。”, vbInformation
End Sub
‘ イベント監視を停止し、メモリを解放する
Sub StopEventMonitoring()
Set EventSink = Nothing
Visio.Application.EventsEnabled = True ‘ 安全のため有効に戻す
MsgBox “イベント監視を停止しました。”, vbInformation
End Sub
—
データベースや外部ファイル連携時のアーキテクチャ注意点
このイベント駆動モデルを拡張し、図形の変更をトリガーにして「外部データベース（SQL Server等）への自動保存」や「Excel/CSVファイルへのログ出力」を行うシステムを構築する場合、さらに高度な配慮が必要になる。
1. I/Oレイテンシの遮断
データベースへの書き込みやファイルの入出力には、VBAの内部処理に比べて圧倒的な時間がかかる。イベントハンドラ内で同期的にDBアクセスを行うと、ユーザーが図形を高速でドラッグ＆ドロップした際にVisioのUIが完全にフリーズする。
- 対策: イベントハンドラ内では重い処理を直接行わず、変更された図形のID（`Shape.ID`）やユニークなカスタムプロパティをコレクションやキューに蓄積し、タイマー処理（あるいは非同期バッチ）でまとめて処理する設計（キューイングモデル）を採用すること。
2. トランザクション整合性と無限ループの二重防壁
外部APIやDB更新に失敗した場合のリトライ処理などで再度図形プロパティをロールバックさせる際、誤って `EventsEnabled = True` のまま書き換えると、エラーハンドラー内で無限ループが再発する。エラー時こそ `EventsEnabled = False` を徹底するコードレビューの習慣が、プロジェクトの生死を分ける。
—
チーフアーキテクトからの総括
Visio VBAにおけるイベントプログラミングは、使いこなせば「ただのお絵描きソフト」を「極めてスマートな業務プロセスイネーブラー」へと変貌させることができる。
しかし、その裏側にあるオブジェクトのライフサイクルとイベントの連鎖構造を軽視したコードは、現場にバグの爆弾を仕込むようなものだ。
- 「VBAからの変更であっても容赦なくイベントは発火する」
- 「`EventsEnabled = False` とエラーハンドリングのセットは絶対の掟」
この2点を骨身に刻み、堅牢で美しいプロダクションコードを君の手で実装してほしい。プロジェクトの成功は、こうした細部のエンジニアリングの徹底にかかっている。
