稼働管理システムの発注・外注では、設備の稼働データを集めるだけでなく、停止理由、生産数、良品・不良、保全履歴を現場で使える形にし、改善につなげる範囲まで決めることが重要です。発注前に対象ラインとKPIを絞り、設備接続・セキュリティ・保守の条件をRFPに整理すると、見積金額と提案内容を比較しやすくなります。
本記事では、製造設備・生産ラインを対象とする稼働管理システムについて、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、委託先の選定方法、見積書の比較ポイントを解説します。紙やExcelの日報から移行したい企業、古いPLCを含む設備を接続したい企業、1ラインのPoCから段階導入したい企業にも使える実務的な進め方をまとめています。
▼全体ガイドの記事
・稼働管理システム開発の完全ガイド
稼働管理システムの発注では何を決めるべきですか?

結論からいえば、発注前に決めるべきなのは「何を見える化するか」だけではなく、「どの設備から、どの周期で、どの意味のデータを取り、誰がどの改善判断に使うか」です。稼働管理システムは、設備監視、MES、設備保全、工数管理と重なる部分があるため、対象範囲を曖昧にしたまま外注すると、提案会社ごとに前提が変わって比較できなくなります。
設備稼働の管理と人員・工数管理を分けて定義します
本記事でいう稼働管理システムは、工場の設備・ライン・工程がいつ、どの状態で、どれだけ稼働したかを収集し、停止・段取り替え・チョコ停・故障・品質不良などのロスを分析する仕組みです。人員の出退勤やプロジェクトの工数を管理するシステムとは目的が異なります。人員情報を担当者やシフトとしてひも付ける場合はありますが、主語はあくまで設備と生産実績です。
発注書やRFPの冒頭には、「対象は製造設備の稼働・停止・生産実績であり、勤怠管理を主目的としない」と明記しておくと安全です。そのうえで、PLC、センサー、工作機械、計測機器、IoTゲートウェイからデータを取得し、アプリ、時系列データベース、クラウドまたはオンプレミス、ERP・MES・品質管理・BIへつなぐ構成を想定します。
見える化の先にあるKPIを先に決めます
「稼働状況を見える化したい」だけでは、発注先が必要な機能を判断できません。たとえば、停止時間を20%削減する、日報入力を1日30分削減する、段取り時間を短縮する、不良原因の特定時間を短くするなど、導入前の基準値と導入後の目標値を置きます。数字がまだ測れていない場合は、最初の2〜4週間を現状把握期間としてPoCの範囲に含めてもよいです。
OEEを使う場合は、時間稼働率、性能稼働率、良品率の計算条件も合意します。予定停止を分母から除くのか、段取り替えを停止に含めるのか、微小停止を何秒単位で集計するのかが会社やラインごとに違うと、同じ設備でも数字が変わります。発注前に「稼働」「アイドル」「異常」「保全中」「計画停止」などの状態定義と停止理由マスタを決めることが、画面の多さより重要です。
発注形態はどれを選ぶべきですか?

