3D CAD「SolidWorks」の組立図から部品表を自動で出すマクロを、専門のプログラマーではない書き手が、実装のほぼ全部をAIに任せて作った。書き手が実際に手を動かしたのは、コードではなく「何を数え、何を除外するか」という3つの仕様判断だった。
非エンジニアがAIに実務ツールを作らせるときに人間側が先に決めておくべき仕様判断の実例3つと、その判断が実際のコードにどう落とし込まれているかの中身。
3D CADのSolidWorksには、組立図(アセンブリ)から部品表(BOM)を出す標準機能がある。だが今回は、それをそのまま使わず、開いているアセンブリをSolidWorks APIで直接走査して部品表を作るマクロを、ゼロから用意した。
書き手はSolidWorksやVBAを専門にするプログラマーではない。実装のほぼ全部をAIに任せて書かせている。ただし、AIに「部品表を作って」とだけ頼んで済んだわけではない。実際にコードに落ちているのは、標準のBOM機能では調整しにくい、実務ならではの細かい判断の積み重ねだった。
AIに実装を任せる前に、日本語で言葉にして決めておいた判断はこの3つ。
組立図の中には、部品そのものだけでなく「サブアセンブリ(部品をまとめた小さな組立図)」も含まれる。これをそのまま数えると部品表の数量がずれる。サブアセンブリ自体はカウントせず、内部の実部品だけを再帰的に展開して集計する、という仕様を先に決めている。同様に、抑制(Suppressed)された部品や、パスを持たない仮想部品も部品表からは除外する。
部品ファイルの名前は「型式_部品名」という命名規則で運用している。だが実際の現場では、部品名側にさらに「_」が混ざってしまう、命名規則違反のファイルが出てくる。これを無理に型式と部品名へ分割してしまうと、誤った型式が部品表に出力される。違反を検知したら型式を空欄にし、ファイル名全体をそのまま部品名として出力するというフォールバックを、あらかじめ仕様に入れている。
Excelへの出力はCreateObject("Excel.Application")による遅延バインディングで実装されている。VBAプロジェクトの「参照設定」ダイアログで事前にExcelのライブラリをチェックしておく必要がない設計で、他のPCへそのまま配ってもすぐ動く。専門知識のない書き手が「自分の環境以外でも動くこと」を優先条件として先に伝えたからこそ選ばれた実装方法だ。
ファイル名からの型式・部品名の解析は、優先順位付きのルールとして実装されている。
' 1. "P_" で始まる → 購入品(型式なし)
' 2. "_" を含む → 型式_部品名(最初の"_"で分割)
' ただし部品名側にさらに"_"が含まれる場合は命名規則違反として
' 型式を空欄にし、ファイル名全体をそのまま部品名に出力する
' 3. それ以外 → 型式のみ崩れた入力を例外扱いで落とすのではなく、「型式は空欄、部品名にファイル名をそのまま出す」という安全な着地先を用意している点が実務向きだ。エラーで止めてしまうと、部品表を作る作業そのものが止まってしまう。
他にも、仕様の細部がそのままコードの分岐として残っている。出力はExcelのA列(No)・C列(型式)・D列(部品名)・F列(数量)、1〜14行目は空欄にして15行目からデータを書き始める。保存先はアセンブリと同じフォルダに「部品リスト_<アセンブリ名>.xlsx」。ソート順は型式ありを型式の昇順、型式なしはその後に回す。そしてアセンブリが未保存の場合は、処理を進めず先に保存を促すエラーダイアログを出す。
エラーハンドリングも、思いつきではなく5パターンに分けて用意されている。SolidWorks未接続、アセンブリが開かれていない、開いているドキュメントがアセンブリ型でない、アセンブリが未保存、対象の部品が0件——それぞれに、原因が分かるメッセージを出す。
ここが核心。AIが書いたのはコードのほぼ全部だが、「何を数え、何を除外し、崩れた入力にどう着地させるか」を先に日本語で決めたのは書き手だった。専門知識がなくても実務レベルのツールができた理由は、AIの実装力より先に、この仕様判断が言葉にできていたことにある。
「部品表を出す」という一見単純な依頼の裏には、標準機能だけでは吸収しきれない現場の事情が隠れている。専門知識がなくても、その事情を先に言葉にできれば、実装はAIに任せられる。
このマクロには、材質・重量などのカスタムプロパティ取得、出力列の追加、命名規則チェックの強化という「今後の拡張時の想定箇所」があらかじめファイルの役割ごとに整理されている。専門知識がなくても、仕様を言葉にする力があれば、AIと一緒に実務で使えるツールを育てていける。