規格外の自動化：JSON駆動型SolidWorksパーツ生成アーキテクチャの真髄
Excelを設計の「データベース」として利用する時代は終わった。重厚長大なマクロ付きブックは、共有のたびにリンク切れやメモリリークの温床となり、VBAエンジニアの寿命を削る。
真の自動化アーキテクチャを目指すなら、設計仕様は「疎結合」であるべきだ。今回は、`FileSystemObject (FSO)`と`JSON`を統合し、SolidWorksのパーツ生成を極限まで軽量化・高速化する「パラメータ駆動型基盤」の設計思想を伝授する。
—
1. なぜ「JSON + FSO」なのか
設計資産をJSONで管理するメリットは、単なる可読性ではない。
- バージョン管理の親和性: Gitなどのソース管理ツールで差分が明示できる。
- システム間連携の抽象化: Webサーバーや他言語（Python/C#）で生成されたパラメータを、そのままVBAで受け取れる。
- メモリ効率: ExcelのCOMオブジェクトを介さないため、読み込みオーバーヘッドが極小。
VBAには標準のJSONパーサーが存在しないが、`ScriptControl`や`MSScriptControl`を利用する手法は今や推奨されない（32bit/64bitの壁が厚すぎるためだ）。ここでは、堅牢な運用を前提とした「最小構成でのJSONパースとパーツ生成」の流儀を解説する。
—
2. 堅牢なパーツ生成エンジンの実装
以下のコードは、単なるサンプルではない。メモリリークを許さないオブジェクト解放と、JSONから読み取った値でスケッチを制御する「基幹エンジン」の雛形だ。
‘ 必要なライブラリ: Microsoft Scripting Runtime
‘ ※JSONパーサーは別途、軽量な「VBA-JSON」ライブラリ等のクラスモジュールを組み込むことを推奨
Option Explicit
Public Sub BuildPartFromJson(ByVal jsonPath As String)
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim fso As FileSystemObject
Dim jsonText As String
Dim data As Object ‘ JSONパース結果
‘ 1. インスタンスの取得（既知のセッションを利用）
Set swApp = Application.SldWorks
Set fso = New FileSystemObject
‘ 2. メモリ効率を考慮したファイル読み込み
If Not fso.FileExists(jsonPath) Then Err.Raise 53, , “仕様書が見つかりません”
jsonText = fso.OpenTextFile(jsonPath, ForReading).ReadAll
‘ 3. JSONパース（外部モジュール想定）
Set data = JsonConverter.ParseJson(jsonText)
‘ 4. パーツ新規作成
Set swModel = swApp.NewDocument(swApp.GetUserPreferenceStringValue(swUserPreferenceStringValue_e.swDocTemplatePart), 0, 0, 0)
‘ 5. フィーチャ操作の実行
Call GenerateGeometry(swModel, data)
‘ 6. クリーンアップ（極めて重要）
Set fso = Nothing
Set swModel = Nothing
End Sub
Private Sub GenerateGeometry(swModel As SldWorks.ModelDoc2, data As Object)
Dim swFeatMgr As SldWorks.FeatureManager
Set swFeatMgr = swModel.FeatureManager
‘ パラメータ駆動による寸法制御
‘ オブジェクトの明示的な解放を怠らないこと
swModel.Parameter(“D1@Sketch1”).SystemValue = data(“Length”) / 1000
swModel.Parameter(“D2@Sketch1”).SystemValue = data(“Width”) / 1000
swModel.ForceRebuild3 True
End Sub
—
3. シニアエンジニアが守るべき「メモリ解放の作法」
SolidWorksのAPIは、COMインターフェースの集合体だ。VBAのガベージコレクションに頼るなどという甘えは、長大なループ処理において必ず「メモリ不足によるクラッシュ」という形でしっぺ返しを食らう。
- SET NOTHINGの徹底: `swModel`、`swFeat`、`swSketch`などのオブジェクト変数は、スコープを抜ける前に必ず `Set = Nothing` を宣言する。
- ForceRebuildの制御: ジオメトリ更新のたびに `ForceRebuild` を呼ぶのは素人のやり方だ。すべてのパラメータ更新を終えた後、最後に一度だけ呼び出す。これがパフォーマンスを10倍にする秘訣である。
- エラーハンドリング: 外部ファイル（JSON）は常に破壊される可能性がある。`On Error GoTo` による厳格なエラーキャッチを実装し、異常終了時に `swApp` がゾンビプロセスとして残らないようにせよ。
—
4. 拡張性：レガシーシステムからの脱却
このアーキテクチャの真価は「システムの疎結合化」にある。
もし将来、設計仕様の生成をExcelからWebアプリやデータベースへ移行したとしても、「JSONファイルを出力する」というインターフェースさえ維持すれば、VBA側のコードは一行も変更する必要がない。
これが、10年先まで生き残るシステムを構築するチーフアーキテクトの矜持だ。
推奨される次のステップ
1. バリデーション: JSONのスキーマチェックを実装し、異常値を弾くレイヤーを設けること。
2. ログ出力: FSOを使用して、処理時間とエラーログをテキストファイルに蓄積し、ボトルネックを可視化すること。
コードは美しく、動作は無駄なく。それが、我々が目指すべきエンジニアリングの極致だ。健闘を祈る。
