予防保全システム開発の進め方/やり方/流れや方法/手法/工程/手順

予防保全システム開発は、要件整理から定着までの6段階で進めます。重要設備を選び、台帳と点検を整えたうえで、現場で検証しながら段階的に広げると、故障前の保全につながります。

全体像は、予防保全システム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・予防保全システム開発の完全ガイド

予防保全システム開発の全体像

保全業務を中心に、設備台帳、作業記録、監視・連携をつなぐ予防保全システムの機能図。
日々の記録が監視や分析へ広がる構成です。

予防保全システムは、設備が壊れてから直す事後保全を減らすための業務基盤です。

このシステムでは、周期や状態に応じて、点検、部品交換、修理を計画します。

最初から高度なAIを目指すより、現場の判断と作業を記録し、そのデータを監視や分析へ広げるほうが現実的です。

予防保全・予知保全・CMMS・EAMの違い

予防保全と予知保全は作業を決める基準が、CMMSとEAMは扱う範囲が異なります。

  • 予防保全:稼働時間、使用回数、カレンダー、法定期限などの周期に基づいて作業する。
  • 予知保全:振動・温度・電流・圧力・音などから、異常の兆候や故障リスクを推定する。
  • CMMS:設備台帳、点検、作業指図、履歴、部品を管理する保全業務システム。
  • EAM:設備の取得から保全、更新、廃棄まで、資産のライフサイクルを扱う上位概念。

周期点検を電子化することも、予防保全システムの第一歩になります。ただし、故障履歴が少ない設備では、AIの学習データが足りず精度が出ないおそれがあります。そのため、まず異常時の担当者、作業期限、記録先を決めておきます。

最初に必要な機能

最初に必要な機能は、記録、設備管理、状態監視、他システムとの連携に分けて考えます。

  • 保全業務:台帳、点検計画、作業指図、修理・交換の履歴をまとめて扱う中核機能。
  • 設備台帳:拠点・ライン・装置・部品の階層と、型式・メーカー・設置日・保証期限・重要度の登録。
  • 作業記録:数値、写真、異常と原因、作業時間、交換部品、再発防止策を残す。
  • 現場機能:端末入力、部品在庫、承認、通知、KPI管理を現場で使う機能。
  • 監視・連携:センサーやPLCのデータを基盤、CMMS、現場端末へつなぎ、MES・ERP・SCADAとも結ぶ。

状態監視の基盤は、クラウドかオンプレミスから選びます。また、全連携を一度に必須にはせず、停止損失の大きい設備と必要なデータから始めます。

ポイント

導入の範囲は、停止損失の大きい設備から決めます。AIやセンサーを先に決めるより、現場の判断と作業を記録できるかどうかを基準に考えると、迷いにくくなります。

予防保全システム開発の進め方

予防保全システム開発が、要件整理・選定から設計・開発、テスト、稼働、定着へ進む流れ図。
各段階の完了条件を置いて順に進めます。

開発は、要件整理から定着までの6段階で進みます。

各段階で作る成果物と完了条件を先に決めておくと、次の段階へ進む条件がはっきりします。

現場、保全、生産技術、情シス、経営が合意し、次の段階の条件を明確にしておくと、予算の膨らみを抑えられます。

フェーズ1:要件整理で設備停止と保全業務を数値化

過去6〜12か月分の突発停止時間や故障件数、計画外保全費を確認します。点検漏れや部品欠品、復旧までの時間も調べます。

全台を対象にすると、台帳整備やセンサー設置が進まず、投資対象も広がります。そのため、安全・品質への影響、停止損失、代替生産の可否から設備の重要度を評価し、優先対象を1〜5台か1ラインに絞ります。

現状調査では、紙帳票、Excel、口頭連絡の伝達手段を一覧にします。保全ソフトに加え、PLCやSCADAなどの制御系、MESやERPなどの生産・基幹系も書き出します。そのうえで、設備コードと故障分類もそろえます。

点検項目や異常レベル、承認者と完了条件も、この段階で整理します。要件整理で残す成果物は、現状の保全手順や台帳の項目、課題、選定根拠など5種類です。

  • 業務フロー:現状の保全手順をまとめたもの
  • 台帳項目表:設備・部品ごとに登録する項目の一覧
  • 課題一覧:現場調査で見つかった課題の整理
  • 対象選定理由:設備を絞り込んだ根拠
  • KPI基準値:導入前の比較用の数値

