通い箱・パレットの回収状況を追って、返ってこないものを拾う

処理の起点を決める

トリガーは2つあります。最初にここを整理します。

トリガー1は、回収票が受付フォルダに保存されたときです。 スキャンした画像、FAXから変換されたPDF、得意先からのメール添付。いずれも同じフォルダへ集めます。既定の15分ごとでも構いませんが、回収票は便が戻る時間帯に集中するため、平日の1日1回、夕方に動かす設定でも足ります。

トリガー2は、毎月1日です。 得意先ごとの残数と回収のペースを見て、区分へ振り分けます。月単位のスケジュールを設定した、別のシナリオにしてください。

分ける理由は、判断の材料がそろう時点が違うからです。 回収票は1枚ずつ届きますが、「回収のペースが落ちた」は1枚では分かりません。数か月分の記録がそろって初めて言えることです。 1枚読むたびに判定させると、便が1日ずれただけで「遅れている」と出ます。

実務上の理由もあります。 連絡は月に1度まとめるほうが、相手の負担も軽くなります。「先週も連絡が来たのに、また来た」という状態は避けなければなりません。

スケジュールを設定しただけでは動きません。 Makeでは、シナリオを有効化しなければスケジュールは働きません。テストで動かした後、有効化を忘れたまま「動かない」となることがよくあります。 なお最小の間隔はプランによって異なりますが、この構成は1日1回で足りるため制約にはなりません。

再処理の入口も用意してください。 読み取りに失敗した伝票、後から差し替えられた回収票があります。伝票の番号を指定して、もう一度処理できる形にしてください。

入力データを集める

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

容器のマスタが、この構成の質を決めます。 回収票に書かれる容器の呼び方は、得意先ごと、ドライバーごとに揺れます。「青箱」「中箱」「Aケース」が同じものだと機械が知らなければ、残数は合いません。

「呼び方の揺れ」の列がいちばん効きます。 最初は物流部の担当者に思いつくものを挙げてもらい、運用しながら足していく形にしてください。読み取れなかった呼び方が出るたびに1行足せば、半年で実用に足ります。

「標準の往復日数」の列は、長く戻っていないものの判定に使います。 週2回納品の得意先と月1回の得意先では、戻るまでの日数が違って当たり前です。一律に「30日を超えたら督促」とすると、月1回の先が毎月引っかかります。

出荷の記録： 販売管理システムから、出荷日・得意先・容器の種類・数量を読み出します。容器の数が伝票の備考欄にしか入っていない場合は、ここを構造化するところから始めてください。 文章から数を取り出す処理を毎回挟むと、そこが誤差の入口になります。欄そのものが無いなら、この構成より先に欄を作ってください。 出た数が分からなければ、戻った数と比べようがありません。

容器台帳： 現状のExcelは、月ごとの集計表になっていることが多いはずです。得意先 × 容器の種類を行とし、出荷の累計・回収の累計・残数・最終の動きの日付を持つ形へ作り直してください。 集計表では、いつからその残が積まれているのかが分かりません。

過去の確認の履歴は、新たに作る必要があります。 現状はメールや口頭で済んでおり、記録が残っていないはずです。いつ連絡し、相手が何と答え、実際に何個戻ったか。 この3つだけで、次の判断の質が変わります。

AIへ渡す前に整形する

1. ファイル形式の判別 … PDF（文字あり）／PDF（スキャン画像）／画像ファイルを判別します
2. 解像度と文字の高さの確認 … 文字が小さすぎる伝票は、読み取りの前に弾きます
3. ページの分割 … FAXで複数の得意先の票がまとめて届くことがあります。伝票ごとに切り分けます
4. 項目の読み取り … 得意先・容器の種類・数量・回収日を、表の構造を保ったまま取り出します
5. 信頼度の保持 … 項目ごとの信頼度を、後段へそのまま渡します
6. 呼び方の名寄せ … 容器のマスタの「呼び方の揺れ」に照らして、容器コードへ寄せます
7. 得意先の特定 … 得意先名の表記の揺れを、得意先コードへ寄せます

5の信頼度が、この構成の要です。 読み取りの結果は3つの部分に分かれて返ります。認識された全テキストと選択マークをページ・行・単語で整理した部分、表とセルに信頼度を添えた部分、検出された項目の値の部分です。このうち信頼度を必ず後段へ渡してください。

信頼度を捨てると、「読み取れなかった」と「書かれていない」が区別できなくなります。 数量の欄が空だったのか、手書きが薄くて読めなかったのか。前者は伝票を書いた人の問題、後者はスキャンの問題で、直す相手が違います。

キーと値のペアの返却は、既定では無効です。 オプションで有効にできますが、キーが存在しても値が無い場合、キーだけが単独で存在することがあります。 「数量」というキーだけが返る状態です。これを0と解釈しないよう、処理の側で明示的に扱ってください。

2の解像度の確認を読み取りの前に置くのは、入り口で弾くほうが安全だからです。 手書きの数字が最小の文字の高さの目安を割るなら、スキャナの設定を上げてもらうしかありません。

