SolidWorks APIの深淵：堅牢なエラーハンドリングと「死なない」プロセスの設計術
SolidWorks APIを操る際、多くのエンジニアが「なんとなく動くコード」で満足し、実運用でのクラッシュに頭を抱えます。
「なぜかたまに落ちる」「バックグラウンドでSolidWorksがゾンビ化している」。これらはすべて、APIのライフサイクルと例外処理に対する甘えが原因です。本稿では、プロフェッショナルとして現場で生き残るための「例外を制する設計」を伝授します。
—
1. On Error Resume Next の「正しい」使い所
多くのチュートリアルが `On Error Resume Next` を「魔法の杖」として紹介しますが、これは「制御不能な暴走」への招待状です。
VBAにおいて、この命令は「エラーを無視する」のではなく「エラーをスタックに溜め込み、実行を継続させる」もの。これを広範囲に適用するのは自殺行為です。「エラーが予測可能であり、かつ即座に処理が可能な局所的範囲」に限定して使用するのが鉄則です。
2. GetObjectによる安全なインスタンス接続
SolidWorksが起動しているか、あるいはバックグラウンドでハングアップしているかを判別せずに処理を開始するのは危険です。`CreateObject` でむやみに新規プロセスを立ち上げるのはメモリリークの温床となります。
実務レベルで必須となるのは、「既存のプロセスをアタッチし、存在しなければ新規作成する」という多重防衛のアーキテクチャです。
プロダクションコード：安全な接続とエラーハンドリング
以下は、私がプロジェクトの基盤として常に実装する「堅牢な接続処理」のテンプレートです。
Option Explicit
‘ SolidWorks APIを安全に呼び出すための設計
Public Sub GetSolidWorksSession()
Dim swApp As SldWorks.SldWorks
‘ 1. エラーハンドリングのスコープを最小化する
On Error Resume Next
Set swApp = GetObject(, “SldWorks.Application”)
‘ 2. エラー判定：GetObjectで失敗した場合はCreateObjectを試みる
If Err.Number <> 0 Then
Err.Clear
Set swApp = CreateObject(“SldWorks.Application”)
‘ 3. それでも失敗した場合は完全終了
If Err.Number <> 0 Then
MsgBox “SolidWorksを起動できませんでした。”, vbCritical
Exit Sub
End If
End If
‘ 4. 必ずエラー制御を戻す（ここが重要！）
On Error GoTo 0
‘ 表示設定と可視化の制御
swApp.Visible = True
Debug.Print “SolidWorks Version: ” & swApp.RevisionNumber()
End Sub
—
3. なぜ「ModelDoc2」の取得で躓くのか
`swApp.ActiveDoc` を安易に使うのは避けましょう。ユーザーがドキュメントを閉じていたり、モーダルダイアログが開いていたりすると、APIは `Nothing` を返します。これに対するチェックを怠ると、続く `swModel.Save` などで即座に例外が発生します。
実務で守るべき3つの鉄則
1. Always Check for Nothing: `swModel` を取得した直後は、必ず `If swModel Is Nothing Then` で生存確認を行うこと。
2. Close Handling: ファイルを開く際は、パスの存在確認（`Dir()`関数を使用）を事前に行うこと。ファイルシステムとAPIのズレを許容してはいけません。
3. Ghost Processの掃除: `swApp.ExitApp` を呼ぶだけでは不十分なケースがあります。タスクマネージャにプロセスが残る場合は、明示的に参照を解放（`Set swApp = Nothing`）するライフサイクル管理を徹底してください。
—
4. データベース連携時の落とし穴
SolidWorksのAPIと外部DB（Excel/SQL Server）を連携させる際、最も多いエラーは「SolidWorksがビジー状態（モーダルダイアログ待機中）」によるタイムアウトです。
これを防ぐためには、「SolidWorksの応答状態を監視する設計」が必要です。`swApp.GetUserPreferenceToggle(swUserPreferenceToggle_e.swBlockFileSaveWhenOutOfDate)` 等のフラグを活用し、API操作前にドキュメントが編集可能かを確認するロジックを挟むことで、バックグラウンド実行の堅牢性は飛躍的に向上します。
最後に：エンジニアとしての矜持
「コードが動くこと」と「コードが壊れないこと」の間には、広大な川が流れています。
今回紹介した手法は、単なるテクニックではなく「システムという不確実な対象をいかに制御下に置くか」という設計思想です。エラーを「起きたら対応するもの」ではなく、「発生を予期して無効化するもの」と捉え直してください。
あなたの書くマクロが、誰かの業務を止めるのではなく、誰かの時間を創出する「信頼できる自動化」となることを期待しています。
