ガス・電気の小売事業者に届く料金・検針の問い合わせに、料金表と請求の明細から回答の下書きを作る

処理の起点を決める

オペレーターが問い合わせの画面で「下書きを作る」を押した時点を起点にします。 押す前に、お客さま番号と対象の月（料金計算上の使用月）を画面で確かめてもらいます。問い合わせの登録だけで自動に動かさないのは、対象の月の取り違えを防ぐためです。 「今月の請求」と書かれていても、請求書が届いた月なのか、検針の対象の月なのかで、開くべき明細が1か月ずれます。

押した時点の明細を使います。 料金計算のシステムで請求の訂正が入ることがあるので、夜間にまとめて下書きを作っておく方式は取りません。 朝の時点の下書きが、昼に訂正された明細とずれていると、正しい数字の入った誤った説明になります。

同じ問い合わせで2回目を押したときは、前の下書きを残したまま新しい下書きを作ります。 オペレーターが比べられるようにし、どちらを使ったかを記録に残します。

入力データを集める

質を決めるのは、明細が項目ごとに取れることと、料金表に適用期間があることです。 明細が合計しか取れなければ差額を分けられず、料金表に適用期間が無ければ、改定をまたぐ月の説明が今の単価になります。

30分ごとの使用量の記録は渡しません。 1日のうちいつ電気を使ったかは、生活の様子そのものです。「使用量が増えた」という説明には日ごとの合計で足ります。

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

料金表は、検針期間のどの日の版を使うかを決めておきます。 検針期間の途中で料金が改定された場合、料金計算のシステムが日割りで計算しているはずです。明細にその区分が出ているならそれに従い、出ていなければ「改定をまたぐ月」の印だけを付けて、説明はオペレーターに任せます。

前年同月の明細が無いお客さま（契約から1年未満）には、前月とだけ比べます。 比べた月を差し込みの印として下書きに出すので、お客さまにも何と比べたかが伝わります。

AIへ渡す前に整形する

1. 差額の分解 … 対象の月と比べる月の明細から、次の4つの差を計算します

- 使用量の差による分（比べる月の単価で、使用量の差を掛けたもの） - 単価の差による分（燃料費調整の単価と従量の単価の変化） - 日数の差（検針期間の長さの違い。1日あたりの使用量もあわせて出す） - 割引・値引きの有無の差

1. 検針の注意点の印 … 推定での検針、計量器の交換、検針期間が通常より長い・短い、指示数の桁あふれ（一巡）を印にします
2. 保安の言葉の検知 … 「におい」「漏れ」「警報器が鳴る」などがあれば、以降の処理を止めて保安の窓口へ回します
3. 個人情報の除去 … 氏名・住所・電話番号・メールアドレスは AI に渡す本文から伏せます
4. 差し込みの印の一覧を作る … 使ってよい値を current.usage prev.amount_total diff.by_usage のような名前の付いた表にします

1番目の分解は、合計が合うように作ります。 4つの差を足したものが、合計の差と一致することをプログラムで確かめます。一致しなければ、明細に想定外の項目があるので、下書きを作らずにオペレーターへ知らせます。

AI に渡す差額の表は、次のような形です。値の列はプログラムが明細から入れ、AI は印の名前の列だけを使って文章を書きます。

表には符号も入れておきます。 単価が下がって使用量が増えた月は、要因どうしが打ち消し合います。「増えた要因」と「減った要因」を両方並べないと、合計の差だけでは説明がつきません。

3番目は、AIの判断に頼りません。 ガスのにおいの申し出を文面対応の列に並べておくこと自体が、危険です。言葉の一覧で拾い、拾い過ぎは許容します。

AIに処理させる

させるのは、問い合わせの種類を選ぶこと、差額の表と検針の注意点から、問い合わせに沿った説明を書くこと、数字を差し込みの印で書くこと、担当へ回すべきかを示すことです。

1行目がこの構成の要です。 数字を直接書かせない理由は、AIの計算が苦手だからというより、明細の値をそのまま写す工程を、人の手からも AI の手からも外すためです。

3行目の「断定しない」も明記が要ります。 使用量が前年の倍になっていれば、AIは「計量器の不具合の可能性があります」と書きたがります。お客さまにとって、それは「会社が誤りを認めた」と読めます。 推定での検針や計量器の交換の印があっても、書くのは「担当より改めてご連絡します」までにします。

指示内容を固定する

あなたは電気・ガスの小売事業者のお客さまセンターで、
料金と検針の問い合わせに回答の下書きを作る担当です。
下書きはオペレーターが確かめてから送ります。

【使ってよい情報】
- 【差額の表】【検針の注意点】【料金表の抜粋】【お知らせ】だけ
- 数字はすべて【差し込みの印の一覧】の名前で書いてください
  例：{{current.usage}}、{{diff.by_unit_price}}
- 一覧に無い印を作らないでください

【やること】
1. 問い合わせの種類を category から1つ選ぶ
   bill_change / meter_reading / proration / payment / other
2. 問い合わせが聞いていることに、最初の段落で答える
3. 差額の表の要因を、差額の大きい順に説明する
   比べた月を必ず書く（{{compare.month}}）
4. 検針の注意点に印があれば、その旨を伝え、担当から連絡すると書く

【厳守事項】
- 数字（金額、使用量、単価、日数、日付）を直接書かないでください。
  必ず差し込みの印で書いてください。
