店舗から物流センターに届く手書きの返品伝票を読み取り、店舗・品番・数量・返品理由を返品データにそろえて、出荷実績との数量の食い違いと理由の書き漏れを拾う

処理の起点を決める

Google Apps Script の時間主導型のトリガーで、10分ごとに受付フォルダを確かめます。 インストール型のトリガーには、毎分から月1回までの間で動かせる時間主導型のトリガーと、開いたとき・編集したとき・フォームの送信などの出来事で動くトリガーがあります。Google ドライブにファイルが追加されたことで動くトリガーは一覧に無いので、時間で見回る形にします。

実行の時刻には少し揺らぎがあります。 公式のページでも、時刻が少しばらつくことがあると書かれています。返品の受付は即時性を求めない業務なので、10分の間隔で十分です。

インストール型のトリガーは、作った人のアカウントで動きます。 個人のアカウントで作ると、その人が異動や退職でいなくなったときに止まります。 センターの業務用のアカウントで作り、共有ドライブの権限もそのアカウントに付けます。処理が終わったPDFは処理済みのフォルダへ移します。 移すのは成功したときだけにし、受付フォルダに残っている数がそのまま未処理の数になるようにします。

入力データを集める

質を決めるのは、商品マスタと出荷実績の鮮度です。 前の日の出荷が反映されていないと、昨日届いた商品をすぐ返品した行が「出荷実績を超える」になります。 倉庫管理システムからの書き出しは毎朝の始業前に終わらせ、その時刻をファイル名に入れます。

センター検品数の欄は、様式に足します。 これまでは伝票の数量の横に手で書き込んでいましたが、決まった欄が無いと、OCRはどの数字が検品数かを区別できません。 本部と相談し、明細の右端に「センター検品数」の列を設けます。

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

PDFは、Apps Script から Document AI の処理のAPIへ送ります。 応答はJSONで、ページごとに formFields（キーと値のペア）と tables（表）が入っています。

キーと値のペアのキーは、伝票に印刷されている文字そのものです。 公式のページでも、ほかの抽出のように名前を設定するものではなく、書類の上のキーの文字がそのまま返るとされています。「店舗コード」「店コード」のように様式の版で印刷の文字が違うときは、Apps Script の側で同じ項目にまとめます。

返品理由の印は、明細の行ごとに結び付け直します。 チェックボックスは、近くの文字をキーにしたペアとして返るので、どの行の印かは、印の位置（boundingPoly）と表の行の位置を比べて決めます。 行の高さの範囲に入る印を、その行の理由とします。

AIへ渡す前に整形する

1. 形式の確認 … PDFであることを確かめます。複合機の設定でJPEGの圧縮を使ったTIFFが混ざることがありますが、TIFFの中のJPEGの圧縮の一部には対応していないとされているので、スキャンはPDFにそろえます
2. 1ファイル1枚にそろえる … 複合機でまとめてスキャンしたものは、ページで分けます
3. 向きの確認 … 逆さまや横向きのページは、向きを直してから送ります
4. 重複の確認 … 同じ店舗・同じ返品日・同じ明細の伝票が直近にあれば、二重のスキャンとして印を付けます
5. 商品マスタと出荷実績の読み込み … その朝の書き出しのファイルの日付を確かめ、前の日より古ければ処理を止めます

5番目を省くと、すべての照合がずれます。 書き出しが止まっていた日に動かすと、数日分の出荷が反映されないまま、大量の行に「出荷実績を超える」が付きます。 古いファイルで照合するより、止めて知らせるほうが確実です。

AIに処理させる

AIにさせることは2つの段に分かれます。 Document AI に伝票を読ませる段と、Claude に品番の候補を選ばせ、「その他」の理由を区分させる段です。品番の照合、出荷実績との突き合わせ、印の付け方は、Apps Script の決まった規則で行います。

返品理由の行が、この構成でいちばん大事な区別です。 印が6つとも unfilled_checkbox として検出され、その他の欄にも文字が無ければ、店舗が理由を書いていないということです。一方で、四角そのものが検出されなかったり、信頼度が低かったりするなら、センターで伝票を見れば分かることです。

Form Parser には、空欄の値を確実には取り出せないという制限があります。 公式のページでも、値の入っていないキーと値のペア（白紙の様式など）を確実には解析しないと書かれています。だから、「その他」の欄が空かどうかを、キーと値のペアの値が無いことだけで決めません。その欄の位置の範囲に、全文の文字が1つも無いことをあわせて確かめます。

Claude には、品番の無い行と引けない行の品名だけを渡します。 商品マスタから、品名の文字が近い候補を Apps Script で10件まで絞り、その中から選ばせます。マスタの外の品番を作らせないために、候補の番号から選ぶ形にします。 出力は、Claude API の構造化出力で決まった形のJSONにします。output_config.format に json_schema を指定すると、スキーマに合ったJSONが返ります。

2行目がいちばん起きやすい失敗です。 品名に「割れ」と書かれていれば、理由は破損らしく見えます。生成AIに渡すと、もっともらしく「破損・汚損」を選びます。 理由の集計は商品部が発注と仕入先の評価に使う数字です。推し量った理由が混ざると、集計そのものが信用できなくなります。

指示内容を固定する

あなたは物流センターで、店舗から届いた返品伝票の明細を整える担当です。
渡す情報だけを見て判断してください。推測で埋めないでください。

