部品ごとの発注・納期回答・仕入先の遅れの実績から来月に欠品しそうな部品を見込み、確かめる仕入先と代わりの手配の案を購買担当に示す

処理の起点を決める

毎月10日の夜に、来月分をまとめて見込みます。 来月の所要量は月の前半に確定し、仕入先の納期回答も、来月の入荷分はこのころまでにおおむね出そろいます。10日に出せば、確かめて代わりの手配を考える時間が3週間ほど残ります。 これより遅いと、別の仕入先からの取り寄せが間に合わない部品が増えます。

月の後半にもう一度、変わった明細だけを見込み直します。 毎月25日の夜に、10日から後に納期回答が変わった明細と、所要量が増えた部品だけを対象にします。回答の変更そのものが、遅れの強い兆しだからです。 全件をやり直すと一覧の順位が大きく動き、購買担当がどこまで確かめたかが分からなくなります。

毎月の初めに、前の月に入荷を予定していた明細で答え合わせをします。 見込んだ確率と実際に遅れたかどうかを並べ、確率の帯ごとの実際の遅れの割合を出します。モデルの学び直しは四半期に一度と、仕入先が大きく入れ替わったときにします。

入力データを集める

質を決めるのは、納期回答の履歴です。 最後の回答の日付しか残っていなければ、「回答を2回変えてきた」という一番強い兆しが使えません。生産管理システムが回答の上書きの履歴を持っていない場合は、回答を入れるたびに別の表へ1行ずつ残す運用から始めます。 半年分たまれば、学習に使えます。

部品マスタの代替品と第二の仕入先も外せません。 代わりの手配の案はここから作ります。マスタに無い代替品をこの構成が考え出すことはありません。 品質保証の承認を経ていない部品を候補に出さないためです。

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

生産管理システムからは、毎晩CSVで書き出したものを読みます。 読み取り専用のデータベースの口があればそちらでも構いませんが、本番のデータベースへ直接つなぐのは避けます。 毎月10日と25日の夜に動くので、その日の夜の書き出しが終わってから始めます。

学習のデータは、見込む時点に戻して作ります。 過去の明細について、入荷の予定の前の月の10日の時点で分かっていた情報だけで特徴を作り直します。その日より後に回答が変わった回数を入れると、見込むときには分からない情報で学習することになり、検証では当たるのに本番で外れます。

仕入先の直近の遅れの割合も、同じく時点に戻して数えます。 「その時点から見て過去6か月に、その仕入先の明細が5稼働日以上遅れた割合」を、学習の明細ごとに計算し直します。今の割合を過去の明細に付けると、結果を知ったうえで学ぶことになります。

AIへ渡す前に整形する

1. 遅れを稼働日で数える … 最後の回答の日付から入荷日までを、自社のカレンダーの稼働日で数えます。暦の日数で数えると、連休をまたいだ明細だけが遅れて見えます
2. ラベルを決める … 5稼働日以上遅れた明細を1、それ以外を0とします。分けて届いた明細は、必要な数量の8割が届いた日を入荷日とします
3. 回答の特徴を作る … 回答の変更の回数、最初の回答から最後の回答までのずれ、発注から最初の回答までの日数、回答が無いまま希望の納期に近づいているか
4. 仕入先の特徴を作る … 過去6か月の遅れの割合、明細の件数、同じ月に抱えている自社の発注の数
5. 時期の特徴を作る … 入荷の予定が月末か、仕入先の大型連休の前後か、年度末か
6. 取り消した発注を外す … 自社の都合で取り消した明細と、納期を自社から後ろへずらした明細は、遅れとして数えません

2番目の「5稼働日」は、購買課と生産管理課で決める値です。 1日の遅れでも欠品になる部品はありますが、1日のずれまで遅れとして学ばせると、運送の都合のような偶然の分が増えて、仕入先の遅れ方が見えにくくなります。 何日の遅れで欠品するかは、次の在庫の余裕の計算で部品ごとに見ます。

6番目を省くと、自社の都合で後ろへずらした明細が、仕入先の遅れとして残ります。 生産の計画が変わって「入荷を2週間待ってほしい」と頼んだ明細は、変更の履歴に自社からの依頼の印を付け、学習から外します。

AIに処理させる

この構成の「AI」は、明細ごとの「5稼働日以上遅れて届く確率」の見込みだけです。 在庫の余裕、欠品のおそれの順位、代わりの手配の候補は、決まった計算と部品マスタから出します。