6の名寄せは、機械的な照合で足ります。 マスタに無い呼び方が出たときだけ、人へ回してマスタに足します。

AIに処理させる

処理は5つに分かれます。生成AIに任せるのは、後ろの3つだけです。

（1）読み取り（OCRの側）

伝票の項目を取り出し、項目ごとの信頼度を付けます。ここで数量を確定させません。 読み取った数字は候補です。

（2）突き合わせ（ワークフローの側。生成AIは使いません）

出荷と回収の記録を、得意先 × 容器の種類で突き合わせ、残数といちばん古い残の経過日数を計算します。引き算は機械にさせてください。生成AIに計算させると、合わないときに原因が追えません。

（3）区分への振り分けと説明（生成AIの側）

count_mismatch と undetermined を分けることが、この設計の要です。 前者は伝票の問題で、書いた人か様式を直します。後者は読み取りの問題で、スキャンの設定かマスタを直します。 一緒にすると、どちらを直せばよいか分からない一覧になります。

slow_return と long_outstanding も分けてください。 前者はまだ連絡する段階ではありません。取引量が落ちただけのことがあるので、1か月では判断しません。

（4）差が出た理由の候補を挙げる

実際の紛失、伝票の書き漏れ、他の得意先の箱と混ざった、自社の入庫の記録漏れ。「紛失した」ではなく「この4つのいずれかが考えられ、直近の履歴からはこれが疑わしい」という形にします。

（5）確認の連絡の下書き

「返してください」ではなく「こちらの記録ではこうなっていますが、ご確認いただけますか」の形にします。 数の食い違いは相手を疑う話になりやすいためです。記録の提示にとどめてください。 「紛失分をご負担いただきます」といった、請求につながる文も書かせません。

指示内容を固定する

読み取りの側の指示

回収票の画像から、次の項目を取り出してください。

【取り出す項目】
- 得意先名（伝票に書かれているとおりの文字列）
- 容器の呼び方（伝票に書かれているとおりの文字列。正式名称に直さない）
- 数量（半角の数字）
- 回収日
- ドライバー名または伝票番号

【厳守事項】
- 記載がなければ「不明」としてください。推測で埋めないでください。
- 数量が読み取れない場合は、0ではなく「不明」としてください。
  空欄と読み取り不能を区別してください。
- 容器の呼び方を正式名称に直さないでください。
  「青箱」と書かれていれば「青箱」と返してください。変換は後の処理で行います。
- 1枚の票に複数の容器の種類が書かれている場合は、行ごとに分けて返してください。
- 手書きの数字で 1 と 7、0 と 6 の判別に迷う場合は、
  確定させずに候補を両方挙げ、信頼度を下げてください。

月次の判断の側の指示

あなたは食品メーカーの物流部で、通い箱とパレットの管理を担当する者です。
得意先ごとの残数と回収の履歴を見て、次の連絡が必要かを整理してください。

【厳守事項】
- 得意先が紛失したと断定しないでください。
  「紛失」「未返却のまま」といった、相手の責任を示す書き方をしないでください。
  「こちらの記録では戻っていない数がある」という事実までにしてください。
- 数が合わない理由を1つに決めないでください。
  実際の紛失、伝票の書き漏れ、他の得意先の箱との混同、自社の入庫の記録漏れ。
  考えられるものを挙げ、どれが疑わしいかの根拠を示してください。
- 請求に関する記述をしないでください。
- 記載がなければ「不明」としてください。
  出荷の記録が欠けている期間は「記録なし」とし、前後の月から推定して埋めないでください。
- 数量を自分で計算し直さないでください。
  残数と経過日数は、すでに計算された値を使ってください。
- 読み取りの信頼度が 0.8 未満の伝票を含む得意先は、
  status を undetermined とし、needs_human を true にしてください。
- 連絡の下書きは、返却を要求する文面ではなく、確認を依頼する文面にしてください。
- 一律の日数ではなく、標準の往復日数を超えたかどうかで判断してください。

【得意先の情報（納品の頻度／標準の往復日数／担当営業）】
{customer_profile}

【容器の種類ごとの残数（出荷の累計／回収の累計／残数／いちばん古い残の経過日数）】
{balance}

【直近6か月の回収のペース】
{return_pace}

【この得意先への過去の確認の履歴（連絡日／内容／その後戻った数）】
{contact_history}

【読み取りの信頼度が低かった伝票の一覧】
{low_confidence_docs}

「数量を自分で計算し直さない」の指示が外せません。 残数は引き算で出ます。計算までさせると、合わないときに読み取りの誤りか計算の誤りかを切り分けられません。

「返却を要求する文面にしない」も必ず入れてください。 何も指示しないと、督促状らしい文面が返ります。それがそのまま送られると、取引の関係に直接響きます。

出力形式を固定する

