風力発電所の運営会社が気象の予報と過去の発電の記録から Python で翌日の発電量を30分ごとに予測し、発電計画の提出の下地を作る
気象会社の風の予報と、号機ごとの過去の運転の記録から、発電所ごとの翌日・翌々日の30分ごとの発電量を幅つきで見込みます。点検の停止を差し引いた計画の値の案を作り、需給計画の担当の確認に回します。
- 連携・自動化
- Python
- 対象業界
- その他/自治体
- 対象部門
- 経営企画
- 対象業務
- 書類作成/集計・分析
- 主な課題
- データ分析に時間がかかる/判断に時間がかかる/属人化している
- AIで行う処理
- 予測
- 主な効果
- 判断支援/属人化解消/工数削減
- 導入難易度
- ★★★★★
- 実装レベル
- 本格構成
- 費用感
- 個別開発(大)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 朝、気象会社の配信から、発電所ごとの翌々日と翌日の時間ごとの風速・風向の予報を表計算に写す
- 風車の監視の仕組みから、前日の号機ごとの発電量と停止の時間を書き出し、予報と実績のずれを見る
- 保守の担当から、点検で止める号機と時間を聞き、止まる分を差し引く
- 予報の風速を、発電所ごとの「風速と発電量の表」に当てはめ、30分ごとの値を出す
- 前線の通過や強風の予報があれば、経験で値を下げる
- 計画の作成の仕組みに48コマの値を入れ、提出する
- 当日、実績が大きくずれ始めたら、ゲートクローズまでに計画を直す
- 自動毎朝、気象会社の予報が届いたら、プログラムが発電所ごとの翌々日・翌日の予報と、前日までの号機ごとの運転の記録を読み込む
- 自動保守の点検の予定表から、止める号機と時間を読み、30分ごとの運転できる基数の割合を出す
- 自動発電所ごとに、30分ごとの発電量の真ん中と、上側・下側の幅を見込む
- 自動見込みに運転できる基数の割合を掛け、計画の値の案を作る
- 自動強風で止まるおそれのある時間帯、風の急な変わり目、幅の広い時間帯、点検の予定と運転の記録が食い違う号機に印を付ける
- 人需給計画の担当が、印の付いた時間帯の理由を見て、計画の値をどの幅で出すかを決めて直す
- 人担当が計画の作成の仕組みに値を入れて提出する(これまでどおり)
各工程の詳しい説明を読む
- 朝、気象会社の配信から、発電所ごとの翌々日と翌日の時間ごとの風速・風向の予報を表計算に写す
- 風車の監視の仕組みから、前日の号機ごとの発電量と停止の時間を書き出し、予報と実績のずれを見る
- 保守の担当から、点検で止める号機と時間を聞き、止まる分を差し引く
- 予報の風速を、発電所ごとの「風速と発電量の表」に当てはめ、30分ごとの値を出す
- 前線の通過や強風の予報があれば、経験で値を下げる
- 計画の作成の仕組みに48コマの値を入れ、提出する
- 当日、実績が大きくずれ始めたら、ゲートクローズまでに計画を直す
(a)風速と発電量の表が古い。 4番目の表は、風車のメーカーの仕様の出力の曲線をもとに作ったものです。実際の発電所では、地形、ほかの風車の陰、羽根の汚れ、冬の着氷で、同じ風速でも出る量が違います。 表を直す時間が無く、ずれは5番目の経験で埋めています。
(b)風の変わり目で大きく外れる。 前線が通る日は、風の強まる時刻が数時間ずれるだけで、30分ごとの値が大きく外れます。 強風の予報の日は、風車が止まるかどうかで発電量がゼロか満量かに分かれます。
(c)作り方が人によって違う。 5番目の「経験で値を下げる」は、主任と若い担当で大きく違います。同じ予報を見ても、主任は2割下げ、若い担当は下げない、といった差が出ます。 下げた理由は記録に残りません。
(d)毎日、休みなく続く。 発電計画は土日も祝日も毎日出します。6発電所 × 2日分を毎朝、限られた時間に作るので、丁寧に見る日と見ない日が出ます。
- 【自動】 毎朝、気象会社の予報が届いたら、プログラムが発電所ごとの翌々日・翌日の予報と、前日までの号機ごとの運転の記録を読み込む
- 【自動】 保守の点検の予定表から、止める号機と時間を読み、30分ごとの運転できる基数の割合を出す
- 【自動】 発電所ごとに、30分ごとの発電量の真ん中と、上側・下側の幅を見込む
- 【自動】 見込みに運転できる基数の割合を掛け、計画の値の案を作る
- 【自動】 強風で止まるおそれのある時間帯、風の急な変わり目、幅の広い時間帯、点検の予定と運転の記録が食い違う号機に印を付ける
- 【人】 需給計画の担当が、印の付いた時間帯の理由を見て、計画の値をどの幅で出すかを決めて直す
- 【人】 担当が計画の作成の仕組みに値を入れて提出する(これまでどおり)
6番目で、担当は「表に当てはめる」代わりに「どの幅で出すか」を決めます。 印の無い日は、真ん中の値の案を流し見て提出に回せます。時間を使うのは、強風や前線の通過のような、見込みの幅が広がる日です。
7番目を自動にしないのは、意図してのことです。 計画の案をそのまま提出の仕組みに送る作りにすると、予報の取り違えや点検の予定の入れ漏れが、そのまま計画になります。 計画の値はインバランスの精算に直結するので、人の目と手を1回通します。
02今回想定するシステム構成
風車の監視の仕組み(号機ごとの10分ごとの風速・出力・運転の状態。一方向の書き出し) 気象会社の予報の配信(発電所ごとの時間ごとの風速・風向・気温・気圧。初期時刻つき) 保守の点検の予定表/出力の制御の記録 │ ▼【トリガー】予報の配信の受け取り(毎朝。事務の環境で動かす) Python(pandas) ├──▶ 停止・出力の制御・着氷の時間を外し、運転できる基数の割合を出す ├──▶ 30分ごとに束ね、風速の3乗・風向・空気の密さの項目を作る ▼ LightGBM(objective="quantile"、alpha=0.1/0.5/0.9 の3つのモデル) │ 発電所ごとの30分ごとの発電量の真ん中と、上側・下側 ▼ Python ── 運転できる基数の割合を掛け、計画の値の案と印を作る ▼ 【人が幅のどこで出すかを決め、印の付いた時間帯を直す】── 需給計画の担当 ▼ 計画の作成と提出の仕組み ── 担当が手で入れて提出
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 実行環境 | Python(pandas・LightGBM) | R |
| 処理エンジン | LightGBM の分位点回帰(objective="quantile") | scikit-learn の HistGradientBoostingRegressor(loss="quantile")、気象会社の発電量の予測の配信 |
| 集計 | Python(運転できる基数の割合の算出、計画の値の案への換算、印付け) | 計画の作成の表の計算式 |
| データの取得元 | 監視の仕組みからの一方向の書き出し、気象会社の配信、点検の予定表 | 監視の仕組みの日報 |
| 結果の出力先 | 需給計画グループの共有フォルダの計画の案の表 | 社内の連絡の場への通知 |
風車の監視の仕組みには、何も書き込みません。 監視の側から事務の環境へ、決まった時刻に10分ごとの記録を書き出すだけの一方向のつなぎにします。事務の環境から監視の側へは、ネットワークでつなぎません。
土台になるのは、LightGBM の分位点回帰です。 objective に quantile を選ぶと分位点回帰になり、どの分位点を見込むかは alpha で決めます。 alpha は huber と分位点の回帰でだけ使われ、既定は0.9です。真ん中(0.5)・上側(0.9)・下側(0.1)を、3つのモデルとして別々に学ばせます。
翌日の予報は、気象会社の配信を使います。 気象庁の気象データ高度利用ポータルサイトは、気象情報の迅速かつ確実な配信については、気象業務支援センターや予報業務許可事業者等に問い合わせるよう案内しています。発電所の場所の風の予報は、ハブの高さに近い高さの値を出せるかを気象会社に確かめて契約します。
計画の出し方は、ここ数年で変わっています。 電力広域的運営推進機関(広域機関)のよくある質問では、2025年度から翌日計画をBPフォーマットで提出し、翌々日計画から変更が生じなかった場合は翌日計画の提出が不要になること、翌々日計画の提出期限が10時であることが示されています。このため、見込みは翌々日分と翌日分の2回作ります。
03どうやって実装するのか
処理の起点を決める
気象会社の予報の配信が届いたことを起点にします。 毎朝、決まった初期時刻の予報が届いた後に動かし、翌々日計画の提出期限(10時)の前に担当が計画を確かめる時間を残します。 配信の時刻は契約している気象会社に確かめ、それに合わせて仕組みを組みます。
同じ朝に、翌日分の見込みも作り直します。 翌々日の見込みを出した前日の予報と、今朝の予報で風速が大きく変わっていれば、翌日計画として直すかどうかを担当が決める材料になります。変わっていなければ、翌日計画は出し直しません。
予報の配信が届かない、または初期時刻が前日のままなら、動かしません。 古い予報で見込むと、風の変わり目がまるごとずれます。担当に知らせ、気象会社の画面で予報を確かめて、これまでの方法で作ります。
当日の直しは、この構成では扱いません。 ゲートクローズまでの当日の直しは、監視の画面で実績を見ながら担当が行います。当日の短い先の見込みは別の作りが要るので、まずは翌日・翌々日に絞ります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 運転の記録 | 号機ごとの10分ごとの風速(ナセルの風速計)、風向、出力、運転の状態(運転・待機・停止・故障) | 監視の仕組みの書き出し |
| 発電量の実績 | 発電所の送電の端の30分ごとの電力量 | 計量の記録 |
| 予報 | 発電所ごとの時間ごとの風速・風向・気温・気圧、予報の初期時刻 | 気象会社の配信 |
| 点検の予定 | 止める号機、開始と終了の予定の日時 | 保守の点検の予定表 |
| 出力の制御 | 出力の制御の指示があった日時と、制御した量 | 需給計画グループの記録 |
| 風車の仕様 | 号機ごとの定格出力、運転を始める風速、強風で止まる風速 | 風車のメーカーの仕様書 |
質を決めるのは、出力の制御と停止の記録です。 出力の制御で抑えた日や、号機が故障で止まっていた時間は、風があっても発電量が少ない記録になります。 そのまま学ばせると、「この風速ならこのくらい」の値が全体に低めにずれます。止まっていた時間と抑えていた時間を、学ばせる記録から外す印にします。
予報の初期時刻を必ず残します。 同じ時刻の予報でも、前日の朝に出たものと前々日に出たものでは外れ方が違います。翌々日分を見込むモデルには前々日の朝の予報を、翌日分には前日の朝の予報を、学ばせるときから合わせて使います。
データの取得方法を決める
監視の仕組みからは、決まった時刻に、号機ごとの10分ごとの記録を決まった列の並びで書き出す設定を作ります。書き出しは風車のメーカーか保守の会社の作業になることが多いので、列の並びと運転の状態の符号の意味を最初に取り決めます。
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 号機ごとの10分ごとの出力と運転の状態 | 監視の書き出し | 停止の時間の印、運転できる基数 |
| 送電の端の30分ごとの電力量 | 計量の記録 | 学ばせる目的の値 |
| 過去の予報(初期時刻つき) | 気象会社の配信の保存分 | 学ばせる項目(予報の値) |
| 翌々日・翌日の予報 | 気象会社の配信 | 見込む項目 |
| 点検の予定 | 保守の予定表 | 運転できる基数の割合 |
過去の予報を保存しておくことが、いちばん大事な準備です。 学ばせるときに観測の風速を使うと、モデルは「本当の風速なら発電量はこう」という関係を学びます。本番で入るのは予報の風速なので、予報の外れの分だけ見込みが楽観に寄ります。 気象会社の配信を、少なくとも1年分、初期時刻ごとに保存してから学ばせます。保存が無ければ、過去の予報を気象会社から買えるかを確かめます。
AIへ渡す前に整形する
- 止まっていた時間を外す … 運転の状態が停止・故障・保守の10分は、号機ごとに印を付けます
- 出力の制御の時間を外す … 制御の指示があった時間は、発電所ごと学ばせる記録から外します
- 着氷の疑いを外す … 冬に、気温が0度前後で、風速の割に出力が大きく下がった時間に印を付けます。印の付いた時間は、学ばせる記録から外し、別に数えます
- 運転できる基数の割合で割る … 30分ごとに、運転できた基数 ÷ 全基数 を出し、発電量をこの割合で割って「全基が動いていたら」の値にします
- 30分ごとに束ねる … 予報の時間ごとの値を30分ごとに引き延ばし、計量の30分ごとの電力量と時刻を合わせます
- 項目を作る … 予報の風速、風速の3乗、風向(sin と cos の2つ)、気温と気圧から求めた空気の密さ、時刻、予報の初期時刻からの時間、前後の時間の風速の差
- 強風の項目を作る … 予報の風速が、仕様の強風で止まる風速の何割かを項目にします
4番目を軽く見ないでください。 点検で半分の号機を止めていた日の発電量を、そのまま学ばせると、その風速での見込みが半分にずれます。 割合で割って「全基の値」にそろえ、見込んだ後に翌日の運転できる割合を掛け戻します。
6番目で風向を sin と cos に分けるのは、359度と1度を近い向きとして扱うためです。 角度のまま入れると、北風の両側が遠い値として学ばれます。山の尾根の発電所では、向きで風の通り方が大きく変わります。
目的の値に、監視の仕組みの出力の合計ではなく、計量の30分ごとの電力量を使うのも意図してのことです。 号機ごとの出力の合計には、発電所の中の変圧器や線の損失、所内で使う電力が入っていません。計画と照らされるのは送電の端の量なので、学ばせる値もそれにそろえます。 監視の側の出力は、止まっていた時間の印と運転できる基数を出すためだけに使います。
AIに処理させる
させるのは、発電所ごとに「30分ごとの全基の発電量の真ん中と幅」を見込むことだけです。 運転できる基数の割合を掛けること、計画の値の案、印付けは、決まった計算で行います。
| 見込むもの | 使うもの | 判断できないときの扱い |
|---|---|---|
| 30分ごとの発電量(真ん中、alpha=0.5) | 予報の風速と3乗、風向、空気の密さ、時刻、初期時刻からの時間 | 予報の風速が学ばせた範囲の外なら out_of_range |
| 30分ごとの発電量(上側・下側、alpha=0.9/0.1) | 同上 | 幅が定格出力の4割を超えたら wide |
| 強風で止まるおそれ | 予報の風速と仕様の止まる風速の比 | 9割を超えたら cutout_risk |
真ん中と幅を、別々のモデルで見込むのは、外れ方が風速によって違うからです。 弱い風の日は発電量が小さく幅も狭い一方、風車が満量に近づく手前の風速の日は、少しの予報の外れで発電量が大きく動きます。 分位点のモデルなら、風速ごとに広がる幅をそのまま見込めます。
| させないこと | 理由 |
|---|---|
| 計画の値をどの幅で出すかの決定 | インバランスの損の出方と市場の見通しを見て、担当と責任者が決める |
| 電力の市場での売り買い | 取引の担当が、市場の規則と会社の方針で決める |
| 出力の制御の見込み | 制御は一般送配電事業者の指示による。指示が来てから反映する |
| 風車の運転の操作 | 監視の側の担当とメーカーの保守が行う |
| 予報の風速の補正 | 気象会社の予報をそのまま使い、勝手に足し引きしない |
5行目がいちばん起きやすい失敗です。 「この気象会社の予報はいつも1メートル強い」と感じると、プログラムの中で予報を補正したくなります。予報の外れ方は、学ばせた記録の中にすでに入っています。 さらに補正を入れると、外れが二重になります。外れ方は保存して数え、気象会社と話す材料にします。
指示内容を固定する
この構成は生成AIを使わないので、プロンプトの代わりに、モデルの設定と計算の規則を書いておきます。
【モデル(発電所ごと・見込む先ごとに3つ)】
- LightGBM
・objective = "quantile"
・alpha = 0.5(真ん中)、0.9(上側)、0.1(下側)
・目的の値 = 30分ごとの全基の発電量(運転できる基数の割合で割った値)
・項目 = [予報の風速, 風速の3乗, 風向sin, 風向cos, 空気の密さ,
時刻, 初期時刻からの時間, 前後1時間の風速の差, 強風の比]
- 見込む先は2つ:翌々日分(前々日の朝の予報)と翌日分(前日の朝の予報)
- 学ばせる記録 = 停止・出力の制御・着氷の印のある時間を外した過去2年
- 学ばせ直しは月に1回。確かめは直近1か月を外して学ばせ、外した1か月で見る
【計画の値の案】
- 案の値 = 真ん中 × 翌日の運転できる基数の割合
- 上側が真ん中を下回る、下側が真ん中を上回る(分位点の交差)ときは、
3つを小さい順に並べ替えてから使う
- 案の値は定格出力の合計 × 運転できる割合を上限、0を下限で切る
- 実際にどの値で出すかは担当が決める。案は真ん中で作る
【印を付ける条件】
- cutout_risk … 予報の風速が仕様の強風で止まる風速の9割超
- ramp … 1時間で見込みの真ん中が定格出力の3割以上動く
- wide … 上側と下側の差が定格出力の4割超
- out_of_range … 予報の風速が学ばせた記録の範囲の外
- maint_check … 点検の予定表と前日の運転の状態が食い違う号機がある
- 印の無いコマは、案の値をそのまま計画の案の表に載せる
分位点の交差の並べ替えを書いておくのは、3つのモデルを別々に学ばせると、まれに上側が真ん中を下回るからです。 そのまま表に出すと、担当が幅を読み違えます。並べ替えたコマの数は保存して数えます。 多い発電所は、学ばせる記録が足りていません。
案を真ん中で作り、どの幅で出すかを担当に残すのは、インバランスの損が上下で同じではないからです。 どちらにずれたほうが損が小さいかは、その日の市場の値の見通しで変わります。見込みのモデルはその判断の材料を出すだけにし、判断の物差しは需給計画の責任者が決めます。
出力形式を固定する
発電所・計画の対象日ごとに、次の形のJSONを作り、48コマの表にして計画の案の表に載せます。
{
"plant": "",
"target_date": "",
"horizon": "day_after_next | next_day",
"forecast_issued_at": "",
"available_ratio": [ { "slot": 1, "ratio": 0 } ],
"slots": [
{ "slot": 1, "wind_ms": 0, "p10_kwh": 0, "p50_kwh": 0, "p90_kwh": 0,
"plan_draft_kwh": 0, "flags": ["cutout_risk | ramp | wide | out_of_range"] }
],
"maint_check": [],
"quantile_crossing_count": 0,
"model_version": "",
"operator_plan": { "chosen": "p50 | adjusted", "reason": "" }
}
1つ目の理由は、forecast_issued_at を見込みと並べて残せることです。 どの初期時刻の予報で見込んだかが分かれば、外れたときに、予報の外れかモデルの外れかを分けられます。
2つ目は、available_ratio を48コマごとに持てることです。 点検が午前だけの日は、午後のコマの割合が戻ります。1日1つの割合で掛けると、午後の計画が少なすぎます。
3つ目は、operator_plan で担当が選んだ値と理由が残ることです。 真ん中で出したのか、強風の止まりを見込んで下げたのか。主任が直した理由が残れば、それがそのまま引き継ぎの材料になります。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 風車の監視の仕組み | 一方向の書き出しの受け取り | 号機ごとの10分ごとの記録 |
| 計量の記録 | 表の読み込み | 30分ごとの電力量 |
| 気象会社 | 契約している配信の受け取り | 予報(初期時刻つき) |
| 保守の点検の予定表 | 表の読み込み | 止める号機と時間 |
| 計画の案の表 | 事務の環境での書き出し | 48コマの見込みと案の値、印 |
| 社内の連絡の場 | 通知 | 印の付いた発電所とコマの数 |
計画の作成と提出の仕組みへは、何もつなぎません。 計画の案の表までで、担当が表を見て、提出の仕組みに自分で値を入れます。 提出の形式や期限が変わっても、この構成は直さずに済みます。
監視の仕組みへも、何もつなぎ返しません。 計画の値から風車の運転を変える経路は作りません。出力を抑える操作は、制御の指示を受けた担当が監視の側で行います。
人が確認する
需給計画の担当が見るのは、毎朝の計画の案と、印の付いたコマの理由です。 印の無いコマは、真ん中の案を流し見て提出に回します。全コマを前の方法で計算し直す運用にすると、第10章の15.0時間には収まりません。
maint_checkを先に見る … 点検の予定と運転の状態が食い違う号機です。保守の担当に、点検が延びたのか、予定外の停止かを確かめますcutout_riskとrampを見る … 強風で止まるおそれと風の急な変わり目です。幅の上側と下側のどちらで出すかを、責任者の決めた物差しで選びますwideとout_of_rangeを見る … 見込みの土台が弱いコマです。気象会社の予報の解説を読み、前線の通る時刻を確かめます- 選んだ値と理由を書く …
operator_planに残します
1番目を省かないでください。 点検が1日延びたのを見落とすと、止まっている号機の分の発電量を計画に載せ、そのまま不足のインバランスになります。 見込みの精度より、運転できる基数の入れ違いのほうが外れが大きくなります。
主任が在職しているうちは、週に1回、印の無い日も並べて見てもらいます。 見込みと主任の見立てが同じ向きにずれる発電所が続くなら、モデルに入っていない手がかり(羽根の汚れ、地形の陰、新しい建物)があるということです。
例外に対処する
| 起きること | 対応 |
|---|---|
| 予報の配信が届かない、初期時刻が古い | 見込みを出さず、担当がこれまでの方法で作る |
| 監視の書き出しが届かない | 前日の運転の状態が分からないので maint_check を全号機に付ける |
| 号機が予定外に故障で止まった | 保守の担当に復旧の見込みを聞き、運転できる割合を直して出し直す |
| 出力の制御の指示が来た | 指示の量を案の値から差し引き、担当が計画に反映する |
| 台風が近づく | 全コマに cutout_risk の確認を求め、責任者が出し方を決める |
| 冬の着氷で出力が落ちている | 着氷の印の時間を数え、気温の低い日は wide の線を下げる |
| 風車を建て替え・増設した | 新しい号機は1年は別に扱い、仕様の出力の曲線を参考に並べる |
| 気象会社や予報の地点を変えた | 半年は前の予報との違いを並べ、out_of_range を付けやすくする |
| 分位点の交差が多い | 並べ替えて使い、学ばせる記録の期間を見直す |
上から3行目は、毎月どこかで起きます。 風車は部品の不調で止まり、復旧まで数時間から数日かかります。止まった号機の分を見込みから引く作業を、毎朝の最初に置きます。 見込みのモデルが正しくても、運転できる基数を取り違えれば計画は外れます。
記録を残す
- 読み込んだ予報(配信の初期時刻を含めて)と、監視の書き出しの件数
- 発電所・コマごとの見込み(真ん中・上側・下側)と、運転できる基数の割合
- 計画の値の案と印、分位点の交差の数
- 担当が選んだ値と理由(
operator_plan)、実際に提出した値 - 翌日・翌々日の実際の発電量と、見込み・予報の外れ方
- モデルの版、学ばせた期間、印の線の値
4行目で、案の値と提出した値の両方を残すのは、担当の直しが効いたかを後から数えるためです。 真ん中のまま出した日と直して出した日で、どちらの外れが小さかったかを月ごとに比べます。直しが外れを増やしている型が見つかれば、その型の日は案のまま出す、という決まりに変えられます。
最後から2行目は、発電所ごと・季節ごとに並べます。 冬の季節風の時期だけ外れる発電所、前線の日だけ外れる発電所が見えてきます。外れの型が分かれば、どの日に人が時間を使うべきかが分かります。
04実装レベルの3段階
最小構成では、風向や時刻の違いが入りません。 同じ風速でも、向きと時刻で出る量が違う発電所には足りません。確かめるための段階です。 半自動化で、予報を写して表に当てはめる時間はほぼ無くなります。 ただし、点検の停止の差し引きと、計画の値の作り込みは手で残ります。本格構成で、担当が見るのは計画の案と印の付いたコマだけになり、この段階が本記事の想定です。 差が大きいのは、点検の予定を48コマに割り振る作業が、毎朝の手作業だからです。 段階を飛ばさないでください。 半自動化の見込みを冬と夏の一巡まで並べると、外れやすい発電所と季節が先に分かります。着氷と季節風の冬を一度見てから本格構成に進むほうが、印の空振りが減ります。
05工数削減シミュレーション
導入後 180件 × 5分 ÷ 60 = 15 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 陸上の風力発電所を複数持ち、自社(または同じグループの会社)で30分ごとの発電計画を作って毎日出している運営会社。計画の値を、気象会社の風速の予報と前日の実績を見比べる担当の経験で決めていて、担当が休むと同じ精度で作れない場合。風車の監視の仕組みから、号機ごとの10分ごとの風速・出力・運転の状態を2年以上取り出せる場合。発電計画の提出をアグリゲーターに任せている発電所でも、見込みの下地を自社で持ちたい場合に使える。
- 発電所が1か所で風車が数基しかなく、気象会社の発電量の予測の配信をそのまま使えば足りる場合。発電計画を一般送配電事業者やアグリゲーターが作り、自社では計画の値に関わらない場合。監視の仕組みの記録が月ごとの発電量しか残っていない場合。なお、発電計画の提出の判断、電力の市場での売り買い、出力制御への対応、風車の運転の操作は、この構成では代替できません。
07最小構成で試す方法
- 発電所を1つ選び、過去1年の30分ごとの電力量と、保存してある気象会社の予報を表に並べる
- 号機の停止と出力の制御があった時間を、運転の記録から消す
- 予報の風速と電力量の散らばりの図を描き、メーカーの仕様の出力の曲線と重ねる
- 風速の区切り(1メートルごと)に、電力量の真ん中と上側・下側の値を表計算で出す
- この表で翌日の値を作った場合と、いまの方法で作った計画の値の外れ方を、月ごとに比べる
5番目の比べを、必ず作ってください。 いまの方法の外れ方が、Python のモデルが超えるべき線です。風速の区切りの表だけで十分に当たる発電所もあります。
| 出てきた内容 | 判断 |
|---|---|
| 仕様の曲線と実際の散らばりがずれ、区切りの表で外れが減る | Python で LightGBM の見込みに進む |
| 停止や制御の記録が残っておらず、消せない | 監視の書き出しと記録の付け方を直すのが先 |
| 過去の予報が保存されていない | 予報の保存を始め、1年たまってから学ばせる |
3行目が出ることは珍しくありません。 失敗ではなく、予報と実績を並べて振り返る材料が無かったということです。 今日から配信を初期時刻ごとに保存してください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 観測の風速で学ばせ、本番の予報で楽観に寄る | 過去の予報(初期時刻つき)で学ばせる |
| 停止・出力の制御の時間を学ばせ、見込みが低めにずれる | 運転の状態と制御の記録で印を付けて外す |
| 点検の日の発電量をそのまま学ばせる | 運転できる基数の割合で割って全基の値にそろえる |
| 風向を角度のまま入れる | sin と cos の2つに分ける |
| 3つのモデルの分位点が交差する | 並べ替えて使い、交差の数を数える |
| 強風で止まる日を見込みの真ん中で出す | cutout_risk を付け、人が出し方を決める |
| 点検の延長を見落とす | 前日の運転の状態と予定表を突き合わせる |
| 予報をプログラムの中で補正する | しない。外れ方を保存して数える |
| 翌々日と翌日を同じモデルで見込む | 見込む先ごとに、その初期時刻の予報で学ばせる |
| 計画の案を提出の仕組みに自動で送りたくなる | 送らない。 担当が手で入れる |
| 着氷の冬を普通の日として学ばせる | 気温と出力の落ち方で印を付けて外す |
上の3行が、この構成の外れのほとんどです。 どれもモデルの問題ではなく、学ばせる記録が本番と同じ条件になっているかの問題です。確かめるときも、直近1か月を外して学ばせ、外した1か月の予報で見込んで外れ方を数えます。学ばせた期間の中で当てはまりを見ると、本番より良く見えます。モデルを凝らす前に、予報の保存と停止の記録をそろえてください。
下から2行目は、外れではなく作り方の失敗です。 運用に乗ると、「案をそのまま出したい」という声が出ます。計画の値はインバランスの精算に直結します。最初から作らないと決めておいてください。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 号機ごとの運転の記録、発電量の実績、気象会社の予報、点検の予定、出力の制御の記録、発電計画の値です。個人の情報は扱いませんが、発電設備の運転の情報と、電力の取引に関わる計画の情報です。
- 監視の仕組みと事務の環境を一方向でつなぐ … 事務の環境から監視の側へは、ネットワークでつなぎません。受け渡しの方法は、風車のメーカーと保守の会社と決めます
- 計画の提出に自動でつながない … 出すのは計画の案までで、提出は担当が手で行います
- 計画の値と見込みを社外に出さない … 発電所ごとの翌日の見込みは、電力の取引に関わる情報です。外部の生成AIのサービスに計画の表を貼り付けて相談する使い方はしません
- 見られる人を絞る … 計画の案の表は、需給計画グループと責任者に限ります。取引の担当との共有の範囲は、社内の取引の決まりに沿って決めます
- 予報の配信の契約の範囲で使う … 気象会社の予報を、契約で認められた目的と範囲の外へ出しません
- 外れたときの手順を先に決める … 見込みを止めて、これまでの方法に戻す条件(予報が届かない、書き出しが届かない、台風)を手順書に書いておきます
誤りが起きた場合のリスクは、発電量を多めに出して不足のインバランスが出ることと、少なめに出して余剰のインバランスが出ることの2つです。 前者は止まった号機の分を差し引き忘れると起き、後者は強風の止まりを見込みすぎると起きます。前者は運転できる基数の確認という作業で防げるので、毎朝の最初に置きます。
10まず何から始めるか
1週目:予報の保存を始める
気象会社の配信を、初期時刻ごとに消さずに保存する仕組みを作ります。あわせて、過去の予報を買えるかを気象会社に確かめます。この保存が無いと、どのモデルも本番と同じ条件で学べません。
2週目:停止と制御の記録をそろえる
監視の仕組みの運転の状態の符号の意味を、メーカーの資料で確かめます。出力の制御の指示を、日時と量の一覧にします。
3週目:1発電所で風速の区切りの表を作る
第8章の手順で、1つの発電所の予報の風速と電力量の表を作り、いまの方法との外れ方を比べます。この外れ方が、Python のモデルが超えるべき線です。
4週目:Python で見込みを出す
1つの発電所で LightGBM の3つのモデルを学ばせ、翌日の48コマの真ん中と幅を出します。この時点では計画には使わず、担当の計画の値と実際の発電量と並べて毎日記録します。
2か月目以降: 残りの発電所、点検の予定の反映、計画の値の案、印付け、翌々日分の見込みを足します。冬と夏を一度ずつ並べて確かめ、 1件20分が何分になったかを実測します。主任が直した理由が記録に残り、若い担当が印と幅を見て計画の出し方を説明できるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
objective に quantile(分位点回帰)を選べること。alpha が huber と分位点の回帰でだけ使われ、既定が0.9であること。monotone_constraints・categorical_feature の意味 | LightGBM: Parameters | 2026-10-27 |
| 計画値同時同量の下で、発電事業者が1日を48コマに分けた30分ごとに発電計画を作り、実需給の1時間前(ゲートクローズ)まで直せること。計画と実績の差(インバランス)を送配電事業者が調整力で補い、発生させた者が事後に精算すること | 電力・ガス取引監視等委員会事務局: インバランス料金制度等について(令和4年1月28日) | 2026-10-27 |
| 2025年度から翌日計画をBPフォーマットで提出し、翌々日計画から変更が生じなかった場合は翌日計画の提出が不要になること。翌々日計画の提出期限が10時であること | 電力広域的運営推進機関: 翌々日計画に関するご質問及び回答(Ver.1.3、2024年5月10日) | 2026-10-27 |
| 気象情報の迅速かつ確実な配信については、気象業務支援センターや予報業務許可事業者等に問い合わせるよう案内されていること。格子点(GPV)の資料の見本が公開されていること | 気象庁: 気象データ高度利用ポータルサイト | 2026-10-27 |
計画の提出の期限と様式は、広域機関の最新の要領で確かめてください。どの幅の値で計画を出すかは、自社の需給計画の責任者が決めてください。 本記事は上記の公開資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1987)についてのご相談はこちらから。
