部分最適のDXを終わらせる。中小工場のデータ基盤は「共通キー」から始める

外観検査AIを導入した。

需要予測を始めた。

設備の電力を見える化した。

生成AIも使い始めた。

それぞれの取組では効果が出ている。それでも、工場全体を見ると、

「データがつながっていない」

という問題に戻ってくることがあります。

たとえば、外観検査AIが不良を見つけても、その製品がどの材料ロットから作られ、どの設備で処理されたのかをすぐに確認できない。

需要予測で来月の数量が分かっても、工程能力や材料情報とつながっていないため、生産計画に落とせない。

顧客から製品ごとのCO2排出量を求められても、どの製品を作るために、どの設備がどれだけ電力を使ったのか分からない。

個々のDXは進んでいるのに、次の改善につながらない。

その原因の一つが、データが工程や部門ごとに分断されていることです。

IPAの「DX動向2025」でも、日本企業のDXについて、業務効率化を中心とした「内向き」、個別業務の改善にとどまる「部分最適」の傾向が指摘されています。

工場で言い換えれば、次に必要になるのは、

ただし、「データ基盤」と聞いて、大規模なデータベースや高価なシステムを想像する必要はありません。

中小工場のデータ基盤は、次のようなところから始まります。

• 同じ製品を同じコードで呼ぶ
• どのロットか分かる
• どの設備を使ったか分かる
• いつ作ったか分かる
• 誰がそのデータを更新するか決まっている

なぜ現場DXは「部分最適」で止まるのか

データがつながらないのは、現場の運用に原因があることが多いです。

原因	現場で起こること
部門ごとにシステムを導入する	営業、生産、品質、設備がそれぞれ別のデータを持つ
呼び方が違う	同じ製品でも営業と製造で名称やコードが違う
紙・Excel・システムが混在する	どれが正式なデータか分からない
時刻や日付の基準が違う	生産実績と設備データを時間で結合できない
更新責任者が曖昧	マスタが古くなり、信用されなくなる

新しいシステムを導入しても、品目コードやロット番号の考え方が部門ごとに違えば、つながらないシステムが一つ増えるだけです。

逆に、最低限の共通ルールが決まっていれば、Excel、CSV、既存の生産管理システムを使いながらでも、段階的にデータをつなぐことはできます。

まず、何のデータをつなぐのか

工場で扱うデータは、大きく分けると次のようになります。

領域	主なデータ	つなぐと分かること
受注	顧客、品目、数量、納期	どの注文が遅れそうか
品目・BOM	品目、部品構成、材料	何を使って製品を作るか
工程	工程順序、標準時間、使用設備	どこで、どう作る予定か
製造実績	開始・終了時刻、数量、設備、作業者	実際にどう作ったか
品質	検査結果、不良内容、判定	どのロット・工程で問題が起きたか
エネルギー	設備別電力、燃料、流量	どの設備でエネルギーを使ったか

重要なのは、最初から全部を一つのシステムへ集めることではありません。

必要なときに、別々のデータを結び付けられることです。

そのために共通する識別情報を決めます。

データをつなぐ4つの「共通キー」

実務では、次の4つをそろえると、異なるデータを結び付けやすくなります。

1．品目コード

同じ製品や部品を、部門をまたいで同じコードで識別します。

たとえば、営業では「A100」、現場では「Aの大」、品質では「製品A」となっていれば、人には分かってもシステムには別物です。

正式な品目コードを一つ決め、通称や旧名称は別の属性として持たせます。

ここで注意したいのが、品目コードに情報を詰め込みすぎないことです。

「材質－形状－サイズ－顧客名」のようにコードそのものへ意味を詰め込むと、新しい材料や例外品が出たときにルールが崩れることがあります。

そのため、長期的には、変わりにくい識別子と、材質・寸法・分類などの属性を分けて管理する方が運用しやすくなります。

2．受注番号・製造ロット

「誰からの注文か」を追うなら受注番号。「何を一緒に作ったか」を追うなら製造ロット。用途によって必要なキーが変わります。

特にトレーサビリティでは、次の関係を記録できるようにします。

• 材料ロット
• 半製品ロット
• 製造ロット
• 出荷ロット

ここで大切なのは、BOMだけでは不十分という点です。

BOMは、「この製品を構成するために、どの部品や材料をどれだけ使うか」という標準的な構成を表します。

一方、トレーサビリティで必要なのは、「この製品ロットには、実際にどの材料ロットを使ったか」という実績です。

したがって、材料投入や部品消費の記録をロットと紐付ける必要があります。

3．設備ID・工程ID

設備名も、人によって呼び方が変わりやすい情報です。

「プレス3号機」「第2ラインのプレス機」「P-03」が同じ設備なら、一つの設備IDで管理します。

同じ設備を移設しても同じ資産として追跡したい場合は、設備IDを維持し、設置場所を属性として変更します。

一方、設備そのものを更新して別の設備へ入れ替えた場合は、新しいIDを発行した方が履歴を追いやすくなります。

工程についても同様です。

「切削」「研削」「検査」といった工程をコード化しておけば、製品がどの工程を通ったのかをデータとして追えます。