発注形態は、設備や工程を標準機能に合わせられるか、独自のデータ収集やKPIが競争力に直結するか、将来の拠点展開があるかで選びます。迷う場合は、最初から全工場をスクラッチ開発するのではなく、1ラインで稼働データ収集と停止理由の記録を検証し、効果が確認できた部分だけを拡張する段階導入が現実的です。
SaaS・クラウド型は短期間の見える化に向いています
SaaSやクラウド型は、標準化された設備接続、ダッシュボード、アラート、帳票を早く使い始めたい企業に向いています。初期のサーバー調達を抑えやすく、アップデートを受けられる点も利点です。一方で、古いPLCやメーカー独自プロトコル、特殊な停止理由、細かい権限設計、工場内のネットワーク制約があると、標準機能だけで対応できない場合があります。
クラウドへ送るデータの範囲、通信断時の一時保存、復旧後の再送、データの保存場所、テナント分離、契約終了時のデータ返却を確認します。工場の制御系を直接インターネットへ公開するのではなく、エッジゲートウェイで収集・バッファリングし、上位システムへ必要なデータを送る構成が基本です。SaaSを選んでも、設備接続と現場導入を担う会社が別に必要になることがあります。
パッケージ・セミカスタムは標準化と独自要件を両立します
パッケージや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に含めます
非機能要件には、稼働時間、応答性能、同時利用者数、データ保存期間、バックアップ、復旧目標、監視、ログ、可用性、保守時間、障害時の連絡体制を含めます。工場のシステムは、障害時にアプリだけが止まるのか、設備の制御に影響するのかで要求水準が変わります。稼働管理は読み取り中心でも、設計を誤ると現場の操業に影響するため、責任分界を明確にします。
経済産業省の「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」は、IoT化やクラウド接続で工場の利活用が広がる一方、新しいリスクも増えるとして、ゾーン分け、通信制御、運用・管理面を含めた対策を示しています(出典:経済産業省、2022年)。2025年に公表されたJEITAの「工場のためのセキュリティ対策策定ガイドライン」も、中小製造業がOTセキュリティの第一歩を進めるための資料です(出典:JEITA、2025年)。RFPには、ITとOTのネットワーク分離、読み取り専用接続、最小権限、監査ログ、脆弱性対応、バックアップ復旧演習を入れておきます。
契約形態と発注プロセスはどう選びますか?

稼働管理システムは、要件が固まる前の調査・企画と、仕様に基づく開発・検収で不確実性が異なります。そのため、すべてを一つの契約に押し込むより、現地調査や要件定義、PoC、開発、保守を分けて発注し、各段階の成果物と次段階へ進む判断条件を定める方法が適しています。
準委任・請負・サブスクリプションの違いを確認します
準委任契約は、専門家の作業や支援に対して時間・業務の提供を受ける形で、要件定義、現地調査、アジャイル型の検証、運用改善に向いています。請負契約は、合意した仕様の成果物を完成させ、検収する形で、要件と完成条件が明確な開発に向いています。SaaSやクラウドサービスは、利用規約やサービス契約に基づく月額・年額利用となるため、開発契約とは別に可用性、データ返却、解約、障害対応を確認します。
実務では、要件定義を準委任、仕様確定後の開発を請負、クラウド利用と保守をサブスクリプションまたは保守契約にする組み合わせが考えられます。契約形式の名称だけで安全性を判断せず、成果物、作業範囲、変更管理、検収基準、知的財産権、第三者ソフトウェア、再委託、秘密保持、障害時の責任を条項で確認します。
検収条件と仕様変更の手順を発注時に定めます
検収では、画面が表示されることだけでなく、実機から正しいデータを取得できること、通信断から復旧できること、停止理由の集計が合意した計算式になること、権限と監査ログが機能することを確認します。設備ごとの受入テスト項目を作り、正常系に加えて通信遅延、時刻ずれ、重複データ、欠損、設備停止、外部APIエラーを試します。製造ラインを止められる時間が限られる場合は、テスト環境、シミュレーター、夜間切替なども計画に含めます。
現場で追加要望が出ることは避けにくいため、変更要求の受付、影響範囲の確認、追加費用と納期の承認、優先順位の更新を手順化します。口頭の依頼を無償対応として積み重ねると、納期遅延や品質低下につながります。反対に、すべてを変更不可にすると現場定着を阻害します。1ラインの検証期間では柔軟に試し、本開発では合意した変更管理に移行する切り分けが必要です。
稼働管理システムの費用相場とコスト内訳

