チラシのポスティングを請け負う会社で、配布員が手書きする配布報告書を読み取り、地区・配布枚数・不配の理由を配布実績の台帳にそろえ、広告主への報告の前に計画との差を拾う

処理の起点を決める

営業部の担当が朝に回収箱から報告書を出し、複合機でまとめてスキャンして取込フォルダに保存することを起点にします。 報告書は1人1日1枚なので、束のまま両面なしで通し、1つのPDFにします。 ファイル名にはスキャンした日付を入れます。

Python のスクリプトを、事務所のPCで15分ごとに定時実行します。 新しいPDFがあれば、ページごとに1枚の報告書に分けてから処理します。台帳への書き込みまで成功したページだけを処理済みとして記録し、失敗したページは次の実行で拾い直します。

毎日の一覧は、別のスクリプトで昼の12時に作ります。 午前中に回収とスキャンを済ませれば、午後のうちに配布員へ確かめの電話ができます。 配布員の多くは午後から夕方に配るので、その前に連絡がつくようにします。

入力データを集める

質を決めるのは、不配の理由の区分です。 区分は広告主への説明に使う言葉で決めます。たとえば「投函禁止の表示」「管理人・住人に断られた」「空き家・空き室」「立ち入れない（オートロックなど）」「天候で中止」「その他」です。区分ごとに、配布員がよく書く表記を集めておきます。

町丁目の一覧は、地名の読み違いをそろえるために使います。 手書きの「本町2」「本2」「本町二丁目」を同じ町丁目として扱えるようにします。ただし、一覧に無い地名を一覧のどれかに寄せることはしません。

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

読み取りは、Python から Document AI の処理の API を呼ぶだけです。公式のページには Python のクライアントライブラリで応答を扱う例が載っています。返ってきた Document から次のものを取ります。

指示書番号は、計画の行を探す鍵です。 読み取った番号で計画を引き、完全に一致する指示書が1つだけあるときだけ結び付けます。 番号が読めないときに、配布員の名前と日付から指示書を推すことはしません。配布員は1日に複数の指示書を持つことがあるからです。 結び付かなければ no_plan として担当者が確かめます。

表は、見出しの行で列を決めます。 「町丁目」「配布枚数」「残数」の見出しで列の位置を決め、見出しが読めないときに列の並び順で推すことはしません。 配布枚数と残数の列を取り違えると、差の計算がすべて狂います。

AIへ渡す前に整形する

1. 書式の見直し（導入時に1回） … 広告主の欄の結合をなくし、1行に1町丁目の単純な格子にします。上部に「指示書番号」の欄を足します
2. 1枚ずつに分割 … まとめてスキャンしたPDFをページごとに分けます。オンラインの処理は1回の要求で最大15ページです
3. 形式と画質の確認 … Document AI の対象は PDF や画像です。公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。鉛筆の報告書のために、複合機の設定を300dpi以上・濃いめに固定します
4. 白紙と裏面の除外 … 文字のほとんど無いページは、報告書として扱わず飛ばします
5. 重複の検知 … 同じ指示書番号・同じ配布員のものが2枚あれば、後のものを書き直しとして扱い、前のものも残します

3番目の「濃いめ」がいちばん効きます。 屋外で鉛筆で書かれた報告書は、数字が薄く、雨でにじんでいることもあります。数字の信頼度は、スキャンの濃さで目に見えて変わることがあります。

AIに処理させる

させるのは、表の行を台帳の項目にそろえ、不配の理由を区分に当てることだけです。 計画との照合と差の計算は Python が行います。

Python が比べる規則は次のとおりです。

4行目の割合は、町丁目ごとの事情で変わります。 集合住宅の多い町丁目は、投函禁止で配れない枚数がもともと多めです。割合は一律にせず、町丁目の過去の実績から決めると、一覧が本当に見るべきものに絞れます。

1行目がいちばん起きやすい失敗です。 残数の欄が空の行を渡すと、AIは「渡した枚数 − 配布枚数」を計算して残数を埋めようとします。埋めた残数で差は0になり、確かめるべき報告が一覧から消えます。 そもそもAIには渡した枚数を見せず、計画との照合は Python で行います。

指示内容を固定する

あなたはチラシのポスティング会社の営業部で、配布員の配布報告書を
配布実績の台帳に記録する担当です。
渡すのは、報告書1枚の読み取り結果です。
書かれている文字だけを使って、町丁目ごとに値を並べてください。
推測で埋めないでください。

【やること】
1. staff：「配布員」の欄の文字をそのまま写す
2. order_no：「指示書番号」の欄の文字をそのまま写す
3. 表の各行について次を並べる
   area：町丁目。町丁目の一覧に当たれば一覧の名前、無ければ書かれたまま
   date：配布日
   delivered：配った枚数（数字だけ）
   returned：残数（数字だけ）
   reason_text：不配の理由として書かれた文をそのまま
   reason_code：reason_text を不配の理由の区分に当てた結果。
                当たらなければ other、書かれていなければ none
4. 項目ごとに status を付ける
   read（読めた）／missing（欄に値が無い）／unreadable（読めない）
5. evidence に、根拠にした文字列をそのまま写す

【厳守事項】
- 配った枚数や残数が書かれていない欄を、計算で埋めないでください。
  missing のままにします。
