プレス機の荷重・振動・温度の稼働ログと保全記録から、故障が近い設備を予測して点検の優先順位を出す

処理の起点を決める

集計は毎日5時、順位づけは毎週月曜日5時に動かします。 工場のサーバーのタスクの予定実行で Python のスクリプトを起動します。集計を毎日にするのは、1週間分を月曜日にまとめて読むと、ショットの値の量が大きく、始業に間に合わないことがあるためです。

順位を週1回にするのは、保全の段取りが週単位で組まれているからです。 点検には生産を止める時間が要り、その枠は前の週に生産管理と決めています。毎日順位が入れ替わると、組んだ点検の枠と合わなくなります。

例外として、規則で inspect_now になった台は、毎日の集計の時点で保全課のチャットに知らせます。 月曜日を待ちません。

入力データを集める

質を決めるのは、段取りの記録と保全の作業履歴です。 段取りの記録が無いと、荷重を金型ごとに見られません。保全の作業履歴の区分が「突発故障」と「計画点検」で分かれていないと、何を当てればよいかが決まりません。

生産への影響の区分は、保全課と生産管理で先に決めます。 後ろの工程が1本しかない製品を作る台、代わりの台が無い大型の台は「高」です。同じ見込みでも、止まったときの影響が違えば、点検の順番は変わります。

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

ファイルは読み終えたら処理済みのフォルダへ移します。 移すのは集計が成功したときだけにします。共有フォルダに残っているファイルの数が、そのまま未処理の数になります。

時刻のそろえ方を先に決めておきます。 荷重計の記録装置と振動・温度の収集装置は、それぞれ自分の時計で時刻を付けています。数分ずれていると、段取りの直後のショットが前の金型の区間に入ります。 取り込むときに装置ごとの時計のずれを表で持ち、段取りの記録の時刻に合わせて補正します。同じファイルが二度書き出されたときは、台・時刻・ショットの番号が同じ行を1つにまとめます。

保全管理の仕組みからは、読み取りだけを行います。 作業履歴の書き出しを毎日取り込み、この構成から保全管理の仕組みへ書き込むことはしません。点検の結果は、人が保全管理の仕組みに記録したものを次の日に読み直します。

AIへ渡す前に整形する

1. 段取りの区間に切る … ショットの値を、段取りの記録の「載せた時刻〜降ろした時刻」で金型に結びつけます。どの金型にも入らないショットは試し打ちとして外します
2. 段取り直後を外す … 金型を載せた後の最初の30分は、高さの調整で荷重が揺れます。この区間を代表値に入れません
3. 日ごとの代表値にする … 台・金型・日ごとに、最大荷重の中央値と上位5％の値、左右の荷重の差の中央値を出します。振動と温度は稼働中の時間だけで中央値と最大値を出します
4. 金型ごとの基準を作る … 金型ごとに、故障の無かった過去90日の代表値の中央値と幅を持ち、その日の値が基準からどれだけずれたかを出します
5. 増え方を出す … 振動・温度・荷重のずれについて、7日と28日の増え方を出します
6. 欠けを印にする … センサーの値が無い日は欠けたまま渡し、欠けた時間の割合を別の列に持ちます
7. 答えを付ける … 学ぶときだけ、その日から14日以内に「突発故障」の作業履歴がある日を1にします

1番目と2番目を軽く見ないでください。 段取りの直後と試し打ちの荷重を混ぜると、金型の交換が多い台ほど「荷重が荒れている」と見えます。 機械の傷みではなく、段取りの多さを当てるモデルになります。

7番目の答えには、計画点検と予防交換を入れません。 計画どおりに止めた日を「故障」として学ぶと、点検の予定を当てるだけのモデルになります。

AIに処理させる

させるのは、規則で inspect_now にならなかった台について、14日以内に故障で止まる見込みを出すことだけです。

