予防保全システム開発の発注/外注/依頼/委託方法について

予防保全システムの発注は、設備と履歴の整理、RFPでの要件共有、段階導入の順に進めると、現場で使える保全業務につながります。

発注形態から委託先の選び方まで、順に見ていきます。全体像は、下の完全ガイドもご覧ください。

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

予防保全システムの発注前に整理すべき全体像

設備台帳を土台に点検・修理履歴と作業指図を重ね、上段に異常検知とAIを置いた4層図。
履歴を蓄積してから監視機能を広げる構成です。

予防保全システムは、故障する前に点検や部品交換を計画し、作業履歴を蓄積する仕組みです。発注するときは、異常を検知したあとに誰が判断し、いつまでに作業し、結果をどこに記録するかを、あらかじめ決めておきます。

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

予防保全は、時間や稼働時間、使用回数などの周期を基準に点検や交換を行う考え方です。一方、予知保全は、状態データ(振動・温度・電流・圧力)から異常の兆候を推定します。

CMMSは、設備台帳と作業指図、点検履歴、部品在庫を管理する業務システムです。EAMは、設備資産のライフサイクルや調達・原価まで含む、より広い管理の考え方です。

進め方としては、まずCMMSの基本機能を整え、故障履歴が蓄積してから予知保全やAIを追加する順番が現実的です。

発注範囲に含める機能

発注範囲には、設備台帳と親子階層、点検計画を含めます。さらに、作業指図や点検・修理履歴も入れます。写真や数値の登録、権限管理、検索・集計は、最低限そろえておきたい機能です。

  • 現場機能:部品在庫、QRコード、モバイル端末、オフライン入力
  • 既存システム連携:PLC・SCADA・MES・ERPとの接続
  • センサー導入:通信方式、設置工事、ゲートウェイ、電源、保守、保存期間

発注側は、現場課題と投資効果を見て優先順位を付けます。そのうえで、センサー関連の項目は、RFPに個別に記載します。

ポイント

迷ったときは、台帳・点検・履歴・作業指図を含む基本機能を発注範囲に入れ、予知保全やAIは履歴がたまってから追加する順で考えます。

発注形態の選び方(クラウド・パッケージ・個別開発)

発注形態は、業務を標準化できるか、既存設備や基幹システムと接続できるか、自社で運用できるかで比べます。最初に一つへ絞るより、標準機能で満たせる範囲と個別対応が必要な範囲を切り分けて考えます。

クラウドCMMSが向くケース

点検計画や台帳、履歴、作業指図を早く始めたい場合は、クラウドCMMSが候補になります。サーバーの調達や更新の負担を抑えられるうえ、1拠点で試してから他拠点へ展開しやすいのが利点です。

  • 接続・保管:工場の閉域網、データの保管場所、認証方式
  • 障害対応:外部連携APIと障害時の復旧目標
  • 追加料金:初期設定、データ移行、教育、センサー接続

発注側は、クラウド料金に含まれる範囲を確認します。別料金になる作業は、見積もりに反映させます。

パッケージ導入と個別開発を組み合わせるケース

設備階層や作業指図はパッケージで導入し、独自の設備コード、特殊な点検帳票、MES・ERP連携だけを追加開発する形にすると、費用と柔軟性のバランスを取りやすくなります。

標準機能を大幅に改修すると、更新時の検証費用やベンダーロックインが増えます。そのため、標準機能に合わせる業務と、安全や競争力に関わるため変えられない業務を、RFPで明示します。

スクラッチ開発やPoCが適するケース

複数工場の設備階層や権限を統合する場合や、独自工程を組み込む場合は、個別開発が候補になります。リアルタイムデータやAI分析、ERP・MES連携まで一体で扱うときも、個別開発が候補です。

ただし、全社版をいきなり作ると要件が膨らみやすいため、まずは重要設備1〜5台か1ラインを対象に、3〜6か月程度のPoCでデータ品質と現場定着を検証します。

PoCでは、AIの検知率だけでなく、アラートから作業完了までの時間を見ます。誤報への対応工数と計画外停止時間も、判定の材料にします。

ポイント

標準機能で満たせる範囲と個別対応が必要な範囲を切り分けたうえで、業務の標準化、既存システムとの接続、自社での運用の可否で形態を比べることが判断の目安です。

予防保全システムの要件整理とRFP作成の進め方

RFPは、機能一覧だけでなく、現状課題や目標KPI、対象設備をそろえる文書です。利用者や業務フロー、データも明記します。さらに、連携とセキュリティ、納期と予算、提案事項まで書いておくと、各社が同じ前提で提案できます。

現場と保全、生産技術の代表者を集めます。情シス、購買、経営の代表者も加え、部門ごとの要求を一つの優先順位にまとめます。

