設備の故障の兆しを、点検記録と保全履歴から拾って優先度をつける

処理の起点を決める

毎月1日の深夜に、全設備を一括評価します。 保全担当が月初に優先度つきの一覧を受け取れる状態にします。

週次のトリガーも検討してください。 日常点検の自由記述に強い兆し（「異音が大きくなった」「油漏れ」）が現れたときは、月次を待たずに通知します。月次だけだと、最大で1か月の遅れが生じます。

故障が発生したときにも処理を走らせます。 その設備の直近3か月の記録を「故障前の記述」として登録し、以後の照合に使います。この登録がこの構成を育てます。

入力データを集める

「故障前の記述の蓄積」が、この構成でもっとも価値のあるデータです。

過去3年の故障履歴から、故障した設備について「故障の3か月前までに書かれた点検記録の自由記述」を抜き出します。月3〜6件の故障が3年分なら、100〜200件の事例になります。

この作業は過去データから作れます。 新しくデータを取る必要はありません。

法定の定期自主検査の記録も使ってください。 労働安全衛生法に基づく定期自主検査は、対象となる機械について1年を超えない期間ごとに実施し、記録を3年間保存することが定められています。 すでに3年分あるはずです。

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

保全管理システム： APIがあればAPIを、なければCSVエクスポートを使います。月1回の取得で足ります。

自由記述の抽出： 備考欄・所見欄のテキストを、設備番号と日付つきで取り出します。空欄が多いのが普通です。 記入率が2割を切るようなら、この構成の効果は限定的になります。

故障前の記述の作成： 故障履歴の各件について、その設備の故障日から遡って3か月分の自由記述を集めます。Pythonで機械的に作れます。

稼働時間： 生産管理システムの実績から算出します。取得できない設備は、「経過日数」で代用します。 稼働時間が取れないことを理由に、この構成を諦める必要はありません。

AIへ渡す前に整形する

1. 設備の分類 … 設備を「回転機」「搬送機」「熱源」「油圧機器」「その他」に分けます。故障の現れ方が違うため、同じ基準で評価できません
2. 同型機のグループ化 … 同じ機種・同じ導入年の設備をグループにします。同型機の故障間隔が、その設備の目安になります
3. 測定値の傾向の算出 … 直近6か月の推移から、傾向（上昇／横ばい／下降）と、しきい値までの余裕を計算します
4. 経過時間の算出 … 部品ごとに、前回交換からの経過時間・稼働時間を計算します
5. 自由記述の抽出と正規化 … 備考欄のテキストを集め、設備の呼び名の表記ゆれをそろえます
6. 法定検査の期限の算出 … 次回の期限までの残り日数を計算します

AIに処理させる

優先度の計算は、プログラムで行います。 次の要素を点数化して合計します。

「何点なら整備すべきか」は決めません。 点数は並べ替えのためのものであり、しきい値で自動判定はしません。

LLMにさせること：

「いつ壊れるか」を書かせないでください。 「残存寿命は約2か月です」という出力は、根拠がないうえ、外れたときに構成全体が信用されなくなります。

「整備すべき」という判断も書かせないでください。 整備の要否は、現場で状態を見て、部品の入手性と生産計画を踏まえて決めることです。

「応急処置で対応」の拾い出しは、実務で効きます。 恒久対策をしないまま運転を続けている設備は、記録を読まないと分かりません。

指示内容を固定する

あなたは、設備保全の担当者が見るべき設備を絞るのを支援する担当者です。
点検記録の自由記述から、異常の兆しを示す記述を拾ってください。

【厳守事項】
- 故障の時期を予測しないでください。
  「〇か月以内に故障する可能性があります」「残存寿命は〜」と書かないでください。
- 整備すべきかどうかを判断しないでください。
  「交換が必要です」「早急に対応してください」と書かないでください。
  記述に現れた事実と、過去の似た事例を示すだけにしてください。
- 記述にないことを補わないでください。
  「おそらく軸受の摩耗と思われます」のように原因を推測しないでください。
  記述された症状をそのまま扱ってください。
- 過去の故障前の記述と照合するときは、
  実際に故障した設備の記録と、その故障内容を similar_cases に示してください。
  「同様の経過をたどる可能性があります」と結論づけないでください。
- 記述の時系列の変化（悪化・改善・変化なし）は、
  各月の記述を並べて示してください。
  変化の度合いを数値化しないでください。
- 自由記述が空欄の月については、「記載なし」としてください。
  「異常なし」と解釈しないでください。**記入されていないことと、異常がないことは違います。**
