葬儀社で遺族が手書きする葬儀の申込書と返礼品・供花の注文票を読み取り、施行台帳と発注の入力案にそろえて、数量と届け先の書き漏れを拾う

処理の起点を決める

施行番号のフォルダにファイルが保存されたことを起点にします。 施行番号は、申込を受けた時点で担当者がフォルダを作って決めます。紙の中身から施行を推定させることはしません。 同じ日に複数の施行があると、喪主の名字が同じだけで取り違えます。

スクリプトは数分おきにフォルダを見て、新しいファイルを1枚ずつ流します。夜にまとめて流す形にはしません。 通夜の当日の昼に発注の締切がある業務で、まとめると間に合いません。

処理が終わったファイルは、同じフォルダの中の処理済みのフォルダへ移します。移すのは成功したときだけです。 施行番号のフォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、書式ごとの項目表です。 Form Parser が値の空の欄を取り出しきれない以上、「どの欄があるはずか」はこちらで持っておく必要があります。 項目表に欄の名前と必須かどうかを持たせ、読み取り結果に出てこなかった必須の欄を blank とします。

施行の情報は、日程の食い違いを見るのに使います。 供花の届け先が会場なのに、届ける日が通夜の日より後になっている、といった食い違いを拾います。

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

読み取りは、スクリプトから Form Parser のプロセッサを呼ぶだけです。PDFを送ると、document の形で結果が返ります。

文字は、要素の中に直接入っていません。 textAnchor.textSegments が、文書全体の文字列 document.text の何文字目から何文字目かを指しているので、スクリプトでその範囲を切り出します。 1つの値が複数の区間に分かれることがあるので、順につなぎます。startIndex が無い区間は0から始まるものとして扱います。

プロセッサの1回の同期の処理は15ページまでです。 1施行の申込書と注文票を1つのPDFにまとめると、超えることがあります。1枚ずつ別のファイルとして送るほうが、欄ごとの対応も取りやすくなります。まとめて流す必要があるときは、非同期の処理（100ページまで）を使います。同期の処理でも、リクエストで imageless モードを有効にすると上限は30ページまで広がりますが、1施行の紙は1枚ずつ送るほうが、どの紙のどの欄かを追いやすく、再実行も1枚で済みます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、JPEG、PNG、BMP、GIF、WebP のいずれかであることを確かめます
2. 解像度の確認 … 公式のページでは、スキャンは最低200dpi、300dpi以上で最もよい結果になるとされています。斎場の複合機の既定の設定を、まずここに合わせます
3. ページの分割 … 1つのファイルに複数の注文票が入っていれば、1枚ずつに分けます
4. 書式の見分け … 見出しの文字と欄の並びで、申込書・自社の返礼品の注文票・自社の供花の注文票・他社の書式（FAXなど）に分けます
5. TIFF の確認 … FAXの受信画像が TIFF のとき、JPEG で圧縮した TIFF は扱えないため、PNG か PDF に変換します
6. 重複の検知 … 同じ施行で、名札と届け先が同じ供花の注文が直近にあれば、二重の注文の候補として印を付けます

6番目は、葬儀ではよく起きます。 会社の総務がFAXで注文し、同じ会社の担当者が斎場で注文票を書く、ということがあります。二重の注文の候補は削らず、担当者に確かめる一覧に出します。

AIに処理させる

生成AIにさせるのは、読み取った値を施行台帳と発注の項目にそろえることだけです。 自社の書式は項目表で対応が決まっていますが、他社の書式（FAXの注文）は欄の名前がばらばらで、「御芳名」「お名札」「札名」が同じ名札の欄を指します。この対応づけに生成AIを使います。

いちばん上の行が、この構成で譲らないところです。 名札の表記は、読み取った文字列を写すだけで、旧字体を常用の字に直す、会社名の「株式会社」の位置を整える、といったことを一切させません。

指示内容を固定する

あなたは葬儀社で、受け取った申込書や注文票の読み取り結果を
施行台帳と発注の項目に整理する担当です。
以下はOCRが読み取った記入欄の名前と値です。書かれていることだけを使い、
推測で補わないでください。

【そろえる項目】
- 名札の表記（nameplate）
- 基数（quantity）と、数字以外で書かれた数量の原文（quantity_text）
- 届け先（delivery_to：会場／自宅／その他／不明）
- 届ける日時（delivery_when）
- 請求先（bill_to）
- 返礼品の品物と数量（gifts）
- 注文した人の連絡先の有無（orderer_contact_present）

【厳守事項】
- 名札の表記は、読み取った文字列を一文字も変えずにそのまま入れてください。
  旧字体・異体字を直す、空白を詰める、法人格の位置を整えることをしないでください。
- 書かれていない項目は「不明」とし、他の欄や施行の情報から推測しないでください。
- 「一対」「1対」など数字以外で書かれた数量は、quantity を null にし、
  原文を quantity_text に入れてください。換算しないでください。
