神社の社務所で受け付けた手書きのご祈祷の申込書を読み取り、願意・氏名・住所・人数を受付台帳とお札の送付リストにそろえる

処理の起点を決める

閉門後に1日分をまとめてスキャンし、受付フォルダに保存したことを起点にします。 窓口で1枚ずつスキャンする形にはしません。受付の最中は、初穂料の受け取りと授与で手が空かないからです。 ご祈祷が済んだ申込書は神職から社務所に戻ってくるので、箱にたまった分を閉門後に複合機の自動給紙でまとめて読み込みます。

郵送で届いた申込書は、ご祈祷を行った日の分と一緒にスキャンします。ファイル名には日付と「窓口」「郵送」の別を入れます。 郵送の分は全件がお札の郵送になるので、後段で送付リストに回す目印になります。

Apps Script は時間主導のトリガーで、閉門後の決まった時刻から数回、受付フォルダを見に行きます。処理が終わったファイルは処理済みのフォルダへ移し、移すのは成功したときだけにします。 受付フォルダに残っているファイルが、そのまま読み取りの済んでいない分です。

入力データを集める

質を決めるのは、願意の一覧と異体字の一覧です。 願意の一覧は、申込書の□の並びと台帳の願意の名前を1対1で結びます。申込書の書式を変えたら、この一覧も同じ日に直します。

異体字の一覧は、字を直すためではなく、印を付けるために持ちます。 「髙」「﨑」「邊」「澤」のように、氏名でよく使われる旧字体や異体字を並べ、読み取った氏名にこれらの字が含まれるか、逆に普段の字で読まれた可能性がある氏名かを見分けます。 崇敬者の名簿で、同じ人が以前に旧字体で書いていたことが分かることもあります。

郵便番号のデータは、日本郵便が公開している住所の郵便番号のCSVを使います。1レコード1行・UTF-8の形式があり、スプレッドシートに読み込みやすい形です。 月に一度、新しいものに入れ替えます。

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

読み取りは、Apps Script から Form Parser のプロセッサを呼んで行います。返ってくる Document から、見出しの欄・チェック欄・信頼度を取り出します。 Apps Script から Google Cloud の API を呼ぶ認証の設定は、利用環境に応じて個別に用意します。

チェック欄は、キーと値のペアとして返ってきます。 公式の説明では、チェックの付いた欄は filled_checkbox、付いていない欄は unfilled_checkbox という値の種類で示されます。願意の欄の名前（「家内安全」など）がキーに、チェックの状態が値に入るので、願意の一覧と名前で突き合わせます。

ただし、Form Parser の説明では、ラジオボタンは読まず、見つかったチェックボックスに対応するキーが無いこともあるとされています。願意の□の横の文字が小さかったり、□と文字が離れていたりすると、チェックは取れても何の願意かが分かりません。キーの無いチェックは、ページ上の位置から願意の一覧の並びに当てはめ、当てはめられなければ印を付けます。

連名の欄は、申込書の下に罫線で区切った表にしておくと、表として返ってきます。公式の説明では、Form Parser の表は行や列をまたぐセルを認識しないとされています。 罫線の表を、結合したセルの無い単純な形にしておきます。

崇敬者の名簿の検索は、ふりがなと電話番号を先に使い、氏名の字はその後に使います。 字で探すと、旧字体と普段の字で別の人に見えます。

AIへ渡す前に整形する

1. 1枚1ファイルに分ける … 1日分をまとめたPDFを、申込書1枚ずつに分けます。公式のプロセッサ一覧では、同期の要求のページ数の上限は15です。 1枚ずつ送れば、上限を気にせずに済みます
2. 向きと傾き … 自動給紙で斜めに入ったものの傾きを直します
3. 解像度 … ふりがなの欄は字が小さいので、複合機の既定より高い解像度でスキャンします
4. 白紙と裏面の除去 … 両面で読み込んだときの白紙の裏面を除きます
5. 重複の検知 … 同じ日付で、同じ画像に近いものが二度入ったら印を付けて止めます
6. 書式の確認 … 古い書式の申込書や、ほかの用紙（お守りの郵送の申込など）が混ざったら、読み取りの前に分けます

3番目を軽く見ないでください。 ふりがなは小さな字で書かれ、濁点と半濁点が潰れやすい欄です。「はら」と「ばら」の区別が付かないまま台帳に入ると、祝詞で読み上げる読みが変わります。

AIに処理させる

生成AIにさせるのは、読み取った欄を台帳の項目にそろえることと、確認の要る欄に理由を付けることです。 字を書き換えることはさせません。

住所を分けて写させるのは、郵便番号のデータと照らすためです。 郵便番号から引いた市区町村・町域と、書かれた住所の頭が合っているかを、Apps Script が比べます。照合はプログラムで行い、生成AIには分けるところまでをさせます。

2行目がいちばん起きやすい失敗です。 氏名の字から一般的な読みを付けたくなりますが、「たぶんこう読む」は、まさに第3章の（b）で人が起こしていた誤りです。 空のふりがなは空のまま残し、職員が崇敬者の名簿を見るか、本人に確かめます。

指示内容を固定する

あなたは神社の社務所で、ご祈祷の申込書の読み取り結果を受付台帳の形にそろえる担当です。
OCRが返した欄だけを見てください。推測で埋めないでください。

【台帳の項目】
name（代表者の氏名）、name_kana（ふりがな）、birth_date（生年月日）、
postal_code（郵便番号）、address_pref_city（都道府県と市区町村）、
address_rest（町域・番地）、address_building（建物名・部屋番号）、
phone（電話番号）、headcount（人数の欄）、vehicle_no（車両番号）、
wishes（願意）、delivery（お札の受け取り方：持ち帰り／郵送）、
companions（連名の氏名とふりがな）

