スマートメーター管理システム開発の発注/外注/依頼/委託方法について

スマートメーター管理システムの発注は、業務範囲・データ量・連携先を整理してから、RFP、契約、共通試験の順に進めます。条件をそろえておくと、要件に合う委託先を選びやすくなります。

各段階で決めた内容は次の段階の材料になるため、最初の範囲設定が見積と比較の精度を左右します。

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

スマートメーター管理システムの発注で押さえる全体像

受信後の処理と配信先を一続きで確認できます。

スマートメーター管理システムは、MDMS（Meter Data Management System）を中心とする仕組みです。電力メーターのデータを集め、品質を管理し、保存して配信するまでを担います。

発注前には、メーター本体や通信網、HES、MDMSを一体で任せるか、分けて委託するかを決めておく必要があります。

CISも同じ判断の対象で、請求や顧客管理を行うシステムです。

MDMS・HES・CISの役割の違い

発注範囲を分けて委託する場合は、各システムの役割と委託の構成を先に整理しておく必要があります。CISは、機能ごとに別会社へ委託する構成と、一括で委託する構成のどちらにもできます。

HES（Head End System）：メーターとの通信を受け持つ
MDMS：HESから受けたデータを整え、業務システムへ渡す
CIS：顧客・契約・料金・請求を管理する

HESは、検針値や電圧、通信状態、アラームをメーターから受け取ります。

次にMDMSは、HESのデータを重複排除し、VEE（Validation・検証、Editing・補正、Estimation・推定）を行ったうえで、請求・託送・需給管理・分析へ渡します。

データ量と業務連携から見た発注範囲

発注範囲は、管理機能とデータの流れを次の観点で分けて見ると決めやすくなります。

台帳と受信：メーター・通信端末・設置場所・契約の管理、再送と欠損の管理
データ処理：30分値・15分値・5分値の保存、VEE、異常使用量の検知
業務連携：料金計算や託送へつなぐ処理、監査ログと権限管理

台数が少なくても、計測間隔が短かったり、保存年数が長かったり、配信先が多かったりすると、処理量と連携数は増えます。そのため、「何台を何分間隔で何年間保存し、何件のシステムへ渡すか」を数値で示しておくと、提案と見積を比べやすくなります。

スマートメーター管理システムの発注形態の選び方

要件に応じて選ぶ3つの方法を並べています。

発注形態に唯一の正解はなく、制度や業務の特殊性、既存システムを残す範囲、将来のメーター増加によって選び分けます。主な方法は次の3つです。

パッケージ・SaaS：標準機能を備えた製品を導入する
個別開発：SI会社に独自要件の実装を委託する
段階導入：PoCを行ってから本番へ広げる

パッケージ・SaaS導入で見る標準機能の範囲

標準機能で足りる範囲と、国内要件や運用条件とのずれは、次の観点で確かめておきます。

基本機能：VEE、台帳、利用量計算、品質監視、API連携、Oracleの標準VEE・料金連携の有無
製品と連携：Oracle Utilities MDMSはオンプレミスとSaaSのどちらも選べ、Siemens Gridscale Xとの接続方式も比較対象になる
実装期間：製品ごとの導入計画と所要期間
国内要件：料金制度、締め時刻、CIS項目、通信方式に応じて、追加設定や連携開発が発生する場合がある
SaaS契約：初期サーバーなしで始めやすい一方、メーター単位の課金、保存量、障害時の責任分界、データ持ち出し方法は、導入前に見ておく

Gridscale Xは、既存HES・CIS向けのオープンAPIと標準コネクターを掲げています。

Siemens公式情報では、Gridscale Xの実装期間は早ければ6〜9か月です（出典：Siemens「Gridscale X Meter Data Management SaaS」、2026年確認）。

個別開発・一括SIで実装する独自要件

独自の計量ルールや特殊な料金メニュー、OT設備との深い連携が必要な場合は、SI会社への個別開発が選択肢になります。

複数事業をまたぐ権限管理：個別開発の選択肢に入る
一括委託の場合：要件定義から設計、移行、試験、教育、24時間運用まで一括で担う会社なら、ベンダー間の調整の負担を抑えられる
発注者が文書にする事項：HES・MDMS・CISのどこがデータ品質を保証するか、通信障害や請求不一致の一次対応を誰が担うか