要件はMUST、SHOULD、将来検討に分けておくと、優先順位を保ったまま機能追加を判断できます。

フェーズ2:業務適合性で製品・開発会社を選定

候補の方式を現場の業務に当てはめ、作業完了後の運用責任まで見比べます。

  • 候補方式:クラウドCMMS・EAM、オンプレミス型EAM、IoT個別開発、MES・ERPモジュール、センサーとSaaSの中から選ぶ。
  • 業務適合性:標準業務と設備固有の連携を、どの方式で実現するか。
  • デモ:実際の設備コードで、点検予定からKPI反映まで操作できるかを試す。
  • 機能・実績:設備業界、オフライン、QRコード、センサー・制御、API、ERP・MESへの対応。
  • 契約・運用:データ所有権、設計書、SLA、AI再学習費用、障害時の窓口と責任の取り決め。

標準業務はパッケージやクラウドに寄せ、設備固有の連携だけをAPIや個別開発で補うと、初期導入と拡張のバランスを取りやすくなります。

閉域網や低遅延、社内サーバーが必須であれば、オンプレミスも候補になります。

オンプレミスを選ぶ場合は、更新・脆弱性対応・バックアップを誰が担当するかと、製品ベンダーとSIerの間で、障害時の一次窓口と切り分けの責任をどう分けるかを確認します。

フェーズ3:設計・開発での現場作業の落とし込み

設計では、現場の判断から作業の完了までに必要な要素を具体的に決めていきます。

  • データと権限:設備の階層・コード、点検・判定、異常レベル、担当者を定める。承認、期限、部品、写真、履歴も決める。
  • 作業フロー:責任者が通知を確認して必要なら指図を出し、作業者が写真と数値を登録したうえで、責任者が承認する流れ。
  • センサー:対象、周期、位置、電源、通信を決める。ゲートウェイ、校正、交換、保存期間も定める。
  • AI運用:故障ラベル、正常データ量、誤報確認者、更新頻度、判断を覆した記録を用意する。
  • 成果物:基本・詳細設計、API仕様、権限一覧、運用手順、テスト計画。

紙帳票の項目をそのまま移すと、入力項目が増えすぎてしまいます。そのため、判断に必要な項目に絞り込み、既存のPLCやSCADAのデータを調べたうえで後付けセンサーを選びます。

フェーズ4:テストでのデータ・通知・現場運用の検証

画面の表示確認だけでなく、業務の一連の流れと現場の受入条件を検証します。

  • 業務シナリオ:台帳、周期点検、通知、作業指図の流れを一通り確かめる。部品引き当てや写真・履歴、承認、KPIまで含めます。
  • 例外ケース:通信断やセンサー欠損、重複通知、担当者不在を確かめる。期限超過、設備統廃合、ERP・MES停止も対象にする。
  • 現場入力:実機で、手袋をした状態や騒音のある場所、オフライン環境での操作を確かめる。
  • 通知と作業時間:通知を数分以内に理解できるか、完了までの時間を測れるかを見る。
  • AI・異常検知:検知率のほか、誤報率、確認工数、作業化率、安全手順で評価する。

フェーズ5:小さく始める稼働と安全な切り替え

本番は小さな範囲から始めます。そのうえで、移行と切り替えの条件を確認し、安全に稼働させます。

  • 対象範囲:重要設備1〜5台、または1ラインから始める。
  • データ移行:台帳と部品マスタを移し、欠けている履歴は「不明」として、移行日と信頼度を記録する。
  • 稼働判定:紙・Excelとの並行期間、切り戻し、障害連絡、復旧手順、権限責任者を決めておく。
  • 接続セキュリティ:IT・OT分離、最小権限、多要素認証、暗号化、ログ監視を要件に含める。
  • 継続運用:パッチやバックアップ、委託先・サプライチェーンについて、どこまでを誰が受け持つかを決める。

経済産業省のガイドラインは、工場の業務、保護対象、ゾーンを整理してから対策を立案する流れを示しています。

ガイドラインでは、運用後も対策を見直します(出典:経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Ver.1.1」)。

フェーズ6:定着後のKPIと改善会議による価値向上

