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

停電管理システムの開発を発注・外注するなら、最初に「停電情報の見える化」「復旧判断の支援」「設備の自動制御」のどこまでを対象にするかを決めることが重要です。対象範囲を曖昧にしたまま見積を依頼すると、SCADAやGISとの連携、現場機器、冗長化、セキュリティ試験が後から追加され、費用と納期が大きく変わるためです。

この記事では、停電管理システムを発注・外注・委託するときの進め方を、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法まで順番に解説します。電力会社向けのOMSだけでなく、工場やデータセンターの電源監視を検討している方にも、必要な機能と発注範囲を切り分ける視点を紹介します。

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

停電管理システムとは何ですか？発注前に対象範囲を分けます

停電管理システムは、停電の発生、影響範囲、復旧状況、作業員の対応、顧客への通知などを一元管理する仕組みです。電力会社の計画外停電を扱う場合はOMS（Outage Management System）と呼ばれ、SCADA、GIS、AMI、CISやCRM、現場作業管理と連携して使われます。ただし、同じ「停電管理」という言葉でも、対象業務によって発注すべきシステムは変わります。

復旧対応型OMSは、事故や災害などで発生した計画外停電を早く把握し、復旧の優先順位を判断するためのシステムです。停電通報、遮断器やスマートメーターのイベントを受け取り、GIS上の系統モデルと照合して、故障箇所や影響顧客を推定します。その後、復旧作業員の手配、復旧予定時刻の通知、作業結果の記録までをつなげます。

FLISR（Fault Location, Isolation and Service Restoration）を採用すると、故障位置の推定、事故区間の切り離し、健全区間への送電復旧候補の生成を支援できます。自動開閉器を操作する範囲まで含める場合は、権限分離、承認、手動介入、通信断時の安全側動作、監査ログを要件に入れます。日立エナジーの公式情報でも、OMS/ADMSはSCADA、IEC 61850、作業員管理、顧客通知などを連携する領域として整理されています。

設備の点検や工事に伴う計画停電の作業計画を管理するシステムは、事故復旧型OMSとは目的が異なります。経済産業省の資料でも、設備ごとの停電作業計画に関する情報を管理するシステムという意味で「停電管理」が使われています。発注時は、計画作成、承認、関係者への通知、実績管理が中心なのか、リアルタイムの事故検知と復旧判断が中心なのかを明記します。

工場、病院、データセンターでは、UPS、非常用発電機、受変電設備、電源品質、BCP通知を一体で監視したいケースがあります。この場合は、まず電源監視や設備管理の既製パッケージ、クラウド監視を比較し、配電網の自動切替まで必要かを確認します。電力会社向けOMSの構成をそのまま導入すると、不要な制御機能や高い運用負荷まで抱える可能性があります。

停電管理システムの発注形態はどれを選びますか？

発注形態は、単一ベンダーへの一括委託、OMSパッケージと国内SIerの組み合わせ、電気設備会社とIT会社の共同体制、既存SCADAを残す段階発注の4パターンで考えると整理しやすいです。最適な形は企業規模だけでなく、既存設備のメーカー、制御範囲、社内にいる運用担当者、切替可能な期間によって決まります。

制御機器、SCADA、GIS、OMS、通信、現地試験までを一社または主契約者がまとめる形は、責任分界を明確にしやすい方法です。障害が起きたときに「機器の問題か、連携の問題か、アプリの問題か」を発注者側だけで切り分ける必要がなく、24時間運用や広域の冗長化を一体設計しやすくなります。

一方で、単一ベンダーに依存すると、追加機能の価格や保守条件を比較しにくくなります。ソースコードだけでなく、系統モデル、インターフェース仕様、設定値、試験成績、脆弱性情報、運用手順を誰が所有し、契約終了時にどの形式で引き渡すかを先に決めます。再委託先が複数ある場合は、主契約者が全体責任を負う条項も確認します。

OMSやADMSの標準製品を選び、国内SIerに要件整理、既存システム連携、データ移行、現場教育を委託する形は、標準機能を活用しながら国内業務に合わせやすい方法です。海外製品のロードマップや大量メーター対応を活かしつつ、国内の配電設備、帳票、承認手順、保守窓口を調整できます。

