【実務・中級編】【上級者向け】ページ内の全シェイプを「グループ化」したまま、レイヤー属性を継承させる再帰処理 – Visio VBA解析バイブル

Visio VBAの深淵：再帰処理によるレイヤー属性の強制継承と、堅牢な設計思想

業務自動化の現場において、「動けばいい」というコードを書く人間と、「運用に耐えうるシステム」を設計する人間の差は、どこに現れるのか。

Visioを用いた複雑な図面管理ツールを開発していると、必ず直面する壁がある。それは「階層構造（Group）とレイヤー（Layer）の不整合」だ。

ユーザーが直感的にグループ化したシェイプであっても、その内部（子シェイプ）が個別のレイヤー属性を持っていれば、グループ全体の表示・非表示操作やロック操作が期待通りに機能しない。グループのレイヤー設定を子シェイプへ「強制的に、かつ再帰的に」継承させるロジック。これは、単なるループ処理では決して到達できない、オブジェクトモデルの深い理解を必要とする領域である。

本記事では、プロフェッショナルな自動化ツール開発者が備えておくべき、再帰を用いたレイヤー属性継承の極致を解説する。

1. なぜ「単純なループ」では敗北するのか

多くの開発者が陥る罠は、`Page.Shapes` コレクションを `For Each` で回すだけの実装だ。

' --- 典型的な失敗例 ---
For Each shp In Page.Shapes
    If shp.Type = visTypeGroup Then
        ' グループ直下の子シェイプしか見ていない！
        shp.Cells("Layer").Formula = ... 
    End If
Next shp

この実装は、グループの中にさらにグループがある「入れ子（Nested Group）」構造になった瞬間、無力化する。図面が複雑化すればするほど、階層の深さは予測不能だ。

我々アーキテクトが実装すべきは、「シェイプがグループである限り、その中身を掘り下げ続ける」という、数学的な再帰構造を持つアルゴリズムである。

2. 設計指針：冪等性とパフォーマンスの担保

実装に入る前に、設計の三原則を定義する。

1. 再帰の終端条件（Base Case）の明確化: シェイプがグループでない、あるいは子シェイプを持たない場合に確実に再帰を抜ける設計にすること。
2. 副作用の制御: レイヤーの追加・削除は、VisioのUndoスタックを激しく消費する。処理前に `Application.DeferUpdates = True` を活用し、描画更新を抑制しなければ、大規模図面ではフリーズに近い状態に陥る。
3. 冪等性（Idempotency）の確保: 同じ処理を二度実行しても、図面の状態が破壊されないこと。既に目的のレイヤーに属している場合は、不要な操作をスキップする。

3. プロダクション・コード：再帰的レイヤー継承エンジン

以下に、実務でそのまま利用可能な、堅牢な設計に基づいたコードを示す。単にレイヤーをコピーするのではなく、「グループが属する主要なレイヤーを、子シェイプに強制適用する」ロジックだ。

Option Explicit

''' <summary>
''' 指定されたグループ内の全シェイプに対し、グループのレイヤー属性を再帰的に継承させる。
''' </summary>
''' <param name="targetGroup">対象となるグループシェイプ</param>
Public Sub ForceLayerInheritance(ByVal targetGroup As Visio.Shape)
    Dim targetLayer As Visio.Layer
    
    ' 1. エラーハンドリング: グループでない場合は即時終了
    If targetGroup.Type <> visTypeGroup Then Exit Sub
    
    ' 2. グループが属する最初のレイヤーを取得（ビジネスロジックに応じて調整）
    ' ※Visioのシェイプは複数のレイヤーに属し得るため、設計判断が必要
    If targetGroup.LayerCount = 0 Then Exit Sub
    Set targetLayer = targetGroup.Layers.Item(1)
    
    On Error GoTo ErrorHandler
    
    ' パフォーマンス最適化: 描画更新と更新通知を停止
    Visio.Application.ScreenUpdating = False
    Visio.Application.DeferUpdates = True
    
    ' 3. 再帰処理の開始
    Call RecursiveSyncLayer(targetGroup, targetLayer)

    ' 4. 後処理
    Visio.Application.DeferUpdates = False
    Visio.Application.ScreenUpdating = True
    MsgBox "レイヤー継承処理が完了しました。", vbInformation
    Exit Sub

