電力量計を付けても「この山は何だったのか」が分からないまま眠っているデータは少なくありません。PLCが持つ稼働状態・生産数・品種・サイクルタイムと、電力データを時刻でつなぐと、初めて消費電力が「意味のある一本の線」になります。本記事では、その連携をどう設計し、どこでつまずくのかを現場目線で解きほぐします。
電気料金の高止まり、省エネ法の定期報告、そしてカーボンニュートラルへの取引先からの要請──こうした外圧を受けて、多くの工場や物流拠点が「まず電力を測ろう」と分電盤やブレーカーにCT（電流センサ）や電力量計を取り付けます。これは正しい第一歩です。ところが実際にデータが溜まり始めると、次の壁に必ずぶつかります。「この時間帯の電力の山は、稼働だったのか、それとも空調や待機だったのか」「昨日より消費が多いのは、生産量が多かったからか、無駄が増えたからか」。電力の値そのものは正確でも、それが何を意味するのかを説明できないのです。
背景には、電力データが本質的に「結果」の指標である、という構造があります。消費電力は設備が何をしていたかの結果として表れますが、電力の数字だけを眺めても「何をしていたか」という原因側の情報が欠けています。原因が分からなければ、改善の打ち手も立てられません。省エネ活動が「気合いで消灯」「なんとなく設定温度を上げる」といった精神論に流れがちなのは、多くの場合このデータの片肺状態が根っこにあると考えられます。
電力の可視化ダッシュボードを導入した現場でよく聞くのが、「最初の1か月は皆が見たが、そのうち誰も見なくなった」という声です。理由は明快で、グラフを見ても行動に変換できないからです。生産量が変動する製造現場では、電力の絶対量が増減するのは当たり前で、それが良い増減なのか悪い増減なのかを判定する物差しがありません。この物差しこそが、生産数で割った設備別電力の可視化から一歩進んだ「原単位（エネルギー原単位）」であり、その算出にはPLCが持つ生産実績が不可欠になります。
多くの生産設備・搬送設備は、その動作をPLC（プログラマブルロジックコントローラ）で制御しています。PLCの内部レジスタやデバイスメモリには、現場が欲しかった「文脈情報」が実はほとんど揃っています。ここを電力データと突き合わせることが、本記事の核心です。まずPLCから何が取れるのかを、電力と紐付ける価値の高い順に整理します。
第一に設備ステータスです。運転／停止／段取り替え中／異常停止（アラーム）／待機、といった状態を表すビットやワードは、電力の山が「生産による山」なのか「アイドルや待機による山」なのかを切り分ける最重要情報です。第二に生産数（良品数・総数）。原単位＝消費電力÷生産数を成立させる分母であり、これが無いと原単位は計算できません。第三に品種・製番・レシピ番号。同じ設備でも品種によって消費電力は大きく変わりうるため、拠点間・ライン間比較や品種別原単位を出すうえで欠かせません。
さらにサイクルタイム／タクト、主要モータの回転数や負荷率、温調ゾーンの設定温度・実温度、アラームコードなども取得できると、消費電力の変動要因をより深く説明できるようになります。ただし欲張って全レジスタを集めると後段の設計が破綻しがちなので、「電力を説明するために本当に要る信号は何か」という視点で絞り込むのが実務のコツだと考えます。
見落とされがちなのが、PLCが制御している範囲と、電力を測っている範囲が一致しているか、という点です。分電盤の1系統に複数設備がぶら下がっていると、PLCのステータスと電力が1対1に対応しません。既存の配電を変えずに設備単位で測りたい場合は、既存設備への後付けセンシングのように、対象設備の一次側にクランプ式CTを追加して計測点をPLCの制御単位に合わせる、といった設計が現実的な落としどころになりうると考えます。
PLCと電力データを紐付ける構成は、大きく三つの型に整理できます。どれが正解ということはなく、既存設備の年式・通信仕様・セキュリティ要件・拠点数によって選ぶことになります。
エッジのゲートウェイ（産業用PCやJetson等）が、PLCから通信でステータス・生産数を読み、同時に電力計からもデータを取り込み、同じ時刻軸で1本のテーブルに書き込む型です。時刻同期の主導権を1台のエッジが握れるため、後述の時刻ズレ問題を抑えやすいのが利点です。PLCの通信仕様（後述）に対応したドライバが必要になります。工場内でデータを完結させ外部にそのまま出さない設計とも相性がよく、エッジAIによる工場内データ処理のように現場側で前処理・紐付けまで済ませてから上位へ渡す構成が取りやすいと考えます。
既にSCADAやライン管理システムでPLCデータを収集済みの場合、その履歴DBと電力データを後からキー（時刻・設備ID）で結合する型です。既存資産を活かせますが、両系統のサンプリング周期や時刻源が異なることが多く、結合時のズレ吸収に手間がかかりやすい傾向があります。
PLCへの通信接続がセキュリティ上・保守契約上むずかしい設備では、稼働ランプやシグナルタワーの点灯、接点出力（無電圧接点）を後付けセンサで拾い、「運転／停止」の二値だけでも電力と紐付ける割り切りが有効なことがあります。品種や生産数までは取れませんが、「待機電力の山」を切り分けるだけでも改善余地は見えてくる場合があると考えます。まず何が取れるかは設備ごとに現物確認が要ります。
PLC連携でもっとも軽視され、そしてもっとも結果を狂わせるのが時刻同期です。原単位や品種別分析は「同じ瞬間の電力と設備状態を突き合わせる」ことで成り立ちますが、現場では複数の時計が微妙にずれています。PLC内蔵時計、電力計の時計、収集サーバの時計──これらが数秒〜数分ずれていることは珍しくなく、サイクルタイムが数秒〜十数秒の高速ラインでは、この程度のズレでも「どの品種のときの電力か」がまるごと入れ替わってしまいうるのです。
対策の基本は、時刻源をできるだけ一本化することです。工場内にNTPサーバ（あるいはGPS基準の時刻源）を置き、収集エッジ・電力計・PLCを可能な範囲で同じ時刻に合わせるのが王道です。ただしPLCの機種によってはNTP同期に対応しない、あるいは時刻の分解能が秒単位までしかない、といった制約があります。その場合は、型Aのように「電力とPLCを同じエッジが同時刻に読み取る」構成にして、エッジの単一クロックを基準にすることで、機器間の時計ズレそのものを回避する設計が有効だと考えます。
PLCの通信仕様はメーカー・機種によって様々で、産業用イーサネット系のプロトコルや、シリアル系のプロトコル、OPC UAのような標準化されたインタフェースまで幅があります。同じ「PLCから読む」でも、対応ドライバの有無・読み取り周期の上限・同時接続数の制限が異なります。設計初期に、対象PLCの型式と通信オプションの有無、そして「1秒に何回まで安定して読めるか」を現物で確認しておくと、後段のサンプリング設計で破綻しにくくなります。省エネ法など制度側が求めるデータ粒度・報告様式は所管省庁の最新の公表資料でご確認いただく前提で、そこから逆算して必要な計測周期を決めるのが安全だと考えます。
電力は1秒周期、PLCステータスは変化点のみ、生産数はワーク完成のたびにインクリメント──というように、データによって「意味のある粒度」が違います。全部を最短周期で取ると通信もストレージも圧迫するため、電力は連続サンプリング、状態や品種は「変わった瞬間のイベント」として記録し、後で時刻で結合する、というハイブリッド設計が実務的だと考えます。
データが時刻でつながると、ようやく分析が意味を持ちます。設備ステータスで区間を「生産中／段取り中／待機中／停止中」に分け、それぞれの区間の消費電力量を積算すれば、「電気代のうち、実際の生産に使われたのはどれだけで、待機や段取りに消えたのはどれだけか」が見えてきます。ここで待機・アイドルの割合が想像以上に大きいと分かる現場は少なくないと考えられます。
生産数を分母に置いた原単位（生産1個あたりkWh）を品種別・時間帯別に出せば、電力の絶対量が生産量に連動して増減するノイズを取り除けます。「今日は電力が多かったが、生産も多かったので原単位はむしろ改善」といった、絶対量だけでは見えない評価が可能になります。原単位を品種横断・拠点横断で並べれば、どのラインの、どの品種の、どの状態が改善余地を持つのかという優先順位づけができるようになると考えます。
見える化はゴールではなく起点です。「待機電力が大きい設備の主電源運用を見直す」「段取り替え時の空運転を減らす」といった打ち手を実施したら、同じ品種・同じ条件で改善前後の原単位を比較し、効果を数字で確認する。これを回してこそ、データ整備の投資が回収に向かいます。そして分析の負担を下げる手段として、蓄積した電力×ステータスのデータをローカルLLMに読ませ、「先週と比べて原単位が悪化した設備と、その時間帯の状態遷移」を日本語で要約させる、といった支援も現実味を帯びてきています。ただしLLMの出力は仮説であり、必ず現物データに立ち返って裏取りする運用が前提だと考えます。報告書作成の下書き支援としても、現場の報告負担を軽くしうると考えます。
PLC×電力連携は「つないで終わり」ではありません。実運用で足をすくわれやすいポイントを、正直に挙げておきます。
これらはいずれも、机上の設計だけでは潰しきれず、「実際につないでデータを見て初めて分かる」性質のものです。だからこそ、最初から全社展開を狙うより、限定した範囲で確かめてから広げる進め方が、結果的に近道になると考えます。
現実的な進め方は、対象を絞った検証から始めることだと考えます。最初のステップは、電力消費が大きい主要設備を1〜数台選び、その設備のPLCから「運転／停止・生産数・品種」の三点だけでも取得し、電力データと時刻同期で紐付けて、波形と状態が本当に一致するかを目視で確認することです。ここで一致しないなら、時刻ズレか計測点の不一致か通信周期のどれかに原因があり、それを潰す作業自体が本番展開の設計図になります。
次に、その1台で待機・段取りの電力割合や品種別原単位を実際に算出し、「この分析は改善判断に使えるか」を現場の担当者と一緒に評価します。使える手応えが得られてから、同種設備・他ライン・他拠点へ横展開する。この順序なら、投資を小分けにしながら、各段階で引き返す判断もできます。小規模PoCから始める相談のように対象設備を絞った検証設計から入るのが、費用対効果を見極めるうえで堅実だと考えます。
Nsightは、元キーエンス画像処理事業部の現場知見をベースに、VLM・Jetsonエッジ・産業用カメラ・現場ライティングに加え、PLC/センサー/IoT連携を組み合わせて、設備データと電力を工場内で紐付ける構成の検証を支援しています。自社の設備で「電力とステータスが本当につながるのか」を確かめたい段階の方は、まず相談するところから、現物での小さな検証を設計していけると考えます。
電力量計は正確な第一歩ですが、電力の値だけでは稼働中か待機中か、どの品種を流していたかが判別できず、増減が良いのか悪いのか評価しづらい傾向があります。PLCの設備ステータスや生産数と紐付けて原単位で見ることで、初めて改善対象を絞り込めるようになると考えられます。まずは主要設備1台での現物確認から始めるのが堅実だと考えます。
優先度が高いのは、運転／停止／段取り中などの設備ステータス、良品数や総数といった生産数、そして品種・レシピ番号です。この三点があれば待機電力の切り分けと品種別原単位の算出が可能になりうると考えます。加えてサイクルタイムやアラームコードがあると変動要因の説明力が上がりますが、欲張らず必要な信号に絞るのが実務的です。
原単位や品種別分析は同じ瞬間の電力と設備状態を突き合わせて成立するため、数秒のズレでも高速ラインではどの品種の電力かが入れ替わりうると考えられます。対策として工場内NTP等で時刻源を一本化するか、電力とPLCを同一エッジが同時刻に読み取る構成にしてクロックを一つに寄せる設計が有効だと考えます。
通信接続が保守契約やセキュリティ上むずかしい場合でも、稼働ランプやシグナルタワー、無電圧接点を後付けセンサで拾い、運転／停止の二値だけでも電力と紐付けられることがあります。品種や生産数までは取れませんが、待機電力の切り分けだけでも改善余地は見えうると考えます。何が取れるかは設備ごとの現物確認が前提です。
必要なデータ粒度や報告様式は制度側で定められており、その具体的な数値・適用範囲は所管省庁の最新の公表資料でご確認いただく前提となります。実務では、そこで求められる粒度から逆算して電力の計測周期やPLCの読み取り設計を決めると、後で作り直しになりにくいと考えます。まず何が求められているかの確認から始めるのが安全です。
電力データにPLCの設備ステータス・生産数・品種を紐付ければ、消費電力は改善判断に使える一本の線になりうると考えます。まずは主要設備を1〜数台に絞り、現物のデータで波形と状態が一致するかを確かめるところから設計していけます。
設備データ連携のPoCについて相談する