この発注形態では、製品ライセンスの責任とカスタマイズの責任を分けて記載します。標準機能に見える部分が追加開発扱いなのか、製品アップデートで維持されるのか、バージョンアップ時に改修費が必要なのかを確認します。見積では、ライセンス、導入サービス、追加開発、クラウド利用、保守を別項目に分けると、複数社を比較しやすくなります。

受変電設備、自動開閉器、保護リレー、通信機器の現地施工を電気設備会社に任せ、OMSのアプリやデータ連携をIT会社に委託する方法です。既存の設備メーカーを維持したい場合や、現場工事と業務システムで専門会社を使い分けたい場合に適しています。

ただし、インターフェースの境界で不具合が起きやすいため、主契約者、試験責任者、障害時の一次窓口を明確にします。通信プロトコル、時刻同期、点数表、信号の意味、異常値の扱い、現地試験の手順を共通仕様にし、IT会社と電気設備会社が同じテストケースで確認できるようにします。

最初から自動制御まで含めず、停電イベントの収集とGIS表示、復旧状況の共有、顧客通知から始める段階発注も有力です。次に復旧候補の判断支援、最後に自動開閉器操作へ広げると、データ欠損や現場の操作負荷を確認しながらリスクを抑えられます。

段階発注では、初回契約の時点で将来フェーズの接続条件を決めます。たとえば、後からAMIや現場モバイルを追加できるAPI、系統モデルを再利用できるデータ形式、環境を増やせる認証方式を要件にします。第一段階の納品物を使い捨てにしないことが、総額を抑えながら導入範囲を広げるポイントです。

RFPと要件整理では何を記載しますか？

RFPは「画面を作ってほしい」という依頼文ではなく、現状、達成したい業務効果、対象設備、データ量、制御範囲、非機能要件、納品物、評価方法をそろえた発注資料です。委託先が同じ前提で提案できるようにし、価格だけでなく、実現方法とリスクを比較できる状態にします。

最初に、SCADA、DMS、GIS、AMI、MDM、CISやCRM、設備台帳、作業管理、顧客通知、認証基盤、バックアップ環境を一覧にします。各システムの所有部署、データの更新頻度、連携方式、障害時の代替手順、保守期限、ベンダー窓口を確認します。設備台帳とGISの系統モデルが一致していない場合、OMSの画面を作り込んでも影響範囲の推定が正しくならないため、データ品質を要件の前に調べます。

RFPには、対象フィーダー数、変電所や開閉器の点数、スマートメーターや通報のイベント量、同時多発停電の想定、現場端末の台数、顧客通知の件数を記載します。まだ確定できない場合も、最小・標準・最大の3パターンを示します。入力データが不足する場合は、現状調査やPoCを先行発注する方法もあります。

機能要件は、通報・イベントの取り込み、停電の重複統合、故障位置の推定、影響範囲の表示、復旧優先順位の設定、作業員の割り当て、復旧予定時刻の更新、顧客通知、復旧実績、信頼度指標、監査ログの順に業務シナリオで整理します。担当者が使う画面の一覧だけでなく、「地震で複数地域が同時に停電したとき」「通信が一部断になったとき」「誤った設備データが届いたとき」の処理も書きます。

自動制御を含める場合は、操作可能な設備、操作できる役割、承認者、操作前の確認、操作後のフィードバック、失敗時の戻し方を具体化します。AIによる異常検知や復旧候補の提示は、まず参照・判断支援として検証し、制御操作を自動化する場合は別の安全審査と受入条件を設定します。AIを導入すること自体を目的にせず、復旧時間や誤判断の削減に結びつくかで判断します。

非機能要件には、可用性、処理遅延、同時接続数、データ保持期間、RTO、RPO、バックアップ、災害時の切替、監視、ログ、権限管理、脆弱性対応、保守時間を含めます。「高速」「止まらない」と書くのではなく、停電イベントを何秒以内に画面へ反映するか、何件を同時処理するか、復旧目標を何分にするかまで落とします。

2026年4月版のIPA「制御システムのセキュリティリスク分析ガイド 第2版」では、資産ベースと事業被害ベースのリスク分析が示されています。RFPでも、制御センター、現場端末、通信機器、外部サービス、委託先の接続を資産として整理し、停電の長期化や誤操作などの事業被害から対策を確認します（出典: IPA「制御システムのセキュリティリスク分析ガイド 第2版」、2026年4月版）。

