停電管理システム開発の発注/外注/依頼/委託方法について

停電管理システムの発注は、対象業務を切り分け、要件を整理し、段階的に導入する順で進めると、安全性と費用を両立しやすくなります。

発注前に決めたい範囲や形態、契約、費用、委託先の選び方を、発注側の担当者の目線で順に説明します。

▼全体ガイドの記事
・停電管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

停電管理システムの概要と発注前の対象範囲

停電管理システムは、停電の発生と影響範囲、復旧状況を一元管理し、作業員の対応や顧客通知も扱います。電力会社の計画外停電を扱う場合は、OMS（Outage Management System）と呼ばれます。

OMSは、SCADAやGIS、AMIのほか、CISやCRM、現場作業管理と連携します。ただし、必要なシステムは対象業務によって異なります。

復旧対応型OMSの管理内容

復旧対応型OMSは、事故や災害による計画外停電を把握し、復旧の優先順位を判断するシステムです。主な処理は、通報や遮断器、スマートメーターのイベントを、GISの系統モデルと照合することです。

• 影響把握：故障箇所と影響顧客の推定。
• 復旧支援：作業員の手配と、復旧予定時刻の通知を支援します。
• 作業記録：復旧作業の結果の記録。

FLISR（Fault Location, Isolation and Service Restoration）を採用すると、故障位置の推定を支援できます。また、事故区間の切り離しや、健全区間への送電復旧候補の生成も支援できます。

自動開閉器を操作する場合は、権限分離と承認、手動介入を要件にします。加えて、通信断時の安全動作と監査ログも欠かせません。

日立エナジーの公式情報では、OMS/ADMSはSCADAやIEC 61850と連携する領域とされています。作業員管理や顧客通知なども、同じ連携の範囲に含まれます。

計画停電と施設の電源監視の切り分け

発注対象は、停電の目的と、必要な監視・復旧業務を基準に切り分けます。

• 計画停電：事故復旧型OMSとは目的が異なり、経済産業省の資料では設備ごとの停電作業計画情報を指します。
• 発注要件：対象が計画作成から実績管理までか、事故検知・復旧判断かを明記します。
• 施設監視：工場や病院、データセンターでは、UPSや発電機、受変電設備を監視します。電源品質やBCP通知も対象です。
• 方式選定：既製パッケージとクラウド監視を比べ、配電網の自動切替が必要かを見極めます。
• 導入範囲：電力会社向けOMSをそのまま使うと、不要な機能や運用負荷を抱えるおそれがあります。

停電管理システムの発注形態の選び方

発注形態は、既存設備のメーカーや制御範囲をもとに、社内の運用担当者や切替可能な期間と照らし合わせて選びます。

単一ベンダーへの一括委託が向くケース

一括委託を検討する場合は、統合責任と契約終了後の引き渡し条件をセットで見ます。

• 委託範囲：制御機器やSCADA、GIS、OMSに、通信と現地試験を加えて一括し、24時間運用や広域の冗長化も一体で設計できます。
• 障害対応：機器、連携、アプリの問題を、発注者だけで切り分けずに済みます。
• 依存リスク：追加機能の価格や保守条件を比べにくくなる場合があります。
• 所有権：ソースコードや系統モデル、IF仕様の所有者を決めます。設定値や試験成績、脆弱性情報、運用手順も対象です。
• 契約終了：引き渡し形式と、再委託先を含む主契約者の全体責任を確かめておきます。

パッケージと国内SIerを組み合わせるケース

標準製品を活用する場合は、国内業務への適合と責任範囲を先に確かめておく必要があります。

• 役割分担：製品はOMS/ADMSを選び、要件整理と連携、移行、現場教育は国内SIerに委託します。
• 国内適合：海外製品のロードマップや大量メーター対応を生かし、配電設備と帳票を国内向けに調整します。承認や保守窓口も対象です。
• 責任範囲：ライセンスとカスタマイズを分けたうえで、標準機能が追加開発に当たるかを確かめます。
• 更新費用：アップデートで機能が保たれるか、改修費が発生するかを見極めます。
• 見積内訳：ライセンスや導入、追加開発の各項目を、クラウドや保守と分けて比べます。

電気設備会社とIT会社を分けて発注するケース

設備工事とOMS開発を分けて発注する場合は、接続仕様と試験責任を両社で共有することが欠かせません。