現状資料とKPIの先行整理

RFPには、設備台帳の項目、設備数と拠点数、点検帳票を添付します。さらに、故障履歴や交換部品、担当者と承認者も添付し、現行のExcelや紙帳票も加えます。

過去データの欠損は、隠さずに示します。その際、「初期導入で移行する期間」と「稼働後に蓄積する期間」を分けて書くと、移行作業の過小評価を防ぎやすくなります。

KPIの候補には、MTBFやMTTR、計画保全率などがあります。計画外停止時間、保全費、アラート対応時間も候補になり、最初の3〜5個に絞ります。

現場が使える要件の具体化

現場要件には、スマートフォンやタブレットでの入力、写真添付、QRコードでの設備呼び出しを含めます。オフライン入力や必須項目も入れます。外国語表示や手袋での操作も、要件に加えます。

画面の機能を増やすより、巡回中に数十秒で記録でき、異常を作業指図へ変換できることのほうが、定着につながります。

RFPでは、アラートを受け取る人と一次確認をする人、停止を判断する人、修理を承認する人を決めておきます。

IoT連携とセキュリティの要件

センサーを使う場合は、まず対象の種類を明確にします。候補は、振動、温度、電流などです。

サンプリング周期、PLCやSCADAからの取得データ、通信経路を明記します。ゲートウェイやエッジ処理、クラウド保存も示します。時刻同期も書き込みます。

経済産業省は2025年4月、中小規模の製造事業者向けに、工場セキュリティの始め方を示す解説書を公開しました。

同省は、工場の規模にかかわらず、サプライチェーンを含む対策が必要だとしています(出典: 経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン Appendix」、2025年)。

  • アクセス管理:ネットワーク分離、最小権限、多要素認証
  • 情報保護:暗号化、ログ、バックアップ、脆弱性対応
  • 委託先管理:責任分界とサプライチェーン対策

ポイント

RFPに含める範囲は、現場で使える操作と、移行作業を過小評価しない程度の現状資料で判断します。KPIは最初の3〜5個に絞ると、各社の提案を比べやすくなります。

予防保全システム開発を外注する手順

現状診断と対象設備の選定から、RFPの配布・比較を経て、要件定義・テスト・本番運用へ進む3段階の流れ図。
各段階の成果を固めながら次の工程へ進みます。

外注は、3つの段階で進みます。まず、現状把握とRFP配布、提案比較を行います。そのあと、要件定義と設計・開発を進め、テストと教育を経て本番運用へ移ります。

発注側は、各工程の成果物と意思決定者を先に決めておきます。現場データや業務ルールを確かめずに開発を進めると、画面はできても点検記録が残らない事態になりやすいです。そのため、最初の現状把握で、現場データと業務ルールを確かめます。

1. 現状診断と対象設備の選定

設備は、故障による停止損失や安全・品質への影響から分類します。修理部品の入手性や故障履歴の量も、分類の材料にします。

初期対象には、重要度や停止時の影響が大きく、かつデータを取得できる設備を選びます。データが取れる設備から始めると、効果を検証しやすくなります。

発注側は、保全責任者に加えて、設備担当者と生産計画の責任者にも聞き取りを行います。点検の実態と例外処理を明らかにするためです。

2. RFP配布と提案・見積の比較

候補会社には同じRFPを渡し、提案書の目次と、要件別の対応可否を指定します。前提条件や、標準機能と追加開発の区別も求めます。

体制と工程、費用の内訳を求めます。運用保守や導入事例も確認します。価格に加えて、設備業務への理解も比べます。

提案時には、現場ヒアリング、画面モック、簡易なデータ連携の説明を依頼します。質問への回答が曖昧なときは、追加請求や責任分界のリスクを見極める材料になります。

3. 要件定義からテスト・本番運用までの移行

本番稼働までは、工程ごとに成果と確認内容を固めていきます。要件定義の段階では、テスト計画と移行計画も決めておきます。

  1. 要件定義書、業務フロー、設備コード一覧を確定し、画面・権限一覧と連携仕様を固める
  2. 現場代表者が画面と操作を確認し、試験データで点検登録から作業完了までを通す
  3. 通信断、センサー欠損、異常値を受入テストで確かめる。重複登録、担当者不在、緊急停止の場合も検証する
  4. 教育と旧帳票との並行運用を整え、問い合わせ窓口と障害時の復旧手順も用意してから本番へ移る

ポイント

各工程の成果物と意思決定者を先に決め、現場データと業務ルールを確かめてから設計へ進めるかどうかが判断の目安です。

発注前に決める契約形態と責任分界

要件が定まりにくい初期工程と、成果物を決めやすい開発工程とで、契約を分ける方法が有効です。設備や既存データを調べないまま全工程を固定すると、追加要件が出たときに納期と費用の調整が難しくなります。