【あなたがすること】
1. 品番の無い行・商品マスタで引けなかった行について、
   渡す候補（最大10件）の中から、品名と規格が一致するものを1つ選ぶ。
2. 返品理由が「その他」で、その他の欄に文字が書かれている行について、
   次の区分のどれに当たるかを選ぶ。
   破損・汚損／期限間近／誤納品／過剰在庫／不良品／その他

【厳守事項】
- 品番は、渡した候補の candidate_id から選んでください。
  候補に一致するものが無ければ candidate_id を null にし、status を not_found にしてください。
  候補の外の品番を作らないでください。
- 品名が一致していても、規格（容量・色・サイズ）が違う候補を選ばないでください。
  規格が読み取れないときは status を ambiguous にしてください。
- 返品理由は、その他の欄に書かれた文字だけを根拠にしてください。
  品名や数量から理由を推し量らないでください。
- その他の欄が空の行、理由の印が無い行は、あなたに渡しません。
  渡されていない行の理由を書かないでください。
- 区分に当てはまらない理由は「その他」のままにし、書かれた文字を evidence に写してください。
- 数量を変えないでください。
- evidence には、判断の根拠にした文字をそのまま写してください。

【明細の行】{lines}
【品番の候補】{candidates}

「渡されていない行の理由を書かない」を入れているのは、理由の空欄を守るためです。 理由の印が無い行は、そもそも Claude に渡しません。それでも、同じ伝票の他の行を見て「この伝票は破損の返品」と書き足すことがあります。 渡す範囲と、書いてよい範囲を両方で縛ります。

出力形式を固定する

伝票1枚ごとに、次の形のJSONを作り、明細の行を返品データの一覧に書き込みます。

{
  "slip_id": "RS-2026-1008-0153",
  "file": "RS_20261008_101530.pdf",
  "store": { "code": "", "status": "ok | unreadable | not_found" },
  "return_date": "2026-10-06",
  "lines": [
    {
      "line_no": 1,
      "item_code": "",
      "item_status": "ok | from_candidate | not_found | ambiguous | unreadable",
      "item_name": "",
      "qty": 0,
      "qty_status": "ok | unreadable",
      "center_count": 0,
      "reason": "破損・汚損 | 期限間近 | 誤納品 | 過剰在庫 | 不良品 | その他 | ",
      "reason_status": "ok | missing | unreadable | ambiguous",
      "shipped_90d": 0,
      "flags": ["over_shipped", "count_diff"],
      "confidence": { "item": 0.00, "qty": 0.00 },
      "evidence": ""
    }
  ],
  "verdict": "pass | needs_check | needs_store_inquiry"
}

1つ目の理由は、reason_status で書き漏れと読めないを分けられることです。 missing は店舗への問い合わせ、unreadable はセンターでの見直しに回ります。返品データの理由の欄は、どちらも空のままにし、空の理由を別の欄で持ちます。

2つ目は、verdict を規則で決められることです。 規則は次のとおりです。

3つ目は、from_candidate を ok と分けて持つことです。 品名から候補で選んだ品番は、伝票に書かれていた品番ではありません。pass にはしますが、一覧で色を変えて見せ、店舗ごとの件数を数えます。 毎月多い店舗には、品番を書いてもらうよう本部から伝えます。

システムへ連携する

倉庫管理システムへの取り込みは、1日2回にまとめます。 確かめ終わった行だけを取り込みの形のCSVに書き出し、事務担当が取り込みます。未確認の行は書き出しの対象にしません。

人が確認する

事務担当が開くのは、needs_check と needs_store_inquiry の伝票だけです。 pass の伝票は一覧で件数と店舗を流し見ます。

1. needs_check を先に見る … unreadable の行は伝票の画像を見て直します。多くはセンターだけで解決します
2. count_diff は返品の担当に確かめる … 実物の数え直しか、輸送中の抜けかを確かめます
3. needs_store_inquiry の根拠を確かめる … missing の行は、画像で理由の四角が本当に空かを目で見ます
4. 店舗へ問い合わせる … 店舗ごとの一覧で、1店舗1回にまとめます
5. 直した内容を記録する … どの行の何を、何から何に直したかを残します

3番目を省かないでください。 missing の判定は、店舗の作業を止める問い合わせに直結します。 印が薄くて検出されなかっただけの行を問い合わせると、次から店舗がこの問い合わせを軽く扱うようになります。

目標は、900枚をならして1枚1分です。 pass の伝票は数秒で流し、印の付いた伝票は画像を見て数分かかります。印の付く伝票が2割を超える月は、様式か店舗の書き方に原因があります。

例外に対処する

7行目の over_shipped は、店舗の不正を疑う材料にしません。 多くは品番の1桁違いか、別の店舗から移ってきた商品です。確かめる順番は、品番の書き間違い、店舗間の移動の記録、そのあとで店舗への問い合わせです。

記録を残す

• 元の伝票のPDFと、スキャンの日時
• Document AI が返したJSONの全文
• 明細の行ごとの判定（status・flags・verdict）と、そのとき使った商品マスタと出荷実績の書き出しの日付
• Claude に渡した候補と、選んだ候補・根拠
• 人が直した記録 … どの行の何を、何から何に直したか
• 店舗への問い合わせの日時と、店舗の回答
• 店舗ごとの missing・from_candidate・unreadable の件数

3つ目で書き出しの日付を残すのは、照合のやり直しの範囲を決めるためです。 出荷実績の書き出しが遅れていた日が後から分かったとき、その日付で照合した伝票だけを照合し直せます。