ドライバーや作業者から届く荷物事故の報告をフォームとメールから受けて事故台帳に転記し、荷主への報告と再発防止の検討の材料にする

処理の起点を決める

入口はフォームとメールの2本のフローに分け、途中から先は同じ子フローを呼びます。 登録の処理を入口ごとに持つと、片方だけを直して項目がずれます。

フォームの側は、Microsoft Forms の「When a new response is submitted」のトリガーを使います。 このトリガーが返すのは回答のIDまでで、回答の中身は「Get response details」のアクションで、フォームのIDと回答のIDを渡して取ります。 コネクタは組織のアカウントでのみ動くとされ、グループで作ったフォームはドロップダウンに出ないため、フォームのIDを手で入れる必要があります。

メールの側は、Office 365 Outlook の「When a new email arrives (V3)」を使います。 監視するフォルダを事故受付のメールボックスに絞ります。「Include Attachments」を「はい」にすると、添付の多いメールが同時に届いたときに取り込みが時間切れになることがあるとされています。そこで「いいえ」にして、添付は後から「Get Attachment (V2)」で取ります。

トリガーには遅れと取りこぼしがあります。 ドキュメントでは、ほとんどの場合すぐに動くものの、まれに動くまで最大1時間かかることがある、多数のメールが同時に届くとまれに取りこぼすことがある、とされています。当日中が期限の荷主があるので、夕方に1回、受付のメールボックスの未処理を数える定時のフローを別に回します。

入力データを集める

質を決めるのは、3行目の荷主の一覧です。 荷主名は「〇〇さん」「△△の部品」「□□センター」のように書かれます。表記ゆれの列に現場の呼び方を足すほど、引き当てが当たります。

フォームの事故の区分は、選択式にします。 破損・汚損・紛失・誤配・数量違い・その他の6つです。自由記述にすると、同じ破損が「破れ」「つぶれ」「割れ」に分かれ、月末の集計が合いません。 メールの報告では区分を生成AIが選びますが、その値は確定のときに必ず人が見ます。

5行目の報告者の一覧は、聞き直しの宛先に使います。 協力会社のドライバーには、協力会社の配車担当のアドレスに返すことがあります。

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

SharePoint の「Get items」は、OData のフィルターで行を絞り、取得の件数を指定できます。 指定しないと既定ではすべての行が対象になるため、重複の確認では伝票番号と発生日の条件と、件数の上限を必ず付けます。 台帳の行は年に約1,800行ずつ増えます。

写真は台帳の行に添付します。 SharePoint のコネクタは、リストの項目の添付で90MBまでのサイズに対応するとされています。スマートフォンの写真を何枚も付けたメールは、このサイズに近づくことがあるので、添付ごとに分けて付けます。

AIへ渡す前に整形する

1. フォームの回答を1つの文にまとめる … 項目ごとの回答を「項目名：値」の形で並べた文にして、メールの本文と同じ入口からプロンプトに渡します
2. メールの署名と引用を外す … 協力会社のメールは署名が長く、前のやり取りの引用が残っています。本文の先頭から、最初の署名の区切りまでを使います
3. 聞き直しへの返信かを見分ける … 件名に聞き直しのメールの受付番号が入っていれば、新しい事故ではなく既存の行への追記として扱います
4. 報告者の照合 … 送信者のアドレスを報告者の一覧と照らし、所属を付けます。一覧に無いアドレスは、台帳に登録せず担当へ回します
5. 暗号化されたメールの扱い … Outlook のコネクタは暗号化されたメールに対応していないとされています。届いたら受付のフォルダに残し、担当に知らせます
6. 添付の数とサイズの確認 … 写真が多いものは分けて添付します。写真が無ければ、その旨を台帳の行に書きます

3番目が無いと、「伝票番号は1234-4521です」という返信だけのメールが、新しい事故の行になります。

AIに処理させる

させるのは、報告の文から台帳の項目を取り出すことと、足りない項目を一覧にすることです。 第一報の下書きは、確定した項目から別のプロンプトで作ります。

「さっき」を受信日時にしないのは、報告が事故の何時間も後に送られることがあるからです。 第一報の時刻が事実と合わなくなります。

指示内容を固定する

項目の取り出し（Run a prompt に登録するプロンプト）：

あなたは運送会社の品質管理の担当として、荷物事故の報告を台帳の項目に整理します。
入力の「報告」に書かれていることだけを使ってください。推測で埋めないでください。

【取り出す項目】
occurred_date, occurred_time, place_type（届け先／倉庫／車内／路上／その他）,
place_name, slip_no, slip_no_is_partial（末尾など一部だけのとき true）,
shipper_candidate, accident_type（破損／汚損／紛失／誤配／数量違い／その他）,
item_name, damaged_qty, total_qty, situation, photos_mentioned

【厳守事項】
- 記載がなければ「不明」とせず、空欄（空の文字列）にしてください。
  他の項目から補って埋めないでください。
- 伝票番号は書かれた文字列をそのまま入れてください。桁を補ったり、
  記号を直したりしないでください。「末尾4521」なら slip_no に 4521、
  slip_no_is_partial に true を入れてください。
- 荷主は【荷主の一覧】の名前と表記ゆれに当たるときだけ shipper_candidate に入れてください。
  品名や届け先から荷主を推測しないでください。
- 「本日」は受信日の日付を occurred_date に入れ、occurred_time は空欄にしてください。
  「さっき」「先ほど」から時刻を作らないでください。
- 個数が「何個か」「数ケース」のように数で書かれていなければ空欄にしてください。
- situation には、報告に書かれた事実だけを3文以内で書いてください。
  原因の推測、責任の所在、損害の金額を書かないでください。