• 設備工事：受変電設備や自動開閉器を含む機器類を、電気設備会社に任せます。保護リレーと通信機器も対象です。
• システム開発：OMSのアプリとデータ連携をIT会社に任せます。既存メーカーを維持したい場合に向いた形です。
• 責任分界：主契約者と試験責任者、障害時の一次窓口を決めます。
• 共通仕様：通信プロトコルと時刻同期、点数表をそろえます。信号の意味や異常値、現地試験手順も含みます。
• 試験方法：両社が同じテストケースで確かめられる形にします。

既存SCADAを残した段階発注

既存SCADAは残したまま、現場データと操作の負荷を確かめながら、段階的に範囲を広げます。

• 初期導入：自動制御は含めず、イベント収集とGIS表示、復旧共有、顧客通知から始めます。
• 段階拡張：判断支援の後に自動開閉器の操作へ進み、データ欠損や現場負荷を確かめます。
• 追加接続：AMIや現場モバイルを後から追加できるよう、APIを初回契約の要件に入れます。
• 再利用性：系統モデルを再利用しやすい形式と、環境を増やせる認証方式を要件にします。
• 納品物：第一段階の成果を次の段階でも使える状態にして、総額を抑えながら導入範囲を広げます。

RFPと要件整理の記載項目

RFPは、画面の依頼文というより、現状と業務効果、対象設備を一式でそろえる資料です。データ量や制御範囲、非機能要件などに加え、納品物と評価方法も書きます。

記載項目がそろっていれば、委託先は同じ前提で提案でき、価格だけでなく実現方法とリスクも比べられます。

現状調査によるシステムとデータの境界の洗い出し

RFPを書く前に、既存システムとデータの範囲や品質、規模を把握しておきます。

• 対象一覧：SCADAやDMS、GIS、AMIのほか、MDMやCIS/CRM、設備台帳、作業管理、顧客通知を一覧にします。
• 運用・保守情報：認証とバックアップの環境、所有部署、更新頻度を確かめます。連携方式や代替手順、保守期限、ベンダー窓口も含めます。
• データ品質：系統モデルが実際と食い違っていると、OMSは影響範囲を正しく推定できません。
• 処理規模：フィーダーや変電所・開閉器の数、イベント量を数えます。同時多発停電時の端末台数と通知件数もRFPに書きます。
• 想定と先行調査：規模が未確定なら最小・標準・最大の3案を置きます。入力が足りないときは、調査やPoCを先に発注できます。

復旧業務の流れに沿った機能要件

機能要件は、通報の取り込みから復旧実績、信頼度指標、監査ログまでを、業務のシナリオに沿って書きます。

• 停電把握：イベントの統合と故障位置の推定、影響範囲の表示を定義します。
• 復旧対応：優先順位、作業員の割当、復旧予定時刻の更新を含みます。
• 顧客対応：通知と復旧実績、信頼度指標、監査ログの扱い。

地震による同時停電や通信断、誤った設備データが届いた場合の処理も書きます。

自動制御では、操作する設備と役割、承認者を具体化します。事前確認や操作後の応答、失敗時の戻し方も詰めておきます。

AIの異常検知や復旧候補は、まず参照と判断支援として検証します。制御を自動化するなら、別の安全審査と受入条件を立てたうえで、復旧時間や誤判断の削減をもとに効果を判断します。

数値で指定する非機能要件と試験条件

非機能要件は、運用の継続性と、試験で判定できる数値をセットで定めます。

• 性能・可用性：可用性と遅延、同時接続数を定めます。保持期間やRTO、RPOも含めます。
• 運用要件：バックアップや災害切替、監視、ログ、権限を含めます。脆弱性対応と保守時間も入れます。
• 数値基準：「高速」「止まらない」といった表現は避け、反映秒数や同時処理件数、復旧目標時間で指定します。
• 分析の考え方：IPAの2026年4月版ガイドでは、資産と事業被害の両面からリスクを見ます。

RFPでは、制御センターや端末、通信機器を資産として扱います。外部サービスや委託先との接続も資産に含めます。そのうえで、停電の長期化や誤操作による事業被害をもとに、対策を確かめます（出典: IPA「制御システムのセキュリティリスク分析ガイド 第2版」、2026年4月版）。

停電管理システムの契約形態の選び方

契約形態は、要件がどこまで決まっているか、既存設備との接続や現地試験、運用継続の責任に応じて使い分けます。

特に、要件が固まる前に完成品の価格だけを固定すると、前提外の変更が追加費用や遅延につながりやすくなります。

準委任契約が向く調査・要件定義

