運送会社から届く配送の遅延・事故・不在の連絡メールを種類で仕分け、荷主ごとに影響のある出荷をまとめて担当へ知らせる

処理の起点を決める

連絡を受ける入口は、共用の受信箱へのメールの着信です。 「共有メールボックスに新しいメールが届いたとき (V2)」の「元のメールボックス アドレス」に共用の受信箱を、差出人に運送会社4社の連絡用のアドレスをセミコロンで区切って入れます。 運送会社の担当者が個人のアドレスから送ってくることもあるので、差出人の一覧は運送会社の一覧のリストと合わせて保守します。

「添付ファイルを含める」は「いいえ」にします。 公式ドキュメントでは、添付を含める設定にすると添付のダウンロードを待ってタイムアウトが起きる可能性があるとされ、「添付ファイルの取得 (V2)」で別に取る回避策が示されています。事故の報告書は写真入りのPDFで大きくなりがちなので、最初からこの形にします。

まとめの投稿は、別のフローにします。 「繰り返し」トリガーで頻度を週にすると、実行する曜日と時刻を複数指定でき、タイム ゾーンも選べます。月曜から土曜の11時と16時に動かし、連絡の記録のリストから「まとめ待ち」の行を荷主ごとに集めて投稿します。11時は午前の配達の結果が、16時は午後の再配達の調整が間に合う時刻として置いています。

入力データを集める

質を決めるのは、運送会社の一覧に持たせる送り状番号の形です。 運送会社ごとに送り状番号の桁数と形は決まっています。AIが抜き出した番号がその形に合わなければ、読み違いか、運送会社の社内の番号を拾ったかのどちらかです。形の確認はフローの側で行います。

荷主の一覧に「急ぎで知らせる種類」を持たせるのは、荷主ごとに求めが違うからです。 ある荷主は事故だけをすぐ知りたく、別の荷主は不在の持ち戻りもすぐに知りたい。取り決めを一覧に持たせれば、フローを直さずに荷主ごとの急ぎ方を変えられます。

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

本文はトリガーの出力から、添付は「添付ファイルの取得 (V2)」で取ります。出荷実績は SharePoint の「アイテムを取得」で引きます。

「アイテムを取得」のフィルター クエリは、返すエントリを OData のフィルターで絞るものです。 送り状番号は運送会社とあわせて指定します。運送会社が違えば同じ番号が別の荷物を指すことがありうるからです。

地域単位の連絡では、出荷日の範囲を広めに取ります。 「本日お届け予定の九州宛て」とあれば、宅配便なら前日と前々日の出荷が該当します。範囲は運送会社と地域ごとに一覧に持たせ、絞り込みの条件そのものを連絡の記録に残します。

AIへ渡す前に整形する

1. 差出人の確認 … 運送会社の一覧にあるアドレスかを確かめ、運送会社のコードを決めます
2. 本文の整形 … 過去のやり取りの引用部分と署名を落とします。運送会社の署名に並ぶ営業所の住所を、届け先の地域として拾わせないためです
3. 添付の仕分け … PDF・PNG・JPG・JPEG はプロンプトへ渡し、それ以外の形式は窓口に回します
4. 大きさの確認 … 添付の合計が25MB未満、ドキュメントが50ページ未満かを確かめます
5. 同じ連絡の再送の確認 … 同じ運送会社から同じ件名のメールが短い間に二度届いたら、2通目は記録だけにして投稿しません
6. 続報の確認 … 件名に「続報」「第2報」とあれば、同じ件の前の記録を探して結び付けます

2番目を省くと、地域単位の連絡で絞り込みを誤ります。 署名に「福岡営業所」とあると、AIはそれを影響のある地域として拾うことがあります。影響の地域は本文の中だけから取らせます。

6番目は、台風の日に効きます。 運送会社は状況が変わるたびに続報を送ってきます。続報ごとに荷主の担当へ同じ一覧を流すと、どれが最新かが分からなくなります。 続報は前の記録を上書きし、変わった点だけを投稿します。

AIに処理させる

させるのは、連絡を7つの種類のどれかに仕分け、送り状番号・地域・日付・指示の要否を抜き出し、根拠の文を写すことだけです。

種類の判断に迷ったときは、other にさせます。 迷った連絡を delay に寄せると、事故だったものがまとめに回り、半日遅れて荷主に伝わります。 窓口に回る件数が少し増えても、急ぐ連絡を遅らせないほうを選びます。

instruction_needed を別の種類にしているのが、この仕分けの要です。 不在の連絡でも、保管期限が迫って指示を求めているものは急ぎます。1通の連絡が「不在」でもあり「指示を求めている」でもあるときは、instruction_needed を優先させ、期限の日付を抜き出させます。

2行目がいちばん大事です。 「九州宛て」と書かれた連絡から、AIに「影響のある出荷」を挙げさせると、それらしい出荷を挙げてしまいます。 AIが抜き出すのは地域と日付までで、影響する出荷は出荷実績の絞り込みで決めます。

指示内容を固定する

あなたは物流センターの出荷の窓口で、運送会社から届いた連絡を
仕分ける担当です。メール本文と添付だけを見て判断してください。
推測で埋めないでください。

【種類（category）】次のどれか1つを選んでください。
accident ........... 事故・破損・紛失・誤配
instruction_needed . 保管期限・返送か再配達か・住所の確認など、
                     こちらに指示を求めている
address_issue ...... 住所不明・受取拒否・転居
area_disruption .... 天候・災害・交通規制による地域単位の
                     集荷・配達の見合わせや遅れ
delay .............. 個別の荷物の遅れ
absent ............. 不在の持ち戻り・再配達の予定
other .............. 上のどれにも当たらない、または判断できない

