製造業DXを加速するデータ加工手法：現場の『ゴミ』を『資産』に変える工場IoTデータクレンジングの実践

工場の各設備にセンサーを取り付け、ネットワークをつなぎ、膨大なIoTデータをクラウドに蓄積する。製造業DXの第一歩として、こうしたデータ収集の仕組みを構築したものの、「いざAIで分析しようとしたら、データが汚すぎて全く使えなかった」という壁に直面するケースは決して珍しくありません。

センサーのノイズ、通信の瞬断による欠損、人間が手入力した曖昧な作業記録。これらが混在した生データをそのままアルゴリズムに投入しても、有意義な洞察は得られません。製造現場のデータ活用において、真の勝負の分かれ目となるのは、高度なAIモデルの選定ではなく、泥臭い「データの前処理・加工」の工程にあります。

本記事では、製造現場特有のコンテキスト（設備特性、生産サイクル、物理法則など）を踏まえ、現場の「ゴミ」と見なされがちな生データを、生産性向上や品質改善に直結する「資産」へと変えるための具体的なアプローチを解説します。

製造業DXにおけるデータ処理の目的：なぜ『分析』より『前処理』が重要なのか

データ分析プロジェクトにおいて、作業時間の実に8割がデータの前処理に費やされると言われています。特に製造業においては、この工程を軽視することがプロジェクト全体の致命傷になり得ます。

Garbage In, Garbage Out：品質の低いデータが招く経営リスク

「Garbage In, Garbage Out（ゴミを入れたら、ゴミが出てくる）」という言葉は、データサイエンスの世界で古くから語り継がれる原則です。どれほど最新のディープラーニングモデルを導入したとしても、入力されるデータに欠損や異常値が含まれていれば、出力される予測結果も信頼できないものになります。

例えば、予知保全AIを構築する際、センサーの故障による「ゼロ」の連続データを正常な稼働データとして学習させてしまうと、実際の設備異常を見逃すリスクが高まります。不適切なデータ処理は、単なる「AIの精度低下」にとどまらず、不要な設備停止や不良品の流出といった経営リスクに直結するのです。

データ処理の3大目的：可視化・予測・最適化

製造現場におけるデータ処理は、最終的に以下の3つのビジネス目的を達成するために行われます。

1. 可視化（Visualization）：現状の稼働状況や品質のバラツキを正確に把握する
2. 予測（Prediction）：設備の故障時期や、製品の品質不良を事前に察知する
3. 最適化（Optimization）：歩留まりを最大化するための最適な加工条件を導き出す

これらの目的を達成するためには、それぞれの用途に合わせた粒度と形式にデータを整える必要があります。単にデータを集めるだけでなく、「何のためにデータを使うのか」というゴールから逆算して前処理の要件を定義することが重要です。

期待されるビジネス効果：歩留まり向上と設備稼働率の改善

適切なデータ処理を経て構築されたAIモデルは、製造原価の低減に直接的に貢献します。品質予測AIによって不良品の発生メカニズムが解明されれば歩留まりが向上し、異常検知AIによって突発的なドカ停（長時間の設備停止）が防げれば設備稼働率が劇的に改善します。データ処理の精度は、そのまま投資対効果（ROI）の最大化に直結すると考えるべきです。

データソースの特定と収集：PLC・センサーからERPまで

データ処理の最初のステップは、工場内に散在する多様なデータソースを正確に把握し、それらを統合可能な形で収集することです。製造現場のデータ統合は、ITシステムのそれとは異なる特有の難しさがあります。

製造現場の多様なデータソース：時系列データとマスターデータ

製造現場のデータは、大きく2種類に分類されます。1つは、PLC（プログラマブルロジックコントローラ）や後付けセンサーからミリ秒・秒単位で出力される「時系列データ（温度、圧力、振動、電流値など）」です。もう1つは、MES（製造実行システム）やERP（統合基幹業務システム）に記録される「マスターデータ・トランザクションデータ（生産計画、ロット情報、作業員シフト、原材料のロット番号など）」です。

