エネルギー需要予測AIを現場で使う｜精度競争から意思決定・実行ループへ

需要予測AIの導入で、最初に決めるべきことはモデルではありません。予測を受け取った担当者が、いつまでに、どの選択肢から、何を決めるのかです。

需要予測や価格予測は重要ですが、予測値を画面に表示しただけでは、調達量も設備の運転計画も変わりません。競争力の差が出るのは、予測を制約条件と照合し、判断、承認、実行、結果の記録までつなぐ部分です。

この記事では、電力・ガス・熱の需要予測を対象に、予測モデルを「業務の部品」として実装する手順を整理します。

需要予測だけでは業務は変わらない

従来の需要予測プロジェクトは、誤差を小さくすることを中心に設計されがちです。しかし現場で必要なのは、最も精度の高い数字だけではありません。

• 予測が外れそうな幅はどれくらいか
• その幅によって調達量や運転計画を変えるべきか
• 契約、設備、与信、要員などの制約を満たすか
• 誰が承認し、どのシステムへ入力するか
• 実績との差と修正理由を次回へどう残すか

BCGは2026年のエネルギー取引に関する論考で、一般的な予測や要約は単独では持続的な優位になりにくく、データ、モデル、業務フロー、統制、既存システムを接続して洞察を行動へ移すことが競争力になると整理しています。

これは「需要予測は不要」という意味ではありません。予測モデルを単独の完成品として扱うのではなく、意思決定を支える一つの道具として位置付け直すということです。

最初に「予測で何を決めるか」を一枚にする

モデル開発の前に、予測が使われる場面を一枚にまとめます。例えば翌日の電力調達なら、次のように定義します。

「許容誤差5%」のような数字を先に置くと、その根拠が曖昧になりやすくなります。予測誤差が1単位増えたときに、調達費、インバランス、設備余力、担当者の作業へどの程度影響するかを見て、業務上の閾値を決めます。

データは量より「予測時点で見えていたか」

需要予測では、検証時だけ使える情報が混ざると、実運用より良い精度が出ます。翌日予測を前日17時に発行するなら、その時点で取得できた気象予報、設備計画、営業計画だけを使います。翌日の確定気象や、締め後に確定する実績は入力できません。

最初のデータセットは、次の4群に分けると管理しやすくなります。

1. 需要実績：電力、ガス、熱、蒸気などの時系列
2. 外部条件：気温、湿度、降水、日射、曜日、祝日
3. 業務条件：生産計画、営業時間、設備停止、来館者数
4. 取得時点：各データがいつ利用可能になったか

SQLでも、需要時刻だけでなく「予測発行時刻」を条件に入れます。

SELECT
    demand_time,
    area_id,
    demand_kwh,
    temperature_forecast,
    is_holiday,
    production_plan
FROM demand_features
WHERE available_at <= forecast_issue_time;

欠測や異常値も、すべて削除すればよいわけではありません。計量器の故障は補正対象ですが、猛暑や設備停止は現実に再発し得る事象です。「計測異常」と「現実の異常」を別のフラグで残します。

行動データは、効きそうだから集めるのではなく仮説から始める

今回の記事候補の起点になった論文は、エネルギー需要を直接予測した研究ではありません。学生の通学手段を、5つの天候シナリオと習慣的な移動情報から予測した研究です。454件の回答・シナリオ観測を使い、会話型調査、構造化処理、行動予測を3つのエージェントでつないでいます。

したがって、この論文から「移動情報を加えれば電力需要の精度が上がる」とは言えません。参考になるのは、天候だけでなく、習慣や選好を会話から収集して構造化し、予測へ渡す設計です。

エネルギー需要へ応用するなら、先に因果の仮説を置きます。

• オフィス：出社率が在館人数と空調・照明需要に影響する
• 商業施設：来館者数と営業時間が空調・店舗負荷に影響する
• 工場：生産計画と設備の起動停止が需要に影響する
• 地域需要：交通・人流が滞在地域の需要配分に影響する