- 確認事項は、保全担当が現場で実際にできることを書いてください。
  「詳細な診断を行ってください」ではなく
  「運転中に軸受部の音を聞き、前回の点検時と比べてください」と書いてください。
- 作業者の技量や対応の適否について記述しないでください。

【設備の情報】
設備番号: {equipment_id} / 機種: {model} / 導入年: {installed_year}
分類: {category} / 設置場所: {location}

【計算済みの指標】
{calculated_metrics}

【直近12か月の点検記録の自由記述（月ごと）】
{free_text_by_month}

【この設備の保全履歴（直近3年）】
{maintenance_history}

【過去に故障した設備の、故障前3か月の記述（同分類）】
{failure_precursor_cases}

「故障の時期を予測しないでください」の1行が、この構成の安全装置です。 これを書かないと、LLMは親切に「2〜3か月以内の故障が懸念されます」と書きます。その予測が外れると、保全担当は一覧を見なくなります。

「記載なしと異常なしは違う」の指示は、実務で重要です。 点検記録の備考欄は、多くの月で空欄です。空欄を「異常なし」と解釈すると、記入されなかっただけの設備が安全側に評価されます。

出力形式を固定する

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

{
  "equipment_id": "",
  "model": "",
  "category": "",
  "priority_score": 0,
  "score_breakdown": {
    "parts_age_ratio": 0.0,
    "vs_same_model_mtbf": 0.0,
    "measurement_trend": "worsening | flat | improving | no_data",
    "margin_to_threshold": 0.0,
    "statutory_inspection_days_left": 0,
    "production_impact": "high | medium | low",
    "failure_count_3y": 0
  },
  "parts_status": [
    {
      "part": "",
      "last_replaced": "",
      "recommended_interval": "",
      "elapsed_ratio": 0.0
    }
  ],
  "measurement_history": []
}

LLM部分の出力：

{
  "equipment_id": "",
  "findings": [
    {
      "month": "",
      "quoted_text": "",
      "symptom_type": "noise | vibration | leak | heat | play | other",
      "record_status": "written | not_written"
    }
  ],
  "trend_in_text": "worsening | unchanged | improving | insufficient_records",
  "similar_cases": [
    {
      "equipment_id": "",
      "failure_date": "",
      "failure_part": "",
      "precursor_text": "",
      "months_before_failure": 0
    }
  ],
  "temporary_fix_records": [],
  "check_points": [],
  "needs_review": []
}

quoted_text（記録の原文）を必ず残します。 「異音の記載あり」と要約されると、保全担当はどの程度の異音かを判断できません。

record_status: not_written（記載なし）を明示的に持ちます。 「異常なし」と区別するためです。

similar_cases には、実際に故障した設備の記録を示します。 「似た記述の後に、この設備ではこの部位が故障した」という事実だけを並べ、同じことが起きるとは書きません。

check_points は、現場で何を見ればよいかです。ここが具体的であるほど、この構成は使われます。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-16時点ではベータ機能として提供）。420台ぶんを機械処理するため、利用できると安全です。

システムへ連携する

整備計画への自動反映はしません。 部品の手配、ラインの停止調整、作業者の確保が伴うため、人が決めて計画に入れます。

故障発生時の「故障前の記述」の登録は自動化してください。 これを人手に任せると、忙しい復旧対応の中で必ず忘れられます。この登録が止まると、この構成は育たなくなります。

人が確認する

上位の設備を保全担当が現場で確認します。

no_data が多い設備を放置しないでください。 測定値が記録されていない設備は、この構成では評価できません。評価できないことを「問題なし」と読まないでください。

現場で見た結果を必ず記録してください。 「上位に挙がったが、見たところ問題なかった」という記録が、優先度の計算を見直す材料になります。

例外に対処する

記録を残す

• 月次の評価結果（score_breakdown を含む全項目）
• LLMが拾った記述と、その原文
• 過去の故障前の記述との照合結果
• 保全担当が現場で確認した結果（問題あり／なし、その内容）
• 整備した内容と日付
• 故障の発生と、その前3か月の記録
• 上位に挙がらなかったのに故障した設備の記録

最後の項目が、この構成を改善する唯一の材料です。 見落とした故障について「記録に兆しがあったのに拾えなかった」のか「記録に何もなかった」のかを分けると、次に何を直すべきかが決まります。

• 前者なら、照合の仕組みを直す
• 後者なら、点検の項目か記録の運用を直す

「保全担当が現場で確認した結果」も必ず残してください。 上位20台のうち何台が実際に整備を要したかが、この構成の精度そのものです。