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

スマートメーター管理システムの発注は、メーターの台数だけでなく、HES・MDMS・CISの責任範囲、計測粒度、VEE、既存システムとの連携を決めてから委託先を比較することが成功の近道です。

本記事では、電力小売・送配電・自治体・アグリゲーターなどの担当者に向けて、発注形態の選び方、RFPと要件整理、契約形態、2026年時点の費用相場、委託先の選定方法、見積比較のポイントを順番に解説します。システムを丸ごと丸投げするのではなく、発注者側で先に決める項目と、専門会社に任せる項目を切り分けるための実務ガイドです。

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

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

スマートメーター管理システムは、一般にMDMS（Meter Data Management System）を中心とした、電力メーターデータの収集・品質管理・保存・配信を担う仕組みです。発注時に最初に行うべきことは、スマートメーター本体、通信網、HES、MDMS、請求や顧客管理を行うCISを同じシステムとして扱うのか、それぞれ分けて委託するのかを明確にすることです。

HESはスマートメーターと通信して検針値や電圧、通信状態、アラームなどを受け渡すHead End Systemです。MDMSはHESから届いたデータを重複排除し、Validation（検証）、Editing（補正）、Estimation（推定）というVEE処理を行い、請求・託送・需給管理・分析に使えるデータへ整えます。CISは顧客、契約、料金、請求を管理するシステムです。HESを別会社、MDMSをパッケージ、CIS連携をSI会社に依頼する構成もあれば、一括で請け負う会社に委託する構成もあります。

必要な機能は、メーター・通信端末・設置場所・契約の台帳管理、受信データの再送と欠損管理、30分値・15分値・5分値などの時系列保存、VEE、異常使用量の検知、料金計算や託送への連携、監査ログと権限管理です。メーター台数が少なくても、計測間隔が短く、保存年数が長く、複数のCISや顧客ポータルへ配信する場合は、処理量と連携数が増えます。発注前に「何台のメーターを、何分間隔で、何年間保存し、何件のシステムへ渡すか」を数字で置くと、委託先の提案と見積を比較しやすくなります。

スマートメーター管理システムの発注形態はどれを選びますか？

発注形態は、パッケージやSaaSを導入する方法、SI会社に個別開発を委託する方法、PoCを含む段階導入を組み合わせる方法の3つに分けて考えると整理しやすくなります。どれが正解ということではなく、制度や業務の特殊性、既存システムを残す範囲、将来のメーター増加に応じて選択します。

パッケージやSaaSは、VEE、メーター台帳、利用量計算、データ品質監視、API連携など、MDMSに必要な基本機能を既に持っていることが強みです。Oracle Utilities MDMSはオンプレミスとSaaSの選択肢を示し、標準のVEEや料金業務への連携を提供しています。SiemensのGridscale X Meter Data Management SaaSも、既存のHESやCISと接続するオープンAPIや標準コネクターを掲げ、公式情報では早ければ6〜9か月で実装できると説明しています（出典：Siemens「Gridscale X Meter Data Management SaaS」、2026年確認）。

一方で、日本固有の料金制度、データの締め時刻、既存CISの項目、国内の通信方式に合わせる追加設定や連携開発が発生することがあります。SaaSなら初期サーバーを持たずに始めやすい反面、メーター単位の課金、データ保存量、障害時の責任分界、データの持ち出し方法を契約前に確認します。

独自の計量ルール、特殊な料金メニュー、既存のOT設備との深い連携、複数事業をまたぐ権限管理がある場合は、SI会社へ個別開発を委託する選択肢があります。要件定義から設計、移行、試験、教育、24時間運用まで一括して責任を持つ会社を選べば、複数ベンダー間の調整負担を抑えられます。ただし、一括契約でも、HES・MDMS・CISのどこでデータ品質を保証するか、通信障害や請求不一致が起きたときに誰が一次対応するかは文書化が必要です。

初めから全メーターを対象にせず、数百〜数千台のPoCで、収集、簡易VEE、1〜2種類の連携、ダッシュボードを検証してから本番導入する方法も有効です。通信欠損がどの程度発生するか、既存CISとの名寄せが成立するか、請求確定までに再処理が間に合うかを実データで確かめられます。PoCを単なる画面デモにせず、本番のデータ量に近いピーク試験と異常系試験まで含めることが重要です。

発注形態を決めるときは、標準機能で業務の80％以上を満たせるか、残りの差分を設定で埋められるか、将来の15分値・5分値化やDERMS連携に拡張できるかを確認します。最初からMDMSコアをすべてスクラッチ開発するより、実績のあるパッケージ、API、データ基盤を組み合わせる方が、制度変更と保守のリスクを抑えやすい場合があります。

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