- 読めない数字を、ほかの行の数字や切りのよい数字に寄せないでください。
- 不配の理由の文を書き換えたり、言葉を足したりしないでください。
- reason_code は区分の一覧にあるものだけを使ってください。
- 配布員が実際に配ったかどうか、報告が正しいかどうかは書かないでください。
- 欄外のメモは note にそのまま写してください。

【町丁目の一覧】{areas}
【不配の理由の区分と表記の一覧】{reason_codes}
【読み取り結果】{ocr_result}

AIに渡す情報から、計画の枚数を外しているのは意図してのことです。 渡した枚数が見えると、AIは読めない数字をそれに合わせて読もうとします。計画を知らない状態で読ませ、照合は後ろの Python に任せます。

reason_text と reason_code を両方残すのは、区分が後から変わるからです。 広告主から「オートロックで入れなかった枚数を別に知りたい」と言われたら、区分を足して reason_text から当て直せます。 書かれた文が残っていないと、過去の分は当て直せません。

出力形式を固定する

Claude API の構造化出力を使い、次の形のJSONで受け取ります。 output_config.format に JSON スキーマを渡すと、応答がそのスキーマに沿った形になります。

{
  "file": "20261008_scan.pdf",
  "page": 14,
  "staff": "佐藤",
  "order_no": "A-10342",
  "rows": [
    { "area": "本町二丁目", "date": "10/7",
      "delivered": "380", "returned": "20",
      "reason_text": "マンション チラシお断り", "reason_code": "no_flyer_sign",
      "status": { "delivered": "read", "returned": "read" },
      "evidence": "本2 380 20 ﾏﾝｼｮﾝ ﾁﾗｼお断り" },
    { "area": "本町三丁目", "date": "10/7",
      "delivered": "410", "returned": "",
      "reason_text": "", "reason_code": "none",
      "status": { "delivered": "read", "returned": "missing" },
      "evidence": "本3 410" }
  ],
  "note": "雨のため途中で中断"
}

1つ目の理由は、差の計算をAIの外に出せることです。 AIが返すのは報告書1枚の値までで、計画との照合は Python が行います。上の例の2行目は残数が missing なので、差を計算せずに「枚数の合わない報告」の候補として一覧に出します。

2つ目は、数字を文字列のまま受け取ることです。 「380」を数値にしてから返させると、「38O」のような読み違いが黙って別の数になります。文字列で受け取り、Python で数字だけかを確かめてから数値にします。

3つ目は、note に欄外のメモが残ることです。 「雨のため途中で中断」と書かれていれば、残数の多さの理由が分かります。一覧にメモが載っていれば、配布員に電話する前に当たりを付けられます。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、reason_code と status は Python で正規化してから使います。stop_reason が max_tokens のときは出力が途中で切れているので、台帳に書かずに呼び直します。

システムへ連携する

台帳への書き込みは、実績と印の列だけにします。 計画の枚数は営業部が広告主と決めた値で、報告書の値で上書きしません。 差がある行には印を付け、どちらが正しいかは担当者が確かめます。

広告主への完了報告は、この構成からは送りません。 完了報告の下書きの表までは台帳から作れますが、送る前に担当者が差のある行を確かめ終えていることが条件です。

人が確認する

1. 毎日昼、「枚数の合わない報告」を見る … 配布員に電話で確かめ、残数の書き忘れや行の書き違いなら台帳を直します。直した記録は台帳の別の列に残します
2. 「報告の無い町丁目」を見る … 配布員に報告書の出し忘れか、まだ配っていないのかを確かめます。配布期間の終わりが近い町丁目から先に見ます
3. 「不配の多い町丁目」と区分 other を見る … 理由を読み、区分に足すべき表記なら一覧に足します
4. 完了報告を出す … 配布期間の終わった広告主について、差のある行が残っていないことを確かめてから送ります

1番目を翌日にするのは、配布員の記憶が新しいうちに聞くためです。 1週間たつと、どの町丁目で何があったかを配布員は覚えていません。その日のうちに聞けば、ほとんどは書き方の間違いとして片付きます。

電話で聞く順番も決めておきます。 差が大きい行、配布期間の終わりが近い広告主の行、区分 other の行の順です。同じ配布員の行はまとめて1回の電話で聞き、1日に何度も同じ人へ電話しないようにします。

目標は、1,200枚をならして1枚1.5分です。 印の付く報告書が2割前後という想定で、それより多い月は、書式か、特定の配布員の書き方を疑います。

例外に対処する

4行目は、複数の広告主を重ねて配る日に起きます。 1回の配布で2つの指示書を持って出ると、配布員は1枚の報告書にまとめて書きがちです。行ごとに指示書番号を書く欄を足すと、1枚にまとまっていても結び付けられます。

記録を残す

• スキャンしたPDFと、スキャンした日付（紙の原本は、社内で決めた期間保管する）
• Document AI が返したJSONの全文
• Claude API に渡した入力と、返ってきたJSON
• 台帳に書き込んだ実績、差、印、人が直した記録と、配布員に確かめた内容
• 毎日の一覧の控えと、そのときの不配の理由の区分の版
• 広告主に完了報告を送った日と、送った内容

人が直した記録を残すのは、広告主から問い合わせを受けたときに説明するためです。 「本町三丁目の残数が後から変わったのはなぜか」と聞かれたら、いつ、配布員に何を確かめて直したかを示せます。