- 欄の名前が「御芳名」「お名札」「札名」などでも、名札の欄として扱ってください。
  どの項目にも当てはまらない欄は other_fields に原文のまま入れてください。
- 連絡先の番号そのものは書き出さず、有無だけを答えてください。
- 二重の注文かどうか、発注してよいかどうかは判断しないでください。
- source_field には、値を取った記入欄の名前をそのまま写してください。

【書式の種類】{form_type}
【施行の日程と会場】{ceremony_info}
【読み取った記入欄の名前と値（信頼度付き）】
{form_fields}
【読み取った表の行】
{table_rows}

「一文字も変えずに」をはっきり書かないと、名札が整えられます。 生成AIは、読みやすい表記に直すことを親切だと考えます。葬儀の名札では、その親切が誤字になります。

連絡先の番号を書き出させないのは、渡す範囲を絞るためです。 発注に要るのは「確かめる先があるか」だけで、番号は元の紙と台帳にあれば足ります。

出力形式を固定する

生成AIの出力は、構造化出力（JSON スキーマ）で受け取ります。 Claude API では output_config.format に json_schema の形でスキーマを渡します。オブジェクトには additionalProperties: false が必要で、数値の minimum ／ maximum の制約は使えないので、基数の範囲は受け取った後にスクリプトで見ます。

{
  "case_no": "",
  "form_type": "application | gift_order | flower_order | external_fax",
  "nameplate": { "text": "", "source_field": "" },
  "quantity": null,
  "quantity_text": "",
  "delivery_to": "会場 | 自宅 | その他 | 不明",
  "delivery_when": "",
  "bill_to": "",
  "gifts": [ { "item": "", "quantity": null, "source_field": "" } ],
  "orderer_contact_present": false,
  "other_fields": [ { "name": "", "value": "" } ]
}

スクリプトは、これと読み取りの信頼度を合わせて、欄ごとに状態を付けます。

1つ目の理由は、blank と unreadable を別の一覧に出せることです。 blank は注文した人への電話、unreadable は担当者が紙を見るだけで済み、確かめる相手が違います。

2つ目は、名札を別の状態として固定できることです。 信頼度が高くても、名札は needs_check のままにします。信頼度は「読めた」の目安であって、「贈り主の表記どおり」の保証ではないからです。

3つ目は、source_field で確かめが速くなることです。 他社の書式でも、どの欄の値を使ったかが分かれば、担当者は画像の該当箇所をすぐに見られます。

システムへ連携する

生花店と返礼品の業者へは、この構成から何も送りません。 発注書は、担当者が確定した入力案から作り、担当者が送ります。誤った数量や名札で発注が飛ぶと、通夜までに取り返せません。

施行台帳への書き込みも、担当者の確定の後だけにします。 入力案のシートと台帳を分けておくと、確かめる前の値が台帳に混ざりません。

人が確認する

1. 名札の全件を、元の画像と見比べる … 確認用のシートに、読み取った名札と、元の画像の名札の欄の切り抜きを並べます。1文字ずつ見比べて確定します
2. unreadable の欄を紙で確かめる … 多くは字がかすれているだけで、紙を見れば分かります
3. blank の欄を注文した人に確かめる … 届け先と数量が空の注文が中心です。遺族への確認はまとめて1回にします
4. 二重の注文の候補を確かめる … 同じ贈り主が2つ贈るのか、重複なのかを注文した人に聞きます
5. 入力案を確定し、台帳と発注に進む

3番目で、遺族への確認をまとめるのが大事です。 書き漏れのたびに遺族に電話をすると、そのたびに打合せの流れが止まります。確認の一覧を見て、次に遺族と会うときにまとめて聞きます。

目標は、600件をならして1件2分です。 filled だけの返礼品の注文票は数十秒、名札のある供花の注文票は見比べに1〜2分、書き漏れのある注文は確認に数分かかります。

例外に対処する

7行目は、運用の取り決めとして先に書いておきます。 通夜の1時間前に届いた供花の注文を、読み取りと確認の流れに乗せる時間はありません。急ぎの注文は従来どおり電話で手配し、後から紙をフォルダに入れて記録だけを残します。

記録を残す

• 元のスキャンとFAXの受信画像、保存した日時、施行番号
• OCRが返した JSON の全文（formFields、tables、document.text、信頼度）
• 生成AIの出力と、そのとき使った書式ごとの項目表の版
• 欄ごとの状態（filled／blank／unreadable／needs_check）
• 担当者が名札を確定したときに直した文字と、直す前の文字列
• 注文した人に確かめた内容と、確かめた日時
• 業者に送った発注書と、送った日時

5つ目の「名札で直した文字」が、いちばん役に立つ記録です。 どの字がどう読み違えられやすいか（旧字体、手書きの「髙」と「高」など）が分かり、確認のときにどこを見ればよいかを担当者の間で共有できます。

保存の期間は、施行台帳と同じ扱いにします。 申込書と注文票には個人の情報が多く含まれるので、台帳の保存期間を過ぎたら画像も消すように決めておきます。