AutoCAD VBAの深淵：Offsetメソッドを「実務レベル」で掌握する極限の設計論
AutoCADの自動化において、最も頻出かつ「地雷」を踏みやすいのが`Offset`メソッドだ。
ネット上に転がっているコードの多くは、単にメソッドを呼び出すだけの「おもちゃ」に過ぎない。実務で求められるのは、「例外を握りつぶさず、図面データベースの整合性を守り、かつ保守可能なコード」である。
今日は、AutoCAD VBAのチーフアーキテクトとして、オフセット処理を現場レベルで完遂させるための設計指針を伝授する。
—
1. Offsetメソッドが抱える「3つの罠」
初学者が`Offset`で躓くのは、以下の3点だ。これを回避しなければ、君のプログラムは「たまに落ちる」という最悪の仕様になる。
1. 戻り値の不確実性: `Offset`メソッドは、結果として生成されるオブジェクトが1つとは限らない（ポリラインのオフセットは1つだが、曲線によっては分裂する可能性がある）。戻り値は常に`Variant`配列（オブジェクトの配列）で返されることを理解せよ。
2. 法線ベクトルの誤解: 2D操作だと思っていても、AutoCADの座標系は常に3Dだ。オフセット方向（点）を指定する際、UCSとWCSの混同は致命的な計算ミスを引き起こす。
3. 図面データベースの同期: `Update`メソッドを過信してはならない。データベースへの反映タイミングを制御しなければ、連続処理で旧い図形を参照し続けるリスクがある。
—
2. 実務仕様のプロダクションコード
以下に、エラーハンドリングを完備し、柔軟に運用可能なプロシージャを提示する。これをベースに君の業務ロジックを構築せよ。
‘ ==============================================================================
‘ 機能: 指定オブジェクトをオフセットし、新オブジェクトを生成する
‘ 引数: targetObj – オフセット元オブジェクト
‘ offsetDist – オフセット距離
‘ pointOnSide – オフセット方向を示す点
‘ ==============================================================================
Public Sub CreateOffsetEntity(ByVal targetObj As AcadEntity, _
ByVal offsetDist As Double, _
ByVal pointOnSide As Variant)
Dim offsetObjs As Variant
Dim i As Integer
On Error GoTo ErrorHandler
‘ 1. オフセットの実行
‘ オブジェクトがオフセット可能か事前に検証するロジックを挟むのがプロの流儀
offsetObjs = targetObj.Offset(offsetDist, pointOnSide)
‘ 2. 戻り値の処理（配列として受け取る）
For i = LBound(offsetObjs) To UBound(offsetObjs)
Dim newObj As AcadEntity
Set newObj = offsetObjs(i)
‘ 3. 後処理（色変更、画層変更など）をここで行う
newObj.Color = acRed
newObj.Update
Next i
Exit Sub
ErrorHandler:
‘ 単なるログ出力ではなく、何が原因でオフセット不能だったかを解析し
‘ プロセスを停止させるか、スキップするかを厳密に制御する
Debug.Print “Offset Error: ” & Err.Description & ” | Object Handle: ” & targetObj.Handle
Resume Next
End Sub
—
3. 堅牢なシステムを構築するためのアーキテクチャ設計
ファイル・DB連携の際の注意点
もし君が、CSVやExcelから座標やオフセット距離を読み込んで一括処理するツールを作るなら、「処理の塊（トランザクション）」を意識しろ。
- Undoログの制御: 1000個の線をオフセットする際、一つ一つにUndoを効かせるのはメモリの無駄だ。処理の前後で`ThisDrawing.StartUndoMark`と`EndUndoMark`を配置し、処理単位を明確にせよ。
- オブジェクトの寿命管理: `Set`した変数には必ず責任を持つこと。ループ内で生成したオブジェクトの参照を保持し続けると、メモリリークを招く。処理が終われば即座に`Nothing`を代入する習慣を徹底せよ。
なぜこれが「非効率な書き方」ではないのか
多くのエンジニアは、単にメソッドを並べるだけで満足する。しかし、実務では「どの画層に配置するか」「元のオブジェクトと属性を継承するか」といった要件が必ず後から追加される。
上記のコードのように、戻り値を配列で受け取り、個別に属性操作を行う設計にしておけば、将来的な仕様変更（例：オフセット線を特定の画層に移動させる等）にも数行の追加で対応可能だ。これが「拡張性」というものだ。
—
最後に：チーフアーキテクトからの提言
AutoCAD VBAはレガシーな言語と思われがちだが、そのオブジェクトモデルは極めて精緻に設計されている。
「動けばいい」コードは誰でも書ける。しかし、「図面データベースの不整合を許さず、メンテナンスコストを最小化するコード」を書くことこそが、君をエンジニアとして一段階上のステージへと引き上げる。
次は、このオフセット処理に「交差判定」や「フィルタリング」のロジックを組み合わせていく必要があるだろう。その時、この設計が君の強力な基盤になるはずだ。
妥協のないコードを書き続けろ。それが、プロフェッショナルの矜持だ。
