設計BOM(EBOM)と製造BOM(MBOM)は何が違うのでしょうか?製造業の現場では欠かせない「BOM(部品表)」ですが、その中でもEBOMとMBOMは用途や構成の考え方が大きく異なります。
設計図面から始まる製品開発のプロセスにおいて、EBOMは設計意図の表現、一方でMBOMは製造実行のための構成を担います。つまり、同じ製品でも「誰が使うか」「何のために使うか」によって、BOMの中身や構造は変わってくるのです。
本記事では、EBOMとMBOMの違いを明確に整理しながら、次のような疑問を持つ方に向けて、現場で活かせる知識や運用ノウハウを専門的かつ実践的に解説します。
この記事でわかること
- 設計BOM(EBOM)と製造BOM(MBOM)の定義と違い
- EBOM⇔MBOM変換の流れとチェックポイント
- 属性や粒度、責任分担の構成方法
- 同期パターン(手動・半自動・API連携)の選び方と注意点
- よくある失敗例とその対策方法
BOMに関して全体像を知りたい方はこちらの記事をごかくにんください。
→BOMとは?|定義・種類・作成手順・管理ベストプラクティスまで徹底解説
初心者の方にも理解しやすいように、図解や比較表を交えながら丁寧に解説していますので、
設計・生産技術・製造・情報システムなど、BOMに関わるすべての部門の方にお役立ていただける内容になっています。
読み終わる頃には、EBOMとMBOMの違いだけでなく、どう連携・同期すれば業務がスムーズになるかがわかるはずです。ぜひ最後までご覧いただき、実務にお役立てください。

