市役所の窓口で受け付けた手書きの住民票の写し等の交付請求書を読み取り、請求者の区分に応じた記入漏れを返して受付台帳に転記する

処理の起点を決める

窓口のスキャナで請求書を読み込み、保存用のコンテナにファイルが置かれたことを起点にします。 スキャナの保存先を Azure Blob Storage のコンテナにし、Azure Functions の Blob のトリガーで1枚ずつ処理します。まとめて夕方に処理しないのは、第5章の6番目のとおり、請求者がいるうちに漏れを返すためです。

ファイル名には、窓口の番号と受付の番号を入れます。受付の番号は、窓口で請求者に渡す番号札と同じにしておきます。 画面に返す結果と、目の前の請求者が結びつきます。

郵送で届いた請求も、様式の請求書で届いたものは同じスキャナで読み込みます。便箋に書かれた手紙の請求は、様式が無いのでこの構成の対象にせず、これまでどおり職員が読みます。

入力データを集める

質を決めるのは、区分ごとの規則の表です。 法の条文を、請求書のどの欄が要るかに置き換えた表で、市民課が様式に合わせて作り、改正や様式の変更のたびに直します。

この表の「必要な欄」には、法が総務省令に委ねている事項もあります。 省令と市の様式で何を求めているかを、市民課が様式の欄に当てはめて書き足します。表を作る作業そのものが、区分ごとの確認の基準を窓口でそろえることになります。

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

読み取りは、Azure Functions から合成したカスタム モデルを呼ぶだけです。モデルの学習は、様式ごとに見本の請求書にラベルを付けて行います。 公式では、学習の呼び出しで buildMode を template にするとテンプレート モデルになります。

POST {endpoint}/documentintelligence/documentModels:build?api-version=2024-11-30
{ "modelId": "juminhyo-third-party-v1",
  "buildMode": "template",
  "azureBlobSource": { "containerUrl": "...", "prefix": "third-party/" } }

学習の見本には、実際の請求書を使わず、職員が架空の内容で書いたものを使います。 見本は様式ごとに少なくとも5枚で、字のうまい人とそうでない人、ボールペンと鉛筆、チェックを丸で囲んだものとレ点を付けたものを混ぜます。 窓口で起きる書き方のばらつきを、見本の側に入れておきます。

信頼度は欄ごとに受け取ります。 公式では、2024-11-30（GA）の API 版からカスタム モデルの欄の信頼度に単語の信頼度が含まれるようになり、表・行・セルの信頼度も返るとされています。一方で、すべての欄が信頼度を返すわけではないとも書かれています。 信頼度が返らなかった欄は、値があっても low_confidence として扱い、職員が見る側に回します。値が無いことを「確か」と読み替えないための決まりです。

公式では、カスタム テンプレート モデルは学習時に推定の精度を出し、80％以上を目安に、機微な場面では100％近くを目指すよう案内されています。 住民の個人情報を扱うので、推定の精度が十分でない欄は、運用で必ず職員が目で確かめる欄に指定します。

AIへ渡す前に整形する

1. 形式の確認 … スキャナの出力を PDF か画像にそろえます
2. 向きと傾きの確認 … 逆さに読み込んだものは回転してから呼びます
3. 様式の確認 … 合成モデルが返す文書の種類から、どの様式かを確かめます
4. 解像度の確認 … 1024×768の画像で12ピクセルの下限を割らない設定かを、導入時に確かめます
5. 委任状・本人確認の書類を混ぜない … 請求書だけを読み込み、添付の書類はスキャナに通しません

5番目は、この構成が扱う個人情報を必要な範囲にとどめるためです。 本人確認の書類の画像をクラウドに送る理由は、この構成にはありません。職員が目で見て確かめ、画像は残しません。

AIに処理させる

させるのは、請求書の欄ごとの読み取りと、信頼度を返すことです。 漏れの判定は、Azure Functions のプログラムが規則の表で行います。生成AIは使いません。

右端の列の missing と low_confidence の区別が、この構成でいちばん大事です。 missing は請求者に書き足してもらう欄、low_confidence は職員が請求書を見て確かめる欄です。混ぜると、書いてある請求者に書き直しを頼むことになります。

not_allowed は、第三者の申出で個人番号の記載に印がある場合などです。 住民基本台帳法は、本人等以外の申出で交付できる写しに表示できる事項から、個人番号と住民票コードを除いています。印があっても交付の中身は職員が決めますが、窓口で請求者に説明が要る場面なので、画面の上に出します。

「読めない字の推測」を禁じるのは、氏名の字体に意味があるからです。 「髙」と「高」、「齋」と「斎」を読み取りの側で寄せると、対象者を取り違えたまま台帳に残ります。 読みにくい字は low_confidence にして、職員が請求書の字を見ます。

指示内容を固定する

この構成では生成AIを使わないので、プロンプトの代わりに判定の規則を設定として持ちます。 規則の表は次のような形で、Azure Functions が読み込みます。

【区分】third_party（第三者）
【必要な欄】
  applicant_name      申出者の氏名
  applicant_address   申出者の住所
  subject_name        対象者の氏名
  subject_address     対象者の住所
  purpose             利用の目的（空白・「提出のため」だけは missing）
  cert_type           証明の種類
  copies              通数
