工場の電力の使用実績と生産計画・気温の予報から、翌日の30分ごとの電力需要を見込み、デマンドの上限を超えそうな時間帯と止める設備の候補を生産の担当へ出す

処理の起点を決める

毎日14時に、定時で動かします。 生産計画の表は、翌日の分が毎日13時に確定します。14時に見込みを出せば、夕方の班長との打ち合わせに間に合います。 夕方より前に段取りが決まれば、乾燥機の立ち上げをずらすといった前日の準備ができます。

翌朝6時に、もう一度動かします。 JMA MSM は3時間ごとに更新されるとされていて、当日の朝の予報のほうが、前日の昼の予報より午後の気温が確かです。 出し直しで超える時間帯が増えた場合だけ、担当者と班長に知らせます。減った場合は表を差し替えるだけにします。

休日の前の稼働日は、休日明けの分まで出します。 金曜の14時に、月曜の分も出します。ただし月曜の分は、月曜の朝6時の出し直しを必ず見る決まりにします。

モデルの学び直しは、季節の変わり目の年4回にします。 設備を入れ替えた、ラインを増やした、といった変化があったときは、その月のうちに学び直します。

入力データを集める

質を決めるのは、いちばん下の優先順位の表です。 見込みがどれほど確かでも、止めてよい設備が決まっていなければ、候補は出せません。 空調の一部、予備のコンプレッサー、乾燥機の立ち上げの後ろ倒し、フォークリフトの充電の時刻など、品質に影響しない順に並べます。

設備の一覧の「立ち上げのときの電力」も外せません。 乾燥機や温調機は、立ち上げの30分ほどのあいだ、ふだんより多くの電力を使います。定格だけで足し算をすると、立ち上げが重なる朝の時間帯を少なく見積もります。

データの取得方法を決める

30分デマンド値は、デマンド監視装置から毎日CSVで書き出します。 中小企業基盤整備機構の J-Net21 の解説では、30分デマンド値は毎時0〜30分と30〜60分の30分間の使用量から平均の電力を出したものとされています。取り込むときは、時刻の区切りがこの30分に合っているかを最初に確かめます。装置によっては、終わりの時刻で記録しているためです。

気温は、予報の値で学習するのが理想です。 実際の気温で学習すると、予報が外れる分の誤差をモデルが知らないまま、見込みの幅が狭く出ます。過去の予報を取れない期間は実際の気温で学習し、取り込みを始めた日から、毎日の予報の値を保存しておきます。 1年分たまったら、予報の値で学び直します。

API の場所の指定は、工場の緯度と経度で行います。 timezone には Asia/Tokyo を指定し、30分値の時刻と同じ時刻の並びで受け取ります。

AIへ渡す前に整形する

1. 時刻の区切りをそろえる … 30分値の時刻を、区切りの始まりの時刻にそろえます
2. 生産計画を30分ごとにする … 設備ごとの稼働の開始と終了から、30分ごとに動いている設備の定格の合計を作ります。立ち上げの30分には、立ち上げのときの電力の目安を使います
3. 気温を30分ごとにする … 1時間ごとの予報を、前後の時刻の値で30分ごとに直します
4. 特徴を作る … 時刻、曜日、休日明けか、30分ごとの定格の合計、立ち上げる設備の数、気温、湿度、前日の同じ時刻の実績、前週の同じ曜日・同じ時刻の実績
5. 特殊な日の印 … 停電、設備の故障、計画外の停止、棚卸で止めた日に印を付け、学習から外します
6. 設備の変化の印 … 設備を増やした・入れ替えた日の前後で、印を付けて分けます

2番目の「立ち上げの30分」を軽く見ないでください。 30分デマンド値は30分の平均なので、立ち上げを15分ずらすだけで、その30分の平均が変わります。 J-Net21 の解説にも、30分のうち後半の15分の負荷を下げれば30分デマンド値が下がる例が載っています。立ち上げを30分単位で扱うと、この効き方が見えません。

