荷主から届く入荷予定のメールと添付から入荷日・品番・数量・車両を読み取って入荷予定表に転記し、受入の能力を超える日を物流センターの担当者に示す

処理の起点を決める

共有メールボックスへの着信で、1通ずつ動かします。 Office 365 Outlook コネクタの「新しいメールが届いたとき（V3）」を使います。届いた時点で合計を出し直すことが能力の超過を早く知る理由そのものなので、1日1回のまとめ処理にはしません。

添付は、トリガーでは取らずに後から取ります。 コネクタの説明では、トリガーで添付を含める設定にすると、添付付きのメールが同時に多数届いたときに時間切れになることがあるとされ、含めずに「添付ファイルの取得（V2）」で取る方法が示されています。朝に荷主の予定がまとめて届くセンターでは、この設定が効きます。

同じメールで2回動くことがあります。 コネクタの説明では、Microsoft Defender の安全な添付ファイルの動的配信を使っていると、トリガーが2回動き、1回目は添付の配列が空のことがあるとされています。添付の数が0のときは、本文だけの予定として扱う前に、数分おいて同じ Message Id のメールを取り直します。

取りこぼしの対策として、毎日15時に突き合わせのフローを動かし、取り込みの記録に Message Id が無いメールを同じ処理に流し直します。

入力データを集める

質を決めるのは、荷主の対応表と品番マスタです。 荷主の対応表には、「納品予定日」「着日」「搬入日」のように荷主ごとに違う項目名を、1社ずつ人が書いておきます。 プロンプトに渡すのは、その荷主の言い換えの行だけです。

予定番号の書き方も荷主の対応表に持たせます。 発注番号、仕入先の出荷番号など、変更の連絡で元の予定を引く鍵が荷主ごとに違うからです。 予定番号を持たない荷主は、荷主・入荷日・品番の組を鍵にします。

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

添付の種類で渡し方を分けます。 PDF と画像はドキュメント入力に、CSV は文字に直してテキスト入力に渡します。表計算のファイルはコード インタープリターを有効にした別のプロンプトに渡し、1回に複数のファイルを分析できないとされているので、添付が2つあれば2回呼びます。

元の予定は、フィルター クエリで荷主コードと予定番号の2つで引きます。 SharePoint のコネクタの「複数の項目の取得」は、OData のフィルター クエリで返す行を絞れます。品番や数量をクエリの条件に入れません。 変更の連絡は品番や数量そのものを変えるもので、条件に入れると元の行が見つからなくなります。

日ごとの合計は、書き込んだ日だけ出し直します。 変更で日が動いた予定は、動く前の日と動いた後の日の両方を出し直します。 片方だけにすると、動く前の日に荷物が残ったままの合計になります。

AIへ渡す前に整形する

1. 送り主の確認 … 荷主の対応表に載ったアドレスかを確かめます。載っていなければ処理せず、担当者に回します
2. 重複の確認 … 同じ Message Id の取り込みの記録があれば処理しません
3. 添付の確認 … 署名の画像やロゴの画像を外し、PDF・画像・表計算のファイル・CSV だけを残します
4. 大きさの確認 … ファイルの合計が25MB未満、ドキュメントが50ページ未満かを見ます。超えるものはプロンプトに渡さず担当者に回します
5. パスワードの確認 … 開けない PDF や表計算のファイルは、担当者に回します
6. 引用の除去 … 「Re:」の返信で付いてくる過去のメールの引用を、本文から落とします
7. 受信日の付与 … 相対の日付を読むために、メールの受信日時をプロンプトに渡します

6番目を省くと、過去の予定を新しい予定として拾います。 変更の連絡には元の予定がまるごと引用されていることが多く、引用の部分の品番と数量を、もう一度新しい行として書き込みます。 引用の開始を示す行（「-----Original Message-----」など）から下を落とします。

7番目は、推測を見分けるためです。 相対の日付は書かれたとおりに返させ、日付への置き換えはフローで行い、置き換えた行は担当者の確認に回します。

AIに処理させる

させるのは、予定の行ごとに、書かれている項目を書かれたとおりに取り出すことと、その連絡が新規・変更・取消のどれかを示すことだけです。

右端の列が要です。 品番マスタや過去の予定から補った値は、担当者がその行を確かめる理由を消します。

1行目がいちばん起きやすい失敗です。 品名から箱の大きさを想像してパレットに直した数は、マスタと違えばそのまま日ごとの合計を狂わせます。

指示内容を固定する

あなたは物流センターの入荷の事務担当です。
荷主から届いたメールの本文と添付から、入荷予定を行ごとに取り出してください。
書かれていることだけを取り出し、推測で埋めないでください。

【取り出す項目】
- plan_no ... 予定番号。荷主の予定番号の書き方に合うものを写す
- arrival_date ... 入荷日。日付として書かれていれば YYYY-MM-DD
- arrival_date_text ... 入荷日の原文（「明日」「来週火曜」なども、そのまま）
- time_slot ... 時間帯の原文（午前、午後、10時着 など）
- item_code ... 品番。書かれた文字列をそのまま
- quantity ... 数量（数字のみ）
- unit ... 単位（ケース、パレット、ピース など。原文のまま）
- packing ... 荷姿の原文
- vehicle_type / vehicle_count ... 車種と台数
- change_type ... new（新規） / change（変更） / cancel（取消） / unknown
- evidence ... その行の根拠にした原文の一節

