店舗ごとに紙やPDFで届く電気・ガス・水道・通信の請求書を読み取って拠点別の費用台帳に転記し、前月・前年同月より増え方の大きい拠点を拾う

処理の起点を決める

受領フォルダにファイルが保存されたことを起点にします。 受領フォルダは Azure Blob Storage のコンテナーにし、Azure Functions の Blob ストレージ トリガーで受けます。トリガーにはイベントベースとポーリング型があり、イベントベースのほうが遅延が小さく推奨とされています。

1枚ずつ動かし、月末にまとめて処理しません。 請求書は相手先ごとに届く日がばらばらです。届いた日に読み取って比べれば、漏水のような急増に、その月のうちに気づけます。 第3章の（d）への答えはここにあります。

月に1回、締めの処理も動かします。 毎月10日など決めた日に、今月分の請求書がまだ届いていない拠点と種別を契約マスタから洗い出します。届いていない請求書は、読み取りを起点にした処理では見えないからです。

入力データを集める

質を決めるのは、契約マスタの「契約の番号」の列です。 ここが埋まっていないと、第3章の（a）がそのまま残ります。最初の作業は、この列を埋めることです。 過去の請求書を読み取った結果から、番号の候補を作って総務が確かめる、という順番で埋められます。

拠点の出来事は、比較の結果を読むための材料です。 改装で営業時間が延びた月に使用量が増えるのは当然で、それを知らずに一覧を見ると、毎月同じ拠点に問い合わせることになります。

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

読み取りは、Azure Functions から請求書モデル（prebuilt-invoice）を呼ぶだけです。返ってくるJSONは3つに分かれ、documentResults に請求書固有の値と品目、pageResults に表とセルと信頼度、readResults に認識された全テキストが入ります。キーと値のペアの返却は既定で無効なので、オプションで有効にします。

拠点を決める順は、契約の番号、供給場所の住所、宛名の順です。 番号が契約マスタに一致すれば、それで決めます。番号が取れないか一致しないときだけ住所で引き、住所で1つに決まらなければ確認待ちにします。 同じ商業施設に2店舗あるような場合を、住所で無理に決めないためです。

前月と前年同月の値は、拠点別の費用台帳から拠点コードと種別で引きます。台帳は下書きの行と確定の行を分けて持ち、比較には確定の行だけを使います。

AIへ渡す前に整形する

1. 形式の確認 … 請求書モデルの入力はPDFと画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）です。会員サイトからCSVで取れる相手先は、OCRを通さず直接取り込みます
2. ページ数とサイズ … PDFとTIFFは最大2,000ページ、有料（S0）レベルで500MBまでです。Free レベルは最初の2ページしか処理されません
3. パスワードの解除 … 会員サイトのPDFにパスワードが付く相手先があります。提出前にロックを解除する必要があります
4. 1ファイルに複数の請求書 … 店舗でまとめてスキャンされたものは、ページで分けます
5. 重複の検知 … 同じ契約の番号・同じ使用期間のものが既にあれば、二重に取り込みません
6. 解像度の確認 … 抽出するテキストの最小高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。検針票の小さな文字は、この下限に近いことがあります

6番目を軽く見ないでください。 水道の検針票は小さな用紙に細かい字で印字されていることが多く、使用量の数字だけが読めずに残ることがあります。店舗の複合機のスキャン設定を、本部で一度そろえておきます。

AIに処理させる

OCRが取れなかった値を、全テキストから取り出させることだけです。 拠点の決定、日数の計算、比較はコードで行います。

2行目と3行目がいちばん起きやすい失敗です。 番号の1桁が読めないとき、生成AIは契約マスタに近い番号へ寄せようとし、使用量が読めないときは金額から逆算して埋めます。 どちらも、見つけたかった誤りや異常を消してしまいます。

指示内容を固定する

あなたは経理担当です。公共料金・通信料金の請求書の読み取り結果から、
指定の項目を取り出します。読み取り結果に書かれていることだけを使ってください。

【取り出す項目】
utility_type / contract_numbers / usage / usage_unit /
period_start / period_end / charges

【厳守事項】
- utility_type は electricity / gas / water / telecom / unknown から選んでください。
- 契約の番号（お客さま番号、供給地点の番号、回線番号など）は、
  書かれた文字列をそのまま入れてください。桁を補ったり、記号を直したりしないでください。
  番号の種類が分かる場合は label に項目名を入れてください。
- 使用量は、請求書に書かれた数値と単位をそのまま入れてください。
  金額や単価から計算して埋めないでください。書かれていなければ null です。