- 差額を計算し直さないでください。差額の表の値をそのまま使ってください。
- 検針の誤り、計量器の不具合、請求の誤りを断定しないでください。
  「確認のうえ、担当よりご連絡いたします」と書いてください。
- 返金、減額、支払の猶予を約束しないでください。
- 料金表の抜粋に無い料金の仕組み（他のメニュー、他社の料金）を
  説明しないでください。
- 問い合わせに書かれていない生活の事情（家族の人数、在宅の時間など）を
  推測して書かないでください。
- お客さまを責める言い方（「使いすぎ」など）をしないでください。
- 保安（ガスのにおい、漏れ）に関わる記述に気づいたら、
  escalate に safety と入れ、本文を書かないでください。

【問い合わせ（個人情報は伏せ字済み）】{inquiry_text}
【契約の料金メニュー】{plan_name}
【差額の表】{diff_table}
【検針の注意点】{meter_flags}
【料金表の抜粋】{tariff_excerpt}
【お知らせ】{notices}
【差し込みの印の一覧】{placeholder_list}

「差額を計算し直さない」は、数字を書かない指示とは別に必要です。 数字を印で書くよう言っても、AIは「{{current.amount_total}}から{{prev.amount_total}}を引くと」と計算の手順を文章で書くことがあります。差額の表に値があるので、その印を使えば足ります。

「推測して書かない」は、説明を親切にしようとして起きる失敗を止めます。 冬の使用量の増加に「ご家族が在宅の時間が増えたことなどが考えられます」と書くと、事実ではないことを会社の名前で書いたことになります。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "category": "bill_change | meter_reading | proration | payment | other",
  "answer_draft": "",
  "placeholders_used": [""],
  "factors_order": ["usage | unit_price | days | discount"],
  "escalate": "none | meter_check | refund_request | safety | operator_judgment",
  "escalate_reason": ""
}

1つ目の理由は、placeholders_used で置き換えの検査ができることです。 本文に出てくる {{...}} と、placeholders_used と、差し込みの印の一覧の3つを突き合わせます。一覧に無い印が1つでもあれば、作られた値の入る場所があるということなので、下書きを止めます。

2つ目は、escalate を列挙型で縛れることです。 構造化出力では列挙型が使えます。再検針の手配や返金の検討に回す件数を、この値で毎日数えます。

3つ目は、factors_order で説明の順番を検査できることです。 差額の表で最も大きい要因が先頭に来ていなければ、オペレーターに印を付けます。大きな要因を後回しにした説明は、正しくても納得されません。

スキーマの書き方には制約があります。 公式ページでは、すべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定すること、文字列の pattern や配列の minItems などがサポートされないことが書かれています。「本文に数字が無いこと」はスキーマで表せないので、後段の正規表現で見ます。

システムへ連携する

下書きの置き換え後の文面は、下書きの欄に入れます。 送信の欄には入れません。オペレーターが下書きを写して直し、送信の操作をします。

担当への依頼も、オペレーターの操作にします。 escalate が meter_check でも、自動で再検針を手配しません。お客さまが求めていない現地の訪問が入ると、それ自体が問い合わせの種になります。

人が確認する

全件、オペレーターが読んでから送ります。 送らずに下書きを捨てる判断も、オペレーターに任せます。

1. 比べた月を確かめる … 下書きの冒頭に出る比べた月が、問い合わせの意図と合っているかを見ます
2. 最大の要因が先頭にあるかを見る … 印が付いていれば、順番を直します
3. 検針の注意点を読む … 推定での検針や計量器の交換があれば、担当へ回すかを決めます
4. 言い回しを確かめる … 断定や約束になっていないか、お客さまを責めていないかを読みます
5. 送る … 直した箇所は記録に残ります

1番目を省かないでください。 対象の月を1か月取り違えると、下書きの数字はすべて正しい明細の値なのに、問い合わせと関係のない月の説明になります。数字の検査では見つからない誤りです。

目標は、1件あたり7分です。 画面を行き来する時間と、差額を電卓で分ける時間がほぼ無くなります。読む・直す・判断する時間は残ります。

例外に対処する

2行目は、明細の項目が増えたときに起きます。 新しい値引きや一時的な調整の項目が始まると、分解の計算が知らない項目を取りこぼします。合計が合わないことで気づけるように、検算を必ず入れます。

8行目は、セット契約で起きやすい失敗です。 電気とガスの差額を1つの表にまとめると、ガスの使用量の単位（立方メートル）と電気の単位（キロワット時）が混ざった説明になります。

記録を残す

• 問い合わせの原文と、AI に渡した伏せ字後の本文
• 使った明細（3か月分）と検針の記録、料金表の版と単価の、取得した時点の値
• 差額の表と検算の結果
• Azure OpenAI の出力の JSON と、置き換え前・後の下書き
• オペレーターが直した箇所の差分と、送った文面
• escalate の値と、担当へ回したかどうか

2つ目で「取得した時点の値」を残すのは、明細が後から訂正されるためです。 訂正の前の値で説明していたなら、送った回答は当時としては正しかったことになります。後から苦情を受けたとき、当時の明細が残っていないと説明できません。

5つ目の差分は、プロンプトの手直しの材料です。 オペレーターが毎回書き足している説明（たとえば検針期間の日数の違い）があれば、差額の表の出し方か指示を直します。