仕入先から届く製造中止・仕様変更の通知を読み取って、影響する製品と手配を洗い出す

処理の起点を決める

購買の共有メールボックスに新着メールが届いたことを起点にします。担当者個人のメールアドレスを起点にしません。理由は3つあります。

1つは、担当者が休んだときに止まるのを避けるためです。2つ目は、個人のメールを外部サービスが読む構成を作ると、私信まで対象になってしまうためです。3つ目は、仕入先に「今後の通知はこのアドレスへ」と依頼できるためです。

仕入先ポータルにしか掲示されない通知は、この構成では拾えません。ポータル運用の仕入先には、メール通知の設定を依頼してください。 それができない数社は、従来どおり人が週1回見に行く運用を残します。

入力データを集める

部品マスタに「仕入先の型番」の欄があるかどうかが、この構成の成否を分けます。 ない場合は、この欄を作ることから始めます。6,000点すべてを埋める必要はありません。通知が届いた部品から順に埋めていけば、半年で主要な仕入先はそろいます。

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

通知の本文とPDF： メールの本文はそのままテキストで取れます。添付PDFはテキスト情報を持つものが大半ですが、スキャンした紙をPDFにしたものも混ざります。テキストが取れない場合は、AIの画像入力に渡します。1ページの通知なので、この程度なら十分に読めます。

部品表の展開： 部品番号から製品をたどる処理は、生産管理システムの「逆展開」「使用先照会」といった機能を使います。この機能がない場合は、部品表のデータをエクスポートし、親子関係を再帰的にたどるスクリプトを書きます。

在庫と生産計画： 日次のエクスポートで足ります。夜間バッチで前日分をファイルに出し、それを参照します。

AIへ渡す前に整形する

1. 通知かどうかの選別 … 仕入先からのメールには、価格改定、営業案内、納期回答、請求が混ざります。件名と本文の冒頭で一次選別し、迷うものだけAIに判定させます
2. 部品番号の正規化 … ハイフン、スラッシュ、スペースを取り除いた文字列を作り、これで突き合わせます。「ABC-1234-05」「ABC1234/05」がどちらも ABC123405 になります
3. 同じ通知の重複除去 … 同じ通知が担当者あてと共有あての両方に届くことがあります。仕入先＋部品番号＋通知日で重複を検出します
4. 複数部品が書かれた通知の分割 … 1通の通知に部品が20点並ぶことがあります。部品ごとに1件として処理します
5. 期限の書式の統一 … 「2026年12月31日」「2026/12/31」「Dec 31, 2026」を同じ形にそろえます

AIに処理させる

AIと従来の処理で役割を分けます。

従来の処理にさせること： 部品表の展開、在庫と生産計画の集計、不足数量の計算。ここは計算であって判断ではありません。 AIにさせると、数字が合わなかったときに原因が追えません。

AIにさせること：

最後の緊急度はあくまで並べ替えの材料です。緊急度が低いと判定されたものを自動で放置する構成にはしません。

指示内容を固定する

あなたは製造業の調達担当を支援する立場です。
仕入先から届いた通知を読み、部品番号・変更区分・期限を抽出してください。

【厳守事項】
- 通知に書かれていない値を補わないでください。
  期限の記載がなければ deadline を null にしてください。
  「おそらく月末」のような推測を入れないでください。
- 部品番号は、通知に書かれた文字列をそのまま part_number_as_written に入れ、
  自社部品番号への対応づけは candidates に候補として列挙してください。
  1つに決めないでください。
- 1通に複数の部品が書かれている場合は、部品ごとに1件ずつ返してください。
- 変更区分は次から選んでください。判断がつかない場合は "unknown" にしてください。
  eol / spec_change / site_change / alternative / not_applicable
- 「梱包形態のみの変更」「ラベルのみの変更」は spec_change ではなく
  site_change として扱い、その旨を note に書いてください。
- 原文の該当箇所を evidence にそのまま入れてください。要約しないでください。