PoCから始める段階導入の進め方

小規模のPoCから始めて本番へ段階的に広げる方法も、有効な選択肢です。

小規模PoC：数百〜数千メーターで収集、簡易VEE、1〜2種類の連携とダッシュボードを試す
実データ検証：通信欠損、CISとの名寄せ、請求確定前の再処理の扱いを確かめる
拡張性確認：標準機能で業務の80％以上を満たし、差分を設定で埋められるか見る

特に、本番に近いデータ量でピーク試験と異常系試験を行い、単なる画面デモで済ませないようにします。

あわせて、将来の15分値・5分値化やDERMS連携へ拡張できるかも確かめておきます。

また、実績のあるパッケージ、API、データ基盤も比較の対象に入れます。MDMSのコアを全面スクラッチで開発するより、制度変更や保守のリスクを抑えやすい場合があります。

ポイント

発注形態は、標準機能で業務を回せるか、独自要件がどこまであるかで選びます。未確定の要素が多いときは、PoCから段階的に始めるほうが、後からの手戻りを抑えやすくなります。

RFPと要件整理で委託先に伝えるべき項目

RFPは、機能一覧に加えて、達成したい業務成果や、現在のデータとシステム、将来の拡張を書き、提案と見積の前提をそろえる資料です。候補会社が同じ条件で回答できるように、必須要件と希望要件を分け、提案依頼事項と未確定事項も別に書きます。

データの流れと利用者から見た業務要件

誰が、いつ、どのデータを何の判断に使うのかを書き出し、検針値を受信してから何分以内に品質判定するか、日次請求締めまでの未着データをどう扱うかも記載します。

メーター交換や契約切替の前後で引き継ぐデータは、利用者ごとの画面・権限・通知とあわせて示します。候補会社が業務と処理量を同じ前提で見積もれるように、次の情報をRFPにそろえておきます。

業務の流れ：誰がいつどのデータを使うか、品質判定時間、日次請求締め時の未着データの扱い
引き継ぎと利用者：メーター交換・契約切替前後のデータ、運用監視・料金・設備・顧客対応・管理者の役割
規模と性能：台数、増設計画、計測粒度、1日あたりのレコード数、ピーク同時受信数、欠損率、保存年数、連携先数
数値の根拠：不明な値は現行実績を一定期間測り、通常時と繁忙時を示す。「大量データ」とだけ書くと、見積の前提がずれる

SLA・セキュリティ・復旧の非機能要件

RFPでは、稼働水準、復旧条件、セキュリティと将来拡張の要件を具体的に書きます。

稼働と性能：可用性、処理能力、拡張性、バックアップ、監視、障害対応を、機能要件と同じ粒度で決めておく
復旧目標：RPO（どの時点のデータまで戻すか）、RTO（何時間以内に戻すか）、許容遅延、保守時間、ログ保存期間を数値で示す
セキュリティ運用：暗号化、特権ID、脆弱性対応期限を定める。24時間運用なら、夜間・休日の受付、エスカレーション、現地対応も明記する
将来の接続リスク：第二世代メーター、IoTルート、DR、蓄電池、EVへ広げる場合は、端末やクラウドゲートウェイの扱いも見ておく
ガイドライン対応：改定内容を踏まえた方針と、責任を持つ会社の回答を求める

経済産業省は2025年にERABサイバーセキュリティガイドラインVer.3.0を改定しました。同ガイドラインは、ゲートウェイを使わない制御や、IoT端末の脆弱性、機器から取得する情報のリスクを扱っています（出典：経済産業省「ERABに関するサイバーセキュリティガイドラインVer.3.0」、2025年）。

データサンプルと異常系の受入条件

受入試験で実運用に近いデータ処理を確かめるには、次の異常ケースも匿名化して用意しておきます。

通信・値の異常：欠損、重複受信、時刻ずれ、異常に大きい使用量
業務・設備の変化：メーター交換、契約切替、逆潮流
復旧時の受信：停電復旧後の一括受信

そのうえで、VEEによる補正・推定値と原本を区別できるか、再計算ができるか、請求担当の承認方法はどうかを評価します。受入試験では、受信から配信までの件数と処理時間を見ます。欠損の補完や監査ログ、再処理後の差分も確認します。

