設計者のための3D CADモデリングルール——後から困らない命名・構造管理

はじめに——「このデータ、誰が作ったんですか」

「以前の担当者が作ったCADデータを引き継いだが、ファイル名がバラバラで何がどの部品か分からない」「アセンブリを開くとリンクが切れだらけだ」——こういった問題を経験したことがある設計者は多いはずだ。

筆者は機械設計者として20年以上、装置メーカーや客先常駐先で3D CADを使い続けてきた。独立して個人事業主になった今も、過去に自分が残したデータや、他社から引き継いだデータと向き合う機会は多い。その経験から断言できるのは、「モデリングが上手い」ことと「データ管理が上手い」ことは、まったく別のスキルだということだ。どれほど美しい形状を作れても、ファイル名がバラバラで、アセンブリのリンクが切れやすい構造であれば、そのデータはチームの資産にはならない。むしろ後任者の足を引っ張る負債になる。

3D CADはモデリング能力だけでなく、「管理しやすいデータをどう作るか」がチームとしての生産性を左右する。この記事では、3D CADのモデリングにおける命名規則・構造管理の実務ポイントを、筆者自身の失敗談も交えながら解説する。SolidWorks、Inventor、Fusion 360といった代表的なCADごとの違いや、PDM(製品データ管理システム)との役割分担にも触れるので、これからルールを整備しようとしているチームの参考にしてほしい。

なぜ命名・構造管理が重要なのか

設計データは「作った人が使うもの」ではなく「チームで使い続けるもの」だ。これは口で言うのは簡単だが、実際に徹底できているチームは少ない。特に納期に追われている現場では、「とりあえず動けばいい」「とりあえず図面が出ればいい」という意識が先行し、命名や構造の整理は後回しにされがちだ。しかしその「後回し」のツケは、必ず誰か——多くの場合は自分自身か、後任の設計者——が払うことになる。

良いデータ管理がされていると、次のような効果がある。

• 他者が引き継いでも迷わない: どのファイルが何の部品かが一目で分かる
• 変更対応が早い: 変更が必要な箇所をすぐに特定できる
• 流用設計が楽になる: 過去モデルを効率よく活用できる

逆に管理が悪いと、次のような問題が起きる。

• ファイルの在り処が分からず時間を無駄にする
• リンク切れ・バージョン混在のアセンブリが出来上がる
• 過去設計の再利用ができず、毎回ゼロから設計する羽目になる

特に深刻なのは3つ目の「過去設計が再利用できない」という問題だ。多くの機械設計は、まったくのゼロから生まれるわけではなく、過去の類似機構を参照・流用しながら組み立てられていく。ところが命名がバラバラで構造も整理されていないと、探索コストが毎回発生し、結局は流用を諦めてゼロから設計し直すことになる。これは個人にとってもチームにとっても、大きな機会損失だ。

ファイル命名規則のポイント

命名規則は「誰が見ても意味が分かる」ことが大原則だ。以下の要素を組み合わせてルール化する。

プレフィックスで種別を明示する

部品図・アセンブリ・板金・標準品など、種別がファイル名から判断できるようにする。

例:

• ASM_搬送ユニット_v01.sldasm → アセンブリ
• PRT_サポートブラケット_001.sldprt → 部品
• SHT_カバー板_001.sldprt → 板金部品

プレフィックスのルールはチームで統一することが重要で、個人の判断でバラバラにしないことだ。誰か一人が独自ルールで命名を始めると、そのファイルだけが「浮いた」存在になり、検索性が一気に落ちる。

バージョン管理を名前に含める

ファイル名に版数(v01, v02)やリビジョン(A, B, C)を含めることで、古いバージョンと最新版が混在するトラブルを防ぐ。ただし、PDMがある場合はシステムにバージョン管理を任せ、ファイル名には含めない場合もある。

日本語・英語の使い分け

日本語ファイル名はWindowsでは概ね動作するが、他OS環境・PDMシステムへの持ち込み時に文字化けの原因になることがある。英数字表記をメインにして、日本語は注釈・説明に限定するのが安全だ。

PDM(製品データ管理システム)との役割分担

ある程度の規模の設計組織になると、ファイルサーバー上のフォルダ管理だけでは限界が来る。ここで登場するのがPDM(Product Data Management)だ。PDMは、CADファイルのバージョン管理・チェックイン/チェックアウト・変更履歴・承認フローなどを一元管理するシステムで、SolidWorks PDM、Autodesk Vault、Windchillなどが代表的な製品として知られている。

PDMを導入すると、ファイル名に版数を書き込む必要がなくなる、複数人が同じファイルを同時に編集してしまう事故を防げる、変更履歴が自動的に記録される、といったメリットがある。中小規模の設計チームでは、まずはファイルサーバー上での命名規則・フォルダ構成の徹底から始め、データ量やメンバー数が増えてきた段階でPDM導入を検討する、という段階的なアプローチが現実的だ。