{
  "period": "",
  "doc_id": "",
  "customer": "",
  "container_type": "",
  "shipped_qty": 0,
  "returned_qty": 0,
  "ocr_confidence": 0.0,
  "outstanding_qty": 0,
  "days_outstanding": 0,
  "status": "balanced | slow_return | long_outstanding | count_mismatch | undetermined",
  "possible_reasons": [
    { "reason": "", "basis": "" }
  ],
  "evidence": [
    { "doc_id": "", "page": 0, "field": "", "excerpt": "", "confidence": 0.0 }
  ],
  "message_draft": "",
  "needs_human": { "required": true, "reason": "" }
}

構造化する理由は、後の処理が全部この形に依存するからです。 区分ごとに一覧を分けるのも、信頼度の低いものを上に並べるのも、実際に戻った数を後から突き合わせるのも、決まった項目名があって初めてできます。文章で返されると、そのたびに読み取り直すことになります。

status をenumで固定していることが重要です。 「やや遅れている」といった表現が混ざると、一覧が並べ替えられません。5つのどれかに必ず入る形にしてください。

ocr_confidence を残数と並べて持つことにも意味があります。 残数が400個あっても、読み取りの信頼度が低ければその400という数自体が怪しいのです。信頼度を見ずに残数だけを見る画面を作らないでください。

possible_reasons を配列にしているのは、1つに決めさせないためです。 basis に「直近3か月は伝票の数と一致しており、今月だけ差が出ている」といった根拠を書かせます。evidence には、伝票のどの欄を読んだかまで入れてください。「3枚目の3行目の数量欄」まで示せれば、担当者の確認は数十秒で終わります。

needs_human には理由を持たせます。 真偽だけでは、担当者が何を見ればよいか分かりません。「信頼度が低い」「得意先を特定できない」「出荷の記録が欠けている」のどれかを書かせてください。

システムへ連携する

出力は一覧と下書きを作るだけで、外部への送信は行いません。

得意先へ自動で連絡しないでください。 これがこの構成でいちばん重要な線引きです。数の食い違いの連絡は、相手を疑う話になりやすく、関係に直接ひびきます。 下書きは作りますが、送るのは人です。

営業担当を通すかどうかも決めてください。 物流部から直接、得意先の窓口へ連絡する会社もあります。どちらでも構いませんが、決めずに始めると連絡が重なります。

販売管理システムへの書き戻しは行いません。 出荷の記録は読むだけです。残数を売掛の情報に紐づけないでください。 購買システムへの起票も自動にしません。補充するかどうかは、単価と使用の見込みを見て人が決めることです。

人が確認する

物流の担当者の確認は必ず残します。

3つ目が最も重要です。 こちらの記録が欠けているだけなのに「戻っていません」と連絡すると、相手に記録を出されて終わります。一度これをやると、次から連絡が軽く扱われます。

確認を速くするための設計が効きます。

• 信頼度の低い項目を、一覧の上に並べる
• 伝票の該当の行の画像を、一覧から直接開けるようにする
• 出荷の記録と回収の記録を、日付順に左右で並べる
• 前回の連絡の内容と、その後に戻った数を横に置く
• 連絡の文面を、その場で直して保存できる欄を置く

4つ目が、次の判断の質を決めます。 前回連絡して翌月に全部戻った先と、連絡しても動かない先を、同じ扱いにすべきではありません。記録に残さなければ、これは担当者の記憶の中だけに残ります。

「連絡しないと決めた」も記録してください。 残っていないと、翌月も同じものが一覧の上に出てきて、毎月同じ判断を繰り返すことになります。

例外に対処する

「同じ回収票が二重に届く」は必ず起きます。 ドライバーが持ち帰った現物と、得意先からのFAXの両方が届くためです。伝票番号で弾く仕組みを、最初から入れてください。

そして「マイナスの残数」を放置しないでください。 二重の計上か、他の得意先の箱が混ざって戻ってきた可能性があります。 放置すると、混ざった先の残数がいつまでも合いません。

記録を残す

この記録は、翌月以降の判断に直接使われます。

• 処理した回収票の一覧と、受付日
• 項目ごとの読み取り結果と、信頼度
• 出荷の記録との突き合わせの結果
• 得意先 × 容器の種類ごとの残数の推移
• 振り分けられた区分と、その根拠
• 担当者が確認した結果（連絡した／見送った／伝票の誤りだった）
• 連絡の文面と、送った日
• 連絡の後に実際に戻った数と、その日付
• 読み取りが誤っていた事例（数字の読み違い、得意先の取り違え）

「連絡の後に実際に戻った数」の記録が最も効きます。 連絡して戻る先と、戻らない先が分かれます。戻らない先には、容器の種類を変える、預け数の上限を決めるといった別の手立てが要ります。

「伝票の誤りだった」事例も必ず記録してください。 count_mismatch の原因が伝票側に集中している得意先があれば、回収票の様式をそろえてもらう交渉の材料になります。 読み取りの誤りが特定のドライバーの伝票に集中しているなら、書き方を揃えてもらうほうが早いこともあります。

容器台帳の残数は、月ごとの断面を残してください。 上書きだけだと、いつから残が積まれ始めたのかが後から追えません。