自治体の清掃担当に届く手書きの粗大ごみ収集の申込はがきを読み取り、住所・品目・個数・希望日を受付台帳にそろえ、手数料の計算と収集日の割当ての前に記入漏れと読めない欄を拾う

処理の起点を決める

スキャンしたはがきが Cloud Storage のバケットに保存されたことを起点にします。 公式のドキュメントでは、Cloud Run は Eventarc を使って Cloud Storage のオブジェクトの変更をきっかけに呼び出せ、オブジェクトの新規作成や上書きのときには google.cloud.storage.object.v1.finalized のイベントが出るとされています。トリガーで監視するバケットとサービスは、同じプロジェクトに置く必要があります。

スキャンは1日1回、午前の郵便が届いた後にまとめて行います。 はがきは1日に十数枚から数十枚で、まとめてスキャンしても昼までに台帳の案がそろいます。午後に受付係が印の付いたはがきを確かめ、その日のうちに受付システムへ取り込みます。

両面をスキャンするのは、表面に差出人の住所が書かれているためです。 裏面に住所を書き忘れても、表面の差出人の欄に書かれていることがよくあります。表と裏を1組として扱い、どちらかに書かれていれば住所はあるとみなします。

入力データを集める

質を決めるのは、品目表の「別名」の列です。 「カラーボックス」「三段ボックス」「収納ボックス」が同じ品目に当たるのか、別名を持っていないと照合できません。 照合できなかった言葉を毎月ためて、別名に足していきます。

過去の申込は、二重の申込を見つけるために持ちます。 電話で申し込んだ人が、念のためはがきも出すことがあります。同じ住所から同じ品目の申込が直近にあれば、二重の可能性として印を付けます。

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

どちらのプロセッサに回すかは、はがきの種類で決めます。 市の申込用はがきは右上に様式の番号が印刷されているので、その番号を読み取れたものだけを Form Parser に回します。 官製はがきは Enterprise Document OCR だけで読みます。

日本語の手書きなので、言語のヒントを付けます。 Enterprise Document OCR は、データの特徴に応じて言語と手書きのヒントを渡すと精度の改善に役立つとされています。

AIへ渡す前に整形する

1. 表と裏の組み合わせ … スキャンの順で表と裏を1組にします。枚数が奇数なら、どこかで裏返しが漏れています
2. 向きの補正 … はがきは縦書きと横書きが混ざります。回転の補正を使い、読み取りの前に向きをそろえます
3. ファイルとページの確認 … 同期の処理は、ファイルが40MBまで、画像が40メガピクセルまで、Enterprise Document OCR と Form Parser は15ページまでです。1組（2ページ）ずつ送ります
4. 画像の品質の確認 … 品質の点数が低いページは、読み取りの結果にかかわらず needs_staff に回します
5. 余計な部分の除去 … 表面の郵便番号の枠、切手、消印の部分は、申込の内容から外します
6. 重複の確認 … 同じ画像が二度スキャンされていないかを、画像の照合で確かめます

4番目を軽く見ないでください。 鉛筆で薄く書かれたはがき、雨で滲んだはがきは、文字が検出されても値として確定できません。品質の点数が低いのに読み取れたことにすると、番地の1字違いがそのまま台帳に入ります。

AIに処理させる

させるのは、読み取った文字を受付台帳の項目にそろえ、根拠にした文字列を書き出すことだけです。 手数料の計算と、品目表との照合はプログラムが行います。

品目を「書かれた言葉のまま」としているのが、この表でいちばん大事なところです。 AIに品目表のどれに当たるかを決めさせると、「棚」を手数料の安いほうの品目にそろえることがあります。品目表との照合は、別名の表を使ってプログラムが行い、当たらないものは人に回します。 手数料が決まる判断を、AIの言葉の選び方に預けません。

3行目がいちばん起きやすい失敗です。 「本棚」とだけ書かれていると、AIは一般的な大きさを思い浮かべて「中」と書きます。その瞬間、問い合わせるべき不備が消え、収集の日に作業員がその場で手数料の不足に気づくことになります。

指示内容を固定する

あなたは市の清掃事務所で、粗大ごみの申込はがきを受付台帳に転記する立場です。
渡すのは、はがき1枚（表面と裏面）の読み取り結果です。
読み取り結果に書かれていることだけを使い、推測で埋めないでください。

【そろえる項目】
1. 住所（町名・丁目・番地・建物名・部屋番号）
2. 氏名
3. 連絡先（電話番号・FAX番号を区別）
4. 品目ごとの、品目の言葉・大きさ・個数
5. 出す場所、希望日（書かれていれば）

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- missing .... 値が書かれていない
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 品目は、はがきに書かれた言葉のまま写してください。品目表の名前に言い換えないでください。
- 大きさ・個数が書かれていない品目は、missing にしてください。
  一般的な大きさや「1個」を推測で入れないでください。