停電管理システムの契約形態はどう選びますか？

停電管理システムは、要件の不確実性、既存設備との接続、現地試験、運用継続の責任が大きいため、工程ごとに契約形態を使い分けることが現実的です。要件を固める前から完成品の価格だけを固定すると、前提外の変更が追加費用や納期遅延として表れやすくなります。

現状調査、業務整理、RFP作成支援、PoC、技術検証のように、作業量や成果の形が変わりやすい工程は準委任契約と相性があります。発注者と受託者が定例会議で課題を解き、調査結果や要件一覧、検証報告書を段階的にまとめます。

準委任契約では、作業時間だけでなく、担当者、稼働想定、会議体、成果物、意思決定の期限を明記します。成果物の完成責任をどこまで負うかは請負契約と異なるため、要件定義書やPoC報告書のレビュー方法、次工程へ進む判定基準を合意しておきます。

基本設計、連携開発、画面開発、データ移行、試験など、成果物と受入条件を定義できる工程は請負契約にしやすいです。完成責任、納品日、瑕疵への対応、検収方法が明確になるため、発注者が予算とマイルストーンを管理しやすくなります。

ただし、現場機器の仕様が未確定、系統モデルの品質が不明、第三者ベンダーのAPIが未提供という状態で全工程を請負にすると、前提条件の変更が争点になります。契約書には、発注者の提供資料、第三者の対応期限、変更管理、追加費用の算定方法、納期の見直し条件を明記します。

実務では、調査・要件定義を準委任、PoCと基本設計を成果物ベース、開発・移行・試験を請負、運用改善を準委任または保守契約とする組み合わせが使いやすいです。各契約の終了時に、次工程へ進むための成果物と判断会議を設定すると、発注者が不要な開発を抱えにくくなります。

変更管理票には、変更理由、影響する機能、工数、費用、納期、試験範囲、承認者を記録します。口頭で決まった仕様変更を放置すると、後で「標準機能か追加開発か」が分からなくなります。特に、開閉器の制御範囲や通知先の追加は安全と運用に影響するため、軽微な画面変更と同じ扱いにしないことが大切です。

停電管理システムの費用相場はいくらですか？

停電管理システムに全国共通の公開定価はなく、対象設備数、既存システム、制御範囲、現地工事、冗長化、セキュリティ、保守時間によって費用が変わります。以下は一般業務システムの2025〜2026年相場と、OMSに必要なSCADA・GIS・AMI・現場連携を前提にした推定です。OMS専用の公定価格ではないため、発注時は必ず前提条件とセットで提示します。

調査・PoC・限定拠点の停電可視化であれば、初期費用は1,000万〜3,000万円、期間は3〜6か月が一つの目安です。数フィーダーや限定拠点で通報、GIS表示、通知、データ連携を検証する範囲を想定します。

OMSパッケージやクラウドの基本導入では、5,000万〜2億円、9〜18か月程度が目安です。標準OMSの設定に加えて、系統モデル、GIS、CIS、AMIとの接続、操作訓練、受入試験を含めます。SCADA、GIS、AMI、現場作業、顧客通知を含む中規模導入では2億〜10億円、18〜36か月程度を見込みます。広域事業者向けのADMS/OMS更改や大規模スクラッチは10億〜50億円超、3〜5年に及ぶ可能性があります。

これらは、システムの大きさだけでなく、連携・機器・試験・運用の範囲で増減します。一般的な業務システムの相場でも、パッケージ導入、カスタマイズ、スクラッチ開発で金額と期間が大きく変わるため、費用を一つの数字で比較しないことが重要です（出典: ノーコード総合研究所「業務システム開発の費用相場」、2026年、およびHarmonic Society「2025年版 業務システム開発費の相場」、2025年をもとにした推定）。

比較用の見積では、要件定義・業務設計、アプリ開発、製品ライセンス、SCADA/GIS/AMI/CIS連携、系統モデルやマスタデータ整備、現場機器と通信、冗長化、セキュリティ、性能・総合試験、教育・移行、プロジェクト管理を分けて記載してもらいます。これらを一式にまとめた見積は、安く見えても、別途費用が多い場合があります。

