原単位が先月より悪くなった——その一言から始まる要因探しは、なぜいつも属人的で時間がかかるのでしょうか。設備別の電力・生産量・停止・外気温・保全記録がバラバラに存在する現場で、AIに「候補要因の整理」と「確認すべき項目の提示」を任せ、因果の断定は人が担う。その現実的な役割分担を考えます。
月次の会議で「今月は製品あたりの電気代が上がっている」「原単位が先月より悪い」と指摘される。数字は出ている。けれど、そこから先——なぜ悪化したのかを説明し、次の手を決めるまでが、多くの現場でいちばん重い工程になっているのではないでしょうか。電力コストの高騰が続く中で、この「悪化した理由の説明責任」は、以前より確実に厳しく問われるようになってきていると考えられます。
背景には複数の圧力があります。電力単価の上昇で、同じ使い方でも請求額が膨らむ。省エネ法やGX関連の枠組みのもとで、エネルギー使用状況の把握と改善の報告が求められる（制度の具体的な適用範囲や数値は、所管省庁の最新の公表資料でご確認ください）。一方で現場は人手不足で、要因分析に何日もかけている余裕がない。「見える化」のダッシュボードは導入したものの、グラフを眺めて『で、結局なぜ？』の問いに答えるのは、結局ベテランの勘に頼っている——という声を、私たちはよく耳にします。
厄介なのは、必要なデータが「無い」わけではないケースが多いことです。設備別の電力量はスマートメーターやCT（電流センサー）で取れている。生産量はMESや日報にある。設備の停止・アラームはPLCのログに残っている。外気温は気象データで拾える。保全記録は保全部門のExcelにある。ところがこれらは別々のシステム・別々の担当・別々の粒度で存在していて、原単位が悪化したその週に「何が同時に起きていたか」を一望する仕組みが無い。だから毎回、担当者が手作業でファイルを突き合わせることになります。
原単位は、そもそも分子（エネルギー）と分母（生産量など）の割り算です。悪化と言っても、分子が増えたのか、分母が減ったのか、その両方かで意味がまったく違います。まずここを切り分けないまま「省エネ対策」に走ると、実は生産量が落ちていただけ、という空振りが起きます。原単位そのものの考え方はエネルギー原単位とはで整理していますが、本記事はその一歩先——悪化したときの「要因分析」をAIでどう支援するかに焦点を当てます。
要因分析を始める前に、原単位が悪化する経路を頭の中で分解しておくと、その後の作業が驚くほど楽になります。ざっくり分けると、悪化の入口は「分子（エネルギー消費）が増えた」「分母（生産量・良品量）が減った」「両方が動いた」の三つです。そしてそれぞれの裏に、性質の違う要因が並びます。
エネルギー消費が増える典型は、段取り替えの増加、少量多品種化による立ち上げ回数の増、待機・アイドル電力の積み上がり、コンプレッサーや冷凍機の効率低下、そして外気温の上昇による空調・冷却負荷の増大です。特に待機電力と季節要因は「気づかないうちにじわじわ効く」タイプで、生産していない時間帯の電力ベースラインが上がっていないかを見ると発見できることがあります。
生産量そのものの減少、稼働率の低下、不良やリワークの増加による良品数の目減り。ここが動くと、設備の使い方を何も変えていなくても原単位は悪化します。固定的に消費される電力（照明・空調・待機系）は生産量が減っても大きくは減らないため、生産が落ちた月ほど「製品あたり」は跳ね上がる。これは省エネ努力の失敗ではなく、需要側の変動であることが多い。ここを混同しないことが、無駄な対策と犯人捜しを避ける第一歩だと考えます。
つまり原単位悪化は、性質の異なる複数要因が同時に、しかも別々のデータソースに痕跡を残しながら進行します。人間が一つずつ突き合わせると時間がかかり、しかも「最初に思いついた仮説」に引っ張られやすい。ここに、複数系列を横断して淡々と差分を並べる作業——まさにAIが補助として向く領域が生まれます。
ここで最初に線を引いておきたいことがあります。AI（LLMを含む）に原単位悪化の「原因」を断定させてはいけない、ということです。相関は因果ではありません。外気温が上がった週に原単位も悪化していた、という事実からAIが「原因は外気温」と言い切ると、実は同じ週に不良が増えていた、という本当の主因を見落とす。だからAIの役割は、あくまで『悪化と同時に動いていたデータ系列を、影響が大きそうな順に並べ、人が確認すべき項目を提示する』ところまでに設計します。
実務的なイメージはこうです。まず悪化した対象期間（週や日）と、比較対象となる平常期間を決める。次に、設備別電力・生産量・停止時間・アラーム回数・外気温・直近の保全記録を、同じ時間軸に揃える。ここまでが下ごしらえで、原単位管理の仕組みの本体でもあります。そのうえでLLMに『平常期間と悪化期間で、どの系列がどれだけ変化したか』を差分として整理させ、変化の大きい順・原単位への効き方が大きそうな順に候補を並べさせる。この工程の基本はエネルギーデータのLLM分析でも触れています。
LLMを使う価値は、数値の差分そのものよりも「文脈をつけて説明できる」点にあると考えます。単に『設備Bの停止時間が+40分』と出すだけでなく、『設備Bの停止が増え、同時間帯の待機電力ベースラインがやや上がっている。段取り替え回数の増加と関係している可能性があるため、生産計画と段取り記録の確認を推奨』といった、次の確認行動に繋がる形で提示させる。この『確認項目の提示』こそが、現場で本当に使える出力だと私たちは考えています。
電力・生産・不良といったデータは、企業にとって機微な情報を含みます。外部のクラウドLLMに丸ごと送ることに抵抗がある現場は少なくありません。そこで、設備データの集約と一次的な分析を工場内で完結させるエッジAIによる工場内データ処理の構成が現実的な選択肢になりえます。Jetsonクラスのエッジ機とローカルLLMを組み合わせ、生データは外に出さず、要約・要因候補の整理までを構内で行う——そうした設計であれば、機密性と分析支援を両立しやすいと考えられます。
AI支援の質は、出力フォーマットの設計でほぼ決まります。「原単位が悪化しました」という曖昧な入力に対して「省エネしましょう」という曖昧な出力を返すシステムには価値がありません。要因候補と確認項目を、人がそのまま動ける粒度で構造化することが肝心です。
私たちが有効だと考えるのは、各候補要因を三つの要素で提示する形です。第一に『何がどれだけ変化したか』（例：設備Aの待機電力ベースラインが平常比で上昇）。第二に『原単位悪化への寄与がどの程度見込まれるか』（あくまで見込みであり、大・中・小や概算レンジで、断定はしない）。第三に『それを確認するために現場で何を見ればよいか』（例：夜間の主電源運用ルール、当該設備の直近保全記録）。この三点があると、会議で『次にこれを見る』が即座に決まります。
設計上、最初に必ず提示させたいのは「今回の悪化は、エネルギー側（分子）主導か、生産量側（分母）主導か」の切り分けです。生産量が落ちたことによる見かけの悪化であれば、省エネ設備投資よりも稼働率・需要変動の話になる。ここを冒頭で固定するだけで、その後の議論が的外れになる確率が大きく下がると考えます。地味ですが、これがAI支援の設計で最も効くポイントの一つです。
電力と生産だけを見ていると、要因分析はどうしても『使いすぎ／作らなさすぎ』の二択に寄ります。ここに保全記録（部品交換、フィルタ清掃、異音対応の履歴）と外気温を並べると、解像度が一段上がります。『冷凍機の効率が落ちているように見えるが、直近の保全記録では凝縮器の清掃が半年空いている。外気温上昇も重なっている』——こうした複合的な読み解きは、複数の文脈データを同じ土俵に載せて初めて可能になります。設備が古くPLCを持たない場合でも、後付けのセンサーやカメラで運転状態の痕跡を拾い、文脈データを補完できる可能性があります。
AIが要因候補と確認項目を出しても、そこで止まっては「賢いダッシュボード」に過ぎません。価値は、提示された確認項目を現場で一つずつ潰し、対策を打ち、その効果を次の期間で検証する——このループを回して初めて生まれると考えます。運用設計では、この反復を軽く回せるようにすることを最優先にすべきです。
AIが『夜間の待機電力を確認』『冷凍機の凝縮器清掃状況を確認』といった項目を出したら、それぞれに担当者と確認期限を付けて、次回のレビューまでに結果を持ち寄る運用にします。ここは人間側の運用ルールの話で、システムだけでは完結しません。ただ、確認項目が構造化されて出てくることで、この『誰が何をいつまでに』が決めやすくなる効果は大きいと考えられます。
対策を打った後の効果検証で最も注意したいのが、生産量や外気温といった前提条件が変わってしまうことです。単純に翌月の原単位が改善しても、それが対策の効果なのか、単に生産量が回復しただけなのか、外気温が下がっただけなのかは切り分けが要ります。ここでもAIに『対策前後で、生産量・外気温などの条件をそろえたときに原単位はどう変わったか』を整理させると、思い込みによる過大評価・過小評価を減らせる可能性があります。効果の数値は必ず現場・現物で確認する前提で扱ってください。
そして、確認して『違った』要因も記録に残すことが、実は継続運用でいちばん効きます。『外気温が疑われたが、条件をそろえると寄与は小さかった』という否定の記録が積み上がると、翌月以降のAIの候補提示も、その現場の実態に沿って精度が上がっていく。要因分析は一発勝負ではなく、季節や生産品目が一巡する中で育てていくものだと捉えると、運用が続きやすくなると考えます。
ここまで前向きな話をしてきましたが、実際にやってみると分かる落とし穴と、現時点での限界も正直にお伝えしておきます。これらを知らずに始めると、期待外れに終わったり、かえって判断を誤ったりしかねません。
限界も明確です。現時点のAI支援は、あくまで「人の要因分析を速く・漏れなくする補助」であって、現場を知らずに正解を出す魔法ではありません。設備の癖、運用の事情、季節の効き方——最後の解釈は現場の人にしかできない部分が残ります。そこを無理にAIに肩代わりさせようとすると、かえって信頼を失います。役割分担を守ることが、長く使われる仕組みの条件だと考えます。
最後に、では何から始めればよいか。いきなり全設備・全ラインを対象にした大掛かりな仕組みを目指すと、データ整備だけで息切れします。私たちがお勧めするのは、原単位悪化が課題になっている設備を数点に絞り、既にあるデータで小さく検証を始めることです。
最初のステップは、対象設備の電力・生産・停止・外気温・保全記録を、たとえ手作業でも一度同じ時間軸に並べてみることです。この段階で『そもそもどのデータが取れていて、どこに欠測や粒度のズレがあるか』が見えます。多くの現場で、ここが本当のスタート地点になります。そのうえで、悪化した週と平常週の差分をAIに整理させ、出てきた確認項目を現場で潰してみる。この一巡が、仕組み全体の価値を判断する材料になります。
小さく回してみると、『自社のデータで意味のある候補が出るのか』『確認項目が現場の行動につながるのか』が具体的に分かります。ここで手応えがあれば設備・ラインを広げ、ローカルLLMやエッジ処理を含めた本格構成へ育てていく。逆に、データ整備の負担が大きすぎるなら、まずデータの取り方から見直す——そういう判断ができるのが、小さく始める最大の利点です。実現可能性そのものを検証するAI PoC開発や、対象を絞って設計する小規模PoCから始める相談の形で、身の丈に合った一歩を設計できます。
Nsightは、元キーエンス画像処理事業部の現場知見をベースに、VLM・Jetsonエッジ・産業用カメラ・PLC/センサー連携を組み合わせて、こうした設備データ×AIの検証を現物ベースで支援しています。原単位悪化の要因分析を「勘とExcel突き合わせ」から一歩進めたいとお考えでしたら、まずは対象設備を絞った検証設計から相談することをお勧めします。客観的な把握と現物での確認が、いつでも出発点です。
現時点では、AIに因果を断定させる使い方はお勧めしません。AIやLLMが見つけられるのは「悪化と同時に動いていたデータ系列」までで、それは相関であって因果とは限らないためです。現実的には、要因候補を優先順位付きで整理し、人が確認すべき項目を提示させる補助に留め、最終的な因果の判断は現場の人が現物確認のうえで下す設計が安全だと考えられます。
設備別の電力量、生産量（できれば良品量）、設備の停止時間やアラーム、外気温、直近の保全記録が揃うと、悪化期間と平常期間の差分を比較しやすくなります。すべてが完璧に揃っている必要はなく、まずは対象設備を数点に絞り、既存データを同じ時間軸に並べてみて、どこに欠測や粒度のズレがあるかを把握するところから始めるのが現実的だと考えます。
はい、その可能性が高いと考えられます。原単位はエネルギー（分子）を生産量（分母）で割った値のため、照明・空調・待機電力など生産量に比例しない消費がある分、生産量が減ると製品あたりの値は上がりやすくなります。要因分析ではまず「エネルギー側主導か、生産量側主導か」を切り分けることが、無駄な省エネ対策を避けるうえで重要だと考えます。
工場内にエッジ機とローカルLLMを置き、設備データの集約から要因候補の整理までを構内で完結させる構成が選択肢になりえます。電力・生産・不良といった機微な情報を外に出さずに分析支援を受けられる可能性があり、機密性を重視する現場に向くと考えられます。ただし処理性能やデータ整備の条件は現場ごとに異なるため、小規模な検証で実現可能性を確かめることをお勧めします。
エネルギー使用状況の把握と改善は制度的にも求められる方向にありますが、具体的な適用範囲・数値・報告義務の内容は所管省庁の最新の公表資料でご確認ください。制度対応の観点でも、原単位の悪化要因を客観的に説明できる状態は役立つと考えられますが、まずは自社の電気代や設備の無駄といった実務課題を起点に、必要な範囲で無理なく始めるのがよいと考えます。
対象設備を数点に絞り、既にあるデータで「悪化した週と平常週の差」をAIに並べさせるところから小さく始められます。因果の断定はせず、確認すべき項目の提示までを支援する現実的な設計を、現物ベースでご一緒に検証します。
原単位分析のPoCについて相談する