設備保全の「いつ手を打つか」が人によって変わる構造——予防保全の判断が属人化する理由と、生産技術OSで標準化できる範囲

Q: 紙の故障台帳や個人メモしか残っていない状態でも始められますか？

始められます。初期の数か月で過去の故障履歴や立ち上げノートを設備ID×部位×兆候で意味検索できる形に構造化し、その後に新規設備の保全フローへ織り込みます。突発停止の多い設備から始めます。

Q: AIが止める／止めないを自動で判断するのですか？

いいえ。エージェントが担うのは過去の故障モードや当時の判断、立ち上げ条件などの判断材料をそろえるまでで、止める／止めないの最終判断や安全に関わる線引き、4M変更の可否は人が握り続けます。

製造業の基礎知識

設備保全の「いつ手を打つか」が人によって変わる構造——予防保全の判断が属人化する理由と、生産技術OSで標準化できる範囲

製造DX編集部

2026年06月23日 08時00分

設備保全の「いつ手を打つか」が人によって変わる構造——予防保全の判断が属人化する理由と、生産技術OSで標準化できる範囲

設備保全の現場では、同じ設備の同じ異音を前にして、ある保全担当者は「次の定期点検まで持つ」と判断し、別の担当者は「今すぐ止める」と判断します。どちらも経験に裏打ちされた判断ですが、その根拠は本人の頭の中にあり、引き継がれません。予防保全（PM）の基準書はあっても、実際の「止める／止めない」の線引きは人によって変わる——これは多くの工場に共通する構造です。本記事では、設備保全の判断が属人化する理由を「人・プロセス・情報・ツール」の4つに分解し、生産技術OSという業務基盤でどこまで標準化でき、どこは人が握り続けるべきかを業務分解の視点で整理します。

保全判断が属人化する4つの理由

保全担当の一日は、朝の設備巡回から始まります。異音・振動・油温・電流値といった兆候を五感とハンディ計測器で拾い、TPMの自主保全チェックシートに記入し、気になった設備は段取り替えのタイミングを見計らって分解点検する。突発停止が起きれば、過去の故障台帳をめくり、ベテランに電話で聞き、復旧と再発防止を同時に走らせる——この繰り返しです。

このワークフローのどこで判断がばらつくのか。痛みを「人・プロセス・情報・ツール」の4つに分けると、原因が立体的に見えてきます。

人：「止める／止めない」の閾値が、担当者ごとの経験則に依存している。ベテランは過去のトラブルを身体で覚えているが、その判断軸は言語化されていない。
プロセス：予防保全の基準書は「3か月ごとにグリス交換」のような周期は定めても、「異音が出たらどう動くか」という劣化兆候への対応手順までは定義していないことが多い。
情報：過去の故障履歴、立ち上げ期に決めた段取り条件や初期Cpk、設備個別の癖が、故障台帳・立ち上げ報告書・個人のメモに散在している。逆引きに半日かかる。
ツール：設備管理パッケージやCMMSは保全の「記録」には強いが、「この兆候なら過去にどう判断したか」を業務として引き出す設計にはなっていない。

既存の解決策——熟練者の同行OJT、紙の故障台帳、設備管理パッケージへの記録蓄積——はいずれも一定の効果があります。しかし、判断の根拠を増やすのではなく記録を増やす方向に働くため、最後はベテランが現場に呼ばれる運用に戻り、属人化が再生産されます。引き継ぎを根性論で重ねるほど、この再生産は強まります。

「判断の自動化」ではなく「判断材料をそろえる工程」を切り出す

「判断の標準化」と聞くと、AIが止める／止めないを自動で決めるイメージを持たれるかもしれません。しかし設備保全で本当に効くのは、判断そのものの自動化ではなく、判断材料をそろえる工程の自動化です。ここを取り違えると、現場の納得を失います。まず、エージェントに任せてよい課題と、人が握り続けるべき課題を分けてみます。

図1：保全判断のビフォー・アフター。生産技術OSが変えるのは「判断材料をそろえる工程」で、最終判断は人が握る。

任せてよいのは「情報をそろえる」領域です。異音や振動の兆候に対し、同じ設備・同じ部位の過去の故障モード、そのとき誰がどう判断したか、立ち上げ期に決めた段取り条件や初期の工程能力指数（Cpk）を、数十秒で一覧に並べる。これは定型作業であり、人がやると半日かかります。一方で「止める／止めない」の最終判断、4M変更を伴う改造の可否、安全に関わる線引きは、人が握り続けるべき領域です。設備個別の文脈やその日の生産計画との兼ね合いは、現場の責任者しか統合できません。

この線引きを業務フローのビフォー・アフターで見ると、変わるのは判断の前段です。ビフォーは「異音を検知→故障台帳をめくる（30分）→立ち上げ報告書を探す（半日）→ベテランに電話→勘で判断→根拠は議事録に残らず、次の担当者がまたゼロから」。アフターは「異音を検知→兆候を入力→過去の類似故障3件と当時の判断、立ち上げ段取り条件を1分で提示→担当者が根拠を見て判断→判断と理由が次の参照対象として蓄積」。判断を奪うのではなく、判断に至る情報探索の往復をなくすのが要点です。

