エネルギー使用量を月次で集計して、増減の理由と見通しを出す

処理の起点を決める

毎月5日の朝に、定時で一括処理します。 前月分の請求書と検針票がそろうタイミングです。

Apps Script のインストール可能なトリガーには「時間主導型」があり、最短1分ごと、最長で月1回まで設定できます。月次の処理はこれで動かします。

年度末（4月）には、年度の集計を確定させる処理を別に走らせます。 定期報告書の提出期限は毎年7月末なので、4月に確定して5〜6月に確認する時間を取れる設計にしてください。

なお、インストール可能なトリガーは作成した人のアカウントで動きます。 担当者の異動で止まらないよう、部門の共用アカウントで作成してください。

入力データを集める

「拠点の記録」がこの構成の効き目を決めます。

原単位が悪化したときに、その理由を数字だけから特定することはできません。「7月にコンプレッサーが1台故障して、予備機で運転した」という記録があって初めて、要因が分かります。

この記録を月次で集める運用を、先に作ってください。 自由記述で構いません。むしろ自由記述のほうが、この構成では役に立ちます。

「原油換算係数」は省エネ法の告示で定められています。 自分で決めないでください。エネルギー種別ごとの係数を、告示から転記します。

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

電力： 電力会社のWeb明細からCSVをダウンロードします。自動取得できるかは契約と会社によります。 手動ダウンロードでも、月1回なら運用に乗ります。

ガス・燃料： 請求書または納品書からの転記です。OCRで読み取る構成も取れますが、月に十数枚なので、手入力のほうが早いことが多くあります。 ここに労力を割かないでください。

原単位の分母： 生産管理システム・物流システムから取得します。分母の定義を拠点ごとに固定してください。 「生産量」が製品重量なのか、投入原料重量なのかで、原単位が変わります。

気象データ： 気象庁が過去の気象データを公開しています。拠点の最寄りの観測所の月平均気温を使います。 空調負荷の比較には、冷房度日・暖房度日という指標もあります。

拠点の記録： フォームで集めます。「今月、エネルギー使用に影響しそうな出来事があれば書いてください」という1問で足ります。

AIへ渡す前に整形する

1. 単位の統一 … kWh、m3、kg、Lを、それぞれの換算係数で原油換算（kl）にそろえます。係数は省エネ法の告示に従います
2. 拠点・種別の名寄せ … 請求書上の事業所名と社内の拠点コードを対応づけます
3. 分母の妥当性の確認 … 生産量がゼロや異常値の月を検出します。分母が誤っていると原単位が無意味になります
4. 気温の補正 … 前年同月との気温差から、空調に起因する分の目安を計算します
5. 稼働日数の補正 … 稼働日数が前年と違う場合の影響を分けます
6. 欠測の検出 … 請求書が届いていない系統を検出します。前月と同じ値で埋めないでください

6番目を必ず実装してください。 欠測を放置すると年度の合計が狂い、定期報告書の数値が誤ります。欠測は「欠測」として明示します。

AIに処理させる

計算はすべてプログラムで行います。

これらはすべて決まった式です。LLMを使う理由がありません。

LLMにさせること：

要因を断定させないでください。 「コンプレッサーの故障が原因です」ではなく、「7月に原単位が12%悪化しており、同月にコンプレッサーの故障の記録があります」という並べ方です。因果関係の判断は、拠点に確認したうえで人が行います。

年度末の見通しについても、幅で示させてください。 「年度末の原単位は前年比1.2%低減の見込み」と断定すると、その数字が独り歩きします。「直近の傾向が続けば0.8〜1.5%低減の範囲」といった示し方にします。

指示内容を固定する

あなたは、エネルギー管理の担当者を支援する担当者です。
計算済みの数値と拠点の記録から、増減の要因を切り分ける材料を整理してください。

【厳守事項】
- 数値を計算し直さないでください。
  原単位、前年同月比、年度累計、補正値はすべて計算済みです。
  その値をそのまま引用してください。
- 増減の原因を断定しないでください。
  「〜が原因です」「〜によるものです」と書かないでください。
  「同月に〜の記録があります」という事実の並列にとどめてください。
- 拠点の記録にない出来事を推測しないでください。
  「おそらく空調の設定が変わったと思われます」と書かないでください。
  要因が見当たらない場合は、cause_candidates を空にし、
  「記録から該当する出来事が見つかりません」と書いてください。
- 年度末の見通しは、幅で示してください。
  単一の数値で断定しないでください。
  前提（直近◯か月の傾向が続いた場合）を必ず明記してください。
- 省エネ施策の効果について、「効果が出ています」と評価しないでください。
  実施日と、その前後の原単位を並べるだけにしてください。
