宅内漏水による水道料金の減額申請書と修理証明を読み取り、検針の記録と照らして要件に合わないものと不足書類を拾う

処理の起点を決める

受付フォルダにPDFが保存されたことを起点にします。 1件ずつ動かし、処理が終わったものだけを処理済みフォルダへ移します。受付フォルダに残っている数が、未処理の数になります。

1件分を1つのPDFにまとめることを、受付の決まりにします。 申請書と証明書が別々のファイルになると、どの証明書がどの申請のものかを後から使用者番号で探すことになり、番号が読めなかった1枚が宙に浮きます。 郵送の封筒単位、窓口の受付単位でまとめます。

検針の直後の繁忙期も、夜間の一括処理にはしません。 不足書類の連絡を早く出すほど、次の検針までに書類がそろいます。

入力データを集める

質を決めるのは、いちばん下の要件の表です。 静岡市のページでは、給水栓の故障、水洗便所の洗浄装置の故障、施工した日から1年以内の漏水、過去の使用水量の方が多い場合などを対象外として挙げています。長野市は受水槽のボールタップの故障を条件付きで対象にしています。同じ「トイレ」でも局によって扱いが違うので、自局の要綱から表を作ります。

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

読み取りは Form Parser のオンライン処理で呼びます。公式の上限では、Form Parser のオンライン処理は15ページまで、ファイルは40MBまでです。1件分は数ページなので収まります。

キーは書類に書かれた文字そのものです。 応答の扱いの説明では、キーと値のペアは設定した項目名ではなく、書類上のキーの文字がそのまま返るとされています。「お客さま番号」「使用者コード」「水栓番号」のように局の様式の文字を、Python 側の対応表で項目名に寄せます。

お客さま番号は表として返ることがあります。 京都市の様式では、検針区・使用者コード・水栓番号が1行の表です。Form Parser の表の抽出は、行や列をまたぐセルの無い表だけを認識するとされています。様式の表はこの形なので読めますが、手で罫線を引き足した用紙は崩れます。

料金システムの書き出しは、毎朝の一括の書き出しを Python が読みます。照合は使用者番号が先、氏名と住所が後です。 氏名から引くと、契約者と申請者が違う家（賃貸住宅など）で引けません。

AIへ渡す前に整形する

1. ページの種類分け … 申請書・証明書・写真を、様式のタイトルの文字と画像の割合で分けます
2. 解像度の確認 … 公式の説明では、スキャンは最低200dpi、300dpi以上が一般に最もよいとされています。200dpiを下回るものはスキャンし直します
3. 画像の大きさ … PDF以外の画像は1ページ40メガピクセルが上限です
4. 選択の形の確認 … 区分を丸で囲む様式は、チェック欄として返りません。様式を改めるまでは、区分の欄の文字と丸の位置を生成AIに読ませ、needs_human に寄せます
5. 印字と手書きの区別はしない … どちらも同じ処理に流します。信頼度で後から分けます
6. 重複の検知 … 同じ使用者番号・同じ修繕日の申請が直近にあれば、二重の受付として印を付けます
7. 写真のページ … OCRに回さず、枚数と撮影の有無だけを記録します。写真の中身の判断は職員が行います

4番目は様式の側で直すのが早道です。 減量の事由の欄を、丸で囲む形から四角のチェック欄に変えるだけで、区分が文字の読み取りではなく filled_checkbox で決まります。 様式の改定は工事店への周知が要るので、半年ほどかけて切り替えます。

AIに処理させる

させるのは、読み取った項目を決まった名前にそろえることと、漏水箇所の自由記述を区分に当てはめて、根拠の文字列を写すことだけです。

漏水箇所の区分がいちばん難しく、いちばん大事です。 「屋外 給湯器下 地中 エルボ割れ」は、器具の名前が出てきますが漏水は地中の配管です。逆に「給湯器 本体より漏水」は器具の故障です。器具の名前と、壊れた部材の位置の両方を写させ、区分はその2つから決めさせます。

最後の行がいちばん起きやすい失敗です。 使用者番号の1桁が読めないとき、生成AIは料金システムにありそうな番号へ寄せたくなります。寄せた番号は、照合で「一致」になってしまいます。

指示内容を固定する

あなたは水道局の料金課で、漏水による使用水量の減量の申請書類を
受け付ける立場です。OCRが返した読み取り結果だけを見て、
決められた項目に値をそろえてください。推測で埋めないでください。

【そろえる項目】
1. customer_no（使用者番号。申請書と証明書の両方から）
2. applicant_name、address、phone
3. repair_date（修繕年月日。YYYY-MM-DD にそろえる）
4. leak_location_text（漏水箇所の記述をそのまま）
5. leak_category（underground / under_floor / in_wall /
   fixture / other / ambiguous のどれか）
6. fixture_words（給水栓、便器、タンク、給湯器、ボールタップ等の語）
7. contractor_name、contractor_no（事業者名と指定番号）
8. pages（申請書・証明書・写真の枚数）

