製造業のデータ連携基盤｜工場IoT・PLC統合の事例5選と進め方

工場の設備から取れる稼働データ、MESに残る生産実績、基幹システムの受注や在庫は、多くの現場で別々の場所に散らばったままです。担当者がExcelに転記して突き合わせ、稼働率を出すのに月末3日かかる状態は、データが「取れていない」のではなく「つながっていない」ことから生まれます。

つながらない理由は技術の不足よりも、設備世代の混在、部門ごとに育ったシステム、品目や工程を指すコードの食い違いにあります。通信の口を開けるだけなら数週間で済みますが、数字が合う状態にするには、取得方式の選定とコード体系の統一という2つの設計判断を先に片づけることが条件です。

本記事では、製造業のデータ連携基盤をPLC・IoT・MES・基幹の各層でどう設計するかを、構築の5ステップと失敗パターン、業種別の事例5選とあわせて解説します。自社の工場でどの取得方式を選び、どこからコード統一に着手すべきかを判断する材料としてご活用ください。

製造業におけるデータ連携基盤とは：工場・IoT・PLCのデータが分断される背景

製造業のデータ連携基盤は、設備の制御信号から経営指標までを1本の流れとしてつなぐ中間層です。ここでは基盤の定義と役割、設備・MES・基幹という3層構造の違い、現場でデータが分断される3つの要因を順に整理します。最後に、個別インタフェースや既製の連携サービスと比べたときに連携基盤が何を担うのかを明確にし、構築ステップへ進む前提をそろえます。

データ連携基盤の定義と製造業で担う役割：OT層とIT層を橋渡しする中間層

データ連携基盤とは、複数のシステムからデータを収集し、形式や粒度をそろえて必要な先へ届ける共通の仕組みです。製造業では、設備や制御装置が属するOT（Operational Technology）の層と、基幹システムや分析基盤が属するITの層をつなぐ役割を担います。OT側は秒単位で更新される制御信号、IT側は日次や月次で締まる業務データという、時間軸も形式も異なる世界です。両者の間に変換と蓄積を担う層を置くことで、設備ごと・システムごとに個別の接続を作らずに済みます。

役割を具体的に言うと、取り込み・変換・配信・監視の4つです。取り込みはPLCやセンサー、MES、ERPからのデータ取得、変換はコード統一や単位換算、配信は分析基盤やBIツールへの受け渡し、監視は欠損や遅延の検知を指します。現場でよくあるつまずきは、取り込みだけを基盤の仕事と考え、変換と監視を各部門の手作業に残してしまうことです。この4つを基盤側の責務として最初に定義しておくと、識別子の突き合わせやデータ品質の仕組みを後から追加する手戻りを避けられます。

データ統合とは？統合の目的や初心者向けの進め方を解説

設備・MES・基幹の3層構造と各層を流れるデータの違い

工場のシステムは、設備層・MES層・基幹層の3層で捉えると整理しやすくなります。設備層にはPLCやセンサー、ロボットコントローラが属し、温度や回転数、稼働中か停止中かといった信号がミリ秒から秒単位で発生する世界です。MES層は作業指示や実績登録、品質検査の記録を扱い、工程やロット単位でデータが残ります。基幹層はERPや生産管理システムで、受注・在庫・原価を日次や月次の締め単位で管理する層です。3層を同じ画面に並べるには、この粒度の差を基盤側で吸収する必要があります。

3層の違いで押さえるべき点は、粒度・更新頻度・主キーの3つです。設備層は「どの設備のどの信号が何時何分何秒に何だったか」という単位で記録されます。MES層は「どのロットがどの工程を何時に通ったか」、基幹層は「どの受注がいつ出荷され原価がいくらか」という単位です。層をまたいでデータをつなぐには、設備IDとロット番号、ロット番号と受注番号のように、層と層の間をつなぐ結合キーを明示的に設計する必要があります。この結合キーが現場にないと、どれだけ通信を整えても数字を突き合わせることはできません。

製造現場でデータが分断される3つの要因：設備世代の混在・部門別システム・コード体系の不一致

製造現場でデータが分断される要因は、大きく3つに整理できます。

• 設備世代の混在：導入年が20年以上離れた設備が同じラインに並び、通信規格もメーカーも異なる
• 部門別システム：生産技術・品質保証・生産管理がそれぞれの予算で別々のシステムを導入してきた
• コード体系の不一致：同じ品目を設備側は型番、MESは品目コード、基幹は受注品番で呼んでいる

3つのうち、着手の優先度を最も高くすべきなのはコード体系の不一致です。設備世代の混在はゲートウェイの後付けで解消でき、部門別システムは連携基盤そのものが吸収します。コード体系だけは誰かが正本を決めない限り技術では解決できず、放置すると通信はつながるのに数字が合わない状態が続きます。実際の現場では、品目コードの桁数が部門ごとに違う、工程名が「組立」と「ASSY」で混在するといった事実が、連携プロジェクトの初月に必ずと言ってよいほど見つかるものです。

製造業のデータ分析はなぜ必要？解決できる課題やメリットなどを解説

データ連携基盤と個別インタフェース・iPaaSとの違い