月次会議では、導入前の基準値と比べながら、効果と現場の負荷を一緒に確かめます。

  • 保全KPI:MTBF(平均故障間隔)、MTTR(平均修復時間)、稼働率、計画外停止時間を追う。
  • 運用KPI:計画保全率、保全費、アラートから作業開始までの時間、点検入力率を見る。
  • 改善会議:保全リーダーが未完了の指図や繰り返す故障、部品欠品、通知過多、未入力項目を取り上げる。
  • 段階展開:点検周期や画面を見直したうえで、データがたまった設備から状態基準保全やAIへ進める。

古野電気の三木工場の事例では、エクサの公開事例として突発故障対応コストを3年間で約56%削減しました。

対象設備のMTTRについても、2019年から2022年に約20%短縮したと紹介されています(出典:株式会社エクサ「古野電気株式会社導入事例」)。

現場の保全リーダーを改善責任者とします。全設備へ一律に広げず、改善の効果と現場の負荷を見ながら対象を決めます。

ポイント

各段階で作る成果物と完了条件を先に決め、次の段階へ進む条件をそろえておくと、予算の膨らみを抑えやすくなります。迷ったときは、その段階の完了条件に照らして進めるかを決めます。

予防保全システムの費用相場とコストの内訳

クラウドCMMSから大規模・スクラッチ開発まで、導入方式ごとの初期費用目安を規模順に並べた図。
個別開発の規模に応じて費用幅が広がります。

費用は、設備・拠点・センサーの数や通信方式、データ移行で変わります。さらに、AI、ERP・MES連携、教育、保守、セキュリティの扱いによっても変わります。

なお、予防保全システム単独の公的統計は限られます。次の金額は、公開価格と類似するCMMSや業務システムの案件から整理した、企画段階の目安です。稟議では、対象設備と作業範囲を示したうえで、複数社の見積もりで金額を更新します。

導入パターン別の初期費用と期間の目安

導入方式ごとの費用と期間は、企画段階では次の幅を目安にします。

  • クラウドCMMS:初期0万〜30万円程度、月額3万〜20万円前後、数日〜数週間。
  • EMLink公開料金:月額料金の公開例があります。
  • 小規模個別開発・連携:300万〜700万円程度、2〜4か月程度。
  • 中規模CMMS・EAM:700万〜1,800万円程度、4〜9か月程度。
  • 大規模・スクラッチ開発:1,800万〜4,000万円以上、9〜18か月以上。

設備保全総合研究所のEMLinkは、1事業所あたり月額12万円、AI機能付きは月額21万円という公開情報があります。ただし、この金額はソフト利用料の例で、台帳整備、センサー、工事、個別連携、教育、保守は含まれません(出典:設備保全総合研究所 EMLink公式料金情報、2026年8月確認)。

複数工場や複雑な設備階層、データ移行、BI・AI、ERP・MES連携を含む大規模開発は、類似案件からの推定です。

IoT・AIのPoCは、重要設備数台から1ラインを対象に、センサー、ゲートウェイ、可視化、分析を含めて、300万〜800万円程度、3〜6か月程度が目安です。

見積もりで分けるべきコスト項目

初期費用とランニングコストは分けて考え、見積書では次の項目を確認します。

  • 企画・開発:調査、業務設計、画面・DB設計、アプリ、API連携。
  • 移行・導入:マスタと紙・Excelの履歴の移行、センサー・ゲートウェイ、工事、テスト、教育、安全手続き。
  • センサー・AI:本体価格、設置、配線、電源、校正、通信が対象です。交換やデータ整形、教師データ、モデル開発・評価・再学習、監視、誤報対応も含みます。
  • 運用:クラウド、ユーザー・拠点ライセンス、保存、通信、センサー交換が対象です。監視、ヘルプデスク、脆弱性対応、バックアップ、モデル再学習、追加開発も含みます。
  • AWS試算例:50センサー・50ゲートウェイなどの構成で、クラウド部分は月額159.84米ドル。

AWSの料金例は2024年3月6日時点で、センサー本体、設置工事、通信、アプリ開発、データ整備、保守を含みません(出典:AWS「IoT予知保全のためのクラウド構成と料金試算例」、2024年)。