稼働管理システムの価格は、設備数、PLCやセンサーの種類、収集周期、現場端末、データ保存期間、既存システム連携、工場数、24時間運用の要否で大きく変わります。標準製品の公開価格だけで判断せず、どこまでの接続・設定・移行・テスト・教育が含まれるかを確認してください。以下の金額は、リサーチノートの生産・製造業務システム相場と類似システムの構成から整理した目安であり、特定ベンダーの確定価格ではありません。
導入範囲別の初期費用を比較します
標準的なSaaS・クラウド型で、初期設定や導入支援だけを依頼する場合は、初期費用0〜60万円程度が一つの目安です。利用料は1ユーザー月額数百〜数千円、または設備・拠点単位の個別見積もりなど、料金体系が分かれます。標準導入のパッケージやMESは、ライセンス・設定で数十万〜数百万円程度から、追加連携や端末を含めると上振れします。これらは標準範囲が広い場合の目安であり、設備接続の現地調査費を別に見る必要があります。
1ラインのPoCや小規模個別開発は、センサー・ゲートウェイ・画面・停止理由・簡易ダッシュボードまで含めて300万〜1,000万円程度、複数ラインとERP・MES・品質・保全連携を含む案件は1,000万〜5,000万円程度が目安です。複数工場、大規模移行、拠点展開、24時間運用設計まで行うスクラッチ開発は、5,000万〜1億円以上になる場合があります。いずれも類似システムからの推定レンジで、設備数や連携数を減らせば下がり、独自要件や品質・セキュリティ要件が増えれば上がります。
人件費・連携費・保守費を分けて見ます
見積もりの大部分を占めるのは、要件定義、設備接続、設計、実装、テスト、移行、教育、プロジェクト管理の人件費です。リサーチノートでは、2026年の参考値としてPMが月90万〜150万円、SEが月65万〜110万円、PGが月50万〜90万円、テスターが月45万〜80万円と整理されています。これは市場全体の公定価格ではなく、体制と専門性によって変わる参考レンジです。単価だけでなく、各工程の人月、担当者の役割、設備接続の本数を確認します。
工程比率の参考として、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度という整理があります。実際には設備調査、データ移行、現場教育、切替支援が追加されるため、実装だけを安く見せた見積もりには注意が必要です。保守運用は初期開発費の年15〜25%程度を目安に、クラウド利用料、監視、バックアップ、問い合わせ、脆弱性対応、OS更新対応を分けて確認します。
補助金は対象年度と登録ツールを公式情報で確認します
補助金を前提に予算を組む場合は、採択を確約する営業説明に頼らず、対象経費、申請者要件、登録ITツール、申請期間、交付決定前に契約・発注してよいかを確認します。2026年は「IT導入補助金」から名称が変わった「デジタル化・AI導入補助金2026」の公式サイトで、申請対象や事業スケジュールが案内されています(出典:中小企業庁・独立行政法人中小企業基盤整備機構、2026年)。製造設備管理や稼働状況に使えるかは、年度の公募要領と登録ツールの機能区分を必ず確認してください。
委託先選定と見積比較のポイント

委託先は、知名度や製品名だけで決めず、「自社の設備接続と現場運用を最後まで説明できるか」で比較します。製造業のシステムでは、アプリ開発会社、制御機器メーカー、ネットワーク会社、保守会社が分かれることもあります。元請けが現地調査と実装担当を管理できるか、再委託先の責任範囲と連絡経路を確認してください。
同じ設備・規模・導入範囲の実績を確認します
実績は「製造業の導入経験あり」という業種名だけでなく、設備の種類、PLCや通信方式、収集周期、工場規模、現場端末、導入期間、段階展開の有無で確認します。日立のFactRiSM導入事例では、設備・測定機器から製造記録をMESへ自動収集し、製造記録を一元化する取り組みが紹介されています。富士通のCOLMINA事例では、生産設備の稼働状況や進捗、不具合を閉域網経由でクラウドに集約する構成が示されています。公式事例を読むときも、自社の設備接続と同じ条件かを確認することが大切です。
候補会社には、同業・同規模の事例について、導入前の課題、実装範囲、接続した設備、現場の教育方法、導入後に測ったKPI、保守体制を質問します。稼働率が上がったという結果だけでなく、停止時間、段取り時間、入力工数、不良原因の特定時間など、どの数字をどの定義で測ったかを聞くと、提案の具体性が分かります。
見積書は同じ単位にそろえて比較します
見積書は、初期費用の総額だけでなく、要件定義、現地調査、設備接続、エッジ機器、アプリ、クラウド、既存システム連携、データ移行、テスト、教育、切替、保守に分けてもらいます。設備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比較、次のラインへ展開する条件を整理します。期間は設備や契約条件によって変わるため、あくまで計画例です。
PoCの合格条件は、画面ができたことではありません。たとえば、対象設備のデータ取得率、停止理由の入力率、手作業の日報との差分、通信断からの再送、現場作業者の操作時間、改善会議での利用回数を測ります。停止時間の削減がまだ見えない場合でも、信頼できる基準値を取得できたか、次の改善仮説が立ったかを評価し、拙速に全工場展開を決めないことが重要です。
運用責任者とデータの所有権を決めます
本稼働後は、設備マスタや停止理由マスタを誰が変更するのか、データ品質の異常を誰が確認するのか、障害時に現場とベンダーへどう連絡するのかを決めます。SLAの稼働時間、一次回答、復旧目標、保守時間、脆弱性情報の通知、バックアップと復旧演習の頻度も契約に反映します。現場だけに運用を押し付けると入力が形骸化するため、工場長や生産技術、情報システム、品質、保全が参加する運用会議を設けます。
データの所有権、二次利用の範囲、学習データへの利用可否、契約終了時の返却形式、APIの利用権、ログの保存期間も確認します。ベンダーが変わっても設備データを持ち出せるよう、データ辞書、API仕様、接続設定、運用手順を成果物として受け取ります。導入時に文書化へ投資することが、将来の追加開発費と乗り換えリスクを下げます。
よくある質問(FAQ)

