Visio VBAを掌握する極限の知見：List.SetListMemberStateによるリストコンテナ順序制御の全貌
Visioのオートメーションにおいて、最も過小評価され、同時に最も誤解されている領域の一つが「コンテナとリストの振る舞い」である。
特に、業務フロー図や組織図、ネットワーク構成図などで多用される「リストコンテナ（List Container）」内のシェイプの順序制御は、UI操作であればドラッグ＆ドロップで完結するものの、VBAからプログラム制御しようとした途端に開発者を絶望の淵に突き落とす。
ドキュメントの隅にひっそりと記載された `Page.SetListMemberState` メソッド。
このメソッドの本質と、オブジェクトモデルのメモリ管理、そして実務に耐えうる堅牢なコードの書き方を、現場の最前線を知るアーキテクトの視点から解き明かす。
—
1. Visioリスト構造のアーキテクチャと `SetListMemberState` の正体
Visioのシェイプは単なるベクターグラフィックスではない。それぞれがセル（Cell）の集合体であり、コンテナ（ContainerProperties）やリスト（ListProperties）といった特殊な振る舞いを定義するインターフェースを内包している。
リストコンテナ内において、メンバーシェイプの並び順（インデックス）は、単なる視覚的な配置ではなく、データ構造としての厳密な順序を持つ。UI上での「上に移動」「下に移動」は、内部的にはリスト内のメンバーのインデックス値を書き換える処理に他ならない。
ここで登場するのが、`Page` オブジェクトが持つ以下のメソッドである。
Page.SetListMemberState (ListShape, MemberShape, State)
一見すると難解なこのメソッドは、指定したリストシェイプ（`ListShape`）に対して、メンバーシェイプ（`MemberShape`）をどのように関連付け、どの位置に挿入・移動させるかを制御する。
シニアエンジニアが押さえるべき「State」の挙動
`SetListMemberState` の第3引数（State）に渡すフラグや定数は、単にリストに追加するだけでなく、「既存リスト間での移動」「特定インデックスへの挿入」を司る。しかし、VisioのCOMインターフェースは親切ではない。インデックスの指定を誤ると、実行時エラー（`-20324: シェイプはリストではありません` 等）が容赦なく発生する。
したがって、VBAから順序を操作するアプローチとしては、以下の鉄則を遵守する必要がある。
1. 対象シェイプが本当にリストコンテナであるか（`ListProperties` の有無）を確認する。
2. メンバーシェイプがそのリストに属していることを前提条件とする。
3. リスト内の全メンバーを取得し、配列またはコレクション上でインデックスを再計算した上で適用する。
—
2. 実践：リスト内シェイプの順序制御（上下移動・特定位置挿入）
百聞は一見に如かず。以下のコードは、アクティブページ上で選択されているリスト内のメンバーシェイプを、指定した方向へ1つ移動、あるいは任意のインデックスへ強制挿入するための実用的なモジュールである。
このコードは、エラーハンドリング、オブジェクトの明示的解放（メモリリーク防止）、およびVisio特有のトランザクション処理（`UndoScope`）を完全に網羅している。
Option Explicit
‘ =========================================================================
‘ 務用自動化モジュール: リストコンテナ内シェイプの順序制御
‘ Architecture: 徹底的なオブジェクト解放とUndo対応
‘ =========================================================================
Public Sub ShiftSelectedListMember(ByVal moveDirection As Integer)
Dim vsoApp As Visio.Application
Set vsoApp = Application
‘ 画面描画とイベントを停止し、パフォーマンスを極限まで引き上げる
vsoApp.ScreenUpdating = False
vsoApp.EventEnabled = False
Dim undoScopeID As Long
undoScopeID = vsoApp.BeginUndoScope(“リストシェイプの順序変更”)
On Error GoTo ErrorHandler
Dim vsoPage As Visio.Page
Set vsoPage = vsoApp.ActivePage
‘ 選択状態の検証
If vsoPage.Selection.Count = 0 Then
MsgBox “対象となるシェイプが選択されていません。”, vbExclamation, “構造制御エラー”
GoTo CleanUp
End If
Dim vsoMemberShape As Visio.Shape
Set vsoMemberShape = vsoPage.Selection(1)
‘ メンバーがコンテナ（リスト）に属しているか確認
If Not vsoMemberShape.ContainerProperties Is Nothing Then
‘ コンテナ自体の可能性を排除、リスト機能を持っているか？
Dim vsoListShape As Visio.Shape
Set vsoListShape = vsoMemberShape.ContainerProperties.ListShape
If vsoListShape Is Nothing Then
MsgBox “選択されたシェイプはリストコンテナのメンバーではありません。”, vbExclamation, “構造制御エラー”
GoTo CleanUp
End If
‘ リスト内の現在のインデックスを取得
Dim currentIndex As Long
currentIndex = vsoListShape.ListProperties.MemberIndex(vsoMemberShape)
Dim targetIndex As Long
targetIndex = currentIndex + moveDirection
‘ 境界値チェック
Dim totalMembers As Long
totalMembers = vsoListShape.ListProperties.MemberCount
If targetIndex < 1 Then targetIndex = 1 If targetIndex > totalMembers Then targetIndex = totalMembers
If currentIndex <> targetIndex Then
‘ SetListMemberState を用いた順序の再配置
‘ Visioの仕様上、既存メンバーの順序変更は該当インデックスへの再挿入として処理される
vsoPage.SetListMemberState vsoListShape, vsoMemberShape, visListAddAfter, vsoListShape.ListProperties.Member(targetIndex)
End If
Else
MsgBox “選択されたシェイプはコンテナに属していません。”, vbExclamation, “構造制御エラー”
End If
CleanUp:
vsoApp.EndUndoScope undoScopeID, True
vsoApp.ScreenUpdating = True
vsoApp.EventEnabled = True
‘ オブジェクト変数の完全解放（COMラッパーのメモリリークを根絶）
Set vsoMemberShape = Nothing
Set vsoListShape = Nothing
Set vsoPage = Nothing
Set vsoApp = Nothing
Exit Sub
ErrorHandler:
vsoApp.EndUndoScope undoScopeID, False
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
—
3. チーフアーキテクトが指摘する「VBAメモリ管理」のダークパターン
上記のコードで最も注目すべきは、処理の最後にある `Set xxx = Nothing` によるオブジェクトの明示的解放である。
VBA初学者や一般的なスクリプト記述者は、プロシージャの終了とともにローカル変数が破棄されるため、変数の解放は不要だと誤解している。しかし、Visio VBA（COMオブジェクト）において、この考え方は致命的なメモリリークを引き起こす。
COM参照カウントの闇
`vsoApp.ActivePage` や `vsoPage.Selection(1)` を呼び出した瞬間、背後ではC++ベースのVisioエンジンとVBAランタイムの間でCOM参照カウント（Reference Count）がインクリメントされる。
プロシージャが終了しても、VBAのガベージコレクタが即時にCOMオブジェクトの解放を実行するとは限らない。特に、大量のシェイプを走査・操作するバッチ処理において、この「参照の残留」が蓄積すると、Visioプロセス全体のメモリ消費量が肥大化し、最終的に `エラー -2147024882 (OutOfMemory)` でクラッシュする。
極限の知見:
> ループ内でオブジェクトを変数に格納して処理する場合、ループの各イテレーションごとに `Set vsoTarget = Nothing` を実行し、プロシージャ終了時にもルートから末端まで逆順でオブジェクトを完全に `Nothing` に解放せよ。これが数万回のアクティビティを安定稼働させる唯一の防衛策である。
—
4. レガシー環境・システム間連携への応用
この `SetListMemberState` を用いたリスト制御の自動化は、単なる図面の一括整形に留まらない。例えば、外部データベース（SQL ServerやC#製バックエンドサービス）からJSONやXML形式で「業務プロセスの順序データ」を受け取り、Visio側で自動的にダイアグラムのフロー順序を再構築・同期させるエンタープライズ・システムにおいて極めて強力な武器となる。
外部システム連携のアーキテクチャ設計図：
1. 外部API / DB: プロセスの依存関係と順序IDを保持。
2. Visio (VBA / VSTO): ドキュメント起動時（`Document_DocumentOpened` イベント）に外部データを非同期取得。
3. リスト構築・ソート: 取得した順序データに基づき、既存のシェイプ群を `SetListMemberState` で正しいインデックスへ一瞬で並べ替える。
4. 描画・保存: ユーザーが操作することなく、常に最新のガントチャートやリスト構造を維持した図面が生成される。
この自動化層を構築することで、人間の手作業による「図面のメンテナンス漏れ」や「レイアウトの崩れ」を完全に排除し、図面を「生きたシステムドキュメント」へと昇華させることが可能になる。
総括
Visio VBAにおけるオブジェクトモデルの掌握は、単なるAPIの暗記ではない。コンテナとリストが持つ階層構造の理解、COMのライフサイクルを制御する厳格なメモリ管理、そして予期せぬ例外に対するトランザクション保証。これらを高次元で統合できた者だけが、真にエンタープライズなVisioソリューションを構築できる。
コードは嘘をつかない。アーキテクチャの美しさは、細部のメモリ解放とエラーハンドリングに宿る。