公開試算をそのまま導入総額とはみなさず、自社の対象範囲で費用を積算します。そのうえで、初期費用と運用費の両方を比べます。

費用対効果の判断に使う停止損失と保全KPI

回収の判断では、設備停止の削減額に加えて保全費用も含め、導入前の基準値と比べます。

  • 対象費用:緊急出張、特急部品、廃棄、品質ロス、残業が対象です。さらに、熟練者の確認時間や法定点検漏れも含めます。
  • 試算条件:停止1時間の損失と年間停止時間を置き、仮の削減割合から保守・通信・センサー交換費を差し引いて算出する。
  • 効果確認:仮置きの削減割合を実績とは扱わず、PoCで検証して、導入後3・6・12か月で判定する。
  • 公開事例:KYB株式会社の導入事例も比較の材料になる。

KYB株式会社は、予知保全システムをクラウドネイティブに構築し、オンプレミス環境と比べてインフラの導入・運用コストを97%削減したと公表しています。この事例は、同社の構成と比較条件に基づくものです(出典:AWS「KYB株式会社」導入事例)。

ポイント

費用は、導入方式と対象範囲、初期費用と運用費の両方で比べます。公開された金額は類似案件からの目安なので、自社の対象範囲で積算し直してから判断します。

予防保全システムの見積もりを取るポイント

見積もりは、金額の安さだけでなく、開発範囲、自社の準備、導入後の運用担当を確認して比べます。とくに、業務設計や移行、教育、テストが別料金になっていると、予算が膨らみます。

RFPや依頼資料には、対象範囲、課題、データ、KPIを記載します。そのうえで、セキュリティ、希望時期、将来拡張も書き込むと、各社の提案条件をそろえやすくなります。

見積依頼前にそろえる資料

依頼の条件をそろえるため、現状の資料と第1段階の対象範囲を整理します。

  • 設備情報:拠点・ライン・設備・部品の一覧、重要度、点検周期・帳票、故障・修理履歴。
  • 既存環境:紙・Excel、既存システム、センサー・PLC・SCADA、ERP・MES連携の候補。
  • 可能であれば:年間停止時間、停止1時間の損失、担当者数、部品在庫、現場端末、ネットワーク制約。
  • 導入対象外:全工場、AI予測、24時間監視、外国語。法定帳票、部品購買、設計書の引き渡しの扱い。
  • 要件優先度:MUSTとWANTを分け、標準機能・追加開発・将来費用を比較する。

過去データに欠損があれば、その状態を明記しておきます。そうすると、各社が移行方法を同じ前提で比べられます。

開発会社を比較するときのチェックリスト

提案の実力、現場での使いやすさ、契約後の責任分担を一つずつ確認します。

  • 技術・業務実績:設備保全のヒアリング、端末・オフライン、IoT・制御、クラウド・オンプレミス。
  • 連携・運用実績:API、ERP・MES、セキュリティ、データ移行、運用教育。
  • 現場デモ:自社の設備コードや点検票で、異常の登録から完了まで操作してもらい、入力の秒数やタップ数を見る。
  • 契約条件:検収、品質保証、障害対応時間、データ所有・返却、サポートを確認する。さらに、更新、脆弱性対応、追加開発単価、AI再学習費も取り決める。
  • 工事・責任の範囲:センサー故障、工事可能な時間帯、作業時間、安全、切り戻しを見積もり、各社がどこまで受け持つかを示す。

一次請け、製品ベンダー、センサー会社の関係を図にすると、障害時の一次窓口がどこになるかを確かめられます。

失敗しやすい進め方と対策

失敗につながる要因と、PoCから段階展開までの対策を対応させて見ていきます。

  • センサー・AI先行:作業指図につながらない、故障ラベル不足で精度を検証できない。
  • データ・現場の不備:設備マスタの未整備、入力の形骸化、誤報の放置、ERP・MES連携の後回し。
  • 一括展開:全工場へ同時に広げず、重要設備を限定して始める。
  • PoCの評価:検知・誤報率、完了時間、計画保全率を見る。加えて、計画外停止、MTTR、保全費、入力率も確かめる。
  • 展開判断:3〜6か月で効果と負荷を測り、次のライン・拠点へ広げる条件を先に決める。

