【AutoCAD VBA】ActiveSpaceの絶対制御：モデル・ペーパー空間の混迷を断つ防壁アーキテクチャ
AutoCAD VBAの自動化において、最も初歩的でありながら、最も多くのエンジニアを奈落の底へ突き落としてきた悪夢がある。
それが「意図しない空間への図形配置」だ。
スクリプトを実行し、完璧な座標計算のもとで生成されたはずの図形群が、モデル空間の彼方に消え去る、あるいはペーパー空間のビューポートの海に沈む。原因を調査すれば、`ThisDrawing.ModelSpace` と `ThisDrawing.PaperSpace` の参照先を、現在のコンテキスト（ActiveSpace）を無視してハードコーディングしていたことによるものだった——。
この種のバグは、単なるケアレスミスとして片付けられてはならない。CADエンジニアリングの根幹に関わる「空間のコンテキスト管理の欠如」というアーキテクチャの敗北である。
本稿では、`AcadDocument.ActiveSpace` を完全に掌握し、空間の混迷を物理的に断つための実戦的防壁コードと、その背後にあるオブジェクトモデルの真理を解説する。
—
1. 空間制御のパラドックス：ActiveSpace と Database.CurrentSpace
AutoCAD VBAのオブジェクトモデルにおいて、空間を制御するプロパティは一筋縄ではいかない。初心者は `ActiveSpace` さえ切り替えれば万事解決だと勘違いするが、実務の現場では、UI上の見え方と、データベース内部のポインタの挙動を厳密に分離して考える必要がある。
空間を決定づける2つの軸
1. `AcadDocument.ActiveSpace`（UI空間の制御）
- ユーザーが画面上で操作している空間。
- `acModelSpace`（モデル空間）または `acPaperSpace`（レイアウト空間）のいずれか。
- `SendCommand` や画面上のビューポート切り替えに連動する。
2. `AcadDatabase.CurrentSpace`（論理空間の制御）
- `AddLine` や `AddCircle` などの図形生成メソッドが、実際にどのブロックテーブルレコードに対してエンティティを書き込むかを決定する。
もしあなたが「現在はペーパー空間を表示しているから、そこに追加されるはずだ」と思い込み、`CurrentSpace` の評価を怠って `ModelSpace` オブジェクトに対して直接メソッドを叩けば、UIがどこを向いていなかろうと、図形は容赦なくモデル空間のデータベースに迷い込む。
—
2. 実装：空間自動判定・強制スイッチング・防壁ラッパー関数
現場のエンジニアに求められるのは、「エラーが起きてから気づくこと」ではなく、「エラーの発生余地をコードレベルで完全に排除すること」である。
以下のコードは、指定した空間（モデルまたはペーパー）へと確実にコンテキストを同期させ、意図した空間以外への図形生成を物理的に阻止する、堅牢なラッパー関数群である。
Option Explicit
‘ 空間識別のための列挙体（型安全性の一元管理）
Public Enum TargetSpace
Space_Model = 1
Space_Paper = 2
End Enum
”
‘ 指定した空間へ安全にコンテキストを同期させ、対応するブロックオブジェクトを返す防壁関数
‘ @param target 目的の空間（Space_Model または Space_Paper）
‘ @return AcadBlock 実際に図形を追加すべきアクティブな空間オブジェクト
‘ @throws 実行時エラー（不正な状態遷移時）
‘
Public Function SafeGetActiveSpace(ByVal target As TargetSpace) As AcadBlock
On Error GoTo ErrorHandler
Dim doc As AcadDocument
Set doc = ThisDrawing
‘ 1. UI上のActiveSpaceの同期
If target = Space_Model Then
If doc.ActiveSpace <> acModelSpace Then
doc.ActiveSpace = acModelSpace
End If
ElseIf target = Space_Paper Then
If doc.ActiveSpace <> acPaperSpace Then
doc.ActiveSpace = acPaperSpace
End If
Else
Err.Raise 9999, “SafeGetActiveSpace”, “不正なターゲット空間が指定されました。”
End If
‘ 2. 論理的なCurrentSpaceの取得と返却
‘ ActiveSpaceの変更直後は、確実にその空間のブロックポインタを返す
If doc.ActiveSpace = acModelSpace Then
Set SafeGetActiveSpace = doc.ModelSpace
Else
‘ ペーパー空間の場合、現在アクティブなレイアウトのペーパー空間ブロックを指す
Set SafeGetActiveSpace = doc.PaperSpace
End If
Exit Function
ErrorHandler:
‘ 異常系のログ出力・例外伝播のアーキテクチャ
MsgBox “空間制御エラー: ” & Err.Description, vbCritical, “AutoCAD VBA Architecture”
Set SafeGetActiveSpace = Nothing
End Function
—
3. 実戦投入：空間ミスを完全に根絶するトランザクション的アプローチ
上記のラッパー関数を使用することで、ビジネスロジック層は「自分がどこに図形を描いているのか」という無駄な煩わしさから解放される。以下に、モデル空間とペーパー空間の両方に、誤謬なく図形を振り分ける実用スクリプトを示す。
Sub ExecuteSecureDrawingAutomation()
‘ パフォーマンスとメモリの最適化：画面描画の凍結
ThisDrawing.Application.ScreenUpdating = False
Dim targetBlock As AcadBlock
Dim lineObj As AcadLine
Dim p1(2) As Double, p2(2) As Double
On Error GoTo CleanUp
‘ ==========================================
‘ シナリオA：モデル空間への確実な図形配置
‘ ==========================================
Set targetBlock = SafeGetActiveSpace(Space_Model)
If targetBlock Is Nothing Then Err.Raise 1000, , “モデル空間の取得に失敗しました。”
p1(0) = 0#: p1(1) = 0#: p1(2) = 0#
p2(0) = 100#: p2(1) = 100#: p2(2) = 0#
‘ 常に意図した空間オブジェクトに対して直接Addメソッドを呼ぶ
Set lineObj = targetBlock.AddLine(p1, p2)
‘ ※VBAのCOMオブジェクト参照はスコープ外で自動解放されるが、大規模処理時は明示的破棄を推奨
‘ ==========================================
‘ シナリオB：ペーパー空間への確実な図形配置
‘ ==========================================
Set targetBlock = SafeGetActiveSpace(Space_Paper)
If targetBlock Is Nothing Then Err.Raise 1000, , “ペーパー空間の取得に失敗しました。”
p1(0) = 20#: p1(1) = 20#: p1(2) = 0#
p2(0) = 80#: p2(1) = 20#: p2(2) = 0#
Set lineObj = targetBlock.AddLine(p1, p2)
MsgBox “空間制御を伴う図形生成が正常に完了しました。”, vbInformation, “System Success”
CleanUp:
‘ 異常終了時も確実に画面描画を復元する（メモリ・UIスレッドのデッドロック防止）
ThisDrawing.Application.ScreenUpdating = True
‘ オブジェクト変数の明示的破棄（COMラッパーのメモリリーク対策）
Set lineObj = Nothing
Set targetBlock = Nothing
If Err.Number <> 0 Then
MsgBox “致命的なエラーが発生しました: ” & Err.Description, vbCritical
End If
End Sub
—
4. チーフアーキテクトからの警鐘：レガシー環境におけるVBAの限界とメモリ最適化
ここまでのコードで、実務上の空間制御ミスは99.9%排除できる。しかし、数万図形を扱うエンタープライズ規模の自動化において、VBAのCOMラッパー構造は諸刃の剣となる。
1. COMオブジェクトの参照カウントとメモリリーク
`targetBlock.AddLine` のようなメソッドチェーンや、変数への代入をループ内で無秩序に行うと、AutoCADのプロセス（`acad.exe`）側にCOMオブジェクトの参照が残り続け、VBA終了後もメモリが解放されない現象（メモリブロー）が発生する。
ループ処理内では必ずインスタンスを使い回し、処理の終わりに `Set variable = Nothing` を明示的に実行せよ。
2. `ScreenUpdating = False` の不可欠性
空間（`ActiveSpace`）を切り替えるたびに、AutoCADのGUIは再描画（Viewport Regeneration）を走らせようとする。これを放置すると、プログラムの実行速度が目に見えて低下するだけでなく、画面のチラつきによってユーザーに心理的ストレスを与える。必ず描画をロックしてから空間制御を行え。
—
結論
AutoCAD VBAにおいて、「どこに描かれているか分からない」という現象は、技術の未熟さではなく、コンテキスト管理の設計思想の欠落に起因する。
`ActiveSpace` の切り替えとデータベース空間の同期を関数としてカプセル化し、システム全体の防壁とせよ。このアプローチを導入した瞬間から、あなたの書くAutoCADマクロは、単なる「動くスクリプト」から、工業用として耐えうる「堅牢なシステム」へと昇華する。
