EV充電スポットの運営会社が拠点ごとの充電の記録から Python で翌月の利用を幅付きで予測し、混雑する時間帯と増設の候補を出す

処理の起点を決める

毎月3日の朝に、定期実行で動かします。 月末の最終日の夜につないだ充電は翌日に終わるので、記録が出そろうのは2日以降です。プログラムは最初に、決まったフォルダに前月の CSV が置かれているかを見ます。無ければ何も作らず、担当へ知らせて止まります。 翌日の同じ時刻にもう一度見に行きます。

CSV があっても、すぐには予測しません。 前月の件数を前年の同じ月・前月と比べ、極端に少なければ書き出しの漏れを疑って止めます。 書き出しの期間の指定を誤ると、月の後半が欠けた CSV ができます。欠けたまま学ばせると、翌月の予測がまるごと下にずれます。

会議の1週間前までに資料がそろうように、実行の日を決めます。 経営企画の担当が予測を読み、設置先との協議の予定を書き足す時間が要るからです。

入力データを集める

質を決めるのは、「つないだ時刻」と「外した時刻」です。 充電の開始と終了だけでは、充電が終わったあとも車が口をふさいでいた時間が分かりません。埋まり具合は、充電していた時間ではなく、口がふさがっていた時間で数えます。普通充電の拠点では、この差が大きく出ます。

祝日は内閣府の CSV を使います。 内閣府のページでは、昭和30年（1955年）から令和9年（2027年）までの国民の祝日を CSV で公開しています。文字コードは Shift_JIS 系なので、読むときに指定します。 翌年の祝日が載っていない時期は、予測の対象の月が範囲に入っているかを確かめ、入っていなければ止めます。

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

1回の充電を時間帯に分ける処理が、Before の②の15分を置き換える部分です。 日をまたぐ充電、月をまたぐ充電は、月の境目で切り、前月の分は前月の集計に入れます。 時刻は充電の管理システムが出す時間帯の扱いを確かめ、日本時間にそろえます。

AIへ渡す前に整形する

1. 形を確かめる … 列の名前と並び、時刻の形、件数を確かめます。合わなければ止めます
2. おかしな行を除く … 外した時刻がつないだ時刻より前の行、48時間を超える行、同じ口で時間が重なる行を除き、件数を残します
3. 時間帯に分ける … 上の表のとおりに集計します
4. 故障の時間を外す … 故障の記録の時間を、使える分から引きます。口がすべて止まっていた時間帯は、予測の学習から外します
5. 張り付きの印を付ける … 埋まり具合が決まりの値以上の時間帯に印を付けます
6. 暦の特徴を作る … 祝日の CSV から祝日と連休の何日目かを作ります
7. 過去の利用の特徴を作る … 前年の同じ月の同じ曜日・時間帯の平均、直近8週の同じ曜日・時間帯の平均。予測する月より前に分かっている値だけを使います
8. 開業の日数を付ける … 開業から日の浅い拠点は、伸びている途中なので、開業からの月数を特徴に入れます

7番目の「前に分かっている値だけ」を守らないと、過去の月でやり直した成績が良く見えすぎます。 予測する月の中の値が特徴に混ざると、答えを見ながら答えていることになります。直近8週の平均は、予測する月の前日までで切ります。

3番目の分け方は、例で確かめておきます。 21時40分につないで翌朝6時10分に外した普通充電は、21時台に20分、22時台から5時台に各60分、6時台に10分として足します。この1回が、9つの時間帯の埋まり具合に入ります。 表計算でつまずいていたのはここで、Python では1回の充電を分単位の区間として持ち、時間帯の境目で切って足すだけで済みます。

AIに処理させる

予測をするのは、Python の機械学習のモデルです。 生成AIは、その結果を会議の資料の文にするだけです。

学習は、すべての拠点をまとめた1つのモデルで行います。 拠点ごとに分けると、記録の少ない拠点のモデルが作れません。拠点の種類・設置先の種類・口の数を特徴に入れ、 似た拠点の動きから学ばせます。公式のページでは、categorical_features で区分の特徴を指定でき、区分ごとの値の数は max_bins 以下である必要があるとされています。拠点の番号そのものを区分の特徴に入れるかは、拠点の数が増えたときに見直します。

学習に使う期間は、直近2年を基本にします。 それより古い記録は、EVの台数や周辺の充電器の数がいまと大きく違い、いまの動きを学ぶ邪魔になることがあります。 期間を変えたときは、過去の月でのやり直しの成績を比べてから切り替えます。モデルの設定（木の深さ、学習の回数）は最初は既定のままにし、データの扱いが固まるまで細かく詰めません。

過去の月でのやり直しには、TimeSeriesSplit を使います。 公式のページでは、時間の順に並んだデータで、未来のデータで学んで過去を評価することを避けるための分け方とされ、学習の期間とテストの期間のあいだを空ける gap を指定できます。外れ方は mean_pinball_loss で測ります。 公式のページでは、分位点の回帰のためのピンボール損失で、alpha で狙う分位点を指定し、0.5のときは平均絶対誤差と同じになるとされています。

2行目がいちばん大事です。 張り付いた時間帯の本当の需要は、記録からは分かりません。モデルはそこを「上限まで使われた」としか学べないので、予測の上振れも上限で止まります。増設の候補は予測の数字の大きさではなく、張り付きの日数で出します。