システム同士をつなぐ手段は、個別インタフェースの開発、iPaaS（Integration Platform as a Service）の利用、データ連携基盤の構築の3つに分かれます。個別インタフェースは2つのシステム間に専用のプログラムを書く方法で、接続先が増えるたびに組み合わせの数だけ開発が必要です。iPaaSはクラウド上でSaaS同士をつなぐサービスで、API連携には強い反面、PLCや旧設備の通信プロトコルには対応していない製品が大半を占めます。3つの違いを比較軸ごとに整理すると、次の表のとおりです。

判断基準は接続先の数とOT層の有無です。接続先が3本以内で設備データを扱わないなら個別インタフェースで十分であり、SaaS間の連携が中心ならiPaaSが最も早く立ち上がります。設備・MES・基幹の3層をまたぎ、接続先が5本を超える見込みがあるなら、変換と監視を一元化できるデータ連携基盤を選ぶのが現実的です。なお、基盤を構築したうえでSaaS側の接続にiPaaSを併用する構成も一般的であり、両者は排他ではありません。

製造業がデータ連携基盤で解決できること：工場データ活用の4つのメリット

連携基盤は接続のための設備投資ではなく、業務の結果を変えるための投資です。ここでは、稼働と実績のリアルタイム可視化、品質とトレーサビリティ、予知保全と歩留まり改善、拠点横断の4つについて、何がどう変わるのかを業務の単位で整理します。それぞれのメリットは、後述する構築ステップでどの層を優先するかの判断材料にもなるため、自社で効果が大きい順に読み進めてください。

設備稼働と生産実績のリアルタイム可視化：手入力・転記作業からの脱却

稼働データと生産実績が基盤でつながると、日報の手入力と月末の転記作業がなくなります。典型的な工場では、各ラインの作業者が稼働時間と生産数を紙やExcelに記入し、生産管理担当が月初に集計して稼働率を出している状態です。この作業には1ライン当たり月5〜10時間かかるうえ、転記ミスで数%の誤差が入ることも珍しくありません。PLCの稼働信号とMESの実績登録を基盤で突き合わせれば、稼働率と生産数は作業者が入力しなくても自動で算出される数字になります。

可視化の設計で現場がつまずくのは、停止理由の扱いです。PLCから取れるのは「止まった」という事実だけで、段取り替えなのか故障なのか材料待ちなのかは分かりません。回避策として、停止が一定時間を超えたときだけ作業者がタブレットで理由を選択する運用にすると、入力負荷を抑えながら内訳を残せます。選択肢は5〜8個に絞り、「その他」の比率が2割を超えたら選択肢を見直すという運用ルールまで決めておくのが、データを形骸化させないコツです。

品質管理とトレーサビリティの強化：ロット単位で工程を横断追跡

品質問題が起きたとき、どのロットがどの設備をどの条件で通ったかを数分で特定できるかどうかは、連携基盤の有無で大きく変わります。MESの工程実績、設備の加工条件、検査装置の測定値が別々に保管されていると、原因追跡はロット番号を手がかりに複数システムを人が渡り歩く作業です。1件の追跡に半日から2日かかる現場も多く、その間に同じ条件で生産が続くことが二次被害を生みます。顧客への回答期限が迫るなかで、担当者が各システムの画面を印刷して机に並べる光景は、連携前の工場で頻繁に見られるものです。

基盤でロット番号を結合キーとして各層のデータをひもづけておくと、追跡は検索1回で済みます。実装上の判断基準は、ロット番号が設備層まで届いているかどうかです。届いていない設備では、MESの作業開始時刻と設備の加工時刻を突き合わせる時刻ベースの推定でひもづけます。時刻ベースのひもづけは時計のずれが数秒あるだけで別ロットに混ざるため、NTPによる時刻同期を設備側まで徹底することが前提条件です。この前提を確認せずに着手すると、トレース結果の信頼性を担保できません。

予知保全・歩留まり改善へのデータ活用：センサーデータと実績データの突き合わせ

予知保全や歩留まり改善は、センサーデータ単体では成り立ちません。振動や温度の時系列があっても、「いつ故障したか」「どのロットが不良だったか」という実績側のラベルがなければ、どのパターンが異常なのかを学習できないからです。連携基盤の価値は、センサーデータと保全記録、品質実績を同じキーで並べられる点にあります。保全記録は紙の作業報告書に残っていることが多く、故障日時と対象設備だけでも電子化するところが最初の作業です。

工数の目安として、1設備の予知保全モデルを作るには、正常時と異常時の両方を含む3〜6か月分のデータが必要です。異常の発生が年に数回しかない設備では、異常データが集まる前に半年以上が経過します。投資対効果を早く出したいなら、異常の頻度が高く停止コストが大きい設備から着手し、学習に必要なデータが揃うまでは閾値監視で運用するのが現実的な進め方です。モデルを作る前段階の閾値監視だけでも、突発停止を2〜3割減らせた工場は珍しくありません。

データ分析基盤とは？基盤を構築するための5つのステップ

拠点横断・サプライチェーン連携：複数工場や取引先とのデータ共有

