部品の在庫・発注残・納期回答をエージェントが毎朝生産計画と突き合わせ、欠品の恐れに督促の文案と警告を付ける

処理の起点を決める

毎朝6時30分の定時実行にします。 生産管理システムの夜間の所要量計算が終わり、購買の担当者が出社する前の時刻です。n8n の Schedule Trigger は秒・分・時・日・週・月の間隔と、Custom（Cron）の指定ができます。平日だけ動かすなら Cron で曜日を指定します。

時刻の基準に注意してください。 Schedule Trigger はワークフローのタイムゾーンが設定されていればそれを、無ければ n8n のインスタンスのタイムゾーンを使います。自前で立てたインスタンスの既定は America/New York です。 そのままにすると、朝6時30分のつもりが夜に動き、前日の所要量で見回ることになります。ワークフローの設定で Asia/Tokyo を指定します。

また、Schedule Trigger を起点にしたワークフローは、保存して公開（publish）しないと定時に動きません。 道具として呼ぶ側のワークフローも同じで、公開されていないと「Workflow is not active and cannot be executed.」で失敗します。親だけ公開して道具を公開し忘れるのが、最初の週にいちばん起きる失敗です。

入力データを集める

質を決めるのは、納期回答の「回答日」です。 回答納期が入っていても、それが3週間前の回答なら、仕入先の状況はもう変わっているかもしれません。回答日が古い発注残は、回答があっても「回答なし」に近い扱いにします。 何日を古いとするかは仕入先の区分ごとに決め、品目マスタか仕入先の一覧に持たせます。

在庫の「取得した時刻」も必ず持ちます。 夜間のバッチが止まった日に前日の在庫で計算すると、入荷済みの部品が欠品と出ます。 時刻を見て古ければ、その日の見回りを止めます。

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

データの取得は、エージェントの外で先に済ませます。 欠品の計算に使う所要量・在庫・発注残・回答は、毎朝まとめて読み込み、計算のノードに渡します。エージェントが道具で引くのは、欠品の恐れと出た部品についての詳細だけです。

AIへ渡す前に整形する

1. 鮮度の確認 … 在庫と所要量の取得時刻が当日の夜間バッチより後かを確かめます。古ければ見回りを止め、生産管理へ知らせます
2. 発注残と台帳の照合 … 発注番号と行番号で突き合わせ、台帳にあってシステムに無い行、その逆を一覧にします
3. 入荷予定の区分 … 発注残の行ごとに、回答のある行は回答納期と回答数量で、回答の無い行は「未確定」として別に数えます
4. 在庫の推移の計算 … 当日から15営業日先まで、日ごとに「手持ち − 引当 ＋ 確定の入荷 − 所要」を足し上げます
5. 欠品の恐れの判定 … 確定の入荷だけで数えて安全在庫を割る日があれば候補にします。未確定の入荷を足しても割るなら「強い候補」、足せば足りるなら「回答待ち候補」とします
6. 前日との差分 … 前日の見回りでも拾った部品か、新しく拾った部品か、前日より欠品の日が早まったかを付けます
7. 件数の制限 … 1回の見回りでエージェントに渡すのは、欠品の日が近い順に上限まで。上限を超えた分は一覧にだけ載せます

5番目が、この構成の要です。 未確定の入荷を最初から足してしまうと、回答の無い発注残で埋まっている部品が候補から消えます。 逆に未確定をまったく見ないと、回答が来れば済む部品まで督促の対象になります。2つに分けて、「回答待ち候補」は回答を催促する文面、「強い候補」は前倒しや代替の相談に進めます。

計算はすべて Code ノードで行い、AIには結果だけを渡します。 数量の足し引きを生成AIにさせると、桁や日付の取り違えがそのまま警告になります。

AIに処理させる

させるのは、計算が拾った部品について、原因を記録から決め、対応の案と文案を作ることです。 欠品の日と数量は計算の結果をそのまま受け取り、AIは書き換えません。

原因の「入荷済み未計上の疑い」は、メールの抜粋から拾います。 「本日出荷しました」というメールが来ているのに発注残が残っている部品は、督促ではなく受け入れの確認が先です。 これを督促にしてしまうと、届いている部品を仕入先に催促することになります。

指示内容を固定する

System Message に次の内容を入れます。

あなたは製造業の購買部で、欠品の恐れがある部品の原因を調べる担当です。
計算のノードから渡される「欠品の恐れ」の結果を前提に、道具で記録を引き、
原因と対応の案、仕入先への文案、生産管理への警告文を作ってください。

【前提として変えないこと】
- first_short_date、short_qty、basis は計算の結果です。書き換えないでください。
- 数量や日付の足し引きをしないでください。必要な数値は道具の結果から写してください。

【道具の使い方】
1. まず get_open_po_detail で発注残を確認してください。
2. 回答の無い行、回答日が古い行があれば get_supplier_messages を呼んでください。
3. 足りなくなったときに何が止まるかを get_demand_orders で確認してください。
4. 前倒しや代替を検討するときだけ get_alternatives と get_expedite_history を使ってください。
同じ道具を同じ引数で2回呼ばないでください。

【原因の選び方】
- no_reply ......... 回答の記録が無い発注残がある
- reply_late ....... 回答納期が所要日より遅い
- reply_short_qty .. 回答数量が発注数量より少ない
- reply_stale ...... 回答日が基準より古い
- demand_increase .. 前日より所要が増えたことで足りなくなった
- receipt_pending .. 出荷済み・納品済みと読めるメールがあるのに発注残が残っている
- unknown .......... 上のどれとも決められない
迷ったときは unknown を選び、questions_for_buyer に理由を書いてください。

