小売店で手書きされる客注（取り寄せ）伝票を読み取り、客注台帳にそろえて、入荷したのに連絡していないものと長く引き取られていないものを拾う

処理の起点を決める

閉店後に、その日の店控えを撮って店の取込フォルダに保存することを起点にします。 店には複合機が無いことが多いので、店のスマートフォンで撮ります。1枚1ファイルで撮り、ファイル名は気にしません。 伝票番号は伝票に印刷されているので、読み取りで決まります。

Apps Script の時間主導型トリガーが、毎日夜に8店舗の取込フォルダを順に見ます。 公式のページでは、時間主導型のトリガーは指定の時刻や間隔で動かせ、実行の時刻は少しずれることがあるとされています。翌朝の開店前に台帳と一覧ができていれば足りるので、夜の1回で十分です。

入荷データの照合は、別のトリガーで朝に動かします。 仕入先の入荷データが共有ドライブに届く時刻に合わせ、届いたら照合し、続けて一覧を作ります。 伝票の読み取りが止まっていても、入荷の照合と一覧は出続けるように分けておきます。

処理が終わった画像は処理済みのフォルダへ移します。移すのは、台帳への登録まで成功したときだけです。 取込フォルダに残っている画像が、未処理の伝票です。

入力データを集める

質を決めるのは、商品マスタの「シリーズ名と巻数」の列です。 書店の客注でいちばん多いのは、シリーズものの特定の巻です。店員は「〇〇 12巻」と書き、マスタの商品名は「〇〇（12）」や「〇〇 第12巻」になっています。 シリーズ名と巻数を別の列で持っていれば、AIがそろえた検索語で引けます。

伝票番号は、伝票と台帳を結ぶ鍵です。 印刷された通し番号なので、手書きの字より読み取りが確かです。同じ伝票番号の行が台帳にすでにあれば、新しく登録しません。 撮り直した画像が二重に登録されるのを防ぎます。

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

読み取りは、Apps Script から Document AI の処理の API を呼ぶだけです。画像を渡すと、Document という形の応答が返ります。

客の名前と電話番号は、Apps Script が項目名と値の組から直接台帳に書きます。 AIには渡しません。電話番号は数字とハイフンだけになっているかを Apps Script で確かめ、桁が足りなければ unreadable にします。 連絡ができない電話番号は、受付の翌日に分かるほうがよいからです。

商品の欄は、Claude API に渡してそろえます。 商品マスタの検索は Apps Script が行い、AIには商品マスタを渡しません。 AIが返す検索語と品番で、Apps Script がマスタを引きます。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP などです。スマートフォンの写真の JPEG はそのまま入れられます
2. 画質の確認 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。伝票を枠いっぱいに、真上から撮るよう、撮り方を1枚の紙でレジ横に貼ります
3. 複写の濃さ … 店控えは複写の2枚目なので、文字が薄いことがあります。受付のときに強めに書くよう、伝票の上に一言印刷します
4. 様式の改訂 … 「連絡方法　電話・メール・来店時」の○を付ける欄を、□ にレ点を入れる欄に改めます
5. 重複の検知 … 伝票番号が台帳にすでにあれば、登録しません

4番目は、伝票を刷り直すときに行います。 Form Parser のチェックボックスのモデルはラジオボタンに対応しないとされているので、○で囲む欄は読めません。刷り直すまでは、連絡方法は読まずに「電話」を既定にし、客注担当が台帳で直します。

AIに処理させる

させるのは、伝票の商品の欄から、商品マスタを引ける検索語と品番を取り出すことだけです。

検索語を「略さない形で」にしているのは、店員の略記のためです。 「ワンピ」「ハリポタ」のような略記は、マスタの商品名では引けません。略記をよく知られた正式な名前に直すことまではAIに任せ、直した名前が商品マスタに無ければ、候補なしとして人に回します。

商品コードの候補は、Apps Script が商品マスタで引きます。 検索語と巻数で引いて1件だけ当たれば確定、複数当たれば候補を並べて candidates、当たらなければ not_found にします。

1行目がいちばん起きやすい失敗です。 書籍の客注で商品名を渡すと、AIはISBNやJANらしい番号を返そうとします。それらしい番号は、マスタに無い番号か、別の版の番号であることがあります。 番号を作らせず、検索語だけを返させます。

指示内容を固定する

あなたは書店・文具店の本部で、客注伝票の商品の欄を整える係です。
渡すのは、伝票1枚の商品の欄と数量の読み取り結果です。
客の情報は含まれていません。
書かれている文字だけを使って、商品マスタを引くための語を返してください。

【やること】
1. item_type：book（書籍）／magazine（雑誌）／stationery（文具）／
   other／unclear のいずれか
2. search_term：シリーズ名や商品名。店員の略記は、よく知られた
   正式な名前に直してください。自信がなければ書かれたままにしてください。