AIに「なぜ不良が発生したのか」を学習させるためには、この「センサーの波形データ」と「どのロットの製品を作っていたかという実績データ」を正確に紐付ける（突合する）必要があります。

プロトコルの壁を越える：OPC UAやMQTTによるデータ収集

工場内には、メーカーや年代の異なる設備が混在しており、それぞれが独自の通信プロトコルを使用していることが一般的です。この「プロトコルの壁」を越えるための標準規格として、近年はOPC UAの採用が進んでいます。OPC UAを介することで、異なるPLCのデータを統一されたフォーマットで収集することが可能になります。

また、クラウドへのデータ送信においては、軽量でネットワークの瞬断に強いMQTTプロトコルがよく利用されます。現場のネットワーク環境は必ずしも安定しているとは限らないため、こうした通信レイヤーでの工夫もデータ欠損を防ぐ重要な要素です。

サンプリングレートの設計：適切な時間分解能の決定方法

データを収集する際、「とりあえず取れるだけ細かく取る」というアプローチは推奨されません。データ量が膨大になりすぎ、ストレージコストの増大や処理遅延を招くためです。

例えば、設備の振動データからベアリングの異常を検知したい場合は、数キロヘルツ（1秒間に数千回）という高頻度なサンプリングが必要です。一方で、工場の室温変化を監視するのであれば、1分に1回の取得で十分です。対象となる物理現象の変化スピードに合わせて、適切なサンプリングレートを設計することが、効率的なデータパイプライン構築の第一歩となります。

データクレンジングの実践：現場特有の『ノイズ』をどう除去するか

収集した生データには、必ずと言っていいほどノイズや欠損が含まれています。ここでは、製造現場の物理的特性を考慮したデータクレンジングの手法について解説します。

欠損値の取り扱い：単純削除か、物理モデルに基づく補間か

ネットワークの瞬断やセンサーの再起動により、データが部分的に抜け落ちることは日常茶飯事です。一般的なITデータ分析では、欠損を含む行を「削除（Drop）」するか、前後の「平均値で埋める」といった処理が行われます。

しかし、製造現場の時系列データにおいては、単純な平均値補間は危険です。例えば、加熱炉の温度データが欠損した場合、温度は急激には変化せず連続的に変化するという物理的な制約があります。このような場合は、スプライン補間（曲線を滑らかに繋ぐ数学的手法）や、過去の類似パターンの波形を用いた補間など、物理現象に即したアプローチを選択する必要があります。

異常値・外れ値の検出：統計的手法とドメイン知識の併用

センサーデータには、実際の物理的な異常だけでなく、センサー自体の誤作動による「外れ値」が混入します。例えば、リミットスイッチの接点が物理的に跳ねてオン/オフを繰り返す「チャタリング」現象などです。

これらを除去するために、統計的な外れ値検知（3シグマ法など）を用いるのが基本ですが、それだけでは不十分です。「この配管の圧力が一瞬で10倍になることは物理的にあり得ない」といった、現場のエンジニアが持つドメイン知識（専門知識）をルールとして組み込み、システム的な異常値と設備的な異常値を明確に切り分けることが求められます。

データの重複排除と単位系の統一

複数のシステムからデータを統合する際、タイムゾーンのズレ（UTCとJSTの混在など）により、同じ瞬間のデータが重複して記録されることがあります。また、温度が「摂氏（℃）」と「華氏（℉）」で混在していたり、圧力が「MPa」と「kgf/cm²」で分かれていたりするケースもあります。これらを機械的に処理し、全社で統一された単位系とタイムスタンプに揃える正規化のプロセスは、後段の分析をスムーズに行うための必須条件です。

データ変換・加工：AIが学習しやすい『特徴量』の設計手法

クレンジングされたデータを、そのままAIモデルに入力しても高い精度は得られません。AIがパターンを見つけやすくするために、データを加工して「特徴量（Features）」を生成するプロセスを「特徴量エンジニアリング」と呼びます。

