STEPから部品表を「確認する」と「作る」は別の話
200品以上が1ユニット。製作品20品・購入品20品・ボルト類100品が集まった製品だから、確認のたびに部品表を見ていた。
「これ何個入ってたっけ？」の繰り返し。
部品表抽出ツールを作ってから、その部分は随分楽になった。でも、客先に送る発注書用の部品表を作るのは、まだ別の話だった。
部品表を確認する作業 vs 部品表を作る作業
最初、部品表抽出について「STEP（3D CADの標準的な中間ファイル形式）があれば、部品表は全部自動」と思ってた。でも現場でやってみると、2つの作業は違う。
パターン1: 部品表の確認（レビュー・設計チェック）
この組立品に何が入ってるのか、ぱっと知りたい
このときは、数量が不正確でも大丈夫。
例えば、M3×10のネジが本当は10個入ってるのに「1個」と表示されても、「あ、M3×10のネジが使われてるんだ」がわかればいい。
標準部品の選定漏れを見つけたり、設計レビューで「こんな部品も使うんだ」と確認するだけなら、正確な数量はいらない。
実装: STEPから読んだ部品名をそのまま並べてOK。簡単な部品名の抽出ならCadQuery（Pythonで3D形状を扱うライブラリ）でできる。
パターン2: 発注用の部品表（客先提出・在庫管理）
正確な数量がないと成り立たない
同じネジが複数個入ってるなら「10個」と数えないといけない。「1個」では発注できない。
手作業の補正が避けられない。
でも、このために階層構造の解析にコストをかけるのが本当に必要か？という疑問もある。
MVP版の制約は「計画的」
部品表抽出ツールを作るとき、階層構造対応（pythonocc-coreという別の重いライブラリが要る）の実装も検討した。
でも、実装コスト vs 実用性のバランスを見て、単純なCadQuery版で先に出すことにした。
理由は、設計現場で実際に「必要になる順番」がある。
- 今すぐ使いたい: 「このアセンブリに何が入ってるのか確認したい」（CadQueryで可能）
- あとで必要: 「正確な発注部品表を作りたい」（階層構造が要る）
1を先に出して、本当に2が必要か、どんなタイミングで必要か、ユーザーに聞きながら進める。
最初から「完璧な部品表」を目指して何ヶ月もかけるより、まず動くものを早めに出して、フィードバック取りながら伸ばす方が早い。
Streamlit版で試してみる
社内向けに、STEPをアップロードして部品表を確認できるWebアプリを作ってみた（Streamlit = Pythonだけで簡単なWebアプリをつくれるツール）。
オープンソースのSTEPで動作確認したときは、部品名を入力 → 重複を自動集計、みたいなイメージだった。
ただ、実際の運用ではまだやってないから、本当に「ザッと一覧が見たい」という現場ニーズを満たせるのか、実データで試してからになる。
「調べてわかったこと」と「実装した機能」は別
外部との比較機能について。最初は「複数の仕様書から自動抽出して比較したら便利じゃないか」と思ってた。
調べてみると、仕様書の形式がバラバラだから自動化は難しい。
他社の事情も知らずに「標準仕様」を決めるわけにはいかない。実装するなら、顧客ごとに合わせる必要があって、汎用ツールの形では成り立たない。
そもそも客先は「こっちの仕様書と違う」ということを自分たちで気づくはず。うちが勝手に比較機能を作るより、「変更がどこにあるのか目視で確認できる方が早い」という方針に落ち着いた。
次のステップはユーザー実データ
オープンソースのSTEPで検証したから、基本的な動きは確認できた。次は、実際に設計した部品表で試す。
「こういう名前が付いてたら、実はこの部品だ」というパターンは、ユーザーごとに違う。その癖を知ることで、自動抽出の精度も上がる。
完璧なツール → ユーザーに試してもらう、ではなく、まず動くものを出してフィードバック受けて改善する。その方が、最終的には使える形に落ち着く。
ドコカワの部品表確認機能をWebで試すことができます。STEPファイルをアップロードするだけで、アセンブリに含まれる部品が一覧で出る。この「ザッと確認したい」という局面では、手作業の補正を入れる前提で十分。
現場で「あ、これ必要だ」と気づいたことを、その順番で実装していく。それが本当に使えるツールになる道だと思ってる。