見込みには、LightGBM の objective="binary" を使います。 遅れる明細は全体の1割から2割程度と想定されるので、偏りの手当てとして scale_pos_weight を使います。is_unbalance と同時には使えないので、どちらか一方に決めて設定ファイルに書いておきます。 評価の指標は auc と average_precision を並べて見ます。順位の良さと、上位の当たり具合を別々に見るためです。

確率は、scikit-learn の CalibratedClassifierCV で較正します。 方法は sigmoid です。欠品のおそれの順位は「確率 × 余裕を超える遅れの見込み」で作るので、確率の目盛りがずれていると、順位そのものがずれます。 「30％」と出た明細が、実際に10件に3件くらい遅れているかを、答え合わせで毎月確かめます。

検証は時間の順で分けます。 scikit-learn の TimeSeriesSplit は、未来のデータで学習して過去を評価しないための分け方で、k番目の分割では前のk個の区切りで学び、次の区切りで評価します。ただしサンプルが等しい間隔で並んでいることを前提にしています。 発注の明細は月によって件数がばらつくので、この構成では入荷の予定の月で区切って、前の月までで学習し次の月で検証する分け方を自前で作ります。

在庫の余裕は、次の計算で出します。 部品ごとに、来月の日ごとの所要量を在庫と先に届く入荷から順に引いていき、その明細が届かなかったら何日目に安全在庫を割るかを数えます。その日数から入荷の予定日を引いたものが「余裕の稼働日」です。余裕が5稼働日未満の部品は、遅れの確率が低くても一覧の上に寄せます。

1行目がいちばん起きやすい失敗です。 順位が出ると、上から順に機械的に電話したくなります。仕入先が自社の大口の取引先でもある場合や、先週すでに話している場合は、確かめ方を変える必要があります。 順位は確かめる候補であって、問い合わせの指示ではありません。

指示内容を固定する

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

# 部品の欠品のおそれの見込みの設定（shortage_risk.yaml）

対象: 来月に入荷を予定している発注の明細（自社の都合で取り消したものを除く）
単位: 稼働日（自社のカレンダー。仕入先の大型連休は別の表）

ラベル:
  遅れ: 最後の回答の日付から5稼働日以上あとに入荷（分納は必要数の8割が届いた日）
  除外: 自社の依頼で納期を後ろへずらした明細

特徴:
  - 仕入先, 部品区分, 数量, 発注から希望の納期までの稼働日数
  - 回答の変更の回数, 最初の回答から最後の回答までのずれ, 発注から最初の回答までの日数
  - 仕入先の過去6か月の遅れの割合, 仕入先の明細の件数（見込む時点に戻して数える）
  - 入荷の予定が月末か, 仕入先の大型連休の前後か, 年度末か

見込み:
  モデル: {objective: binary, scale_pos_weight: 学習のデータの比から決める}
  較正: CalibratedClassifierCV（method: sigmoid）
  理由: pred_contrib の上位3つ（最後の列の期待値は使わない）
  学び直し: 四半期ごと（1月・4月・7月・10月）と、仕入先の大きな入れ替えのあと
  検証: 入荷の予定の月で区切る。前の月までで学び、次の月で確かめる
  評価: auc, average_precision, 確率の帯ごとの実際の遅れの割合

欠品のおそれ:
  余裕の稼働日: その明細が届かないときに安全在庫を割る日 − 入荷の予定日
  順位の値: 遅れの確率 × （余裕の稼働日が5未満なら1.0、5以上10未満なら0.5、10以上なら0.1）
  一覧に出す: 順位の値の上位60件と、余裕の稼働日が0以下の明細の全件

代わりの手配の候補（部品マスタにあるものだけ）:
  - 他の倉庫の在庫（移せる数量）
  - 承認済みの代替品（在庫と発注残）
  - 第二の仕入先（過去の発注の有無と、最後の発注の日）

守ること:
  - 部品マスタに無い代替品・仕入先を候補に出さない
  - 仕入先の過去の遅れの割合を、学習の範囲を超えて言葉で評価しない（「遅れがちな仕入先」などと書かない）
  - 明細の件数が10件未満の仕入先は「実績が少ない」の印を付ける
  - 結果を生産管理システムの発注や納期の欄に書き込まない