指示内容を固定する

あなたはEV充電スポットの運営会社の経営企画の担当です。
拠点ごとの翌月の利用の予測の表と印をもとに、会議の資料の説明の文を書いてください。

【書き方】
- summary：その拠点の翌月の見通しを2〜3文で。
- busy_hours：混雑する時間帯を、表のとおりに並べる。
- flags_explained：付いている印の意味を1文ずつ。

【数字の使い方】
- 数字は、表にある値だけを、表のとおりの形で書いてください。
- 割合・差・合計を計算して新しい数字を作らないでください。
- 文で使った数字は、numbers_used にすべて並べてください。
- 予測は「10％点〜90％点」の幅で書き、中央の値だけを書かないでください。

【厳守事項】
- 増設すべき・すべきでない、と書かないでください。候補であることだけを書いてください。
- 利用が増えた・減った理由を推測して書かないでください（競合、景気、EVの普及など）。
- 「張り付き」の印のある拠点では、「記録上の利用は上限に達しており、
  実際の需要は記録より多い可能性がある」旨を必ず書いてください。
- 単純な見込みより外れが大きい拠点（model_worse が true）は、
  summary を空にし、needs_review に理由を書いてください。

【拠点】{site_name}（{site_type}、{charger_type}、口の数 {ports}）
【予測の表】{forecast_table}
【過去の月の外れ方】{backtest}
【印】{flags}

「中央の値だけを書かない」は、幅で出す意味を守るためです。 何も言わなければ、文は「来月は約1,240回の見込み」と1つの数字に寄ります。会議で読まれるのは文のほうなので、幅を文にも残します。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、output_config.format に json_schema を指定し、オブジェクトには additionalProperties: false を付けることとされています。数値の minimum・maximum には対応しないとされているので、値の範囲は Python の側で確かめます。

{
  "site_id": "S-031",
  "summary": "",
  "busy_hours": ["土 12時台", "土 13時台", "日 12時台"],
  "flags_explained": [""],
  "numbers_used": ["410", "520", "640"],
  "needs_review": null
}

Python の側の予測の表は、次の形で保存します。 こちらが会議の資料の本体で、文は添え物です。

照合は次のとおりです。

10％点が50％点を上回る、50％点が90％点を上回ることが、分位点を別々のモデルで出すと起こりえます。Python の側で並べ替えて順をそろえ、そろえた件数をログに残します。 件数が多い拠点は、特徴かデータを見直します。

システムへ連携する

充電の管理システムには書き込みません。 予測の結果で料金や時間の上限を自動で変えることもしません。この構成が出すのは、会議の材料までです。

API キーは環境変数に置き、プログラムに書きません。 定期実行のアカウントだけが読めるようにします。

人が確認する

1. 止まった理由を見る … CSV が無い、件数が少ない、祝日の CSV に対象の月が無い、のどれかです
2. model_worse の拠点を見る … 単純な見込みに負けている拠点は、改装・周辺の工事・料金の変更など、記録に無い変化があったかを確かめます
3. 増設の候補を読む … 張り付きの日数と予測の幅を見て、設置先との協議の予定を書き足します
4. 説明の文を直す … 表に無い事情（近くの充電器の開業、施設の営業時間の変更）を書き足します
5. 会議で決める … どの拠点で増設・案内の見直しを検討するかを決め、記録します

候補の一覧は、拠点ごとに1枚の表にまとめて渡します。 時間帯の予測の行は1拠点で月に数百行になるので、人が読むのは、混雑の印のある時間帯と張り付きの日数、過去の月の外れ方の3つに絞った要約の表です。細かい行は、疑問が出たときに開きます。

目標は、1件あたり10分です。 多くの拠点は予測の表と文を流し見て数分で済み、増設の候補と model_worse の拠点に時間を使います。

例外に対処する

どの行で止まったかは、処理ログの1行目に書きます。 担当が最初に開くのはログで、止まった理由がすぐ分かれば、CSV を取り直すか、管理システムの提供元に聞くかがその場で決まります。

増設したばかりの拠点の行は、見落としやすいところです。 口が2つから4つに増えた拠点で、前の月の埋まり具合をそのまま学ばせると、混雑が続くように予測します。 拠点の一覧の増設の履歴から、口の数が変わった月を特徴に入れます。

撤去や長い休止の拠点も同じです。 設置先の改装で2か月止まっていた拠点は、その期間を学習から外し、再開した月を「開業」と同じように扱って「参考」の印を付けます。 止まっていた理由と期間は、故障の記録とは別に拠点の一覧に残しておきます。

記録を残す

• 実行の日時、使った CSV のファイル名と件数、除いた行の件数と理由
• 学習に使った期間と特徴の一覧、モデルの設定、scikit-learn の版
• 過去の月でのやり直しの結果（拠点ごとのピンボール損失と、単純な見込みとの比較）
• 予測の表、候補の一覧、AIに渡した表とAIが返した JSON、照合の結果
• 会議の決定と、翌月の実際の利用との差

最後の行を毎月残すことで、予測が役に立っているかが分かります。 半年分たまれば、どの種類の拠点で外れやすいか、上振れの90％点を超える月がどれくらいあるかが見えます。90％点を超える月が1割を大きく超えるなら、幅が狭すぎます。