設備コードが拠点ごとに異なると、同じ装置の履歴を比べられず、KPIの信頼性も損なわれます。そのため、対策の第一歩は、台帳、周期点検、履歴、通知、作業指図を重要設備で運用することです。

ポイント

見積もりは、開発範囲、自社の準備、運用担当、別料金の項目がそろっているかで比べます。条件がそろわない見積もりは、金額の安さだけで判断しないようにします。

よくある質問(FAQ)

導入前によく寄せられる疑問に答えます。設備やデータの状態に合わせて、要件整理やベンダーへの質問に役立ててください。

Excelや紙の履歴しかなくても導入できますか?

導入はできます。過去の履歴をすべて完全に移す必要はありません。まず、設備コードと重要設備をそろえ、直近の履歴や故障の多い設備から移します。

欠損、不明、推定は区別して登録します。そのうえで、並行運用で入力ルールを定着させ、記録がたまってから状態監視やAI分析へ進むのが安全です。

小規模工場でもセンサーやAIを導入するべきですか?

導入範囲は、設備の故障リスクと運用準備を見て決めます。

  • 対象を絞る:全設備を対象にせず、停止損失や安全影響の大きい1〜5台、または1ラインに絞って試す。
  • PoCで確認:既存データ、後付けセンサーの安定性、アラート後の作業、現場入力を検証する。
  • 保全方法を選ぶ:周期点検と履歴管理だけで効果が出る場合もある。
  • 追加導入:運用と記録を整えたうえで、解決したい故障モードが明確な設備から、センサーやAIを加える。

クラウドとオンプレミスはどちらを選べばよいですか?

導入時期、ネットワーク、設備の安全運転、将来の拡張を含めて、方式を比べます。

  • クラウド:早期導入、複数拠点展開、更新、BCPを重視する場合に候補です。
  • オンプレミス:閉域網、厳格なデータ所在、低遅延を重視する場合に候補です。
  • エッジ処理:既存制御との分離を重視する場合に検討する。
  • 運用条件:OT・ITの接続点、障害時の安全運転、バックアップ、保守担当を比べる項目。
  • 拡張性:将来のセンサー増加も含め、自社の要件に合う構成を選ぶ。

予防保全システムの開発期間はどのくらいですか?

開発期間は、方式や連携範囲によって変わります。企画段階では、次の幅が目安です。

  • 標準クラウドCMMS:初期設定は数日〜数週間。
  • 小規模な個別開発:2〜4か月。
  • 中規模連携:4〜9か月程度。
  • 複数工場・AI・基幹連携:9〜18か月以上。

設備マスタの整備や受入テストを省くと、期間が短く見えても、本番後に手戻りが起きます。そのため、PoCと本番を分けて範囲を絞り、現場確認も含めて計画すると、現実的な納期につながります。

まとめ

予防保全システム開発では、故障リスクに優先順位を付けたうえで、点検、判断、作業、記録を一つの流れにまとめます。目的は、センサーやAIを増やすことではありません。

要件整理では停止損失と設備重要度を数値化し、選定では業務適合性を、設計では設備コードとワークフローを確認します。

テストでは現場運用を、稼働では小さな範囲を、定着ではKPIと改善会議を重視します。各段階で条件を決めてから進めます。

重要設備の台帳・履歴・点検からの着手

重要設備1〜5台、または1ラインを対象にし、台帳、周期点検、履歴、作業指図、月次KPIをデジタル化します。

運用とデータが整ったら、状態監視、アラート、部品在庫、ERP・MES連携、AI予測へと広げ、段階的に対象を増やします。

小さく検証して、効果と現場負荷を測ります。そのうえで次の展開条件を決めておくと、投資の妥当性を説明しやすくなります。

見積もりの総額・責任範囲・定着支援の比較

見積もりは、費用の内訳、比較条件、稼働後の支援までそろえて確認します。

  • 総費用:開発、マスタ整備、移行、センサー・工事、通信、クラウドを含める。連携、教育、保守、セキュリティ、AI再学習も見ておく。
  • 比較条件:公開価格や他社事例を自社の総額とみなさず、台帳、帳票、履歴、停止損失、希望KPIの条件をそろえる。
  • 運用支援:責任範囲と定着支援を確認し、現場で使い続けられ、改善データを残せる体制かを比べる。

▼全体ガイドの記事
・予防保全システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。