「実績が少ない仕入先に印を付ける」は、新しく取引を始めた仕入先への備えです。 過去の明細が数件しかないと、たまたま1回遅れただけで遅れの割合が高く出ます。印を見た購買担当が、数字ではなく取引を始めたときの話を思い出せるようにします。

出力形式を固定する

明細ごとに、次の形のJSONと、それを一覧にした表で出します。

{
  "run_id": "SR-2026-10-10",
  "model_version": "sr-2026Q4",
  "po_line": { "po_no": "P-2026-08-1123-02", "part_no": "", "supplier": "", "qty": 0 },
  "promised_date": "2026-11-12",
  "late_probability": 0.00,
  "slack_workdays": 0,
  "risk_score": 0.00,
  "reasons": [
    { "feature": "answer_change_count", "label": "回答の変更が2回", "contribution": 0.00 }
  ],
  "alternatives": [
    { "type": "other_warehouse | approved_substitute | second_supplier", "detail": "", "qty_available": 0 }
  ],
  "flags": ["few_records"],
  "buyer_decision": { "action": "", "contacted_at": "", "result": "", "reason": "" }
}

late_probability から alternatives までは Python が埋め、buyer_decision は購買担当が書きます。

1つ目の理由は、見込みと人の判断を同じ記録に並べられることです。 翌月の答え合わせで、確かめなかった明細が遅れたのか、確かめて手を打った明細が間に合ったのかを分けて数えられます。手を打って間に合った明細を「遅れなかった」と数えると、次の学習で仕入先の遅れ方が実際より良く見えます。

2つ目は、reasons の label で問い合わせの切り口が決まることです。 「回答の変更が2回」なら変更の理由を、「月末の入荷」なら出荷の締めの日を、最初に聞けます。

仕入先ごとに、確かめる明細を次の表にまとめます。

システムへ連携する

生産管理システムへは書き込みません。 回答の納期を見込みで書き換えると、所要量の計算が見込みで動き、別の部品の発注まで自動で前倒しされます。 見込みはあくまで横に置く一覧です。

判断の記録は、購買担当が書く表に分けます。 生産管理システムの備考の欄に書くと、後から集めるのが手間です。明細の番号で一覧と結び付く形で残し、翌月の答え合わせで読み込みます。

人が確認する

購買担当は、一覧の上から順に、仕入先ごとの表で確かめます。 全件を開く必要はありません。

1. 余裕の稼働日が0以下の明細を先に見る … 回答どおりに届いても欠品する明細です。仕入先への問い合わせより先に、所要量と在庫の数字を確かめます
2. 上位の明細の理由を読む … reasons を読み、知っている事情と照らします。先週すでに話した仕入先は、確かめたことを記録して順位を下げてよい
3. 仕入先へ問い合わせる … 仕入先ごとの表で1社1回にまとめます
4. 遅れが分かったら代わりの手配を選ぶ … 候補から実際の手を選び、生産管理課と相談します。発注の振り替えと割増の運賃は、購買課長の承認を経ます
5. 判断を記録する … 何をしたか、仕入先が何と答えたかを buyer_decision に書きます

目標は、240件をならして1件6分です。 上位の明細は問い合わせと代わりの手配の検討で10分以上かかり、下位の明細は一覧で流し見て数十秒です。

例外に対処する

2行目を「確率0」として扱わないことが大事です。 回答が無いこと自体が遅れの兆しで、機械が分からない明細ほど人が先に見るべきです。

最後の行は、過去の遅れ方からは分からない出来事です。 災害や大きな事故の知らせが入ったら、その仕入先の明細はモデルの順位を使わずに、購買担当が全件を確かめます。

記録を残す

• 実行の日時、使ったモデルの版、読み込んだCSVの件数
• 明細ごとの特徴の値、遅れの確率（較正の前と後）、余裕の稼働日、順位の値
• 明細ごとの理由の上位3つと、pred_contrib の値
• 購買担当の判断 … 確かめたか、順位を動かしたか、その理由、仕入先の答え、取った手
• 翌月の入荷の実績と、答え合わせの結果（確率の帯ごとの実際の遅れの割合）
• 学び直しの日時と、そのときの検証の指標

購買担当の判断の記録は、モデルの答え合わせに欠かせません。 確かめて手を打った明細は、手を打たなければ遅れていたのかもしれません。手を打った明細を学習のラベルから外すかどうかを、記録を見て決めます。