受注ごとの品目・数量・工程の混み具合と過去の実績から生産のリードタイムを見込み、営業が顧客へ答える納期の候補と、遅れるおそれのある受注を出す

処理の起点を決める

問い合わせの登録をきっかけに、1件ずつ動かします。 営業が品目と数量を入れて登録すると、数秒で候補が返り、同時に生産管理の確認待ちの一覧に入ります。営業が顧客と電話している間に、真ん中と遅めの日付が見えるようにするためです。

毎朝7時に、受注残の全件を見込み直します。 前日の工程の完了の実績は、夜のうちに生産管理システムへ入っています。朝礼の前に、遅れるおそれのある受注の一覧が生産管理の手元にあるようにします。

月に一度、前の月に完成した受注で答え合わせをします。 見込んだ日数と実際の日数を並べ、90％点を超えた受注の割合を工程の組み合わせごとに出します。モデルの学び直しは、四半期に一度と、設備や人の配置が大きく変わったときにします。

入力データを集める

質を決めるのは、工程ごとの着手日と完了日です。 受注日と出荷日しか残っていなければ、どの工程で待っていたかが分かりません。工程の混み具合が日数にどう効くかを学ばせるには、工程ごとの実績が要ります。 現場の端末で着手と完了を入れていない工場は、まずそこから始めます。

工程の能力の表も外せません。 受注残の工数をそのまま特徴にすると、人が増えた月と減った月の違いが見えません。受注残の工数を1日の能力で割った「その工程があと何日分詰まっているか」を特徴にします。

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

生産管理システムからは、毎晩CSVで書き出したものを読みます。 読み取り専用のデータベースの口があればそちらでも構いませんが、本番のデータベースへ直接つなぐのは、問い合わせのたびに負荷をかけるので避けます。 夜の書き出しに加えて、受注残だけは問い合わせのたびに最新を取ります。

学習のデータは、受注の時点に戻して作ります。 過去の受注について、その受注が入った日の受注残から工程ごとの負荷の日数を計算し直します。 今の受注残で過去の受注の負荷を作ると、見込むときには分からない情報で学習することになり、検証では当たるのに本番で外れます。

図面番号が初めての品目は、品目区分の標準の並びで代えます。 「架台・溶接・塗装あり」「機械加工のみ」のような区分ごとに、工程の並びと工数の目安を生産管理課が決めておきます。

AIへ渡す前に整形する

1. 稼働日数に直す … 受注日から完成日までを、カレンダーの稼働日の数で数えます。暦の日数で学習すると、連休をまたいだ受注だけが長く見えます
2. 負荷の日数を作る … 工程ごとに、受注の時点の受注残の工数を1日の能力で割ります
3. 工程の特徴を作る … 工程数、標準の工数の合計、外注の工程の有無、塗装・溶接・機械加工を通るかの印
4. 材料の特徴を作る … 在庫から出せるか、発注残があるか、新たに発注するか。発注残は入荷の予定日までの稼働日数
5. 特殊な受注の印 … 顧客の都合で止めた受注、図面の変更でやり直した受注、棚卸や設備の故障で止まった期間に印を付けます
6. 外注と出荷を分ける … 外注の工程の日数と出荷の日数は、モデルの外で過去の実績の中央値を足します

5番目の印を付けた受注は、学習から外さずに、印を特徴として残します。 外すと、止まった受注の多い品目区分だけが短く見えます。ただし見込むときには印を「無し」として出します。 顧客の都合で止まるかどうかは、受注の時点では分からないからです。

6番目で外注を分けるのは、外注先の混み具合が社内のデータに無いからです。 外注の日数まで1つのモデルで見込むと、社内の負荷で説明できない分が全部ばらつきに入り、90％点が広がりすぎます。

AIに処理させる

この構成の「AI」は、受注から完成までの社内の稼働日数の見込みだけです。 日付への変換、外注と出荷の足し算、遅れの判定は決まった規則で出します。

見込みには、LightGBM の objective="quantile" を使います。 alpha を0.5と0.9にした2つのモデルを作り、どちらも同じ特徴で学習します。欠けた値の扱いが組み込まれているので、初めての品目で過去の実績が無い列も、落とさずに見込めます。

