荷主からメールで届く出荷依頼の本文・PDF・表計算の添付から、出荷先・品番・数量・指定日を倉庫管理システムの取込形式にそろえ、不足と矛盾を確認文にする

処理の起点を決める

出荷依頼のラベルが付いたメールが届いたことを起点にします。 当日出荷の締めは14時で、締めの前の1時間に依頼が集中します。定時にまとめて処理すると、締めに間に合わない依頼が出ます。 シナリオは短い間隔で動かします。

業務課の共用メールには、荷主からの問い合わせや請求、運送会社からの連絡も届きます。Gmail のフィルタで、荷主ごとの登録アドレスから届いたものに「出荷依頼」のラベルを付け、そのラベルだけを見張ります。 件名で絞ると、「出荷依頼の件で」という問い合わせまで拾います。

取り込んだメールには、処理の結果で「取込待ち」「要確認」のラベルを付け直します。ラベルが「出荷依頼」のまま残っているメールが、未処理の数です。

入力データを集める

質を決めるのは、取込定義の表です。 「この荷主の数量はケース」「この荷主は納品日を書いてくる（出荷日ではない）」という区別が無いと、生成AIが正しく取り出しても、取込の項目に入れる場所を誤ります。

マスタは毎朝、倉庫管理システムから書き出した写しを使います。 生成AIにはマスタ全体を渡しません。照合はワークフローの側で行います。

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

表計算の添付は、行をそのまま生成AIに渡します。 列の名前が「品番」「商品コード」「JAN」と荷主ごとに違っても、生成AIに列の意味を判定させ、取込の項目に対応づけます。 対応づけの結果は荷主ごとに保存し、次から同じ形のファイルが来たら、前回の対応づけを渡して確かめさせるだけにします。

PDFは、ページ数と大きさを確かめてから渡します。 出荷指示書は1〜3ページが多く、上限に近づくことはまずありません。

AIへ渡す前に整形する

1. 荷主の特定 … 差出人のアドレスで取込定義の表を引きます。登録外のアドレスは処理せずに担当者へ
2. 添付の振り分け … 拡張子とファイルの種類で、PDF・表計算・それ以外に分けます。画像や圧縮ファイルは担当者へ
3. パスワード付きPDFの検知 … 開けないPDFは扱えないため、荷主にパスワードの無いものを送ってもらう確認文を作ります
4. 表計算の変換 … スプレッドシートに変換し、見出しの行と明細の範囲を読みます。複数のシートがあれば、シート名も渡します
5. 本文の整理 … 署名と引用を除きます。ただし「添付のとおり」「前回と同じ」などの一文は残します
6. 受信日時の添付 … 「明日」「来週月曜」を日付に直すため、受信日時を渡します
7. 再送の検知 … 同じ荷主から同じ件名・同じ添付名のメールが直近にあれば、訂正の再送か二重送信かを担当者に確かめるよう印を付けます

5番目で、短い一文を残すのが要です。 「前回と同じ届け先で」と書かれていると、届け先は本文にも添付にもありません。この一文を落とすと、届け先が空のまま取り込まれます。

AIに処理させる

させるのは、依頼に書かれた出荷先・品番・数量・単位・日付を、書かれたとおりに取り出し、取込の項目に対応づけることです。

「出どころ」を必ず書かせるのは、食い違いを拾うためです。 同じ項目が本文とPDFの両方から取り出され、値が違えば、それが食い違いです。どちらを採るかは決めず、両方を並べます。

1行目がいちばん起きやすい失敗です。 「AB-1O230」のようにOと0が混ざった品番を渡すと、マスタにありそうな番号に直して返すことがあります。直さずに返させ、マスタに無いという事実を照合で拾います。

指示内容を固定する

あなたは物流センターの業務課で、荷主からの出荷依頼を読み取る担当です。
渡されたメール本文と添付（PDF、または表計算の行）だけを見て、
書かれている内容をそのまま取り出してください。推測で埋めないでください。

【取り出す項目】
明細の1行ごとに、出荷先、品番、品名、数量、単位、出荷日、納品指定日、時間指定。
あわせて、書かれている合計（ケース数・個数）があれば取り出す。

【厳守事項】
- 品番は書かれた文字列をそのまま写してください。先頭の0、ハイフン、英字の
  大文字・小文字を変えないでください。似た番号に直さないでください。
- 数量の単位（ケース、c/s、箱、バラ、個、pcs など）を unit_raw に写してください。
  単位が書かれていなければ unit_raw を null にしてください。換算しないでください。
- 日付が「出荷日」か「納品日（着日）」かを、書かれた言葉（出荷、発送、着、納品、
  お届け）で区別してください。区別できなければ date_kind を unknown にしてください。
- 「明日」「来週月曜」は受信日時（{received_at}）から日付に直し、
  元の言葉を date_raw に残してください。
- 「前回と同じ」「いつもの届け先」とだけ書かれている場合は、出荷先を埋めず、
  refers_previous を true にしてください。
- 同じ項目が本文と添付の両方にある場合は、両方を別々に出してください。
  どちらが正しいかを決めないでください。
- すべての値に source（body／pdf:ページ番号／sheet:シート名:行番号）を付けてください。
- 出荷できるか、在庫があるかについては書かないでください。