作業や成果が変わりやすい上流工程では、進め方と成果物を契約でそろえておきます。

• 対象工程：現状調査や業務整理、RFP支援、PoC、技術検証が候補です。
• 進め方：定例会議で課題を解きながら、調査結果や成果を段階的にまとめます。
• 契約事項：担当者と稼働想定、会議体、成果物、意思決定期限を明記。
• レビュー：請負とは完成責任が異なるため、要件書やPoC報告書の見方を決めておきます。
• 次工程：次へ進む判定基準を、事前に合意しておきます。

範囲と受入条件を固めた請負契約

成果物と受入条件を定義できる工程では、完成責任と前提条件を明確にしたうえで契約します。

• 対象工程：基本設計や連携・画面開発、移行、試験が候補です。
• 管理事項：完成責任と納品日、瑕疵対応、検収方法を明確にしておきます。
• 未確定条件：機器仕様や系統モデル、第三者APIが未確定だと、前提の変更が争点になりやすいです。
• 契約記載：提供資料や第三者の期限、変更管理に加え、追加費用と納期見直しの条件も定めます。

段階契約と変更管理の組み合わせ

工程ごとに契約を分け、変更内容と影響を記録しておけば、後から経緯を追えます。

• 契約の組合せ：調査・要件定義は準委任、PoC・基本設計は成果物ベース、開発・移行・試験は請負にします。
• 運用改善：準委任または保守契約とし、成果物と次工程の判断会議を設定します。
• 変更記録：変更の理由や対象機能、工数、費用、納期を変更票に残します。試験範囲と承認者も同じ票に書きます。
• 口頭変更：口頭のまま放置すると、標準機能か追加開発かが分からなくなります。
• 安全関連：開閉器の制御範囲や通知先の追加は、画面変更とは切り離して扱います。

停電管理システムの費用相場

停電管理システムには、全国共通の公開定価がありません。費用は設備数や既存システム、制御範囲で変わり、工事や冗長化、セキュリティ、保守時間も影響します。

次の金額は、一般業務システムの2025〜2026年相場をもとに、OMS連携を想定して推定したものです。OMS専用の公定価格ではないため、発注時は前提条件とあわせて示す必要があります。

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

導入規模と範囲により、初期費用と期間の目安は次のように変わります。

• 限定PoC：1,000万〜3,000万円、3〜6か月。数フィーダーなどを対象に、通報とGIS表示、通知、連携を検証します。
• 基本導入：5,000万〜2億円、9〜18か月。標準OMS設定と系統モデル、GIS・CIS・AMI連携を含み、訓練や受入試験も入ります。
• 中規模導入：2億〜10億円、18〜36か月。SCADAやGIS、AMIのほか、現場作業と顧客通知まで含みます。
• 広域更改：10億〜50億円超、3〜5年。広域ADMS/OMS更改や大規模スクラッチが該当します。
• 比較条件：連携や機器、試験、運用範囲によって増減します。一般業務システムでも、パッケージかカスタマイズか、スクラッチかで金額と期間が変わります。

上記の数字は推定なので、一つの金額だけで比べないようにします（出典: ノーコード総合研究所「業務システム開発の費用相場」、2026年、およびHarmonic Society「2025年版 業務システム開発費の相場」、2025年）。

連携・機器・試験で分けた見積の内訳

比較のため、見積は費用項目ごとに分けて書いてもらいます。

• 開発・製品：要件定義や業務設計、アプリ開発、製品ライセンスを、それぞれ別の項目にします。
• 連携・設備：SCADA/GIS/AMI/CIS連携と、系統モデルやマスタデータの整備を分けます。現場機器と通信も別にします。
• 品質・導入：冗長化やセキュリティ、性能・総合試験に加え、教育・移行、プロジェクト管理も分けます。

一式見積は安く見えても、別途費用が多い場合があります。

関西電力送配電の事例では、1,400万台の基盤を止めずに段階移行しました。AWS事例は、10年間のTCOを13％削減できる見込みとしています。

なお、AWS事例では、開発サイクルは従来の3〜4年から2〜3年へ短縮し、PoCサイクルは4か月程度としています。これらはOMSの価格ではありません。

クラウド等の比較では、初期費用だけでなく移行期間、運用人員、10年TCOも見ます（出典：AWS「Kansai T&D modernizes 14M smart meters on AWS with zero downtime」、2026年掲載）。

ランニング費用に含める保守・クラウド・現地対応

