【極限の知見】Visio VBAにおける「ページ削除」の罠：インデックス・シフトを制する逆順ループの設計思想
業務自動化の現場において、ツールが「動く」ことと「堅牢である」ことの間には、深淵な溝が存在する。
特にVisioのような、複雑なオブジェクトモデルを持つアプリケーションを操作する場合、プログラマが陥りやすい典型的な罠がある。それが、「コレクション内の要素削除時におけるインデックス・シフト問題」だ。
「ページを順番に削除していったはずなのに、なぜか一部のページが残ってしまう」「実行時に『オブジェクトがありません』というエラーでプロセスが落ちる」――。もし君がこのような事象に直面しているなら、それは単なるバグではない。オブジェクトのライフサイクルと、コレクションの動的な再編に対する理解が不足している証拠だ。
本稿では、プロフェッショナルとして、この問題をいかにして設計レベルで回避し、プロダクション環境に耐えうる堅牢なコードを記述すべきかを伝授する。
1. なぜ「正順ループ」は破綻するのか
まず、多くの初学者が書きがちな「失敗するコード」を提示しよう。
' ❌ 典型的な失敗例：正順ループによる削除
Sub BadPageDeletion()
Dim i As Integer
Dim pgCount As Integer
pgCount = ActiveDocument.Pages.Count
' 1ページ目から順番に削除しようとする
For i = 1 To pgCount
ActiveDocument.Pages(i).Delete
Next i
End Subこのコードを実行すると、何が起きるか。論理的には全ページが削除されるはずだが、実際には「全ページの半分程度が削除され、残りのページが残る」か、あるいは「インデックス範囲外エラー（Run-time error ‘438’ 等）」が発生する。
破綻のメカニズム：インデックスの再編
Visioの`Pages`コレクションは、要素が削除された瞬間に「動的にインデックスを再編」する。
1. 初期状態：`[Page1, Page2, Page3, Page4]`
2. `i = 1` のとき：`Page1`を削除。コレクションは即座に再編され、`[Page2, Page3, Page4]` となる。
3. ここで、`Page2`は新しいインデックス `1` に昇格する。
4. ループの次ステップ `i = 2` に進む。プログラムは「新しいインデックス `2`」を見に行く。
5. 結果として、`Page2`（現在のインデックス1）はスキップされ、`Page3`（現在のインデックス2）が削除対象になる。
このように、削除によって「ターゲットが動いてしまう」のが、正順ループが致命的な欠陥を抱える理由だ。
2. 解決策：逆順ループ（Reverse Loop）という定石
この問題をエレガントに、かつ計算量的に最適に解決する方法はただ一つ。「末尾から逆順に走査すること」である。
' ✅ 正解：逆順ループによる安全な削除
Sub SafePageDeletion()
Dim i As Integer
Dim pgCount As Integer
pgCount = ActiveDocument.Pages.Count
' 末尾のインデックスから1に向かってデクリメントする
For i = pgCount To 1 Step -1
ActiveDocument.Pages(i).Delete
Next i
End Subなぜ逆順なら安全なのか
逆順ループでは、`i`番目の要素を削除した際、インデックスが再編されるのは「`i`より後ろ（大きい数値）」の要素に対してのみである。しかし、ループの走査方向は「`i`より前（小さい数値）」に向かっている。
つまり、「これからアクセスする予定のインデックス」には、削除による影響が一切及ばないのだ。これが、オブジェクトのライフサイクルを考慮した設計における「不変条件」の作り方である。
3. プロダクション級の設計：堅牢な実装例
実務において、単にページを消すだけのコードでは不十分だ。予期せぬエラー、権限不足、あるいは「消してはいけないマスターページ」の存在など、考慮すべきリスクは山積みである。
以下に、私が実務のプロジェクトで標準的に採用している、エラーハンドリングと条件判定を組み込んだプロフェッショナルな実装例を示す。
''' <summary>
''' 指定された条件に基づき、安全にページを削除する。
''' </summary>
''' <param name="preservePageName">削除から除外する（保護する）ページの名称</param>
Public Sub RobustPageCleanup(Optional ByVal preservePageName As String = "")
Dim doc As Visio.Document
Set doc = ActiveDocument
Dim i As Integer
Dim targetPage As Visio.Page
' 1. エラーハンドリングの開始
On Error GoTo ErrorHandler
' 2. 描画更新の停止（パフォーマンス最適化と画面のちらつき防止）
' ※VisioにはExcelのApplication.ScreenUpdatingに相当する直接のプロパティはないが、
' 処理の重い操作の前には状態管理を意識する。
Debug.Print "--- Cleanup Process Started ---"
' 3. 逆順ループによる削除プロセス
' Pages.Count は動的に変化するため、ループ内で常に最新のカウントを取得する設計にする
For i = doc.Pages.Count To 1 Step -1
Set targetPage = doc.Pages(i)
' 4. 保護条件の判定（ビジネスロジックの注入）
If targetPage.Name = preservePageName Then
Debug.Print "Skipped: " & targetPage.Name & " (Protected)"
Else
' 5. 削除実行
targetPage.Delete
Debug.Print "Deleted: " & targetPage.Name
End If
Next i
Debug.Print "--- Cleanup Process Completed Successfully ---"
Exit Sub
ErrorHandler:
' 6. エラーログの出力（実務ではファイルやDBへ書き出す）
MsgBox "致命的なエラーが発生しました。" & vbCrLf & _
"Error No: " & Err.Number & vbCrLf & _
"Description: " & Err.Description, vbCritical, "Automation Error"
' プロジェクトの整合性を保つため、ここで処理を中断させる
Debug.Print "Error: " & Err.Description
End Sub4. アーキテクトの視点：外部連携における注意点
このロジックをデータベース（SQL Server, Access等）やExcel、外部ファイルと連携させる場合、さらに一段上の設計思想が求められる。
インデックス依存の罠
データベースに「どのページにどのデータを格納したか」を記録している場合、そのキーが `PageIndex`（数値）であると、ページ削除によってデータとページの関係性が崩壊する。
- Bad Design: DBに `PageIndex: 3` と記録。ページ削除により、本来のPage 4がPage 3に昇格。データが誤ったページに紐付く。
- Good Design: DBには必ず `PageName`（文字列）または、ページ自体に付与した `Custom Property`（一意のID）をキーとして保持せよ。
トランザクションの概念
Visio VBAには強力なロールバック機能は備わっていない。大量のページ削除を行う前に、必ず「現在の状態を保存する（`doc.Save`）」か、「作業用の一時ファイルを作成する」といった、冪等性（Idempotency）を担保するためのプロセスを組み込むことが、プロのエンジニアとしての責務である。
まとめ
「ページ削除」という一見単純な操作の裏には、コレクションの動的特性という深い罠が潜んでいる。
1. 正順ループは「インデックス・シフト」により必ず失敗する。
2. 逆順ループ（`Step -1`）を用いることで、参照の整合性を保つ。
3. 実務では、保護対象の判定、エラーハンドリング、および一意の識別子（Name）による管理を徹底する。
これらを意識できるかどうかが、単なる「スクリプター」と、信頼される「自動化エンジニア」を分かつ境界線である。次回の開発から、この設計思想を君のコードに刻んでほしい。
