ビル管理会社が手書きで記録するテナントの電気・水道の検針票を読み取り、検針値を台帳に転記して、前月比の異常と請求の元データを作る

処理の起点を決める

各ビルのスキャンの PDF が保管先（Azure Blob Storage）に入ったことを起点にします。 検針は毎月の決まった日の前後に28棟で行われ、検針票は数日に分かれて届きます。届いた順に読み取り、確認の一覧に足していきます。

起点の仕組みは Azure Functions の Blob Storage のトリガーです。公式のページでは、トリガーにはイベント方式とポーリング方式があり、遅れの小さいイベント方式が推奨されています。ポーリング方式を従量課金のプランで使うと、止まっていた後の新しいファイルの処理に最大10分の遅れが出うるとされています。検針票は数日かけて届くので遅れは問題になりませんが、取りこぼしを避けるためにイベント方式を選びます。

ファイル名にビルのコードと検針の年月を入れる決まりにします。 「B07_202610_1.pdf」のようにしておけば、どのビルのどの月の検針票かを、中身を読む前に決められます。同じビルの同じ月のファイルが二度届いたら、新しい方を「再送」として扱います。

入力データを集める

質を決めるのは、メーターの台帳の桁数です。 指針が6桁のメーターに7桁の数字が読めたら、それだけで読み違いと分かります。桁数を持たせておけば、文字の形を見なくても判定できる誤りが一つ増えます。

過去13か月の使用量は、前年同月と比べるために持ちます。 空調の電気や飲食店の水道は季節で大きく変わるので、前月とだけ比べると、夏の初めの月が毎年「異常」になります。

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

読み取りは、Azure Functions からカスタム テンプレート モデルを呼ぶだけです。モデルの学習には、全ビル共通の検針票の様式で、指針を書き込んだ見本を使います。

検針票の区画の並びは、表の項目としてラベル付けします。 公式のページでは、テンプレート モデルは表の項目に対応し、ページをまたぐ表も、各ページの行を1つの表としてラベル付けすれば扱えるとされています。区画の多いビルでは検針票が2枚になるので、この扱いが要ります。

信頼度は2層で見ます。 公式のページでは、カスタム モデルの項目の信頼度は値の位置についてのもので、文字の読み取りの信頼度や選択マークの信頼度もあわせて見て総合するよう書かれています。指針の項目の信頼度と、指針を構成する単語の信頼度の低い方を、その指針の信頼度として使います。

AIへ渡す前に整形する

1. ファイル名の確認 … ビルのコードと年月が決まりどおりかを確かめ、外れたものは人へ回します
2. 向きと傾きの確認 … 上下逆や大きく傾いたページを直します
3. 寸法と解像度の確認 … 画像は50×50〜10,000×10,000ピクセル、文字の最小の高さは1024×768の画像で12ピクセル（150dpiで約8ポイント）です。手書きの数字は小さく書かれがちなので、200dpi以上でそろえます
4. ページ数とファイルの大きさ … PDF は2,000ページまで、有料（S0）レベルで500MB、無料（F0）レベルは最初の2ページだけです。試すときに無料のレベルを使うと、2枚目の検針票が読まれません
5. パスワード付きの PDF の確認 … 解除が要るので、複合機の保存の設定を見直します
6. ページの対応づけ … 1枚目・2枚目の区画の範囲を、検針台帳の並びと照らします

4番目は試しの段階でつまずく点です。 区画の多いビルだけ結果が足りない、という形で現れます。

AIに処理させる

読み取りのモデルにさせるのは、区画ごとの今回の指針と、印の欄と、備考の領域を返すことだけです。 それ以外は、プログラムの規則で行います。

判定は次の規則で決めます。

変化率の幅は、区画の種別ごとに分けます。 事務所の電気と飲食店の水道では、月ごとのぶれ方がまったく違います。最初の数か月は幅を広めにとり、check に回った区画のうち本当に異常だった割合を見て狭めます。

1行目がいちばん起きやすい失敗です。 「1」か「7」か迷った桁を、前月の指針に近くなるほうに寄せたくなります。寄せた瞬間、前月比の確認が働かなくなります。 比べる相手の数字に近づけて読んだのですから、変化率が幅の中に収まるのは当然です。

指示内容を固定する

この構成では、生成AIへのプロンプトは使いません。 代わりに、読み取りのモデルの見本づくりと、規則の決めごとが「指示」に当たります。見本のラベル付けの決まりは次のとおりです。

【検針票の見本のラベル付けの決まり】

1. 見本は少なくとも5枚。うち2枚は区画が2枚目にまたがるビルの検針票にする
2. 指針は数字の部分だけを囲む。単位（kWh、m3）や区切りの線を含めない
3. 区画の行は表の項目「meter_rows」として、1枚目と2枚目の行を1つの表にまとめる
   列：area_name（区画名・印字） / meter_no（メーター番号・印字） /
       reading（今回の指針・手書き） / mark_no_entry（立入不可） /
       mark_display_error（表示不良） / mark_replaced（メーター交換）
4. 印の欄は選択マークとしてラベル付けする。印の付いた見本と、付いていない見本の両方を入れる
5. 指針の欄が空の行も、空のままラベル付けする（「空であること」を学ばせる）
6. 備考は領域の項目「remarks」として、欄の枠の内側だけを囲む
7. 書き直し（二重線と書き足し）のある見本を、少なくとも1枚入れる
8. 見本の指針は実際の値を使う。でたらめな数字を書き込まない