RFPは、機能一覧を並べるだけの資料ではなく、発注者が達成したい業務成果、現在のデータとシステムの状態、将来の拡張、提案と見積の前提をそろえる資料です。候補会社が同じ条件で回答できるように、必須要件、希望要件、提案してほしい事項、現時点で未確定の事項を分けて記載します。

業務要件では、誰が、いつ、どのデータを、何の判断に使うかを整理します。たとえば、検針値を受信してから何分以内に品質判定を終えるのか、日次の請求締めまでに未着データをどう扱うのか、メーター交換や契約切替の前後でどのデータを引き継ぐのかを記載します。利用者も、運用監視担当、料金担当、設備担当、顧客対応担当、管理者に分けると、画面・権限・通知の要件が具体化します。

対象メーター台数、増設計画、計測粒度、1日あたりのレコード数、ピーク同時受信数、欠損率、データ保存年数、連携先数は、RFPの冒頭に書くべき基本情報です。数値がまだ不明な場合は、現行実績を一定期間測定し、通常時と繁忙時の両方を提示します。実測値がないまま「大量データに対応」とだけ書くと、会社ごとに異なる前提で見積が出てしまいます。

可用性、性能、拡張性、バックアップ、監視、障害対応、セキュリティは、機能要件と同じ粒度でRFPに入れます。RPO（どの時点までデータを復旧するか）、RTO（何時間以内にサービスを戻すか）、許容遅延、メンテナンス時間、ログ保存期間、暗号化、特権IDの管理、脆弱性対応の期限を具体的な数値で示します。24時間運用が必要なら、夜間や休日の一次受付、エスカレーション、現地対応の有無も明記します。

第二世代スマートメーター、IoTルート、DR、蓄電池、EVなどへ広げる場合は、端末やクラウドゲートウェイのリスクも確認します。経済産業省は2025年にERABサイバーセキュリティガイドラインVer.3.0を改定し、ゲートウェイを使わない制御やIoT端末の脆弱性、機器から取得する情報のリスクを扱っています（出典：経済産業省「ERABに関するサイバーセキュリティガイドラインVer.3.0」、2025年）。発注時には、ガイドラインへの対応方針と、責任を負う会社の範囲を回答させます。

RFPに添付するデータは、正常な検針値だけでは不十分です。通信断による欠損、同じ値の重複受信、時刻ずれ、異常に大きい使用量、メーター交換、契約切替、逆潮流、停電復旧後の一括受信など、実際に起きるケースを匿名化して渡します。VEEで補正・推定した値と原本をどう区別するか、後から再計算できるか、請求担当が承認できるかも評価します。

受入試験では、単に画面が表示されるかではなく、受信から配信までの件数、処理時間、欠損補完の結果、監査ログ、再処理後の差分を確認します。発注者と候補会社が同じテストデータで評価すれば、営業資料の印象ではなく、業務に使える品質で比較できます。

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

契約形態は、要件の確定度と発注者が担えるプロジェクト管理の範囲で選びます。スマートメーター管理システムは、制度変更、既存データの品質、他社システムの仕様など、契約時点で不確定な要素が多い領域です。契約書に成果物、検収、変更管理、障害対応、データの権利を明記しないと、後から追加費用と責任分界の争いが起きやすくなります。

現行調査、データ量の実測、業務整理、RFP作成、PoCの設計など、作業内容を進めながら決めるフェーズは、準委任型の契約と相性がよい傾向があります。稼働時間や体制、成果物の定義、定例会、課題管理を明確にし、何をもって要件定義完了とするかを合意します。準委任だから成果物が不要になるわけではなく、業務フロー、データ項目表、非機能要件、RFP、試験計画などを納品物として設定します。

仕様、成果物、検収基準を確定できる設計・開発部分は、請負型で契約する方法があります。ただし、既存CISの仕様変更や制度改定が後から判明した場合まで固定価格に含めると、委託先が過大な予備費を積むか、品質を下げるリスクがあります。基本設計で確定した範囲を請負とし、未確定の連携や追加機能は変更要求として見積・承認する二段構えが現実的です。

変更管理票には、変更内容、理由、影響する画面・API・データ、納期、費用、試験範囲、承認者を記録します。特にVEEルールの変更、保持期間の延長、計測粒度の変更は、データ容量と請求処理へ波及します。口頭合意で進めず、リリース前に変更履歴と検収条件を突合できる状態にします。

