BOM（部品表：Bill of Material）は、単なる部品リストや「表」ではありません。製品が「何で・どのような構造でできているか」という構成そのものを定義し、設計・調達・製造・原価・保守まで、製品の一生を通じて参照され続ける基準情報の中核です。結論から述べます。BOMを一元管理し、部門を越えて構成を理解できる状態を作らない限り、生産管理の精度向上も、製造業DXも、そして昨今注目されるAI活用も成立しません。本稿では、E-BOMとM-BOMの不整合、設計変更管理の遅れといった現場の典型課題を構造的に整理し、「数値化・みえる化・言語化」「AI活用」「マネージメント」の3つのアプローチによる解決の道筋を、生産管理・設計の実務者の視点で解説します。

■ この記事でわかること
・BOMが「表」ではなく「製品構成の理解を共有する情報構造」である理由と、品目マスター・工順マスターとの関係
・一元管理を阻む要因（E-BOM/M-BOM不整合・設計変更管理の遅れ等）、BOM課題の3類型とその経営影響
・「数値化・みえる化・言語化」を起点に、BOMの一元管理と生成AI活用へつなげる実務手順
・BOM整備を継続的に回すためのマネージメント体制と人材育成（業務プロセス研修）の要点

1. BOMとは何か ― 製造業の全活動を支える基準情報の中核

1-1. BOM（部品表）の定義

BOMとは、製品を構成する品目の親子関係（親品目・子品目）と員数、有効日／失効日、不良率（歩留・スクラップ率）などを定義した「製品構成情報」です。部品表のほか、B/M、P/S（Product Structure）とも呼ばれます。ここで強調したいのは、英語名がProduct Structure、すなわち「製品の構造」である点です。BOMの本質は、部品名と数量を並べた一覧表ではなく、「どの部品が、どの単位にまとまり、どの順序で製品を形づくるか」という構成そのものを表現する情報構造にあります。ポイントは、BOMが図面の付属物ではなく、企業活動全体が参照し一元管理されるべき独立したマスター情報だということです。
製造業で扱う情報は、大きく3つに分類できます。第一に、販売予測や生産計画といった「計画情報」。第二に、受注・発注・入出庫・検査結果などの「伝票型情報とその集計情報」。そして第三が、製品・部品・工程・組織・取引先などを定義する「マスター型情報」、すなわち基準情報です。基準情報は全活動のベースとなる静的（恒常的）な情報であり、計画も実績も、この基準情報の上に成り立っています。

1-2. 品目マスター・工順マスターとの関係

製造業固有の基準情報は、「製品の定義に関する情報」と「製造の方法の定義に関する情報」に分かれます。前者が品目マスター（Item Number、名称、図面番号、仕様、入手情報、警告情報など品目個々の属性）とBOM（品目間の構成関係）であり、後者が工順マスター（製造工程情報、資源・設備情報）です。つまりBOMは、「何を」（品目マスター）と「どう作るか」（工順マスター）をつなぐ結節点に位置します。MRP（資材所要量計画）、製造指示、原価積上計算、コンフィギュレーターによる提案営業まで、いずれもBOMを参照して動きます。BOMの品質がそのまま業務システム全体の品質を決める、と言っても過言ではありません。

1-3. BOMの一生 ― 設計部門だけのものではない

BOMは、商品企画・設計段階の新規登録に始まり、シリーズ展開時の応用設計（前モデルBOMのコピーと変更）、設計変更、作業手順・調達方法の設定、生産条件・受入条件の登録、そして販売開始・終了まで、製品ライフサイクル全体で更新・参照され続けます。特に見落とされがちなのは最後の局面です。新製品の発売時期や生産打ち切りにおける営業部門と製造部門の同期化も、実はBOMを介した情報伝達によって行われます。BOMは設計部門の成果物であると同時に、生産技術・資材・製造・販売・経理までを貫く「全社の共有言語」であり、だからこそ一元管理が前提条件になるのです。

図1　製造業における基準情報の体系（BOMの位置づけ）

2. なぜ今、BOMが経営課題なのか

結論として、BOM課題が「今」深刻化しているのは、多品種化・サプライチェーン変動・熟練人材の減少という環境変化に、従来の属人的・分散的なBOM運用が耐えられなくなっているためです。言い換えれば、一元管理されていないBOMと、構成を理解しないまま「表」として扱う運用が、限界を迎えたということです。以下、実務で頻発する3つの症状から見ていきます。

2-1. 属人化 ―「担当者の頭の中」にしかない構成情報