複数拠点を持つ製造業では、工場ごとに異なる生産管理システムやExcel台帳が使われ、本社が全社の生産状況を把握するのに週単位の集計を待つ状態が一般的です。連携基盤を拠点共通の受け口として置くと、各工場のシステムを置き換えずに、統一フォーマットで生産実績や在庫を集められます。拠点側のシステム改修を最小限に抑えられる点が、全社の基幹刷新と比べたときの大きな利点です。基幹刷新が数年がかりの投資になるのに対し、受け口の設置は半年前後で効果が出ます。

拠点横断で最初につまずくのは、拠点ごとの品目コードと単位の違いです。同じ製品を国内工場はkg、海外工場はlbで記録している、品目コードの桁数が拠点で異なるといった差異は必ず出てきます。拠点横断の連携は、各拠点のコードを全社コードに変換する対照表を基盤側に持たせ、拠点のシステムには手を入れない方針にすると立ち上がりが早くなるものです。取引先との連携では、EDIの既存データをそのまま基盤に取り込み、受注と自社の生産計画を同じ画面で照合できるようにするところから始めます。

製造業のデータ連携基盤を構築する5つのステップ

構築の順番を間違えると、通信は整ったのに数字が合わない、集めたデータを誰も使わないといった状態に陥ります。ここでは、連携対象の棚卸しから段階的な稼働までを5つのステップに分け、それぞれで決めるべき内容と判断基準を示します。特にSTEP3のコード標準化をSTEP4の識別子の突き合わせより先に置く順序は、後戻りを防ぐうえで外せないポイントです。

STEP1：連携対象の棚卸し：設備・MES・基幹の3層ごとに渡すデータと粒度を定義

最初のステップは、何をどこからどこへ、どの粒度で渡すのかを一覧にすることです。設備・MES・基幹の3層ごとに、データ項目・発生頻度・主キー・保有部門・現在の取得方法を1行ずつ書き出します。棚卸しの単位は設備1台、システム1本ごとで、30設備規模の工場なら2〜3週間が目安です。この段階で「どの指標を出したいか」から逆算して項目を絞ると、取り込み対象を全信号から数十項目に減らせます。一覧に入れる項目は、次の5点を押さえておけば後工程で困りません。

• データ項目名と意味（稼働信号・生産数・加工温度など）
• 発生頻度と保持期間（秒単位で3か月、日次で5年など）
• 主キーと他層との結合キー（設備ID、ロット番号、受注番号）
• 保有部門と現在の取得方法（PLC直読・手入力・CSV出力）
• 活用目的とそれを見る人（稼働率をラインリーダーが毎朝確認など）

棚卸しでよくあるつまずきは、設備メーカーの仕様書に載っている信号をすべて対象にしてしまうことです。1台のPLCには数百から数千のアドレスがあり、全部を取ると通信負荷と保管コストが跳ね上がります。棚卸しの判断基準は「その項目を見て誰が何を判断するか」が答えられるかどうかで、答えられない項目は対象から外すのが原則です。外した項目は一覧に残しておき、第2フェーズで必要になったときに追加すれば済む運用にしておきます。

STEP2：現場データの取得方式の選定：PLC直結・OPC UA・IoTゲートウェイの使い分け

設備層からデータを取る方式は、PLC直結、OPC UA（OPC Unified Architecture）、IoTゲートウェイの3つが中心です。PLC直結は、三菱電機のMCプロトコルやオムロンのFINSなどメーカー独自の通信でPLCのメモリを直接読む方式を指します。OPC UAは、メーカーをまたいで共通の手順でデータを取れる産業用の標準規格で、対応機器なら設備名や単位の情報も一緒に取得できる点が利点です。IoTゲートウェイは、通信機能のない旧設備にセンサーや信号変換器を後付けし、ゲートウェイ機器を経由して上位へ送る方式になります。

選定の判断基準は、設備の通信対応と改造可否の2軸です。PLCが通信対応で同一メーカーに偏っているならPLC直結が最も安く、メーカーが混在しOPC UA対応機器が多いならOPC UAで統一します。通信機能のない旧設備や保守契約上PLCに触れない設備には、ゲートウェイの後付けで稼働信号と温度だけを取る方式が、改造リスクを避けつつ最短で立ち上がります。1つの工場で3方式が混在するのは普通のことです。基盤側で受け口を分けて吸収する前提で設計しておきます。

STEP3：マスタとコード体系の標準化：品目・工程・設備コードの正本を決める

コードの標準化で決めることは、品目・工程・設備の3つのマスタについて、どのシステムの値を正本とするかです。正本を決める判断基準は、最も更新が早く、最も多くの業務がその値で動いているシステムを選ぶことにあります。品目は基幹システム、工程はMES、設備は保全管理システムか設備台帳が正本になる例が多く見られるものです。正本が決まったら、他システムの値は正本のコードへ変換する対象として扱い、新規の採番は正本側でのみ行うルールにします。

標準化の作業は、全マスタを一度に統一するのではなく、連携対象の指標に関係する品目と工程から着手します。30設備規模の工場であれば、品目数千件・工程数十件・設備数十件の対照表を作る作業で1〜2か月が目安です。コード標準化を突き合わせより先に行う理由は、正本が決まっていない状態で突き合わせを始めると、ルールが部門ごとの主張に引きずられて収束しないからです。正本を決めるのは技術者ではなく業務側の責任者であり、生産管理部長や品質保証部長クラスの決裁を最初に取り付けておきます。