同じテストデータで評価すれば、提案資料の印象ではなく、業務で使える品質で比べられます。

ポイント

RFPには、業務の流れや非機能要件、受入条件を、候補会社が同じ前提で見積もれる形で書きます。数値にしにくい項目は、現行の実績を一定期間測って根拠にします。

スマートメーター管理システムの契約形態と責任分界

契約形態は、要件がどこまで固まっているかと、発注者がプロジェクト管理をどこまで担えるかで選びます。この領域は、制度変更や既存データの品質、他社仕様など不確定な要素が多いためです。

納品物や検収条件、変更管理を契約書に書いておかないと、追加費用や責任分界をめぐる争いが起きやすくなります。障害対応やデータの権利も、契約書に明記しておきます。

要件定義の準委任型契約

現行調査やPoC設計のように、作業を進めながら決めていく段階は、準委任型と相性がよい傾向があります。

稼働時間や体制を決め、定例会と課題管理の進め方も合意したうえで、要件定義の完了条件をそろえておきます。準委任であっても、納品物は必要です。

業務フローやデータ項目表、非機能要件は、納品物として設定します。さらに、RFPや試験計画も納品物に含めます。

開発部分の請負型契約と変更管理

開発範囲と変更管理を分けて考え、固定価格に含める条件を明確にしておきます。

請負範囲：仕様・納品物・検収基準が固まった設計開発が対象になる。後から判明したCIS変更や制度改定まで固定価格に含めると、予備費や品質に影響しうる
未確定事項：連携や追加機能は変更要求として見積もり、承認を得てから進める
変更記録：内容、理由、画面・API・データへの影響、納期、費用、試験範囲、承認者を管理票に残す
検収との照合：VEEルール、保持期間、計測粒度の変更は容量や請求処理に波及するため、口頭では合意せず、リリース前に履歴と受入条件を突き合わせる

保守契約で確認する制度改修とデータ品質

保守の対象と、複数社にまたがる障害の責任を、契約で定めておきます。

保守範囲：監視に加え、メーター交換、通信変更、制度改定、料金メニュー・CIS項目変更、VEE改善、再処理、障害時の顧客対応も対象に入れる
サービス水準：月次報告、受付時間、重大障害の復旧目標、脆弱性パッチの期限、軽微改修の月間枠を定める
責任分界：SaaS提供、導入SI、通信、HES各社の保証範囲を分け、API停止・受信遅延・誤推定・請求連携失敗への役割を示す
障害対応：検知、切り分け、復旧承認を担う会社を責任分界表に記す。一次窓口は一つに決めつつ、役割ごとの担当も書く

ポイント

要件がまだ固まっていない段階は準委任型で進め、仕様と検収基準が固まった開発部分は請負型にして、変更管理と組み合わせます。保守では、制度改修やデータ品質まで範囲に含めます。

スマートメーター管理システムの費用相場と見積の内訳

4つの観点をそろえると見積の前提を比べやすくなります。

MDMS単体の定価や、日本の中小規模案件にそのまま使える公開見積は少ないため、金額は前提条件をそろえて考える必要があります。

次の推定レンジは、2025〜2026年に公開された一般的な業務システム開発費と、MDMSの大量データ処理・高可用性・連携の複雑さから組み立てたものです。これは正式な発注額ではなく、RFIやRFPで精査するための予算取りの出発点です。

工程別の初期費用の幅（300万円〜20億円超）

発注範囲と規模によって、初期費用の推定レンジは次のように変わります。

事前調査・RFI・要件定義：300万〜1,000万円
小規模PoC：数百〜数千メーターで1,000万〜3,000万円
パッケージ・SaaS導入：標準連携中心で3,000万〜1.5億円
中規模の個別開発：複雑な基幹連携や高可用性を含み1.5億〜5億円
大規模AMI・MDMS刷新：送配電向けで5億〜20億円超

メーター本体や通信回線、HESは、別建てになる場合があります。データセンターやクラウドの費用も、別建てになることがあります。さらに、CIS改修や移行、教育、24時間運用費も、見積に別の項目として並ぶ場合があります。

経済産業省の次世代スマートメーター費用の再算定では、5分値取得の追加費用は約938億円、15分値化は約163億円です。これは全国規模で機器・通信・HES・MDMSなどを含む試算で、個別企業のMDMS単体の相場ではありません（出典：経済産業省「次世代スマートメーター導入に係るコストの再算定結果」、2026年）。