4．時刻

設備データと生産実績を結び付けるとき、意外に重要なのが時刻です。

設備側では、「10時12分に電力が上がった」と記録されている。

一方、日報には、「午前中に製品Aを加工した」としか残っていない。

この状態では、どの製品に電力を使ったのかを正確に結び付けられません。

また、設備ごとに時計がずれている場合もあります。

そのため、次のようなルールが必要です。

• システムや設備の時刻を合わせる
• 日付だけでなく必要な業務では開始・終了時刻も記録する
• 夜勤などで日付をまたぐ場合の「稼働日」の考え方を決める

ERP、MES、PLCはどうつながるのか

工場には、ERP、MES、SCADA、PLCなど、さまざまなシステムがあります。 ERPは受注・購買・在庫・会計などを管理する基幹業務システム、MESは製造指示や進捗・実績を管理する生産実行システム、SCADAは設備の状態を監視・制御するシステム、PLCは設備や機械を動かすための制御装置です。 用語だけを見ると複雑ですが、それぞれが「何を管理し、どのデータを持っているか」で分けると整理しやすくなります。

そして、それらの製造業のシステム連携を考える際によく使われる考え方に、ISA-95があります。

ISA-95は、工場の活動を大きく、次のように分け、それらの間でどのような情報を交換するかを整理する国際的な枠組みです。

• 経営・受発注・在庫などを扱う業務領域
• 生産実行や品質、保全などを扱う製造運用領域
• 設備を監視・制御する領域
• 実際の設備・センサ

中小工場では、専用MESがなくても問題ありません。

専用MESがなく、MESが担う製造実績の記録や進捗管理の一部を、日報やExcelで行っている工場もあります。

重要なのは製品名ではなく、「どこに、どんなデータがあり、次の業務へ何を渡す必要があるのか」を整理することです。

最初に見直したいのは「帳票」

中小工場でデータ基盤を作るとき、最初の対象として有力なのが日報や検査記録です。

なぜなら、設備から自動取得できない情報が、ここに多く残っているからです。

• どのロットを加工したか
• 何個作ったか
• どの設備を使ったか
• 何時から何時まで作ったか
• なぜ設備が止まったか
• 不良の内容は何だったか

紙をタブレットへ置き換えるだけでは不十分です。

電子化するときに、品目コード、ロット番号、設備ID、工程コード、開始・終了時刻を入力項目として持たせます。

すると、それまで単独だった日報が、受注、設備、品質、エネルギーのデータと結び付けられるようになります。

CSVでもデータ基盤は作れる

「データ基盤」という言葉から、すべてをAPIでリアルタイム連携する構成を考える必要はありません。APIとは、異なるシステム同士が自動でデータを受け渡すための仕組みです。

データの更新頻度によって、つなぎ方を変えます。

方法	向いている用途	注意点
CSV	日次実績、受注、マスタ	手作業、形式変更、取り込み漏れ
API	頻繁なシステム間連携	対応システム、開発・保守
ノーコード連携	部門内の小規模自動化	連携が乱立しないよう管理
IoTゲートウェイ	設備・センサデータ収集	通信仕様、設備側の対応確認

CSVは古い仕組みに見えますが、既存システムから出力できるのであれば、十分に有力な出発点です。

重要なのはCSVかAPIかではありません。

たとえば、同じ製品でも販売管理システムでは「商品コード：A001」、生産管理システムでは「品目コード：P-123」と登録されている場合があります。その場合、「A001＝P-123」のように、どのコード同士が同じ製品を指すのかを示す対応表を作ります。

さらに、次のような問題があったときに、黙って取り込みから除外しない仕組みを作ります。

• 未登録コードがあった
• 数量が空欄だった
• 日付形式がおかしかった

トレーサビリティは「実際に使ったもの」を残す

データがつながると、トレーサビリティの精度が上がります。

たとえば製品ロットAで不良が見つかったとします。

製造実績に、次の情報が紐付いていれば、原因調査を絞り込みやすくなります。

• 使用した材料ロット
• 通過した工程
• 使用設備
• 加工時刻
• 検査結果

逆方向も同じです。

ある材料ロットに問題が見つかったとき、その材料がどの半製品、どの完成品に使われたかをたどることができます。

データ基盤はCFPや取引先とのデータ連携にもつながる

ここまでの話は、主に社内改善です。

しかし、データをつなぐ価値は社内だけではありません。

経済産業省が進める「ウラノス・エコシステム」では、企業や業界をまたいで、必要なデータを安全に連携する仕組みの社会実装が進められています。

その先行例の一つが、自動車・蓄電池のCFPとデューデリジェンスに関するデータ連携です。

CFPとは、Carbon Footprint of Productの略で、製品のライフサイクルにおける温室効果ガス排出量を表します。

製品のCFPを考えるとき、次のような工場データは重要な基礎情報になります。

• どの材料をどれだけ使ったか
• どの工程を通ったか
• 工程でどれだけエネルギーを使ったか

CFP算定では、どこまでを算定範囲とするか、共通設備の排出量をどの製品へ配分するか、どの排出係数を使うか、サプライヤーからどのデータを受け取るかなどのルールが必要です。