【leak_category の決め方】
- 記述に「地中」「埋設」「土中」があり、壊れた部材が配管であれば
  underground。「床下」「壁中」「壁内」も同じ考え方で決める
- 給水栓、便器、タンク、給湯器などの器具そのものが壊れたと
  書かれていれば fixture
- 器具の名前があっても、壊れたのが器具の下や近くの配管なら
  fixture にしない。たとえば「給湯器下 地中 エルボ割れ」は underground
- どちらにも読めるときは ambiguous。迷ったときに underground を
  選ばないでください
- チェック欄の valueType が filled_checkbox の区分があれば、
  それを checkbox_category に写し、記述から決めた区分と並べる

【厳守事項】
- 記載がなければ「不明」とし、status を missing にしてください。
- 読み取りの confidence が 0.7 未満の値は status を unreadable にし、
  値はOCRが返したまま入れてください。
- 使用者番号・指定番号は、読み取った文字列をそのまま入れてください。
  桁を補う、似た番号に直すことをしないでください。
- 減量の可否、対象かどうかの結論、減量する水量は書かないでください。
- evidence には、区分を決めた根拠の文字列をそのまま写してください。

【読み取り結果】{ocr_result}
【様式のキーと項目名の対応表】{key_map}

「器具の名前があっても fixture にしない」を例付きで書かないと、器具の語に引きずられます。 第3章の（b）の読み違いは、人も生成AIも同じ形で起こします。例を1つ書くだけで、区分の揺れはかなり減ります。

checkbox_category と記述からの区分を並べさせるのは、食い違いを拾うためです。 「地中」に印があるのに記述が「便器のタンク内部品の交換」なら、どちらかが誤りです。食い違いはそれだけで needs_human にします。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力では、output_config.format に JSON スキーマを渡して応答の形を固定できます。

{
  "receipt_id": "",
  "customer_no": { "application": "", "certificate": "", "status": "ok | missing | unreadable | mismatch" },
  "repair_date": { "value": "", "status": "ok | missing | unreadable | ambiguous" },
  "leak": {
    "location_text": "",
    "leak_category": "underground | under_floor | in_wall | fixture | other | ambiguous",
    "checkbox_category": "",
    "fixture_words": [],
    "evidence": ""
  },
  "contractor": { "name": "", "contractor_no": "", "status": "ok | missing | unreadable" },
  "pages": { "application": 0, "certificate": 0, "photo": 0 }
}

1つ目の理由は、AIが書く層と規則が書く層を分けられることです。 上のJSONはAIが埋め、要件の照合結果は Python が別の層に書き足します。

2つ目は、verdict の決め方を表で持てることです。

3つ目は、evidence で確認が速くなることです。 職員は画像を開く前に、区分を決めた文字列を一覧で読めます。

システムへ連携する

料金システムへの書き込みは作りません。 減量の算定と調定は、職員が決裁を経て料金システムの画面で行います。一覧の誤りが、そのまま請求額の変更に進む経路を持たせないためです。

不足書類の連絡文は下書きまでです。 使用者に頼むもの（申請書の署名）と工事店に頼むもの（指定番号、写真、修繕日）を分けて下書きし、送るのは職員です。

人が確認する

1. needs_human を先に見る … 読めなかった値と区分の食い違いです。画像を開いて、該当の欄だけを見ます
2. out_of_scope_candidate の根拠を確かめる … evidence と検針の数字を見ます。対象外とするのは職員の判断で、通知の文面も職員が書きます
3. missing_docs の連絡先を決める … 使用者か工事店か。下書きを直して送ります
4. candidate は一覧で流し見る … 修繕日と区分だけを見て、算定に回します
5. 判断を覆したら記録する … どの項目を、どちらに変えたかを残します

2番目を省かないでください。 対象外と通知すれば、使用者は高い請求額をそのまま払うことになります。読み違いの1件は、苦情と再審査の手間になって返ってきます。

目標は、120件をならして1件7分です。 candidate は数分で済み、out_of_scope_candidate と needs_human に時間を使います。

例外に対処する

上の2行は、料金の誤りに直結します。 別の家の検針の記録で判断すると、要件に合うかどうかが入れ替わります。使用者番号の一致は、規則の判定より前に必ず確かめます。

記録を残す

• 申請のPDFと、受け付けた日・経路（郵送・窓口）
• Document AI が返したJSONの全文と、Claude API の出力
• 照合に使った料金システムの書き出しの日付と、そのときの検針の数字
• verdict と、職員が下した判断、覆した項目
• 不足書類を連絡した日、相手、書類がそろった日
• 漏水箇所の区分ごとの件数と、職員が区分を直した件数

3つ目を残すのは、検針の数字が後から変わることがあるからです。 検針の訂正があると、過去の判断の根拠が変わります。当時の数字が残っていないと、再審査の説明ができません。

最後の行は、プロンプトと様式の見直しの材料です。 職員が fixture を underground に直した件数が多ければ、指示の例が足りていません。