マスタデータ管理（MDM）とは？適切に運用する重要性とその手法を解説

STEP4：名寄せ設計と変換ルールの実装：部門ごとに異なる識別子の突き合わせ

名寄せとは、同じ対象を指す異なる識別子を1つに統合する作業です。製造業では、設備側の型番とMESの品目コードと基幹の受注品番が同じ製品を指している、というケースが典型になります。名寄せ設計では、正本コードを縦軸、各システムのコードを横軸にした対照表を作り、1対1・1対多・多対1のどれに当たるかを明示する作業が中心です。1対多になる組み合わせは、変換ルールだけでは解決できないため、業務側で定義を分ける判断を仰ぎます。

変換ルールの実装は、対照表をデータベースのテーブルとして基盤に持たせ、取り込み時に自動で正本コードへ置き換える形です。対照表に存在しないコードが来た場合の扱いを先に決めておくことが、運用で止まらないための条件になります。未知のコードは取り込みを止めるのではなく、「未対応」の印を付けて通し、週次でリストを担当者に回して対照表を更新する運用が実務的です。現場でよくあるつまずきは、対照表をExcelで管理して基盤に手で反映する形にしてしまい、更新が追いつかなくなることです。対照表の編集画面を担当者に渡し、基盤が直接参照する構成にしておきます。

名寄せとは？正確な顧客データ管理の方法と活用ポイントを徹底解説

STEP5：段階的な稼働と効果測定：見える化から計画連動まで投資を区切る

稼働は、見える化・分析・計画連動の3段階に区切り、段階ごとに効果を測って次の投資を判断します。第1段階の見える化は、稼働率と生産数をダッシュボードに出すところまでで、1〜2ラインを対象に3〜4か月が目安です。第2段階の分析は、停止理由の内訳や品質と加工条件の相関を見る段階で、ここで初めてトレーサビリティや予知保全が対象になります。第3段階の計画連動は、実績を生産計画や在庫引当に自動で反映する段階で、基幹側の改修を伴うため最後に置くのが定石です。

効果測定の指標は段階ごとに1つに絞ります。見える化なら「日報作成にかかる時間」、分析なら「品質問題の原因特定にかかる時間」、計画連動なら「計画変更から現場への反映までの時間」です。各段階の終わりに指標の改善幅を経営層へ報告し、次の段階の予算を取るというサイクルにすると、一度に全社展開する場合より承認が通りやすくなります。第1段階で投資回収の見込みが立たなければ、対象ラインや取得方式を見直したうえで第2段階へ進むのが安全です。

製造業のデータ連携基盤で成果を出す実務ノウハウ

構築ステップどおりに進めても、運用に入ると欠損や単位違い、部門間の責任の押し付け合い、ネットワークの制約といった問題が顔を出します。ここでは、データ品質の検知を基盤に組み込む方法、リアルタイムと日次バッチの線引き、OT部門とIT部門の責任分界の3点が前半の内容です。あわせて工場ネットワークのセキュリティと製品選定の確認観点にも触れ、設計段階で決めておけば後からの修正を避けられる内容を5つにまとめて示します。

データ品質の検知を基盤側に組み込む：欠損値・重複・単位不一致・タイムスタンプのずれ

工場データの品質問題は、欠損値・重複・単位不一致・タイムスタンプのずれの4種類にほぼ集約されます。欠損は通信断やセンサー故障で発生し、重複はゲートウェイの再送や二重登録で起こる現象です。単位不一致は拠点や設備によるkgとg、℃と℉の混在、タイムスタンプのずれは設備の内蔵時計が同期されていないことが原因になります。これらを分析側で毎回クレンジングするのではなく、基盤の取り込み時に検知して印を付ける設計が原則です。

• 欠損：一定間隔で来るはずの値が来ない場合に欠損フラグを立て、前回値で埋めない
• 重複：設備IDとタイムスタンプの組み合わせで一意性を確認し、重複は後着を破棄
• 単位不一致：取り込み時に設備ごとの単位定義を参照し、基準単位へ換算
• タイムスタンプ：設備時刻と基盤受信時刻の差が5秒を超えたら警告を記録

検知結果は、データそのものとは別の品質ログに残し、日次で件数を集計して担当者へ通知します。品質問題を基盤側で検知する最大の利点は、分析担当が毎回前処理をやり直す工数をなくし、問題の発生源を設備や通信の単位で特定できることです。欠損率が1%を超える設備は通信経路の見直し、時刻ずれが続く設備はNTP設定の確認というように、ログから保全のアクションへつなげるところまで運用に組み込みます。ログの件数を月次で並べると、通信機器の老朽化やセンサーの劣化が数字として見えてくるため、設備更新の優先順位付けにも使える情報です。

データ品質とは？品質評価項目や品質を向上させるための実務的対策を解説

リアルタイム連携と日次バッチの線引き：出荷判定・トレース・進捗管理に絞る判断基準

