市町村に届く国民健康保険税の減免申請書（手書き）を読み取り、世帯・減免の理由・添付書類の有無を審査台帳に起こして、足りない書類を拾う

処理の起点を決める

スキャンした PDF が保管場所に保存されたことを起点にします。 窓口の受付分は、その日の昼と夕方にまとめて複合機でスキャンし、郵送分は開封した日にスキャンします。1件の申請書と添付書類を1つの PDF にし、先頭のページを必ず申請書にします。 この決まりがあるから、1ページ目をテンプレートモデル、2ページ目以降をレイアウトモデルに振り分けられます。

ファイル名は受付番号にします。 台帳の行と紙の申請書が1対1で結び付きます。処理が終わった PDF は「処理済み」の場所へ移し、移すのは成功したときだけにします。保存場所に残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、求める書類の一覧です。 一覧が曖昧だと、読み取りがどれだけ正確でも、足りないかどうかを決められません。

この表は、さいたま市の案内の必要書類を例として並べたものです。実際の一覧は、自分の市の条例・要綱と運用から作ってください。

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

申請書は、ワークフローからカスタムテンプレートモデルを呼んで読みます。 学習は、Document Intelligence Studio で市の様式の見本に欄の名前を付けて行います。欄の名前は、台帳の列名と同じにしておきます。 そうすると、読み取り結果をそのまま台帳の列に当てられます。

添付書類は、2ページ目以降をレイアウトモデルに渡します。 取るのは、ページごとの文字、表、styles の手書きかどうか、単語ごとの信頼度です。書類の種類を当てる材料は、ページの上のほうにある表題と、発行元の名前です。 「り災証明書」「退職証明書」「給与支払明細書」「在所証明書」のような表題が読めれば、種類はほぼ決まります。

賦課の書き出しは、毎朝1回書き出した CSV を読みます。 照合の順は、記号番号が先、氏名が後です。 氏名から先に引くと、同姓同名と旧字体で引けない世帯が出ます。

AIへ渡す前に整形する

1. ページの切り分け … 1ページ目を申請書、2ページ目以降を添付書類として分けます。1ページ目が申請書の様式でないとき（テンプレートモデルの文書の種類の信頼度が低いとき）は、needs_human にして止めます
2. 寸法と向きの確認 … 画像は50×50ピクセルから10,000×10,000ピクセルの間であることが必要です。横向きにスキャンされた添付書類は向きを直します
3. 文字の大きさの確認 … 抽出できる文字の最小の高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。給与明細の小さな数字は、複合機の既定の解像度だと下限に近くなります。 受付のスキャンは300dpiにそろえます
4. パスワードの確認 … パスワードでロックされた PDF は、提出前にロックを外す必要があります。メールで届いた書類を印刷せずに取り込むときに当たります
5. 白紙と裏面の除去 … 両面スキャンで出た白紙のページを外します。外したページ数は記録に残します
6. マイナンバーの写りの確認 … 添付書類の写しに個人番号が写っている場合があるため、レイアウトモデルの文字に12桁の数字の並びがあれば、その範囲を伏せた画像を作り、以降の処理には伏せた画像を使います

6番目は、この題材に固有の手当てです。 減免の審査に個人番号は要りません。要らない番号を生成AIへ渡さないために、読み取りの直後に伏せます。

AIに処理させる

させるのは2つです。 1つ目は、申請書の読み取り結果を台帳の項目にそろえること。2つ目は、添付書類の各ページについて、書類の種類を辞書から当て、根拠にした文字列を写すことです。

右端の列が大事です。 missing は付いていない、unreadable は付いているが読めない、ambiguous は候補が複数ある、という区別で、前者は申請者に連絡するもの、後の2つは職員が紙を見れば済むものです。

4行目が、いちばん起きやすい失敗です。 説明の欄に「会社を辞めました」と書かれ、理由のチェックが無いとき、AIは「所得の急な減少」にチェックを補おうとします。申請者がどの理由で申請したかは、申請者が決めることです。 チェックが無ければ「理由のチェックなし」と記録し、職員が申請者に確かめます。

指示内容を固定する

あなたは市の国保年金課で、国民健康保険税の減免申請の受付を補助する立場です。
OCRが返した読み取り結果だけを使ってください。推測で埋めないでください。

【1. 申請書の項目】
次の項目を、読み取り結果の欄から写してください。
- insured_no, head_name, head_address, head_phone
- members（氏名、続柄、生年月日）
- reasons（チェックが入っている減免の理由。チェック欄の状態をそのまま写す）
- reason_text（理由の説明の欄の文。要約せずに写す）
- attach_checked（申請者がチェックした添付書類）
- applied_on, signature_present

【2. 添付書類の各ページ】
ページごとに、書類の種類を【書類の種類の辞書】から1つ選び、
根拠にした文字列（表題や発行元）を evidence にそのまま写してください。
辞書に当てはまらなければ other とし、表題の文字列を写してください。