【厳守事項】
- 記録に無いことは書かないでください。回答の無い発注残の納期を推測しないでください。
- 電話で回答があったかどうかは分かりません。記録が無ければ no_reply です。
- 仕入先への文案は「お願い」と「ご相談」の形にしてください。
  納期や数量を一方的に変更する書き方、従わない場合の不利益を示す書き方をしないでください。
- 費用の負担、代金、値引きについては文案に書かないでください。
  必要なら questions_for_buyer に「前倒しの費用の扱いを決める」と書いてください。
- 文案には、発注番号、行番号、品目番号、発注数量、指定納期、回答納期を
  道具の結果のとおりに入れてください。
- evidence には、判断の根拠にした記録の種類と識別子と、該当する文字列を写してください。
- 警告の段階は決めないでください。

【計算の結果】{shortage}
【前日の見回りの結果】{previous}
【担当バイヤー】{buyer}

「電話で回答があったかは分からない」を書かないと、AIは気を利かせます。 回答の記録が無い発注残について「電話で確認済みの可能性」と書き、原因をぼかします。分からないことは分からないまま返させ、確かめるのは人にします。

「お願い」と「ご相談」の形を指定しているのは、取引の条件に関わるからです。 公正取引委員会は、取適法で委託事業者に禁止される行為として、費用を負担せずに注文内容を変更すること（不当な給付内容の変更）や、価格協議の求めに応じない一方的な代金の決定を挙げています。前倒しや数量の追加を「変更します」と書いた文案は、それだけで危うい書き方になります。

出力形式を固定する

Require Specific Output Format を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "part_no": "",
  "run_date": "",
  "shortage": { "first_short_date": "", "short_qty": 0, "basis": "confirmed_only | with_unconfirmed" },
  "cause": "no_reply | reply_late | reply_short_qty | reply_stale | demand_increase | receipt_pending | unknown",
  "evidence": [ { "source": "po | reply_log | mail | demand", "id": "", "quote": "" } ],
  "affected_orders": [ { "mo_no": "", "product": "", "ship_date": "" } ],
  "proposed_action": "chase_reply | pull_in_request | split_delivery_request | check_alternative | consult_planning | check_data",
  "supplier_draft": { "supplier_code": "", "subject": "", "body": "" },
  "planning_message": "",
  "questions_for_buyer": [],
  "confidence": "high | low"
}

Structured Output Parser は、JSONの例から形を作る方法と、JSON Schema を書く方法の2つから選べます。例から作ると、すべての項目が必須として扱われます。 supplier_draft を出さない場合（原因がデータの確認のとき）があるので、JSON Schema で書き、必須の項目を自分で決めます。 なお、JSON Schema の $ref による参照は使えないとされているので、入れ子の形はその場に展開して書きます。

1つ目の理由は、原因と段階を別の層に置けることです。 cause と proposed_action はAIが埋め、警告の段階は後段の規則で決めます。

2つ目は、evidence で確認が速くなることです。 バイヤーは画面を開き直さずに、どの発注残のどの回答を見て判断したかを読めます。

システムへ連携する

エージェントに渡す道具はすべて読み取りです。 下書きの保存とチャットへの投稿は、エージェントの出力を受けた後段のノードが規則で行います。AIが道具として書き込みを持たない形にしておくと、見回りが何回まわっても、勝手に送られるものが無くなります。

エージェントに書き込みの道具を持たせたくなったら、人の承認を挟みます。 n8n では、道具に人の確認を設定すると、その道具を呼ぶところでワークフローが止まり、Microsoft Teams や Slack、メールなどへ承認の依頼が飛びます。$tool.name と $tool.parameters で何をしようとしたかを依頼文に出せます。否認されるとその操作は取り消され、AIに否認されたことが伝わるので、System Message に否認されたときの振る舞いを書いておきます。

人が確認する

人が見るのは、エージェントが出した全件です。 ただし、見る深さを段階で変えます。

1. 段階Aを最初に見る … 生産管理と同時に通知が届きます。バイヤーは文案を直して送り、急ぐものは電話します
2. confidence が low と unknown のものを見る … 原因が決まっていないものは、記録の側に欠けがあることが多い
3. receipt_pending を見る … 督促の前に、受け入れの担当へ入荷の有無を確かめます
4. 段階B・Cは一覧で見る … 文案に問題がなければそのまま送り、回答待ちのものは様子を見ます
5. 前倒しの相談は、費用の扱いを決めてから送る … questions_for_buyer に残された事項を片付けます

目標は、1件をならして6分です。 文案をそのまま送れるものは1〜2分、段階Aで電話と生産管理の相談が要るものは10分を超えます。

例外に対処する

上の2行で、誤った警告の大半を止めます。 どちらもAIの問題ではなく、データがそろっていないまま計算したことによる問題です。

記録を残す

• その日の計算の入力（所要量・在庫・発注残・回答の取得時刻と件数）
• 部品ごとの在庫の推移と、欠品の恐れの判定結果
• エージェントの出力の全文と、Return Intermediate Steps で残した道具の呼び出しの順と結果
• 規則で決めた段階と、送った先
• バイヤーが文案を直したかどうかと、送った日時
• 仕入先からの回答と、その後に欠品が起きたかどうか

4つ目と5つ目は、翌朝の見回りの材料です。 送ったのに回答が来ていない部品を拾うには、いつ送ったかが記録に残っている必要があります。 送ったことが記録されないと、エージェントは同じ督促の文案を毎朝作ります。