スケーリングと正規化：異なる単位のデータを比較可能にする

モーターの回転数（1000〜3000 rpm）と、モーターの温度（20〜80 ℃）。このようにスケール（桁数）が全く異なるデータをそのままAIに学習させると、数値の大きい回転数の影響力だけが過剰に評価されてしまうアルゴリズムがあります。

これを防ぐために、すべてのデータを「0〜1の範囲に収める（Min-Maxスケーリング）」や、「平均を0、分散を1にする（標準化）」といった処理を行います。これにより、異なる単位のセンサーデータを公平に評価できるようになります。

製造業向け特徴量エンジニアリング：移動平均、FFT、変化率の活用

時系列データから意味のある特徴を抽出するための強力な手法がいくつかあります。

• 移動平均と平滑化：細かいノイズを打ち消し、全体的なトレンド（上昇傾向・下降傾向）を捉えるために使用します。
• FFT（高速フーリエ変換）：波形データを周波数成分に分解する手法です。モーターやベアリングの振動データから「特定の周波数帯のエネルギーが急増した（＝特定の部品が摩耗している）」といった特徴を抽出する際、極めて有効です。
• 変化率（微分値）：温度や圧力の「絶対値」だけでなく、「過去1分間でどれだけ急激に変化したか」という変化の傾き自体を新たな特徴量として追加します。

カテゴリ変数のエンコーディング：設備状態や作業員シフトの数値化

「稼働中 / 待機中 / 停止中」といった設備ステータスや、「A班 / B班」といった作業員シフトの情報は、テキストデータ（カテゴリ変数）であるため、そのままでは数式ベースのAIモデルで計算できません。これらを「稼働中＝1、それ以外＝0」といった形でフラグ化する（One-Hotエンコーディング）ことで、AIが「特定の班の作業時や、特定の製品型番の時に不良率が上がる」といった相関関係を見つけ出せるようになります。

データパイプラインの設計と運用：ETL/ELTの最適解

データ処理のロジックが完成したら、それを自動的に実行し続ける仕組み（データパイプライン）を構築する必要があります。

リアルタイム処理 vs バッチ処理：ユースケース別の使い分け

データパイプラインには、大きく分けて2つのアプローチがあります。

一つは、データを1日1回などのタイミングでまとめて処理する「バッチ処理」です。過去のデータを集計して歩留まりの傾向を分析したり、AIモデルを再学習させたりする用途に適しています。

もう一つは、センサーからデータが届いた瞬間に数秒以内で処理を行う「リアルタイム（ストリーム）処理」です。異常な振動を検知して即座に設備を緊急停止させるような、シビアな予知保全のユースケースではこちらが必須となります。目的に応じて、これらのアプローチを組み合わせたアーキテクチャ（ラムダアーキテクチャなど）を設計することが一般的です。

スケーラビリティを考慮したアーキテクチャ設計

工場内の全設備のデータをクラウドに送信しようとすると、ネットワーク帯域がパンクし、莫大なクラウド通信費用が発生します。これを解決するのが「エッジコンピューティング」です。

PLCのすぐそばにエッジデバイス（産業用PCなど）を配置し、そこでデータの一次フィルタリングやFFT処理（特徴量抽出）を行います。そして、「意味のある特徴量」や「異常と判定された前後の波形データ」だけを圧縮してクラウドに送るという分散処理アーキテクチャを設計することで、スケーラビリティとコストのバランスを最適化できます。

データ処理プロセスの自動化とスケジューリング

ETL（Extract：抽出、Transform：変換、Load：書き出し）のプロセスは、手作業で行うものではありません。専用のデータ統合ツールやオーケストレーションツールを用いて、決められたスケジュールやイベント駆動で自動実行されるように構築します。途中でデータ収集エラーが発生した際のリトライ処理や、担当者へのアラート通知機能も組み込んでおくことが、安定稼働の要となります。

品質管理と継続的改善：『データドリフト』への対策