品目番号の採番ルール、類似品の使い分け、階層化の意図、代替部品の可否。こうした判断基準が文書化されず、特定のベテラン担当者の経験知に依存している現場は少なくありません。担当者が在籍している間は問題が表面化しませんが、異動・退職を機に、誰も正しい構成を説明できない「ブラックボックスBOM」が残ります。品目番号ひとつ取っても、「同じものは同じ番号で、違うものは違う番号で」という大原則が、事業部ごとの採番ルールの乱立によって崩れている企業は多いのが実情です。結果として、同一部品の重複登録による在庫の二重持ち、類似品検索の失敗による新規部品の乱発が起こります。

2-2. E-BOMとM-BOMの不整合 ― 設計と製造の分断

設計部品表（E-BOM：Engineering BOM）は設計部門が機能・品質を基本に作成し、PLM/PDMで管理されます。一方、生産部品表（M-BOM：Manufacturing BOM）は生産技術部門が加工方法・手順・経済性を基本に作成し、ERPで管理されます。両者は目的が異なるため、構造が一致しないこと自体は正常です。例えば「部品CとDを組み立てた後でないとBが取り付けられない」という工程上の制約から中間アセンブリXを設ける、設計上は内製想定だった部品を購入品に切り替える、といった変換は日常的に発生します。
問題は、このE-BOMからM-BOMへの変換・連携が手作業やExcel転記に依存している場合です。転記ミス、反映漏れ、タイムラグが慢性化し、「設計は変わったのに現場の部品表は古いまま」という状態が生まれます。誤部品の払い出し、誤発注、原価計算の狂いは、多くの場合ここに根を持ちます。

2-3. 設計変更管理の遅れが品質・原価・納期に波及する

設計変更は、不具合対策、作りやすさ改善、コストダウン、機能改良、過剰品質の適正化など、様々な理由で発生します。重要なのは、一つひとつの変更に設計変更番号（EC番号）を付与し、発行日と適用日を管理することです。変更は即時適用とは限らず、将来適用分も含まれるため、順序と適用時期の管理が崩れると、間違った部品の使用や機能不全に直結します。さらにグローバル生産では、PCN（Process Change Notice：工程変更指示書）の承認・配布プロセスが遅延すれば、その間、海外量産工場は旧仕様で作り続けることになります。設計変更管理は、品質・原価・納期のすべてに波及する、BOM運用の生命線です。

図2　E-BOM/M-BOM連携における課題の構造

3. BOM課題の3類型 ― 課題を構造化して捉える

前章の症状は、突き詰めると「①情報の分断」「②変更管理の脆弱性」「③暗黙知依存」の3類型に整理できます。対策を検討する際は、自社の課題がどの類型に属するかをまず特定することが、遠回りに見えて最短の道です。

3-1. ①情報の分断（サイロ化）

部門別・システム別にBOMが分散し、一元管理が崩れて「正」が一意に定まらない状態です。品目番号の不統一、PLM・ERP・Excelの三重管理、拠点ごとの独自BOMなどが典型です。一元管理されていないBOMは、部門ごとに切り取られた「表」の集合体に退化し、製品全体の構成を誰も俯瞰できなくなります。その結果、逆展開（子部品から親製品をたどる検索）による影響範囲調査が機能せず、部品の調達難や品質問題が起きた際に、どの製品に影響するかを即答できません。

3-2. ②変更管理の脆弱性

EC番号・適用日の管理不備、承認ワークフローの形骸化、E-BOM変更のM-BOMへの反映漏れなどです。変更の伝達方法には、変更分のみ伝達する方式、毎回全構成を置き換える方式、両者の併用がありますが、方式の選択以前に「誰が・いつ・何を承認し・いつから適用するか」のプロセスが崩れていれば、どの方式でも不整合は発生します。

3-3. ③暗黙知依存

採番・階層化・代替可否・ファントム（手配用の仮想階層）の使用基準など、BOMを正しく作り維持するための判断基準が言語化されていない状態です。①②の背後には、ほぼ例外なくこの③が潜んでいます。ルールが言語化されていないから、システムを入れても運用が属人化し、変更管理も担当者の力量次第になる。逆に言えば、③に手を打たない限り、①②への対策は対症療法に終わります。

表１　 BOM 課題の3類型と経営への影響

