需要のばらつきから発注点と発注量を決めて、毎週の発注案を出す

処理の起点を決める

毎週日曜の夜に、定時で一括処理します。 週明けに購買担当が発注案を見られる状態にしておくためです。

品目数が8,000点あるため、1品目ずつリアルタイムに計算する構成にはしません。在庫が発注点を下回った瞬間に反応する必要があるのは、リードタイムの短い国内品だけで、その場合は日次のバッチを追加します。

なお、緊急発注は従来どおり人が判断します。この構成は定常の発注を対象にしたもので、突発の需要には追いつきません。

入力データを集める

出荷実績は2年分以上が必要です。 季節性を判定するには、同じ季節を2回は見る必要があります。1年分では「去年の夏に出た」が季節性なのか単発の案件なのかを区別できません。

「仕入先からのメール」を入力に含めるのが、この構成の特徴です。 数値だけを見て計算した発注点は、「来月から出荷制限がかかる」という情報を知りません。

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

実績・在庫・マスタ： 販売管理システムからの日次エクスポート、またはデータベースへの読み取り専用接続で取得します。リアルタイム連携は不要です。

仕入先からのメール： 購買部の共有メールボックスから、直近3か月ぶんの件名と本文を取得します。取得したメールは、品番または仕入先名で品目に結び付けます。

営業の案件情報： 販売管理システムの見込み案件、または営業からの連絡をスプレッドシートに集めたものを使います。「案件情報が整備されていない」という理由でこの構成を諦める必要はありません。 空のまま動かしても、統計計算の部分は機能します。

AIへ渡す前に整形する

1. 需要パターンの分類 … 品目ごとに、直近24か月の出荷実績から次を判定します

- 安定型 … 毎月出荷があり、月ごとのばらつきが小さい - 季節性型 … 特定の月に集中し、その傾向が2年続いている - 断続的型 … 出荷のない月が半分以上ある - 新規型 … 取り扱い開始から12か月未満 - 終売型 … 直近6か月の出荷が減少を続けている、または終売予定がある

1. 異常値の除去 … 単発の大口案件による出荷を、通常需要から分けます。これを混ぜたまま平均を取ると、発注点が過大になります
2. 欠品期間の補正 … 在庫がなくて出荷できなかった期間の「出荷ゼロ」は、需要がなかったわけではありません。この補正をしないと、欠品した品目ほど発注点が下がり、また欠品します
3. 単位のそろえ … 出荷単位と発注単位が違う品目（バラ出荷・箱発注）を換算します
4. メールと品目の結び付け … 仕入先からのメールを、本文中の品番または仕入先コードで品目に結び付けます

3番目を軽く見ないでください。 欠品による需要の見えない部分を無視すると、在庫管理は自己強化的に悪化します。

AIに処理させる

計算は数式で行います。 使う式は次の2つです。

安全在庫 ＝ 安全係数 × 需要の標準偏差 × √(調達リードタイム ＋ 発注間隔)

発注点   ＝ 1日平均出荷量 × 調達リードタイム ＋ 安全在庫

安全係数は、許容する欠品率から決めます。欠品率を小さくするほど係数は大きくなり、在庫は増えます。「どの品目で欠品を許容するか」は経営判断であり、計算で決まるものではありません。 品目をABC分析で分け、区分ごとに目標欠品率を決めてください。

需要の平均と標準偏差の求め方は、パターンによって変えます。

断続的型と新規型を、安定型と同じ式で計算しないでください。 出荷のない月が多い品目に単純な標準偏差を当てると、意味のない安全在庫が出ます。

LLMにさせること：

LLMに数量を決めさせないでください。 補正の「根拠」は出させますが、補正後の数量を計算させません。 「リードタイムが2週間延びる」という情報を抽出させ、その値を数式に入れて再計算するのはプログラム側の仕事です。

指示内容を固定する

あなたは、購買担当が発注量を判断するための材料を整理する担当者です。
計算された発注点・発注量に対して、数値には表れていない事情を
テキスト情報から拾い、注意点を示してください。

【厳守事項】
- 発注量や発注点の数値を、あなたが計算し直さないでください。
  補正が必要と考える場合は、補正の根拠となる事実（リードタイムが何日延びる、
  出荷制限がいつから、など）だけを抽出してください。
- 抽出した事実には、根拠となったメールの件名・日付、または
  案件情報のIDを source に必ず記載してください。
- メールや案件情報に書かれていないことを推測しないでください。
  情報がない場合は findings を空配列にしてください。