【status の選び方】
- ok ......... 値が読み取れている
- missing .... 欄が空、またはチェックが無い
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 記号番号、電話番号、生年月日は、読み取った文字をそのまま写してください。
  桁を補う、記号を足す、それらしい値に直すことをしないでください。
- 減免の理由のチェックが無いときに、reason_text から理由を補わないでください。
  reasons を空にし、status を missing にしてください。
- 減免に当たるか、減免の割合、所得の見込みを書かないでください。
- 給与明細や通帳の金額を合計したり、計算したりしないでください。
- 診断書の病名、収容された施設の名前、処分の内容を出力に写さないでください。
  書類の種類と表題だけを写してください。
- 伏せ字（■）になっている数字を復元しようとしないでください。
- confidence は OCR が返した値をそのまま入れてください。
- 申請書でない書類が1ページ目にあると判断した場合は、document_type に種類を書き、
  項目を埋めずに返してください。

【書類の種類の辞書】{doc_types}
【申請書の読み取り結果】{form_result}
【添付書類の読み取り結果（ページごと）】{attachment_pages}

「理由を補わない」を明記しないと、親切に補います。 禁じるのは、申請者の選択を推測で置き換えることそのものです。

「病名や施設の名前を写さない」を書くのは、審査台帳を係の全員が開くからです。 指示が無いと、AIは根拠として表題の下の本文まで写します。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力（response_format に json_schema を strict: true で渡す方式）を使い、形を固定します。

{
  "receipt_no": "",
  "document_type": "reduction_application",
  "household": {
    "insured_no": { "value": "", "status": "ok", "confidence": 0 },
    "head_name": { "value": "", "status": "ok", "confidence": 0 },
    "head_phone": { "value": "", "status": "ok", "confidence": 0 },
    "members": [ { "name": "", "relation": "", "birth": "", "status": "ok" } ]
  },
  "reasons": [""],
  "reason_status": "ok | missing | ambiguous",
  "reason_text": "",
  "attach_checked": [""],
  "attachments": [
    { "page": 2, "doc_type": "", "evidence": "", "status": "ok | unreadable" }
  ],
  "applied_on": { "value": "", "status": "ok" },
  "signature_present": true
}

この JSON のあとに、ワークフローが照合の結果を足します。

1つ目の理由は、AIの読み取りと書類の過不足の判定を別の層に置けることです。 求める書類の一覧が年度の途中で変わっても、直すのは一覧だけです。AIが返した attachments を読み直せば、過去の申請の判定もやり直せます。

2つ目は、checked_but_absent で入れ忘れを拾えることです。 連絡の文面が「同封されていませんでした」と具体的になります。

システムへ連携する

審査台帳には「確認待ち」の状態でだけ書き込みます。 職員が確かめるまで、審査の担当の一覧には出しません。賦課のシステムには書き込みません。 減免の決定は、審査を経た職員の操作で行います。

人が確認する

人が全件を確かめます。 確かめ方は、申請書の画像と台帳の行を左右に並べた画面で、黄色の印の付いた欄から見ていく形にします。

1. needs_human を先に見る … 1ページ目が申請書でない、記号番号が賦課の書き出しに無い、読めない欄がある、のいずれかです。多くは紙を見れば数秒で済みます
2. 番号と生年月日を画像と照らす … 信頼度が高くても、記号番号・電話番号・生年月日の3つは画像と並べて目で確かめます
3. 書類の過不足を確かめる … missing の書類が本当に同封されていないかを、紙の束で確かめます。連絡は紙を見てから出します
4. 理由のチェックが無い申請を確かめる … 申請者に電話して、どの理由で申請するかを聞きます
5. 判定を覆したら記録する … どの欄を、どの値に直したかを残します

3番目を省かないでください。 missing は、そのまま申請者への連絡になります。送ったはずの書類を求められた申請者は、市に書類を失くされたと思います。

目標は、120件をならして1件5分です。 5分を超える月は、スキャンの解像度か、求める書類の一覧が曖昧になっています。

例外に対処する

後から届く添付書類の扱いを、最初に決めておきます。 依頼文に受付番号を書き添えてもらう案内を入れないと、後から届いた書類が新しい申請として台帳に並びます。

記録を残す

• 申請書と添付書類の PDF（個人番号を伏せる前の原本と、伏せたあとの画像を分けて保管）
• 読み取りサービスが返した JSON の全文と、Azure OpenAI に渡した入力と返ってきた JSON
• 照合の結果（required_docs、doc_check、household_match、next_action）と、そのとき使った求める書類の一覧の版
• 人が判定を覆した記録 … どの欄を、どの値に直したか
• 不足の連絡をした日と方法、書類が届いた日
• 書類の種類ごとの unreadable の発生率

3つ目で一覧の版を残すのは、一覧が年度の途中で変わるからです。 求める書類を足した日の前と後で、同じ申請の判定が変わります。どの版で判定したかが残っていないと、監査のときに説明できません。