Visio VBAを掌握する極限の知見：ページ削除の罠と「逆順ループ」による完全無欠なオブジェクト防衛策
Visio VBAを用いた大規模な図面自動生成や、世代管理システムのバッチ処理において、最も頻発し、かつ開発者を絶望の淵に追い込むバグの一つが「ページ削除時のオブジェクト参照エラー」だ。
「なぜ、存在するはずのページを指定しているのに `Error 9: インデックスが有効範囲にありません` が発生するのか？」
「なぜ、動的配列のように詰めていく削除処理で、途中から不可解な例外が飛ぶのか？」
本稿では、Visioのドキュメント構造とCOMオブジェクトのライフサイクルを熟知したシニアエンジニア向けに、ページ一括削除・整理処理における根本的な地雷を踏み抜かないための「逆順ループ」による極限の安全実装を解説する。
—
1. 敗北の構文：なぜ「正順ループ」は必ず破綻するのか
多くのプログラマブルな初学者が、あるいは他言語の感覚のままVBAに入ったエンジニアが最初に書く「間違ったコード」から始めよう。
以下のコードを見てほしい。一見すると、何の問題もない美しいループに見えるはずだ。
‘ 【アンチパターン】絶対にやってはいけない正順ループによるページ削除
Sub DeleteAllPages_Bad()
Dim i As Long
Dim vsoPages As Visio.Pages
Set vsoPages = ActiveDocument.Pages
‘ 先頭から順に削除しようとするアプローチ
For i = 1 To vsoPages.Count
‘ 警告: ページを削除するとインデックスが動的に詰まるため破綻する
vsoPages(i).Delete
Next i
End Sub
何が起きているのか？（COMコンテナの動的シフト）
Visioの `Document.Pages` コレクションは、内部的に動的なC++のコンテナ（あるいはCOMのIEnumVARIANTラッパー）として実装されている。
1. ループ初回 (`i = 1`)：1番目のページ（Page-1）を削除する。
2. 削除の瞬間：それまで2番目にいたページ（Page-2）が、自動的に 1番目に繰り上がり（Shift） を起こす。
3. ループ2回目 (`i = 2`)：制御変数がインクリメントされ、元のPage-2（現在は1番目）をスキップし、元のPage-3（現在は2番目）をターゲットにしてしまう。
4. 最終的に：`Count` の半分程度を処理した段階で `Runtime Error`、あるいは存在しないインデックスを参照してクラッシュする。
この挙動は、VBAランタイムとVisioエンジン間におけるCOMポインタのズレに起因しており、デバッグ実行しても追いにくい厄介なバグを生む。
—[AD: 複雑なVisio自動化の設計・パフォーマンスチューニングのご相談はこちら]—
—
2. 解決策：逆順ループ（Decrement Loop）によるインデックスの完全固定
この物理的な矛盾を解決する唯一にして至高の布石が、コレクションの末尾から先頭に向かって処理を進める「逆順ループ（`For i = Count To 1 Step -1`）」である。
なぜ逆順なのか？
末尾のページを削除した場合、それより前にあるインデックス（1から `Count – 1` までの要素）は一切影響を受けない。つまり、削除によってインデックスがズレるのは「すでに処理が終わった安全地帯（右側）」だけであり、これから処理する「未処理の領域（左側）」のインデックスは完全に保全される。
実務でそのまま使える、堅牢性を極限まで高めたページ削除の決定版コードを提示する。
Option Explicit
”’
”’
Sub PurgePagesSafely()
Dim vsoDoc As Visio.Document
Dim vsoPages As Visio.Pages
Dim vsoPage As Visio.Page
Dim i As Long
Dim deletedCount As Long
‘ アクティブドキュメントの取得（エラーハンドリングの前提）
Set vsoDoc = ActiveDocument
If vsoDoc Is Nothing Then
MsgBox “アクティブなドキュメントが存在しません。”, vbCritical
Exit Sub
End If
Set vsoPages = vsoDoc.Pages
deletedCount = 0
‘ 画面描画とイベントを停止し、処理速度を極限まで引き上げる（メモリ・パフォーマンス最適化）
Application.ScreenUpdating = False
Application.EventsEnabled = False
On Error GoTo ErrorHandler
‘ 【極限の知見】末尾から先頭へ向かう逆順ループ
For i = vsoPages.Count To 1 Step -1
Set vsoPage = vsoPages(i)
‘ 例：名前に “Temp_” が含まれるページだけを削除する場合
‘ ※すべて削除する場合はこのIf文を外してください
If Left(vsoPage.Name, 5) = “Temp_” Then
‘ Visioの仕様上、ドキュメントには最低1枚のページが必要なため、
‘ 最後の1枚を削除しようとした場合のガード処理
If vsoPages.Count > 1 Then
vsoPage.Delete
deletedCount = deletedCount + 1
Else
Debug.Print “警告: ドキュメントの最後の1ページは削除できません。”
End If
End If
‘ オブジェクト変数を即座に解放（メモリリーク防止）
Set vsoPage = Nothing
Next i
‘ 処理完了後のクリーンアップ
Application.ScreenUpdating = True
Application.EventsEnabled = True
MsgBox deletedCount & ” 件のページを正常に削除しました。”, vbInformation
Exit Sub
ErrorHandler:
‘ 異常終了時のフォールバック（画面描画の復旧を確実に行う）
Application.ScreenUpdating = True
Application.EventsEnabled = True
Set vsoPage = Nothing
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
End Sub
—
3. シニアアーキテクトが実践する「メモリ最適化」と「エラー防衛」の極意
前述のコードには、単なる「逆順ループ」の他にも、実務レベルのシステムで生き抜くための重要なアーキテクチャ上の工夫が施されている。
A. `Application.ScreenUpdating` と `EventsEnabled` の徹底管理
Visio VBAにおいて、ページ削除やシェイプの生成は、GUIの再描画（Redraw）とイベントハンドラのフックを誘発する。数百ページの図面を一括操作する際、これを有効にしたままだと、OSのウィンドウメッセージキューが飽和し、最悪の場合はVisio本体がフリーズ（ハングアップ）する。
必ず処理の冒頭で `False` にし、エラー時を含めて確実に `True` に戻す構造化（Try-Finally的アプローチ）が必須である。
B. COMオブジェクトの明示的解放 (`Set … = Nothing`)
VBAのガベージコレクタは、スコープを抜けるまでCOMオブジェクトの参照カウント（Reference Count）を保持し続ける傾向がある。ループ内で `vsoPages(i)` を繰り返し代入する場合、明示的に `Set vsoPage = Nothing` を行わないと、VBAの内部ヒープに不要なCOMラッパーが残留し、メモリリークや「RPCサーバーが利用できません」といった不可解なCOM例外を引き起こす引き金になる。
C. Visioのハード制約への配慮 (`Count > 1` ガード)
Visioのドキュメントアーキテクチャでは、「1枚もページがない状態のドキュメント」が存在することは許容されていない。もしすべてのページをコードから抹消しようとした場合、最後の1ページを `Delete` しようとした瞬間にVisioエンジン側から拒絶エラーが返される。
そのため、条件分岐で `vsoPages.Count > 1` を担保するか、あるいはダミーの「表紙ページ」を残す設計にするなどの防衛的プログラミングが求められる。
—
4. 総括
Visio VBAによる自動化の成否は、APIのメソッドを知っているかどうかではなく、「裏で動くCOMコンテナのライフサイクルとインデックスの数学的変化を完全にコントロールできているか」にかかっている。
今回解説した「逆順ループ」は、ページ削除のみならず、シェイプの削除、レイヤーの削除、あるいは外部システム連携におけるXMLノードの走査など、あらゆるコレクション操作に通底する普遍的なエンジニアリングの原則である。
場当たり的なコード記述を捨て、堅牢で予測可能なアーキテクチャを構築すること。それこそが、真のプロフェッショナルエンジニアに求められる姿勢である。