【厳守事項】
- 迷ったときは other にしてください。delay に寄せないでください。
- 指示を求める文があれば、他の種類に当たっても instruction_needed に
  してください。指示の期限が書かれていれば deadline に写してください。
- 送り状番号は、本文と添付に書かれたものを書かれたまま全部写して
  ください。桁を補ったり、似た番号に直したりしないでください。
- 地域単位の連絡では、影響のある都道府県と、対象となる出荷日・
  お届け予定日を書かれたまま写してください。書かれていなければ
  空にしてください。署名の営業所の住所を地域として拾わないでください。
- 影響のある荷主や出荷を推定して書かないでください。
- 事故の責任や補償について判断を書かないでください。
- evidence には、種類の判断に使った文をそのまま写してください。
- 運送会社からの連絡でない、または配送の連絡でないメールなら、
  category を other にし、note に理由を書いてください。
- 回答に JSON マークダウンを含めないでください。

【運送会社】{carrier_name}
【受信日時】{received_at}
【件名】{subject}
【本文】{body}
【添付】{attachment}

「迷ったら other」を2回書いているのは、AIが多い種類に寄せる癖を持つからです。 運送会社からの連絡の大半は遅延と不在なので、少し変わった文面も遅延に見えます。 寄せる先を other に決めておけば、迷った連絡は窓口の人の目に入ります。

最後の1行は、公式ドキュメントの対処に沿ったものです。 プロンプトのテストで「JSON を生成できませんでした」が出るのは、モデルが JSON をマークダウンなどで囲むためで、この指示を足すことで解決できる場合があるとされています。

出力形式を固定する

次の形のJSONで受け取ります。 AI Builder の JSON 出力はキーの無い配列を形式として持てないとされているので、送り状番号もキーを持つオブジェクトの配列にします。

{
  "category": "accident | instruction_needed | address_issue | area_disruption | delay | absent | other",
  "tracking_numbers": [ { "no": "" } ],
  "areas": [ { "prefecture": "" } ],
  "ship_date_text": "",
  "delivery_date_text": "",
  "deadline": "",
  "carrier_next_action": "",
  "evidence": "",
  "note": ""
}

1つ目の理由は、category の値で投稿の急ぎ方を分けられることです。 フローは category と荷主の一覧の「急ぎで知らせる種類」を見比べ、その場で投稿するか、まとめに回すかを条件で決めます。

2つ目は、送り状番号と地域で、出荷実績の引き方を切り替えられることです。 tracking_numbers があれば1件ずつ引き、無くて areas があれば地域で絞り込みます。どちらも無ければ荷主を特定できないので、窓口に回します。

フローは引いた結果を荷主ごとにまとめ、次の形で投稿します。

地域単位の連絡は、件数と一覧へのリンクだけを投稿します。 Teams の投稿はメッセージの大きさが約28KBに制限され、超えると「要求エンティティが大きすぎます」のエラーで失敗するとされています。台風の日は1つの荷主で何十件にもなるので、一覧は連絡の記録のリストの絞り込みのビューへのリンクで渡します。

システムへ連携する

運送会社への返信は、この構成からは送りません。 指示を求める連絡への回答は、荷主の担当が荷主に確かめてから行います。自動で「承知しました」と返すと、運送会社は指示が来るものと待ってしまいます。

連絡の記録には、荷主の担当が対応の状況を書き込みます。 「荷主へ報告済み」「運送会社へ回答済み」の欄を持たせ、指示を求める連絡で期限の前日になっても回答済みにならないものは、まとめの投稿の先頭に再掲します。

人が確認する

荷主の担当は、投稿された連絡を見て、荷主への報告と運送会社への回答を行います。 窓口の担当は、AIとフローが処理しきれなかったものを受け持ちます。

1. 窓口：other の連絡を読む … 種類を決め直し、記録に書き足します
2. 窓口：出荷実績で見つからなかった送り状番号を確かめる … 読み違いか、取り込み前の当日の出荷かを見ます
3. 荷主の担当：その場の投稿を先に見る … 事故と指示を求める連絡は、期限と運送会社の次の動きを先に読みます
4. 荷主の担当：まとめの投稿を見て、荷主へ報告する … 地域単位の連絡は、一覧のリンクから荷主へ渡す一覧を作ります

1番目で決め直した種類は、記録に残します。 どの文面がどの種類に誤って仕分けられたかが、プロンプトに足す注意の材料になります。

目標は、480件をならして1件3分です。 窓口の処理と荷主の担当の確認を合わせた時間で、送り状番号を1件ずつ検索する時間は入っていません。

例外に対処する

上から2行は、運用の最初に多く出ます。 1行目は出荷実績の取り込みの時刻の問題で、取り込みを1日2回に増やすと減ります。 2行目は、運送会社の一覧の送り状番号の形が実際と合っていないことが多く、最初の1か月で形を直していきます。

記録を残す

• 元のメールのIDと受信日時、運送会社
• プロンプトが返したJSONの全文
• 引き当てに使った条件（送り状番号、または運送会社・出荷日の範囲・都道府県）と、引き当てた出荷
• 投稿した日時、投稿したチャネル、その場かまとめか
• 荷主への報告と、運送会社への回答の日時
• 窓口が決め直した種類と、その理由

5つ目は、荷主との約束を守れているかを測る記録です。 事故の連絡を受けてから荷主へ報告するまでの時間を、荷主ごとに月に1度数えます。

6つ目は、仕分けの見直しの材料です。 同じ運送会社の同じ型の文面が毎回 other に回るなら、その運送会社の書き方をプロンプトに例として足します。