ErrorHandler:
    Visio.Application.DeferUpdates = False
    Visio.Application.ScreenUpdating = True
    MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical
End Sub

''' <summary>
''' 再帰エンジン: シェイプの階層を掘り下げながら属性を同期する
''' </summary>
''' <param name="currentShape">現在走査中のシェイプ</param>
''' <param name="targetLayer">継承すべきターゲットレイヤー</param>
Private Sub RecursiveSyncLayer(ByVal currentShape As Visio.Shape, ByVal targetLayer As Visio.Layer)
    Dim childShape As Visio.Shape
    Dim i As Integer
    Dim alreadyHasLayer As Boolean
    
    ' --- A. 現在のシェイプに対する属性更新（子シェイプでない場合、またはグループ自体への適用） ---
    ' 既存のレイヤーチェック（冪等性の確保）
    alreadyHasLayer = False
    For i = 1 To currentShape.LayerCount
        If currentShape.Layers.Item(i).Name = targetLayer.Name Then
            alreadyHasLayer = True
            Exit For
        End If
    Next i
    
    ' ターゲットレイヤーに属していなければ追加
    If Not alreadyHasLayer Then
        currentShape.Layers.Add targetLayer
    End If
    
    ' --- B. 再帰ステップ: 子シェイプが存在する場合 ---
    If currentShape.Type = visTypeGroup Then
        For Each childShape In currentShape.Shapes
            ' 再帰呼び出し：自分自身を引数として、階層を深く潜る
            Call RecursiveSyncLayer(childShape, targetLayer)
        Next childShape
    End If
End Sub

コードの技術的ポイント

• `RecursiveSyncLayer` の分離: 外部公開用のメソッド（`ForceLayerInheritance`）と、内部ロジック用の再帰メソッドを分離している。これはカプセル化の基本であり、呼び出し側が内部の再帰構造を意識せずに済むようにするためだ。
• `alreadyHasLayer` による判定: 無駄な `Layers.Add` を防ぐ。Visioにおいて、既に属しているレイヤーを再度 `Add` しようとすると、実行時エラーが発生する場合がある。これを防ぐのは「堅牢な設計」の最低条件だ。
• `DeferUpdates` の制御: `ErrorHandler` 内でも必ず `False` に戻す。これを忘れると、エラー発生後にVisioの挙動が極端に重くなり、ユーザーの作業を妨害する。

4. 外部連携（DB/ファイル）における注意点

このロジックを、データベース（SQL ServerやExcel管理台帳）から取得した「レイヤー構成定義」に基づいて実行する場合、以下の設計ミスに注意せよ。

1. オブジェクト参照の保持:
DBから「レイヤー名」を取得した場合、それを直接 `Layers.Add` に渡してはいけない。必ず `Page.Layers.Item(“レイヤー名”)` を通じて `Visio.Layer` オブジェクトとして取得し、そのオブジェクトを再帰関数に渡すべきだ。文字列操作によるレイヤー検索は、実行速度を著しく低下させる。
2. トランザクションの概念:
Visio VBAには標準的なDBのような強力なトランザクションはない。もし処理の途中でエラーが起きた場合、図面は「半分だけレイヤーが変わった」という中途半端な状態（汚染状態）になる。大規模な更新を行う場合は、処理開始前に `ActiveDocument.SaveCopyAs` でバックアップを作成する、あるいは「一括処理」ではなく「一工程ずつ確実にコミットする」設計が求められる。

5. 結論：アーキテクトの視点

「グループ化」というユーザーの操作は、論理的には「情報のカプセル化」を意味する。しかし、Visioのレイヤーシステムはそのカプセル化を自動的には守ってくれない。

エンジニアの仕事は、ユーザーの直感（グループ化したのだから、一緒に動いて当然だ）と、システムの論理（各シェイプは個別のレイヤー属性を持つ）の間にある溝を、再帰という数学的解法を用いて埋めることにある。

コードの美しさは、単なる見た目の問題ではない。それは、予期せぬ階層構造や、大量のデータ、そしてエラーという混沌（カオス）に対していかに冷静に、論理的に立ち向かえるかという、設計者の意志の現れなのだ。