NPO法人が毎月受け取る手書きの寄付の申込書を読み取り、寄付者の台帳と領収書の発行の一覧に転記する

処理の起点を決める

スキャンした PDF を、決めたフォルダに保存したことを起点にします。 フォルダは経路ごとに3つ（街頭／イベント／郵送）に分けます。経路は申込書の紙面に書かれていないことが多いので、フォルダで持たせます。 街頭とイベントの申込書は現金と一緒に届くので、入金の照合の相手が現金の受領の記録になり、郵送は振込の明細になります。

スキャンは、届いた日のうちに行います。 月末にまとめてスキャンすると、入金の照合で受付の日付と入金の日付が離れ、照合の候補が広がります。1日の終わりに、その日の封筒を開けてスキャンすることを事務局の決まりにします。

封筒ごとに1つのファイルにします。 イベントの会場の封筒には、その日の申込書と現金の受領の記録の控えが入っています。封筒の単位でスキャンすると、ファイル名に封筒の番号を付けられ、現金の受領の記録と1対1で結べます。 ファイルを1枚ずつに分けるのは、その後の処理で行います。

入力データを集める

質を決めるのは、入金の記録の粒度です。 現金の受領の記録が「イベントの合計額」しか無いと、申込書1枚ごとの金額と照らせません。イベントの会場で、ボランティアが申込書の右上に受け取った金額を書き込む欄を設けると、照合がぐっと楽になります。

口座振替の依頼書は入力データにしません。 依頼書には口座番号と届出印が入っており、収納代行の会社へそのまま送る書類です。事務局の読み取りの仕組みに通す理由がありません。 スキャンの前に抜く手順を、第5章の1番目に入れてあります。

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

欄の信頼度だけを見て確定しません。 公式ページでは、カスタム モデルの欄の信頼度は値を取り出した位置の確からしさを表し、文字の読み取りの確からしさは語ごとの信頼度として別に返るとされています。両方を見て合成した値で、確定か要確認かを決めます。 位置は正しくても、字が崩れていれば読み違えています。

チェック欄は、選択マークの信頼度も合わせて見ます。 公式ページでは、選択マークの付いた欄は、欄の選択と選択マークの信頼度を合わせたものが全体の確からしさをよく表すとされています。「3,000円」と「5,000円」の両方にうっすら印があるような申込書は、どちらも信頼度が下がります。

AIへ渡す前に整形する

1. 口座振替の依頼書の除外 … スキャンの前に人が抜きます。混ざっていたら、様式の種類の信頼度の低さで見つけて除外します
2. 1枚ずつへの分割 … 封筒ごとの PDF を、ページで分けます。ファイル名に封筒の番号とページの番号を付けます
3. 向きと解像度の確認 … 上下逆のページを回転させ、文字の高さが下限（1024×768の画像で12ピクセル、150dpiで約8ポイント）を下回らないかを見ます
4. 白紙と裏面の除外 … 裏面だけのページや白紙を除きます
5. 重複の検知 … 同じ封筒を二度スキャンしたものを、封筒の番号で見つけます

3番目は、スキャンの設定で決まります。 公式ページでは、抽出する文字の高さの下限が示されています。手書きの小さな字は、複合機の既定の解像度だと下限に近づきます。 300dpi でスキャンする設定を、複合機に登録しておきます。

AIに処理させる

させるのは、決まった位置の記入欄とチェック欄を読み取り、値と信頼度を返すことだけです。 読み取った値を台帳の形にそろえ、検査と照合をするのはプログラムです。

右端の列の多くは、AIではなく規則で決まります。 読み取りが完全でも、寄付者が金額の欄に2つ印を付けていれば、どちらが本当かは申込書からは分かりません。読み取りの誤りと、記入そのものの矛盾を分けて印にします。 前者はスキャンや字の問題、後者は寄付者への確認の問題です。

1行目が、いちばん守るべき線です。 「髙橋」が「高橋」に読まれても、台帳の検索では同じ人に見えますが、寄付者にとっては自分の名前が違う領収書が届くことになります。 字体の違いが読み取りで落ちる可能性があるので、氏名の欄は信頼度にかかわらず、台帳に無い新しい寄付者なら画像と並べて確かめます。

指示内容を固定する

カスタム テンプレート モデルは文章の指示で動くものではなく、ラベル付けした欄の定義と、学習に使うサンプルで何を読むかが決まります。ラベル付けの決まりを、次のように文書にして職員とそろえます。

【申込書のラベル付けの決まり（新様式）】
対象：自団体の寄付の申込書 A4 1枚
学習用のサンプル：記入済みの申込書を5枚以上（できれば15枚）
  - 字のきれいなもの、崩れたもの、空欄の多いものを混ぜる
  - チェック欄に「✓」「○」「塗りつぶし」の書き方を混ぜる

【欄の名前と種類】
name_kanji ........ 記入欄（氏名）
name_kana ......... 記入欄（フリガナ）
postal_code ....... 記入欄（郵便番号）
address ........... 記入欄（住所。番地・建物名・部屋番号まで1つの欄）
phone ............. 記入欄（電話番号）
email ............. 記入欄（メールアドレス）
type_once / type_monthly ............ 選択マーク（寄付の種類）
amount_3000 / amount_5000 / amount_10000 / amount_other ... 選択マーク（金額）
amount_other_value ................... 記入欄（その他の金額）
pay_cash / pay_transfer / pay_debit .. 選択マーク（支払の方法）
receipt_yes / receipt_no ............. 選択マーク（領収書）
publish_yes / publish_no ............. 選択マーク（年次報告への掲載）
staff_received_amount ................ 記入欄（会場で受け取った金額。ボランティアが記入）

