現場のエンジニアへ告ぐ:SolidWorksの「負の遺産」を殲滅する再帰的マイグレーション戦略
多くの企業で、共有サーバ内に数世代前のSolidWorksファイルが放置され、開くたびに発生する「再保存のプロンプト」や「バージョン不一致によるパフォーマンス低下」が現場の生産性を蝕んでいる。
これを手動で解決しようとするのはナンセンスだ。我々自動化エンジニアの仕事は、FSO(FileSystemObject)を用いた再帰的探索と、SolidWorks APIを組み合わせ、深夜のうちに全ファイルを最新のバージョンへと昇華させることにある。
本記事では、単に「動くコード」ではなく、「数万ファイルの海でもクラッシュせず、ログを残し、堅牢に完走する」ためのプロフェッショナルな設計を授ける。
—
1. なぜ「単純な再帰」では失敗するのか
多くの初心者は、FSOの `SubFolders` を再帰的に呼び出すだけのコードを書く。だが、実務環境では以下の壁に突き当たる。
- パスの長さ制限: 260文字を超える深い階層への対応。
- メモリリーク: SolidWorksのプロセスを適切に解放(`swApp.ExitApp` や参照の解除)しないと、メモリが食いつぶされ、500ファイル程度で沈黙する。
- ファイルロック: 他のユーザーが編集中、あるいは読み取り専用設定のファイルに遭遇した瞬間にエラーで停止する。
これらを解決するための要諦は、「イテレーションごとのクリーンな終了」と「厳格なエラーハンドリング」に尽きる。
—
2. 堅牢なマイグレーション・スクリプト(プロダクション・コード)
このコードは、指定ルート内のファイルを走査し、最新バージョンで保存し直す。ログファイルを出力することで、どのファイルで躓いたかを後から検証可能にしている。
‘ 必要な参照設定: Microsoft Scripting Runtime
Option Explicit
Dim swApp As SldWorks.SldWorks
Dim fso As FileSystemObject
Dim logFile As TextStream
Sub RunMigration()
Dim rootFolder As String
rootFolder = “C:\Projects\TargetFolder” ‘ ここにルートパスを入力
Set swApp = New SldWorks.SldWorks
Set fso = New FileSystemObject
Set logFile = fso.CreateTextFile(rootFolder & “\migration_log.txt”, True)
swApp.Visible = False ‘ バックグラウンドで動作させる
ProcessFolder fso.GetFolder(rootFolder)
logFile.Close
swApp.ExitApp
Set swApp = Nothing
MsgBox “マイグレーション完了。ログを確認してください。”
End Sub
Private Sub ProcessFolder(folder As Folder)
Dim file As file
Dim subFolder As Folder
Dim modelDoc As ModelDoc2
Dim errors As Long, warnings As Long
‘ ファイルの処理
For Each file In folder.Files
If UCase(fso.GetExtensionName(file.Path)) Like “SLDPRT|SLDASM|SLDDRW” Then
logFile.WriteLine “Processing: ” & file.Name
‘ ファイルを開く(読み取り専用ではなく書き込み可で開く必要あり)
Set modelDoc = swApp.OpenDoc6(file.Path, swDocNONE, swOpenDocOptions_Silent, “”, errors, warnings)
If Not modelDoc Is Nothing Then
‘ 最新バージョンで保存
modelDoc.Save
swApp.CloseDoc modelDoc.GetTitle
Else
logFile.WriteLine “ERROR: Failed to open ” & file.Name
End If
End If
Next
‘ サブフォルダを再帰的に探索
For Each subFolder In folder.SubFolders
ProcessFolder subFolder
Next
End Sub
—
3. 実務で「生き残る」ための3つの鉄則
① メモリ管理とプロセス再起動の判断
SolidWorksのAPIは非常に強力だが、メモリを食う。もしマイグレーション対象が1,000ファイルを超える場合は、スクリプト内で「100ファイル処理ごとに一度SolidWorksを再起動する」処理を入れるべきだ。メモリリークを物理的に強制リセットする、これが安定稼働の秘訣である。
② データベース(CSV/Excel)連携の重要性
上記のログはテキストファイルだが、本格的な運用では処理結果を「Excel」や「SQLite」に書き出すことを推奨する。
- ファイルパス
- 処理結果(成功/失敗)
- 所要時間
- 最終保存バージョン
これらをデータベースに蓄積することで、「どのプロジェクトのファイルが重いのか」「どのフォルダが更新頻度が高いのか」というメトリクスが見えてくる。これができるエンジニアは、単なる作業者ではなく「改善の仕掛け人」になれる。
③ 権限とネットワークトラフィックへの配慮
サーバ内を走査する場合、ネットワーク負荷がボトルネックになる。夜間実行を前提としつつ、`DoEvents` を適切に挟むことで、OS側のタイムアウトやハングアップを防ぐ工夫を怠らないこと。
—
結びに:自動化は「愛」である
今回紹介したコードは、単なるコードの断片ではない。皆さんのチームが抱える「過去の遺物」を整理し、未来のエンジニアがストレスなく開発に集中できる環境を作るための「技術的清掃ツール」だ。
自動化とは、単に楽をすることではない。不毛な手作業を排除し、クリエイティブな設計業務へ時間を割くための「愛のある投資」である。ぜひ、このコードをベースに、自社の環境に合わせた最高の自動化ツールを組み上げてほしい。
もし、さらに深い最適化(非表示ロードの高速化や、PdmWorks連携など)が必要であれば、いつでも尋ねてくれ。道は開いてやる。