すべてをリアルタイムで連携する必要はなく、むしろ多くの業務は日次バッチで十分です。リアルタイム連携は、通信負荷・基盤の処理能力・障害時の影響範囲のいずれも大きくなるため、本当に秒や分の単位で判断が変わる業務に絞ります。判断基準は「その情報が遅れると、その日のうちに損失が確定するか」です。出荷判定の品質結果、不良発生時のトレース、ライン進捗に応じた段取り指示の3つは、遅れが即座に損失につながるためリアルタイムの対象になります。

逆に、原価計算・稼働率の月次推移・保全計画の見直しは、日次バッチで翌朝に反映されていれば業務が成り立つものです。リアルタイムと日次の線引きを業務ごとに文書化し、「リアルタイムが必要だと主張する側が損失額で根拠を示す」ルールにすると、要望の膨張を抑えられます。現場でよくあるつまずきは、ダッシュボードの更新頻度を秒単位にしたことで通信とデータベースの負荷が上がり、肝心の出荷判定の処理が遅れることです。見せるための更新頻度と、判断に使う更新頻度は分けて設計します。

OT部門とIT部門の責任分界点：制御盤の中と上位システムで役割を分ける

連携基盤のプロジェクトで最も揉めやすいのが、設備を扱うOT部門（生産技術・保全）と、システムを扱うIT部門の責任分界です。線引きの基準は、物理的には制御盤の扉を境にすることにあります。制御盤の中にあるPLCやセンサー、信号変換器の設定と保守はOT部門、制御盤の外に出た信号を受け取るゲートウェイから上位システムまではIT部門の担当です。この境界を文書で定義し、障害時にどちらが一次対応するかを設備ごとに一覧にしておきます。

責任分界で現場がつまずくのは、ゲートウェイ機器の扱いです。制御盤の中に設置されることが多い一方で、設定はネットワークの知識を要するため、どちらの部門も自分の担当だと思っていない状態が生まれます。ゲートウェイは設置と電源はOT部門、通信設定と監視はIT部門と役割を分け、設定変更は両部門の立ち会いで行うルールにするのが実務上の落としどころです。両部門の間で週1回の定例を設け、品質ログに出た設備側の問題をOT部門が、通信側の問題をIT部門が持ち帰る形にすると、押し付け合いが起きにくくなります。

工場ネットワークのセキュリティ設計：制御系と情報系の分離と一方向通信

工場ネットワークは、設備を制御する制御系と、事務や分析に使う情報系を物理的または論理的に分離するのが大前提です。連携基盤はこの2つの間に置かれるため、制御系から情報系へデータは流すが、情報系から制御系へは通信を通さないという一方向の設計にします。具体的には、制御系と情報系の間にDMZを設け、ゲートウェイやOPC UAサーバーをDMZに配置して、情報系からは制御系の機器に直接到達できない構成が基本です。

一方向通信を物理的に保証する手段として、データダイオードと呼ばれる機器があります。片方向にしか信号が流れない構造で、情報系が侵害されても制御系へ侵入できないため、安全性要求が高い工場で採用される機器です。費用は1経路で数百万円規模になるため、すべての経路に入れるのではなく、重要設備や危険物を扱う工程に限定するのが一般的な使い方になります。セキュリティ設計は、情報系の端末が1台乗っ取られたときに設備が止まらないことを基準に判断すると、過不足のない投資です。設計の確認観点は次の4点に絞られます。

https://data-viz-lab.com/datasecurity

• 制御系と情報系の間にDMZがあり、情報系から制御系の機器へ直接通信できない
• ゲートウェイやOPC UAサーバーの認証情報が初期値から変更されている
• 設備側のファームウェア更新手順が、保守契約と矛盾しない形で文書化されている
• 基盤へのアクセス権限が部門・役割ごとに分かれ、退職者のアカウントが残らない運用になっている

連携基盤を選ぶ際の確認観点：対応プロトコル・変換機能・監視・再送・拠点展開性

製品やサービスを選ぶ際は、機能一覧ではなく自社の設備と運用に当てはめた確認観点で比較します。最初に確認すべきは対応プロトコルで、自社に存在するPLCのメーカーと型式、OPC UAの対応、MQTTなどIoT向け通信への対応を、棚卸しの一覧と突き合わせる作業です。変換機能については、コードの対照表を基盤内で管理できるか、単位換算やタイムスタンプの補正を設定で行えるかを確認します。候補製品を3つ程度に絞ったうえで、次の5つの観点を同じ表に並べて比較するのが効率的です。

• 対応プロトコル：自社のPLCメーカー・OPC UA・MQTT・ファイル取り込みに対応しているか
• 変換機能：対照表の管理画面があり、業務担当者が更新できるか
• 監視：欠損・遅延・エラーを検知し、通知先を設定できるか
• 再送：通信断の復旧後に、断絶中のデータを自動で再取得できるか
• 拠点展開性：拠点を追加するときに、同じ設定を複製して展開できるか