- 使用期間は、請求書に「使用期間」「ご使用期間」などとして書かれた日付を入れてください。
  検針日しか書かれていない場合は、period_status を ambiguous にしてください。
- charges には、基本料金、使用量の料金、調整額、消費税など、
  請求書に内訳として書かれた行だけを入れてください。
- 拠点名や店舗名を推測しないでください。
- 各項目の evidence には、根拠にした文字列をそのまま写してください。

【請求書モデルが返した値】{invoice_fields}
【全テキスト】{read_text}

「金額や単価から計算して埋めない」を明記しないと、使用量が埋まります。 単価が書かれた請求書では、生成AIは金額を単価で割って使用量を出そうとします。埋まった使用量は正しそうに見えるので、読めなかったという事実が消えます。

出力形式を固定する

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

{
  "file_id": "",
  "utility_type": "electricity | gas | water | telecom | unknown",
  "vendor_name": "",
  "contract_numbers": [ { "label": "", "value": "", "evidence": "" } ],
  "period_start": null,
  "period_end": null,
  "period_status": "ok | ambiguous | missing",
  "usage": null,
  "usage_unit": null,
  "invoice_total": 0,
  "charges": [ { "label": "", "amount": 0 } ],
  "site": { "site_code": null, "match_by": "contract_number | address | none" },
  "comparison": {
    "per_day_usage": null, "per_day_amount": null,
    "vs_last_month_pct": null, "vs_last_year_pct": null,
    "flag": "none | increase | first_record | no_history"
  },
  "status": "ready | needs_review"
}

site と comparison は、生成AIではなくコードが埋めます。 生成AIに返させるのは utility_type から charges までで、Azure OpenAI の構造化出力で形を固定します。json_schema に strict: true を指定し、全フィールドを required にして、省略してよい値は null との組み合わせの型で表します。

per_day_usage で比べる理由は第1章のとおりです。 使用期間の日数で割り、前月と前年同月の同じ値と比べます。flag を increase にする基準は、たとえば次のように決めます。

計算の例を1つ挙げます。ある店舗の電気の請求書で、今月は使用期間が33日・使用量が9,900kWh、前年同月は29日・7,250kWhだったとします。

月の使用量で比べると約37％の増加ですが、1日あたりでは20％の増加です。 30％の基準なら、この店舗は一覧に載りません。期間が4日長かっただけの増加を、拠点への問い合わせに回さずに済みます。

基準の数字は例です。 割合だけで判定すると、もともと小さい拠点の小さな変化が毎月並びます。金額の下限と組み合わせることで、問い合わせる価値のある拠点だけが残ります。

システムへ連携する

台帳の下書きには、拠点・種別・月ごとに次の1行を足します。

原本へのリンクを行ごとに持たせるのは、確認の時間を短くするためです。 台帳の値に疑問を持ったとき、共有フォルダを探さずに1回で原本が開けます。

契約マスタへは書き込みません。 新しい番号が見つかっても、追加するかは総務が契約書と照らして決めます。 読み取った番号をそのまま足すと、読み誤った番号が正しい番号として残ります。

人が確認する

人が開くのは needs_review のものだけです。 ready のものは下書きの一覧で件数と拠点を流し見て、まとめて確定します。

1. 拠点が決まらなかったものを先に見る … match_by: none。契約マスタの番号の抜けが原因なら、総務に追加を頼みます
2. 信頼度の低い値を原本で確かめる … 使用量・金額・使用期間のどれかの信頼度が低いもの
3. increase の拠点を総務が確かめる … 拠点の出来事の表を見てから、店舗に事情を聞きます
4. 値を直したら記録する … どの請求書の、どの項目を直したかを残します

目標は、360枚をならして1枚2分です。 確認待ちが1〜2割という想定で、それを超える月は、店舗のスキャンの設定か契約マスタの番号の抜けを疑います。

例外に対処する

4行目の料金改定のお知らせは、捨てずに総務へ回します。 単価が変わった月は、使用量が同じでも金額が増えます。お知らせを見ていれば、その月の increase を問い合わせる前に理由が分かります。

記録を残す

• 元の請求書ファイルと、受け取った日時・経路
• 請求書モデルが返したJSONの全文と、生成AIが返したJSON
• 拠点の決め方（match_by）と、そのとき参照した契約マスタの行
• 1日あたりの値と比較の結果、flag
• 人が値や拠点を直した記録
• increase の拠点に確かめた結果（理由、対応）

最後の行は、翌年の比較の材料になります。 去年の8月に漏水で増えた拠点は、今年の8月の前年同月比が大きく下がって見えます。理由が残っていれば、その下がり方を正しく読めます。