評価には、scikit-learn の mean_pinball_loss を使います。 分位点回帰のための損失で、alpha を見込みと同じ0.5と0.9にして測ります。あわせて「実際の日数が90％点以下に収まった割合」を数えます。 90％点なら、9割前後に収まっていなければ、損失の値が小さくても使えません。

検証は時間の順で分けます。 scikit-learn の TimeSeriesSplit は、未来のデータで学習して過去を評価しないための分け方ですが、サンプルが等しい間隔で並んでいることを前提にしています。 受注は日によって件数がばらつくので、この構成では受注月で区切って、前の月までで学習し次の月で検証する分け方を自前で作ります。さらに、検証する月の直前1か月は学習から外します。検証する月の受注と完成が重なる期間の実績を、学習に混ぜないためです。

1行目がいちばん起きやすい失敗です。 候補の日付が画面に出ると、営業はそのまま顧客へ答えたくなります。生産管理の確認を経ない日付で約束すると、特急が重なった月に、答えた納期がまとめて崩れます。

指示内容を固定する

この構成は生成AIを使わないため、指示は Python の設定ファイルに書きます。 何をどう見込み、どの規則で候補と遅れを出すかを、生産管理と営業が読める形で残すためです。

# 生産のリードタイムの見込みの設定（leadtime_forecast.yaml）

対象: 社内の工程（切断・曲げ・機械加工・溶接・塗装・組立・検査）
単位: 稼働日（生産管理課のカレンダー）

特徴:
  - 品目区分, 数量, 材質
  - 工程数, 標準の工数の合計, 外注の工程の有無
  - 工程ごとの負荷の日数（受注の時点の受注残の工数 ÷ 1日の能力）
  - 材料の手配（在庫／発注残／新規）, 入荷の予定までの稼働日数
  - 特急の印, 受注月

見込み:
  50％点: {objective: quantile, alpha: 0.5}
  90％点: {objective: quantile, alpha: 0.9}
  向きの制約: {数量: +1, 標準の工数の合計: +1, 工程ごとの負荷の日数: +1}
  学び直し: 四半期ごと（1月・4月・7月・10月）と、設備・人の配置の変更のあと
  検証: 受注月で区切る。検証する月の直前1か月は学習から外す
  評価: mean_pinball_loss（alpha=0.5, 0.9）と、90％点以下に収まった割合

納期の候補:
  標準: 受注日 + 90％点 + 外注の日数（過去の中央値） + 出荷の日数
  最短: 受注日 + 50％点 + 外注の日数 + 出荷の日数（「調整が要る」と必ず書く）

遅れるおそれ:
  - 受注残ごとに、残りの工程で見込み直した90％点の完成日を出す
  - 完成日 + 出荷の日数 が約束の納期を超えたら「おそれあり」
  - 50％点でも超えたら「遅れの見込み」

守ること:
  - 品目区分が未登録の問い合わせは見込まない。「区分の登録が必要」と返す
  - 90％点が50％点を下回った行は、並べ替えずに印を付けて人に見せる
  - 学習のデータに無い数量（過去の最大の2倍を超える）は印を付ける
  - 結果を生産管理システムの納期の欄や工程の計画に書き込まない

「最短には必ず調整が要ると書く」が、営業の側の要です。 50％点は、半分の受注がそれより遅れる日数です。何の手当てもなしに答えれば、2件に1件は遅れの連絡をすることになります。 画面にも、最短の日付の横に同じ注意を出します。

「学習のデータに無い数量に印を付ける」は、木のモデルの性質への備えです。 木のモデルは学習した範囲の外へ伸びず、過去の最大の数倍の数量でも、最大の数量と同じくらいの日数を返します。 大口の受注ほど見込みが短く出るので、印で人に知らせます。

出力形式を固定する

問い合わせ1件ごとに、次の形のJSONと、それを一覧にした表で出します。

