建材商社・メーカーから届く資材の納品予定・欠品・遅れの連絡メールを読み取り、現場ごとの資材手配表を更新して、使う日に間に合わない資材を現場監督に知らせる

処理の起点を決める

資材課の共有メールボックスへの着信を起点にします。 トリガーは「When a new email arrives in a shared mailbox (V2)」で、フォルダは受信トレイ、添付ありに絞らない設定にします。 本文だけで納品日を知らせてくる商社が多いからです。

1日1回のまとめ処理にはしません。 朝に届いた「明日の納品が遅れる」という連絡を夕方に処理すると、第3章の（b）がそのまま残ります。届いたその時に動かし、遅れを監督に届けるまでを数分で終えます。

取りこぼしへの備えを、最初から入れます。 コネクタの既知の問題のとおり、同時に多く届くとトリガーがまれにメールを拾い損ねます。毎朝7時に動く2本目のフローで、受信トレイに残っている前日以前のメールを数え、処理の記録に無いものを拾い直します。 処理が終わったメールは「処理済み」フォルダへ移すので、受信トレイに残っている数が、そのまま未処理の数になります。

トリガーは受け取った日時で動きます。 フォルダを移しても受け取った日時は変わらないため、一度移したメールを受信トレイへ戻しても、トリガーは拾い直さないことがあります。 やり直したいメールは、確認待ちの一覧から2本目のフローを手で動かして処理します。

入力データを集める

質を決めるのは、手配表の注文番号と、現場の一覧の略称です。 注文番号がそろっていれば、行の特定はほとんど機械的に終わります。略称の一覧が無いと、「〇〇2期」と「〇〇ビル新築工事（第2期）」が同じ現場だと分かりません。

取引先の一覧には、商社が自社の注文番号を書いてくるかどうかの列を持たせます。 書いてこない商社の連絡は、最初から品名と数量で当たりを付けることになり、取り違えが起きやすい相手として扱いを変えます（第7章の「人間の確認」）。

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

添付はトリガーで含めず、あとから取り出します。 コネクタの既知の問題には、添付付きのメールが同時に多く届くと、添付のダウンロード中に時間切れになることがあると書かれ、Include Attachments を「いいえ」にして Get Attachment (V2) で取る方法が示されています。添付の名前や種類などの情報は、この設定にかかわらず返ります。

手配表は、注文番号で絞って1行だけ取ります。 Get items にはフィルター クエリ（OData）と取り出す件数の指定があり、指定しなければ全件を取りに行きます。 30現場分の手配表は数千行になるので、絞らずに取ると遅くなります。

AIへ渡す前に整形する

1. 送信者の確認 … 送信者のドメインが取引先の一覧に無いメールは、読み取らずに確認待ちへ回します。営業の案内や請求書が混ざるのを入口で止めます
2. 件名での振り分け … 件名に「請求」「見積」「ご案内（新商品）」を含むものは対象外として処理済みへ移します。迷うものは対象に残します
3. 本文の整理 … 返信の引用部分（「-----Original Message-----」以下や「>」で始まる行）と署名を落とします。過去の連絡の日付を、今回の日付として読ませないためです
4. 添付の選別 … PDFと画像だけを渡し、合計が25MB未満、50ページ未満であることを確かめます。超えるものは確認待ちへ回します
5. パスワード付きPDFの確認 … 開けないものは確認待ちへ回し、商社に解除して送り直してもらいます
6. 重複の検知 … 同じ送信者から同じ件名・同じ添付名のメールが24時間以内にあれば、二重の処理にしないよう印を付けます

3番目を省かないでください。 商社の返信は前回のやり取りを引用したまま来ることが多く、引用の中には前回の納品予定日が書かれています。 落とさずに渡すと、古い日付と新しい日付が1通に並びます。

AIに処理させる

させるのは、メールと添付から注文ごとの値を写し、連絡の種類を決められた選択肢から1つ選ぶことだけです。

右端の列がこの構成の要です。 「来週中」を来週の金曜日に、「月末」を末日に置き換えると、手配表には確定した日付のように見える値が入ります。 使用予定日との比較もその日付で行われ、監督は確定していない日付で段取りを組みます。あいまいな日付は日付にせず、原文のまま確認待ちへ回します。

