市民課に郵送で届く手書きの証明書の請求書を読み取り、請求者・種類・通数・同封の定額小為替を受付台帳にそろえて、記入漏れと不足額を拾う

処理の起点を決める

Cloud Storage のバケットにスキャン画像が保存されたことを起点にします。 Cloud Run では、Eventarc を通じて、オブジェクトが作成・上書きされたとき（google.cloud.storage.object.v1.finalized）にサービスや関数を呼び出せます。関数とバケットは同じ Google Cloud のプロジェクトに置く必要があります。

スキャンは、封筒1通分を1つのPDFにまとめるのが決まりです。請求書と小為替と本人確認書類が別のファイルになると、どれが同じ請求かを後から結びつける手間が生じます。スキャナーの設定で、封筒ごとに区切りの白紙を挟むか、1通ずつスキャンします。

ファイル名には、受付日と受付の連番を付けます。連番は封筒に手で書いた番号と同じにし、原本の封筒と台帳の行がいつでも突き合わせられるようにします。

1日1回の定時処理にはしません。 午前に届いた郵便を午前のうちに読み取れば、午後には不足の連絡ができます。連絡が1日早まると、請求者に証明書が届く日も1日早まります。

入力データを集める

質を決めるのは、下の3つです。 料金表が無ければ過不足が出せません。必須の項目の一覧が無ければ、何が書かれていないのかを言えません。 小為替の規則が無ければ、期限の切れた小為替を受け取ってしまいます。

料金表は、自分の市のものを使います。 堺市の案内では、住民票の写しが1通300円、戸籍謄抄本が450円、除籍・改製原戸籍の謄抄本が750円、戸籍の附票が300円とされ、手数料は市区町村によって異なると書かれています。他の市の料金表を流用しないでください。

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

請求書の形で、使うプロセッサを分けます。 市の様式はページの見出しで見分けられるので、様式なら Form Parser、それ以外は Enterprise Document OCR に送ります。小為替・本人確認書類・委任状は Enterprise Document OCR で読みます。

Enterprise Document OCR には、言語と手書きのヒントを渡します。 郵送の請求は日本語の手書きが中心なので、日本語と手書きのヒントを付けると読み取りの精度を上げられるとされています。

画像の品質の点数は、ページ単位で8つの観点（ぼやけ、小さすぎる文字、反射など）から返ります。この点数が低いページの空欄は、「書かれていない」ではなく「読めなかった」として扱います。

ページ数の上限にも気を付けます。同期の処理は Form Parser も Enterprise Document OCR も15ページまでです。封筒1通で15ページを超えることはまずありませんが、まとめてスキャンしてしまった束はバッチ処理に回すか、分けます。

AIへ渡す前に整形する

1. 形式の確認 … Enterprise Document OCR は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP を扱います
2. サイズとページ数の確認 … 同期の処理でファイル40MB、15ページまで。画像は40メガピクセルが上限です
3. 向きの確認 … 封筒から出した紙は向きがそろっていません。Enterprise Document OCR の回転の補正を使います
4. 書類の区切り … 1つのPDFの中で、請求書・小為替・本人確認書類・委任状がどのページかを見分けます
5. 本人確認書類の伏せ字の確認 … 健康保険の資格確認書の写しは、保険者番号と記号・番号を黒く塗るよう案内されています。塗られていないものは、読み取り結果からその部分を消して保管します
6. 重複の確認 … 同じ請求者・同じ対象者・同じ種類の請求が直近にあれば、二重に届いた可能性として印を付けます

4番目は、生成AIに任せます。 ページの文字から「請求書」「定額小為替証書」「運転免許証」「委任状」のどれかを見分けさせます。見分けに迷うページは unknown とし、職員が見ます。

AIに処理させる

させるのは、書類の種類を見分け、台帳の項目に値をそろえ、根拠の文字列を添えることだけです。

請求者の立場を推し量らせないのが、この構成でいちばん大事なところです。 請求者と対象者の姓が同じでも、同じ世帯とは限りません。立場の判断は交付の判断そのものなので、書かれた文字だけを返させます。

4行目が、いちばん起きやすい失敗です。 氏名の1字が読めないとき、AIはよくある字で埋めます。埋めた字が正しくても誤っていても、読めなかったという事実が消えます。 読めない字は ? のまま残させ、職員が原本を見ます。

指示内容を固定する

あなたは市民課の郵送の受付担当として、郵送で届いた証明書の請求を
受付台帳の項目にそろえます。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【まず、ページごとに書類の種類を見分けてください】
request（請求書）/ money_order（定額小為替証書）/ id_copy（本人確認書類の写し）/
proxy（委任状）/ envelope（返信用封筒）/ unknown

【台帳の項目】
1. 請求者（住所、氏名、生年月日、昼間の連絡先）
2. 請求者の立場（本人／同じ世帯／代理人／第三者）
3. 対象者（住所または本籍、氏名、筆頭者）
4. 証明書の種類と通数（種類ごとに1行）
5. 使用目的と提出先
6. 小為替（1枚ごとに、額面、発行日、受取人の欄に記入があるか）
7. 同封物の有無

