電力小売のAI活用｜需給連絡・契約照会・案内文の責任分界【2026】

電力小売の窓口でAIを使うなら、需要データを読む作業と契約条件を説明する作業を分けます。問合せの分類や案内文の下書きは支援できますが、個別契約への回答を確定する担当を外せません。登録後の届出や報告を案内する資源エネルギー庁のページも、手続ごとに確認先を分けています。

需要の変化を示すグラフから、個別の契約変更案内は作れません。集計値と顧客の原契約は性質が違い、両者を一つの入力欄で扱うと説明の根拠がぼやけます。照会履歴から誰が何を確認したかを辿れる状態が必要です。

問合せから監査記録までを「照会責任の分岐マップ」に置き、需要情報の扱い、案内文の下書き、回答の確定、例外処理を順に扱います。公開情報で答えられる範囲と個別契約の確認が必要な範囲を整理します。

本記事で分かること

• 需要情報と契約照会を分ける方法
• 問合せ分類から例外を見落とさない手順
• 案内文の根拠を履歴に残す考え方
• 監査に備える例外処理の記録

結論：電力小売でのAI活用（早見表）

電力小売でのAI活用は、需要情報と顧客照会を分け、契約に基づく回答を担当者へ渡すための窓口支援です。

需要の傾向から契約の内容を推測してはいけません。問合せには照会した顧客、対象の契約、参照した案内を結び、回答を送る前に人が確定します。顧客とのやりとりを記録する点では信用金庫のAI活用も参考になりますが、電力小売では需給情報と契約照会の境界が中心です。

資源エネルギー庁「小売電気事業の登録申請・届出」は、登録の流れ、登録後の届出・報告、登録情報の変更などを分けて案内しています。この区分を顧客向けの個別回答と取り違えず、窓口の確認対象を整理します。

公的ページは事業者の手続を説明するもので、顧客の契約条件を決める資料ではありません。顧客に送る案内は原契約と社内の確定情報で照合します。

需要情報と契約照会を別の箱に置く

需要データの傾向と個別の原契約は、参照できる人と使う目的が違います。問合せの画面で両者を混ぜない設計にします。

需要予測と契約条件の境目を示す

需要の推移は、問合せが増える時期や窓口の準備を考える材料になります。一方、顧客が契約内容を尋ねたときに答えとなるのは原契約と適用中の条件です。AIが過去の傾向からもっともらしい案内を作っても、個別契約の記載と一致するとは限りません。

窓口の担当は需要情報を集計した画面と、契約照会の画面を分けて扱います。回答案には契約のどの項目を見たかを付け、予測値を請求や手続の説明の根拠にしません。需要に関する文と契約に関する文の出所が異なれば、送信前に差し戻せます。

社内の需給連絡を顧客向けの説明に使うときも、外へ伝えてよい範囲を確認します。集計の目的で作られた数値が、そのまま個別の供給条件を意味するわけではありません。

顧客別の照会を集計値で置き換えない

同じ問合せ分類に入る顧客でも、契約の種類や変更履歴が異なります。よくある質問への一般案内は公開情報から作れますが、顧客本人の照会は個別の原記録を確かめます。集計結果を「標準的な契約」として回答文に入れると、相手の契約と食い違う可能性があります。

AIに顧客別の情報を渡す前に、問合せの目的と必要な項目を窓口で絞ります。回答後は照会履歴に参照した原契約の版を残し、次回に別の担当が同じ内容を繰り返さないようにします。入力範囲の決め方は生成AIの社内ルールにも通じます。

問合せ分類に例外を残す

分類が決まらない問合せを無理に定型回答へ入れません。公開情報の説明で済むものと、担当部署の確認が必要なものを分岐させます。

案内文の下書き対象を公開情報に絞る

事業者の手続や窓口の連絡先など、公表された内容を探して案内文の土台にできます。ただし登録申請の説明と顧客からの契約照会は同じ文面で返せません。AIに渡す参照先を明示し、公開ページの更新日と手続の種類を確認します。

