稼働管理システムの発注は、対象設備とKPIを決めることから始まります。RFPで接続や運用の条件をそろえ、1ラインで検証してから段階的に広げると、各社の提案を比べやすくなります。
発注では、発注形態を選び、RFPと要件整理を経て、契約と費用、委託先の選定、導入計画へ進みます。
▼全体ガイドの記事
・稼働管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注前に決める項目
発注前に決めるのは、対象設備とデータ取得周期、データの意味、改善判断に使う人です。対象範囲が曖昧なまま外注すると、会社ごとに前提が異なり、提案を比べられなくなります。
設備稼働の管理と人員・工数管理の区別
稼働管理システムは、設備・ライン・工程の状態や稼働時間を集め、停止、段取り替え、チョコ停、故障、品質不良などを分析します。
人員の出退勤やプロジェクト工数を管理するシステムとは、目的が異なります。ただし、人員情報を担当者やシフトとしてひも付けても、管理の主語は設備と生産実績です。
発注書やRFPには、対象範囲とデータ取得・連携の構成を明記します。
- 対象範囲：設備稼働・停止・生産実績が対象で、勤怠管理を主目的にはしません。
- 取得元：PLC、センサー、工作機械、計測機器、IoTゲートウェイ
- 保存・連携先：アプリや時系列DB、クラウドまたはオンプレミス、ERP・MES・品質管理・BI
見える化の先にあるKPIの設定
発注先が機能を判断できるように、導入前後で比べられる目標と測定条件を決めておきます。
- 改善目標：停止時間20％削減、日報入力1日30分削減、段取り時間や不良原因の特定時間の短縮。
- 現状把握：数値が未測定なら、最初の2〜4週間をPoCに含める。
- OEE条件：時間稼働率・性能稼働率・良品率の計算条件。予定停止を分母から除くか、段取り替えを停止に含めるかを合意する。
- 状態定義：「稼働」「アイドル」「異常」「保全中」「計画停止」の定義、微小停止の集計秒数、停止理由マスタ。
発注形態の選び方
発注形態は、標準機能に設備や工程を合わせられるか、独自のデータやKPIが競争力に関わるか、拠点展開の予定があるかで選びます。
迷う場合は、まず1ラインで稼働データの収集と停止理由の記録を検証します。そのうえで、効果を確認できた部分から広げる段階導入が現実的です。
SaaS・クラウド型の向いている場面
SaaSやクラウド型は、標準化された設備接続、ダッシュボード、アラート、帳票を早く使いたい企業に向いています。さらに、初期のサーバー調達を抑えやすく、更新を受けられる点も利点です。
- 標準機能の限界：古いPLCや独自プロトコル、特殊な停止理由、細かな権限、工場内ネットワークの制約では、標準機能だけで対応できないことがあります。
- クラウド条件：送信範囲、通信断時の一時保存と復旧後の再送、保存場所、テナント分離、終了時の返却。
- 接続構成：制御系を直接公開せず、エッジで収集・バッファリングして、必要なデータだけを上位へ送る形。
- 担当範囲：設備接続と現場導入を担う会社を、別に用意する場合があります。
パッケージ・セミカスタムによる標準化と独自要件の両立
パッケージやMESを標準で導入し、設備接続やAPI、帳票、独自KPIだけを追加する方式は、更新と自社要件の両方を重視する企業に適します。
Fit to Standardを基本にして、競争優位に関わる分析や業務ルールだけをアドオンにすると、個別開発を抑えやすくなります。
提案の段階では、各機能が標準機能で実現するのか、設定やアドオンで実現するのか、外部システムに任せるのかを分類してもらいます。
独自工程と複雑な連携があるときのスクラッチ開発
独自工程があるとき、異なる設備を持つ複数工場にまたがるとき、既存のERP・MES・WMS・品質・保全システムと高度な連携が不可欠なときは、スクラッチや大規模セミカスタムが候補です。
全機能を一度に作ると、接続が遅れ、現場の入力負荷が増えます。さらに、テストが不足しがちになり、保守費も増えがちです。
稼働データ収集とエッジ部分は再利用できる基盤にします。そのうえで、1ラインのMVPから拡張する契約にすると、リスクを抑えられます。
RFPと要件整理の進め方
RFPは要望を伝える資料であり、自社の発注条件をそろえる設計図です。機能だけでなく、設備やデータ、現場運用、停止可能時間の条件を書きます。連携先、セキュリティ、検収条件も記載します。
候補会社に同じ資料を渡すと、価格だけでなく、前提の抜けや追加費用の扱いも比べられます。
設備・通信・データの洗い出し
設備調査では、見積もりの前提をそろえるために、次の情報を一覧にします。
- 設備情報：工場・建屋・ライン、設備メーカーと型式、PLC、センサー
- 接続情報：接続方式と信号、電源とネットワーク、停止可能な時間帯
- データ条件：収集周期、欠損や重複時の扱い、データを使う判断や会議
OPC UA、MQTT、Modbus、Ethernet/IP、RS-232C、独自プロトコルが混在する場合は、方式ごとに難易度と追加機器を確認します。
接続可否が分からない設備を後回しにすると、比較が崩れます。そのため、現地調査をRFPの必須作業に含めます。
データ項目は、設備IDや時刻、稼働状態を中心に洗い出します。残りの項目は、次のように分けて一覧にします。
- 停止と実績：停止理由、生産数、サイクルタイム、良品・不良数
- 品番と人：品番、ロット、担当者、シフト
- 記録：アラーム、段取り、保全記録
収集周期は秒単位か分単位かを決めます。そのうえで、収集データがどの会議のどの判断を変えるのかとひも付けます。
機能要件に書く現場の行動
機能要件は、画面名ではなく、誰がいつ何をするかを示す形で整理します。
- 記録・分析：実績登録、停止理由、OEE計算、日報・帳票、検索、追跡
- 監視・管理：リアルタイム表示、アラート、権限、マスタ、API連携、保全予定
- 現場操作：作業者の登録端末、班長の承認画面、管理者の効果確認
停止時に、作業者が何秒以内にどの端末で理由を登録するか、班長がどの画面で承認するかを決めておきます。管理者が効果を確認する期間も記載します。
画面要件は現場の導線に合わせます。たとえば、手袋での操作、固定タブレット、バーコードやRFIDの使用を前提にするかを確かめます。通信断のときに入力できるかも見ます。
自動で取得するデータと人が入力するデータは分け、入力項目は改善に必要な最小限にします。入力の負担だけが増える設計は、定着しません。
非機能要件とOTセキュリティの条件
RFPには、非機能要件とOTセキュリティの条件を具体的に書き込みます。
障害がアプリだけにとどまるか、設備制御にも影響するかによって、要求水準は変わります。ただし、読み取り中心の構成でも操業に影響し得るため、どこまでを誰が受け持つかを明確にします。
- サービス条件：稼働時間、応答性能、同時利用者数、可用性、保守時間、障害時の連絡体制。
- データ保護：保存期間、バックアップ、復旧目標、監視、ログ。
- 接続対策：ネットワーク分離、読み取り専用接続、最小権限、監査ログ、脆弱性対応、復旧演習。
経済産業省の「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」は、IoT化やクラウド接続でリスクが増えるとしています。さらに、ゾーン分け、通信制御、運用・管理面の対策を示しています（出典：経済産業省、2022年）。
JEITAの「工場のためのセキュリティ対策策定ガイドライン」は、中小製造業がOTセキュリティの第一歩を踏み出すための資料です（出典：JEITA、2025年）。
契約形態と発注プロセス
要件が固まる前の調査・企画と、仕様に基づく開発・検収では、不確実性が異なります。そのため、調査、要件定義、PoC、開発、保守の工程ごとに、何を納めるかと、次の段階へ進む条件を決めます。
準委任・請負・サブスクリプションの違い
契約形態ごとに、責任と支払いの対象が異なります。そのため、工程に合う形を選び、条件を条項で確かめます。
- 準委任：専門家の作業や支援を受ける形で、要件定義、現地調査、アジャイル検証、運用改善の場面に合います。
- 請負：合意した仕様どおりに仕上げて検収する形で、要件と完成条件が明確な開発に適します。
- サブスクリプション：SaaSやクラウドを、利用規約に基づいて月額・年額で使う形です。
実務では、要件定義を準委任、仕様確定後の開発を請負、クラウドと保守をサブスクリプションや保守契約にする、といった組み合わせがあります。
契約は中身で判断し、作業の範囲、変更管理、検収基準を確認します。さらに、知的財産権や第三者ソフトウェア、再委託、秘密保持、障害時の責任も確認します。
クラウド契約では、可用性やデータ返却、解約、障害対応を、開発契約とは分けて確認します。
検収条件と仕様変更の手順
検収では、実機から正しいデータを取れるか、通信が途切れた後に復旧できるかを確認します。
停止理由の集計が合意した計算式どおりになるか、権限と監査ログが機能するかも確認します。
- 受入テスト：設備ごとの通信遅延、時刻ずれ、重複・欠損、設備停止、外部APIエラーの試験
- 停止時間の制約：テスト環境、シミュレーター、夜間切替の計画
- 変更管理：要求受付から影響確認、追加費用と納期の承認、優先順位の更新までの手順
口頭での依頼を積み重ねると、納期遅延や品質低下につながります。一方で、変更をすべて断ると、現場への定着を妨げます。
変更への対応は、PoC中は柔軟に試し、本開発では合意した変更管理に移すといった切り分けが必要です。
稼働管理システムの費用相場とコスト内訳
価格は、設備数や収集周期、端末、保存期間で変わります。さらに、PLCやセンサー、既存連携、工場数、24時間運用の要否も影響します。公開価格を見る前に、接続、設定、移行、テスト、教育の範囲を確認します。
ここに挙げる金額は、生産・製造業務システムの相場と類似構成から整理した目安です。特定のベンダーの確定価格ではありません（出典：リサーチノート）。
導入範囲別の初期費用
導入範囲別の費用は、初期費用と継続費を分けて比べると、見積もりの前提を確認できます。
- SaaS導入支援：標準的なSaaS・クラウド型で、初期設定や導入支援だけの場合は0〜60万円程度です。
- パッケージ・MES：ライセンスと設定で、数十万〜数百万円程度からです。
- 1ラインPoC・小規模開発：センサー、ゲートウェイ、画面、停止理由、簡易ダッシュボードを含み、300万〜1,000万円程度です。
- 複数ライン連携：ERP・MES・品質・保全との連携を含み、1,000万〜5,000万円程度です。
- 複数工場のスクラッチ：大規模移行、拠点展開、24時間運用設計まで行うと、5,000万〜1億円以上の場合があります。
SaaSの利用料は、1ユーザー月額数百〜数千円の場合と、設備・拠点単位の個別見積もりの場合に分かれます。なお、現地調査費は別に確認します。
ここに挙げた額は、いずれも類似システムからの推定です。設備数や連携数を減らせば下がり、独自要件や品質・セキュリティ要件が増えれば上がります。
人件費・連携費・保守費の内訳
費用の内訳は、工程別の人件費、連携費、保守費に分けて比べます。そのうえで、各工程の人月と担当者の役割を確認します。
- 参考月額単価：2026年の参考値は、PMが90万〜150万円、SEが65万〜110万円、PGが50万〜90万円、テスターが45万〜80万円です。
- 工程比率：要件定義10〜12％、設計・環境構築22〜24％、実装48〜50％、テスト15〜17％程度です。
- 保守運用：初期開発費の年15〜25％程度を目安にします。
単価は公定価格ではなく、体制と専門性によって変わる参考の幅です。そこで、設備接続の本数や現地調査、データ移行、教育、切替支援の範囲も確認します。
保守費には、クラウド利用料や監視、バックアップ、問い合わせ、脆弱性対応、OS更新を分けて含めます。特に、実装費だけが低い見積もりには注意が必要です。
補助金の対象年度と登録ツールの公式情報
補助金を予算に含めるときは、採択を確約する営業説明より、公募要領で要件を確かめます。
- 対象条件：対象経費と申請者要件の確認
- 申請時期：申請期間と事業スケジュールの確認
- 発注時期：交付決定前の契約・発注の可否
- ツール要件：登録ツールと機能区分の確認
2026年は、「IT導入補助金」から名称が変わった「デジタル化・AI導入補助金2026」の公式サイトで、申請対象や日程が案内されています（出典：中小企業庁・独立行政法人中小企業基盤整備機構、2026年）。
製造設備の管理や稼働状況に使えるかは、年度の公募要領で確認します。
委託先選定と見積比較のポイント
委託先は、知名度や製品名だけでなく、自社設備への接続と現場運用を説明できるかで比べます。加えて、元請けが現地調査と実装担当を管理できるかも確認します。
アプリ開発、制御機器、ネットワーク、保守を別々の会社が担う場合は、再委託先の責任範囲と連絡経路を確認してください。
同じ設備・規模・導入範囲の実績
実績は、業種名だけでなく、設備や通信方式、規模、現場運用まで自社の条件と照らして評価します。
- 設備条件：設備種類、PLC、通信方式、収集周期の一致
- 導入範囲：工場規模、現場端末、期間、段階展開の有無
- 導入成果：課題、実装範囲、教育方法、KPI、保守体制に関する質問
日立のFactRiSM事例では、設備や測定機器から製造記録をMESへ自動で集め、一つにまとめる取り組みが紹介されています。
富士通のCOLMINA事例では、生産設備の稼働・進捗・不具合を閉域網経由でクラウドに集約しています。公式事例でも、接続条件は自社の設備と照らして確かめます。
稼働率だけでなく、停止時間や段取り時間、入力工数、不良原因の特定時間などを、どの定義で測ったかを聞くと、提案がどこまで具体的かを見極められます。
同じ単位にそろえた見積書の比較
見積書は、作業ごとの範囲と数量をそろえて、会社ごとの前提の違いを見つけます。
- 作業項目：要件定義、現地調査、設備接続、機器、アプリ、クラウド、連携、移行、テスト、教育、切替、保守
- 比較単位：設備1台、ライン1本、拠点1か所などの数量
- 概算条件：確定に必要な調査と金額が変わる条件
安い見積もりには、含まれていない作業がないかも調べます。古いPLC接続、現地立会い、休日作業、ネットワーク変更が含まれるかを確かめます。さらに、帳票追加、過去データ移行、利用者教育も見ます。
障害監視やセキュリティ診断、OS・ミドルウェア更新、クラウドの転送量が別料金になっていないかも見ます。また、「含まないもの」と追加単価も提示してもらいます。
実機デモと異常系テストによる実装力の確認
可能なら、自社設備のサンプル信号や匿名化した日報でデモを依頼し、通常時だけでなく異常時の動作も確かめます。
- 現場機能：停止理由の登録とロット追跡
- データ処理：欠損データや設備時計のずれ
- 連携復旧：通信断からの復旧、外部API無応答
実機を止められない場合は、同じプロトコルのシミュレーターや過去データで検証します。
選定の評価は、価格、設備接続、現場定着、業務連携、セキュリティ、保守の6つの観点で整理できます。各観点を5段階で採点します。ただし、必須条件を満たさない会社は、総合点に関係なく候補から外します。
2026年は、工場のOTセキュリティを事業継続や品質と一体で考える流れが強まっています。たとえば、経済産業省は2025年に半導体デバイス工場向けOTセキュリティガイドラインを成案化し、IT・OTの分離やゾーンごとの通信制限を示しています（出典：経済産業省、2025年）。
発注後に失敗しない導入計画と運用設計
導入後にデータが自然に改善されるわけではありません。そのため、データの精度を保つには、導入後の役割分担を先に決めておく必要があります。停止理由の入力、マスタ管理、障害時の一次対応、現場教育、効果測定の担当者を決めます。
現場と管理部門が同じ定義で数字を見る運用を作ります。そのうえで、最初のPoCでは機能数よりも、データの正確さと使いやすさを検証します。
1ラインの90日PoCで集める投資判断のデータ
90日程度のPoCは、調査、実装、運用検証の順に進めます。ただし、期間は設備や契約条件によって変わる計画例です。
- 最初の2〜3週間で、現場ヒアリング、設備・通信の洗い出し、停止理由とKPIの合意を行います。
- 次の3〜5週間で、エッジ収集、最低限の画面、停止理由の登録、生産数・良品・不良の連携を実装します。
- 実機で欠損や時刻ずれを確かめ、残りの期間で教育、運用テスト、導入前後のKPI比較を進めます。
- 最後に、次のラインへ展開する条件を整理します。
合格条件は、データ取得率、停止理由の入力率、日報との差分、通信断からの再送、操作時間、改善会議での利用回数で測ります。画面の完成そのものは、合格条件にはなりません。
停止時間の削減が見えなかった場合でも、信頼できる基準値や次の改善仮説が得られたかを評価します。全工場への展開は、拙速に決めないようにします。
運用責任者とデータの所有権
マスタ更新や障害対応が滞らないよう、本稼働後の運用責任を決めておきます。
- データ管理：設備・停止理由マスタの変更者と品質確認者
- 障害対応：現場とベンダーへの連絡方法、一次対応者
- 契約条件：SLAの稼働時間、一次回答、復旧目標、保守時間、脆弱性通知
- 会議体：工場長、生産技術、情報システム、品質、保全が参加する運用会議
現場だけに運用を任せると、入力が形骸化しがちです。そこで、関係部門が参加し、バックアップと復旧演習の頻度も決めます。
データ所有権や二次利用、学習データへの利用可否、返却形式、API利用権、ログ保存期間を確認します。
ベンダーを変える場合に備えて、データ辞書、API仕様、接続設定、運用手順は、文書として受け取ります。こうした文書は、将来の追加開発費と乗り換えリスクを下げます。
よくある質問（FAQ）
古い設備や予算、導入期間、既存システムとの連携について、外注前によくある疑問を紹介します。
古いPLCやネットワーク未接続の設備でも発注できますか？
発注は可能です。ただし、信号や通信方式、読み取りの可否、追加センサーやゲートウェイの有無は、現地調査で確認します。
既存の制御に書き込まず読み取り専用で収集できるか、通信断時に保存できるかを、RFPに記載します。不明な設備は見積もり前の調査対象にしておくと、追加費用を抑えられます。
予算が限られる場合はどこから外注すべきですか？
1ラインの現地調査、データの洗い出し、停止理由の定義、稼働・停止・生産数の収集、簡易ダッシュボードから始められます。
リサーチノートの目安では、1ラインPoCや小規模開発は300万〜1,000万円程度です。なお、設備接続や端末、ネットワークの追加によって変わります。
要件定義やテストは削らずに、対象設備と画面を絞ります。そのうえで、次の段階でも再利用できる設計にします。
SaaSとスクラッチ開発はどちらがよいですか？
標準的な設備接続と業務で早く始めるならSaaSやパッケージ、独自工程や複雑な連携が競争力に関わるならセミカスタムやスクラッチが候補です。
まず1ラインのPoCで、データ品質と現場定着を確認します。そのうえで、標準機能で足りない部分だけを個別開発すると、投資リスクを抑えられます。
稼働管理システムの外注契約で特に注意する点は何ですか？
設備接続の責任範囲やデータ所有権、検収条件、通信断や欠損の扱いを確認します。さらに、仕様変更や再委託、保守SLA、脆弱性対応、終了時のデータ返却も見ます。
画面が完成していても、実機データが正しく集計されなければ、目的は達成できません。そのため、正常系と異常系の設備受入テストを、納品の対象と検収条件の両方に含めます。
まとめ
発注では、設備稼働の定義と対象を決め、停止理由やOEEなどのKPIを合意します。そのうえで、設備、通信、データ、運用、非機能要件をRFPにまとめます。
標準化しやすさと独自要件を見て、SaaSやパッケージ、セミカスタム、スクラッチから選びます。見積もりは、調査、接続、設計、実装の単位で比べます。テスト、教育、保守も、同じ単位で見ます。
委託先は、同じ設備や規模の実績、PoC、異常系テストで評価します。さらに、契約前に条件を文書で合意しておくと、稼働後のずれを防ぎやすくなります。
- OTセキュリティ：非機能要件で定めた接続対策
- データ所有権：二次利用、返却形式、ログ保存期間
- SLA：稼働時間、復旧目標、保守時間
小さく発注し、データの信頼性と現場の改善行動を確認してから展開すると、投資と操業のリスクを抑えられます。
▼全体ガイドの記事
・稼働管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。