5番目を省くと、空欄の区画で何かを読もうとします。 公式のページでは、値の無い項目の信頼度について、見本の中で空であることが多い項目なら、空の予測に高い信頼度が付くと書かれています。空欄の見本を入れておくことが、「書かれていない」を正しく返させる条件です。

8番目も公式のページに沿った決まりです。 見本の値は多様で実際的であるべきで、でたらめな文字列は性能に響きうるとされています。

規則の側の決めごとは、表にして経理と管理員の責任者が承認します。

【使用量の確認の規則（区画の種別ごと）】
種別 / 前月比の幅 / 前年同月比の幅 / 前回より小さい指針の扱い
事務所・電気 / ±30％ / ±30％ / check（メーターの一巡なら交換記録を確かめる）
飲食・水道 / ±50％ / ±40％ / check
物販・電気 / ±35％ / ±30％ / check

判定の処理は、次の順に書きます。 順番を変えると、桁数の合わない数字で変化率を計算して、意味の無い out_of_range が出ます。

for 区画 in 読み取り結果の行:
    台帳の行 = 検針台帳から (ビル, 区画名, メーター番号) で引く
    if 台帳の行が無い:            → check（unknown_meter）
    if 指針が空:                  → missing（印の種類 または no_reading）
    conf = min(項目の信頼度, 指針の単語の信頼度の最小値)
    if conf < 基準:               → reasons に low_confidence
    if 桁数 ≠ メーターの台帳の桁数: → reasons に digits_mismatch、ここで計算をやめる
    if 今回 < 前回:               → reasons に below_previous、ここで計算をやめる
    使用量 = (今回 − 前回) × 乗率
    前月比・前年同月比を計算し、種別ごとの幅の外なら reasons に out_of_range
    reasons が空なら ok、そうでなければ check

「ここで計算をやめる」が2か所あるのは、誤った使用量を一覧に載せないためです。 桁数が合わない指針から計算した使用量は、前月の何十倍にもなります。その数字が一覧に出ると、経理はまず使用量に目を奪われ、本当の原因である読み違いを見るのが遅れます。

出力形式を固定する

区画1件ごとに、次の形の JSON にまとめて確認の一覧に流します。

{
  "building": "B07",
  "period": "2026-10",
  "area": "3F-302",
  "tenant": "",
  "meter_no": "E-0731",
  "kind": "electric | water",
  "reading": { "value": "", "confidence": 0, "digits_ok": true },
  "previous_reading": 0,
  "multiplier": 1,
  "usage": 0,
  "change_vs_last_month": 0,
  "change_vs_last_year": 0,
  "marks": { "no_entry": false, "display_error": false, "replaced": false },
  "remarks_image": "B07_202610_1_p1_remarks.png",
  "verdict": "ok | check | missing",
  "reasons": ["low_confidence", "digits_mismatch", "below_previous", "out_of_range", "unknown_meter", "no_reading"]
}

1つ目の理由は、reasons で確かめる場所が分かることです。 check だけでは、経理は何を見ればよいか分かりません。below_previous なら交換の記録を、low_confidence なら画像の数字を、out_of_range なら現地の事情をというように、確かめ方が理由ごとに違います。

2つ目は、読み取りの値と計算の値を分けて持てることです。 reading は読み取りのモデルが返したもの、usage と変化率はプログラムが計算したものです。経理が指針を直したら、usage と変化率は計算し直すだけで済みます。

確認の一覧は、ビルごと・理由ごとに並べます。

【確認の一覧（2026年10月分 B07）】
区画 / メーター番号 / 今回の指針 / 信頼度 / 使用量 / 前月比 / 前年同月比 / 理由 / 画像

システムへ連携する

検針台帳へは、確かめる前に書き込みません。 読み取りの誤りがそのまま台帳に入ると、翌月の「前回の指針」が誤った値になり、翌月の使用量まで狂います。 確定は人が行います。

人が確認する

人が開くのは check と missing の区画だけです。 ok の区画は、ビルごとの件数と使用量の合計を前月と見比べるだけにします。

1. missing の理由を見る … 「立入不可」なら翌月の扱いを決めごとどおりに記録し、「記入漏れ」なら管理員に再検針を頼みます
2. check の画像を見る … 指針の数字を画像で確かめ、読み違いなら直します
3. below_previous は交換の記録を見る … メーター交換の印や、メーターの台帳の取り付けた日を確かめます
4. out_of_range で数字が正しいときは、現地の事情を聞く … 漏水や設備の不具合のこともあるので、管理員に伝えます
5. 直した区画を記録する … 読み取りの値と直した値の両方を残します

4番目を経理だけで閉じないでください。 数字が正しくて使用量が跳ねているなら、テナントに請求を出す前に、管理員が現地を見るべき事象です。

例外に対処する

上から3行目までが、この題材の大半の check です。 どれも読み取りの誤りではなく、メーターの側の事情です。交換と一巡の記録を台帳に持っておくと、確かめが速くなります。

記録を残す

• 検針票の画像と、届いた日時・ビル・年月
• 読み取りの結果の JSON の全文（指針・印・信頼度・単語の信頼度）
• 判定（verdict、reasons）と、そのとき使った確認の規則の版
• 人が指針を直した記録 … 読み取りの値、直した値、直した人、理由
• 再検針の依頼と、その結果
• ビルごと・管理員ごとの low_confidence の発生率

4つ目は、請求の根拠になります。 テナントから問い合わせがあったとき、検針票の画像、読み取った値、直した値と理由をすぐに出せれば、説明の時間が短くなります。