電力メーターは「工場全体で何kWh使ったか」しか教えてくれません。一方でPLCやSCADAは、いつどの設備がどんな稼働状態にあったかを既に握っています。この両者をどう突き合わせれば、電気代を設備・製品・工程の単位で語れるようになるのか。既存の制御データを起点に、連携の構成と紐付け設計の考え方を整理します。
電気料金の高止まり、省エネ法の定期報告、取引先からのCO2算定の要請——工場や物流拠点の現場担当者に、エネルギーを「数字で説明する」責任が急速に集まっています。ところが実際に手元にあるのは、多くの場合、受電点の総電力量だけです。月末に届く請求書と、せいぜい工場全体のデマンド値。ここから「どの設備が」「どの製品を作るときに」「稼働中と待機中で」どれだけ電気を使ったのかを答えるのは、原理的に不可能です。
一方で、多くの工場には既に稼働情報を握っている資産があります。PLC(プログラマブルロジックコントローラ)とSCADA(監視制御システム)です。設備がいつ運転し、いつ停止し、何個作り、どのレシピ・段取りで動いていたか——これらは制御のために既に取得され、蓄積されています。つまり「エネルギーの数字」と「現場で何が起きていたか」は、別々の場所にすでに存在していて、突き合わされていないだけ、という状況が少なくありません。
背景には二つの流れがあります。ひとつは電力コストの構造的な上昇と、GX・カーボンニュートラルという制度的・経営的な要請です(制度の適用範囲や報告義務の閾値は所管省庁の最新の公表資料でご確認ください)。もうひとつは人手不足で、検針や集計を手作業で回す余裕が現場から失われていることです。新たに全設備へ電力計を後付けし、さらに人がExcelで集計する——という増設一辺倒のやり方は、コストと工数の両面で続けにくくなっています。だからこそ「既にあるPLC/SCADAのデータを活かす」という発想が、現実的な選択肢として浮かび上がってきていると考えられます。
連携の設計に入る前に、目的を言語化しておく必要があります。同じ「電力とPLCをつなぐ」でも、狙いによって集めるべきデータの粒度も、精度への要求もまったく変わるからです。ここを曖昧にしたまま機器を選ぶと、後から「この分析には粒度が足りない」と手戻りになりがちです。
製品1個あたりのkWhなのか、ライン1時間あたりなのか、設備1台の稼働状態別なのか。原単位の分母をどこに置くかで、必要な生産データ(良品数か投入数か、工程単位か製品単位か)が決まります。原単位は歩留まりと切り離せないため、不良を作るのに使った電気まで含めて評価したいなら、品質データも視野に入ります。この観点は電力・生産・品質データ統合の考え方と地続きです。
「月次で拠点間を比較したい」なら分単位の細かさは不要かもしれません。しかし「設備の異常予兆を電流波形から捉えたい」「待機電力を切り分けたい」なら、秒単位やそれ以下のサンプリングと、設備の稼働ON/OFFとの正確な時刻同期が要ります。目的が粗ければ既存のSCADAのトレンドログで足りることもあり、細かい異常検知を狙うほど専用の電力計測とエッジ側の高頻度取得が必要になると考えられます。
生産データや稼働情報は、そのまま外部クラウドへ送ることに社内の情報システム部門や取引先が難色を示す場合があります。どこで前処理し、どこに集約し、何を外に出すのか。この線引きは技術要件であると同時にセキュリティ・ガバナンスの問題でもあり、後述する連携構成の選択に直結します。
既存の制御データと電力を突き合わせる構成には、大きく分けて三つの取り出し口があります。現場の設備世代や通信環境によって、どれが現実的かは変わります。
比較的新しいSCADAや上位のPLCは、OPC UAをはじめとする標準的な産業通信プロトコルに対応していることがあります。この場合、稼働状態・生産数・アラームなどをタグ単位で読み出し、電力計測側のデータと同じ基盤に集約する構成が組みやすくなります。ベンダー依存が少なく、タグに意味(単位・工程)を持たせやすいのが利点です。ただし全ての現場が対応しているわけではなく、既存資産の対応状況の確認が起点になります。
標準プロトコルを持たない世代のPLCでも、各社のプロトコル(シリアルやEthernet経由)でデバイス/レジスタを直接読みに行けることが多くあります。稼働接点や生産カウンタのアドレスを特定し、周期的に読み出して電力データと突き合わせる構成です。設備を改造せず既存の配線を活かせる反面、アドレスマップの解読と、読み出しが制御周期に影響しないかの確認が必要になります。この直接連携の考え方はPLCと電力データの連携で扱う紐付けと共通します。
PLCに手を入れにくい場合、電力側をクランプ式電流センサーなどで独立に計測し、PLC/SCADAの稼働ログとはタイムスタンプで後から結合する構成も現実的です。制御系に影響を与えないため導入のハードルが低く、まず1台で試すのに向きます。ここで肝になるのが両系統の時刻同期で、時計がずれていると「稼働ONの瞬間の消費電力」がずれて紐付き、分析が成り立たなくなります。
いずれのアプローチでも、収集・前処理・突き合わせを工場内で完結させたい場合は、現場に置いたエッジ側で処理する構成が有力です。エッジAIによる工場内データ処理のように、生データを外に出さずに原単位や異常判定まで現場で計算し、必要な集計値だけを上位に上げる形が、セキュリティと通信負荷の両面で扱いやすいと考えられます。
連携で最も差が出るのは、機器の選定よりもデータの紐付け設計です。同じ電力値と稼働値でも、揃え方を誤ると「集めたのに使えない」データになります。ここでは分析に耐える紐付けの勘所を整理します。
電力データとPLCの稼働データは、別々の機器が別々の時計で記録しています。この時計を揃えないと、稼働ONの瞬間と消費電力の立ち上がりが紐付きません。NTPなどで各機器の時刻源を統一し、可能なら定期的にずれを監視する仕組みを持たせることが望ましいと考えられます。特にアプローチC(別系統計測)では、時刻同期の甘さがそのまま分析精度の限界になります。
「D100」「M5」といった生のアドレスのまま貯めても、後から見た人には何のことか分かりません。設備名・工程・信号の意味・単位を対応づけたタグ辞書(名寄せ表)を最初に作り、収集時点で意味のある名前に変換しておくことが、運用を長く続ける鍵になります。設備更新や増設のたびにこの辞書を更新できる体制があるかどうかが、データ品質の分かれ目です。
月次の拠点比較なら分〜時間単位で足りることもありますが、待機電力の切り分けや異常波形の検知を狙うなら秒単位以下が要ります。周期を細かくすればデータ量と保存コストが増えるため、「何を判断したいか」から逆算して粒度を決めるのが現実的です。迷ったら、対象を絞って一時的に高頻度で取り、実際に見たいものが見えるか確かめてから本設計に落とす進め方が安全だと考えます。
「稼働中」「待機中」「段取り中」「停止」の境界は、PLCの接点だけでは一意に決まらないことがあります。段取り中を待機に含めるか、微速運転をどう扱うか——この定義を現場の実態と擦り合わせないと、算出した待機電力が実感とずれ、改善提案の説得力を失います。データ設計は現場ヒアリングと一体だと捉えるのが誠実だと考えられます。
データが紐付いても、グラフを眺めるだけでは電気代は下がりません。連携の価値は、そこから改善行動を起こし、効果を数字で確かめ、運用として回し続けられるかにかかっています。
稼働データと電力を突き合わせると、最初に見えてくることの多いのが待機電力です。生産していない時間帯・休日・昼休みに、設備が停止しているはずなのに電力が落ちきっていない——こうした「無駄の輪郭」は、電力単独では見えず、稼働状態と重ねて初めて浮かびます。ここは制御設定やタイマー、運用ルールの見直しで比較的着手しやすい領域だと考えられます。
生産数で割った原単位にすると、生産量の増減に左右されずに効率そのものを比べられます。「先月より電気を使ったが、たくさん作ったからか、効率が落ちたからか」を切り分けられるのが原単位の力です。ただし製品構成や外気温、稼働率が違えば単純比較はできないため、条件を揃えた比較設計が前提になる点は正直に押さえておく必要があります。
改善策を打った後は、同じ紐付けデータで前後比較して効果を検証します。ここで貯まった電力×稼働×生産の時系列は、異常予兆の検知やレポート作成の自動化といったAI活用の素地にもなります。たとえば稼働状態ごとの正常な電力波形を学習させ、逸脱を早期に知らせる、あるいは日々の集計と気づきをローカルLLMで下書きさせ、報告負担を軽くする——といった使い方が考えられます。いずれも「まず正しく紐付いたデータがある」ことが前提で、AIは連携の代わりにはならない点は強調しておきたいところです。
PLC/SCADAと電力の連携は、原理はシンプルでも実装で足をすくわれがちです。事前に知っておきたい落とし穴を挙げます。
そして最も正直に伝えるべきは、これらの多くは「やってみないと分からない」ということです。既存PLCの型番、SCADAのバージョン、配線の余裕、時計の精度、稼働定義の実態——これらは資料だけでは確定せず、現物で確かめて初めて構成が固まります。だからこそ、いきなり全ラインの本設計に進むより、小さく試す進め方が結果的に近道になると考えられます。
最後に、無理のない進め方を段階で整理します。前提は「小さく始め、現物で確かめてから広げる」ことです。
「拠点比較」「待機電力削減」「異常予兆」など目的を一つに定め、電気を多く使う・変動が大きい・改善余地が見込めそうな設備を1台か1ラインだけ選びます。ここで論点(原単位の分母・必要粒度・データを外に出すか)を紙一枚に落とします。
対象PLC/SCADAの型番・通信対応(OPC UAの可否など)・取得できるタグ・時刻同期の状況を確認します。ここで、標準プロトコルで上位から取れるのか、レジスタ直読みなのか、電力を別系統で計測して後結合するのか——現物に即して連携アプローチが見えてきます。
選んだ1台で電力と稼働データを実際に紐付け、待機電力や異常波形が「見たい形で見えるか」を確認します。ここで粒度・時刻同期・稼働定義の妥当性を検証し、本設計に反映します。対象を絞った検証設計は小規模PoCから始める相談の形で、失敗コストを抑えながら進められると考えます。
1台で紐付けと改善のサイクルが回ることを確認できたら、タグ辞書と収集構成を型として他ラインへ広げます。ここで初めてレポート自動化やAIによる異常検知といった発展に投資する順番が、遠回りに見えて堅実だと考えられます。自社のPLC/SCADA構成で何がどこまでできるか迷う場合は、現状を持ち寄って相談するところから始めていただくのがよいと考えます。
多くの場合、各社独自のプロトコルでレジスタを直接読み出す方法や、電力を別系統で計測して稼働ログとタイムスタンプで後結合する方法が取れると考えられます。ただし読み出し方法や頻度が制御に影響しないかは事前確認が必要です。対応可否は既存PLCの型番と通信環境を現物で確かめることが出発点になります。
時刻同期の甘さが最もつまずきやすい点と考えられます。電力とPLCが別々の時計で記録していると、稼働の瞬間と消費電力が正しく紐付かず、算出した待機電力などが実感とずれます。NTPなどで時刻源を揃え、ずれを監視する仕組みを持たせることが、分析に耐えるデータの土台になります。
制度上の報告は総量ベースでも成立する場合がありますが、どこに無駄があり何を改善すべきかを知るには、設備・工程単位の原単位が有効と考えられます。省エネ法やGX関連の報告義務・閾値・算定方法は変わりうるため、適用範囲は所管省庁の最新の公表資料でご確認ください。
必須ではありません。生産・稼働データを外部に出すことに社内や取引先が慎重な場合、現場のエッジ側で原単位や異常判定まで計算し、必要な集計値だけ上位に上げる構成も現実的と考えられます。どこまで工場内で処理するかは、セキュリティと通信負荷の両面から先に決めておくのが安全です。
最初から全ラインをつなぐ必要はなく、電気を多く使う設備や変動の大きい設備を1台選んで試す進め方が現実的と考えます。1台で電力と稼働を突き合わせ、待機電力や異常波形が見たい形で見えるかを現物で確認してから、型として横展開する順番が、結果的に失敗コストを抑えられると考えられます。
自社の制御データと電力が本当に紐付くかは、型番と現場を見て初めて分かる部分が多くあります。まずは電気を多く使う1台を対象に、待機電力や原単位が見える形になるかを現物で確かめるところから始められます。
PLC・電力データ連携について相談する