CorelDRAW VBAを掌握する極限の知見：Layer.CreateShapeとLayer.Deleteによる動的ライフサイクル管理の極意
CorelDRAW VBAの自動化において、真に堅牢で高速なシステムを構築できる者は少ない。大半のコードは「動くには動くが、メモリリークの温床となり、長時間のバッチ処理でCorelDRAWごとクラッシュする」という爆弾を抱えている。
特に、数千、数万点におよぶ図形要素を動的に生成・破棄するような高度なレイアウトエンジンや、外部DBと連携したバリアブル印刷システムにおいて、オブジェクトのライフサイクル管理を誤ることはシステム全体の死を意味する。
今回は、`Layer.CreateShape` による生成から、不要になったシェイプの `Layer.Delete` による確実な破棄、そしてVBAの背後でうごめくCOMコンポーネントのメモリ管理の真実について、チーフアーキテクトの視点から徹底的に解説する。
—
1. CorelDRAWオブジェクトモデルの闇：ライフサイクルの実態
VBA（Visual Basic for Applications）は、一見するとガベージコレクション（GC）に似た参照カウント方式でメモリ管理を行っているように見える。しかし、CorelDRAWの背後にあるC++ネイティブのCorelDRAWエンジン（GMS / Automation API）と、VBAランタイムの間には、常にCOM（Component Object Model）の境界線が存在する。
[VBA Runtime] == (COM Reference) ==> [CorelDRAW C++ Engine]
(変数) (実際のシェイプ実体)
`Layer.CreateShape` を呼び出した瞬間、C++側で新しいシェイプオブジェクトがヒープ上に確保され、そのポインタがVBA側の `Shape` オブジェクトにラップされて返される。ここで問題となるのは以下の2点だ。
1. 参照の解放漏れ: 変数のスコープが抜けても、内部的なCOM参照が適切にデクリメントされない場合、CorelDRAWのプロセス内に「ゾンビオブジェクト」が残り続ける。
2. 画面描画（Redraw）のオーバーヘッド: シェイプを1つ生成・削除するたびにCorelDRAWがビューポートを再描画しようとすると、処理速度が幾何級数的に低下する。
これらを完全防御し、極限のパフォーマンスを引き出す設計アプローチを次項のコードで示す。
—
2. 実践：安全かつ超高速な生成・破棄のアーキテクチャ
以下のコードは、単にメソッドを並べたものではない。画面描画の抑止、オブジェクトの明示的な変数解放（Nothing代入）、そしてエラーハンドリング時のメモリリーク防止を網羅した、プロダクション品質のテンプレートである。
Option Explicit
Sub AdvancedLifecycleManagement()
Dim sw As Double
sw = Timer
‘ 1. 最重要：画面描画とイベントの完全停止（パフォーマンスの劇的向上）
EventsEnabled = False
CorelDRAW.Application.Optimization = True
Dim doc As Document
Set doc = ActiveDocument
Dim layer As layer
Set layer = doc.ActivePage.ActiveLayer
On Error GoTo ErrorHandler
Dim i As Long
Dim shpTemp As Shape
Dim rectX As Double, rectY As Double
‘ 大量生成のシミュレーション（1000個の矩形を動的生成）
For i = 1 to 1000
rectX = (i Mod 50) 10
rectY = (i \ 50) 10
‘ Layer.CreateShape を用いた効率的な図形生成
‘ ※実際には曲線やインポートしたパスなど多様なオブジェクトを扱える
Set shpTemp = layer.CreateRectangle2(rectX, rectY, 8, 8)
‘ 属性の設定（メタデータの付与など）
shpTemp.Outline.Color.RGBAAssign 255, 0, 0
shpTemp.Fill.ApplyNoFill
‘ 【重要】役目を終えた一時オブジェクトの即時破棄テスト
‘ ここでは条件に合致したものを削除するシナリオを想定
If (i Mod 2 = 0) Then
‘ Layer.Delete ではなく Shape.Delete でも同等だが、
‘ レイヤー構造を意識したライフサイクル管理ではLayer配下の整合性を保つため
‘ 生成したインスタンスを直接ターゲットにする
shpTemp.Delete
End If
‘ ループ内でのCOM参照の確実なクリア
Set shpTemp = Nothing
Next i
MsgBox “処理完了: 経過時間 ” & Format(Timer – sw, “0.00秒”), vbInformation
GoTo Finally
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
Finally:
‘ 2. 必ず最適化モードとイベントを復元する（これを忘れるとCorelDRAWがフリーズしたような状態になる）
CorelDRAW.Application.Optimization = False
EventsEnabled = True
doc.Window.Refresh
‘ 3. 根底のオブジェクト参照も解放
Set shpTemp = Nothing
Set layer = Nothing
Set doc = Nothing
End Sub
—
3. シニアエンジニアが押さえるべき3つの極意
① `Application.Optimization = True` の絶対的遵守
CorelDRAW VBAにおいて、ループ内で図形を追加・削除・変形する場合、このフラグを立てないコードは「欠陥品」とみなしていい。画面の再描画（Redraw）やUIの更新処理は、VBAの実行速度の何百倍も重い。描画を完全にロックし、メモリ上でトランザクションを完結させることが大前提となる。
② 明示的な `Set Variable = Nothing` によるCOM参照カウンタの調停
VBAの変数はプロシージャを抜ければ自動解放される……というのは理想論に過ぎない。CorelDRAWのような重厚なCOMサーバーを相手にする場合、変数をスコープアウトさせるだけでは内部のCOM参照（IUnknown::AddRef / Release）が即座にデクリメントされないケースが多々ある。
特にループ内で何度もオブジェクトを生成・破棄する場合、ループの各イテレーションの最後で `Set shpTemp = Nothing` を明示的に実行することが、メモリ肥大化（ブルースクリーンや突然の強制終了）を防ぐ唯一の防壁となる。
③ エラーハンドリング時のリソース枯渇防止
`On Error GoTo` を用いる際、エラー発生時に `Optimization = True` や `EventsEnabled = False` が解除されないままプロシージャが終了すると、CorelDRAWのUIが操作を受け付けなくなる致命的なロック状態に陥る。必ず `Finally` ブロック（疑似的なtry-finally構造）を記述し、異常系であっても確実に環境を復元させなければならない。
—
4. システム間連携を見据えたアーキテクチャ拡張
外部システム（例えば、C#で書かれたWPF製クライアントや、Web API経由の受注システム）からCorelDRAWをCOMオートメーション経由で制御する場合、VBA側のメモリ管理の甘さはそのまま外部プロセスからの制御不能（RPCサーバーの失敗）に直結する。
外部連携を前提とするならば、VBA側で完結するスクリプトであっても、今回解説した `Layer.CreateShape` と `Shape.Delete` のライフサイクル管理を徹底し、「生成したリソースの総量と破棄の総量が完全に一致する（あるいは意図した最終状態のみが残る）」クリーンなコードベースを維持し続けることだ。
妥協のないコードのみが、過酷な現場のバッチ処理を何時間もノーエラーで走り抜けさせる。この知見をあなたの開発環境に直ちに組み込んでほしい。