つまり工場のデータ基盤は、CFPを自動計算する仕組みそのものではなく、信頼できる活動量データを取り出せる土台と考える方が正確です。

また、自動車・蓄電池分野では、ウラノス・エコシステムの先導プロジェクトとして、CFP・デューデリジェンス情報を企業間で安全に連携する取組が進んでいます。

こうした動きを見ると、今後は「自社の中で使えるデータ」だけでなく、取引先から求められたときに、根拠とともに必要なデータを出せる状態も重要になっていくと考えられます。

データ基盤は「作る」より「保つ」が難しい

共通コードを作り、帳票を電子化し、データをつないでも、それで終わりではありません。

新製品が追加される。図面が改訂される。工程が変わる。設備を更新する。担当者が替わる。

このたびにマスタを更新しなければ、データは徐々に現場とずれていきます。

そのため、マスタごとに責任者を決めます。

マスタ	主な更新責任の例
品目マスタ	設計・技術
BOM	設計・生産技術
工程マスタ	生産技術
設備マスタ	設備保全
顧客・取引先マスタ	営業・購買

ここでいう責任者とは、一人だけが入力するという意味ではありません。

「最終的に、そのデータが正しい状態に保たれていることに責任を持つ部門を決める」ということです。

さらに、誰が変更したか、いつ変更したか、何を変更したかを残します。

特に注意したいのが、設計変更です。

図面は改訂されたのにBOMは旧版。工程は変わったのに標準時間は旧版。

こうした状態になると、データ基盤そのものが信用されなくなります。

設計変更や工程変更の手続きに、「関連するマスタを更新したか」という確認を組み込むことが重要です。

4段階で小さく育てる

中小工場が最初から完成したデータ基盤を作る必要はありません。

次のように段階を分けます。

段階	やること	目指す状態
1	共通コードを決め、重要帳票を電子化	検索・集計できる
2	ロット、設備、時刻を製造実績と紐付ける	製品がどう作られたか追える
3	受注・品質・設備・エネルギーを横断表示	部門をまたいで原因を確認できる
4	顧客・取引先との必要データ連携	外部要求に根拠を持って答えられる

期間は会社によって変わります。

重要なのは、次のシステムを導入することではなく、一段階ごとに「何ができるようになったか」を確認してから広げることです。

最初の1か月でやること

データ基盤づくりの第一歩として、大規模な調査は必要ありません。

まず対象を一つに絞ります。

たとえば一つの製品群について、次の順番で確認します。

1. 受注データを確認する
2. 品目コードを確認する
3. BOMを確認する
4. 日報に記録されている内容を確認する
5. 品質記録を確認する
6. 同じロット番号でつながるか確認する

つながらないところがあれば、「コードが違うのか」「そもそも記録していないのか」「記録はあるがExcelの別ファイルなのか」を確認します。

これだけでも、自社のデータ基盤で最初に直すべき場所が見えてきます。

まとめ：データ基盤の本質は「システム」ではなく「約束事」

データ基盤というと、大きなデータベースやクラウドシステムを想像しがちです。

しかし、中小工場で最初に必要なのはそこではありません。

• 同じ製品を同じコードで呼ぶ
• どのロットか分かる
• どの設備を使ったか分かる
• いつ作ったか分かる
• マスタを誰が更新するか決まっている

この約束事がそろって初めて、受注、製造、品質、設備、エネルギーのデータがつながります。

逆に約束事がなければ、どれだけ新しいシステムを入れても、データは別々の場所に残ります。

IPAの「DX動向2025」が指摘した「部分最適」から抜け出すためにも、次に必要なのはツールの追加ではなく、「データが工程と部門をまたいでつながる状態」を作ることです。

外観検査AIも、需要予測も、エネルギーDXも、生成AIも、その効果を工場全体へ広げるには、同じ土台が必要になります。

出典・参考リンク

IPA｜DX動向2025｜https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html

IPA｜DX動向2026｜https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2026.html

ISA｜ISA-95 Series of Standards: Enterprise-Control System Integration｜https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard

IEC｜IEC 62264-1 Enterprise-control system integration｜https://webstore.iec.ch/en/publication/6675

経済産業省｜Ouranos Ecosystem（ウラノス・エコシステム）｜https://www.meti.go.jp/policy/mono_info_service/digital_architecture/ouranos.html

IPA｜サプライチェーン上のデータ連携の仕組みに関するガイドライン（蓄電池CFP・DD関係）｜https://www.ipa.go.jp/digital/architecture/guidelines/scdata-guidline.html

IPA｜データ連携の仕組みに関するガイドラインの手引き サプライチェーン共通編｜https://www.ipa.go.jp/digital/architecture/guidelines/scdata-guide.html

経済産業省・環境省｜カーボンフットプリント ガイドライン｜https://www.meti.go.jp/policy/energy_environment/global_warming/LCA_CFP/LCA_CFP.html

資源エネルギー庁｜デジタル・AI技術による省エネ・生産性向上に向けた手引き｜https://www.enecho.meti.go.jp/category/saving_and_new/saving/enterprise/ai/digital_ai_tebiki.html