関西電力送配電のスマートメーター基盤では、1,400万台の運用を止めずに段階移行し、AWSの事例では10年間のTCOを13％削減できる見込み、開発サイクルを従来の3〜4年から2〜3年へ短縮、PoCサイクルを4か月程度としています。これはOMSの価格ではありませんが、クラウドやマネージドサービスを比較するときに、初期費用だけでなく移行期間、運用人員、10年TCOを見るべき理由を示す事例です（出典: AWS「Kansai T&D modernizes 14M smart meters on AWS with zero downtime」、2026年掲載）。

初期費用以外には、製品保守、クラウド利用料、データベースや監視の利用料、閉域網、バックアップ、24時間の監視・障害対応、脆弱性診断、現地保守、機器の更新、教育、制度変更や設備追加に伴う改修が発生します。保守費は初期費用の年10〜20％を仮置きすることがありますが、製品や対応時間によって変わるため、金額だけでなく含まれるSLAと作業を確認します。

クラウドを使う場合も、制御系を直接インターネットへ公開するという意味ではありません。エッジ、閉域網、認証、監視、バックアップ、オンプレミスとの接続を含むハイブリッド構成を候補にし、通信断時に現場側だけで安全に継続できるかを確認します。クラウドとオンプレミスを価格だけで比較せず、障害訓練と更新作業を含めた運用費で判断します。

委託先の選定と見積比較では何を確認しますか？

委託先は、知名度や見積総額だけで決めず、OMS/ADMSの標準機能、国内の電力設備やOT連携、大量データ、相互運用性、現場作業、顧客通知、長期保守のどこに強いかで比較します。候補会社には同じRFPを渡し、提案書、見積書、実機デモ、災害シナリオの回答を同じ評価表で確認します。

「電力向けの実績がある」という説明だけでなく、どの範囲を担当したかを確認します。SCADAやGISとの連携だけなのか、OMSの故障位置推定やFLISRまで含むのか、現場機器の設定や現地試験を担当したのか、24時間運用後の保守を継続しているのかで、実績の意味は変わります。

可能であれば、類似規模の案件で使った性能試験、災害時の切替訓練、障害報告、移行手順のサンプルを確認します。顧客名や構成の開示が難しい場合でも、対象設備数、イベント量、可用性、切替方法、体制、保守時間を匿名化して説明できる会社は、提案の前提を整理する力を持っている可能性があります。

見積比較では、対象範囲、対象設備、連携先、イベント量、稼働時間、試験範囲、教育、移行、保守、税区分をそろえます。特に、既存システムの改修費、第三者ベンダーとの調整費、現地出張費、通信費、ライセンス更新費、休日夜間の切替費を別項目にしてもらいます。安い見積が、必要な作業を除外した結果ではないかを確認します。

提案の評価は、価格だけでなく、要件適合度、データ連携の実現性、制御の安全性、試験計画、移行計画、保守体制、データの可搬性、再委託管理、将来拡張のしやすさで行います。評価比率をあらかじめ決め、営業担当の印象やデモ画面の見栄えだけで順位が変わらないようにします。

提案段階では、架空の画面説明だけでなく、自社のサンプル系統モデルや過去の停電データを使った実機デモを依頼します。複数の通報が同時に入ったときの重複処理、GISでの影響範囲、復旧候補、作業員への通知、顧客への表示、復旧後の監査ログを一連の流れで確認します。

試験シナリオには、広域災害、通信断、停電イベントの急増、系統モデルの誤り、センサー異常、開閉器操作の失敗、主センター停止、バックアップセンター切替、権限のない操作の試行を含めます。ベンダーが「対応できます」と答えるだけでなく、検知、判断、承認、操作、復旧、報告の各段階で誰が何をするかを説明できるかが選定のポイントです。

発注後の開発・移行・セキュリティはどう進めますか？

契約と委託先が決まった後は、基本設計、インターフェース開発、系統モデルの整備、単体・結合・性能・セキュリティ・現地・総合試験、並行運用、夜間や休日の切替、現場訓練、障害訓練の順で進めます。納品日だけで管理せず、各工程で業務担当者が確認できる中間成果物を置きます。

