仕入先からの納期回答メールを読み取って発注残の納期を更新する

処理の起点を決める

購買の共有メールボックスへの着信を起点にします。

Office 365 Outlook コネクタの「When a new email arrives (V3)（新しいメールが届いたとき）」トリガーを使います。このトリガーには、件名での絞り込み（Subject Filter）、差出人アドレスでの絞り込み（From）、監視するフォルダーの指定（Folder）、添付ファイルの内容を取得するかどうか（Include Attachments）、添付のあるメールだけを対象にするか（Only with Attachments）といったパラメーターがあります。

専用の共有メールボックスを用意し、仕入先にそこへ返信してもらうのが確実です。 担当者個人のメールボックスを監視する構成にすると、担当者が休んだときに止まります。

添付の中身は、「Get Attachment (V2)」アクションでメッセージIDと添付IDを指定して取得します。返るのは Content Bytes（バイナリ）です。

入力データを集める

品番マスタに「仕入先品番」を持っているかどうかが、この構成の成否を分けます。 仕入先は自社の品番で回答してきます。対応表がないと、照合が人手に戻ります。

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

メール本文： トリガーの出力から取ります。HTMLメールの場合はテキストに変換します。

Excel添付： 表を読み取ってCSVまたはテキストに変換します。Excelファイルをそのまま生成AIに渡すことはできません。 Claude API のドキュメントには、.txt や .csv などのプレーンテキストは document ブロックで直接使えるが、.xlsx や .docx などのバイナリ形式は対応しておらず、テキストかPDFに変換する必要があると明記されています。ワークフロー側で変換工程を必ず挟んでください。

PDF添付： Azure AI Document Intelligence の prebuilt-layout モデルに渡します。このモデルは文字に加えて表を抽出し、行数・列数・行結合・列結合の情報を返します。outputContentFormat=markdown を指定するとMarkdown形式で出力でき、v4.0（2024-11-30 GA）以降は結合セルや複数行ヘッダーを表現するため表がHTML形式で出力されます。納期回答表は結合セルが多いので、この形式で受け取れることが効きます。

なお、Claude API は PDF を直接扱うこともできます（1リクエストあたり最大32MB・600ページ、コンテキストウィンドウが1Mトークン未満の場合は100ページ）。ページ数の少ない回答表ならこちらでも足ります。表の構造を厳密に取りたい場合はOCRサービス、文章混じりの回答書ならClaude直接、と使い分けます。

発注残・マスタ： 生産管理システムのAPI、または日次エクスポートを参照します。照合の対象は「未回答または回答済みで未納品」の発注に限れば、数百行から数千行に収まります。

AIへ渡す前に整形する

1. 引用部分の除去 … 返信メールには自社が出した発注メールがぶら下がっています。ここに書かれた希望納期を「回答納期」として拾う事故が起きます。 区切り行から下を必ず落とします
2. 署名の除去 … 署名の電話番号を数量として拾うことがあります
3. 添付の種別判定 … 納期回答表、請求書、図面が混ざります。ファイル名と中身から判定し、回答表以外は処理対象から外します
4. 照合対象の絞り込み … 発注残のうち「その仕入先の未納品分」だけをプロンプトに渡します。全件を渡すと誤照合が増えます
5. 年の補完 … 「3/15」とだけ書かれた回答が届きます。発注日と希望納期から年を推定するルールを前処理に置き、AIに推測させません

AIに処理させる

「出荷日か着荷日か」の判別を入れてください。 ここを取り違えると、輸送日数の分だけ納期の見込みがずれます。遠方の仕入先では1週間ずれることがあります。

指示内容を固定する

あなたは製造業の購買部で納期管理を担当する担当者です。
仕入先からの納期回答メールを読み、発注残と突き合わせる項目を取り出してください。

【厳守事項】
- 引用部分（自社が送信した発注メールの内容）は読まないでください。
  回答は今回書かれた本文と添付にだけ書かれています。
- 発注番号が本文に書かれていない場合は、po_number を null にし、
  【この仕入先の発注残】から候補を最大3件まで candidates に挙げてください。
  1つに決めないでください。
- 日付は YYYY-MM-DD で返してください。年が書かれていない場合は
  year_missing を true にし、date_raw に原文の表記をそのまま残してください。
  年を推測して補わないでください。
- 「出荷」「発送」とあれば ship、「納入」「着荷」「入荷」とあれば arrive、
  どちらとも読めなければ unknown を date_type に入れてください。
- 分納の場合は splits に数量と日付の組を分けて入れてください。
- 納期回答以外の連絡（値上げ、欠品、代替品の提案、条件付きの回答）が
  含まれていれば、other_notices に原文を引用してください。

【この仕入先の発注残（未納品分）】
{open_po_list}

【品番の対応表（自社品番 / 仕入先品番）】
{part_mapping}

【メール本文】
{mail_body}

【添付の内容】
{attachment_text}

「年を推測して補わない」の1行が重要です。 12月に「1/20」という回答が届いたとき、それが翌年の1月20日であることは文面からは決まりません。発注日との関係で判断すべきものなので、前処理のルールで補い、AIには推測させません。

出力形式を固定する

{
  "supplier_name": "",
  "po_number": "",
  "candidates": [
    { "po_number": "", "part_no": "", "qty": 0, "reason": "" }
  ],
  "part_no": "",
  "qty": 0,
  "answer_date": "",
  "date_raw": "",
  "date_type": "ship | arrive | unknown",
  "year_missing": false,
  "splits": [
    { "qty": 0, "date": "", "date_type": "ship | arrive | unknown" }
  ],
  "other_notices": [],
  "confidence": "high | medium | low"
}

Claude API の structured outputs を使うと、output_config.format に JSON スキーマを渡すことで、制約付きデコードによりスキーマに沿った出力が保証されます。公式ドキュメントは「JSONのパースエラーが起きない」「型と必須項目が保証される」「スキーマ違反によるリトライが不要」と説明しています。日付を文字列型、数量を数値型で固定しておくと、後段の台帳更新で型変換の失敗が起きません。

システムへ連携する

生産管理システムの発注残を更新します。連携方法は3通りあります。

最初は中間台帳から始めることを勧めます。 生産管理システムを直接書き換える構成は、誤った納期が入ったときの影響が大きく、切り戻しも面倒です。中間台帳で2か月運用して精度を測ってから、直接更新に移します。

遅延の通知は、1件ごとに送らず日次でまとめて1通にします。1件ずつ飛ばすと、受け取る側が見なくなります。

人が確認する

全件は確認しません。条件を決めて分けます。

この分け方が、この構成の設計の中心です。遅延なしの回答を自動で通すから工数が減り、遅延のある回答を人に回すから見落としが防げます。 全件を人が見る設計にすると、削減効果は半分以下になります。

自動更新した分も、監査のために日次の更新一覧を担当者に送ります。 見るのは1日1回、数分です。

運用を始めて2か月は、自動更新の対象も全件を人が見てください。精度が分かる前から自動で通す範囲を広げないでください。

例外に対処する

記録を残す

• メールの原本（本文・添付）
• 抽出結果（生のJSON）と確信度
• 照合の結果（どの発注に紐づけたか、その根拠）
• 台帳の更新前後の値
• 自動更新か、人の確定かの区別
• 人が修正した項目と、修正前後の値

自動更新か人の確定かを区別して残してください。 後で納期のトラブルが起きたとき、誰の判断で入った値かが分かる必要があります。更新前の値を残しておけば、誤更新の切り戻しもできます。