下書きの文章が読みやすくても、具体的な契約変更の可否を含んでいれば送信前に止めます。問合せの分類を理由に自動送信せず、回答範囲を担当者が確認します。定型文の改訂時には古い版を候補から外し、窓口が今使う文面を指定します。

個別事情のある照会を担当窓口へ渡す

契約変更、供給に関する個別の事情、過去の回答との食い違いがあれば、要約だけで結論を出しません。顧客の質問文を残し、窓口担当が確認した契約情報とともに専門の担当部署へ渡します。AIの分類名が同じでも、必要な調査や回答者は案件によって変わります。

引継ぎ先には「確認待ち」の状態を明示し、回答期限と連絡予定を記録します。顧客に伝えた途中経過と社内の作業メモを混ぜないようにすると、未確定の案内が送信済みに見える事故を防げます。例外を処理した結果は元の照会番号へ戻します。

担当部署から返った回答に新しい条件が含まれるなら、窓口の古い案内文を更新します。今回の顧客だけに当てはまる扱いは共通の定型文へ広げず、照会番号に限定して保存します。

回答の根拠を照会履歴で確かめる

回答を送る前に、どの契約条件と案内を参照したかを記録します。文案の修正履歴だけでは、内容の正しさを後から確かめられません。

参照した契約条件を案内文に対応付ける

回答文の各段落が何を説明しているかを見て、原契約の該当箇所や確認した担当を結びます。複数の契約が関係する照会なら、どの条件をどの範囲に適用するかを区別します。AIの要約に条件の例外が抜けたときは、担当者が原文を開いて補います。

顧客に伝える文面には、内部向けの推測や未確認の処理予定を含めません。契約内容を変える可能性がある回答は、担当部署の確認を経て確定します。確認経路の設計はAIガバナンス体制の作り方にもつながります。

修正前の回答候補を送信済み扱いにしない

AIが作った文案と人が承認した文面は、同じ案件にあっても別の状態です。画面上で下書きが残っているだけでは送信されたことを意味しません。送信時刻、送信先、確定した版を照会履歴へ残して初めて、顧客への回答を追えます。

誤った候補を修正した場合は、削除だけで済ませず、なぜ直したかを担当者が記録します。次に似た照会が来たとき、過去の修正前の文面を再利用しないためです。過去の送信文も現行の契約条件に合うかを都度確かめます。

回答履歴を検索する際は、顧客区分や対象の契約時点を条件に加えます。文面が一致しただけの古い回答を候補として採ると、変更後の条件を見落とすためです。

例外処理を監査可能な形にする

通常の回答から外れた案件では、停止と再開の理由を時系列で見られるようにします。後から「なぜこの案内を送ったか」に答えられる記録が必要です。

停止した処理の理由を時系列で残す

契約の確認で差異が見つかったら、回答の作成を止めた時刻と理由を照会番号へ付けます。顧客からの追加情報、担当部署の回答、修正した案内文を順に並べると、再開の判断まで追えます。AIが原因を一つにまとめても、確認できた事実と推測を混同しません。

例外の案件が終わった後にも、最初に送ろうとした文案と差戻し理由を保管します。監査では最終文だけでなく、途中で何を止めたかが重要になるためです。回答候補を鵜呑みにしない確認はAIのハルシネーション対策でも扱います。

監査で確認する記録を担当別に整理する

窓口、契約担当、送信担当が別なら、各段階で誰が確認したかを区別します。問い合わせの受付から回答までを一つの長い要約にすると、判断の境目が消えます。契約の版、例外の判断、送信記録を別の欄でつなぎ、必要な原資料へ戻れるようにします。

監査で差異が判明した場合は、送信済みの顧客と未送信の案件を分けて対応します。AIの検索条件を直すだけでは既に伝えた内容は訂正できません。対応結果を照会履歴へ返し、次に同じ条件で案内文を作る際の確認点を更新します。

まとめ

電力小売のAI活用は、需要情報から個別契約の回答を推測しないことから始まります。公開された手続の案内、顧客の照会、原契約を分けて読み、回答の確定と送信は担当者の履歴で示します。例外が出た案件は停止理由から再開、送信までの経過を残すと、後の照会や監査で根拠を追えます。