費用を左右する台数・粒度・連携・SLA

初期費用と5年TCOの両方を見積もるため、次の条件と費目をそろえます。

処理規模：台数、計測頻度、保存年数、ピーク受信数、VEEの複雑さ、連携先、移行データ
運用条件：可用性、セキュリティ監査、監視時間。30分値から5分値への変更は、受信・保存・再処理の負荷を増やす
移行範囲：過去データを全件引き継ぐか、参照用にアーカイブするかで、ストレージと試験工数が変わる
5年TCO：導入、クラウド・ライセンス、通信、保守、バックアップ、監視、制度改修、障害対応、追加連携まで含めて見る
将来費用：月額の安いSaaSも台数やデータ量で課金が伸びることがあり、オンプレミスは機器更新や運用人材が要る。台数は3パターン程度に分け、5年目まで比べる

作業量と前提条件を分けた見積の比較

見積の抜けや前提の違いを見つけるため、候補会社には次の形で回答を求めます。

費目：要件定義、設計、開発、ライセンス、環境、移行、試験、教育、リリース支援、保守ごとに分けて示す
作業前提：人数、期間、対象機能、連携範囲、除外事項を示す。「一式」で追加費用が生じる条件も明らかにする
共通条件：同じデータサンプルと非機能の前提を渡し、標準機能、設定、個別開発、将来拡張を分けて回答してもらう
必要範囲：安い見積にVEE、移行、障害試験、運用設計が含まれないこともあるため、すべて含めた総額で比べる

ポイント

見積は、台数・計測粒度・連携・SLAといった前提をそろえてから比べます。初期費用だけでなく、5年TCOと保守条件まで含めて判断します。

委託先の選定と見積比較で見るべきポイント

委託先は、製品名や知名度より、電力・送配電・小売の業務知識と、対象台数に近い処理実績で比べます。HES・CIS・SCADA・DERMSとの接続経験、VEEの設計力、長期保守の体制も確認します。

候補会社には提案書だけでなく、実データの説明、異常系への回答、障害時の連絡体制も示してもらいます。

発注範囲ごとの候補会社の得意分野

発注範囲に応じて、候補となる会社や製品の得意分野を確認します。

機器から一括導入：計量機器とシステムを扱う三菱電機、大崎電気工業など
MDMS標準機能と既存接続：HES・CISとつなぐOracle Utilities、Siemens製品の導入会社
OT・IT統合や設備管理・系統運用：日立製作所、NTT DATAなど大規模SI

会社名よりも、各社に同じ質問をして提案の具体性を比べることが大切です。たとえば、対象台数やピーク処理量の実績、利用者によるVEE変更の可否を尋ねます。

発注者は、HESやCISを別のベンダーにした場合の接続、第二世代の計測粒度、IoTルート、障害時の原本再処理についても、確かめておきます。

機能・リスク・5年TCOの比較表と点数化

評価軸と共通試験の結果をそろえて採点すると、提案を価格だけに寄せずに比べられます。

評価軸：価格、機能適合、処理性能、連携、セキュリティ、運用、拡張性、体制、実績、データ可搬性
配点例：価格20％、要件適合25％、非機能・セキュリティ20％、実績・体制20％、将来拡張15％。必須要件は足切りの基準にする
共通試験：収集率、欠損時の処理時間、VEEの説明可能性、再処理後の差分、監査ログ、復旧、APIエラー処理を見る
ベンチマーク：各社が公表するベンチマークも、提案比較の材料にする

Oracleは2025年、自社ベンチマークとして誤検知63％減、メーターデータ処理約70％高速化、ストレージ要件37％減を紹介しました（出典：Oracle「Oracle AI Transforms Meter Data Management」、2025年）。使う際は、対象データと測定条件を確かめてから、自社の評価に使います。

PM体制と保守の継続性

導入時の責任体制と、稼働後の引き継ぎや保守を続けられるかを確かめます。

担当者と役割：各担当者の氏名と受け持ち、責任者の継続的な関与
保守の継続性：制度改定や品質改善に備えて、契約期間中の担当者、サポート終了時期、更新方針、API変更通知、データ・設定の出力可否を見る
データ可搬性：ロックインを避けるため、標準形式のデータ、API仕様、運用手順、テストデータ、設定一覧を発注者が保有できる契約にする

