SolidWorks VBAを掌握せよ：なぜ「今開いているのがパーツか」を厳密に判定すべきなのか
エンジニア諸君。業務自動化の旅路へようこそ。
SolidWorksの自動化で最も初心者が陥りやすく、かつ最も痛い目を見るのが「ドキュメント型の誤認」だ。アセンブリ（.sldasm）が開いている状態でパーツ用（.sldprt）のマクロを走らせ、数千個のフィーチャを誤って生成・破壊した経験はないか？
現場において「ごめん、間違えた」は通用しない。堅牢なシステムとは、エラーが起きないことではなく、エラーを起こさせないための「防波堤」が設計レベルで組み込まれているものだ。
今回は、`ModelDoc2.GetType`メソッドを使い、あなたのマクロを「プロの道具」へと昇華させるための厳密な判定ロジックを伝授する。
—
1. なぜ「雑な判定」では生き残れないのか
多くの初学者は、こう考える。「現在アクティブなドキュメントを取得すればいいだけだろ？」と。
‘ 危険なコード例
Set swModel = swApp.ActiveDoc
‘ ここでいきなりフィーチャ操作を始める（※これが悲劇の始まり）
これでは、図面（.slddrw）を開いているときにもマクロが暴走する。SolidWorksのAPIは強力だ。対象外のドキュメントに対してフィーチャ取得メソッドを投げれば、高確率でメモリリークや未定義エラー、最悪の場合はSolidWorksのクラッシュを招く。
我々が目指すべきは、「実行された瞬間に、期待した環境でなければ即座に親切な警告を出して停止する」という設計だ。
—
2. 実践：鉄壁のドキュメント判定ロジック
以下に、プロダクションコードとしてそのまま利用可能な、堅牢な判定テンプレートを提示する。
Option Explicit
‘ SolidWorks定数の定型
Const swDocPART As Long = 1
Sub ExecutePartMacro()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ 1. ドキュメントが開かれているかのチェック（NULLチェック）
If swModel Is Nothing Then
MsgBox “エラー：ドキュメントが開かれていません。”, vbCritical
Exit Sub
End If
‘ 2. 型チェック（GetTypeの真価）
If swModel.GetType <> swDocPART Then
MsgBox “エラー：このマクロはパーツファイル専用です。” & vbCrLf & _
“現在アクティブなファイル種別: ” & swModel.GetType, vbExclamation
Exit Sub
End If
‘ — ここから先は「パーツであること」が保証された聖域 —
Debug.Print “パーツ判定完了。安全に処理を開始します。”
‘ 実際のフィーチャ操作処理をここに記述
End Sub
このコードが「プロ仕様」である理由
- NULLチェックの徹底: `ActiveDoc`はファイルが開かれていないと`Nothing`を返す。ここを飛ばすと、以降の処理で必ず例外が発生する。
- マジックナンバーの排除: `1`と書かずに`swDocPART`という定数を用いることで、可読性と保守性を担保している。
- 早期リターン（ガード節）: メイン処理をネストさせず、エラー時は即座に抜ける。これによりコードの可読性が劇的に向上する。
—
3. さらに先へ：データベース連携時の注意点
もしこのマクロが、生成したパーツの情報をデータベース（CSVやSQL Server）に記録するタイプのものなら、判定はさらに重要だ。
「間違ったパーツ」の情報をデータベースに書き込んでしまったら、その整合性を修復するコストは計り知れない。「型判定」は単なる安全装置ではなく、データ保全のための「ゲートキーパー」であると認識してほしい。
業務自動化エンジニアへのアドバイス
1. GetPathNameを活用せよ: 判定の際、`swModel.GetPathName`でファイルパスが空（未保存）かどうかもチェックすると、ファイル保存を強制するフローも作れる。
2. ユーザーへのフィードバック: 単に止めるだけでなく、`MsgBox`で「何が起きたか」「何をすべきか」を明確に伝えろ。これができる開発者は、現場のエンジニアから信頼される。
—
結論
`ModelDoc2.GetType`を使った判定は、SolidWorks自動化の第一歩にして、最も重要な基礎だ。ここを疎かにするエンジニアは、一生「動くけれど壊れやすいコード」しか書けない。
君たちがこれから作るツールは、現場のエンジニアの手間を減らすためのものだ。そのツール自身がトラブルの元になっては本末転倒である。
さあ、コードを開け。まずは君の既存のマクロに、この「防波堤」を組み込むことから始めてみてほしい。それが、伝説への入り口だ。