2行目がいちばん起きやすい失敗です。 注文番号の無いメールを渡すと、本文の品名から「おそらくこの注文」と番号を埋めてきます。埋めた番号で行を引けてしまうと、ワークフローの側からは正しく引けたものと見分けがつきません。

指示内容を固定する

あなたは建設会社の資材課で、建材商社・メーカーから届いた
納品に関する連絡を読み、注文ごとの値を写す担当です。
メールの本文と添付の納品予定表だけを見て、書かれている値を写してください。

【写す項目（注文ごとに1件）】
- order_no ........ 当社の注文番号（例：PO-2026-01234）。書かれたとおりに写す
- supplier_ref .... 商社・メーカー側の受注番号
- site_name ....... 現場名。略称のまま写し、正式名に直さない
- item_name ....... 品名
- spec ............ 規格・品番・色・寸法
- quantity ........ 数値のみ
- unit ............ 枚、本、m、ケースなど
- delivery_date ... 納品予定日を YYYY-MM-DD で
- delivery_date_text ... 日付が「来週中」「月末」などのときは原文をここに
- notice_type ..... confirmed（確定）／changed（変更）／delayed（遅れ）／
                    out_of_stock（欠品）／partial（分納）／cancelled（取消）／other
- partial_rest .... 分納の残りの数量と、その納品予定日（書かれていれば）
- substitute ...... 代わりの品の提案があれば、その品名と規格
- evidence ........ この注文の値を写した元の文をそのまま

【厳守事項】
- 書かれていない値は空欄にしてください。推測で埋めないでください。
- order_no は、当社の注文番号として書かれているものだけを写してください。
  品名や数量から、どの注文かを推測して番号を埋めないでください。
- 「来週中」「月末」「〇日以降」などは delivery_date に日付を入れず、
  delivery_date_text に原文を写してください。曜日から日付を計算しないでください。
- 引用された過去のメールに書かれた日付は写さないでください。
- 1通に複数の注文があるときは、注文ごとに分けてください。
  同じ品名でも現場や注文番号が違えば別の件です。
- 遅れているか、間に合うかは判断しないでください。
  文面が丁寧であることを、遅れの根拠にしないでください。
- 納品に関する連絡ではないと判断した場合は、orders を空にして
  mail_type に種類（請求、見積、案内など）を書いてください。

回答に JSON マークダウンを含めないでください。

「文面が丁寧であることを、遅れの根拠にしない」を書いているのは、商社のメールが「ご迷惑をおかけします」から始まることが多いからです。 通常の納品日の確定でもこの書き出しを使う商社があり、何も言わなければ delayed を選びます。連絡の種類は、日付が前の連絡から動いたかどうかで決まるもので、言い回しでは決まりません。

最後の1行は、Microsoft の公式の FAQ にある対策です。 JSON の前後に説明やマークダウンの印が付くと形の検証に通らないことがあり、「回答に JSON マークダウンを含めないでください」を指示に足すことが示されています。 なお、プロンプトの入力に指示を含めることはセキュリティ上の理由で禁止されているため、指示はすべてプロンプトの本体に書き、メール本文は入力として渡すだけにします。

出力形式を固定する

プロンプトの出力を JSON にして、形をカスタムで固定します。 既定の「自動検出」はテストのたびに形が変わるため、例を書いて「カスタム」として保存します。 保存した形が、フローから呼ぶときにも使われます。

{
  "mail_type": "delivery_notice",
  "orders": [
    {
      "order_no": "PO-2026-01234",
      "supplier_ref": "",
      "site_name": "",
      "item_name": "",
      "spec": "",
      "quantity": 0,
      "unit": "",
      "delivery_date": "",
      "delivery_date_text": "",
      "notice_type": "confirmed | changed | delayed | out_of_stock | partial | cancelled | other",
      "partial_rest": [{ "quantity": 0, "delivery_date": "" }],
      "substitute": "",
      "evidence": ""
    }
  ]
}