【status の選び方】
- ok ............ 値が読み取れている
- missing ....... 欄が無い、または欄が空である
- unreadable .... 文字はあるが読み取れない（画像の品質の点数が低い場合を含む）
- ambiguous ..... 候補が複数あり、1つに決められない
- not_enclosed .. 同封物が見つからない
迷ったときに ok を選ばないでください。

【厳守事項】
- 読めない字を補わないでください。読めない字は ? のまま value に入れ、
  status を unreadable にしてください。
- 請求者の立場は、請求書に書かれた文字だけで決めてください。
  姓や住所が同じことを理由に「同じ世帯」としないでください。
  書かれていなければ missing にしてください。
- 手数料、合計、過不足を計算しないでください。
  小為替の額面は、証書に書かれた数字をそのまま返してください。
- 交付してよいか、本人確認が足りているかを書かないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- 本人確認書類の写しからは、氏名・住所・生年月日だけを返し、
  番号は返さないでください。

【読み取り結果】{ocr_result}
【ページごとの画像の品質の点数】{quality_scores}
【市の様式かどうか】{is_city_form}

「姓や住所が同じことを理由にしない」を書かないと、立場が埋まります。 請求者と対象者の姓が同じなら、AIは「同じ世帯」と書きます。そう書かれた台帳を見ると、職員は委任状の有無を確かめずに進めてしまいます。

「番号は返さない」も意図して書いています。 本人確認書類の写しには、免許証の番号などが写っています。照合に要るのは氏名・住所・生年月日だけで、番号を台帳に残す理由はありません。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "receipt_no": "",
  "pages": [ { "page": 1, "doc_type": "request" } ],
  "fields": [
    { "item": "requester_name", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "evidence": "", "page": 1 }
  ],
  "certificates": [ { "type": "", "copies": 0, "status": "ok", "evidence": "" } ],
  "money_orders": [
    { "face_value": 0, "issue_date": "", "payee_filled": "yes | no | unreadable",
      "status": "ok" }
  ],
  "enclosures": { "id_copy": "found | not_enclosed", "proxy": "found | not_enclosed",
                  "envelope": "found | not_enclosed" }
}

1つ目の理由は、過不足をプログラムが計算できることです。 certificates の種類と通数に料金表を掛け、money_orders の額面を足して比べます。不足なら fee_short、多ければ返す額を台帳に書きます。 目黒区の案内では、未使用分は定額小為替で返すとされています。

2つ目は、小為替の規則を機械的に当てられることです。

3つ目は、印の決め方を規則の側に置けることです。 どの項目が欠けたら電話で確かめ、どれなら原本を見るだけでよいかは市の取り決めです。取り決めが変わっても、直すのは規則だけです。

システムへ連携する

基幹の仕組みにつながないのは、意図してのことです。 住民記録と戸籍の仕組みは、外部のクラウドと切り離して運用するのが前提です。台帳の案を職員が見て、基幹の仕組みには職員が入力します。

人が確認する

職員が開くのは、印の付いた請求です。 ok の請求も、台帳の案を流し見て確定の印を付けます。交付の判断は、印の有無にかかわらず全件を職員が行います。

1. unreadable を先に見る … 原本の封筒を出して、読めなかった字を確かめます。多くはこれで片付きます
2. missing を見る … 本当に書かれていないかを原本で確かめ、必要なら請求者に電話します
3. fee_short と小為替の印を見る … 不足の連絡の下書きを直して送ります
4. 請求者の立場と同封物を見る … 代理人なら委任状、第三者なら理由の資料を確かめ、交付してよいかを判断します

目標は、600件をならして1件3分です。 1分はスキャン、残りが台帳の確定と印の確認です。印が付くのは2割前後という想定で、それより多い月は、スキャンの設定か必須の項目の一覧を見直します。

例外に対処する

6行目は、新しく起きている例外です。 目黒区の案内では、2026年4月から住民票の郵送請求でクレジットカード決済・PayPay決済が使えるとされています。小為替が無いことを一律に不足とすると、支払済みの請求に不足の連絡を送ってしまいます。

記録を残す

• スキャン画像と、受付日・受付の連番
• Document AI の結果のJSON全文と、画像の品質の点数
• Claude API の出力（fields、certificates、money_orders、enclosures）
• 計算に使った料金表の版と、過不足の計算の結果
• 職員が値を直した記録と、交付の判断をした職員
• 不足の連絡を送った日時と、返事が届いた日時

4つ目で料金表の版を残すのは、改定があるからです。 改定の前に届いた請求を改定の後に処理すると、どちらの料金で計算したかが分からなくなります。

本人確認書類の写しの保管期間は、市の文書の取り扱いの規程に合わせます。 読み取り結果のJSONにも氏名や住所が残るので、画像と同じ期間で消すようにします。