課題類型	典型的な症状	経営への影響
①情報の分断	品目番号の不統一／PLM・ERP・Excelの多重管理／拠点別の独自BOM	在庫の二重持ち、影響範囲調査の不能、DX・AI活用の前提データ欠如
②変更管理の脆弱性	EC適用日管理の不備／承認ワークフローの形骸化／E-BOM変更の反映漏れ	誤部品使用・誤発注による品質問題と手戻り、原価計算の信頼性低下
③暗黙知依存	採番・階層化・代替可否の判断基準が未文書化／特定担当者への依存	技能承継の断絶、教育コスト増大、①②の再発（対策の対症療法化）

 

4. 解決アプローチ① 数値化・みえる化・言語化 ― 暗黙知を全社の共有言語に変える

筆者は、業務改善のコンセプトとして「数値化・みえる化・言語化」の3ステップを提唱しています。BOM整備においても、この順序で進めることが効果的です。結論を先に言えば、最終ゴールは「言語化」、すなわちBOMにまつわる暗黙知を、誰もが参照・検証できる形式知に変換することです。数値化とみえる化は、そのための現状把握と合意形成の手段と位置づけます。

4-1. 数値化 ― まず現状を測る

感覚論で「うちのBOMは汚い」と言っても、対策の優先順位は決まりません。最初に、現状を数値で押さえます。例えば、品目マスターの重複登録率（類似品検索によるサンプリング調査）、E-BOMとM-BOMの不整合件数（レベル別確認・集約展開確認による突合）、設計変更の発行から現場適用までのリードタイム、Excel等システム外で管理されているBOMの比率、といった指標です。これらの数値は改善活動のベースラインとなり、後述するAI活用の効果検証にもそのまま使えます。なお、どの指標を採用すべきかは各社の業務形態に依存するため、自社の管理目的に照らして取捨選択してください。

4-2. みえる化 ― 構造と影響範囲を可視化する

次に、測った現状と、BOMの構造そのものを見える形にします。ここでの要点は、BOMを「上から順に読む表」として扱うのをやめ、「構成を理解するための道具」として使い倒すことです。同じデータでも、見せ方を変えれば読み取れる情報がまったく変わります。有効な手法の一つが「派生BOM（バリアントBOM）」です。横軸に機種、縦軸に構成品目を取ったマトリックス表示により、類似製品間の共通点と相違点が一目でわかり、標準化・共通化のポイント絞り込みや、新規登録BOMの抜け漏れチェックに使えます。また、正展開（親から子へたどる）・逆展開（子から親へさかのぼる）・集約展開（最下層まで展開して所要を集約する）といったBOM検索機能を目的別に使い分ければ、同じBOMから「組立の順序構造」「共通部品の波及範囲」「購入部材の総所要」という異なる断面を読み取れます。特に逆展開は、ある部品の調達難や不具合がどの製品の生産に影響するかを即座に可視化する、一元管理されたBOMならではの使い方です。「部品表を見る」のではなく「構成を問う」――この転換が、みえる化の核心です。変更管理についても、承認ワークフローの進捗（起票・承認中・適用中・適用完了）を一覧化し、停滞案件を監視する仕組みが有効です。

4-3. 言語化 ― 判断基準を文書として残す

仕上げが言語化です。具体的には、品目番号の採番ルール（全社統一の発番の仕組み）、BOM階層化の目的別基準（予測・先行手配、余剰品引当、物流簡素化、販売・サービス、共通品識別など、何のための階層かを明記する）、ファントムの使用基準、E-BOMからM-BOMへの変換ルール（中間アセンブリの設定基準、購入品化の判断基準）、設計変更の適用日決定ルール、さらに「どのシステムを正とし、どの情報をどこで一元管理するか」というマスター配置の原則、といった項目を文書化します。重要なのは、「何をするか」だけでなく「なぜそうするか」まで書き残すことです。理由が言語化されて初めて、担当者が代わってもルールが形骸化せず、次章で述べるAIにも判断基準として与えられるようになります。

図3　数値化・みえる化・言語化の3ステップとAI活用への接続

5. 解決アプローチ② AI活用 ― 生成AI時代のBOM整備

結論から言えば、生成AIはBOM整備の強力な支援ツールになり得ますが、それは「言語化されたBOM運用ルール」と「一定品質のデータ」が存在する場合に限られます。AIは魔法ではなく、基準情報の品質をテコにして初めて働く増幅装置です。

5-1. AIが得意な領域