PMや業務要件、データ移行の担当者は、名前を挙げて確認します。さらに、インフラやセキュリティ、テストの担当者も聞いておきます。

再委託の有無と、特定の人に知識が集中している場合の離任時の引き継ぎ方法も、あわせて聞いておきます。

ポイント

委託先は、製品名や知名度より、対象台数に近い処理実績と共通試験の結果で比べます。候補会社には、同じデータと条件で回答させると、提案の具体性の差が見えやすくなります。

スマートメーター管理システムの発注でよくある質問

費用や期間は規模と要件で変わるため、見積の前提と確認の方法を、よくある質問に沿って示します。

スマートメーター管理システムはどこまで外注できますか？

現行調査から運用監視まで、段階ごとに切り分けて外注できます。次の順に、任せる範囲を決めていきます。

現行調査、要件定義、RFP作成
パッケージ選定
設計・開発、移行、試験
教育
運用監視

業務の優先順位や許容する請求遅延、補正・推定ルールは、発注者が決めます。リスクをどこまで受け入れるかも、発注者の判断です。ただし、作業は外注できても、事業上の最終責任までは委託できません。

予算が決まっていなくてもRFPを作れますか？

作れます。予算が未確定なら、RFIや要件定義を先に進め、台数や計測粒度、保存期間を整理します。連携先と可用性も、あわせて書き出します。

調査からPoC、標準導入、大規模刷新までを段階に分けて見積を取ると、経営会議で投資判断をしやすくなります。

公表されている価格は少ないため、発注者側で前提をそろえておくことが欠かせません。

スマートメーター管理システムはクラウドで運用できますか？

クラウド対応の製品はあります。

採用の可否は、業務やセキュリティ、通信、責任分界の条件によって決まります。

拡張性やバックアップの負担を重視する場合は、SaaSが候補になります。その場合は、次の点を確かめます。

保存地域、暗号鍵、ログ
ネットワーク分離
障害復旧、データ返却
課金単位

発注者は、全体をクラウドに置かず、閉域網や既存設備と組み合わせるハイブリッド構成を選ぶこともできます。

委託先を選ぶときに最も重視すべきことは何ですか？

対象業務とデータ量に近い実績を、共通テストで確かめられるかどうかです。そのうえで、通信欠損やVEE、請求締めを検証し、さらにCIS名寄せや障害復旧も見ます。

提案価格や5年TCOは、同じ評価表で比べます。

PM体制や保守、データ可搬性も同じ表に並べ、実際の担当者と話したうえで決めます。

まとめ：発注条件を整えてからの外注

発注では、まずMDMSの範囲とHES・CISとの境界を決めます。

対象台数や計測粒度、保存年数をRFPに書き、ピーク処理量やVEE、連携先も書き添えます。

RPO・RTO、セキュリティ、保守時間も条件に含めます。開発会社へ丸投げせず、発注者が判断する部分を残しておくことが大切です。

発注前に社内で決めておく事項

次の打ち合わせまでに、現行構成図とデータ項目表を用意します。台数と増設計画、日次・ピーク受信件数、通信欠損の実績も、あわせて準備します。

CISや請求との連携仕様と、受入試験のサンプルも手元に置きます。未確定の項目には仮の前提と決定期限を付けます。そうすると、同じ条件で見積を作れるようになり、候補会社を比べやすくなります。

同じデータと条件によるPoC・見積の比較

発注形態と投資条件は、共通試験の結果を踏まえて、次の順に比べます。

共通テスト：通信断、重複、時刻ずれ、メーター交換、請求締め前の再処理を試す
発注形態：標準機能を生かすパッケージ・SaaS、独自要件向けの個別開発、リスクを抑えるPoC・段階導入を比べる
費用の判断：初期費用だけでなく5年TCOと保守条件を見比べる。システムは料金、顧客対応、託送、設備運用、将来のDR・分散電源を支える
発注者の役割：業務判断を担い、専門会社の知見をRFP・契約・試験・運用設計に反映し、導入後のデータ品質と拡張性を見据える

▼全体ガイドの記事
・スマートメーター管理システム開発の完全ガイド

▼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を創業。