はじめに
電力契約が「お得なナイト8」系（夜間が安く、昼間が高い）だと、蓄電池の設定次第で体感コストがかなり変わります。
うちはまだ売電契約が完了していない時期があり、まずは「自家消費を最大化」したい前提で運用していました。
ただ、家庭向けの高度なHEMS/HEMAは導入しておらず、細かいAI制御までは手が届かない状況でした。
一方で、Web画面からなら手動で設定を変えられるので、「手動でできるなら、自動化しよう」という発想で、翌日の日照予測を使って蓄電池設定を決める仕組みを作りました。
何を作ったか（ざっくり）
毎日 23:00 と 07:00 に処理を分けています。
- 23:00
- 翌日の日照予測を取得
- モニタリングサービスにログインしてCSV稼働データを取得
- 翌朝7時時点の目標SOCを計算
- 夜間帯（23:00-07:00）はグリーンモードのまま、06:00終了で必要充電量を逆算して設定を登録
- 07:00
- 日中は自家消費優先に寄せるため、グリーンモード系へ切替
- SOC下限は0%で、朝〜昼の発電が弱い時間帯でも放電可能な状態に調整
この運用ロジックに加えて、ダッシュボードも作り、
- 日照予測 vs 実績
- 自家消費kWh（日/累計）
- 節約額（日/累計）
- 月間推移
- 蓄電池設定値と実績
- kWh軸（夜間充電量・太陽光最大蓄電量）と、SOC(%)軸（設定SOC・日終SOC）を分離
をWebで確認できるようにしました。
ダッシュボード画面
Codexを使ってどれくらいで形になったか
感覚値ですが、約5時間で
- 自動実行バッチ
- 蓄電池設定ロジック
- 履歴DB保存
- ダッシュボード公開
まで一気に到達できました。
もちろん運用しながら係数調整やUI改善は続きますが、「まず動くものを作る」までの速度はかなり高かったです。
なぜGoogle Cloudにしたか（比較つき）
ローカル（Windowsタスクスケジューラ）運用の良い点
- すぐ始められる
- 手元でデバッグしやすい
- 既存PC資産を使える
ローカル運用の課題
- PCが落ちる/再起動で止まる
- 外出時の可観測性が弱い
- 長期運用で「気づいたら止まっていた」が起きやすい
Google Cloud運用の良い点
- Cloud Scheduler + Cloud Run Jobsで定時実行が安定
- ログが標準で追える
- USリージョン中心なら無料枠内に寄せやすい
- ダッシュボードをそのままWeb公開しやすい
使い分け結論
- 開発初期: ローカルで検証
- 本運用: Google Cloudで定時ジョブ化
この段階移行が一番ストレス少なかったです。
このシステムが向いている人
- 夜間安価・昼間高価の時間帯別料金プランを使っている
- 売電よりまず自家消費を重視したい
- 画面上の手動設定はできるが、毎日やるのはつらい
- まずは「完全自動AI」より「堅実な半自動」から始めたい
注意点
- サイト規約に反しない範囲で実施する
- 認証情報はSecret Manager等に置き、コードへ直書きしない
- 自動操作は必ずDRY RUN→本番適用の順で確認する
- 電力単価ロジック（段階単価）は最初に厳密化しておく
実装詳細
実装の詳細・構成・手順はGitHubにまとめています。
ここでは概要だけにして、深掘りはリポジトリ参照にしています。
- Repository: https://github.com/nobunora/SolerControler
- 運用説明:
docs/GCP_OPERATION_JA.md - 無料運用ガイド:
docs/GCP_FREE_BEGINNER_JA.md
おわりに
大げさな仕組みを最初から目指すより、
「今あるUIで手動できること」を自動化して、毎日の判断を減らすのが一番効きました。
同じような電力契約の方なら、十分再利用できる構成だと思います。
もしこれから始めるなら、まずはローカルで1週間回して、次にCloud移行が安心です。