5つの観点のうち、再送機能は見落とされやすい反面、運用で最も効いてきます。工場の通信断は月に数回は起こるものであり、再送機能がないと欠損の穴埋めを人が行うことになって、連携の自動化が崩れるからです。製品のデモでは、通信を意図的に切って復旧後にデータが揃うかを実際に試すと、カタログでは分からない差が見えます。コスト感は、オンプレミスのパッケージで初期数百万円から、クラウド型で月額数十万円からが目安であり、設備台数と拠点数で大きく変わる点に注意が必要です。

製造業のデータ連携基盤でよくある失敗パターンと回避策

連携基盤のプロジェクトは、技術的に難しい箇所よりも、順番や運用の決め方を誤った箇所で止まります。ここでは、PoC止まり、集めたデータの未活用、数字の不一致、締め処理との競合、保守契約の抵触、名寄せ表の放置という6つの失敗パターンを扱います。それぞれについて発生する原因と具体的な回避策を示すので、自社の計画に当てはめ、該当するものがないかを確認する材料としてお読みください。

PoC止まりで全社展開できない：最初から対象設備を広げすぎる

PoCで成果が出たのに全社展開に進めないケースの多くは、PoCの段階で対象を広げすぎたことに原因があります。10ラインを同時に対象にすると、設備ごとの通信設定やコード差異への対応に時間を取られ、半年経っても見える化の画面が安定しません。結果として経営層に見せられる成果がなく、予算が継続されないという流れです。PoCは1〜2ラインに絞り、3か月以内に「日報作成時間が何時間減ったか」という1つの数字を出すことを目標にします。

回避策として、PoCの開始時点で全社展開の条件を文書にしておきます。たとえば「稼働率の自動算出が3か月安定して動くこと」「対象ラインの日報作成時間が半減すること」の2条件を満たしたら次の3ラインへ、という形です。条件を先に決めておくと、PoCの終了が「なんとなく様子見」ではなく、展開か中止かの判断になります。PoCで使った取得方式やコード対照表は、そのまま展開先で再利用する前提で作り、使い捨ての検証にしないことも継続のために効く要素です。

PoCとは？意味や失敗させないポイントをわかりやすく解説

データは集まるが活用されない：目的とKPIを決めずに収集から始める

「とりあえず全部集めてから考える」という方針で始めたプロジェクトは、数か月後に大量のデータと誰も見ないダッシュボードが残ります。原因は、データを見て何を判断するのかを決めずに収集を先行させたことです。収集には通信設定やストレージのコストがかかる一方、判断に使われないデータは価値を生みません。回避策は、収集を始める前に「誰が・いつ・何を判断するためのデータか」を指標ごとに1行で書き出し、書けない指標は収集対象から外すことです。

活用を定着させる実務上の工夫は、ダッシュボードを見る時間を業務に組み込むことにあります。朝礼の冒頭5分で前日の稼働率と停止理由を全員で確認する、週次の生産会議で品質ログの件数を報告するといった形で、データを見る場を固定します。見る場が決まっていないデータは、どれだけ正確に集まっていても活用されないため、収集の設計と同時に閲覧の運用まで決めておくことが条件です。閲覧回数を基盤側のログで把握し、1か月以上開かれていない画面は廃止するルールにすると、画面の数が増え続ける状態も防げます。

通信はつながるのに数字が合わない：コード体系の整理を後回しにする

通信の疎通確認が終わり、データも流れているのに、MESの生産数と基幹の出荷数が合わないという問題は、ほぼ例外なくコード体系の未整理が原因です。品目コードの桁数が違う、工程名が揺れている、設備IDが部門で別に振られている、といった差異が集計時に別の行として扱われ、合計が一致しません。技術担当はプログラムのバグを疑って調査に時間を使いますが、原因は設計段階の決め事の不足です。調査に数週間を費やした末に、品目コードの先頭のゼロが片方で落ちていただけだった、という結末も珍しくありません。

回避策は、STEP3で述べたとおり正本を先に決め、対照表を基盤に持たせることに尽きます。数字が合わない問題は、疎通確認の前に品目・工程・設備の各コードについて「どのシステムの値を正とするか」が文書で決まっているかを確認するだけで、大半が未然に防げる性質のものです。すでに稼働後に不一致が見つかった場合は、不一致の行を抽出して対照表に欠けているコードを特定し、週次で埋めていく運用に切り替えます。不一致率が1%を切るまでは、ダッシュボードの数値に「暫定」の表示を付けて、現場が誤った判断をしないようにするのが安全です。

締め処理とリアルタイム更新が競合する：基幹側の処理時間帯を把握していない

基幹システムには、日次や月次の締め処理が走る時間帯があり、その最中に連携基盤からデータを書き込むと、処理の失敗や数値の二重計上が起こります。現場でよくあるのは、月末の夜間に原価計算のバッチが走っている時間に、基盤が生産実績を流し込み続けたことで、翌朝の原価が合わなくなる事象です。基幹の運用担当は締め処理の時間帯を把握していますが、連携基盤の設計者がそれを聞いていないことが原因になります。設計者と基幹の運用担当が一度も同じ会議に出ていない、というプロジェクトは珍しくありません。

