【テクニカル・上級編】【実務直結】Visio VBAでのエラーハンドリング：ページ操作失敗時に「どのページで何が起きたか」を詳細に記録する – Visio VBA解析バイブル

Visio VBA

2026.10.29

【極限の知見】Visio VBAにおける「死のログ」を回避せよ：ページ操作の不確実性を制御するフォレンジック・エラーハンドリング
If VBA7 Then
Else
End If
1. 4. アーキテクトの視点：なぜこれが「極限」なのか
2. 結論

【極限の知見】Visio VBAにおける「死のログ」を回避せよ：ページ操作の不確実性を制御するフォレンジック・エラーハンドリング

大規模なエンタープライズ環境において、Visioの自動化は単なる「図面の描画」ではない。それは、複雑なシステムアーキテクチャやネットワークトポロジ、あるいは膨大なプロセスフローをコードによって構築する、極めてクリティカルなエンジニアリング・タスクである。

しかし、多くの開発者が陥る罠がある。それは、「エラーハンドリングの軽視」だ。

数百、数千のページをループで処理し、レイヤーを操作し、ページ設定を動的に変更していくプロセスにおいて、単に `MsgBox Err.Description` を表示して終了するような実装は、プロフェッショナルの仕事とは呼べない。数時間走らせたバッチ処理が、どのページの、どのレイヤーの、どのタイミングで、どのようなメモリ状態において死んだのか。その「死因（フォレンジック）」を特定できなければ、修正は当て推量に過ぎない。

本稿では、シニアエンジニアが実装すべき、コンテキスト（文脈）を保持した高度なエラーハンドリング・アーキテクチャについて詳述する。

1. 抽象的なエラー情報の限界

一般的なVBA開発者が書くエラーハンドリングは、以下のレベルに留まっている。

' 凡庸な実装例（これでは現場では通用しない）
On Error GoTo ErrorHandler
'... ページ操作処理 ...
Exit Sub

ErrorHandler:
    MsgBox "エラーが発生しました: " & Err.Description
    Exit Sub

このコードには、決定的な情報が欠落している。

どのページ（Name/ID）で発生したか？
そのページのどのレイヤー、あるいはどのShapeにフォーカスがあったか？
エラー発生時のタイムスタンプは？
実行環境のメモリ負荷や、API呼び出しのコンテキストは？

VisioのCOMオブジェクトモデルは、ページ追加や削除の際に内部的なステート（状態）が激しく変動する。エラーが発生した瞬間の「オブジェクトのライフサイクル」を捕捉しなければ、再現性のないバグに一生悩まされることになる。

2. フォレンジック・ログ・アーキテクチャの設計指針

堅牢な自動化システムを構築するには、以下の3つの要素をエラーハンドリングに組み込む必要がある。

A. コンテキストの完全なキャプチャ

エラーが発生した瞬間の `ActivePage` のプロパティ、`Selection` の状態、そして現在処理中のループインデックスをログに書き出す。

B. 明示的なオブジェクトの解放（Memory Management）

Visio VBAはCOMベースである。エラーが発生してプロシージャを抜ける際、参照が残っているとメモリリークを引き起こし、後続のプロセスに致命的な影響を与える。`Set obj = Nothing` を、エラーハンドリングの「Exit」ラインに必ず配置する。

C. 高精度なタイムスタンプとWindows APIの活用

ログの前後関係を正確に把握するため、標準の `Now` 関数だけでなく、必要に応じてWindows APIを用いた高精度な計測を行う。

3. 実装：プロフェッショナル・テンプレート

以下に、私が現場で実際に使用している、詳細なログ出力を伴うエラーハンドリングのテンプレートを示す。

Option Explicit

' Windows API: 高精度な時刻取得やシステム情報の取得に利用
' (ここではログの精度を高めるためにDeclareを使用)
If VBA7 Then
    Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
Else
    Declare Function GetTickCount Lib "kernel32" () As Long
End If

' ログ出力用の定数
Private Const LOG_FILE_PATH As String = "C:\Logs\Visio_Automation_Forensics.log"