【記入できないチェック】
  include_individual_number   個人番号の記載
  include_resident_code       住民票コードの記載
【信頼度】
  氏名・住所の欄 ........ 0.90 未満は low_confidence
  チェック欄 ............ 0.85 未満は low_confidence
  通数 .................. 0.95 未満は low_confidence
【通数の目安】
  6 通以上は low_confidence（職員が請求者に確かめる）
【返し方】
  missing ........ 画面の「書き足しを依頼」の枠
  low_confidence . 画面の「目で確かめる」の枠
  not_allowed .... 画面の最上部

信頼度の値は、導入時に試して決めます。 ここに書いた値は例で、架空の請求書100枚を読ませ、職員が正解と突き合わせて、見落としが出ない値まで上げます。 値を高くするほど職員が見る欄が増えるので、欄ごとに分けて決めます。

「提出のため」だけの利用の目的を missing にするのは、運用の一例です。 第三者の申出では、利用の目的が交付を認めるかの判断の材料になるので、「どこに何のために出すか」が分からない書き方を、窓口で書き足してもらう扱いにすることが考えられます。この基準は市民課が決め、表に書きます。

出力形式を固定する

判定の結果を、Azure Functions が次の形にして窓口の画面に返します。

{
  "receipt_no": "",
  "window": "",
  "form_type": "self | third_party | professional",
  "applicant_class": "self | agent | third_party | professional",
  "fields": [
    { "name": "applicant_name", "value": "", "confidence": 0,
      "status": "ok | missing | low_confidence" }
  ],
  "checks": [ { "name": "include_individual_number", "selected": false,
                "confidence": 0, "status": "ok | not_allowed | low_confidence" } ],
  "copies": 0,
  "fee": 0,
  "result": "ready | ask_applicant | staff_check"
}

1つ目の理由は、status と result を別の層に置けることです。 欄ごとの status は読み取りと規則から機械的に決まり、result は missing が1つでもあれば ask_applicant、low_confidence か not_allowed があれば staff_check です。規則が変わっても、直すのは表だけです。

2つ目は、fee を手数料の表から計算できることです。 証明の種類と通数から、条例の手数料の表で計算して画面に出します。通数が low_confidence のときは fee を出しません。 誤った金額を窓口で伝えないためです。

3つ目は、職員が直した値を同じ形で受け取れることです。 画面で職員が直した値で fields を上書きし、直した欄に印を付けて受付台帳に渡します。

システムへ連携する

受付台帳に書くのは、職員が画面で「確定」を押したものだけです。 読み取ったままの値を台帳に書くと、low_confidence の欄が確かめられないまま残ります。

住民基本台帳のシステムには書き込まず、そこから読みもしません。 対象者が住民基本台帳に記録されているかを確かめるのは、交付の操作をする職員です。

人が確認する

この構成では、すべての請求書を職員が扱います。 機械がするのは、確かめる欄を絞ることです。

1. not_allowed を先に見る … 区分に照らして交付できない記載の印があれば、請求者に説明します
2. missing の欄を請求者に書き足してもらう … 画面の枠に出た欄だけを頼みます
3. low_confidence の欄を請求書で確かめる … 請求書の字を見て、画面の値を直します
4. 本人確認・代理権・第三者の申出の判断をして交付する … ここはこれまでどおりです
5. 画面で確定する … 直した欄に印が付いたまま台帳に入ります

ready の請求書でも、職員は画面の氏名と請求書の氏名を見比べてから確定します。 1件数秒の確認で、読み取りの誤りが台帳に残るのを防ぎます。

目標は、1,800件をならして1件1分です。 ready は画面を見比べて確定するだけ、ask_applicant と staff_check は請求書を確かめるので1〜2分かかる想定です。

繁忙期に入った職員には、画面の3つの枠の意味だけを先に伝えます。 区分ごとにどの欄が要るかを覚えていなくても、画面の「書き足しを依頼」の枠に出た欄を請求者に頼めば、区分ごとの確認になります。 区分の知識は、窓口で画面を見ているうちに身につきます。

運用の最初の1か月は、夕方に係長が当日の請求書から10枚を選び、画面の判定と請求書を見比べます。 ready になったのに欄が空いていた請求書があれば、規則の表か信頼度の値に穴があります。

例外に対処する

4行目の「はみ出し」には注意が要ります。 テンプレート モデルは決まった位置の欄を読むので、欄の外に書かれた字は、その欄の値として返らないことがあります。 画面には請求書の画像を並べて出し、missing の欄は画像で空欄かを見てから請求者に頼みます。

記録を残す

• 請求書の画像と、受付の番号・窓口の番号・日時
• 読み取りの結果の全文（欄ごとの値と信頼度、チェック欄、署名欄）
• 判定の結果（fields、checks、result）と、そのとき使った規則の表の版
• 職員が直した欄と、直す前の値
• 受付台帳に確定した日時と、確定した職員

画像と読み取りの結果の保存期間は、請求書の原本と同じ期間に合わせます。 原本より長く残すと、個人情報を必要以上に持つことになります。市の文書の保存年限の定めに合わせて、期間が過ぎたら消す設定にします。

職員が直した欄の記録は、信頼度の値と見本を見直す材料になります。 同じ欄が毎日直されているなら、その欄の見本が足りないか、信頼度の値が低すぎます。