データ処理パイプラインとAIモデルは、「一度作って終わり」ではありません。製造現場は常に変化しており、その変化に対応し続ける運用体制が必要です。

データ品質の監視指標（DQIs）の設定

システム稼働後も、入力されるデータの品質を常に監視する必要があります。「1時間あたりの欠損値の割合」や「定義された範囲外の異常値が検出された回数」などをデータ品質指標（DQIs）として定義し、ダッシュボードで可視化します。データ品質が一定の閾値を下回った場合は、速やかにセンサーの点検やネットワークの確認を行う運用プロセスを構築します。

環境変化によるデータ特性の変化（ドリフト）を検知する

設備の経年劣化、刃具の摩耗、夏と冬の気温変化、あるいは原材料の供給元変更などにより、正常時のセンサーデータの分布（ベースライン）自体が徐々に変化していく現象を「データドリフト」と呼びます。

AIモデルは「過去のデータ」を基準に学習しているため、データドリフトが発生すると、「正常なのに異常と判定する（過検知）」や「異常なのに見逃す（検知漏れ）」が増加します。定期的にデータの分布変化を統計的に監視し、ドリフトが検知された場合は、最新のデータを用いてAIモデルを再学習（リトレーニング）させる仕組みが不可欠です。

フィードバックループの構築：現場担当者との連携

データ処理とAI運用の精度を高め続けるためには、現場のオペレーターや保全担当者との密な連携が欠かせません。AIが「異常」とアラートを出した際、それが本当に設備の異常だったのか、それとも単なるセンサーの誤検知だったのか。現場からのフィードバックをシステムに入力し、教師データを継続的にアップデートしていく「人間とAIの協調ループ」を作ることが、真のスマートファクトリー化への近道です。

ツール選定と次のステップ：スモールスタートからスケールアップへ

ここまで、製造業におけるデータ処理の技術的なステップを解説してきました。最後に、これらの仕組みを自社に導入していくためのアプローチについて触れておきます。

オープンソース vs 商用ツール：コストと機能の比較

データ処理パイプラインを構築する手段として、Pythonなどのオープンソースソフトウェア（OSS）を用いて自社でゼロからコーディングする方法と、GUIベースで直感的に操作できる商用のデータ統合プラットフォームを導入する方法があります。

OSSはライセンス費用がかからず柔軟性が高い反面、高度なプログラミングスキルを持つ人材の確保と保守の手間が課題となります。一方、商用ツールは初期費用が発生しますが、現場の生産技術エンジニア自身がノーコード・ローコードでデータ加工のロジックを構築・修正できるという大きな利点があります。自社のITリソースと現場のデジタルリテラシーを見極めて選定することが重要です。

製造業特化型プラットフォームの利点

汎用的なIT向けデータツールとは異なり、製造業に特化したIoT・AIプラットフォームも存在します。これらは、OPC UAなどの産業用プロトコルに標準対応していたり、FFTや移動平均といった製造業向けの特徴量抽出ブロックがあらかじめ用意されていたりします。現場のコンテキストを理解したツールを選ぶことで、導入までのリードタイムを大幅に短縮することが可能です。

スモールスタートで成果を出すための優先順位

最も避けるべきは、「全工場の全設備のデータを集める」といった壮大な構想からスタートし、何年も成果が出ないままプロジェクトが頓挫することです。

まずは、ボトルネックとなっている「特定の1ライン」や「歩留まり低下の要因と疑われる1つの工程」にターゲットを絞りましょう。限られたデータソースで前処理からAI分析までの小さなサイクル（PoC）を回し、現場の納得感を得ながら小さな成功体験を積むことが鉄則です。

自社のデータが本当にAI分析に使える状態なのか、どのような前処理が必要なのか。それを確かめるためには、実際に手を動かして検証することが最も確実です。多くのソリューションでは、実際の製品画面を操作できるデモ環境や、期間限定のトライアルが提供されています。まずはこうした環境を活用し、現場の「ゴミ」を「資産」に変える第一歩を踏み出してみてはいかがでしょうか。