学習と検証は、時間の順で分けます。 scikit-learn の TimeSeriesSplit は、未来のデータで学習して過去を評価しないための分け方です。翌日を見込むモデルなので、gap を1日分（48行）にします。

AIに処理させる

この構成の「AI」は、30分ごとの電力需要の見込みだけです。 超える量の計算と設備の候補は、決まった規則で出します。

見込みには、scikit-learn の HistGradientBoostingRegressor を使います。 損失の関数に quantile を選び、quantile に0.5と0.9を指定した2つのモデルを作ります。欠けた値（NaN）をそのまま扱えるので、前週の同じ時刻の実績が無い休日明けの行も落とさずに済みます。

多めの見込みに90％点を使うのは、超えたときの損が大きいからです。 1回超えるとその値が1年間の契約電力になり、500kW以上の協議で決まる契約でも、超えれば割増の違約金を払うことになると J-Net21 の解説にあります。備える回数が少し増えても、超える回数を減らすほうに寄せます。

設備の候補は、優先順位の表の上から順に選びます。 超える時間帯ごとに、その時間に動く予定の設備のうち、表で止めてよいとされたものを、減らせる電力の合計が超える量を上回るまで選びます。止めてよい時間の長さを超える時間帯には、その設備を選びません。

2行目がいちばん起きやすい失敗です。 見込みが出ると、設備の制御までつなげたくなります。前日の見込みで当日の設備を自動で止めると、見込みが外れた日に、止める必要のない設備が止まります。

指示内容を固定する

この構成は生成AIを使わないため、指示は Python の設定ファイルに書きます。 何をどう見込み、どの規則で候補を選ぶかを、生産と設備の担当が読める形で残すためです。

# 翌日のデマンドの見込みの設定（demand_forecast.yaml）

工場: [第1工場, 第2工場, 第3工場]
時刻の区切り: 30分（毎時0〜30分、30〜60分）

予報:
  取得先: Open-Meteo JMA API（models=jma_msm）
  変数: [temperature_2m, relative_humidity_2m]
  timezone: Asia/Tokyo
  取得: 毎日14:00（翌日分）、6:00（当日分の出し直し）

見込み:
  50％点: {loss: quantile, quantile: 0.5}
  90％点: {loss: quantile, quantile: 0.9}
  学び直し: 年4回（3月・6月・9月・12月）と設備の変更のあと
  検証: TimeSeriesSplit（n_splits=5, gap=48）

目標のデマンド（kW）: {第1工場: 450, 第2工場: 380, 第3工場: 300}

候補の選び方:
  - 90％点が目標を超える時間帯だけを対象にする
  - 停止・後ろ倒しの優先順位の表の上から、その時間に動く予定の設備を選ぶ
  - 減らせる電力の合計が超える量を上回ったら止める
  - 止めてよい時間の長さを超える設備は選ばない
  - 表に無い設備は選ばない。足りなければ「候補不足」と書く

守ること:
  - 立ち上げの30分は、定格ではなく立ち上げのときの電力の目安を使う
  - 90％点が50％点を下回った行は、並べ替えずに印を付けて人に見せる
  - 予報が取れなかった日は、前日の同じ時刻の予報の値で見込み、表の冒頭に書く
  - 結果を設備の制御やデマンド監視装置の設定に書き込まない

「表に無い設備は選ばない。足りなければ候補不足と書く」が、この設定の要です。 候補が足りない日は、生産計画そのものを見直すべき日です。黙って足りないまま出すと、担当者は表の候補だけで足りると思い込みます。

「90％点が50％点を下回った行に印を付ける」は、2つのモデルを別々に作ると起きることへの備えです。 並べ替えて隠すと、見込みの不安定な時間帯があることに誰も気づきません。

出力形式を固定する

翌日の見込みを、次の形のJSONと、それを表にしたものの2つで出します。