回避策は、基幹側のバッチスケジュールを設計段階で入手し、基盤からの書き込みを止める時間帯を設定に組み込むことです。締め処理中は基盤側でデータを一時保持し、処理の完了を確認してから書き込みを再開する仕組みにすると、基幹側の運用に手を入れずに競合を避けられます。確認の方法は、基幹側が処理完了フラグをテーブルに書く形が最も確実です。フラグが用意できない場合は、締め処理の最大所要時間に余裕を加えた固定の停止時間帯で運用します。月末と期末は処理時間が通常の2〜3倍になることが多いため、停止時間帯も暦に応じて変える設定にしておくのが無難です。

旧設備の改造で保守契約に抵触する：メーカー確認を省略する

通信機能のない旧設備からデータを取ろうとして、PLCの空きポートに通信ユニットを追加する作業は、設備メーカーとの保守契約に抵触する場合があります。制御盤内に信号変換器を取り付ける作業も同様です。無断で改造した設備は保守の対象外になり、故障時の修理費が全額自己負担になるケースが実際に起きています。安全規格の認証が無効になる設備もあり、改造の影響は費用だけでは済みません。数万円の通信ユニットを節約した結果、数百万円の修理費を負担した事例は、製造業のデータ活用の現場で繰り返し聞く話です。

回避策は、設備ごとにメーカーへ書面で確認し、改造の可否と条件を記録に残すことです。確認には1設備当たり2〜4週間かかるため、棚卸しの段階で並行して進めます。メーカーが改造を認めない設備には、制御盤の外側に電流センサーや光センサーを取り付けて稼働の有無だけを取る非接触の方式を選べば、契約に触れずに最低限のデータを確保できるものです。稼働の有無と停止時間だけでも稼働率は算出できるため、非接触で始めておき、設備更新のタイミングで通信対応の機種に置き換える計画にします。

名寄せ表の更新が止まり連携が止まる：運用担当と更新ルールが未定義

名寄せの対照表は、作って終わりではなく、新しい品目や設備が追加されるたびに更新が必要です。更新の担当者とタイミングを決めていないプロジェクトでは、稼働から数か月後に未対応コードが増え続け、ダッシュボードの数値が徐々にずれていきます。気づいたときには数百件の未対応が溜まり、誰も手を付けられずに連携そのものが信用を失う、という経緯をたどるのが典型です。現場が「あの画面の数字は当てにならない」と言い始めた時点で、連携の価値は失われています。

回避策は、対照表の更新を既存の業務に組み込むことです。品目マスタの新規登録を基幹側で行う担当者が、登録と同時に対照表の行を追加する手順にすれば、別の作業として増えません。対照表の更新責任者を部門名ではなく個人名で定め、未対応コードの件数を週次で確認するという2点を運用ルールに書いておけば、更新の停止は起こりにくくなるものです。未対応コードが週に10件を超える状態が続くなら、新規コードの採番ルール自体に問題があるため、基幹側の運用を見直す判断材料にもなります。

製造業におけるデータ連携・統合の事例5選：工場IoT・PLC・基幹システム

ここまでの手順とノウハウが、実際の工場でどのような形になるのかを5つの事例で示します。自動車部品・食品・電子部品・産業機械・化学の各業種について、取得方式や連携パターンが重ならないよう選び、課題・アプローチ・成果の順で記述します。いずれも業種と規模をもとに匿名化した事例であり、設備構成や拠点数が自社の状況に近いものから読み進めてください。

事例1：自動車部品メーカー：PLC直結で稼働データを収集し設備停止の内訳を可視化

従業員500名規模の自動車部品メーカーでは、プレスと溶接の計24設備について、稼働率を日報の手入力から集計していました。ラインリーダーが毎日30分を日報に費やし、集計結果が出るのは翌週で、停止の原因を振り返る頃には現場の記憶が薄れている状態です。設備は三菱電機製PLCに統一されていたため、MCプロトコルによるPLC直結を取得方式に選びました。収集項目は稼働信号・生産数・異常コードの3項目に絞り、1秒周期で基盤へ取り込む設計です。

停止理由については、5分以上の停止が発生したときだけ作業者がタブレットで6つの選択肢から選ぶ運用にし、短い停止はPLCの異常コードから自動分類しました。この結果、日報作成がなくなって1ライン当たり月10時間の工数が削減され、停止の内訳が翌朝には見られる状態です。停止時間の4割が段取り替えに集中していることが数字で示されたため、段取り改善の活動に優先順位が付き、半年で稼働率が6ポイント改善しています。着手から見える化までの期間は4か月でした。

事例2：食品メーカー：IoTゲートウェイの後付けで旧設備の温度・稼働記録を自動化

従業員200名規模の食品メーカーでは、導入から20年以上経過した加熱殺菌設備と冷却設備について、温度記録を作業者が1時間ごとに紙へ転記していました。衛生管理上、温度の記録は必須であり、記録の抜けや転記ミスが監査で指摘されることが課題です。設備には通信機能がなく、メーカーへの確認で制御盤内の改造も認められませんでした。そこで、制御盤の外側に温度センサーと電流センサーを後付けし、IoTゲートウェイ経由で基盤へ送る方式を選んでいます。