【荷主の取込定義（参考）】{shipper_profile}
【前回の列の対応づけ（表計算の場合）】{previous_mapping}
【受信日時】{received_at}
【メール本文】{body}
【表計算の行（ある場合）】{sheet_rows}

「似た番号に直さない」は、書かないと必ず起きます。 生成AIは読みにくい文字を、文脈に合う文字に寄せて読みます。出荷依頼では、その親切がそのまま誤出荷になります。

取込定義は「参考」として渡します。 「この荷主の数量はケース」と渡しても、依頼に「バラで24個」と書かれていれば、書かれたほうを写させます。 定義と依頼の食い違いも、確認の対象です。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "message_id": "",
  "shipper_code": "",
  "lines": [
    { "line_no": 1,
      "ship_to": { "code": "", "name": "", "address": "", "phone": "", "refers_previous": false },
      "item_code": "", "item_name": "",
      "qty": 0, "unit_raw": "",
      "date": "2026-10-15", "date_kind": "ship | deliver | unknown", "date_raw": "",
      "time_window": "",
      "source": "body | pdf:1 | sheet:出荷依頼:5" }
  ],
  "stated_totals": [ { "value": 0, "unit_raw": "", "source": "" } ],
  "notes_from_shipper": ""
}

1つ目の理由は、照合をワークフローの規則で書けることです。 item_code で商品マスタを、ship_to.code で届け先マスタを引き、一致しなければ not_in_master を付けます。

2つ目は、取込待ちの表に書くときに型を守れることです。 品番と届け先コードは文字列のまま、Google Sheets の Add a Row の値の入れ方をRaw（入力した値をそのまま保存する設定）にして書きます。User entered にすると、「00123」が数字の123になります。

3つ目は、source で確認文が具体的になることです。 「本文では15日着、添付のPDF（1ページ目）では16日着となっています。どちらでお手配すればよろしいでしょうか」と、どこに何が書かれていたかを荷主に示せます。

確認文の下書きは、同じメールの要確認の点をまとめて次の形にします。

件名：【確認】10月14日受信の出荷依頼（○○商事様 宛て）について

○○株式会社 物流ご担当 ○○様

いつもお世話になっております。本日ご依頼の出荷について、3点確認させてください。

1. 納品日：本文では「15日着」、添付のPDF（1ページ目）では「16日着」となっています。
   どちらでお手配すればよろしいでしょうか。
2. 品番「AB-1O230」：商品マスタに登録がありません。
   「AB-10230」（○○ 12入）のことでしょうか。
3. 合計数量：本文の「50ケース」に対し、明細の合計は48ケースです。

本日出荷の締めは14時です。13時30分までにご返信いただければ本日出荷できます。

2番目で候補を挙げるのは、照合の側です。 生成AIに品番を直させない代わりに、マスタで1文字違いの品番を引いて問いの形で荷主に示します。決めるのは荷主です。

システムへ連携する

倉庫管理システムへは、この構成から書き込みません。 取り込みの前に人が見る1回を残すためで、誤った出荷予定が引き当てとピッキングの指示まで一息に進む経路を作りません。

確認文は、要確認の表の行に下書きとして置きます。 荷主ごとに、同じメールの要確認の点を1通にまとめます。1行ずつ別のメールにすると、荷主の担当者が返事をまとめきれません。

取込待ちの表の列は、倉庫管理システムの取込形式の並びに合わせます。 荷主コード、出荷予定日、届け先コード、届け先名、品番、数量（バラ換算）、時間指定、備考に、この構成が付ける列として、元のメールの識別子と source を最後に足します。 取り込むときはこの2列を外してCSVに書き出します。取り込んだ後でも、どのメールのどこから来た行かをたどれます。

人が確認する

人が見るのは、取込待ちの表の全件（流し見）と、要確認の表の全件です。

1. 要確認を先に見る … 締め時刻に近いものから。確認文を直して荷主に送ります
2. 取込待ちを流し見る … 荷主・件数・合計の数量を見て、いつもと大きく違う数量が無いかを見ます
3. CSVに書き出して取り込む … 取り込みの結果、倉庫管理システムでエラーになった行を要確認に戻します
4. 荷主の返事で表を直す … 直した行を取込待ちに移し、直した内容を記録します

2番目の「いつもと大きく違う数量」は、規則では拾いきれない誤りです。 毎週12ケースの品番に120ケースと書かれていても、マスタにも入数にも合っています。荷主の打ち間違いかもしれず、ここは人の目で見ます。 過去の平均と比べて大きく外れる行に印を付けると、見る場所が絞れます。

例外に対処する

7行目を自動にしないのは、「前回」がどれかが決まらないからです。 同じ荷主から1日に何通も依頼が来ると、どの依頼の届け先を指しているかは荷主に聞くしかありません。

記録を残す

• 受け取ったメールの識別子、受信日時、添付のファイル名
• 生成AIが返したJSONの全文と、照合の結果
• そのとき参照したマスタと取込定義の版
• 荷主に送った確認文と、返事の内容、直した行
• 倉庫管理システムに取り込んだ日時と、取り込んだ担当者
• 誤出荷が起きたときに、どの段階で誤ったか（荷主の誤記／取り出し／照合／取り込み）

最後の行が、この構成を育てる材料です。 誤出荷のたびに原因を4つのどれかに分けて残すと、直すべき場所が、荷主への依頼のしかたか、指示か、規則かが見えてきます。