初期費用だけでなく、継続利用と安全な運用に欠かせない費用も見積もります。

• 継続費：保守、クラウド、DB・監視、閉域網、バックアップ、24時間対応のほか、脆弱性診断、現地保守、機器更新、教育、改修。
• 保守費：初期費用の年10〜20％を仮置きする場合があります。SLAと作業内容も確かめます。
• 構成：クラウドを使うことは、制御系を直接インターネットへ公開することを意味しません。
• 接続要件：エッジと閉域網の構成、認証、監視を検討します。バックアップやオンプレミス接続も含みます。
• 継続性：通信断時に現場で安全に動き続けられるかを確かめ、訓練や更新費も含めて判断します。

委託先の選定と見積比較の確認項目

知名度や総額だけでなく、OMS/ADMSや国内電力設備、OT連携、大量データへの強みを比べます。相互運用性や現場作業、顧客通知、長期保守も評価します。提案は、同じRFPと評価表をもとに確かめます。

担当範囲で見る実績の確認

実績の有無だけでなく、担当工程と運用経験の中身を確かめます。

• 連携範囲：SCADAやGISとの連携にとどまるか、故障位置推定やFLISRまで手がけたかを見ます。
• 現場経験：機器設定や現地試験、24時間運用後の保守を担当した経験の有無。
• 成果資料：類似案件の性能試験や災害時訓練、障害報告、移行手順を見せてもらいます。
• 匿名情報：顧客名を伏せ、設備数やイベント量、可用性、切替方法、体制、保守時間を説明できるかを尋ねます。前提を整理する力の表れかもしれません。

同じ前提と責任分界による見積比較

同じ前提と評価軸をそろえてから、見積の抜けと提案の差を確かめます。

• 共通前提：範囲や設備、連携、イベント量、稼働時間をそろえます。試験や教育、移行、保守、税区分も含めます。
• 別項目：既存改修や第三者調整、出張、通信、更新、休日夜間切替は、別々に示してもらいます。
• 見積確認：安さが必要な作業の除外によるものではないかを見極めます。
• 評価軸：要件適合、連携、制御安全性、試験・移行計画、保守体制で見ます。
• 将来性・公平性：データ可搬性、再委託管理、拡張性の比率を事前に決めます。営業の印象やデモの見栄えで順位を変えません。

実機デモと災害シナリオ試験による運用力の確認

提案の時点で自社データを使い、停電の発生から復旧後まで、実機の動きを確かめます。

• デモデータ：系統モデルや過去の停電データを使い、架空画面の説明だけで終わらせません。
• 業務確認：重複通報やGIS影響範囲、復旧候補、作業員通知、顧客表示、監査ログを順に追います。
• 障害条件：広域災害と通信断、イベント急増、モデル誤り、センサー異常の各ケースで試します。
• 復旧条件：開閉器の操作失敗や主センターの停止、バックアップへの切替、権限外の操作。
• 体制確認：検知、判断、承認、操作、復旧、報告の各段階で、誰が何をするかを確かめます。

発注後の開発・移行・セキュリティの進め方

契約後は、基本設計と連携開発を経て、系統モデルの整備と各種試験に入ります。その後は、並行運用と切替、現場訓練、障害訓練の順に行います。

試験には、単体と結合、性能、セキュリティ試験のほか、現地と総合の試験を含めます。そのうえで、各工程に中間成果物を置きます。

並行運用と段階切替を前提とした移行

停電対応の安全を保つため、並行運用と小さな範囲からの切替を計画します。

• 検証範囲：限定拠点やフィーダーで試し、新旧の結果を比べてから広げます。
• 移行データ：変換や時刻、設備IDと顧客ID、通知先、権限、未処理イベントを確かめます。
• 切替計画：開始条件や作業時間、担当、連絡網、戻し方、判断者、周知、監視期間を盛り込みます。
• 参考事例：AWSのスマートメーター基盤は1,400万台規模で段階移行し、ほぼ停止なしの運用を計画しています。
• 適用方針：停電管理システムでも、規模に応じて小さく切り替えます。

契約に入れるサプライチェーンと制御系の安全要件

関係する事業者と制御系のリスクを洗い出し、その内容を契約と運用手順に落とし込みます。