BOM業務でAI活用が期待できる代表的な領域は次のとおりです。第一に、類似品目の検出と名寄せです。品名の表記ゆれ（全角半角、カタカナ表記差、略称）を吸収して重複候補を抽出する作業は、従来は目視に頼らざるを得ませんでしたが、言語処理を得意とするAIの適性が高い領域です。第二に、BOM登録時の抜け漏れチェックです。派生BOMによる類似機種比較の考え方をAIに実行させ、「類似機種には存在するのに新機種のBOMにない品目」を候補として提示させる使い方です。第三に、設計変更の影響範囲要約です。逆展開の結果と過去の変更履歴を組み合わせ、影響製品・関連部門・確認すべき観点を要約させます。第四に、過去の変更理由・トラブル事例の検索です。PCNや技術文書を検索対象とし、自然文の質問で過去知見を引き出す活用（いわゆるRAG構成）が考えられます。これらはいずれも「最終判断は人が行い、AIは候補提示と下調べを担う」という役割分担が前提です。

5-2. AI活用の前提条件 ― 言語化なくしてAIなし

前章の言語化がAI活用の前提になる理由は明快です。AIに類似品目の判定をさせるには「何をもって同一・類似とみなすか」の基準が、抜け漏れチェックをさせるには「どの機種を比較対象とするか」のルールが、それぞれ言語として与えられていなければなりません。判断基準が担当者の頭の中にしかない状態でAIを導入しても、AIの出力を検証する物差しがないため、結局は使われなくなります。「まず言語化、その上でAI」という順序を崩さないことが、遠回りに見えて確実な道です。

5-3. 注意点 ― 基準情報ゆえのガバナンス

留意点も明確にしておきます。第一に、検証責任は常に人間側にあります。BOMは全社が参照する基準情報であるため、誤った登録の影響は伝票データの誤りよりはるかに広範囲に及びます。AIの提案は必ず承認ワークフローを通し、既存の変更管理プロセスの内側で運用してください。第二に、機密管理です。BOMは製品構成という機密性の高い技術情報そのものであり、外部AIサービスを利用する場合は、データの取扱条件（学習利用の有無、保存場所）の確認が不可欠です。第三に、効果の定量評価です。AI導入効果は各社のデータ品質・業務量に大きく依存するため、一般論の数値を鵜呑みにせず、4-1で設定した自社KPI（不整合件数、変更リードタイム等）のビフォーアフターで検証することを推奨します。

6. 解決アプローチ③ マネージメント ― BOM整備を「業務改革」として推進する

最後のピースはマネージメントです。BOM整備プロジェクトの失敗パターンの多くは、これを「ITシステム導入」と捉えたことに起因します。結論として、BOM整備は部門横断の業務改革であり、経営層の関与と推進体制の設計、そして人材育成までを含めて初めて定着します。

6-1. 推進体制 ― オーナー不在のBOMは必ず劣化する

BOMは設計・生産技術・製造・資材・経理のすべてが参照する一方、「全社のBOM品質に責任を持つ人」が不在になりがちです。まず、経営層がBOM整備を経営課題として宣言し、基準情報を一元管理するオーナー（責任部門・責任者）を明確にすることが出発点です。ここでいう一元管理とは、すべてを一つのシステムに押し込むことではなく、「どの情報の正がどこにあるか」を一意に決め、他はそこから同期させる、という原則の徹底を指します。その上で、設計変更の承認プロセスを実効化します。並列承認者（品質管理・故障解析・生産技術等）による承認マトリックスや、テクニカル・レビュー・ミーティング（TRB）といった仕組みは多くの企業に存在しますが、判断基準が言語化されていないと形式的な回覧に堕します。「何を確認して承認するのか」のチェック観点を文書化し、承認の中身を伴わせることが肝要です。

表2　BOM整備の推進体制と役割分担（例）

役割	主担当	主な債務
経営層	経営会議	BOM整備の経営課題としての宣言、投資判断、進捗レビュー
基準情報オーナー	基準情報管理部門 （新設含む）	採番・階層化等ルールの制定と維持、基準情報の一元管理、全社BOM品質KPIの管理
設計部門	設計・開発	E-BOMの品質確保、設計変更の起票と技術的妥当性の担保
生産技術部門	生産技術	M-BOMへの変換ルール運用、工順マスターとの整合確保
製造・資材部門	製造・購買	現場適用の完了確認、現物と情報の一致（情物一致）の維持
IT部門	情報システム	PLM-ERP連携基盤の整備、AI活用環境とデータガバナンスの構築

 

6-2. フロントローディング ― 上流で品質を作り込む