左右の荷重の差を入れるのは、偏った摩耗がまず左右の差に出ることが多いためです。 合計の荷重が変わらなくても、左右の差が金型ごとの基準から開いていく台があります。

「過去の故障の数」には、同じ部位の故障だけを数えます。 違う部位の故障まで数えると、故障の多い古い台が、今の値に関係なく上位に並び続けます。

学び直しは月1回です。 前の月までの記録で学び直し、TimeSeriesSplit で検証してから入れ替えます。TimeSeriesSplit は、前の期間で学び後の期間で試す分け方を繰り返すもので、普通の分け方だと未来の記録で学んで過去を試すことになるためです。

4行目は、最初に保全課の全員で確かめてください。 動力プレスには、1年以内ごとに1回の定期自主検査（特定自主検査）と、その日の作業を始める前の点検が決められています。順位の低い台でも、これらの点検を省いてよいことにはなりません。 この構成が受け持つのは、その間の週ごとの点検の順番です。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、集計・規則・モデルの設定を書いておきます。

【集計】
- 単位：台 × 金型 × 日
- 段取りの記録で金型に結びつかないショットは外す（試し打ち）
- 金型を載せてから 30 分のショットは外す
- 荷重：最大荷重の中央値、上位 5％の値、左右の差の中央値
- 振動・温度：稼働中の時間の中央値と最大値
- 金型の基準：突発故障の前後 14 日を除いた過去 90 日の中央値と、
  四分位の幅（上位 25％ − 下位 25％）
- ずれ = （その日の値 − 基準の中央値）÷ 基準の幅

【規則（inspect_now）】
- 温度の最大値が、その位置の上限を超えた
- 振動の最大値が、その位置の警報の値を超えた
- 2 つ以上の位置で、振動の 7 日の増え方が過去 1 年の上位 1％に入った

【モデル】
- HistGradientBoostingClassifier(class_weight="balanced")
- 答え = その日から 14 日以内に「突発故障」の作業履歴があれば 1
  （計画点検・予防交換は 0。段取りの不具合・金型の破損も 0）
- categorical_features = ["機種"]
- 欠けた値は埋めずに渡す。欠けた時間の割合を別の列で渡す
- 検証：TimeSeriesSplit(n_splits=5, gap=14)
  （答えが 14 日先を見るので、学ぶ期間と試す期間の間を 14 日空ける）

【優先順位】
- 順位の点 = predict_proba の 1 の確率 × 生産への影響の重み（高 3 ／ 中 2 ／ 低 1）
- 一覧に出すのは inspect_now と、点の上位 10 台
- 3 日以上記録が届いていない台は stale として別に並べる

gap=14 を付けないと、検証の当たり方が実際より良く見えます。 答えが14日先の故障を見ているので、学ぶ期間の最後の14日の答えには、試す期間の故障の情報が入っています。TimeSeriesSplit の gap は、学ぶ期間の終わりから試す期間の前までの記録を外す指定で、この重なりを切るために使います。

「金型の破損を0にする」を明記しないと、金型の不具合で止まった日も故障として学びます。 金型の破損は機械の傷みとは別の原因で、金型の保全の担当が受け持つものです。 混ぜると、壊れやすい金型を載せる台が上位に並びます。

基準を作るときに故障の前後14日を除くのは、傷んでいく途中の値を「正常」に入れないためです。

出力形式を固定する

台ごとに、次の形のJSONを作り、一覧と通知にします。

{
  "press_id": "",
  "week": "",
  "verdict": "inspect_now | ranked | low_history | stale",
  "fail_prob_14d": 0.0,
  "priority_score": 0.0,
  "impact_class": "high | mid | low",
  "signals": [
    { "name": "", "die_id": "", "value_now": 0, "baseline": 0,
      "deviation": 0, "delta_7d": 0, "delta_28d": 0 }
  ],
  "missing_ratio": 0.0,
  "last_record": "",
  "model_version": ""
}

