電力量計やセンサーを付けてグラフは増えたのに、「で、何が問題なの？」に誰も答えられない。分析できる人がいない現場で、データをどう改善行動につなげるか。AIに要因候補の整理を任せ、人が判断する現実的な運用を考えます。
電力コストの高騰、省エネ法の定期報告、取引先からのCO2算定要請——ここ数年で「工場のエネルギーを数字で把握しなければ」という圧力は確実に強まりました。その結果、多くの現場が電力量計やクランプメーター、簡易な計測ゲートウェイを導入し、ダッシュボードにグラフが並ぶところまでは到達しています。ところが、その先で足が止まる。「グラフは増えたが、で、何が問題で、明日から何を変えればいいのか」に、誰も答えられないのです。
これは怠慢ではありません。設備の電力波形を見て「この山は段取り替えの空焚きか、それとも別ラインの起動か」を切り分け、生産量や外気温、稼働シフトと突き合わせて要因を絞り込む作業は、それ自体が専門技能です。製造・保全の担当者は日々の生産で手一杯で、腰を据えてデータと向き合う時間はまず取れません。かといって、データ分析を専任でこなせる人材は採用市場でも希少で、中小規模の現場に配置できるケースは限られると考えられます。
ダッシュボード製品の営業トークは「見える化」で止まりがちです。しかし見える化はスタート地点であって、ゴールではありません。可視化されたグラフから示唆を引き出し、仮説を立て、現場で確認し、改善を打ち、効果を検証する——この一連のサイクルを回して初めて電気代は動きます。ツールが提供するのは前半の「見せる」部分だけで、後半の「読む・決める・確かめる」部分は依然として人の仕事として残る。ここに人材ギャップが生じているのが実態だと考えられます。
分析人材がいない現場で起きていることを、もう少し細かく分解してみます。「データが読めない」と一括りにされがちですが、実際には性質の違う複数の詰まりが重なっています。ここを切り分けないと、「もっと高機能なBIツールを入れる」といった見当違いの投資に向かいがちです。
第一に「読み取りの層」。グラフを見ても、どこが正常でどこが異常かの基準が頭に入っていないため、山や谷が目に入っても意味を結ばない。第二に「要因分解の層」。異常らしきものに気づいても、それが生産変動なのか、設備劣化なのか、空調や外気温の影響なのかを切り分けられない。第三に「言語化・報告の層」。仮に原因の当たりが付いても、それを上長や経営に伝わる文章にまとめる作業が重く、後回しになる。この3層はそれぞれ必要なスキルが異なります。
重要なのは、この3層はいずれも「ゼロから人が生み出す」必要はない、という点です。読み取りの基準は過去データからある程度自動で引ける。要因分解は候補の列挙まではパターン化できる。報告文の骨子は下書きを機械に作らせられる。つまり、人にしかできない「最終判断」を残しつつ、その手前の重労働をAIに肩代わりさせる余地が、この3層のそれぞれに存在すると考えられます。
分析人材の不足を補うと言うと、「AIに全部やらせる」という発想に飛びがちですが、それは危険です。現場の文脈——今日は特定の大口ロットを流していた、あの設備は先週ベアリングを替えたばかり、この谷はメンテのための計画停止——を知っているのは現場の人だけで、その文脈なしに数字だけ見た判断は的を外します。AIに任せるべきは候補出しと下書きという「作業」であり、どれが本当の原因かを決める「判断」は人に残す。この線引きが、以降の設計すべての前提になります。
分析人材の代わりに、LLM（大規模言語モデル）を「要因の当たりを付ける下書き役」として使う——これが現実的なアプローチの一つだと考えます。具体的には、電力・生産・環境のデータをLLMに渡し、次の3種類のアウトプットを生成させ、それを現場の人がレビューして確定する流れです。詳しい仕組みはエネルギーデータのLLM分析でも整理していますが、ここでは分析人材がいない現場という文脈に絞って述べます。
「昨日の圧縮機の電力が前週同曜日比で高かった。考えられる要因は次の通り」といった形で、LLMに候補を列挙させます。エア漏れの増加、生産量増、外気温上昇による負荷増、段取り替え時の空運転、といった候補を、関連データ（生産数量・気温・稼働時間）と突き合わせて優先順位を付けた形で出させる。人はゼロから原因を考える必要がなくなり、「この候補は違う、これはありそう」と選別する作業から入れます。要因分解の層の負担が大きく軽くなると考えられます。
毎朝、前日のデータについて「注目すべき点」を数行のコメントにして出す運用です。全設備のグラフを人が眺めるのは非現実的なので、異常度の高い設備を優先して提示させる。この考え方は日次エネルギーレポートをAIでで詳しく扱っていますが、要は「今日どこを見ればいいか」をAIが絞ってくれるので、読み取りの層で迷子にならずに済みます。
月次の省エネ報告、経営向けサマリー、取引先向けの説明資料——こうした文書の骨子をLLMに下書きさせ、人が事実を確認して仕上げる。言語化・報告の層は「白紙から書く」のが一番重いので、下書きがあるだけで着手のハードルが劇的に下がります。ただし数値や実績の記述は必ず人が原データと照合する前提です。生成された文章の数字を鵜呑みにしないことが鉄則になります。
LLMに要因整理をさせると言っても、電力データだけを渡しても「電気代が高い理由」は分かりません。要因を切り分けるには、電力に対して「何と紐付けるか」の設計が要になります。最低限、生産量（何をどれだけ作ったか）、時間軸（シフト・稼働/非稼働）、環境（外気温・季節）の3種類を、設備単位・時間単位で突き合わせられる形にしておくことが出発点だと考えられます。
生産量が違う日どうしを電力量の絶対値で比べても「たくさん作ったから電気を使った」で終わり、改善の示唆は得られません。そこで製品1個あたり、あるいは生産金額あたりの電力量——エネルギー原単位——に換算して比べる考え方が有効になります。原単位で見ると、生産量の増減を打ち消したうえで「同じものを作るのに使うエネルギーが悪化していないか」を追える。AIに要因を整理させる際も、原単位という共通のものさしがあると候補出しの精度が上がると考えられます。ただし原単位の取り方（分母に何を置くか）は現場の実態に合わせる必要があり、ここは現物での検証が前提です。
電力波形やセンサーデータは量が多く、すべてをクラウドに送るのは通信・コストの負担になりがちです。設備近くのエッジ機器（Jetson等）で異常度の判定や集計を済ませ、要点だけを扱う設計にすると運用が軽くなる。また、生産データや設備の稼働情報は社外に出したくないという事情も多い。その場合、ローカルLLMを現場・社内に置いて要因整理や下書き生成を回す構成が候補になります。元キーエンス画像処理事業部の現場知見を持つ立場から言えば、産業用カメラによる設備状態の把握とセンサーデータを組み合わせると、電力だけでは見えない「設備が止まっているのに電気を食っている」といった状況の切り分けにも踏み込める可能性があります。
仕組みを作っても、日々回らなければ意味がありません。分析人材がいない現場で持続させる鍵は、「人の作業を増やさない」ことです。AI支援は、人の負担を減らすために入れるのであって、AIの出力チェックのために新たな残業が発生するようでは本末転倒です。
現実的な運用は、朝礼前後の5分程度で、AIが前日について出した「注目すべき設備と要因候補」に目を通し、当たっていれば承認、外れていれば一言修正する、という軽いレビューです。全データを人が見るのではなく、AIが絞った数件だけを見る。ここで大事なのは、外れた指摘に対して「なぜ違うのか」を短くフィードバックする文化で、これが積み重なるとAIの当たりが現場の実態に寄っていくと考えられます。人の暗黙知が少しずつ仕組みに移っていくイメージです。
要因候補が絞れたら、次は打ち手です。待機電力なら停止手順の見直し、エア漏れなら配管点検、段取り時の空運転ならシーケンスの調整。打った後は、同じ原単位で「本当に下がったか」を追う。ここでもAIに「対策前後で原単位がどう変化したか」の要約を出させると、効果検証の報告が軽くなります。見える化で終わらせず、改善→検証→標準化のループを回すこと。AI支援は、このループのうち人が疲弊しやすい「読む」「書く」の部分を肩代わりする補助輪として位置づけるのが健全だと考えます。
AIに分析を補わせる進め方には、はまりやすい落とし穴がいくつもあります。ここを知らずに始めると、「AIを入れたのに使われない」という残念な結果になりがちです。正直に挙げておきます。
分析人材がいない現場でAI支援を軌道に乗せるには、いきなり全社導入を狙わず、小さく検証してから広げるのが堅実です。実現可能性そのものを見極める段階では、AI PoC開発のように、対象を絞った検証開発として進める考え方が合っていると考えられます。
第一段階は「対象選定と現状把握」。電力消費の大きい、あるいは無駄が疑われる設備を2〜3点選び、電力と生産量・稼働・環境データを紐付けられる形に整える。第二段階は「AI支援の試運転」。その数点について要因候補の整理・日次コメント・報告下書きをLLMに出させ、朝の5分レビューを数週間回して、当たり具合と運用負荷を体感する。第三段階は「効果検証と横展開」。原単位で改善効果を確かめ、レビューが回ると確信できた範囲だけ対象設備を増やしていく。うまくいかない部分は正直に見極めて引き返す判断も含みます。
どの段階でも共通するのは、「客観的な把握と現物での確認から出発する」という姿勢です。ダッシュボードの数字を信じ込む前に、実際の設備・現場で確かめる。AIの要因候補を採用する前に、現物で裏を取る。遠回りに見えて、これが分析人材の不在を補いながら着実に改善を積む唯一の道だと考えます。対象設備を絞った検証設計については小規模PoCから始める相談という形で入り口を用意しています。自社の設備で何が起きているかを、まず小さく確かめてみることをお勧めします。
可視化はスタート地点で、グラフから要因を絞り込み改善を打ち効果を検証する工程が残ります。この「読む・決める・確かめる」部分は人の技能に依存するため、分析人材や時間が不足すると止まりがちです。要因候補の整理や報告の下書きをAIに支援させ、人が確認する運用で補える可能性があります。まずは対象を絞った現物確認からの検証をお勧めします。
完全な代替は難しいと考えられます。AIは要因の当たりを付ける下書き役として有効ですが、計画停止や特殊ロットといった現場固有の文脈を踏まえた最終判断は人にしかできません。AIに候補出しや文書の下書きという作業を肩代わりさせ、どれが本当の原因かの判断は人が担う分業が現実的です。人の負担を減らす補助輪として位置づけるのが健全だと考えます。
そのまま使うのは避けるべきです。LLMは自然な文章の中に誤った数値をもっともらしく記述することがあり、削減率や電力量などの数字は必ず人が原データと照合する必要があります。AIは文章の骨子を作る下書き役として活用し、事実確認と数値の裏取りは人が行う前提で運用してください。生成物を無検証で外部に提出しないことが鉄則です。
報告書の骨子や説明文の下書き作成には活用しうると考えられます。ただし制度上求められる数値・様式・適用範囲は変わることがあり、AIの出力を根拠にせず、所管省庁の最新の公表資料でご確認ください。数値は原データと照合し、制度要件は公式情報で確認したうえで、AIは文章化の負担を軽くする補助として使う位置づけが安全だと考えます。
最初から全設備を対象にするとレビューが回らず頓挫しがちです。電力消費が大きい、あるいは無駄が疑われる設備を2〜3点に絞り、電力と生産量・稼働・環境データを紐付けられる形に整えるところから始めるのが定着の近道だと考えられます。数点で要因整理と日次コメントを数週間試し、効果を確かめてから対象を広げる進め方をお勧めします。
電力データを集めたものの読み解けずに止まっている——そんな状態から、要因候補の整理や報告下書きをAIに支援させ、人が確認する運用への一歩を一緒に考えます。対象設備を数点に絞り、現物での確認から小さく検証するところから始めましょう。
分析人材不在の進め方を相談する