契約書と見積書には、作業範囲や成果物、検収条件を明記します。変更手続きと知的財産も書き込みます。データ所有権と保守範囲も明記します。

請負契約・準委任契約・サブスクリプションの使い分け

発注側は、契約名よりも、各工程の成果とリスク負担を照らし合わせます。

  • 請負契約:機能と成果物が明確な設計・開発に適し、完成物の検収で区切る
  • 準委任契約:現状調査、要件定義、データ整理、PoCなど、協議しながら作業時間や体制を管理する工程
  • サブスクリプション:クラウド製品の多くは月額か年額で、利用料と導入支援費、追加開発費、保守費を分けて確認する

センサー・ネットワーク・AIの責任分界

センサー故障や通信・ゲートウェイの障害、クラウド停止は、原因によって対応者が変わります。アプリの不具合やAIの誤検知についても、原因ごとに対応者が決まります。

一次窓口は、決めておきます。連絡先となる設備メーカーと通信会社、クラウド事業者とSIerも明確にします。切り分けに使うログの保有者も、契約前に決めます。

AIモデルを使う場合は、学習データの所有権と再学習の条件を確認します。モデル更新費や、誤報による確認作業の扱いも決めます。

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

開発・移行、設備・通信、システム利用、導入・運用の4費目をカードで並べた図。
周辺作業も独立した費目として照合できます。

予防保全システムの受託開発費は、公的な一律の統計がありません。そのため、公開されているCMMSの料金例と、業務システム・IoT連携の類似案件から、企画段階の目安を整理しました。

費用は、設備や拠点の数、センサー工事、データ移行によって変わります。AI、ERP・MES連携、24時間保守も、費用を左右します。そのため、発注側は自社の条件で見積を取得します。

導入パターン別の費用レンジ

費用と期間の目安は、導入方式や規模によって異なります。代表的なパターンを比べると、検討の初期に予算感をつかめます。

  • クラウドCMMSの標準導入:初期費用0万〜30万円程度、月額3万〜20万円前後
  • 1拠点の台帳・点検・QR・モバイル・簡易ダッシュボードを個別対応:300万〜700万円程度、2〜4か月程度
  • 複数ライン、部品在庫、承認、MES・ERP連携を含む中規模構築:700万〜1,800万円程度、4〜9か月程度
  • 複数工場・大規模開発:1,800万〜4,000万円以上、9〜18か月以上

設備保全総合研究所のEMLinkは、初期費用を0円としています。料金は、ベーシックが1事業所あたり月額12万円、AI機能を含むプロフェッショナルが月額21万円です(税抜・年間契約の掲載例、2026年8月確認)。

クラウド料金は製品の例で、現場調査や特殊な連携が含まれるとは限りません。個別対応と構築の費用・期間は、類似案件から整理した企画段階の目安です。

これらは、予防保全システム単独の公的な相場ではありません。要件が近い案件からの推定です。

センサー・開発・運用の費目別の比較

見積もりの漏れを避けるため、システム構築と周辺作業の費目を分けて確認します。

  • 開発・移行:要件定義、画面・API、設備マスタ、紙・Excel履歴
  • 設備・通信:センサー本体、取付工事、ゲートウェイ、通信費
  • システム利用:クラウド利用料、データ分析、AIモデル
  • 導入・運用:テスト、教育、保守

AWSの公開例では、50センサー・50ゲートウェイの予知保全構成が、月額159.84米ドルと試算されています。これは、2024年3月6日時点のクラウド料金例です。

センサー本体、設置工事、通信に加え、アプリ開発、データ整備、保守も、この額には含まれていません(出典: AWS「IoT 予知保全のためのクラウド構成と料金試算例」、2024年)。

保守費は、障害対応だけでなく、OSやブラウザの更新、クラウド仕様の変更、脆弱性対応の範囲で変わります。ほかに、バックアップ確認やモデル再学習が含まれます。設備の追加や問い合わせ対応も、保守費の範囲に入ります。

年間保守を初期開発費の10〜20%程度とする提案もあります。これは一般的な業務システムの目安で、24時間監視や現地駆け付けは別見積もりです。

月額料金と初期費用を足した3年総額で比べると、提案に含まれていない費用も確認できます。

委託先の選定と見積比較で確認するポイント

委託先は、業務設計や現場端末、センサー・制御データを担えるかで比べます。さらに、クラウドや基幹連携、導入後の保守まで担えるかも見ます。

製品ベンダーとSIerが別なら、一次窓口と障害の切り分け責任を確認します。実績や担当者の経験、提案内容も判断材料です。契約条件も、判断に含めます。

設備業界・現場運用の実績の確認