orders は注文ごとの配列です。 フローの側では「それぞれに適用する」で1件ずつ回し、注文番号で手配表を引きます。キーの無い配列は JSON 出力でサポートされないとされているので、partial_rest も quantity と delivery_date のキーを持つ形にしています。

1つ目の理由は、ワークフローが規則で行き先を決められることです。

2つ目は、evidence で確認が速くなることです。 確認待ちの一覧に、写した元の文が並びます。メールを開き直さずに、何を根拠にした値かを読めます。

3つ目は、分納を1行に押し込まずに済むことです。 partial_rest に残りの数量と日付が入り、手配表に足した「残りの数量の納品予定日」の列に書きます。第3章の（d）の「残りが消える」がここで止まります。

システムへ連携する

手配表で書き換えるのは、納品予定日・数量・状態と、足した3つの列だけです。 使用予定日、注文番号、現場は書き換えません。使用予定日は監督が決める日付で、資材の連絡で動かしてよいものではありません。

Teams への投稿は短くします。 投稿できるメッセージの大きさは約28KBが上限で、超えると「Request Entity too large」で失敗するとされています。現場・品名・数量・元の納品予定日・新しい納品予定日・使用予定日・商社名の7つだけを載せ、元のメールは確認待ちの一覧へのリンクで渡します。 プライベート チャネルへの投稿は現在サポートされていないとされているので、現場のチャネルは標準チャネルで作ります。

人が確認する

資材担当が見るのは、確認待ちの一覧だけです。 自動で書き換わったものは、1日の終わりに件数と現場を流し見ます。

1. 引けなかったものを先に見る … order_no が空、または手配表に無いもの。evidence を読み、手配表で該当する行を探して、注文番号を手で入れてからフローに戻します
2. あいまいな日付を確かめる … 「来週中」などは、商社に電話して日付を決めてもらいます。決まるまで手配表の納品予定日は前の値のままです
3. 欠品と代わりの品 … 代わりの品の提案は、監督に判断を仰ぎます。受けるかどうかは監督が決め、資材担当が商社へ返事をします
4. 分納と取消 … 残りの数量と日付が手配表に入ったかを確かめます。取消は再手配の要否を監督と決めます

注文番号を書いてこない商社の連絡は、行が引けても確認待ちに載せます。 取引先の一覧の「自社の注文番号を書いてくるか」の列で切り替えます。品名と数量で引いた行は、合っていそうに見えて違うことがあるからです。 商社に注文番号の記載をお願いし、書いてくるようになったら列を切り替えます。

現場監督は、Teams の投稿を見て対応を決めます。 待つのか、別の商社から取るのか、工程を入れ替えるのか。この判断はAIにもワークフローにもさせません。 決めた結果は、監督が手配表の備考の列に書きます。

例外に対処する

上から2行目までは、メールの受け方の問題です。 どちらも「受信トレイに残っている＝未処理」の決まりで拾えます。処理済みへ移すのは、すべての注文の書き換えと記録が終わったときだけにします。

下から2行目は、人の判断を上書きしないための規則です。 監督が商社と電話で話して納品日を直したあとに、古い連絡のメールが遅れて届くことがあります。人が後から直した行は、自動では書き換えません。

記録を残す

• 元のメールの識別子と、受け取った日時・送信者
• プロンプトに渡した本文（引用と署名を落とした後）と、返ってきた JSON の全文
• 手配表のどの行の、どの列を、何から何へ書き換えたか
• 確認待ちに回した理由と、資材担当がどう処理したか
• Teams へ投稿した内容と、投稿の成否
• 商社ごとの、注文番号の記載率と、確認待ちに回った割合

3つ目の「何から何へ」を残すのは、書き換えを戻せるようにするためです。 取り違えに気づいたとき、どの行をいつ書き換えたかが分からないと、手配表の正しい値をメールの山から探し直すことになります。

最後の行は、商社との話し合いの材料になります。 注文番号の記載率が低い商社には、記載をお願いします。記載率が上がるほど、確認待ちは減ります。 判定の精度を上げようとするより、こちらのほうが確実に効きます。