顧客から工場に届く生産計画の変更連絡メールから、品番・数量・日付の変更点を抜き出し、資材・製造・出荷の担当に関係する変更だけを通知する

処理の起点を決める

共用の受信箱にメールが届いたことを起点にします。 Office 365 Outlook コネクタの「新しいメールが届いたとき (V3)」を使い、差出人のフィルターに顧客の担当者のアドレスをセミコロンで区切って並べます。 社内からのメールや、顧客からの請求や品質の連絡まで拾わないためです。

差出人だけでは絞りきれない顧客には、件名のフィルターを足します。 「計画変更」「内示変更」のような件名を決めて送ってくる顧客なら、件名でさらに絞れます。件名が決まっていない顧客は差出人だけで受け、変更連絡でないメールはプロンプトの側で見分けて止めます。

「添付ファイルを含める」は「いいえ」にします。 公式ドキュメントでは、これを「はい」にするとコネクタがすべての添付のダウンロードを待ち、タイムアウトが起きる可能性があるとされ、「いいえ」にして「添付ファイルの取得 (V2)」で別に取る回避策が示されています。計画表のPDFは大きくなりがちなので、最初から回避策の形で組みます。

受信箱の振り分けのルールでメールを別のフォルダーへ移す運用とは、組み合わせ方に気をつけます。 このトリガーは受信した日時で動き、フォルダーを移しても受信の日時は変わらないため、最後に正常に動いた時刻より前に受信したメールは飛ばされるとされています。人が後から手で移したメールは拾われません。

入力データを集める

質を決めるのは、品番の対応表です。 顧客のメールに書かれるのは顧客の品番で、自社の台帳は自社の品番で持っています。対応表がなければ、AIが正しく抜き出しても台帳の行にたどり着けません。 対応表は、今は担当者の頭の中か、各自の手元の一覧にあることが多いので、これを1つのリストにまとめるのが最初の準備作業です。

変更の締め切りを顧客の一覧に持たせるのは、急ぎの印を付けるためです。 納入日まで締め切りより近い変更は、契約の取り決めの外で受ける変更になります。受けるかどうかは人が決めますが、急ぎとして一覧の上に出します。

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

本文はトリガーの出力から、添付は「添付ファイルの取得 (V2)」で取ります。このアクションは、メッセージのIDと添付のIDから添付の名前、種類、大きさ、中身を返します。

台帳は「アイテムを取得」のフィルター クエリで引きます。 このパラメーターは返すエントリを OData のフィルターで絞るもので、自社の品番と納入日を条件にすれば、該当の1行だけが返ります。 該当が0行なら「追加」の候補、2行以上なら台帳の側の重複として人に回します。

添付のインライン画像は除きます。 添付の情報には、本文に埋め込まれた画像かどうかの印が付きます。署名のロゴまでプロンプトに渡すと、処理の時間と量が増えるだけです。

AIへ渡す前に整形する

1. 差出人の確認 … 顧客の一覧にあるアドレスかを確かめ、顧客のコードを決めます
2. 本文の整形 … 過去のやり取りの引用部分と署名を落とし、いちばん新しい本文だけを渡します。引用部分に残った前回の変更を、もう一度抜き出させないためです
3. 添付の仕分け … PDF・PNG・JPG・JPEG はプロンプトへ。それ以外の形式は、プロンプトに渡さずに人へ回します
4. 大きさの確認 … 添付の合計が25MB未満、ドキュメントが50ページ未満かを確かめ、超えるものは人へ回します
5. 重複の確認 … 同じ顧客から同じ件名・同じ添付の名前のメールが短い間に二度届いたら、2通目を止めて人に知らせます
6. 前回の連絡の確認 … 同じ顧客の同じ品番について、承認待ちの変更が残っていれば印を付けます。承認待ちのまま次の変更が来ると、変更前の値がずれるからです

3番目で表計算の形式の添付を人に回すのは、プロンプトのドキュメントの入力が通常 PNG・JPG・JPEG・PDF に限られるためです。 公式ドキュメントでは、Word や表計算などのファイルはプロンプトの設定でコード インタープリターを有効にした場合に扱えるとされていますが、この構成の最初の段階では有効にせず、表計算の形式で送ってくる顧客には、PDFで送ってもらえるかを相談します。

6番目は軽く見ないでください。 午前に届いた変更がまだ承認されていないうちに、午後に同じ品番の再変更が届くことがあります。午後の変更を、台帳に残っている午前より前の値と比べると、変更の向きを誤ります。

AIに処理させる

させるのは、メールと添付から変更の行を抜き出し、行ごとに根拠の文を写すことだけです。 変更の種類も、送り先も、受けるかどうかも決めさせません。

顧客が書いた「変更前」も抜き出させるのは、台帳との食い違いを見つけるためです。 顧客が「120個から150個へ」と書いていて、台帳が100個なら、どこかで前回の変更が反映されていないか、顧客の側の勘違いです。 どちらにしても人が確かめるべきことなので、両方の値を並べて承認の一覧に出します。

4行目がいちばん起きやすい失敗です。 「10/20」とだけ書かれた日付に年を補うのは簡単に見えますが、年末に届く翌年1月の変更で年を誤ります。 年が書かれていない日付は、書かれたまま返させ、フローの側で受信日から決め、決めた年を承認の一覧に表示します。

指示内容を固定する

あなたは部品メーカーの生産管理課で、顧客から届いた生産計画の
変更連絡を読む担当です。メール本文と添付だけを見て、変更の行を
抜き出してください。推測で埋めないでください。

