設備の電流値がいつもと違う——その違和感を、勘ではなくデータで掴めるようにするにはどうすればよいのでしょうか。この記事では、電力データの異常を「故障予兆」と「無駄な消費」の両面から捉え、何を基準に、何と組み合わせて判断するかを、落とし穴も含めて誠実に整理します。
電気料金の高止まり、省エネ法の定期報告、GX・カーボンニュートラルへの対応——工場の現場には、エネルギーに関する外圧が年々強くなっています。ただ、現場担当者が本当に困っているのは、制度そのものよりもっと手前の実務です。「先月より電気代が上がったが、どの設備が原因か分からない」「あのコンプレッサ、最近うなりが変わった気がするが数字で説明できない」——こうした違和感を、勘ではなくデータで掴みたい、というのが出発点だと考えられます。
設備の電力（電流値）は、単なるコストの指標ではありません。モータやポンプ、コンプレッサ、ヒータといった設備は、ベアリングの劣化・詰まり・エア漏れ・制御異常が起きると、消費電流の挙動が微妙に変わることがあります。つまり電流値は、故障予兆をうかがう「もう一つのセンサー」になりうる情報です。省エネの文脈で語られがちな電力データを、保全（設備の健康状態）の視点で読み直すと、見えてくるものが変わってくると考えます。
ベテランの保全員は、音や振動、温度の変化から異常の兆しを掴んできました。しかし熟練者の退職や多台持ちの進行で、「いつもと違う」に気づける人が現場から減っているのが実情ではないでしょうか。だからこそ、機械の状態を数値で継続的に見張り、逸脱を自動で拾い上げる仕組みへの関心が高まっていると考えられます。本記事では、その第一歩として電流値の異常検知を、故障予兆と異常消費（空運転・待機運転の無駄）の両面から整理します。
「電力異常を検知したい」という言葉には、実は性質の異なる複数の目的が混ざっています。ここを分けて考えないと、後で「何を検知したかったのか分からない」状態に陥りがちです。大きく分けると、(1) 故障予兆——劣化や不具合の前兆としての電流変化、(2) 異常消費——本来止まっていてよい時間帯の待機・空運転や、想定より過大な消費、(3) 突発異常——過負荷・欠相・瞬時のスパイクなど、の三つに整理できると考えられます。
故障予兆は、日～週～月単位のゆっくりした変化を追う話です。ベアリング劣化で摩擦が増えれば負荷電流がじわりと上がる、フィルタが詰まればファンの電流特性が変わる——こうした緩やかなトレンドを掴むには、長期のベースラインが要ります。一方、異常消費は「今この瞬間、本来動いていないはずの設備が電気を食っていないか」という、もっと短い時間軸の話です。段取り待ちや昼休みに待機電力が高いまま、生産していないラインの補機が回りっぱなし、といった無駄はこちらに入ります。
両者は解き方も違います。故障予兆はベースラインからの逸脱と長期トレンドの分析が中心。異常消費は「生産している／していない」という運転状態との紐付けが鍵になります。同じ電流データでも、何と組み合わせて読むかで見える異常が変わる、という点を最初に押さえておくと設計を誤りにくいと考えます。
最も素朴なアプローチは「電流が○○Aを超えたら異常」という固定しきい値です。過負荷保護としては有効ですが、予兆や無駄の検知には力不足なことが多いと考えられます。設備の電流は生産品種・負荷・段取り・外気温で日常的に大きく揺れるため、固定しきい値を厳しくすれば誤報の山、緩くすれば見逃し、というジレンマに陥りがちです。「いつものこの設備の、この運転状態なら、これくらい」という相対的な基準——ベースライン——が必要になる所以です。
異常検知の実務は、突き詰めると「正常な状態をどれだけ丁寧に定義できるか」に尽きると考えます。正常が曖昧なままでは、異常も定義できません。まずは対象設備の電流値を、運転モード（起動・定常・段取り・待機・停止）ごとに層別し、それぞれの通常範囲を描くことから始めるのが現実的です。定常運転時の平均と分布、起動時のピーク波形、待機時のベース消費——これらを数日～数週間ぶん集めるだけでも、「その設備らしい正常」の輪郭が見えてきます。
電力異常の分析で見落とされがちなのが外気温の影響です。コンプレッサや冷凍・空調系、油圧のオイル粘度が関わる設備などは、外気温で消費電流が素直に変わります。夏場に電流が上がったのを「劣化」と誤認したり、逆に冬の低消費で劣化を見逃したり、ということが起こりえます。そこで、電流値を外気温とセットで記録し、温度で補正した上でベースラインと比べる——つまり「同じくらいの気温の日と比べてどうか」を見る発想が有効になりうると考えられます。外気温データは気象データや現場の温度計から補える場合が多く、補正の有無で異常検知の精度感が変わってくると考えます。
補正の方法は難しく考えすぎる必要はありません。まずは外気温を数区分にビン分けし、区分ごとにベースラインを持つだけでも実務的な改善になりえます。より進めれば、外気温を説明変数にした簡単な回帰で「予測消費」を出し、実測との乖離（残差）を異常度として見る、という組み立ても考えられます。いずれにせよ大切なのは、いきなり高度なモデルに飛ばず、まず交絡要因を意識して正常を定義することだと考えます。
異常消費（空運転・待機の無駄）を掴むには、電流データ単独では足りず、「その時間、生産していたのか」という運転状態の情報が要ります。ここで効いてくるのが設備側の信号です。PLCが持つ稼働信号・運転モード・生産カウントと電力データを時刻で突き合わせると、「非稼働なのに電流が高い」という無駄が定量的に見えてきます。この紐付けの具体的な進め方はPLCと電力データの連携で整理しています。電力と設備信号を同じ時間軸に乗せることが、異常消費分析の土台になると考えます。
電流値の逸脱を捉えられても、それが「本当に不具合を意味するのか」は、電力データだけでは分かりません。ここで組み合わせたいのが保全記録です。過去の故障・部品交換・オーバーホールの履歴と、その前後の電流値の推移を突き合わせると、「この設備は、こういう変化が起きると数週間後に○○が壊れやすい」といった、その現場ならではのパターンが見えてくることがあります。故障の事後記録と予兆データをつなぐこの作業が、単なる見える化を「予知保全の入口」に変える鍵になると考えられます。
新しい検知ロジックをいきなり本番で回す前に、過去の故障事例に対して遡って検証する——いわゆるバックテストが有効だと考えます。「この壊れた設備、電流データを振り返ると事前に兆候が出ていたか」を確かめるのです。兆候が出ていたなら、どれくらい前から、どんな特徴で表れたかが、検知ロジックの設計指針になります。逆に、電流には何の変化も無かった故障モードもあるはずで、それは「電力データでは掴めない領域」として正直に線を引くべき部分です。すべてを電流で捉えようとしないことが、かえって信頼できる仕組みにつながると考えます。
保全記録は、多くの現場で紙やExcel、日報の自由記述に散らばっています。これをデータとして扱えるように整えるのは地味に骨の折れる作業ですが、ここを避けて通ると「異常を検知したが、それが何の予兆か誰も判断できない」状態になりがちです。完璧なデータベース化を目指すより、対象設備を絞って、その設備の主要な故障事例だけでも時刻付きで整理する——それだけでも分析の解像度は大きく変わってくると考えられます。
データ上の異常は、最終的に現物で裏を取る必要があります。電流の変化を検知したら、実際に設備を点検し、ベアリングの発熱・振動・エア漏れ・詰まりといった物理的な状態と照らし合わせる。この「データ→現物確認→記録」のループを回すことで、検知ロジックが現場に合ったものへと育っていくと考えます。異常検知は導入して終わりではなく、現物での答え合わせを積み重ねて精度を上げていく運用そのものだと捉えるのが誠実だと考えます。
電流波形からの異常抽出には、AI/機械学習が力を発揮しうる領域があります。起動時の波形パターンの微妙な崩れ、複数チャネルの相関の変化、外気温を加味した予測消費との乖離——こうした人が目で追いにくい特徴を、モデルが継続的に見張るという使い方が考えられます。ただし、これらを実現するには学習に足る正常データと、できれば少数でも異常事例のラベルが要ります。「AIを入れれば勝手に異常を見つけてくれる」わけではない、という点は最初に共有しておくべきだと考えます。
電流データは高頻度・大量になりがちで、全量をクラウドへ上げ続けると通信・保管のコストが膨らみます。また設備データを外部に出すことへの社内的な抵抗もあります。そこで、現場のゲートウェイやエッジ端末側で一次処理し、異常の候補やサマリだけを扱う構成が現実的になりうると考えます。工場内でデータを処理するエッジAIによる工場内データ処理の考え方は、こうしたコスト・セキュリティ・遅延の要件に沿いやすいと考えられます。既存の盤や設備を改造せずに電流を測りたい場合は、既存設備への後付けセンシングのように、後付けのクランプ式センサー等から計測を追加するアプローチも選択肢になります。
異常度スコアが出ても、現場が動けなければ意味がありません。ここでローカルLLMは、「どの設備が、いつから、通常と比べてどう違うか」を保全記録の文脈も踏まえて言葉で要約し、点検の当たりを付けやすくする——といった役割を担いうると考えられます。数値の羅列を現場の判断につなぐ橋渡しです。ただしLLMの説明はあくまで補助であり、故障の断定ではありません。最終判断は現物点検と技術者の知見に委ねる、という原則を崩さないことが、誤った安心や過剰な警戒を避けるうえで重要だと考えます。
異常検知の仕組みは、作った瞬間が最も精度が低いと考えるくらいでちょうどよいと考えます。運用を始めると必ず誤報（正常なのに異常と判定）と見逃しが出ます。大切なのは、それらを記録し、なぜ外したかを振り返り、ベースラインやしきい値、補正の仕方を調整していくことです。この改善ループを回す担当と頻度を決めておかないと、「アラートが多すぎて誰も見なくなる」というよくある失敗に陥りがちです。
検知結果は、受け取る人が次の行動を取れる形になっている必要があります。「異常です」だけでは動けません。「どの設備の、どのモードで、通常比どれくらい、いつから」——ここまで添えて初めて点検の優先順位が付けられます。そして対応した結果（点検して何があったか、対処したか）を必ず記録し、その情報を次の検知ロジックに還元する。異常消費についても同様で、「非稼働時の待機電力が高い」と分かったら、停止手順の見直しや補機の連動停止といった具体的な改善行動に落とし込み、実施前後の消費を比較して効果を確かめる——ここまでやって初めて省エネの成果になりうると考えます。
消費電力の絶対量だけを見ると、生産量が増えた月は「電気を使いすぎ」に見えてしまいます。生産量あたりの消費（エネルギー原単位）で評価すると、生産変動の影響を除いて「効率が悪化したのか」を見やすくなると考えられます。異常消費の改善効果も、原単位で追うと過大にも過小にも見積もりにくくなります。ただし原単位の分母（生産量・稼働時間など）の取り方で結論が変わりうるため、何を分母にするかを設備・工程の実態に合わせて決めることが前提になると考えます。
電力異常検知は有望な一方で、期待だけで進めると必ずどこかでつまずきます。着手前に知っておきたい代表的な落とし穴を挙げます。
これらは避けるべき理由であると同時に、事前に設計へ織り込めば大きなリスクにはなりにくいものです。「やってみないと分からない部分」を正直に見積もり、小さく検証してから広げる姿勢が、結局は近道になると考えます。
最初から全設備・全ラインを対象にすると、データ整備の負担で頓挫しがちです。まずは「異常を掴めたら効果が大きい」設備を1～数台に絞る——たとえば電気代の比重が大きいコンプレッサや、止まると生産影響が大きい基幹設備が候補になります。その設備の電流値を数週間記録し、運転モードごとのベースラインを描き、過去の故障事例があればバックテストで答え合わせをする。この小さなサイクルで「電力データで本当に予兆や無駄が掴めるか」を現物で確かめるのが、確実な第一歩だと考えます。
小規模な検証では、(1) 対象設備の正常なベースラインが安定して描けるか、(2) 外気温・負荷を補正した異常度が現場感覚と合うか、(3) 過去故障や既知の無駄を遡って捉えられるか、(4) 検知結果が現場の点検・改善行動につながる粒度で出せるか——このあたりを見ていくと、横展開の可否と勘所が掴めてくると考えられます。ここで得た知見（どの計測点が要るか、どのデータ紐付けが効くか）が、次の設備や他拠点への展開設計の土台になります。
対象設備を絞った検証の設計は、小規模PoCから始める相談のように、計測点の選び方・データ整備の範囲・評価指標を先に決めてから進めると迷いにくいと考えます。自社の設備で電流の異常検知が成り立つか確かめてみたい、既存設備にどう計測を後付けできるか具体化したい——そうした段階であれば、まずは現状の設備構成と困りごとを持ち寄って相談するところから始めるのが現実的だと考えます。
最後に強調したいのは、電力異常検知のゴールは「グラフが見えること」ではなく「故障を早く掴み、無駄を減らし、その効果を確かめ続けること」だという点です。検知は入口に過ぎず、現物確認・改善行動・効果検証・ロジックの見直しという運用のループを回して初めて、投資が成果に変わっていくと考えられます。元キーエンス画像処理事業部の現場知見と、Jetsonエッジ・設備データ連携・ローカルLLMを組み合わせたエネルギー監視は、その運用を支える一つの選択肢になりうると考えます。まずは一台、いつもの電流を丁寧に見るところから始めてみてはいかがでしょうか。
過負荷保護には固定しきい値も有効ですが、故障予兆や異常消費の検知では不足しがちだと考えられます。電流は品種・負荷・外気温・段取りで日常的に揺れるため、固定値では誤報か見逃しに偏りやすいためです。運転モードごとのベースラインとの比較や外気温補正を組み合わせ、「いつものこの状態と比べてどうか」を見る発想が現実的だと考えます。
コンプレッサや冷凍・空調系、油圧など多くの設備は外気温で消費電流が変わるため、補正しないと季節変動を故障予兆と誤認したり、逆に見逃したりしうるからです。外気温を数区分に分けて区分ごとのベースラインを持つ、あるいは温度を説明変数にした簡単な予測との乖離を見る、といった方法が考えられます。まずは交絡要因を意識して正常を定義することが出発点だと考えます。
過去の故障・部品交換の履歴と、その前後の電流推移を突き合わせると、その現場特有の予兆パターンが見えてくることがあります。新ロジックはいきなり本番投入せず、過去の故障事例に遡って検証（バックテスト）し、兆候が出ていたかを確かめると設計指針が得られます。電流に表れない故障モードもあるため、掴める範囲を正直に線引きすることも重要だと考えます。
完全な自動化を期待しすぎないほうがよいと考えます。AIは波形の微妙な崩れや予測消費との乖離を見張る補助になりうる一方、学習に足る正常データや異常事例が要ります。LLMは異常の要約や点検の当たり付けに役立ちますが、故障の断定ではありません。最終判断は現物点検と技術者の知見に委ねる前提で、あくまで支援として位置づけるのが現実的だと考えます。
制度対応そのものは報告や算定が中心で、異常検知が直接の義務というわけではありません。ただ、待機・空運転の無駄を掴んで原単位を改善する取り組みは、結果的に省エネやコスト低減につながりうると考えます。省エネ法の報告義務の範囲や算定方法、具体的な数値は制度で定められており、適用範囲は所管省庁の最新の公表資料でご確認ください。
全ラインを一度に対象にする必要はありません。まずは効果の大きい一台に絞り、いつもの電流を数週間記録して、過去の故障や無駄を遡って掴めるかを現物で確かめるところから始めるのが確実だと考えます。計測点の選び方やデータ紐付けの設計から、ご一緒に検討します。
電力異常検知のPoCについて相談する