本番稼働後の保守は、サーバー監視だけではありません。メーター交換、通信方式の変更、制度改定、料金メニューの追加、CISとの項目変更、VEEルールの改善、データ再処理、障害時の顧客対応が含まれます。月次報告の内容、問い合わせの受付時間、重大障害の復旧目標、脆弱性パッチの適用期限、軽微改修の月間枠を契約に入れます。

SaaSを選ぶ場合は、サービス提供会社、導入SI会社、通信会社、HES会社のどこが何を保証するかを一覧にします。API停止、受信遅延、誤推定、請求連携の失敗など、複数会社にまたがる障害は、一次窓口を一つにするだけでは解決しません。障害を検知する会社、切り分ける会社、復旧を承認する会社を責任分界表で示します。

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

MDMS単体の定価や、日本の中小規模案件にそのまま使える公開見積は少ないため、金額は前提条件をそろえて考える必要があります。以下は、2025〜2026年に公開されている一般的な業務システム開発費の目安と、MDMSに求められる大量データ処理・高可用性・連携の複雑さから組み立てた、予算取り用の推定レンジです。正式な発注額ではなく、RFIやRFPで精査するための出発点として使います。

事前調査・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年）。

費用が大きく変わる要因は、メーター台数、1台あたりの計測頻度、保存年数、ピーク同時受信数、VEEの複雑さ、連携先の数、移行対象データ、可用性、セキュリティ監査、監視時間です。たとえば30分値を5分値に変えると、同じ台数でも受信・保存・再処理の負荷が増えます。古いデータをすべて移行するのか、参照用にアーカイブするのかでも、ストレージと試験の工数が変わります。

比較では初期費用だけでなく、5年TCOを計算します。TCOには、導入費、クラウドやライセンスの利用料、通信費、保守費、バックアップ、監視、制度改修、障害対応、追加連携を含めます。月額が安いSaaSでもメーター数やデータ量が増えたときに課金が伸びる場合があり、オンプレミスでも機器更新や運用人材が必要です。将来の台数を3パターン程度に分けて、5年目の費用まで並べると判断しやすくなります。

見積書は総額だけでなく、要件定義、設計、開発、ライセンス、環境構築、データ移行、試験、教育、リリース支援、保守に分けてもらいます。各項目について、人数、期間、対象機能、含まれる連携、除外事項を確認します。「一式」と書かれた項目が多い場合は、追加費用が発生する条件を質問します。

候補会社には同じデータサンプルと同じ非機能条件を渡し、標準機能、設定、個別開発、将来拡張を区別して回答してもらいます。安い見積が、単にVEEや移行、障害試験、運用設計を含んでいないだけということもあります。費用の低さだけでなく、業務に必要な範囲を満たす総額で比較することが大切です。

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

委託先は、製品名や知名度だけでは決めません。電力・送配電・小売の業務知識、対象台数に近い処理実績、HES・CIS・SCADA・DERMSとの接続経験、VEEの設計力、長期保守の体制を確認します。候補会社には、提案書だけでなく、実データを使った説明、異常系への回答、障害時の連絡体制まで示してもらいます。

メーターやHESまで含めた一括提案を重視するなら、三菱電機や大崎電気工業のように計量機器とシステムを扱う会社を候補にできます。MDMSパッケージやSaaSの標準機能を使い、既存HES・CISをつなぎたい場合は、Oracle UtilitiesやSiemensの製品を扱える導入会社を比較します。送配電やOT・ITの統合、設備管理、系統運用まで対象にするなら、日立製作所やNTT DATAのような大規模SIの実績も確認します。

ここで大切なのは、会社名を並べることではなく、各社に同じ質問をすることです。「対象台数とピーク処理量の実績はありますか」「VEEルールを利用者が変更できますか」「HESやCISを別ベンダーにした場合も接続できますか」「第二世代の計測粒度やIoTルートに対応できますか」「障害時に原本データを再処理できますか」といった質問で、提案の具体性を見ます。

提案比較では、価格、機能適合、処理性能、連携、セキュリティ、運用、拡張性、プロジェクト体制、実績、データ可搬性を評価軸にします。たとえば、価格20％、要件適合25％、非機能・セキュリティ20％、実績と体制20％、将来拡張15％のように、社内で重みを決めてから採点します。価格だけを先に見てしまうと、必須条件を満たさない提案が残るため、必須要件は足切りにします。