設計変更の多発は、それ自体が上流工程の検討不足のシグナルでもあります。設計の早い段階で生産技術・調達・製造を巻き込み、作りやすさ・調達性・工程制約を織り込むフロントローディングを徹底すれば、下流での変更件数そのものを減らせます。E-BOM作成時点でM-BOMへの変換を意識した構成を検討することも、その一環です。変更管理の仕組み強化（守り）と、変更を減らす上流改革（攻め）は、車の両輪と捉えてください。

6-3. 人材育成 ― 業務プロセス全体を体系的に学ぶ

そして、体制とルールを動かすのは人です。BOMを軸とした業務は、基準情報の概念、MRP、製造指示、原価計算、設計変更管理、E-BOM/M-BOM連携と広範に及び、断片的なOJTだけで全体像を掴むのは困難です。部門間の「共通言語」を作るには、業務プロセス全体を体系的に学ぶ研修が有効です。ワクコンサルティングでは、製造業業務プロセス研修の一環として「実践 基準情報管理/BOM」を提供しており、BOMの概念から、MRP・原価計算での活用、設計変更管理、工程管理システムとの連携まで、演習を交えて実務目線で習得いただけます。自社の中堅実務者に体系的な土台を持たせたい場合、こうした研修の活用をご検討ください。

7. まとめ ― BOM整備は、DXとAI時代の「最初の一手」である

本稿の要点を改めて整理します。BOMは単なる表ではなく製品の構成を表現する情報構造であり、製品の一生を貫く基準情報の中核です。それを一元管理し、部門を越えて構成を理解できる状態にすることが、生産管理・原価管理・DX・AI活用のすべての土台になります。現場の課題は「情報の分断」「変更管理の脆弱性」「暗黙知依存」の3類型に整理でき、その根には判断基準の未言語化があります。したがって解決の道筋は、数値化で現状を測り、みえる化で構造と影響を可視化し、言語化で判断基準を形式知に変えること。その言語化された基盤の上でこそ、生成AIは類似品目検出・抜け漏れチェック・影響範囲要約といった実務価値を発揮します。そして全体を動かすのは、経営の宣言、オーナーの設置、承認プロセスの実効化、フロントローディング、人材育成というマネージメントです。BOM整備は地味な取り組みに見えますが、DXとAI活用の成否を分ける「最初の一手」です。まずは自社のBOMの現状を、一つの数値からでも測ることから始めてみてください。

よくある質問（FAQ）

Q1. E-BOMとM-BOMの違いは何ですか？

A1. E-BOM（設計部品表）は設計部門が機能・品質を基本に作成する部品表で、主にPLM/PDMで管理されます。M-BOM（生産部品表）は生産技術部門が加工方法・手順・経済性を基本に作成する部品表で、主にERPで管理されます。工程上の制約による中間アセンブリの追加や購入品化などにより、両者の構造は一致しないのが通常であり、重要なのは両者の変換ルールと整合性管理の仕組みです。

Q2. BOM整備は何から始めればよいですか？

A2. 現状の数値化から始めることを推奨します。品目マスターの重複登録率、E-BOMとM-BOMの不整合件数、設計変更の適用リードタイムなどを測定し、課題が3類型（情報の分断・変更管理の脆弱性・暗黙知依存）のどこに集中しているかを特定した上で、優先順位を付けて着手します。

Q3. AIでBOMを自動生成できますか？

A3. 現時点では、AIによる完全自動生成に品質を委ねることは推奨しません。類似品目の検出、登録時の抜け漏れチェック、変更影響範囲の要約など、候補提示と下調べをAIが担い、最終判断と承認は人とワークフローが担う役割分担が現実的です。また、AI活用の前提として、判断基準の言語化とデータ品質の確保が必要です。

Q4. BOM整備の効果はどのように測ればよいですか？

A4. 着手前に設定したKPIのビフォーアフターで測ります。例えば、不整合件数、誤発注・誤部品使用の発生件数、設計変更リードタイム、新機種BOM登録の工数などです。効果の絶対値は各社の環境に依存するため、他社事例の数値ではなく自社ベースラインとの比較で評価してください。

Q5. BOMは部品リストと何が違うのですか？

A5. 部品リストは「何がいくつ必要か」を並べた一覧ですが、BOMは「どの部品がどの単位にまとまり、どう組み上がるか」という階層構造（Product Structure）を表現します。この構造情報があるからこそ、逆展開による影響範囲調査、階層別の原価積上、モジュール単位の需要予測が可能になります。表として読むだけでは、BOMの価値の大半を使っていないことになります。