- accident_type を1つに決められないときは「その他」とし、
  type_note に迷った理由を書いてください。
- 空欄にした項目のうち、台帳に必須の項目（occurred_date, place_name, slip_no,
  shipper_candidate, accident_type, damaged_qty）を missing に並べてください。
- 聞き直しへの返信のように、新しい事故の報告でないと判断したときは
  is_new_report を false にしてください。
- Don't include JSON markdown in your answer.

【受信日時】{received_at}
【荷主の一覧】{shipper_aliases}
【報告】{report_text}

最後の英語の1文は、JSON の出力のための決まった一文です。 ドキュメントでは、テスト時に「A JSON could not be generated」の誤りが出る場合、モデルが JSON を囲む書式を付けていることが原因のことがあり、この一文を足すと解消することがあるとされています。

「品名や届け先から荷主を推測しない」を明記しないと、「△△の部品」から△△を荷主として返します。 外れれば、別の荷主に事故を報告することになります。

第一報の下書き（2つ目のプロンプト）： 確定した行を渡し、発生日時・場所・伝票番号・品名・個数・区分・状況・未確認のこと・次の連絡の予定の順で、事実だけを書くよう指示します。責任や原因には触れさせません。

出力形式を固定する

項目の取り出しのプロンプトは、出力を JSON にし、形式を「Custom」に固定します。 既定の「Auto detected」は、プロンプトをテストするたびに形式が検出し直されます。JSON の例を編集すると「Custom」になり、テストしても更新されなくなるとされています。保存のときに形式が固定され、フローで使うときはその形式で返ります。

{
  "is_new_report": true,
  "occurred_date": "2026-10-05",
  "occurred_time": "",
  "place_type": "届け先",
  "place_name": "△△物流センター",
  "slip_no": "4521",
  "slip_no_is_partial": true,
  "shipper_candidate": "",
  "accident_type": "破損",
  "type_note": "",
  "item_name": "",
  "damaged_qty": "1",
  "total_qty": "2",
  "situation": "2ケースのうち1ケースの外装が破損。中身は未確認。",
  "photos_mentioned": "true",
  "missing": [
    { "field": "slip_no" },
    { "field": "shipper_candidate" }
  ]
}

missing を {"field": ...} の形の配列にしているのは、制限のためです。 ドキュメントでは、項目名の無い配列（["abc", "def"] のような形）は形式として定義できず、[{"Field1": "abc"}] の形なら使えるとされています。JSON のスキーマ自体は編集できないため、形は JSON の例で決めます。

1つ目の理由は、台帳の列に1対1で入れられることです。 リストの列と JSON の項目を同じ名前にすれば、「Create item」にそのまま割り当てられます。

2つ目は、missing から聞き直しのメールを機械的に作れることです。 項目名を質問文に置き換える表をフローに持ち、生成AIを通さずに文面を作ります。

3つ目は、slip_no_is_partial で伝票番号の扱いを分けられることです。 末尾だけの番号は重複の確認に使わず、確定のときに担当者が運送の管理システムで全桁を引きます。

システムへ連携する

台帳の状態の列で、下書きと確定を分けます。 フローが作る行は必ず「下書き」で、月末の集計は「確定」の行だけを数えます。 下書きのまま残っている行は、確定の漏れとして毎朝の一覧に出します。

第一報の確認には、承認のアクションを使います。 Microsoft のドキュメントでは、プロンプトの出力の後に「Start and wait for an approval of text」を置き、提案の文面を承認者が確かめて編集できる手順が示されています。この構成では、承認された文面だけを荷主への送信の下書きにし、送信のボタンは担当者が押します。

人が確認する

台帳の行の確定と、荷主への第一報は、品質管理の担当が必ず行います。

1. 伝票番号を引き当てる … 運送の管理システムで伝票を引き、荷主・届け先・品名が報告と合うかを確かめます。末尾だけの番号は、ここで全桁にします
2. 事故の区分と個数を確かめる … 写真と状況を見て、区分を直します。「その他」になったものは、type_note を読んで決めます
3. 重複の候補を見る … 同じ伝票・同じ日の行があれば、1つにまとめます
4. 状態を「確定」にする … 確定した行だけが集計と第一報の対象になります
5. 第一報を直して送る … 承認の画面で下書きを直し、荷主の様式に合わせて送ります

1番目を省かないでください。 生成AIは伝票番号を書かれたとおりに取り出しますが、ドライバーが書き間違えた番号は、そのまま取り出されます。 伝票と報告の内容が合うかを見るのは人の役目です。

目標は、1件をならして6分です。 項目がそろった報告は1〜2分で確定でき、聞き直しや重複のあるものに時間を使います。

例外に対処する

1行目は第一報の期限のためです。 当日中が期限の荷主のものは、聞き直しのメールと同時に担当へ知らせます。最後の行の取りこぼしはまれとされていますが、1件が荷主への報告漏れになるので、まれでも数えます。

記録を残す

• 元のフォームの回答とメール（本文・添付）と、受け取った日時
• プロンプトに渡した文と、返ってきた JSON の全文
• 台帳の行の下書きの値と、担当者が確定のときに直した項目と直す前の値
• 聞き直しのメールの送信日時と、返信の受信日時
• 第一報の下書き、承認で直した後の文面、荷主へ送った日時
• フローの実行の履歴（成功・失敗）

3つ目の「直した項目」は、プロンプトと荷主の一覧の表記ゆれを直す材料になります。

5つ目の送った日時は、荷主の期限に間に合ったかを数える材料です。 月末の会議で、期限を過ぎた第一報の件数と理由を見ます。