提案の点数には、デモの印象よりも、共通テストの結果を反映します。正常データの収集率、欠損時の処理時間、VEEの説明可能性、再処理後の差分、監査ログ、バックアップからの復旧、APIのエラー処理を確認します。Oracleは2025年の発表で、AIを使った異常検知などについて、誤検知63％減、メーターデータ処理約70％高速化、ストレージ要件37％減という自社ベンチマークを紹介しています（出典：Oracle「Oracle AI Transforms Meter Data Management」、2025年）。このような数字も、対象データと測定条件を確認してから自社評価に取り入れます。

提案時には、プロジェクトマネージャー、業務要件担当、データ移行担当、インフラ担当、セキュリティ担当、テスト担当の役割と氏名を確認します。提案段階の責任者が、設計・開発・稼働後も関与するのか、下請け会社へ再委託するのかも聞きます。電力業務の知識が一人に集中している場合、その人が離任した際の引き継ぎ方法まで確認すると安心です。

稼働後は、制度改定とデータ品質の改善が続きます。契約期間中に担当者を確保できるか、製品のサポート終了時期、バージョンアップの方針、API仕様の変更通知、ソースデータと設定のエクスポート可否を確認します。ベンダーロックインを避けるには、データの標準形式、API仕様、運用手順、テストデータ、設定一覧を発注者が保有できる契約にすることが有効です。

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

ここでは、発注前に多く寄せられる疑問を、実務で判断しやすい形に整理します。費用や期間は規模と要件で変わるため、質問への回答でも一律の数字を断定せず、見積の前提と確認方法を示します。

現行調査、要件定義、RFP作成、パッケージ選定、設計・開発、データ移行、試験、教育、運用監視まで外注できます。ただし、業務上の優先順位、許容できる請求遅延、データを補正・推定するルール、リスクを受け入れる判断は発注者が決める必要があります。外注するのは作業であり、事業上の最終責任まで委託できるわけではありません。

作れます。予算を先に固定できない場合は、RFIや要件定義を先行し、対象台数、計測粒度、保存期間、連携先、可用性の条件を整理して、複数の構成案を出してもらいます。調査・PoC・標準導入・大規模刷新を分けた段階見積にすると、経営会議で投資判断をしやすくなります。公表価格が少ない分、発注者側の前提を揃えることが重要です。

クラウドで運用できる製品はありますが、採用できるかは業務、セキュリティ、通信、責任分界の条件で決まります。拡張性やバックアップの運用負担を重視するならSaaSが候補になりますが、データの保存地域、暗号鍵、ログ、ネットワーク分離、障害時の復旧、データ返却、課金単位を確認します。全体をクラウドに置くのではなく、閉域網や既存設備と組み合わせたハイブリッド構成も選択肢です。

最も重視すべきことは、対象業務とデータ量に近い実績を、共通テストで確認できることです。製品の機能が多くても、通信欠損、VEE、請求締め、既存CISとの名寄せ、障害復旧が成立しなければ業務で使えません。提案価格、5年TCO、PM体制、保守、データ可搬性を同じ評価表で比較し、実際に担当する人と会話して決めます。

まとめ：発注条件を整えてからスマートメーター管理システムを外注します

スマートメーター管理システムの発注では、いきなり開発会社へ丸投げするのではなく、まずMDMSの範囲とHES・CISとの境界を決めます。そのうえで、対象メーター台数、計測粒度、保存年数、ピーク処理量、VEE、連携先、RPO・RTO、セキュリティ、保守時間をRFPに落とし込みます。

次の打ち合わせまでに、現行システム構成図、データ項目表、メーター台数と増設計画、1日・ピーク時の受信件数、通信欠損の実績、CISや請求への連携仕様、受入試験のサンプルを準備します。未確定の項目には仮置きの前提と決定期限を付けます。これだけでも、提案会社が同じ条件で見積を作れるようになり、比較の精度が上がります。

委託先には、正常系だけでなく通信断や重複、時刻ずれ、メーター交換、請求締め前の再処理などを含む共通テストを依頼します。発注形態は、標準機能を生かせるパッケージ・SaaS、独自要件を実装する個別開発、リスクを抑えるPoC・段階導入から選び、初期費用だけでなく5年TCOと保守条件で判断します。

スマートメーター管理システムは、検針値を保存するだけの仕組みではなく、料金、顧客対応、託送、設備運用、将来のDRや分散電源を支えるデータ基盤です。発注者が業務上の判断を担い、専門会社の知見をRFP、契約、試験、運用設計へ落とし込めば、導入後のデータ品質と拡張性まで見据えた外注ができます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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