【厳守事項】
- 書かれていない項目は null にしてください。品名や他の行から補わないでください。
- 「明日」「来週火曜」のような相対の日付を、日付に直さないでください。
  arrival_date は null にし、原文を arrival_date_text に入れてください。
- 数量の単位を換算しないでください。ケースをパレットに直す計算をしないでください。
- 品番は1文字も直さないでください。ハイフンの有無や全角・半角もそのままです。
- 返信の引用部分（過去のメール）に書かれた予定は取り出さないでください。
- 変更の連絡では、変更後の値を返し、change_type を change にしてください。
  変更前の値は before_value に原文で入れてください。
- 取消の連絡では、取り消す予定番号と品番だけを返し、change_type を cancel にしてください。
- 新規か変更か判断できない場合は unknown にしてください。迷ったときに new を選ばないでください。
- 入荷予定ではない連絡（請求、在庫の照会、出荷の依頼など）なら、
  lines を空にし、document_type に連絡の種類を書いてください。
- 回答に JSON マークダウンを含めないでください。

【荷主】{shipper_name}
【この荷主の項目名の言い換え】{field_aliases}
【この荷主の予定番号の書き方】{plan_no_pattern}
【メールの受信日時】{received_at}
【メール本文（引用を除いたもの）】{body}
【添付】{attachment}

「迷ったときに new を選ばない」を明記しないと、ほとんどの連絡が新規になります。 変更の連絡の多くは「下記のとおりお願いします」としか書いていないからです。unknown を返させ、元の行の有無はフローで確かめます。

「回答に JSON マークダウンを含めない」は、JSON を生成できないエラーへの公式の FAQ の対処です。

表計算のファイル用のプロンプトには、「見出しの行を見て列の意味を決め、集計の行は読まない」を足します。

出力形式を固定する

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

{
  "document_type": "asn",
  "shipper_code": "",
  "message_change_type": "new | change | cancel | unknown",
  "lines": [
    {
      "line_no": 1,
      "plan_no": "",
      "arrival_date": "",
      "arrival_date_text": "",
      "time_slot": "",
      "item_code": "",
      "quantity": 0,
      "unit": "",
      "packing": "",
      "vehicle_type": "",
      "vehicle_count": 0,
      "change_type": "new | change | cancel | unknown",
      "before_value": "",
      "evidence": ""
    }
  ]
}

1つ目の理由は、AIの出力とフローの判断を別の層に置けることです。 lines はAIが埋め、追加・書き換え・取消のどれにするか、パレットにいくつ換算するか、能力を超えるかはフローが決めます。換算の数や能力の数が変わっても、直すのはリストの値だけです。

2つ目は、arrival_date と arrival_date_text を分けて持てることです。 日付で書かれた予定は前者で、相対の書き方は後者だけが埋まります。後者だけが埋まった行は、自動で「要確認」に回ります。

3つ目は、行ごとに evidence を持てることです。 引用の部分から拾っていないかを、元のメールを開く前に読めます。

フローは JSON を受け取ったあと、次の規則で行の状態を決めます。

システムへ連携する

入荷予定表の行は消しません。 取消の連絡が来ても、状態を「取消」にして残します。 消してしまうと、荷主から「取り消していない」と言われたときに経緯をたどれません。合計の計算からは、状態が取消の行を外します。

能力を超える日の通知は、超えた時点で、どの荷主のどの予定で超えたかを添えて投稿します。 能力の90％を超えた日は「注意」、100％を超えた日は「超過」と分けます。

倉庫管理システムへは書き込みません。 担当者が「確認済み」にした行だけを従来の手順で取り込みます。未確認の行が検品の予定に入ると、現場で予定違いが増えます。

人が確認する

人が開くのは、「要確認」の行と、能力を超える日の通知だけです。 「未確認」の行は、1日の終わりに入荷予定表を荷主ごとに並べて流し見て、まとめて「確認済み」にします。

1. 要確認（元の行なし）を先に見る … 変更や取消なのに元の予定が無いもの。元の予定のメールを取りこぼしている可能性があります
2. 要確認（日付）を見る … 相対の日付を、フローが受信日から置き換えた値で合っているかを確かめます
3. 要確認（品番）を見る … 品番の書き間違いか、新しい品番かを確かめます。新しい品番なら、品番マスタへの登録を荷主に確かめてから足します
4. 能力を超える日の手当てを決める … 課長が、荷主への日の変更の依頼か、人員の手配かを決めます
5. 直した内容を記録する … どの項目を、何から何に直したかを残します

1番目を最初に見るのは、能力の判断の前に合計の土台をそろえるためです。

目標は、600件をならして1件2分です。 要確認が2割を大きく超える月は、対応表の言い換えか品番マスタの登録が遅れています。

例外に対処する

下から2行目は月の変わり目に必ず起きるので、能力の表の翌月分は月の20日までに入れる決まりにします。

記録を残す

• 元のメール（Message Id、受信日時、送り主）と添付のファイル
• プロンプトが返した JSON の全文と、どちらのプロンプト（PDF・画像用、表計算のファイル用）を使ったか
• 入荷予定表への書き込みの記録（追加・書き換え・取消、書き換え前の値）
• 能力との比較の結果と、そのときの受入の能力の表の値
• 人が直した記録 … どの項目を、何から何に直したか
• 荷主ごとの要確認の発生率

4つ目で「そのときの能力の値」を残すのは、能力の表が後から変わるためです。 派遣を足して能力を上げると過去の超過の通知の意味が変わり、当時の値が残っていないと、なぜ超過と出たのかを説明できません。

最後の行は、荷主と書式を相談する材料になります。