CADソフトごとの管理機能の違い

• SolidWorks: ファイル単位(.sldprt/.sldasm/.slddrw)で管理する伝統的な方式。PDMとの連携(SolidWorks PDM)も強力。
• Autodesk Inventor: iPart・iAssemblyというパラメトリックな部品ファミリー機能があり、標準品のバリエーション管理がしやすい。
• Fusion 360: クラウドベースのデータ管理(Fusion Team)が標準搭載されており、「プロジェクト」単位でデータが管理される。

アセンブリ構造の設計方針

サブアセンブリを機能単位で分ける

1つのトップアセンブリにすべての部品を入れるのではなく、「搬送ユニット」「昇降ユニット」「フレーム」など機能単位でサブアセンブリを作る。

• サブアセンブリ単体での干渉チェック・性能確認ができる
• 変更時に影響範囲がサブアセンブリ内に限定される
• 後工程での組立指示書・分解手順書が作りやすくなる

標準品・購入品の管理

市販ボルト・ベアリング・シリンダなどの購入品は、自社製作部品とは別のフォルダに格納する。取り込んだ時点で自社の命名規則にリネームし、型番・仕様が分かるように整理しておくと、後から探しやすくなる。

スケルトン(骨格)設計の活用

複雑な機械を設計する場合、まず「スケルトン(骨格)モデル」として主要な寸法・取り付け基準を定義してから各部品を作るアプローチが有効だ。ただし参照関係が複雑になりすぎると、逆にブラックボックス化を招くリスクもある。スケルトンに含める要素は「装置全体のレイアウトに関わる基準寸法」に絞る、というバランスが実務では扱いやすい。

フィーチャー命名とモデル管理

部品モデル内のフィーチャー(押し出し・穴・フィレット等)の命名も重要だ。

悪い例: 押し出し1、切り取り2、フィレット3(デフォルト名そのまま)

良い例: メインボディ押し出し、取付穴カット、エッジフィレット

フィーチャー名が分かりやすいと、後からモデルを修正する際に「どのフィーチャーを変更すれば良いか」がすぐに分かる。フィーチャーツリーが長くなる複雑な部品では、フォルダ機能を使い、工程・機能ごとにまとめておくとさらに追いやすくなる。実際、筆者自身も客先常駐時代に「切り取り-押し出し14」のようなフィーチャーを修正する羽目になり、特定するだけで半日費やした経験がある。

図面(2Dドローイング)との連携管理

図面はモデルの派生物でありながら、実際に加工現場や外注先に渡る「最終成果物」でもあるため、モデル以上に慎重な管理が求められる。部品モデル「PRT_サポートブラケット_001.sldprt」に対応する図面は、拡張子だけを変えた「PRT_サポートブラケット_001.slddrw」のように、ファイル名の本体部分を完全に一致させるのが基本だ。

モデルの保存場所を移動した、モデルファイルをリネームした、といった操作を行うと、図面側の参照が切れてしまうことがある。これを防ぐには、モデルと図面を必ず同じフォルダ階層内で管理し、リネームや移動を行う際は専用のツールを使うことが重要だ。

フォルダ構成のテンプレートを作る

プロジェクト開始時のフォルダ構成をテンプレート化することで、毎回ゼロから構造を考える手間が省ける。

例: 基本フォルダ構成

プロジェクト名├── 3Dモデル│ ├── アセンブリ│ ├── 部品│ └── 標準品├── 図面├── 仕様書└── 変更履歴

階層を増やしすぎると逆にファイルを探しにくくなるので注意したい。フォルダの階層は3〜4階層程度に抑え、それ以上細かく分類したい場合はファイル名側の命名規則でカバーする、という設計にするのが扱いやすい。

現場で経験した失敗と改善のエピソード

エピソード1:客先常駐先で味わった「命名地獄」

客先常駐をしていた時期、ある装置メーカーのプロジェクトに参画した際、既存のCADデータフォルダを見て言葉を失ったことがある。ファイル名は「部品1」「部品1_修正」「部品1_修正2」「部品1_これ最新」といった具合で、どれが本当に最新なのか、誰も断言できない状態だった。結局、その現場では過去データの棚卸しに丸2日を費やし、命名規則を新たに定義し直すところから作業をやり直した。命名規則は後から直そうと思うと、既存データの量に比例してコストが跳ね上がる。

エピソード2:スケルトン参照の暴走で丸1日を溶かした話

別のプロジェクトでは、装置全体の基準寸法をスケルトンモデルにまとめ、各部品がそれを参照する構造で設計を進めていた。ある日、フレームの基準位置を10mmだけ変更したところ、まったく関係ないと思っていた昇降ユニットの一部が干渉を起こすようになった。原因を追うと、昇降ユニットの取付基準が、実はスケルトンの別の参照点経由で間接的に依存していたことが判明した。以来、スケルトンを使う際は必ず参照関係の一覧をExcelなどで作成し、変更時にはその一覧を先にチェックする習慣をつけている。