1つ目の理由は、verdict で規則とモデルを分けて見せられることです。 inspect_now は規則が出したもので確率は付かず、ranked はモデルの見込みです。担当者は、どちらの理由で一覧に出たかを最初に分かります。

2つ目は、signals に金型と基準を並べられることです。 荷重のずれが大きいと出ても、それがどの金型のときの値かが分からないと判断できません。die_id と baseline があれば、金型を替えたせいか機械のせいかを一覧の上で確かめられます。

3つ目は、missing_ratio と stale で値の古さを分けられることです。 見込みが低いのか、値が届いていないだけなのかを取り違えないためです。センサーが止まっている台は、見込みが低く出やすくなります。

一覧は、inspect_now を先頭に、ranked を点の高い順に並べ、stale と low_history を末尾にまとめます。

システムへ連携する

プレス機の制御と、収集装置の設定には触れません。 読むのは書き出されたファイルだけで、スクリプトに収集装置へ書き込む権限を持たせません。

保全管理の仕組みにも書き込みません。 点検の依頼は、一覧を見た担当者が保全管理の仕組みで起こします。この構成から作業の依頼を自動で起こすと、点検の枠を誰も見ないまま依頼が積み上がります。

人が確認する

人が見るのは、inspect_now と上位10台だけです。 60台の全部のグラフを開く設計にすると、第10章の20.0時間には収まりません。

1. inspect_now を先に見る … 規則で挙がった台です。温度のセンサーの故障で値が跳ねただけのこともあるので、他の位置の値と並べて確かめます
2. 上位10台の signals を読む … どの金型のときに、どの値が基準からどれだけずれ、7日・28日でどう増えたかを見ます
3. 生産計画と点検の枠を照らす … 今週その台が何を作るか、止められる時間があるかを見て、点検する台と順番を決めます
4. stale を確かめる … 記録が届いていない台は、センサーか書き出しの不具合です。見込みが無いのではなく、見えていないだけです
5. 順位を覆したら記録する … 上位の台を点検しない、下位の台を先に見る、と決めたときは理由を残します

点検の結果は、決まった区分で記録してもらいます。 「異常なし」「摩耗あり（処置せず）」「摩耗あり（交換）」「別の部位に異常」のどれかを選び、部位を添えます。自由記述だけだと、次の学び直しで答えに使えません。 点検して異常が無かった台も、記録が残ることで「挙がったが問題の無かった台」として役に立ちます。

5番目を省かないでください。 覆した理由がたまると、モデルが見ていない事情（部品の在庫、金型の予定）が分かり、次に足す材料になります。

目標は、60台をならして1台5分です。 上位10台と inspect_now は数分ずつかけ、残りは一覧で見込みと増え方を流し見ます。

例外に対処する

上から5行目までが大半を占めます。 どれもモデルの問題ではなく、記録の取り方と段取りの記録の問題です。 直すほうが、モデルを作り直すより効きます。

最後の行は、学び直しを自動で入れ替えないための決まりです。 新しいモデルの検証の成績が前のモデルより下がったら、人が理由を見てから入れ替えます。

記録を残す

• 毎日の集計の結果（台・金型・日ごとの代表値、基準、ずれ、増え方）
• 毎週の見込みと順位の一覧（verdict、fail_prob_14d、signals）と、そのときのモデルの版
• 規則の閾値の表の版
• 人が順位を覆した記録 … どの台を、どちらに変えたか、理由
• 点検の結果（異常あり・なし、部位、処置）と、その台の直前の順位
• 学び直しのたびの検証の成績

2つ目で「モデルの版」を残すのは、学び直しで見込みが変わるためです。 後で突発で止まった台について、その週にどの版のモデルが何位を出していたかが分からないと、見落としの理由をたどれません。

5つ目は、構成の当たり方を測る材料になります。 上位10台を点検して異常が見つかった割合と、順位の外から突発で止まった台の数を毎月数えます。