【メール本文】
{mail_body}

【添付PDFのテキスト】
{pdf_text}

【この仕入先の過去の通知（直近10件の書式）】
{past_notices}

「1つに決めないでください」の指示が重要です。 部品番号の対応づけをAIに断定させると、似た型番の別部品に紐づいた場合に、まったく関係のない製品の影響一覧が出ます。候補を並べさせ、絞り込みは正規化した文字列の一致で機械的に行います。

過去の通知を10件渡すのも効きます。 仕入先ごとに通知の書式は決まっています。同じ書式の例を見せると、項目の取り違えが減ります。

出力形式を固定する

Gemini API の構造化出力を使い、決めた形のJSONで受け取ります。スキーマは properties でプロパティを定義し、required で必須項目を列挙します。非常に大きい、あるいは深くネストしたスキーマは拒否されることがあるため、1回の呼び出しで返させる構造は浅く保ちます。

{
  "notices": [
    {
      "notice_type": "eol | spec_change | site_change | alternative | not_applicable | unknown",
      "supplier_name": "",
      "part_number_as_written": "",
      "candidates": [
        { "internal_part_no": "", "match_reason": "" }
      ],
      "deadline": null,
      "switch_date": null,
      "alternative_part_no": "",
      "change_summary": "",
      "evidence": "",
      "confidence": "high | medium | low"
    }
  ]
}

影響の計算結果は、AIではなく後段の処理が作ります。

{
  "internal_part_no": "",
  "affected_products": [
    {
      "product_no": "",
      "qty_per_unit": 0,
      "plan_12m": 0,
      "required_by_deadline": 0,
      "stock_on_hand": 0,
      "on_order": 0,
      "shortage": 0
    }
  ],
  "total_shortage": 0
}

システムへ連携する

つなぎ先は3つです。

生産管理システムへの書き込みはしません。 発注の起案は、担当者が既存の画面で行います。ここを自動化すると、誤った影響判定がそのまま発注になります。

Make のシナリオは、エラーで止まったときの扱いを決めておきます。Make には、エラーが起きたバンドルを、自分で定義した代替の出力に置き換えて処理を続ける Resume error handler があります。在庫照会が1製品だけ失敗したときに、シナリオ全体を止めないためにこれを使います。置き換えた値には「取得失敗」と分かる印を入れ、一覧上で人が気づけるようにします。

人が確認する

全件、人が判断します。対応を自動で決める構成にはしません。

理由は、対応の選択肢が状況で変わるためです。同じ製造中止でも、最終発注で数年分を買うのか、代替品に切り替えるのか、設計変更するのかは、製品の残存期間と在庫費用と評価工数を天秤にかけて決めます。この判断材料は部品表の外にあります。

確認を速くするための設計が重要です。

• 一覧を期限の近い順に並べる
• 不足数量が0の部品（在庫で足りる）を下に送る
• confidence が低い抽出結果と、部品番号の候補が2つ以上ある件に印を付ける
• 影響製品が0件だった通知も必ず一覧に残す（対応づけが失敗しただけの可能性がある）

最後の項目が重要です。「影響なし」と「対応づけに失敗した」は見た目が同じになります。区別できないと、危険なほうを見落とします。

例外に対処する

記録を残す

• 受信した通知（メール本文と添付の原本）
• AIが抽出した項目と evidence、confidence
• 部品番号の対応づけの結果と、人が選び直したかどうか
• 影響一覧（計算に使った在庫・計画の値と、取得した日時）
• 人が決めた対応（最終発注／代替品評価／設計変更／対応不要）と、その理由
• 期限までの残日数と、リマインドを送った記録

4つ目で「計算に使った値と取得日時」を残すのが要です。後から「なぜこの数量で発注したのか」を問われたときに、当時の在庫と計画を再現できないと説明ができません。

対応の記録は、通知の期限から最低でも5年は保存します。製造中止の判断は、数年後に「なぜあのとき買わなかったのか」と振り返られることがあります。