【厳守事項】
- 氏名・ふりがな・住所は、OCRが返した字をそのまま写してください。
  旧字体や異体字を普段の字に直さないでください。
- ふりがなが空なら空にしてください。氏名から読みを推測しないでください。
- 読めない字は空にし、その欄を unreadable_fields に入れてください。
- 住所は、郵便番号から町名を補わないでください。
  書かれていない部分は空にしてください。
- 願意は、チェックが付いた欄（filled_checkbox）だけを、
  【願意の一覧】の名前で wishes に入れてください。
  チェックの無い欄、丸で囲んだ文字、余白の書き込みから願意を決めないでください。
  1つも無ければ wishes を空にし、flags に no_wish_detected を入れてください。
- 人数の欄の数字はそのまま headcount に写してください。
  連名の行の数と違っても、数え直さないでください。
- 【異体字の一覧】の字を含む氏名には、flags に variant_kanji を入れ、
  該当する字を variant_chars に書いてください。字の正誤は判断しないでください。
- どの項目にも当てられない欄は unknown_fields に入れてください。

【OCRの見出しの欄】{form_fields}
【OCRのチェック欄】{checkboxes}
【OCRの連名の表】{tables}
【願意の一覧（この版の申込書）】{wish_list}
【異体字の一覧】{variant_list}

「字を普段の字に直さない」を明記しないと、生成AIは親切に直します。 読み取った「髙橋」を「高橋」として返すのは、一般の文章では正しい振る舞いだからです。この題材では、直した瞬間に祝詞とお札の宛名が誤ります。 直さないことと、異体字に印を付けることを、別々の指示として書きます。

「丸で囲んだ文字から願意を決めない」も同じ理由です。 OCRのテキストには丸の有無は残らず、願意の名前の文字だけが並びます。何も言わないと、申込書に印刷された願意の名前をすべて願意として拾います。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "form_id": "",
  "form_version": "",
  "received_date": "",
  "channel": "counter | mail",
  "name": "",
  "name_kana": "",
  "birth_date": "",
  "postal_code": "",
  "address_pref_city": "",
  "address_rest": "",
  "address_building": "",
  "phone": "",
  "headcount": "",
  "vehicle_no": "",
  "wishes": [""],
  "delivery": "pickup | mail | unknown",
  "companions": [ { "name": "", "name_kana": "" } ],
  "variant_chars": [""],
  "unreadable_fields": [""],
  "unknown_fields": [""],
  "flags": ["no_wish_detected | variant_kanji | kana_missing | headcount_mismatch"]
}

Claude の構造化出力では、オブジェクトに additionalProperties: false を設定する必要があり、数値の minimum・maximum や文字列の長さの制約は使えないとされています。 郵便番号の桁数の確認は Apps Script の側で行います。

後段の照合は、この出力に対して規則で行います。

システムへ連携する

受付台帳と崇敬者の名簿には、Apps Script から書き込みません。 確認用のシートで職員が「確認済み」の欄にチェックを入れた行だけを、職員の操作で台帳へ移します。移す操作をボタン1つにしておけば手間は増えず、移したかどうかは人が決めます。

送付リストは、確認の済んだ行のうち delivery が mail のものです。宛名ラベルの印刷は、いまの印刷の手順をそのまま使います。 送付リストの列の並びを、いまのラベルの差し込みに合わせておきます。

人が確認する

人が見るのは、印の付いた行だけです。

1. 願意が取れなかったものを先に見る … no_wish_detected は、丸で囲んだ申込書か、□の外に書いたものです。画像を見て願意を選びます
2. 字とふりがなを確かめる … variant_kanji と kana_missing の行を、申込書の画像と並べて見ます。崇敬者の名簿に同じ人がいれば、以前の字と読みを見比べます
3. 郵送の分の住所を確かめる … postal_mismatch と address_incomplete は、発送の前に本人へ電話します
4. 人数を決める … headcount_mismatch は、受付をした職員に当日の様子を聞いて決めます
5. 台帳と送付リストへ移す … 確認済みにした行を移し、宛名ラベルを印刷します

2番目で、ふりがなを推測で埋めないでください。 読みが分からない氏名は、郵送の分なら本人に電話で、持ち帰りの分なら次に来たときに窓口で確かめることにし、それまで台帳のふりがなは空のままにします。

目標は、480件をならして1件1.5分です。 印の無い行は一覧で流し見て数秒、印の付いた行は画像を見て直すので数分かかります。郵送の分は住所の確かめがある分、窓口の分より時間がかかります。

例外に対処する

上の3行が大半を占めます。 どれもAIの精度の問題というより、申込書の書式と書き方の問題です。 □を大きくする、ふりがなの欄を広げる、願意の名前を□のすぐ横に置くほうが、指示を直すより効きます。

記録を残す

• 申込書の画像と、日付・窓口と郵送の別・申込書の版
• OCR が返した Document の全文（text、formFields、tables、信頼度）
• 生成AIの出力（台帳の項目、flags、variant_chars）
• 照合の結果（郵便番号、人数、崇敬者の名簿）
• 人が直した欄の記録 … どの申込書の、どの欄を、何から何に直したか。直した職員と日時
• 台帳と送付リストへ移した日時と、宛名ラベルを印刷した日時

人が直した欄の記録は、問い合わせへの答えになります。 「お札の宛名の字が違う」と言われたとき、申込書の画像・読み取りの結果・直した記録がつながっていれば、申込書の束を探さずに、どこで字が変わったかが分かります。