監修・執筆:UEL株式会社編集部
UEL株式会社のTechデザイン企画部と現場に精通した社内有識者が監修・執筆しています。
本記事は一般的な情報提供を目的としたものであり、特定の企業・環境・状況への適用や効果を保証するものではありません。内容の利用は読者ご自身の判断と責任にてお願いいたします。参考としてご活用ください。
設計BOM(EBOM)と製造BOM(MBOM)の基本
製品のライフサイクル全体において、「BOM(Bill of Materials/部品表)」は情報の起点となる極めて重要な構成データです。その中でも、EBOM(Engineering BOM)とMBOM(Manufacturing BOM)は目的と使われ方が異なる、2つの中核的なBOMです。
以下で、それぞれの定義と役割を明確に整理します。
EBOM(設計BOM)とは?
EBOMは、設計部門がCADやPDM上で作成する「設計意図を反映した部品構成表」です。
製品の機能や性能を実現するために、どの部品をどう組み合わせるかを定義します。設計審査や承認プロセスに使われ、構成の正当性と完全性の担保が目的です。
- 作成主体:設計部門(設計者、CADオペレータ、PDM使用者)
- 利用目的:製品の設計意図の論理的な表現、構成管理と部品管理の効率化
- データ源:3D CAD、PDM/PLM
MBOM(製造BOM)とは?
MBOMは、製造部門や生産技術部門がERPやMES上で使用する「製造実行のための部品構成表」です。製造ラインや工程に適した順序や単位で部品を再構成し、調達・手配・原価計算に直結します。
- 作成主体:製造部門、生産技術、製造管理、調達
- 利用目的:組立指示、手配情報、原価ロールアップ
- データ源:ERP、MES、MRP、EBOM、PBOM
EBOMとMBOMの違い
観点 | EBOM(設計BOM) | MBOM(製造BOM) |
---|---|---|
目的 | 設計意図の表現・機能検証 | 製造実行・手配・原価計算 |
粒度 | 機能単位・部品単位 | 作業単位・着座順序 |
属性 | 図面番号、材料仕様、設計改訂 | 工程用途、代替品、置き場、治工具 |
責任部門 | 設計(PDM/PLM) | 製造/生産技術(ERP/MES) |
更新トリガ | 設計変更(ECR/ECN) | 工程・調達変更、配置変更 |
補足:EBOMに工程情報を混載するとMBOMとBOP(工程表)の区別が曖昧になり、運用破綻のリスクがあります。明確な役割分担が重要です。
関連するBOM用語の整理
- 100% BOM:製品1機種のすべての構成情報を網羅したBOM(MBOMで使われることが多い)
- 120% BOM:設計段階で将来の派生やオプションも含めた「拡張版BOM」。実際に使われるのは一部だが、設計資産を無駄なく活かすための基盤となる
- 150% BOM:選択肢・バリエーションを含んだ構成。受注生産やオプション管理に使われる
- サービスBOM:保守・アフターサービス用のBOM。交換部品や修理手順を反映
- 見積BOM:営業・プリセールス段階で使われる概算用BOM。コスト計算や納期見積に活用
- 環境BOM:製品に含まれる部材や化学物質を管理し、環境規制(RoHSやREACHなど)への適合確認やサステナビリティ評価に活用されるBOM
EBOM⇔MBOM 差分表(保存版)
「設計BOM(EBOM)」と「製造BOM(MBOM)」は、どちらも製品の部品構成を扱いますが、目的・視点・粒度・責任部門・更新トリガなど、あらゆる面で違いがあります。
以下の比較表では、EBOMとMBOMの違いを10の観点で整理し、実務でそのまま使えるレベルで要点をまとめました。
EBOMとMBOMの比較一覧(差分表)
観点 | EBOM(設計BOM) | MBOM(製造BOM) | 注意点・補足 |
---|---|---|---|
目的 | 設計意図の明示/審査用 | 製造実行/手配・原価計算用 | 目的が異なるため、必要な属性も異なる |
視点 | 機能・論理構成 | 組立順・作業指示構成 | 組立順はBOP/ルーティングと連携 |
粒度 | 部品・材料レベル(構成単位) | 作業単位・着座単位(工程単位) | 粒度の設計が不一致だと変換エラーに |
主な属性 | 図面番号、材料、改訂、スペック | 工程用途、代替品、置き場、治工具 | 重複を避け、役割分離を意識する |
責任部門 | 設計/PDM・PLM担当 | 製造/ERP・MES・調達担当 | 業務分界とRACIの明文化が重要 |
データソース | CAD→PDM/PLM | EBOM、PBOMが太字になっているが、太字の必要がないかも | 参照先の管理に一貫性を持たせる |
更新トリガ | 設計変更(ECR/ECN) | 工程変更・材料変更・配置変更 | 適用日の整合と連携がカギ |
連携先システム | CAD、PDM、PLM | ERP、MES、MRP | ゲートレビューやAPI連携設計が必要 |
構成更新の頻度 | 設計フェーズ中心(少数回) | 製造・生産現場で都度更新 | 生産変動や購買変更が多い |
課題になりやすい点 | 工程情報混在、部品粒度過剰 | 品番乱立、Excel地獄、バージョン崩壊 | 共通テンプレ |
表の使い方
- 社内研修資料のテンプレートに転用可能
- PLM・ERP導入時のギャップ分析資料に活用
- 設計と製造のすり合わせミーティングの共通言語として使用
属性・粒度・責任分担をどう設計するか
EBOMとMBOMの違いを理解した上で重要になるのが、「どう分けて、どうつなぐか」という設計思想の構築です。特に、「属性設計」「粒度の定義」「責任分担(RACI)」は、BOM運用の成功可否を分ける中核項目です。
1. 属性設計:持たせる情報の取捨選択と統一ルール
EBOMとMBOMに共通するのは「部品に紐づく属性情報」です。ただし、すべてをMBOMに詰め込むのは失敗パターンの典型です。
属性設計のポイント
- 必須属性/任意属性を分類する
例:図面番号・改訂は必須。ロケーションや工程用途は任意(製造側で持つ) - 意味型 vs 無意味型品番の設計指針
- 意味型(例:ABC-123-SUS)は属人化・破綻しやすい
- 無意味型(例:PN-000123)+属性分離で拡張性と自動化が上がる
- 属性の重複回避ルールを明文化する
→ 例:「材料仕様は設計BOMが持ち、製造BOMには持たせない」
2. 粒度設計:構成の分割と標準化ポリシー
粒度の不一致は、変換エラーや原価ロールアップの不整合を引き起こします。特に、どの単位で構成を分けるかはプロジェクト初期に合意しておくべきです。
粒度設計の視点
- サブアセンブリ分割の基準
- 着座単位(1工程で組み立てられる最小単位)
- 調達単位/在庫単位に一致させる
- 標準部品の再利用ルール
- 同一形状品は共通パーツとして管理(Part Library化)
- ファントム品の活用
- 組立上必要だが在庫しない構成品に使う(例:仮組み品)
3. 責任分担の設計:RACIで曖昧さを排除
BOM管理は設計/製造/IT/調達/品証など複数部門が関与するため、責任の境界が曖昧になると更新が止まります。
そこで有効なのがRACI(責任マトリクス)の導入です。
RACIとは:役割分担の明確化手法
- R = Responsible(実行責任):実際に作業を行う人
- A = Accountable(最終責任):結果に責任を持ち、承認権限を持つ人
- C = Consulted(相談先):助言やレビューを行う人
- I = Informed(情報共有):進捗や結果を通知すべき人
RACI設計例(設計変更の流れ)
タスク | 設計部門 | 製造部門 | 情シス | 品質保証 |
---|---|---|---|---|
設計変更の起案 | ✅Responsible(実行責任) | — | ✅Accountable(最終責任) | ✅Consulted(相談先) |
変更内容の確認 | ✅Accountable(最終責任) | ✅Consulted(相談先) | ✅Consulted(相談先) | ✅Consulted(相談先) |
BOMの差分更新 | ✅Responsible(実行責任) | ✅Informed(情報共有) | ✅Informed(情報共有) | – |
改訂登録/適用日設定 | ✅Accountable(最終責任) | ✅Informed(情報共有) | ✅Responsible(実行責任) | ✅Informed(情報共有) |
ポイント
RACIを使うことで「実務を担う人」と「承認責任を持つ人」を明確化でき、部門間の誤解や責任のなすりつけを防止できる。
責任の主語を曖昧にせず、全工程で「誰がやるか」を明示する。
EBOMとMBOMの役割分離を前提に、構成・属性・責任を整理する。
EBOM→MBOM変換の実務フロー
EBOMとMBOMは目的も構成の視点も異なるため、単純なコピーやインポートでは変換できません。
「設計意図」から「製造実行」へと情報を正しく橋渡しするには、段階的で論理的な変換プロセスが必要です。
ここでは、EBOMからMBOMへ変換する際に実務で採用される4つの主要ステップを紹介します。
加えて、変換時の抜け漏れを防ぐ「チェックリスト抜粋」もあわせて掲載します。
ステップ1:CAD属性マッピング
設計BOMの基になるのは、多くの場合3D CADの構成データです。
まずは、CAD→PDM→PLMに含まれる属性情報を、MBOM側のERPやMESに転送・変換できるように整えます。
主な対象属性:
- 図面番号、材料仕様、改訂番号
- 部品コード(品番)、部品名
- 数量、単位、サブアセンブリ構成
ポイント:PDMの出力仕様を確認し、MBOM側で受け取れるデータ形式(Excel/CSV/API)に落とし込む。
ステップ2:構成の粒度調整
設計BOMでは機能構成で組まれた部品も、製造BOMでは作業単位に分割する必要があります。
対応すべき観点
- 着座ルールの反映(1工程で処理可能な単位)
- 共通部品の再利用化(標準品を再定義)
- 代替品ルールの付与(部品Aが不足時にBを使用可能とする)
設計段階の粒度が荒すぎると、MBOMでの組立・購買指示が不完全になります。
ステップ3:工程・用途の紐付け(BOP/ルーティング)
製造現場では、「どこで」「どの順番で」部品を組み立てるかが極めて重要です。
そのため、MBOMにはBOP(Bill of Process)やルーティング情報と連携する形で用途・工程コードを持たせる必要があります。
紐付けポイント
- 工程用途コード(例:圧入/溶接/検査)
- 使用位置/着座順
- 工程治工具・治具情報の参照
実務Tips:工程情報はBOPに寄せ、MBOMでは参照コードのみ持たせる設計が望ましい。
ステップ4:差分同期と改訂管理
EBOMとMBOMは、変更頻度・タイミングが異なります。よって同期タイミングと差分抽出ルールを明示化しておく必要があります。
管理すべき要素
- 設計変更(ECR)と製造変更(ECN)の分離
- 適用日(適用開始日)の設定と共有
- バージョン/版管理(構成番号の世代追跡)
改訂≠適用日:設計上の改訂(Rev)はEBOM、製造での適用日はMBOM側で持つ必要があります。
変換チェックリスト
チェック項目 | 完了目安 | 備考 |
---|---|---|
CAD属性がMBOMにマッピングされているか | ✅ | 図面番号・材質など |
粒度レベルの再設計が完了しているか | ✅ | 着座・標準化対応済 |
工程用途コードが設定されているか | ✅ | BOPとの紐付け |
改訂と適用日の分離定義があるか | ✅ | トリガ整合性 |
差分抽出ロジックが運用できているか | △ | 手動かAPIか明記 |
同期パターンの選び方
EBOMとMBOMの変換・同期においては、「どのように情報を連携・管理するか」が非常に重要です。特に、システム間の連携方式は、企業規模・製品種別・運用体制によって最適解が異なります。
このセクションでは、現場でよく使われる3つの同期方式(手動/半自動/完全連携)の特徴とメリット・デメリットを比較形式で解説します。
1. 手動同期(Excel/CSVベース)
概要:
PLMやPDMシステムから出力したEBOMデータをExcelやCSVでエクスポートし、ERPやMESへ手作業で転記・整形する方式。
適用シーン:
- 小規模な開発現場/試作品管理/BOM数が少ない環境
- 導入初期のPoC・テスト運用段階
メリット:
- 導入が即可能(初期コストほぼゼロ)
- 柔軟でケースバイケースの対応が可能
デメリット・リスク:
- ヒューマンエラーが頻発(コピペ、入力ミス、未反映)
- 差分追跡・改訂管理が困難
- Excel版がローカルに乱立し、バージョン崩壊が起きやすい
2. 半自動同期(エクスポート→インポート+検証)
概要:
PLMから出力されたBOMファイルを定型フォーマットで変換し、ERP側でスクリプトまたはETLツールを用いて取り込む方式。中間で人による差分検証・承認が入る。
適用シーン:
- 中規模製造業/定型ルールが多い業種
- 運用ルールを整備中の移行フェーズ
メリット:
- 自動化に近づきつつ、柔軟性を保持
- 差分検知・レビュー・承認のゲート設計が可能
- 適用日・改訂の整合がとりやすい
デメリット・リスク:
- スクリプトの保守負荷/担当者依存
- 差分検知の精度によっては漏れが出る
- 中途半端な自動化で属人化の温床になることも
3. 完全連携(PLM⇔ERP/MESをAPI接続)
概要:
PLMとERP(あるいはMES)をAPIまたはEAI(Enterprise Application Integration)で双方向連携し、属性のマッピング・改訂管理・承認ワークフローを自動化する方式。
適用シーン:
- 多品種・多拠点を抱える大規模製造業
- 変更頻度が高く、同期精度がビジネス影響を持つ環境
メリット:
- 即時同期・自動検証・変更履歴の完全トレースが可能
- ロールバックや承認フローによるガバナンス強化
- 責任分界(RACI)と連携ログで監査対応も可能
デメリット・リスク:
- 初期構築コストと期間が大きい(要要件定義・テスト)
- すべてを自動化しすぎると設計変更の確認が甘くなる可能性
- システムトラブル時の影響範囲が広い
同期方式の比較一覧
観点 | 手動 | 半自動 | 完全連携 |
---|---|---|---|
初期導入の手軽さ | ◎ | ○ | △ |
運用の安定性 | △ | ○ | ◎ |
ヒューマンエラーリスク | 高 | 中 | 低 |
コストと期間 | 最小 | 中程度 | 高 |
改訂履歴・トレーサビリティ | ほぼなし | 一部あり | 完全ログあり |
おすすめ対象 | 小規模/短期試行 | 中規模/移行期間中 | 大規模/多拠点運用 |
どの方式を選ぶべきか?
最初から完全連携を目指すのではなく、現状のBOM成熟度やリソースに応じて段階的に進化させることが推奨されます。
補足:特に、「設計変更の頻度」×「拠点数」×「部品数」の掛け合わせで方式を選ぶと、運用の無理・ムダを抑えやすくなります。
よくある失敗と対策
BOM運用において、「設計から製造へ情報が流れたはずが、現場ではまったく反映されていなかった」――
そんなBOMの形骸化を引き起こす要因は、多くが設計思想・責任境界・ツール運用の不整合によるものです。
このセクションでは、実際の現場で多く見られる代表的な失敗例とその対策をセットで紹介します。
失敗①:MBOMに設計情報を全部持たせて混乱
❌ よくあるケース:
設計BOMのすべての属性(図面番号、材料仕様、改訂履歴など)をMBOM側に持たせた結果、製造部門がどれを使って良いか判断できなくなり、運用が崩壊。
✅ 対策:
- 属性の責任分界を明確にする(設計→EBOM、製造→MBOM)
- 「参照のみ可」の属性を定義し、読み取り専用に設定
- MBOMには製造用途に必要な情報のみに絞る(用途コード・置き場・代替品など)
失敗②:失敗②:工程情報をMBOMに混載して破綻
❌ よくあるケース:
組立工程や作業手順の詳細までMBOMに入れてしまい、変更時にBOP(Bill of Process)と二重管理となり矛盾が発生。
✅ 対策:
- 工程情報はBOP/ルーティングへ完全に分離
- MBOMには用途コードや参照IDのみを持たせる
- 工程変更はBOP側の管理フローに一本化
失敗③:代替品・共通部品のルールが曖昧
❌ よくあるケース:
設計段階で代替部品の定義が曖昧なままMBOMに反映され、現場で手配混乱や原価計算ミスが頻発。
✅ 対策:
- 代替品に有効日・優先度・互換性を明示した属性を持たせる
- 共通部品は再利用候補品として設計段階で明示
- 調達と在庫の部門とルールをすり合わせる
失敗④:品番・改訂・適用日が未統一
❌ よくあるケース:
品番が意味型/無意味型で混在し、改訂履歴と適用日の整合が取れず、製造現場とシステムが乖離。
✅ 対策:
- 品番は無意味型(シリアル型)+属性で意味づけする
- 改訂と適用日を分けて定義:「改訂=設計の都合」「適用日=製造現場の都合」
- 適用開始日をERP/MES側で必須化し、出図時点とは別管理
失敗⑤:Excel地獄でバージョン管理が崩壊
❌ よくあるケース:
複数部門が独自にExcelでBOMを管理。マスタデータの一貫性が失われ、「最新版」が誰にもわからない状態に。
✅ 対策:
- 単一マスタでのBOM管理を徹底(PDM/ERPに統合)
- 承認フロー付きの更新プロセスを設計
- Excel利用はテンプレート入力→読み込みのみに制限し、ローカル保存を禁止
まとめ表:失敗と対策一覧
失敗パターン | 主な原因 | 有効な対策 |
---|---|---|
MBOMに設計属性を全部入れる | 責任分界の不在 | 属性の役割分離・参照属性の明確化 |
工程情報をBOMと混在 | 情報粒度の混乱 | BOPとの完全分離・用途コード化 |
代替品ルール未定義 | 設計段階の定義不足 | 有効日/優先度/互換性の属性追加 |
改訂と適用日混在 | 定義不整合 | 改訂=設計、適用日=製造の分離 |
Excel地獄 | マスタ不統一/属人化 | 単一マスタ+承認付きプロセス運用 |
「BOMは設計だけで完結しない。運用まで含めて設計するもの」という視点が、失敗を避けるための第一歩です。
FAQ
Q1. 設計BOM(EBOM)と製造BOM(MBOM)の最大の違いは?
EBOMは設計意図を表現する構成であり、MBOMは製造実行のための構成です。
持つ情報の粒度・属性・責任部門・更新のタイミングが大きく異なります。
Q2. EBOMからMBOMへ変換する最短手順は?
- CADから属性をマッピング(図面番号・材料・改訂など)
- 粒度調整(着座単位・共通部品の再定義)
- 工程用途の紐付け(BOP連携)
- 適用日やECR/ECNに基づく差分同期
という4ステップが基本です。
Q3. 150% BOMと100% BOMの関係は?
150% BOMは、すべてのバリエーションや選択肢を含む「選択肢付きのBOM」です。
一方、100% BOMは、実際の製品1機種を対象とした、絞り込み済みの「確定構成のBOM」です。
150% BOMからオプションや仕様を確定すると、その製品固有の100% BOMが得られます。
つまり、150% BOM(選択肢を含む設計資産) → フィルタリング → 100% BOM(確定設計) という関係になります。
Q4. BOP/ルーティングとMBOMはどう分担すべき?
MBOMは「部品構成(何を使うか)」、BOP/ルーティングは「工程順序(どう作るか)」を管理します。工程情報はBOPに集中させ、MBOMは用途コード等で参照するだけにとどめるのが原則です。
Q5. Excel運用をやめるべきタイミングは?
- BOMの構成が階層化・多品種化し始めたとき
- 属人管理でどれが最新版か分からない状態が生じたとき
- 改訂履歴・適用日・差分比較が求められるようになったとき
これらに該当すれば、PLM/ERP等へのシステム移行を検討すべきタイミングです。
まとめ
本記事では、設計BOM(EBOM)と製造BOM(MBOM)の違いを起点に、差分表・設計ポイント・変換フロー・同期方式・失敗と対策までを体系的に解説してきました。
要点まとめ
- EBOMは設計意図、MBOMは製造実行——目的と構成粒度が根本的に異なる
- 変換には4ステップと責任分界の設計が必須——粒度・属性・用途・改訂の調整
- 運用を成功させるカギは同期方式の選定とルール化——現場とシステムをつなぐ設計が必要