エピソード3:独立後に痛感した「未来の自分への引き継ぎ」

個人事業主として独立してからは、チームメンバーへの引き継ぎではなく「半年後・1年後の自分」への引き継ぎを意識するようになった。特に確定申告の時期になると、過去の案件データを見返して工数や経費を整理する必要が出てくる。20年以上、毎年欠かさず確定申告を続けてきた身としては、設計データの整理と、案件ごとの記録整理は表裏一体だと感じている。「チームのため」だけでなく「未来の自分のため」という視点を持つと、一人で仕事をしている設計者でも命名・構造管理の重要性が実感しやすくなる。

命名規則の運用を定着させるコツ

ルールを一度決めても、現場に定着しなければ絵に描いた餅で終わる。ここでは、実際にチームで命名規則を根付かせるために有効だった工夫をいくつか紹介する。

テンプレートファイルを用意する

命名規則を文書化するだけでなく、実際に正しい名前がついた空のテンプレートファイル(部品用・アセンブリ用・図面用)を共有フォルダに置いておくと、メンバーはそれをコピーして作業を始めるだけで自然とルールに従うようになる。人は文書を読むより、目の前にある実例をなぞる方がずっと定着しやすい。

定期的な棚卸しを仕組みにする

月次や四半期ごとに、フォルダ内のファイル名を一覧化してルール違反がないか確認する棚卸し作業を仕組み化しておくと、ルールの形骸化を防げる。棚卸しは面倒に感じられがちだが、簡単なスクリプトやマクロでファイル一覧を自動抽出できるようにしておけば、確認作業自体は数分で終わる。

新メンバーへのオンボーディング資料に組み込む

命名規則やフォルダ構成のルールは、新しくチームに加わったメンバー向けのオンボーディング資料に必ず含めておく。着任初日にルールを渡しておけば、我流の命名が定着する前に軌道修正できる。後から直すよりも、最初から正しい形を教える方がコストは圧倒的に低い。

独立してから一人で仕事をするようになった今も、こうした「仕組み化」の発想は変わらず役に立っている。テンプレートファイルを自分用に用意しておくことで、久しぶりに触る案件でも迷わず正しい名前で作業を始められる。棚卸しについても、案件が一段落するたびに軽く見直す習慣をつけておくと、後から慌てて整理する手間が省ける。

命名規則の運用がうまくいっているチームに共通するのは、ルールを「守らせる」のではなく「守りやすくする」工夫をしている点だ。禁止事項を列挙するだけのルールブックは読まれずに終わることが多いが、正しい状態を再現しやすい仕組み(テンプレート・自動チェック・オンボーディング資料への組み込み)を用意しておけば、メンバーは意識せずともルールに沿った成果物を生み出せるようになる。

よくある質問(FAQ)

Q1. 命名規則はどのくらい細かく決めるべきですか？

A. 最初から完璧を目指す必要はない。まずは「種別プレフィックス」「案件名または装置名」「連番またはバージョン」の3要素を決めるところから始めるとよい。

Q2. 個人事業主やフリーランスの設計者でも命名規則は必要ですか？

A. 必要だ。案件が増えるほど「半年前の自分」が「今の自分」にとって他人同然になる。案件名・日付・バージョンを含めた命名を徹底しておくと、過去案件の流用や確定申告時の記録整理がスムーズになる。

Q3. PDMを導入すればファイル命名は適当でよくなりますか？

A. いいえ。PDMはバージョン管理や変更履歴の追跡には強いが、「そのファイルが何を表しているか」を分かりやすくする機能ではない。

Q4. 既存の乱雑なCADデータを整理する優先順位はどう決めればよいですか？

A. 現在進行中のプロジェクトや、今後流用する可能性が高いデータから優先的にリネーム・再構成するのが現実的だ。

Q5. SolidWorks・Inventor・Fusion 360でルールを使い分ける必要がありますか？

A. 基本的な考え方は共通でよいが、使用しているCADのデータ管理機能を理解した上で、ルールに過不足がないか確認するとよい。

まとめ

• 命名規則はプレフィックス・種別・バージョンを含めて「誰が見ても分かる」ものにする
• アセンブリは機能単位のサブアセンブリ構造で設計する
• 標準品・購入品は専用フォルダで一元管理する
• フィーチャー命名を意味のある名称にして引き継ぎコストを下げる
• フォルダ構成テンプレートをチームで統一する

データ管理のルールは、一度整備すれば終わりというものではなく、プロジェクトを重ねるごとに少しずつ見直していくものだ。今回紹介した内容を土台に、自分のチーム・自分の働き方に合った運用ルールへと育てていってほしい。

設計×現場ラボ｜機械設計の実務知識を、現場目線で発信しています。