Visio VBAにおける幾何学的整合性の確立：PageSheet操作による精密なページ初期化
エンジニアが「自動化」という言葉を口にする時、そこには二つの道がある。一つは、単に手作業をプログラムに置き換えるだけの「スクリプト」の道。もう一つは、システムの決定論的な振る舞いと、リソースの完全な制御を担保する「アーキテクチャ」の道だ。
多くの開発者が、Visioのページサイズ変更や図面枠の配置を、GUIの操作を模倣するような低レイヤーなマクロで済ませようとする。しかし、大規模な図面生成エンジンや、数千枚の図面をバッチ処理するエンタープライズ・システムを構築する場合、そのようなアプローチは致命的な計算誤差とメモリリークを招く。
本稿では、`Page.PageSheet` のセルプロパティを直接操作することで、幾何学的な精度を極限まで高め、かつリソース効率を最適化した「初期化マクロ」の真髄を解説する。
1. 抽象化レイヤーを剥ぎ取る：PageSheetへの直接アクセス
Visioのオブジェクトモデルは、非常に強力な抽象化レイヤーを提供している。しかし、`Page.Width` や `Page.Height` といったプロパティは、内部的には `PageSheet` 内の特定のセルへの参照をラップしたものに過ぎない。
大規模な自動化プロセスにおいて、プロパティ経由のアクセスを繰り返すことは、COM（Component Object Model）のオーバーヘッドを不必要に増大させる。我々が目指すべきは、PageSheetという「データシート」に対して、直接的な書き込みを行うことだ。
ユニット（単位）の呪縛を解く
Visioのセル操作において最も多くのエンジニアが陥る罠は、単位の不一致である。Visioの内部計算は「インチ」や「ミリメートル」といった人間的な単位ではなく、独自の数値体系に基づいている。
`CellsU` メソッド（Universal Nameを使用するメソッド）を用いることで、ロケール（言語設定）に依存しない、堅牢なセル指定が可能になる。
2. 極限の初期化実装：VBAによる高精度制御
以下に示すコードは、単なる「ページ設定マクロ」ではない。メモリ管理、エラーハンドリング、そして幾何学的な計算の正確性を担保した、プロダクション・クオリティの設計思想に基づいている。
Option Explicit
''' <summary>
''' ページをカスタムサイズに設定し、指定された図面枠を中央に配置する。
''' </summary>
''' <param name="pg">対象となるVisio.Pageオブジェクト</param>
''' <param name="widthMm">ページ幅 (mm)</param>
''' <param name="heightMm">ページ高さ (mm)</param>
''' <param name="frameName">配置する図面枠シェイプの名前</param>
Public Sub InitializePageGeometry(ByRef pg As Visio.Page, _
ByVal widthMm As Double, _
ByVal heightMm As Double, _
ByVal frameName As String)
Dim ps As Visio.PageSheet
Dim frameShape As Visio.Shape
Dim pageWidthInches As Double
Dim pageHeightInches As Double
Dim frameWidth As Double
Dim frameHeight As Double
On Error GoTo ErrorHandler
' 1. PageSheetへの参照取得（オブジェクトのライフサイクル管理）
Set ps = pg.PageSheet
' 2. 単位変換の計算 (1 inch = 25.4 mm)
' 浮動小数点演算の誤差を最小化するため、定数として定義
Const MM_TO_INCH As Double = 1 / 25.4
pageWidthInches = widthMm * MM_TO_INCH
pageHeightInches = heightMm * MM_TO_INCH
' 3. PageSheetのセルを直接操作 (CellsUを使用しロケール依存を排除)
' PageWidth, PageHeight セルへの直接書き込み
ps.CellsU("PageWidth").FormulaU = pageWidthInches & " in"
ps.CellsU("PageHeight").FormulaU = pageHeightInches & " in"
' 4. 図面枠（Frame）の検索と配置計算
' 図面枠がページ内に存在することを前提とするが、存在しない場合の堅牢性を確保
On Error Resume Next
Set frameShape = pg.Shapes(frameName)
On Error GoTo ErrorHandler
If Not frameShape Is Nothing Then
' 図面枠の現在のサイズを取得
' PinX/PinYはシェイプの中心座標。これをページの中心(Width/2, Height/2)に同期させる。
frameWidth = frameShape.CellsU("Width").ResultIU
frameHeight = frameShape.CellsU("Height").ResultIU
' 幾何学的中心への配置
' PinX, PinYをページの半分に設定することで、数学的に完全な中央配置を実現する
frameShape.CellsU("PinX").FormulaU = (pageWidthInches / 2) & " in"
frameShape.CellsU("PinY").FormulaU = (pageHeightInches / 2) & " in"
Else
' 図面枠が見つからない場合は、ログ出力または例外を投げる（設計思想に依存）
Debug.Print "Warning: Frame shape '" & frameName & "' not found."
End If
' 正常終了時のクリーンアップ
CleanExit:
' COMオブジェクトの明示的解放
' 大規模ループ内でこれを行わないと、Visio.exeがメモリ上に残り続ける（ゾンビプロセス化）
Set frameShape = Nothing
Set ps = Nothing
Exit Sub
ErrorHandler:
' エンタープライズ環境では、ここで独自のログ出力機構（Windows Event Log等）を呼び出す
Err.Raise Err.Number, "InitializePageGeometry", _
"Geometric initialization failed: " & Err.Description
Resume CleanExit
End Sub3. アーキテクトの視点：メモリ最適化とレガシー環境への配慮
COMオブジェクトの明示的解放
VBAにおいて `Set obj = Nothing` は単なる作法ではない。特にVisioのような重いアプリケーションを、Excelや外部の .NET プロセスから制御する場合、オブジェクトの参照カウントが適切に減少しないと、プロセスがメモリ上に残留し続ける。これはサーバーサイドでの自動化において、リソース枯渇を引き起こす最大の要因だ。
Windows APIとの連携可能性
もし、このマクロをさらに高度なシステム（例えば、ユーザーが操作中のVisioのウィンドウを強制的に前面に持ってくる、あるいは特定の描画更新を待機するなど）に組み込む場合、`user32.dll` の `SetForegroundWindow` や `SendMessage` を呼び出す必要がある。
しかし、覚えておいてほしい。「APIを叩く前に、オブジェクトモデルの限界まで使い倒せ」ということだ。APIによる外部からの操作は、Visioの内部状態（State）を不安定にするリスクを伴う。
レガシー環境における決定論的挙動
古いVisio（2010/2013等）が混在するレガシー環境では、描画エンジンの更新タイミングが現代の環境と異なる。`PageSheet` の値を書き換えた直後にシェイプの座標を計算する場合、計算結果が古いページサイズのままになることがある。
そのような場合は、`DoEvents` を挟むのではなく、計算に必要な値をあらかじめローカル変数に保持し、「計算はメモリ上で行い、適用は一括で行う」という、計算と描画の分離（Decoupling）を徹底すべきだ。
結論
ページサイズを設定し、図面枠を中央に置く。一見すると初歩的なタスクに見える。しかし、その背後にある「単位の制御」「COMオブジェクトのライフサイクル」「幾何学的整合性」への意識の差が、プロフェッショナルなシステムと、単なるスクリプトを分かつ。
コードは、単に動けばいいのではない。「予測可能（Deterministic）でなければならない」のだ。