ゲートウェイはMQTTで1分周期に温度と稼働の有無を送信し、基盤側で設備IDと時刻をキーに保存する構成です。温度が管理基準を外れた場合は、基盤の監視機能が担当者へ即時に通知する設定にしています。転記作業がなくなったことで1日当たり延べ2時間の作業が削減され、監査では温度記録を電子データで即時に提示できる状態です。設備改造を伴わない方式にしたため保守契約に影響はなく、設備1台当たりの初期費用も20万円前後に収まっています。

事例3：電子部品メーカー：MESと基幹システムを連携しロットトレーサビリティを確立

従業員1,000名規模の電子部品メーカーでは、MESに工程実績、基幹システムに受注と出荷、検査装置に測定値がそれぞれ保管されていました。顧客からの品質問い合わせに対して、該当ロットの工程履歴をそろえるのに2日を要していたことが課題です。原因は、MESのロット番号と基幹の出荷番号を結ぶ対照が人の記憶とExcelに依存していたことにあります。連携基盤を導入し、ロット番号を結合キーとして3つのデータを1つのテーブルに統合しました。

着手前に、品目コードの正本を基幹に、工程コードの正本をMESに定め、検査装置の品目表記を正本コードへ変換する対照表を基盤に持たせた点が準備の中心です。連携後は、ロット番号を入力すれば受注から出荷までの全工程と検査値が1画面に並び、問い合わせへの回答が2日から30分に短縮されました。MESと基幹の連携は基幹側の夜間締め処理の時間帯を避けて日次で実行し、検査値のみ出荷判定に使うためリアルタイムで取り込む構成です。対照表の整備に2か月、連携の実装に3か月を要しています。

事例4：産業機械メーカー：国内外の複数拠点の製造情報を統合しExcel管理から脱却

国内2拠点と海外2拠点を持つ産業機械メーカーでは、拠点ごとに異なる生産管理システムとExcel台帳が使われていました。本社が全社の進捗と在庫を把握するのに毎週3日の集計作業が発生していたことが課題です。拠点ごとに品目コードの桁数が異なり、重量の単位もkgとlbが混在していたため、集計のたびに手作業の換算が必要だったことが工数の主因でした。各拠点のシステムを置き換える案は費用と期間の面で見送られ、拠点共通の受け口として連携基盤を置く方針を取っています。

基盤には拠点コードごとの対照表と単位換算の定義を持たせ、各拠点は既存システムから日次でCSVを出力するだけで済む形が今回の設計です。拠点側の改修はCSV出力の設定変更のみで、1拠点当たり2週間で接続が完了しています。全社の進捗と在庫が翌朝に統一フォーマットで見られるようになり、本社の集計作業は週3日からゼロになった計算です。拠点を追加する際は対照表の行を追加するだけで対応できるため、その後の新拠点の接続も1か月以内で完了しました。

事例5：化学メーカー：センサーデータを分析基盤へ連携し予知保全を実現

従業員800名規模の化学メーカーでは、反応槽の攪拌機やポンプの突発停止が年に十数回発生し、1回当たりの停止損失が数百万円に達していました。振動と温度のセンサーは設置済みでしたが、データは制御系の記録装置に閉じている状態です。保全記録は紙の報告書に残っているだけで、両者を突き合わせた分析はできませんでした。制御系と情報系を分離したうえで、OPC UAサーバーをDMZに置き、センサーデータを一方向で分析基盤へ連携する構成にしています。

保全記録は過去2年分の故障日時と対象設備を電子化し、センサーデータと設備IDで結合しました。異常データが集まるまでの半年間は閾値監視で運用し、その後に故障の前兆を検知するモデルへ移行した流れです。結果として、突発停止は年間十数回から数回に減り、保全を計画停止の枠内で行えるようになったことで停止損失が前年比で約6割減少しました。セキュリティ面では情報系から制御系への通信を遮断しているため、分析基盤の環境を変更しても設備側に影響が及ばない構成です。

まとめ：製造業のデータ連携基盤は「取得方式」と「コード統一」で成否が決まる

製造業のデータ連携基盤は、設備・MES・基幹の3層をつなぐ中間層として、取り込み・変換・配信・監視の4つを担います。構築の成否を分けるのは、設備の通信対応と改造可否で決まる取得方式の選定と、品目・工程・設備のコードについて正本を決めるコード統一の2点です。この2点を棚卸しの段階で片づけ、PoCは1〜2ラインに絞って3か月で1つの数字を出し、効果を確認しながら段階的に広げる進め方が最も確実な道筋です。

運用では、データ品質の検知を基盤側に組み込み、リアルタイムの対象を損失が即座に確定する業務に絞り、OT部門とIT部門の責任分界を制御盤の扉で線引きします。名寄せ表の更新責任者を個人名で定め、未対応コードを週次で確認する運用まで決めておけば、連携は稼働後も止まりません。自社の工場で最初に着手すべきラインと取得方式を決め、コードの正本を業務側の責任者と合意するところから始めてください。

「これから工場のデータ連携基盤を構築したいけれど、取得方式やコード統一をどう進めればいいかわからない」「製造業のデータ活用に詳しい専門家の知見を取り入れたい」という方は、製造業のデータ連携・分析の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、工場データの連携と活用の取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り