- 「念のため多めに」のような、根拠のない増量の提案をしないでください。
- 仕入先からの連絡が、この品目に関するものかどうか判断できない場合は、
  uncertain に入れ、findings には入れないでください。
- 確認事項は、購買担当がその場で確かめられる形で書いてください。
  「需要動向を確認してください」のような一般的な指示は作らないでください。

【対象品目】
品番: {item_code} / 品名: {item_name} / 仕入先: {supplier}
需要パターン: {demand_pattern}
計算された発注点: {reorder_point} / 現在庫: {stock} / 発注残: {on_order}
計算された発注量の案: {suggested_qty}（ロット {lot_size} / 最低発注金額 {moq_amount}）
調達リードタイム（マスタ値）: {lead_time} 日

【この品目・この仕入先に関する直近3か月のメール】
{supplier_mails}

【この品目に関連する案件情報】
{sales_pipeline}

【この品目の過去の欠品・過剰の記録】
{incident_history}

「あなたが計算し直さないでください」の1行が、この構成の安全装置です。 これを書かないと、LLMは親切に「したがって発注量は450個が適切です」と書きます。その数字には根拠の追跡ができません。

「根拠のない増量の提案をしない」も必ず入れてください。 在庫が増える方向の提案は、もっともらしく見えて反論しにくいため、そのまま通りやすくなります。

出力形式を固定する

計算部分（プログラム）の出力：

{
  "item_code": "",
  "demand_pattern": "stable | seasonal | intermittent | new | discontinued",
  "avg_daily_demand": 0,
  "demand_std": 0,
  "lead_time_days": 0,
  "review_interval_days": 0,
  "service_level_target": 0,
  "safety_factor": 0,
  "safety_stock": 0,
  "reorder_point": 0,
  "current_stock": 0,
  "on_order": 0,
  "suggested_qty_raw": 0,
  "suggested_qty_adjusted": 0,
  "adjustment_reason": "lot_size | moq | none",
  "calc_basis": {
    "months_used": 0,
    "outliers_removed": 0,
    "stockout_periods_corrected": 0
  }
}

LLM部分の出力：

{
  "item_code": "",
  "findings": [
    {
      "type": "lead_time_change | price_change | discontinuation | supply_limit | demand_event",
      "fact": "",
      "effective_from": "",
      "source": "",
      "impact_direction": "increase | decrease | timing_only"
    }
  ],
  "uncertain": [],
  "explanation": "",
  "questions": [],
  "recommend_human_review": true
}

2つを別のJSONで持つことに意味があります。 計算値とテキスト由来の情報を1つの構造に混ぜると、どの数字が計算から来てどれが読み取りから来たのかが分からなくなります。 発注案の画面でも、この2つは分けて表示します。

calc_basis を残すのは、後から「なぜこの発注点になったのか」を再現するためです。異常値を何件除いたか、欠品期間を何回補正したかが分かると、おかしな発注点の原因が追えます。

システムへ連携する

承認された発注だけを登録します。 発注案の自動発注は、この構成の対象外です。理由は後述します。

人が確認する

全件を人が承認します。ただし、確認の重さを3段階に分けます。

月1,200件のうち、一括承認に回せるのは700〜900件程度が目安です。ここが自動化の効果の大半を生みます。

発注の完全自動化をしない理由を書いておきます。 発注は現金の支出と在庫の増加を伴います。計算の前提（リードタイム、ロット、終売予定）がマスタで古いままだと、誤った発注がそのまま実行されます。マスタの鮮度を人が保証できない限り、自動発注は危険です。 逆に言えば、マスタの整備が進み、予測と実績のずれが安定して小さくなった品目については、段階的に自動化を検討できます。

例外に対処する

記録を残す

• 週次の計算結果（calc_basis を含む全項目）
• LLMが抽出した findings と、その根拠となったメール・案件情報
• 発注案と、担当者が承認・修正した結果
• 担当者が修正した理由
• 翌週以降の実績と、予測とのずれ
• 欠品・過剰が起きた品目と、そのときの計算値

「担当者が修正した理由」がこの構成の要です。 「この品目は月末に注文が集中するから」「この仕入先は繁忙期に納期が延びるから」という理由が蓄積すれば、次は計算の前提に組み込めます。 修正が減っていくことが、この構成が機能している証拠になります。

予測と実績のずれの記録は、安全係数の見直しに使います。 ずれが小さい品目は係数を下げて在庫を減らせます。ずれが大きい品目は係数を上げる必要があります。これを毎月見直す仕組みがないと、在庫は減りません。