稼働管理システムの発注では、設備の古さ、費用、導入期間、既存システムとの連携に関する質問が多く寄せられます。ここでは、外注前に判断しやすいよう、よくある疑問へ直接回答します。
古いPLCやネットワーク未接続の設備でも発注できますか?
発注できますが、設備ごとの信号、通信方式、読み取り可否、追加センサーやゲートウェイの有無を現地調査で確認する必要があります。既存制御へ書き込まず、読み取り専用で収集できるか、通信断時にローカル保存できるかをRFPに記載してください。接続方式が不明な設備は、見積もり前の調査対象として扱うと追加費用の発生を抑えやすくなります。
予算が限られる場合はどこから外注すべきですか?
まずは1ラインの現地調査、データ棚卸し、停止理由の定義、稼働・停止・生産数の収集、簡易ダッシュボードまでに絞る方法が考えられます。リサーチノートの目安では、1ラインのPoCや小規模個別開発は300万〜1,000万円程度ですが、設備接続の難易度や端末・ネットワークの追加で変動します。価格を下げるために要件定義やテストを削るのではなく、対象設備と画面の範囲を限定し、次段階へ再利用できる設計にします。
SaaSとスクラッチ開発はどちらがよいですか?
標準的な設備接続と業務で早く始めたい場合はSaaSやパッケージ、独自工程や複雑な連携が競争力に直結する場合はセミカスタムやスクラッチが候補です。ただし、最初から全機能を決める必要はありません。1ラインのPoCでデータ品質と現場定着を確認し、標準機能で足りない部分だけを個別開発する段階導入が、判断を後ろ倒しにしながら投資リスクを抑える方法です。
稼働管理システムの外注契約で特に注意する点は何ですか?
設備接続の責任範囲、データの所有権、検収条件、通信断や欠損データの扱い、仕様変更、再委託、保守SLA、脆弱性対応、契約終了時のデータ返却を確認します。画面が完成しても、実機データが正しく集計されなければ目的を達成できません。設備ごとの受入テストと、正常系・異常系の両方を契約上の成果物や検収条件へ落とし込むことが大切です。
まとめ

稼働管理システムの発注・外注を成功させるには、設備稼働の定義と対象範囲を決め、停止理由やOEEなどのKPIを合意したうえで、設備・通信・データ・現場運用・非機能要件をRFPへ整理します。発注形態は、標準化しやすさと独自要件の強さを見て、SaaS、パッケージ、セミカスタム、スクラッチを選びます。
見積もりは総額ではなく、現地調査、設備接続、設計、実装、テスト、教育、保守の単位で比較し、含まれない作業と追加条件も確認します。委託先は、同じ設備・規模の実績、1ラインPoCの提案力、異常系テスト、OTセキュリティ、データ所有権、導入後のSLAで評価します。最初の発注を小さく始め、信頼できるデータと現場の改善行動を確認してから段階展開することが、投資と操業のリスクを抑える進め方です。
▼全体ガイドの記事
・稼働管理システム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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