停電対応は日常業務と安全に直結するため、旧システムを一度に停止するのではなく、限定拠点や限定フィーダーで検証し、旧新の結果を比較してから対象を広げます。移行前に、データ変換、時刻の扱い、設備ID、顧客ID、通知先、権限、未処理イベントの引き継ぎ方法を確認します。

切替計画には、切替開始条件、作業時間、担当者、連絡網、戻し方、判断者、顧客や現場への周知、切替後の監視期間を含めます。AWSのスマートメーター事例でも、1,400万台規模の基盤を段階的に移行し、ほぼ停止なしで運用する計画が取られています。停電管理システムでも、規模に応じて小さな範囲から切り替えることが重要です。

停電管理システムは、アプリ開発会社だけでなく、製品ベンダー、通信会社、機器メーカー、クラウド事業者、再委託先が関わります。経済産業省は2025年6月に、電気事業者に求められる具体的なサプライチェーン・セキュリティ対策を支援する手引きを公表しています。RFPと契約では、再委託先の把握、機器やソフトウェアの真正性、脆弱性情報、更新、アクセス権、ログ、インシデント報告、外部記憶媒体の扱いを確認します（出典: 経済産業省「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年6月）。

ネットワークを分離するだけでは十分ではありません。管理者の多要素認証、特権IDの期限管理、遠隔保守の承認、通信の暗号化、バックアップの復元試験、ログの改ざん対策、脆弱性の評価とパッチ適用方針を決めます。制御系は可用性と安全性を優先して、パッチを即時適用できない場合の代替対策と、緊急時の判断者を契約書と運用手順に残します。

稼働後は、停電の検知から影響範囲の確定までの時間、通報処理時間、復旧作業員の出動時間、復旧予定時刻の更新精度、顧客通知の到達率、SAIDIやSAIFI、手動操作への切替回数、誤操作件数を確認します。導入前の基準値を測り、3か月後、6か月後、1年後に同じ指標を比較できるようにします。

運用体制では、一次監視、障害判断、ベンダー連絡、現場への指示、顧客通知、セキュリティインシデント対応の責任者を決めます。ベンダーの保守に任せきりにせず、発注者側にも系統モデル、設定値、ログ、試験結果、変更履歴を読める担当者を置きます。委託先を替えられる状態を維持することが、長期のベンダーロックインを抑えます。

よくある質問（FAQ）

停電管理システムの発注では、費用だけでなく、対象業務、連携範囲、制御の安全性、導入後の保守まで確認する必要があります。ここでは、発注前によくある質問に直接回答します。

限定拠点の調査・PoC・停電可視化であれば、1,000万〜3,000万円程度から検討するケースがあります。ただし、これはOMS全体の導入価格ではなく、対象設備、連携先、通知、試験の範囲を限定した推定です。自動制御、冗長化、現場工事、24時間保守を含めると、数億円以上になる可能性があります。

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

外注できますが、いきなり本開発を依頼せず、現状調査や要件定義支援を先に発注することをおすすめします。対象設備、既存システム、停電時の業務、必要なKPIを整理し、PoCでデータ連携を検証してから本開発のRFPを作ると、見積の前提がそろいやすくなります。

サプライチェーンと制御系の責任分界を曖昧にしないことです。再委託先、遠隔保守、機器やソフトウェアの更新、脆弱性情報、ログ、バックアップ、事故時の報告期限、権限のない操作への対策をRFPと契約に記載し、通信断や災害時の安全側動作を実機または試験環境で確認します。

まとめ

停電管理システムの発注では、まず復旧対応型OMS、計画停電の作業計画管理、施設の電源監視を切り分けます。そのうえで、対象設備と既存システムを調査し、可視化、復旧判断支援、自動制御の順に必要な範囲を定義します。

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

費用は、限定拠点のPoCで1,000万〜3,000万円、パッケージ基本導入で5,000万〜2億円、複数システム連携を含む中規模導入で2億〜10億円程度が推定の目安です。見積の安さだけでなく、現場データの品質、実機デモ、災害シナリオ試験、移行、セキュリティ、10年単位の保守費を比較することが重要です。まずは現状調査と小さなPoCを外注し、自社に必要な停電管理の範囲を明確にすることから始めます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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