AutoCAD VBAを掌握する極限の知見：メモリの深淵に潜む「幽霊オブジェクト」の駆逐
AutoCAD VBAの現場において、多くのプログラマは `AcadDocument` や `AcadModelSpace` の表面的な操作に終始している。`AddLine` で図形を描き、`Select` で取得し、プロパティを書き換える。しかし、システムが大規模化し、何十万というエンティティが生成・削除を繰り返す複雑なアドインを構築したとき、必ずと言っていいほど「不可解なメモリリーク」「原因不明の致命的な図面破損（Drawing Corruption）」、そして「Undoスタックの肥大化による極端なパフォーマンス低下」に直面する。
その元凶の一つが、「削除されたはずがメモリ上（Database内）にゾンビのように残留しているオブジェクト」である。
今回は、AutoCADのオブジェクトモデルの根幹を成す `AcadDatabase` と、その真の姿を暴く `IsErased` プロパティの走査手法について、チーフアーキテクトの視点から極限まで解説する。
—
1. データベース構造の真実：なぜオブジェクトは「消えても残る」のか
AutoCADの図面（DWG/DXF）は、表面上はレイアウトやモデル空間に配置された図形の集合体に見えるが、内部的には `AcadDatabase` という巨大なシンボルテーブルとオブジェクトのコンテナによって支配されている。
開発者が `object.Delete()` を呼び出したとき、何が起きているのか？
初心者エンジニアは「メモリからそのデータが綺麗に消去された」と誤解する。だが、現実は異なる。
1. 論理削除（Erased State）: `Deleteメソッド`の実行により、オブジェクトの内部フラグ `IsErased` が `True` に書き換わる。
2. シンボルテーブルからの切り離し: 親コンテナ（ブロックテーブルレコードなど）の参照リストからは外れるため、通常の手法（ModelSpaceのループなど）では目視できなくなる。
3. Database内での残存: メモリ上のDatabase領域には、トランザクションやUndoスタックの整合性を維持するため、あるいは他の未解放の参照が存在するため、インスタンスそのものが残り続ける。
これが、「IsErased = True の幽霊オブジェクト（Ghost Objects）」である。
これらがメモリ上に蓄積すると、図面ファイルの肥大化、AutoCADの動作不安定化、そして何よりCOMオブジェクトの参照カウント（Reference Counting）の汚染を引き起こす。
—
2. 標準的な走査の限界と、Database直接アクセスの優位性
通常のVBAコードでは、`ActiveDocument.ModelSpace` やレイアウトをイテレートしてオブジェクトを検査する。しかし、すでに論理削除されたオブジェクトは、これらの空間オブジェクトの列挙から除外されるため、通常のループでは絶対に発見できない。
これらを特定するには、`AcadDocument.Database` から直接、全オブジェクトの根源であるシンボルテーブルや、すべてのオブジェクトを内包するダンプ領域にアクセスし、「全数検査（Full Database Iteration）」を行う必要がある。
これこそが、Undoスタックに依存せず、図面の破損やゴミデータの蓄積をダイレクトに診断する唯一無二の手法である。
—
3. 実装コード：メモリ上の「幽霊オブジェクト」を暴く診断エンジン
以下のVBAコードは、現在のActiveDocumentのDatabaseを直接走査し、`IsErased = True` となっているゾンビオブジェクトを検出・集計するプロシージャである。
レガシーなVBA環境であってもメモリリークを起こさないよう、オブジェクトの参照解放（`Set obj = Nothing`）を徹底した、実戦投入可能なプロダクションコードだ。
Option Explicit
‘ =================================================================================
‘ módulo: ModDatabaseDiagnostic
‘ 概要 : Database内のIsErasedオブジェクトを走査し、メモリ上のゴミデータを特定する
‘ 著者 : チーフアーキテクト
‘ =================================================================================
Public Sub Diagnostic_FindGhostObjects()
Dim acadDoc As AcadDocument
Set acadDoc = ThisDrawing.Application.ActiveDocument
Dim db As AcadDatabase
Set db = acadDoc.Database
Dim totalObjects As Long
Dim erasedCount As Long
erasedCount = 0
On Error GoTo ErrorHandler
‘ ログ出力の開始
Debug.Print “=== AutoCAD Database 診断開始: ” & Now & ” ===”
Debug.Print “対象図面: ” & acadDoc.Name
‘ Database内の全オブジェクトを格納するコレクション（AcadDatabase.Objects）を走査
‘ 注意: このコレクションアクセスはAutoCADオブジェクトモデルの深層に触れるため、
‘ 巨大な図面ではパフォーマンスに影響を与えます。
Dim obj As AcadEntity
Dim entName As String
Dim handle As String
totalObjects = db.Objects.Count
Debug.Print “データベース総オブジェクト数: ” & totalObjects
Dim i As Long
For i = 0 To totalObjects – 1
‘ 厳密なインデックスアクセス
Set obj = db.Objects.Item(i)
‘ 参照が有効か、かつIsErasedプロパティがTrueか判定
If Not obj Is Nothing Then
If obj.IsErased Then
erasedCount = erasedCount + 1
‘ 安全にプロパティを取得（削除済みオブジェクトは一部のプロパティアクセスでエラーになる可能性があるためOn Error Resume Nextを活用）
On Error Resume Next
entName = obj.ObjectName
handle = obj.Handle
On Error GoTo ErrorHandler
‘ イミディエイトウィンドウに幽霊オブジェクトの詳細を出力
Debug.Print ” [幽霊検出 #” & erasedCount & “] ” & _
“Handle: ” & handle & “, ” & _
“Type: ” & entName & “, ” & _
“Index: ” & i
End If
End If
‘ ループごとのCOM参照解放（極めて重要：メモリ蓄積を防ぐ）
Set obj = Nothing
Next i
Debug.Print “=== 診断完了 ===”
Debug.Print “総オブジェクト数: ” & totalObjects
Debug.Print “検出された幽霊オブジェクト数: ” & erasedCount
If erasedCount > 0 Then
MsgBox “警告: メモリ上に ” & erasedCount & ” 個の削除済みオブジェクト（IsErased = True）が検出されました。” & vbCrLf & _
“詳細はイミディエイトウィンドウを確認してください。”, vbExclamation, “Database診断エンジン”
Else
MsgBox “データベースは正常です。幽霊オブジェクトは検出されませんでした。”, vbInformation, “Database診断エンジン”
End If
CleanUp:
Set obj = Nothing
Set db = Nothing
Set acadDoc = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
—
4. コードの深層解説：なぜこの実装が「極限」なのか
1. `db.Objects` コレクションの直接叩き
通常の `ModelSpace` や `Blocks` は、論理削除されたオブジェクトを隠蔽するフィルタがかかっている。しかし `db.Objects` はDatabase内のすべてのCOMラッパーを曝け出す。これにより、ブロック定義の内部や辞書オブジェクト（Dictionary）の片隅に取り残されたゴミをも網羅できる。
2. ループ内での厳格な `Set obj = Nothing`
VBAのCOM interopにおいて、ループ内でオブジェクト変数を再利用し続けると、背後でCOMの参照カウント（AddRef/Release）が狂い、VBAランタイムのヒープ領域が肥大化する。明示的に `Set obj = Nothing` を挟むことで、ガベージコレクションを待たずにメモリを即時解放する設計としている。
3. エラーハンドリングの多重防御
`IsErased = True` になったオブジェクトは、AutoCADのC++コア側ですでに大部分のリソースが破棄されている場合がある。そのため、`obj.ObjectName` や `obj.Handle` へのアクセス時にCOMException（オートメーションエラー）が発生するリスクが高い。あえて `On Error Resume Next` を局所的に適用し、プロパティ取得失敗によるマクロ全体のクラッシュを完全に防いでいる。
—
5. チーフアーキテクトからの提言：システムの寿命を延ばす保守運用
この手法で検出された幽霊オブジェクトを完全にパージ（完全消去）するには、単にVBAからオブジェクトを触るだけでは不十分だ。AutoCADのアーキテクチャ上、Databaseのパージコマンド、あるいはVB.NET（ObjectARX / .NET API）を用いた `Database.Purge()` やトランザクションの深部でのコミットメントが必要となる場合がある。
しかし、まずは「何がメモリ上に残っているのかを可視化する」こと。これがシステムインテグレーションや大規模設計データの品質担保における第一歩である。
レガシーなVBA環境であっても、システムの内部構造（Database）に踏み込むことで、AutoCADは単なる製図ソフトから「プログラム可能な堅牢なエンジニアリングプラットフォーム」へと変貌する。メモリの深淵を恐れず、コードでコンテキストを支配せよ。