【抜き出す項目】
customer_part_no ... 顧客が書いた品番。書かれたまま写す
before_date ........ 顧客が変更前として書いた納入日
after_date ......... 変更後の納入日
before_qty ......... 顧客が変更前として書いた数量
after_qty .......... 変更後の数量。取消と書かれていれば 0
destination ........ 変更後の納入先。変更がなければ空
evidence ........... 根拠にした本文の文、または添付のページと行

【厳守事項】
- 1つの品番の1つの納入日を1行にしてください。
- 書かれていない項目は空にしてください。他の行から補わないでください。
- 品番は書かれた文字列をそのまま写してください。似た品番に直したり、
  ハイフンや桁を補ったりしないでください。
- 日付に年が書かれていなければ、年を補わず、書かれたまま
  （例：10/20）写してください。
- 「来週」「月末」のような書き方は、日付に直さず、そのまま写して
  needs_check を true にしてください。
- 数量を計算しないでください。「30個増」と書かれていれば
  after_qty は空にし、evidence に「30個増」と写してください。
- 変更後の表だけが添付されていて変更箇所の印が読み取れない場合は、
  表の全部の行を抜き出し、changed_mark を unknown にしてください。
- 本文の引用部分（前回のやり取り）は読まないでください。
- 変更を受けるべきか、どの部署に関係するかは書かないでください。
- 計画の変更連絡でないメールなら、changes を空にし、
  mail_type に種類を書いてください。
- 回答に JSON マークダウンを含めないでください。

【顧客】{customer_name}
【受信日時】{received_at}
【本文】{body}
【添付】{attachment}

「数量を計算しない」を明記しないと、増減で書かれた変更を勝手に足し算します。 「30個増」と書かれていると、AIは何かの数から30を足した数を after_qty に入れます。足す元の数が台帳の値と違えば、誤った変更後の数量が承認の一覧に並びます。 増減で書かれた変更は、フローの側で台帳の値に足します。

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

出力形式を固定する

次の形のJSONで受け取ります。 AI Builder の JSON 出力は、キーの無い配列（例：["abc", "def"]）を形式として持てないとされているので、変更の行はキーを持つオブジェクトの配列にします。

{
  "mail_type": "plan_change",
  "customer_code": "",
  "changes": [
    {
      "customer_part_no": "",
      "before_date": "",
      "after_date": "",
      "before_qty": "",
      "after_qty": "",
      "delta_text": "",
      "destination": "",
      "changed_mark": "marked | unknown",
      "evidence": "",
      "needs_check": false
    }
  ]
}

1つ目の理由は、1件のメールの中の複数の変更を、行ごとに扱えることです。 フローは changes を1行ずつ回し、行ごとに台帳を引き、行ごとに送り先を決めます。1件のメールを1つの文章で受けると、どの部署にどの行を送るかを分けられません。

2つ目は、顧客が書いた値と台帳の値を並べられることです。 フローは行ごとに台帳の値を足し、承認の一覧を次の形にします。

2行目のように、台帳と顧客の変更前が食い違う行には印を付けて上に出します。 承認する担当者が真っ先に見るべき行です。

変更の種類と送り先は、次の規則でフローが決めます。

部署ごとの行は、データ操作の「配列のフィルター処理」で分けます。 このアクションは配列の中身を条件に合うものだけに絞るもので、送り先に「資材」を含む行だけ、のように3回絞って、それぞれのチャネルへ投稿します。 公式ドキュメントでは、フィルターの対象のテキストは大文字と小文字が区別されるとされているので、品番の英字は前処理で大文字にそろえておきます。

システムへ連携する

台帳への書き込みは、承認の後だけにします。 承認の前に書き換えると、承認で差し戻した変更が台帳に残ります。変更の記録のリストには、承認の前から全部を書き、承認の結果をその行に足します。

Teams の投稿には、表と元のメールへのリンクを付けます。 投稿の表はデータ操作の「HTML テーブルの作成」で作れます。資材の担当は、元のメールまで見に行かずに手配の変更を始められます。

人が確認する

生産管理課の担当が、1件ごとに承認します。 見るのは、承認の一覧と元のメールの2つだけです。

1. 印の付いた行を先に見る … 台帳と顧客の変更前が食い違う行、needs_check の行、changed_mark が unknown の行
2. 元のメールと見比べる … 品番・日付・数量が、根拠の文と合っているかを確かめます
3. 急ぎの行を確かめる … 締め切りの内の変更は、受けるかどうかを製造と相談してから承認します
4. 承認するか、直すか、差し戻すか … 直した場合は直した値と理由を残します

1番目の食い違いの行は、承認で済ませないでください。 台帳が古いのか、顧客が勘違いしているのかで、直す先が自社の台帳か、顧客への問い合わせかに分かれます。

目標は、180件をならして1件7分です。 一覧を見て元のメールと見比べる時間が中心で、台帳を探す時間と部署への連絡を書く時間は入っていません。

例外に対処する

上から4行目が、運用の最初の数か月でいちばん多く出ます。 対応表が埋まっていない品番は、承認のときに担当者が対応表に足していけば、月を追うごとに減っていきます。

記録を残す

• 元のメールのIDと受信日時、添付の名前
• プロンプトが返したJSONの全文
• 引き当てた自社の品番と、そのときの台帳の値（変更前として使った値）
• 決めた変更の種類と送り先
• 承認の結果と、人が直した値と理由
• Teams に投稿した日時と、投稿したチャネル

3つ目の「そのときの台帳の値」を残すのは、後から台帳が変わるからです。 出荷の遅れが起きたときに、どの時点の台帳と比べて何を送ったかが分からないと、漏れがどこで起きたかを確かめられません。

5つ目の直した記録は、プロンプトの見直しの材料になります。 同じ顧客で同じ項目の直しが続くなら、その顧客の書き方に合わせた注意をプロンプトに足します。