【やらないこと】
- 欄の外の余白に書かれたメモをラベルに含めない
- 署名の欄を氏名の欄として扱わない
- 旧様式のサンプルを新様式のモデルに混ぜない（様式ごとに別のモデルにして合成する）

「様式ごとに別のモデル」を明記するのは、公式の案内に沿うためです。 様式の違うサンプルを1つのモデルに混ぜると、どちらの様式でも精度が落ちます。旧様式と新様式をそれぞれ5枚以上で学習し、合成したモデルを呼びます。

学習の後に出る推定の精度も見ます。 公式ページでは、テンプレート モデルは学習のときに欄ごとの推定の精度を出し、80％以上を目安に、金融や医療のように重要な場面では100％に近い値を勧めるとされています。氏名と住所は領収書に出るので、この2つの欄が100％に近くなるまでサンプルを足します。

出力形式を固定する

1枚ごとに、次の形の JSON を作ります。

{
  "file": "",
  "envelope_no": "",
  "channel": "street | event | mail",
  "doc_type_confidence": 0.0,
  "fields": {
    "name_kanji": { "value": "", "confidence": 0.0, "status": "ok | review | empty" },
    "postal_code": { "value": "", "confidence": 0.0, "status": "ok | review | empty" },
    "address": { "value": "", "confidence": 0.0, "status": "ok | review | empty" }
  },
  "checks": {
    "amount": { "selected": ["amount_5000"], "other_value": "", "status": "ok | conflict | empty" },
    "donation_type": "once | monthly | conflict | empty",
    "receipt": "yes | no | conflict | empty"
  },
  "donor_match": { "status": "new | candidate | matched", "candidates": [""] },
  "payment_match": { "status": "matched | mismatch | waiting", "received_amount": 0, "received_date": "" },
  "verdict": "ready | review | waiting_payment"
}

fields には、ここに挙げた3つのほかに、フリガナ・電話番号・メールアドレスなどを同じ形で並べます。

1つ目の理由は、欄ごとに status を持てることです。 確認の画面では review と empty の欄だけを画像と並べて出します。1枚の中で直す欄が1つなら、職員はその1つだけを見ます。

2つ目は、checks で記入の矛盾を読み取りの誤りと分けられることです。 conflict は寄付者の記入そのものの問題で、電話やメールで寄付者に確かめるものです。読み取りの review とは、直す人と方法が違います。

3つ目は、payment_match で領収書の元になる値を持てることです。 received_amount と received_date は入金の記録から入れ、領収書の発行の一覧はこの2つから作ります。 申込書の金額は使いません。

システムへ連携する

台帳への登録は、職員が確定ボタンを押したものだけです。 読み取ったものを台帳に直接書き込みません。既存の寄付者との統合も、職員が候補から選んだときだけ行います。

領収書そのものの発行も、この構成からは行いません。 一覧を作るまでにして、印刷と送付は職員が一覧を確かめてから行います。 領収書は寄付者の確定申告に使われる書類で、出し直しには手間と説明がかかります。

人が確認する

全件、職員が確認の画面で確定させます。 ただし、全欄を見るのではなく、印の付いた欄だけを見ます。

1. review と empty の欄を直す … 画像の該当箇所と並べて、値を直すか空欄を確かめます
2. conflict を寄付者に確かめる … 金額や寄付の種類の矛盾は、電話かメールで確かめます
3. 既存の寄付者の候補を決める … 候補が出たものは、住所と電話番号を見て同じ人かを決めます
4. 新しい寄付者の氏名を画像と見比べる … 台帳に無い人は、信頼度にかかわらず氏名の字体を確かめます
5. 入金の食い違いを経理と確かめる … mismatch は、申込書の金額と入金額が違うものです

4番目を省かないでください。 新しい寄付者の氏名は、この後ずっと台帳と領収書に使われます。最初の登録で字体を誤ると、毎年の領収書が誤ったまま出続けます。

目標は、420枚をならして1枚3分です。 印の付いていない申込書は一覧で流し見て数秒、要確認の欄がある申込書は1〜2分かかります。要確認が多い月は、スキャンの設定か、サンプルの不足を疑います。

例外に対処する

8行目は、意図して安全な側に倒しています。 掲載してよいかが分からない人の名前を年次報告に載せると、取り消せません。空欄は「載せない」に読みます。

2行目は、起きないように前処理で抜きますが、起きたときの扱いも決めておきます。 口座番号の読み取り結果が保存されてしまうと、事務局が持つべきでない情報を持つことになります。

記録を残す

• 申込書の画像（封筒ごとの原本と、1枚ずつに分けたもの）と、経路・封筒の番号・スキャンの日時
• 読み取り結果の JSON の全文（欄の値と信頼度、語ごとの信頼度、様式の種類の信頼度）
• 検査と照合の結果（status、conflict、donor_match、payment_match）
• 職員が直した欄の、直す前と後の値と、直した人と日時
• 台帳への登録の日時と、領収書の発行の一覧に載せた日時
• 合成したモデルの版と、その版の学習時の推定の精度

4つ目は、モデルの学習し直しの材料です。 同じ欄が繰り返し直されているなら、その欄のラベル付けか、サンプルの偏りに理由があります。直した申込書をサンプルに足して、学習し直します。

6つ目を残すのは、読み取りの誤りが後から見つかったときに、どの版のモデルで読んだかを追えるようにするためです。