3. volume：巻数・号数を数字で。書かれていなければ空
4. part_no：品番・型番。書かれた英数字をそのまま
5. maker：メーカー・出版社・著者。書かれていれば
6. quantity：数量を数字で
7. evidence：取り出した元の文字列をそのまま写す
8. status：read／unreadable（文字はあるが信頼度が低い・読み方が2つ以上）

【厳守事項】
- ISBN、JAN、商品コードを作らないでください。書かれていなければ空です。
- 品番の桁を補ったり、似た型番に直したりしないでください。
- 略記を正式な名前に直したときは、note に「略記を直した」と書いてください。
- 1枚の伝票に商品が複数書かれていれば、items に分けて返してください。
  まとめないでください。
- 在庫があるか、取り寄せられるかは書かないでください。

【読み取り結果】{item_fields}

「コードを作らない」を最初の厳守事項にしているのは、AIが親切に番号を補うからです。 補われた番号は、台帳の上では確定した商品コードと見分けがつきません。入荷データと照合されないまま、連絡漏れの一覧にも出ない伝票になります。

「略記を直したら note に書く」は、人が確かめる場所を残すためです。 直した名前で商品マスタに1件だけ当たっても、略記の読み方が違っていれば別の商品です。 note のある行は、確定でも客注担当が一度見ます。

出力形式を固定する

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

{
  "slip_no": "S03-004512",
  "items": [
    {
      "item_type": "book",
      "search_term": "ONE PIECE",
      "volume": "110",
      "part_no": "",
      "maker": "",
      "quantity": 1,
      "evidence": "ワンピ 110巻",
      "status": "read",
      "note": "略記を直した"
    },
    {
      "item_type": "stationery",
      "search_term": "替刃",
      "volume": "",
      "part_no": "",
      "maker": "",
      "quantity": 2,
      "evidence": "〇〇の替刃 5本入 ×2 型番?",
      "status": "unreadable",
      "note": "型番の欄の文字が読めない"
    }
  ]
}

1つ目の理由は、客の情報とAIの入出力を切り離せることです。 AIに渡すのは商品の欄と数量だけで、slip_no で台帳の行に結び付けるのは Apps Script です。AIの入出力のどこにも、客の名前と電話番号が出てきません。

2つ目は、items で1枚の伝票の複数の商品を分けられることです。 文具の客注では、1枚に色違いや別の品番が並ぶことがあります。まとめて1行にすると、片方だけ入荷したときに照合できません。

公式のページでは、列挙の値の大文字・小文字までは保証されないとされているので、item_type と status は Apps Script で小文字にそろえてから使います。stop_reason が max_tokens のときは出力が途中で切れているので、台帳に登録せずに呼び直します。

台帳の状態と一覧は、Apps Script が次の規則で決めます。

日数は、店で決めて規則に書きます。 書店と自転車店では、引き取りまでの待ち方が違います。最初は1日と14日で始め、一覧の件数を見て店長と調整します。

システムへ連携する

入荷の照合は、同じ店・同じ商品コードの ordered の行のうち、受付日の古い順に当てます。 同じ商品の客注が2件あるとき、先に注文した客から入荷を割り当てます。今まで店員が伝票の受付日を見て決めていた順を、そのまま規則にしたものです。 入荷の数量が足りなければ、残りは ordered のままにします。

POSには書き込みません。 客注台帳は売上の記録とは別のもので、引き取りの会計は今までどおりレジで行います。

人が確認する

1. 毎朝、店ごとの一覧を見る … 「未連絡」は当日中に連絡し、台帳に連絡日を入れます
2. 商品コード未確定を選ぶ … candidates の候補から選ぶか、not_found なら商品マスタを検索して入れます。note に「略記を直した」がある行も一度見ます
3. 電話番号の unreadable を直す … 伝票の画像を見て直し、読めなければ受付者に確かめます
4. 未引取を店長に回す … 再連絡するか、返品するかを店長が決めます

全件の確認はしません。 商品コードが1件で当たり、note も印も無い行は、そのまま台帳に入ります。確認するのは、印の付いた行と一覧に出た行だけです。 これが human_check を「条件付き」にしている理由です。

ただし、最初の1か月は全件を見ます。 略記の直し方と商品マスタの当たり方が店ごとに違うので、どの店のどんな書き方で外れるかを、全件で確かめてから条件付きに移ります。

例外に対処する

4行目が、今まで連絡漏れが起きていた原因の1つです。 入荷データの客注の区分は付かないことがあり、区分だけを見て伝票を探すと、区分の無い客注品を見落とします。 商品コードで照合すれば、区分の有無にかかわらず当たります。

記録を残す

• 伝票の画像と、撮った日時と店
• Document AI が返したJSONの全文
• Claude API に渡した商品の欄と、返ってきたJSON
• 客注台帳の状態の変化（登録、入荷、連絡、引取、取消）と、人が直した記録
• 一覧の日ごとの控えと、そのときの日数の規則の版

状態の変化を残すのは、客から問い合わせが来たときに答えるためです。 いつ入荷して、いつ誰が連絡したかが台帳に残っていれば、伝票の束を探さずに答えられます。