- 拠点への確認事項は、拠点の担当者がその場で答えられる形で書いてください。
  「原因を調査してください」ではなく
  「7月にコンプレッサーの故障の記録があります。予備機での運転は何日間でしたか」
  のように、具体的に聞いてください。
- 欠測の系統については、値を推定しないでください。
  「欠測」として扱い、要因の分析を行わないでください。
- 拠点や担当者の対応の良し悪しについて記述しないでください。

【計算済みの数値】
{calculated_metrics}

【気温・稼働日数の補正の内訳】
{adjustment_breakdown}

【この拠点の今月の記録（自由記述）】
{site_notes}

【この拠点の過去12か月の原単位の推移】
{trend_12m}

【実施済みの省エネ施策】
{energy_saving_measures}

「増減の原因を断定しないでください」の1行が、この構成の安全装置です。 これを書かないと、「生産品目の変更による負荷増が原因です」と書かれます。その説明が定期報告書に載ると、実態と違っていたときに訂正することになります。

「欠測の系統について値を推定しない」も必ず入れてください。 定期報告書に載せる数値は実測値です。推定値を混ぜてはいけません。

出力形式を固定する

計算部分（プログラム）の出力：

{
  "period": "",
  "site": "",
  "energy_type": "",
  "consumption": { "value": 0, "unit": "", "is_estimated": false, "is_missing": false },
  "crude_oil_equivalent_kl": 0,
  "denominator": { "value": 0, "unit": "", "source": "" },
  "intensity": 0,
  "yoy": {
    "consumption_pct": 0,
    "intensity_pct": 0,
    "denominator_pct": 0
  },
  "adjustment": {
    "temperature_effect_pct": 0,
    "operating_days_effect_pct": 0,
    "residual_pct": 0
  },
  "fiscal_year_cumulative": {
    "crude_oil_equivalent_kl": 0,
    "intensity": 0
  },
  "five_year_average_reduction_pct": 0,
  "outlook": {
    "assumption": "",
    "intensity_range_low": 0,
    "intensity_range_high": 0
  }
}

LLM部分の出力：

{
  "site": "",
  "energy_type": "",
  "period": "",
  "observation": "",
  "cause_candidates": [
    {
      "fact": "",
      "source": "site_notes | measure_record | weather | operating_days",
      "quoted_text": "",
      "timing_match": true
    }
  ],
  "questions_to_site": [],
  "measure_timeline": [
    { "measure": "", "implemented_at": "", "intensity_before": 0, "intensity_after": 0 }
  ],
  "report_text_draft": "",
  "needs_review": []
}

adjustment.residual_pct（気温と稼働日数で説明できない残りの変動）が、この構成でもっとも重要な数値です。 「今月は前年より暑かったから電力が増えた」で終わらず、気温で説明できない分がどれだけあるかを示します。 そこに設備の劣化や運用の変化が表れます。

cause_candidates は「候補」です。 timing_match（時期が一致しているか）を持たせることで、単に同じ月に起きた出来事なのか、増減と時期が合っているのかを区別できます。

is_missing（欠測）を必ず持たせてください。 集計から除外する判断を、後から確認できます。

システムへ連携する

定期報告書の作成そのものは自動化しません。 所定の様式への記入と提出は、内容を確認したうえで人が行います。 この構成が担うのは、報告書に必要な数値を月次で積み上げておくことです。

電力会社のWeb明細の自動取得は、契約と会社によります。 自動化できない場合は、月1回の手動ダウンロードで構いません。そこを無理に自動化しないでください。

人が確認する

すべての系統の結果を担当者が確認します。

見る優先順位は次のとおりです。

3番目を毎月見ることが、この構成の主な目的です。 年平均1%の低減は、年1回の報告時に振り返っても間に合いません。毎月、現在地を見ておく必要があります。

拠点への確認の回答は、必ず記録に残してください。 翌年の同じ月に同じ現象が起きたときの材料になります。

例外に対処する

記録を残す

• 月次の使用量（取得元と取得日つき）
• 原単位の計算結果と、計算に使った分母
• 気温・稼働日数の補正の内訳
• 拠点の記録（自由記述の原文）
• 拠点への確認と、その回答
• 省エネ施策の実施記録と、その前後の原単位
• 欠測の記録と、後から補正した経緯

省エネ法では、エネルギーの使用状況を記録し、保存することが求められます。 保存期間と記録の内容は、自社の判断基準への対応状況を含めて確認してください。

「拠点への確認と回答」の蓄積が資産になります。 「この工場は毎年8月に原単位が悪化するが、それは冷却水温度が上がるため」といった知識が、記録として残ります。担当者が交代しても引き継げます。