座標系の支配者：Visio VBAにおけるページ幾何学の自動制御とメモリ管理の極意
自動化エンジニアが陥る最も浅薄な罠の一つに、「命令が実行されたこと」を「システムが正しく制御されたこと」と誤認するミスがある。
Visioのページサイズを変更するスクリプトを書く際、多くの者は単に `PageSheet` の `PageWidth` と `PageHeight` を書き換えるだけで満足する。しかし、その直後に図面枠（Title Block）が左上隅へと放り出される様を見て、彼らは「Visioの仕様だ」と諦める。
断言しよう。それは仕様ではない。座標系（Coordinate System）とオブジェクトのライフサイクルに対する理解不足が生んだ、設計上の欠陥である。
本稿では、ページサイズの変化に追従し、図面枠を完璧に中央配置するための幾何学的ロジック、そしてエンタープライズ環境での運用に耐えうる堅牢な実装手法について、アーキテクチャの観点から詳説する。
1. 幾何学的アプローチ：Pin位置の再定義
Visioにおけるシェイプの配置は、そのシェイプの「Pin」と呼ばれる基準点によって決定される。ページサイズを変更した際、図面枠が動いてしまうのは、ページの原点 $(0,0)$ に対するシェイプの絶対座標が、新しいページ境界に対して相対的な整合性を失うからだ。
図面枠を中央に配置するための数理モデルは極めてシンプルである。
$$PinX = \frac{PageWidth}{2}$$
$$PinY = \frac{PageHeight}{2}$$
ただし、ここで重要なのは、シェイプ自体の `LocPinX` および `LocPinY`（シェイプ内部のローカル基準点）が、シェイプの中心に設定されている必要があるという点だ。ここを疎かにすると、図面枠の「角」がページの「中心」に来るという、初歩的な計算ミスを犯すことになる。
2. エンタープライズ品質の実装：堅牢なコード・パターン
単なるスクリプトと、システムの一部として組み込まれる「モジュール」の違いは、エラーハンドリングとリソース管理にある。
以下に、私が設計思想として推奨する、ページサイズ変更および中央配置のプロトタイプを示す。
Option Explicit
''' <summary>
''' ページのサイズを変更し、指定した名前の図面枠を中央に再配置する。
''' </summary>
''' <param name="pg">対象となるVisio.Pageオブジェクト</param>
''' <param name="frameName">中央配置する図面枠のシェイプ名</param>
''' <param name="newWidth">新しいページ幅 (インチ)</param>
''' <param name="newHeight">新しいページ高さ (インチ)</param>
Public Sub ResizePageAndCenterFrame(ByVal pg As Visio.Page, _
ByVal frameName As String, _
ByVal newWidth As Double, _
ByVal newHeight As Double)
' 1. 高速化のための描画停止とエラーハンドリングの初期化
On Error GoTo ErrorHandler
Application.ScreenUpdating = False
Dim shpFrame As Visio.Shape
Dim pgSheet As Visio.CellSet
' 2. ページシートの取得 (CellsUを使用し、ローカライズによるエラーを回避)
Set pgSheet = pg.PageSheet
' 3. ページサイズの変更
' CellsU (Universal) を使用することは、多言語環境での動作保証における鉄則である
pgSheet.CellsU("PageWidth").FormulaU = newWidth & " in"
pgSheet.CellsU("PageHeight").FormulaU = newHeight & " in"
' 4. 図面枠の探索と配置ロジック
' Shapeを検索する際、存在しない場合の例外処理を考慮する
Set shpFrame = Nothing
On Error Resume Next
Set shpFrame = pg.Shapes.Item(frameName)
On Error GoTo ErrorHandler
If Not shpFrame Is Nothing Then
' シェイプのローカルピンを中央に設定 (重要: これを行わないと角が中心に来る)
shpFrame.CellsU("LocPinX").FormulaU = "Width*0.5"
shpFrame.CellsU("LocPinY").FormulaU = "Height*0.5"
' ページの幾何学的中心をPinX, PinYに代入
shpFrame.CellsU("PinX").FormulaU = (newWidth / 2) & " in"
shpFrame.CellsU("PinY").FormulaU = (newHeight / 2) & " in"
Else
' ログ出力などの業務ロジックをここに挿入
Debug.Print "Warning: Frame '" & frameName & "' not found on page " & pg.Name
End If
CleanUp:
' 5. リソースの明示的な解放 (COMオブジェクトのメモリ管理)
' 大規模なバッチ処理において、これを行わないとメモリリークの原因となる
Set shpFrame = Nothing
Set pgSheet = Nothing
Application.ScreenUpdating = True
Exit Sub
ErrorHandler:
' 6. 異常系のハンドリング
' 現場では、単なるMsgBoxではなく、ログファイルへの書き出しが求められる
MsgBox "Critical Error in ResizePageAndCenterFrame: " & Err.Description, vbCritical
Resume CleanUp
End Sub3. アーキテクトの視点：なぜ `CellsU` なのか、なぜ `Set = Nothing` なのか
Universal Properties (`CellsU`) の重要性
多くの開発者が `Cells(“PageWidth”)` と記述するが、これは極めて危険な実装だ。Visioのプロパティ名は、ユーザーの言語設定（日本語、ドイツ語、中国語等）によって内部的な名前が変わることがある。`CellsU`（Universal）を使用することは、グローバル展開されるシステムにおいて、実行時エラーを未然に防ぐための最低限のマナーである。
COMオブジェクトのライフサイクル管理
VBAはガベージコレクションを持つが、Visioのような外部COMオブジェクトを操作する場合、その参照カウント（Reference Count）の管理はエンジニアの責任となる。
特に、数千枚のページをループで処理するようなバッチ処理において、`Set shp = Nothing` による明示的な解放を怠れば、メモリ使用量は線形に増大し、最終的に `Out of Memory` でプロセスがクラッシュする。これは「動くコード」と「運用できるシステム」の決定的な差である。
Windows APIとの境界線
本稿ではVBAの範囲内で完結させているが、もし、Visioのウィンドウ自体を特定の解像度や座標に強制的に制御する必要があるならば、`user32.dll` の `SetWindowPos` や `MoveWindow` を呼び出すことになる。しかし、図面内の幾何学操作においては、Visioの内部エンジン（PageSheet）に計算を委ねるのが最も計算コストが低く、精度が高い。
結論
ページのリサイズと図面枠の再配置。一見すると単純なタスクだが、その裏には座標系の整合性、多言語対応、そして厳格なメモリ管理という、ソフトウェア工学の基礎が凝縮されている。
「とりあえず動く」コードを書く段階を卒業し、どのような環境下でも、どのようなデータ量に対しても、数学的・構造的な正しさを維持できるコードを書け。それが、シニアエンジニアに求められる真の資質である。