{
  "plant": "第1工場",
  "target_date": "2026-10-08",
  "forecast_issued_at": "2026-10-07T14:00",
  "weather_run": "jma_msm",
  "target_kw": 450,
  "slots": [
    {
      "time": "13:30",
      "planned_rated_kw": 0,
      "temp_c": 0.0,
      "p50_kw": 0,
      "p90_kw": 0,
      "excess_kw": 0,
      "candidates": [
        { "equipment": "乾燥機 D-3", "action": "start_delay_30min", "reduce_kw": 0 }
      ],
      "flag": ""
    }
  ],
  "shortage_slots": [],
  "staff_decision": { "actions": [], "reason": "" },
  "actual_review": { "over_p90_rate": 0.0, "max_actual_kw": 0 }
}

slots と shortage_slots は Python が埋め、staff_decision は電気の担当が書きます。actual_review は翌日の実績が取り込まれた後に Python が埋めます。

1つ目の理由は、見込みと段取りを同じ記録に並べられることです。 候補を入れ替えた日、候補を使わなかった日に、実際の30分値がどこまで上がったかを並べられます。

2つ目は、shortage_slots で候補の足りない時間帯が見えることです。 表の設備を全部止めても目標を超える時間帯は、生産計画の組み方を変えるしかない時間帯です。生産管理課の会議に、この欄の一覧を持っていきます。

3つ目は、forecast_issued_at と weather_run で、どの予報で見込んだかが分かることです。 朝6時の出し直しの後に、前日の14時の見込みのまま段取りをしていたことに気づけます。

システムへ連携する

デマンド監視装置にも、設備の制御にも書き込みません。 当日の守りは警報が受け持ち、この構成の結果が外れても、警報の働きは変わりません。 二重の備えにしておくことが、この構成を入れても安全な理由です。

予報の呼び出しは、1日2回、工場の数だけにします。 必要な時刻の変数だけを取り、取った予報の値はすべて保存します。 保存した予報の値が、後で予報の値で学び直すときの材料になります。

人が確認する

電気の担当は、毎日14時の見込みの表を必ず見ます。

1. 振り返りを先に見る … 前日の見込みで、90％点を超えた時間帯が無かったかを見ます。続けて超えているなら、今日の見込みも割り引いて読みます
2. 超える時間帯と候補を見る … 候補の設備について、翌日止めてはいけない事情（試作、納期、品質の確認中）が無いかを確かめます
3. 候補不足の時間帯を見る … shortage_slots があれば、生産計画の担当と稼働の順番を相談します
4. 段取りを決めて伝える … 班長に、どの設備をいつ止める・ずらすかを伝え、staff_decision に書きます

2番目を省かないでください。 優先順位の表は平時の順番です。納期の迫った品番の乾燥機を後ろ倒しにすると、成形の開始が遅れて納期に響きます。 その日だけ順番を入れ替えるのは、担当者の仕事です。

朝6時の出し直しで超える時間帯が増えたときは、班長に直接知らせます。 担当者がその日に不在なら、代わりに受け取る人を前もって決めておきます。 第3章の（d）を繰り返さないためです。

目標は、1工場1日あたり10分です。 超える時間帯の無い日は表を見て数分、超える時間帯のある日は候補の確かめと班長への連絡で15分前後かかります。

例外に対処する

上の2行は、運用の最初から起きます。 どちらも見込みを止める理由にはしませんが、どの予報と実績で見込んだかを表に書かないと、古い見込みが新しいものに見えます。

記録を残す

• 毎日の30分デマンド値のCSVと、取り込んだ日時
• 取得した気温と湿度の予報の値と、取得した時刻（14時と6時の両方）
• 生産計画の表と、設備の一覧・優先順位の表のそのときの版
• モデルの版、学習の期間、検証の結果
• 30分ごとの見込み（50％点と90％点）、超える量、設備の候補
• 担当者が決めた段取りと理由（staff_decision）、翌日の実際の30分値と最大値

最後の行は、優先順位の表の見直しに使います。 候補にした設備を止めたのに超えた日があれば、減らせる電力の見積もりが大きすぎたということです。設備の担当と一緒に、表の値を直します。