初期検証では、個人の位置履歴より、拠点や時間帯ごとの集計値を優先します。それでも利用目的、保存期間、少人数集計の扱い、再識別リスクを整理し、法務・プライバシー担当の確認を通します。アンケートの行動意向と実際の行動は分けて保持し、同じ実績として扱いません。

モデル比較は段階的に行う

高度なモデルを最初から採用するのではなく、入力群を一つずつ足して寄与を確認します。

候補モデルは線形回帰、勾配ブースティング、時系列モデル、ニューラルネットワークなどです。モデル名より、実運用と同じ情報条件で比較できているかが重要です。

データはランダムに分割せず、過去で学習し、その後の期間で評価します。平均誤差に加えて、ピーク時間帯、猛暑・寒波、休日、設備停止など、意思決定への影響が大きい場面を分けて確認します。

MAPEは需要がゼロに近い時間帯で不安定になります。MAE、RMSE、WAPE、ピーク誤差、予測区間の的中率から、業務に合う組み合わせを選びます。

精度の次に「判断と実行」を測る

実証では、AI予測と現行予測を並べるだけでなく、担当者の行動を記録します。

• どの予測を採用したか
• どの値を、なぜ補正したか
• 判断に何分かかったか
• どの制約で候補を却下したか
• 承認後にどのシステムへ入力したか
• 実績との差と損益・運用影響はどうだったか

これにより、モデルの改善と業務フローの改善を分けられます。精度は十分でも、担当者が複数画面を見て手入力しているなら、次に直すべきはモデルではなく接続と承認です。

自動化の段階も分けます。

1. 可視化：予測値と要因を表示する
2. 推奨：制約を踏まえた複数案を比較する
3. 半自動実行：人の承認後に入力・通知・記帳する
4. 制約内の自律実行：定めた範囲だけ実行し、例外を人へ回す

多くの組織では、まず2から3を目標にするのが現実的です。4へ進む前に、権限分離、限度額、キルスイッチ、監査証跡、障害時の代替手順が必要です。

業種別に最初の一歩を変える

電力・ガス事業者

供給エリアや顧客群を一つ選び、需要実績、気象予報、曜日・祝日からベースラインを作ります。次に、予測区間と調達・需給計画の選択肢を結び付けます。交通量や人流は、既存データだけで説明できない誤差が残り、追加取得の仮説が立った後に検討します。

工場・物流施設

気象より先に、生産計画、シフト、設備停止、立ち上げ時間を同じ時刻軸へそろえます。予測結果は、契約電力、ピーク抑制、設備の起動順序という具体的な判断へ接続します。

商業施設・オフィス

営業時間、在館人数、テナント稼働、イベント、気象予報を候補にします。個人単位の追跡を避け、集計値でどこまで説明できるかを先に確かめます。制御へ直結させる前に、運用担当者への推奨として評価します。

導入前チェックリスト

• 予測を使って誰が何を決めるかを書いた
• 判断期限と、その時点で利用可能なデータを定義した
• 現行ルールをベースラインとして残した
• 計測異常と現実の異常を分けた
• 平均誤差だけでなく重要局面を評価した
• 予測値と予測区間を表示した
• 手動補正と採否理由を記録した
• 契約・設備・権限の制約を確認する場所を決めた
• 承認後の実行先と監査ログを決めた
• 入力欠測や制約違反時の停止条件を決めた

まとめ

エネルギー需要予測AIの価値は、予測誤差だけでは決まりません。予測が判断期限に間に合い、制約を踏まえた選択肢へ変換され、人の承認を経て実行され、その結果が次の判断へ戻るところまで設計されて初めて業務へ定着します。

最初の一歩は、モデルを選ぶことではなく、「誰が、いつ、何を決め、外れたときにどう戻すか」を一枚にすることです。そのうえで需要実績、気象予報、業務計画をそろえ、必要な場合だけ行動データを追加します。

需要予測を完成品ではなく、意思決定・実行・学習のループを支える部品として扱う。この順番が、検証だけで終わらない導入につながります。

参考

• An Agentic Approach for Active Data Collection, Travel Behavior Modeling, and Weather-Sensitive Demand Prediction
• BCG — Putting AI to Work in Energy Trading