保全業務の作業	生産技術OSに載せる定型（支援できる）	人が握り続ける判断
劣化兆候の検知	巡回記録・計測値の集約と異常傾向の提示	五感で拾う違和感の最終確認
原因の照合	同一設備・部位の過去故障モードと立ち上げ条件の自動照合	今回の事象が過去事例と同型かの見極め
止める／止めないの判断	過去の判断と結果（突発停止/過剰保全）の提示	生産計画と安全を統合した最終決定
4M変更を伴う改造	関連FMEA・変更履歴の引き当て	可否と影響範囲の承認
判断の記録	判断と理由を構造化して次の参照対象に変換	記録すべき背景の取捨選択

表1：設備保全の作業を「定型として支援できる範囲」と「人が握る判断」に分けて棚卸しする。

ここで土台になるのが、設計・調達・品質・生産技術の業務を横断して動かす「業務OS」という考え方です。基幹システムの延長では、この横断が起きません。

理由は単純で、ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではないからです。
業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

なぜ既存の設備管理パッケージやMESでは足りないのか。これらは記録の台帳としては優秀でも、立ち上げ・保全・改善の3層を業務として横断させる設計にはなっていないからです。設備保全の判断材料は、保全の記録だけでなく、立ち上げ期の決定や設計のFMEAにまたがって存在します。保全台帳の中だけを探しても、判断の根拠は半分しか見つかりません。

MP情報(保全予防情報)が立ち上げ期の設計レビューに参照されない構造を、業務エージェント基盤で繋ぐのが生産技術OSの役割です。
生産技術OSとは——立ち上げ・保全・改善を統合する業務エージェント基盤

生産技術OSは、この分断された3層——立ち上げノート、保全ノート、改善ノート——を同じデータモデルに載せ、兆候を起点に横断参照できる状態をつくります。設備管理パッケージやMESを置き換えるのではなく、その上位で業務を動かすレイヤーと位置づけるのが現実的です。記録は下層に残しつつ、「この兆候のとき、過去はどう判断し、結果どうだったか」を業務として引き出す層を一段重ねる、という構図です。

設備保全の止める／止めない判断にかかる時間配分のイメージ。過去故障履歴の探索や立ち上げ条件の照合など情報をそろえる工程に時間が偏ることを示す横棒グラフ — 図2：保全判断にかかる時間は、情報を探す工程に偏りがち（イメージ）。ここが定型化の余地。

ROIの考え方も、削減時間だけで測ると本質を外します。保全判断の情報照合にかかる工数は確かに削れますが、より大きいのは「判断のばらつきが生む突発停止・過剰保全のコスト」です。早く止めすぎれば過剰保全で稼働率を落とし、遅らせれば突発停止で段取り替えと挽回生産のコストが乗る。判断の根拠がそろうことで、この振れ幅が縮むこと——これがROIの主項目です。金額に落とす前に、まず自社で「同じ兆候への判断が人によってどれだけ割れているか」を測ることをおすすめします。

属人化を「ベテランの引退で失われるリスク」とだけ捉えると、対策は技能伝承の研修に向かいがちです。研修は必要ですが、問題の半分は、引き継ぐべき情報がそもそも業務基盤に載っていないことにあります。人に貼り付いた知識を別の人へ移すより、業務基盤に判断材料を残すほうが、再現性のある引き継ぎになります。

引き継ぐべき情報をデータモデルとして握るかどうかは、属人化への姿勢の問題ではなく、業務基盤の設計判断です。
立ち上げと量産を分断する組織構造——生産技術と品質保証が引き継げない「現場知」の正体

自己診断：保全判断はどれだけ属人化しているか

次の5項目のうち3つ以上に当てはまる場合、判断材料を業務基盤にそろえる取り組みが効く可能性が高いと考えられます。

同じ設備の同じ兆候への「止める／止めない」判断が、担当者によって割れたことがある
突発停止の原因調査で、過去の故障履歴と立ち上げ条件の照合に半日以上かかったことがある
予防保全の基準書はあるが、「劣化兆候が出たときの対応」までは定義されていない
ベテラン保全員の引退・異動で、特定設備の判断が回らなくなる不安がある
立ち上げ期に決めた段取り条件や初期Cpkを、量産後の保全現場から参照できない

「設備管理パッケージがあるのに、なぜ別の基盤が要るのか」

この疑問はもっともです。CMMSや設備管理パッケージは、保全計画・作業実績・部品在庫の管理には確かに有効で、無理に置き換える必要はありません。合わないのは、立ち上げ期の決定や設計FMEAといった保全台帳の外にある情報まで、兆候を起点に横断参照したいケースです。記録が保全部門の中で完結していて、立ち上げ担当の異動やベテランの引退で情報が切れる実感がないなら、新しい基盤を重ねる優先度は高くありません。逆に、突発停止のたびに「あのとき誰が何を決めたか」を探し回っているなら、それは記録の不足ではなく、業務として情報を横断する仕組みの不在です。後者であれば、まず1台分の判断材料を横断参照できる状態をつくるところから検証する価値があります。