【SolidWorks VBA極限解説】ActiveDocの幻想を断つ：型安全なドキュメント取得と誤作動完全防止のアーキテクチャ
工業用CADの自動化において、マクロの安定性はそのまま現場の生産性に直結する。特にSolidWorks VBA開発において、最も頻繁に犯される致命的な設計ミスが、`SldWorks.Application.ActiveDoc`の無防備な呼び出しだ。
「現在アクティブなドキュメントを取得し、何らかのパーツ操作を行う」――この一見自明に見える処理こそが、レガシーな現場におけるマクロ暴走、不意のクラッシュ、そしてデータ破損の温床となっている。
本稿では、ActiveDocが孕む本質的な危険性を暴き、実務レベルで破綻しない「型安全かつ堅牢なドキュメント取得・判定イディオム」を、チーフアーキテクトの視点から徹底的に解説する。
—
1. なぜ `ActiveDoc` は地雷なのか？
多くの初心者は、次のようなコードを書く。
‘ 【アンチパターン】絶対に書いてはならない危険なコード
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ swModel が Nothing かどうかしか見ていない
swModel.Extension.SelectByID2 …
このコードの何が問題か？ 理由は大きく3つある。
1. ヌルポインタ例外の危険性: SolidWorks上で何もファイルが開かれていない状態（初期起動直後や全クローズ時）では、`ActiveDoc` は `Nothing` を返す。ここでプロパティやメソッドにアクセスすれば、即座に実行時エラー（Runtime Error 424: オブジェクトが必要です）が発生する。
2. 型の不確定性 (Polymorphismの罠): `ActiveDoc` が返すのは、抽象化された `ModelDoc2` インターフェースである。これが「パーツ（PartDoc）」なのか、「アセンブリ（AssemblyDoc）」なのか、「図面（DrawingDoc）」なのかは、この時点では一切保証されていない。パーツ専用のマクロをアセンブリが開いている状態で実行すれば、想定外の挙動を引き起こす。
3. COMオブジェクトのライフサイクル管理の欠如: VBAにおけるCOMラッパーの扱いは繊細だ。暗黙的に生成されるオブジェクト参照を適切にハンドリングし、メモリリークやSolidWorksプロセス自体の不安定化を防ぐ視点が欠落している。
—
2. 型安全なドキュメント取得と厳密な型判定のアーキテクチャ
プロフェッショナルなVBA開発において、祈るようなコーディングは許されない。アプリケーションの状態を厳密に検証し、意図したドキュメント型である場合のみ処理を通過させる「ガード cláusula（ガード節）」のパターンを実装する。
SolidWorksのドキュメントタイプは、`swDocumentTypes_e` 列挙体で定義されている。
- `swDocPART` (1)
- `swDocASSEMBLY` (2)
- `swDocDRAWING` (3)
これを利用し、「①アプリの生存確認」→「②アクティブドキュメントの有無確認」→「③ドキュメントタイプの厳密な型判定」 の3段構えで安全性を担保する。
—
3. 実装コード：極限まで堅牢性を高めたパーツ操作テンプレート
以下のコードは、実務の現場でそのまま流用できる、パーツ専用マクロのエントリポイント（標準モジュール）である。
Option Explicit
‘ ==============================================================================
‘ 処理名: パーツファイル専用・安全なドキュメント取得テンプレート
‘ 概要 : アクティブドキュメントの存在確認と、型安全なキャストを行う
‘ ==============================================================================
Public Sub ExecutePartAutomation()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swPart As SldWorks.PartDoc
‘ 1. SldWorksアプリケーションインスタンスの取得
‘ ※VBA環境では ComHelpers や GetObject ではなく、標準の SldWorks 接続を使用
Set swApp = GetObject(, “SldWorks.Application”)
If swApp Is Nothing Then
MsgBox “SolidWorksが起動していません。”, vbCritical, “致命的エラー”
Exit Sub
End If
‘ 2. アクティブドキュメントの取得（ガード節）
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then
MsgBox “現在、開かれているドキュメントがありません。” & vbCrLf & _
“対象のパーツファイルを開いてから実行してください。”, vbExclamation, “警告”
GoTo CleanUp
End If
‘ 3. ドキュメントタイプの厳密な型判定（型安全の担保）
‘ swModel.GetType() は swDocumentTypes_e を返す
If swModel.GetType <> swDocPART Then
Dim currentType As String
Select Case swModel.GetType
Case swDocASSEMBLY: currentType = “アセンブリ”
Case swDocDRAWING: currentType = “図面”
Case Else: currentType = “不明なドキュメント”
End Select
MsgBox “このマクロは「パーツ」ファイル専用です。” & vbCrLf & _
“現在アクティブなドキュメントは [” & currentType & “] です。”, vbCritical, “型不一致エラー”
GoTo CleanUp
End If
‘ 4. パーツ専用インターフェースへの安全なキャスト
‘ ModelDoc2 から PartDoc へのダウングレード（または特化インターフェースへのバインド）
Set swPart = swModel
If swPart Is Nothing Then
MsgBox “パーツインターフェースへのキャストに失敗しました。”, vbCritical, “COM例外”
GoTo CleanUp
End If
‘ ==============================================================================
‘ 【メイン処理領域】 ここから下にパーツ特有のロジックを記述する
‘ ==============================================================================
Call RunBusinessLogic(swApp, swModel, swPart)
CleanUp:
‘ 5. メモリ最適化と参照の明示的解放（Garbage Collectionの補完）
‘ ローカルスコープであっても、COMオブジェクトは確実にNothing化する
Set swPart = Nothing
Set swModel = Nothing
Set swApp = Nothing
End Sub
‘ ==============================================================================
‘ 実際のビジネスロジックをカプセル化するプロシージャ
‘ ==============================================================================
Private Sub RunBusinessLogic(ByRef swApp As SldWorks.SldWorks, _
ByRef swModel As SldWorks.ModelDoc2, _
ByRef swPart As SldWorks.PartDoc)
‘ 例：アクティブパーツのファイル名を取得してログ出力
Dim docTitle As String
docTitle = swModel.GetTitle
Debug.Print “正常処理完了: ” & docTitle & ” は有効なパーツドキュメントです。”
MsgBox “パーツの検証に成功しました。” & vbCrLf & “対象: ” & docTitle, vbInformation, “完了”
End Sub
—
4. チーフアーキテクトからの技術的提言
COM参照の解放（`Set 〇〇 = Nothing`）の重要性
VBAのランタイムはガベージコレクションを内包しているが、これはCOM（Component Object Model）の参照カウントを完全に制御できるものではない。特にSolidWorksのようなリソースヘビーなCADアプリケーションを背負うVBA環境では、プロシージャ終了時の明示的な `Nothing` 代入が、プロセス残存（ゾンビプロセス）やメモリリークを防ぐための唯一にして最大の防衛策となる。
システム間連携における拡張性
将来的にこのVBAマクロを、外部のC#/.NET製アドインや、PDMシステムからのバッチ実行へとスケールアップさせる時、このような「型安全なガード節」の積み重ねがそのまま活きてくる。場当たり的なコードは負債を産むが、厳密な型チェックと例外耐性を持つコードは、そのままエンタープライズアーキテクチャの部品へと昇華できる。
妥協のないコードだけが、現場の信頼を勝ち取る。明日からの実装において、`ActiveDoc` の直叩きを即座に封印し、本稿で示した厳格な型安全イディオムを標準装備とされたい。