''' <summary>
''' メインプロセスのエントリーポイント
''' </summary>
Public Sub ExecutePageAutomation()
    Dim vsoApplication As Visio.Application
    Dim vsoPage As Visio.Page
    Dim i As Integer
    Dim targetPageCount As Integer
    
    ' エラーハンドリングの開始
    On Error GoTo ErrorHandler
    
    Set vsoApplication = Visio.Application
    targetPageCount = 10 ' 例として10ページ処理
    
    Debug.Print "Automation Started at " & Now
    
    For i = 1 To targetPageCount
        ' --- ページ操作のシミュレーション ---
        ' ここでページ追加、サイズ変更、レイヤー操作を行う
        Set vsoPage = vsoApplication.ActiveDocument.Pages.Add()
        vsoPage.Name = "Automated_Page_" & i
        
        ' 意図的なエラー発生テスト (i=5の時にエラーを発生させる)
        If i = 5 Then
            Err.Raise vbObjectError + 513, "PageOperation", "Simulated failure at page 5"
        End If
        
        ' ページ設定の変更（例：サイズ変更）
        vsoPage.PageSheet.CellsU("PageWidth").FormulaU = "14.0 in"
        vsoPage.PageSheet.CellsU("PageHeight").FormulaU = "8.5 in"
        
        Debug.Print "Processed: " & vsoPage.Name
    Next i

CleanUp:
    ' 【重要】オブジェクトの明示的な解放
    ' メモリリークを防ぎ、後続のプロセスへの影響を最小限にする
    Set vsoPage = Nothing
    Set vsoApplication = Nothing
    Exit Sub

ErrorHandler:
    ' 致命的なエラーが発生した場合、詳細なフォレンジック情報を記録
    Call LogDetailedError(Err, i, vsoApplication)
    
    ' エラー発生後も、クリーンアップ処理へ進む
    Resume CleanUp
End Sub

''' <summary>
''' エラー発生時のコンテキストを詳細に記録する
''' </summary>
Private Sub LogDetailedError(ByRef errObj As Err, ByVal currentIndex As Integer, ByRef vsoApp As Visio.Application)
    Dim logMsg As String
    Dim activePageName As String
    Dim activePageID As Long
    Dim tickCount As Long
    
    ' コンテキストの取得
    tickCount = GetTickCount()
    
    On Error Resume Next ' ログ出力自体が失敗しても停止させない
    If Not vsoApp Is Nothing Then
        If Not vsoApp.ActiveDocument Is Nothing Then
            If Not vsoApp.ActivePage Is Nothing Then
                activePageName = vsoApp.ActivePage.Name
                activePageID = vsoApp.ActivePage.ID
            End If
        End If
    End If
    On Error GoTo 0
    
    ' 構造化されたログメッセージの構築
    logMsg = "=====================================================" & vbCrLf
    logMsg = logMsg & "TIMESTAMP: " & Now & " (Tick: " & tickCount & ")" & vbCrLf
    logMsg = logMsg & "ERROR NO: " & errObj.Number & vbCrLf
    logMsg = logMsg & "SOURCE:   " & errObj.Source & vbCrLf
    logMsg = logMsg & "DESC:     " & errObj.Description & vbCrLf
    logMsg = logMsg & "CONTEXT:  Loop Index = " & currentIndex & vbCrLf
    logMsg = logMsg & "PAGE:     Name = " & activePageName & " | ID = " & activePageID & vbCrLf
    logMsg = logMsg & "=====================================================" & vbCrLf
    
    ' ファイルへの書き出し
    Call WriteLogToFile(logMsg)
    
    ' デバッグ出力
    Debug.Print "CRITICAL ERROR: " & errObj.Description & " (Logged to " & LOG_FILE_PATH & ")"
End Sub

''' <summary>
''' ログをファイルに追記する
''' </summary>
Private Sub WriteLogToFile(ByVal message As String)
    Dim fileNum As Integer
    fileNum = FreeFile
    
    ' Appendモードで開く
    Open LOG_FILE_PATH For Append As #fileNum
    Print #fileNum, message
    Close #fileNum
End Sub

4. アーキテクトの視点：なぜこれが「極限」なのか

この実装が、単なる「エラー回避」を超えて「エンジニアリング」である理由は以下の点に集約される。

1. ステートフルなエラー捕捉

`currentIndex` や `activePageName` を引数として渡すことで、エラー発生時の「空間的・時間的な位置」を特定している。これは、分散システムにおける分散トレーシングの考え方と同じである。

2. 堅牢なクリーンアップ・パス

`Resume CleanUp` という設計は、エラーが発生しても「必ずオブジェクトを破棄して終了する」という強い意志の現れだ。Visioのような重量級のアプリケーションを制御する場合、この「後片付け」の徹底が、サーバー上での長時間稼働における安定性を決定づける。

3. フォールトトレラントなロギング

`LogDetailedError` 内で `On Error Resume Next` を使用している点に注目してほしい。ログ出力処理自体がファイル権限エラーなどで失敗したとき、本来のエラーハンドリングが二次災害を起こしてシステム全体をクラッシュさせることは、絶対に避けなければならない。

結論

Visio VBAによる自動化を、単なるスクリプトから「信頼に足るシステム」へと昇華させるためには、正常系に費やすエネルギーと同じ、あるいはそれ以上のエネルギーを異常系（エラーハンドリング）に投下すべきである。

「どのページで何が起きたか」を瞬時に、かつ正確に語るログ。それこそが、伝説的なエンジニアが手にする最強の武器である。