- 住所の番地・部屋番号が書かれていなければ missing です。似た住所から補わないでください。
- 表面の差出人の欄に住所があれば、裏面に無くても住所として使い、source に「表面」と書いてください。
- 手数料、収集できるかどうか、収集日は書かないでください。
- evidence には、各項目の根拠にした文字列をそのまま写してください。
- confidence は、読み取り結果が返した値をそのまま入れてください。
- 粗大ごみの申込ではない（問い合わせ、苦情、別の手続き）と判断した場合は、
  document_type に種類を書き、項目をそろえないでください。

【読み取り結果】{ocr_result}
【申込用はがきの様式の場合のキーと値】{form_fields}

「品目表の名前に言い換えない」を明記しないと、親切にそろえます。 AIは品目表を渡されていなくても、「カラーボックス」を「棚」とまとめ直します。まとめ直した言葉は別名の表で照合できず、照合できたとしても、どの言葉から照合したのかが残りません。

「1個を推測で入れない」も同じ理由です。 個数が書かれていないはがきの多くは1個ですが、2個以上のこともあり、手数料が変わります。 書かれていないことを示すのは missing で、埋まった値ではありません。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API では、output_config.format に type: "json_schema" でスキーマを渡すと、スキーマに合った JSON が返るとされています。すべてのオブジェクトで additionalProperties を false にします。

{
  "postcard_id": "",
  "document_type": "bulky_waste_application",
  "address": { "town": "", "chome": "", "banchi": "", "building": "", "room": "",
               "source": "front | back", "status": "", "confidence": 0, "evidence": "" },
  "name": { "value": "", "status": "", "confidence": 0, "evidence": "" },
  "contact": { "tel": "", "fax": "", "status": "", "evidence": "" },
  "items": [
    { "written_name": "", "size": "", "quantity": "",
      "status": "ok | missing | unreadable | ambiguous", "evidence": "" }
  ],
  "place": "",
  "preferred_date": ""
}

これにプログラムが、品目表との照合の結果を足します。

1つ目の理由は、missing と unreadable で行き先を分けられることです。

2つ目は、品目ごとに不備を持てることです。 items が配列なので、「棚は大きさが無い、いすは問題ない」のように品目ごとに状態を持てます。問い合わせの下書きは、不備のある品目と項目を全部並べて1通にします。

3つ目は、evidence と confidence で確認が速くなることです。 画像を開く前に、どの文字をどれくらいの信頼度で読んだかが一覧で分かります。

システムへ連携する

受付システムへは、ファイルで渡します。 受付システムに外部から書き込む口があるかは、製品ごとに違います。最初は、受付係が台帳の案を確かめて取り込む形で始めます。

手数料は「候補」として渡します。 品目表から引いた金額でも、大きさの区分の境目にある品目は、受付係がはがきの記載を見て決めます。候補と確定を別の列にしておけば、受付係が金額を変えた件数を数えられ、品目表の区分の見直しに使えます。

人が確認する

1. needs_staff を先に見る … 読めない欄、品目表に当たらない品目、収集できない品目が含まれるものです。多くは、はがきの実物を見れば決まります
2. needs_inquiry の不足を確かめる … missing の欄が本当に空欄かを、画像で確かめます
3. 問い合わせの下書きを直す … 不足を全部並べた1通にします。連絡先がFAXならFAX、無ければはがきで送ります
4. 収集できない品目の案内を添える … 家電リサイクル法の対象品目などは、市の案内の文面を添えて返します
5. 品目表に当たらなかった言葉を記録する … 別名の表に足す候補として、月末にまとめます

2番目を省かないでください。 missing の判定は、申込者に問い合わせるかどうかに直結します。 書いてあったのに聞き返された人は、次からはがきで申し込むのをためらいます。

目標は、360枚をならして1枚2分です。 印の付くはがきが3割前後という想定で、それより多い月は、スキャンの設定か品目表の別名が足りていません。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、スキャンの手順と、はがきの書かれ方の問題です。

記録を残す

• はがきの画像（表と裏）と、届いた日、スキャンした日時
• 読み取り結果（文字、信頼度、画像の品質の点数）
• AIが返したJSONと、品目表との照合の結果、verdict
• 人が判定を覆した記録 … どの項目を、どちらに変えたか
• 問い合わせを送った日と返事が届いた日、受付システムに取り込んだ日
• 品目表に当たらなかった言葉の一覧

4つ目と最後の行は、品目表を育てる材料です。 毎月の当たらなかった言葉を別名に足すと、needs_staff の件数が月ごとに減っていくのが見えます。