SolidWorks自動化の真髄：FSO×APIで構築する「堅牢なバッチ処理基盤」の設計思想
SolidWorksの自動化において、多くのエンジニアが陥る罠がある。それは「マクロを動かすこと」をゴールにしてしまい、「システムを運用すること」への想像力が欠如しているという点だ。
数千の部品を夜通し回すバッチ処理において、メモリリークや未処理のダイアログボックスは、即座にプロジェクトの停止を意味する。本稿では、VBAのレガシーな制約を逆手に取り、FileSystemObject（FSO）とSolidWorks APIを融合させた、現場で生き残るための「バッチ処理フレームワーク」の設計解を提示する。
—
1. なぜ「FSO」を選択するのか：設計の哲学
SolidWorks APIの `ISldWorks::GetSearchFolders` や `FileSearch` は便利だが、複雑なネットワークドライブや権限管理が絡む階層構造においては、制御不能に陥ることが多い。
一方、`Scripting.FileSystemObject` を基盤に据えることで、以下のメリットを享受できる。
- 決定論的制御: ファイルの列挙と処理順序を完全に握れる。
- 例外処理の分離: ファイルシステムレベルのアクセス拒否と、SolidWorksのドキュメントエラーを明確に切り分けられる。
- ポータビリティ: Windows環境であれば外部依存なしで動作し、保守性が極めて高い。
—
2. 実装：堅牢なバッチ処理エンジン
以下は、メモリのライフサイクルを最適化し、再帰的にフォルダを探索するバッチ処理のテンプレートである。
Option Explicit
‘ 参照設定: Microsoft Scripting Runtime
‘ 参照設定: SldWorks 20xx Type Library
Public Sub RunBatchProcess()
Dim fso As New Scripting.FileSystemObject
Dim swApp As SldWorks.SldWorks
Dim rootFolder As String
‘ SolidWorksプロセスの接続 (新規起動を推奨)
Set swApp = Application.SldWorks
rootFolder = “C:\Engineering\Projects”
‘ 再帰探索の開始
ProcessFolder fso.GetFolder(rootFolder), swApp
Set swApp = Nothing
Set fso = Nothing
End Sub
Private Sub ProcessFolder(folder As Scripting.Folder, swApp As SldWorks.SldWorks)
Dim subFolder As Scripting.Folder
Dim file As Scripting.file
Dim swModel As SldWorks.ModelDoc2
Dim errCode As Long, warnCode As Long
‘ ファイル処理
For Each file In folder.Files
If LCase(Right(file.Name, 7)) = “.sldprt” Or LCase(Right(file.Name, 7)) = “.sldasm” Then
‘ メモリ最適化: 必ず非表示モード(swOpenDocOptions_Silent)で開く
Set swModel = swApp.OpenDoc6(file.Path, swDocPART, swOpenDocOptions_Silent, “”, errCode, warnCode)
If Not swModel Is Nothing Then
‘ ここにビジネスロジックを実装
PerformCustomTask swModel
‘ 終了処理: メモリからの明示的破棄
swApp.CloseDoc swModel.GetTitle
Set swModel = Nothing
End If
‘ ガベージコレクションを促す(VBAの限界を補う)
DoEvents
End If
Next
‘ フォルダの再帰探索
For Each subFolder In folder.SubFolders
ProcessFolder subFolder, swApp
Next
End Sub
—
3. シニアエンジニアが守るべき「3つの鉄則」
① メモリ管理と `DoEvents` の罠
`swApp.OpenDoc6` を繰り返すと、SolidWorksの内部メモリキャッシュは瞬く間に肥大化する。`Set swModel = Nothing` を呼び出しても、即座にプロセスが解放されるわけではない。
バッチ処理では、数百ファイルごとにプロセスを再起動する（あるいは `swApp.ExitApp` を挟む）設計も検討すべきだ。また、`DoEvents` はプロセスのフリーズを防ぐが、連打しすぎるとパフォーマンスを阻害する。適度な間隔を見極めるのが職人芸である。
② Windows APIとの連携
もし処理中に発生する「ダイアログ」に阻まれる場合、VBA単体での解決を諦め、`User32.dll` の `FindWindow` や `SendMessage` を呼び出し、強制的に `WM_CLOSE` を送るラッパー関数を実装せよ。SolidWorksはダイアログが表示された瞬間にスレッドが停止するため、この「外からの強制力」こそが自動化の要となる。
③ エラーハンドリング：ログの構造化
標準の `Debug.Print` は論外だ。FSOを用いて、処理結果をCSV形式でログ出力せよ。
- ファイルパス
- 処理時刻
- ステータス（成功/失敗）
- エラーコード
これらを構造化データとして残すことで、翌朝のシステム管理者が「なぜこのファイルだけ失敗したのか」を即座に特定できる。
—
結びに：伝説のアーキテクトからの助言
自動化とは、ただコードを書くことではない。「マシンの挙動を制御下に置くこと」である。
SolidWorks APIは洗練されているが、巨大なアセンブリや複雑な参照関係を扱うとき、それは時に暴走する野獣となる。FSOを用いたこのフレームワークは、その野獣を制御するための「手綱」である。
コードは美しくあるべきだが、それ以上に「止まらないこと」がエンジニアリングの価値を決める。この基盤をベースに、各々の現場の要求に合わせた「カスタマイズ」を積み重ねてほしい。健闘を祈る。