公開事例の再現性は、自社の運用条件にどれだけ近いかで読み解きます。

  • 設備:自社に似た設備を扱った実績
  • 拠点:導入先の拠点数
  • 通信環境:自社と近いネットワーク条件
  • 利用者:想定するユーザー数
  • 導入範囲:事例で対応した機能や業務の範囲

導入社数の多さより、自社の運用条件に近い事例を探します。

エクサは、古野電気の三木工場に、予防保全・リアルタイム監視・稼働集計の仕組みを導入しました。

2019年から2022年に、対象設備のMTTRを約20%短縮し、保守費用を3年間で約56%削減したと説明しています(出典: 株式会社エクサ「古野電気株式会社様 導入事例」)。

同じ効果が出るとは限りませんが、KPIの設定や効果測定の進め方を確かめる材料になります。

見積書の比較軸のそろえ方

見積比較では、比べる軸をそろえます。機能や品質、納期を同じ基準で見ます。費用や体制は、保守や将来拡張とあわせて確認します。

  • 機能:標準・設定・追加開発・対象外に分類する
  • 品質・体制・保守:各社に同じ粒度で示してもらう
  • 費用・納期:工数・単価・数量・前提条件を確認し、設備調査、工事、移行、教育、停止可能時間を日程に含める
  • 将来拡張:追加料金、API、データ出力、設計書、解約後のデータ返却を確認する

安すぎる見積・高すぎる見積の理由確認

見積額の差を判断するには、費用に含まれる範囲と、代替案の条件を確かめます。

  • 他社より極端に安い見積:要件定義、データ移行、テスト、教育、保守、センサー工事が含まれていない可能性を確認する
  • 高い見積:不要なAI機能や全設備の一括対応が含まれていないか見る
  • 代替案:重要設備5台からの開始、AIの第2段階化、クラウド標準機能の優先を求める
  • 選定:費用と効果を比べ、前提と変更時のルールが明確な提案を選ぶ

ポイント

委託先は、どこまで担えるかと、障害時の切り分け責任で比べます。見積は、安い・高いの理由を聞いてから、比べる軸をそろえて判断します。

よくある質問

設備数や既存データによって最適な方法は変わります。下の回答は、初期相談やRFP作成前の判断材料として使ってください。

小規模工場でも予防保全システムを外注できますか?

小規模工場でも予防保全システムを外注できます。

まずは重要設備1〜5台か1ラインから始め、台帳と点検、履歴、作業指図を導入して、現場で使えるか確認します。

クラウドCMMSの標準機能や短期間のPoCを使えば、全社スクラッチ開発より小さく始められます。

故障履歴が少なくてもAI予知保全を導入できますか?

導入はできますが、故障ラベルや履歴が少ないとAIの予測精度を検証しにくくなります。

まずは、設備台帳や点検値、異常内容を、デジタルで記録します。修理内容と作業時間も残し、閾値やルールによる通知から始めます。

履歴がたまった設備から、統計的な異常検知やAIを追加し、誤報率と対応工数で評価します。

RFPにはどの資料を添付すればよいですか?

設備台帳と階層、点検帳票、故障・修理履歴を添付します。部品一覧やExcel・紙帳票、ネットワーク構成も添付します。連携対象のMES・ERP・SCADA、利用者と権限、希望KPIも示します。

履歴の欠損や設備ごとの例外も明記します。資料が完全でなくても、現状を正確に示せば、各社の見積もりの前提や追加費用をそろえやすくなります。

クラウド型の予防保全システムは安全ですか?

安全性は、クラウドかオンプレミスかという形態よりも、対策の中身で決まります。工場とITネットワークの分離、通信暗号化、権限を確認します。多要素認証やログ監視も見ます。

バックアップや脆弱性対応も、確認の対象です。委託先のサプライチェーン管理は、構成と運用の両面で確かめます。OT機器に接続する場合は、停止時の安全確保と責任分界を、情シス・生産技術・ベンダーで合意します。

まとめ

発注側は、設備停止の課題と対象設備を定めます。そのうえで、台帳や点検、履歴、作業指図の範囲を決めます。クラウドCMMS、パッケージ併用、スクラッチ開発を比べ、重要設備1〜5台や1ラインから効果と定着を確かめます。

RFPには、設備やデータ、業務フロー、KPIを記載します。現場操作や連携の要件に加え、セキュリティと保守も記載します。責任分界もRFPに入れます。

見積もりは、開発と移行、教育を分けて比べます。センサーやクラウド、保守も、費目ごとに見ます。

公開料金や事例の数字は、参考情報として見てください。費用や効果は設備数と拠点によって変わり、停止損失や既存システムの条件も関わります。データを整えてから状態監視やAIに進むと、保全業務に定着させやすくなります。

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

会社紹介

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

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

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

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

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

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