{
  "inquiry_id": "Q-2026-1008-014",
  "issued_at": "2026-10-08T10:12",
  "model_version": "lt-2026Q4",
  "item": { "drawing_no": "", "item_class": "架台・溶接・塗装あり", "qty": 0, "is_new_drawing": true },
  "load_days": { "cutting": 0.0, "bending": 0.0, "machining": 0.0, "welding": 0.0, "painting": 0.0, "assembly": 0.0 },
  "material": { "status": "in_stock | on_order | new_order", "days_to_arrival": 0 },
  "forecast_workdays": { "p50": 0.0, "p90": 0.0 },
  "outsourced_days": 0,
  "shipping_days": 0,
  "candidates": {
    "standard_date": "2026-11-10",
    "earliest_date": "2026-11-02",
    "earliest_note": "調整が要る"
  },
  "flags": [],
  "planner_decision": { "answer_date": "", "reason": "" }
}

load_days と forecast_workdays と candidates は Python が埋め、planner_decision は生産管理の担当が書きます。

1つ目の理由は、候補と決めた日付を同じ記録に並べられることです。 後で完成の実績が入ったときに、候補のままのほうが当たっていたのか、担当者が動かしたほうが当たっていたのかを比べられます。動かした理由が溜まれば、モデルに足すべき特徴が見えてきます。

2つ目は、load_days で、なぜその日数なのかを営業に説明できることです。 「溶接があと12日分詰まっている」と分かれば、営業は顧客に「溶接の少ない仕様なら早くできます」と別の案を出せます。

受注残の点検は、受注1件ごとに次の項目を一覧にします。

判定の列は「遅れの見込み」「おそれあり」「間に合う見込み」の3つです。 一覧は判定の重い順、同じ判定の中では約束の納期の近い順に並べます。

システムへ連携する

生産管理システムの納期の欄には書き込みません。 顧客へ答えた日付は、これまでどおり受注の登録のときに人が入れます。見込みの値が受注の納期の欄に入ると、見込みと約束の区別が無くなります。

社内チャットには、件数と一覧の置き場所だけを流します。 顧客名と納期の一覧そのものをチャットに貼ると、営業以外の人にも受注の状況が見えてしまうためです。

人が確認する

生産管理の担当は、問い合わせの候補を1件ずつ確かめてから営業へ返します。

1. 印を先に見る … 未登録の品目区分、学習の範囲外の数量、90％点と50％点の逆転が無いかを見ます
2. 負荷の日数を見る … 来週の休みや設備の保全の予定で、負荷の日数より詰まる工程が無いかを確かめます
3. 特急と残業の予定を加える … 割り込ませる予定の特急、組んである残業や休日の稼働があれば、日付を動かします
4. 回答の日付を決めて記録する … planner_decision に日付と理由を書き、営業の画面に返します

2番目を省かないでください。 モデルは受注残の工数と能力の表から負荷を見ますが、来週だけ溶接の職人が2人休む、といった予定は表に無い限り知りません。 その差を埋めるのが担当者の仕事です。

毎朝の遅れるおそれのある受注は、朝礼の前に生産管理が見て、営業に渡す受注を選びます。 工程の順番の入れ替えで間に合うものは生産管理の側で手を打ち、間に合わないと決めたものだけを営業に渡して、顧客への連絡を相談します。

目標は、ならして1件4分です。 印の無い問い合わせは負荷の日数を見て1〜2分で返し、特急が重なる問い合わせや遅れの見込みの受注は、工程の順番を考えるので10分前後かかります。

例外に対処する

上の2行は、運用の最初から起きます。 新しい形の品目と大口の受注は、営業がいちばん急いで答えを欲しがる問い合わせです。見込みが出ないことを隠さず、生産管理が手で確かめる流れに乗せます。

記録を残す

• 問い合わせの内容と登録の日時、見込みに使った受注残と材料の一覧のそのときの版
• 見込みの値（50％点と90％点）、工程ごとの負荷の日数、納期の候補、付いた印
• モデルの版、学習の期間、検証の結果（月ごとの mean_pinball_loss と、90％点以下に収まった割合）
• 生産管理が決めた回答の日付と理由（planner_decision）
• 毎朝の受注残の判定と、営業に渡した受注
• 完成の実績が入った後の、見込みと実際の日数の差

最後の行が、学び直しのいちばんの材料です。 90％点を超えた受注が特定の工程の組み合わせに偏っていれば、その工程の能力の表か、外注の日数の見積もりがずれているということです。