• 関係者：開発や製品、通信、機器、クラウドの各社と、再委託先を把握します。
• 供給網：再委託先や機器・ソフトの真正性、脆弱性、更新、アクセス権を確かめます。
• 記録と報告：ログや事故報告、外部記憶媒体の扱いを定めます。
• アクセス対策：ネットワーク分離に加えて、多要素認証や特権IDの期限、遠隔保守の承認を決めます。
• 運用・緊急時：暗号化や復元試験、ログ改ざん対策、脆弱性評価、パッチ方針を定めます。代替策（即時適用が難しい場合）と判断者も、契約と手順に残します。

経済産業省は2025年6月、電気事業者向けの対策手引きを公表しました（出典: 経済産業省「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年6月）。

受入条件とする導入後のKPIと運用体制

導入前後の指標と運用責任者を決め、受入のあとも改善の状況を追い続けます。

• 応答指標：検知から影響範囲の確定まで、通報処理と作業員の出動時間を測ります。
• 復旧指標：予定時刻の精度と通知到達率、SAIDI/SAIFI、手動切替、誤操作を見ます。
• 比較時期：導入前に基準値を取り、3か月後、6か月後、1年後と比べます。
• 責任者：監視や障害判断、ベンダー連絡、現場指示、顧客通知、セキュリティ対応の担当を割り当てます。
• 社内知識と移管：発注者側に、運用資料を読める担当者を置きます。

担当者には、系統モデルや設定、ログ、試験結果、変更履歴を読める力が求められます。それにより、委託先を替えられる状態を保ち、長期のベンダーロックインを抑えられます。

よくある質問（FAQ）

停電管理システムでは、費用だけでなく、対象業務や連携範囲、安全性、保守まで確かめる必要があります。

停電管理システムの開発費用は最低いくらですか？

限定拠点の調査・PoC・停電可視化であれば、1,000万〜3,000万円程度から検討するケースがあります。

この金額は、設備や連携、通知、試験を限った推定で、OMS全体の価格を示すものではありません。自動制御や冗長化、現場工事、24時間保守を含めると、数億円以上になる可能性があります。

パッケージとスクラッチ開発はどちらが良いですか？

標準機能を使うか、業務に合わせて作り込むかで比べます。

• パッケージ：標準OMS機能や実績、保守アップデートを優先するなら候補になります。
• スクラッチ：独自の系統モデルや業務フローを作り込めます。その分、長期の要員確保、テスト、保守、仕様変更、引き継ぎの負担が増えます。
• 段階導入：既存SCADAを残し、可視化と通知から導入する方法も有効です。

RFPを作れない状態でも外注できますか？

外注はできます。本開発の前に、現状調査や要件定義支援を先に発注する方法もあります。

まず、対象設備と既存システムを整理し、停電時の業務や必要なKPIも洗い出します。そのうえでPoCで連携を検証してからRFPを作ると、見積の前提がそろいやすくなります。

発注時にセキュリティで最も注意する点は何ですか？

最も注意したいのは、サプライチェーンと制御系の責任分界を曖昧にしないことです。

再委託や遠隔保守、更新、脆弱性情報に加え、ログやバックアップ、事故報告期限も契約に記載します。さらに、権限外操作への対策と、通信断・災害時の安全動作を実機または試験環境で確認します。

まとめ

発注前には、復旧対応型OMS、計画停電管理、施設の電源監視を切り分けておきます。

そのうえで、対象設備と既存システムを調べ、可視化、判断支援、自動制御の順に必要な範囲を決めていきます。

同じ前提で比較する発注のポイント

発注方式とRFP、契約の前提をそろえ、比べられる形にしておきます。

• 発注形態：一括委託、パッケージとSIer、設備会社とIT会社の分担、段階発注のなかから選びます。
• RFP：機能やイベント量、連携先、RTO/RPO、冗長化、災害シナリオ、受入条件を書きます。
• 契約条件：データの所有権や再委託の管理、保守終了時の移行支援を明記します。
• 契約形態：調査と要件定義は準委任、範囲が決まった後の開発と試験は請負に分けます。

最初の一歩：現状調査と小さなPoC

必要な範囲をはっきりさせるため、費用の幅と導入リスクを段階的に確かめます。

• 限定PoC：推定1,000万〜3,000万円です。
• パッケージ：基本導入の推定は5,000万〜2億円です。
• 中規模導入：複数システム連携を含む場合、2億〜10億円程度が目安です。
• 比較項目：現場データや実機デモ、災害試験、移行、セキュリティ、10年単位の保守費を見比べます。
• 着手方法：現状調査と小さなPoCを外注し、自社に必要な範囲をはっきりさせます。

▼全体ガイドの記事
・停電管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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