スマートメーター管理システム開発は、まず現状のデータと業務を調べ、実データでPoCを行ってから段階的に展開する流れで進みます。この順に進めると、請求や託送に使えるデータ品質を整えられます。
▼全体ガイドの記事
・スマートメーター管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
スマートメーター管理システムの全体像
スマートメーター管理システムは、電力メーターから届く大量の時系列データを、業務で使える品質に整える基盤です。一般にはMDMS（Meter Data Management System）を指します。
プロジェクトでは、メーター、通信網、HES、MDMS、CIS、分析基盤までをAMI全体として検討します。そのとき、レイヤーごとの役割を分けておくと、開発範囲や見積もりの抜け漏れを抑えられます。
MDMSとAMI、HES、CISの違い
AMIは、スマートメーターと通信、データ収集、データ活用を含む仕組み全体を指します。そのうち、メーターとの通信を管理するのがHES（Head End System）です。
- HES：検針値やイベントをメーターから受信します。
- MDMS：受信データの保存、名寄せ、検証、補正、推定、公開を担います。
- CIS：顧客情報や契約、請求を管理します。
また、MDMSからCISへ渡すデータは品質と締め時刻を決め、HESとの受け渡し形式も定義しておきます。
開発対象を「メーターから請求まで」と呼ぶだけでは、通信回線やメーター交換、請求改修の範囲が曖昧になります。そこで、RFPでは対象範囲を図にします。
図には、メーター本体、通信、HES、MDMSを含めます。CISや顧客ポータル、分析も入れます。さらに、各境界の責任者と連携方式も明記します。
主な機能とデータの流れ
基本のデータは、スマートメーターから通信、HES、MDMSを経て、料金・顧客・配電・分析システムへ流れます。MDMSでは、次の機能を検討します。
- 台帳と受信：メーター、通信端末、設置場所、契約の情報を管理します。
- データ管理：重複の排除、再送、欠損の管理、30分値や15分値の時系列保存を担います。
- 業務連携：VEE、異常使用量の検知、請求用データの公開を担います。
- 統制：監査ログと権限管理を備えます。
VEEはValidation（検証）、Editing（補正）、Estimation（推定）の略で、請求や託送に使う値の信頼性を左右します。たとえば、前回値より急増した値を警告したり、通信断の値を実績やルールに基づいて推定したりします。後から実測値が届いた場合は、再計算します。
また、VEEのルールを画面で変更できるか、変更履歴を残せるかを決めておきます。さらに、再処理した値をCISへ再送できるかも、設計に含めます。
第二世代スマートメーターで先に考える要件
2026年時点では、30分値を保存できれば十分という前提を見直します。そのうえで、第二世代に向けた次の将来要件を検討します。
- 計測と制御：5分値や15分値の取得、双方向制御を検討します。
- 接続先：IoTルートや共同検針を考慮します。
- エネルギー連携：再生可能エネルギー、蓄電池、EVとの接続を想定します。
- データ提供：DRやDERMSへ渡す情報の範囲を検討します。
導入時期は電力会社や対象地域の計画によって異なります。そのため、「2026年1月から全国一斉に始まる」と断定せず、自社の計画と制度資料を確認します。
計測間隔が30分から5分になると、1台あたりのデータ点数は単純計算で6倍になります。たとえば、メーター10万台で1日24時間、5分間隔のデータを扱う場合、正常値だけでも1日2,880万点に達します。
イベントや再送、履歴、監査ログも発生します。そのため、保存領域に加えて、ピーク受信や再処理も見積もります。バックアップや検索性能も、見積もりの対象に入れます。
スマートメーター管理システム開発の進め方
開発は、製品を選んで画面を作る前に、現状のデータと業務を可視化し、段階的に進めます。特に、請求締め、通信欠損、メーター交換、契約切替は、早い段階で洗い出しておきます。
- 現状調査
- 要件定義
- PoC
- 提案比較
- 設計・開発
- 試験
- 並行稼働
- 段階展開
企画・現状調査・要件定義で決める事項
まず導入目的を具体化します。たとえば、検針業務の自動化や請求の正確性向上、停電や通信障害の把握などの目的に分けて整理します。現状調査では、次のデータを実測します。
- 設備・通信：メーター台数、増設計画、通信方式、HESの製品とバージョン。
- 業務連携：CISや請求との連携方式、既存データの保存年数。
- データ量：ピーク時の受信量と欠損率。
台数は現在の値だけでなく、3年後と5年後の増加も前提にします。そのうえで、機能要件と非機能要件は分けて整理します。
機能要件には、台帳、収集、VEEを含めます。加えて、照会や再処理、通知、APIも対象に入れます。
非機能要件では、可用性、性能、拡張性を中心に定めます。RPO・RTOや監査ログ、暗号化も含めます。アクセス制御、データ保持、障害時の切替も、非機能要件に入れます。
各社の提案を同じ条件で比べるには、「大量データを処理できる」より具体的な書き方が必要です。たとえば、「月次請求締めのピークで何分以内に何件を確定する」と記載します。
PoCとRFPで確かめる事項
候補製品や開発会社を絞る前に、小規模PoCを実施します。その際は、数百から数千メーター分の実データか匿名化データを使います。
PoCでは、次のような状態を再現して、VEEや再処理の動きを確かめます。
- データ異常：欠損、重複、時刻ずれ、急増。
- 運用イベント：メーター交換、通信再送。
- 検証内容：請求用データの再現性、ルール変更履歴、再処理時間が許容範囲か。
RFPには、対象範囲、データ項目、ピーク量を記載します。連携先と移行対象、試験データもあわせて書きます。受入条件やSLA、保守時間、責任分界も盛り込みます。
価格に加えて、標準機能と追加開発の境界も確認します。そのうえで、将来の5分値化や、APIや原本データの持ち出し、障害時の復旧手順についても回答を求めます。
SiemensのGridscale X Meter Data Management SaaSは、公式情報で実装目安を6〜9か月としています。ただし、連携数や移行量で期間は変わるため、この目安を納期とみなさないようにします。
設計・試験・リリースの分け方
設計では、データモデルや時系列データのパーティション、メッセージキューを決めます。さらに、APIと権限、監視の扱いを決めたうえで、バックアップや障害時の再送も設計に含めます。
直近データと長期履歴は、ホット・ウォーム・アーカイブに分けておくと、性能と保管費用を調整しやすくなります。また、原本データを再処理できる形で残しておくと、制度やVEEルールの変更にも備えられます。
試験は、単体、連携、性能に分けます。障害復旧、セキュリティ、業務受入も、区分に加えます。そのうえで、次の異常系をシナリオに含めます。
- 通信・データ：通信断が数時間続く、同じ検針値が複数回届く。
- 負荷・設備：夏季ピークで受信量が増える、メーターを交換する。
- 業務変更：契約が切り替わる、請求締め直前に遅延データが届く。
新旧システムは一定期間並行稼働させ、その間に顧客・地点・メーターの名寄せと請求値を日次で突合します。突合後は、地域や契約種別ごとに段階展開します。
スマートメーター管理システムの費用相場
費用は、メーター台数、計測間隔、連携先によって変わります。VEEの複雑さや可用性、移行範囲も影響します。ただし、MDMS単体の定価や国内案件の公開見積は少ない状況です。
以下の金額は、2026年時点で予算を取るための推定です。メーター本体、通信回線、HESが別契約なら、総額を組み直します。データセンターや24時間運用、CIS改修が別契約になる場合も、同じ考え方で見直します。
開発規模別の費用と期間の目安
規模ごとの予算と期間は、次の幅を目安にします。
- 調査・要件定義：300万〜1,000万円、2〜4か月。
- 小規模PoC：1,000万〜3,000万円、3〜6か月。
- パッケージ・SaaS導入：3,000万〜1.5億円、6〜12か月。
- 中規模の個別開発：1.5億〜5億円、12〜24か月。
- 広域の一体刷新：5億〜20億円超、18〜36か月以上。
PoCは、本番導入の一部を作る費用というより、性能と業務ルールを検証する費用として捉えます。
パッケージやSaaS導入の目安には、標準連携やCIS接続、データ移行が含まれます。試験や教育も、この中に入ります。
中規模開発には、複雑な基幹連携、高可用性、複数通信が含まれます。独自VEEや長期履歴、監査も、この区分の対象です。
広域の一体刷新は、AMIやHES、MDMSから請求、設備、運用までを対象とする案件です。
経済産業省の次世代スマートメーター導入に係るコスト再算定では、5分値データ取得の追加費用を938億円と試算しています（出典：経済産業省「次世代スマートメーター導入に係るコストの再算定結果」）。
同じ試算では、15分値化が163億円、特定計量が86億円とされています。ただし、この数字は全国規模でメーターや通信、HES、MDMSなどを含むもので、1社のMDMS開発費ではありません。そのため、大きな公的試算を自社案件の見積もりに直接当てはめないようにします。
費用を左右する要因と5年TCOの見方
最大の変動要因は、メーター台数とデータ粒度です。たとえば10万台の場合、30分値は1日480万点、5分値は1日2,880万点になります。
こうした量の違いによって、保存、集計、バックアップ、再送処理の負荷も変わります。そのため、費用には保存年数や圧縮、パーティション、連携先数も影響します。
APIのリアルタイム性やSLA、セキュリティ監査も確認します。移行データの品質や24時間監視の有無は、あわせて見ておきます。
運用費も含めた負担を把握するため、初期導入費と年間費用から単純な5年TCO（総保有コスト）を試算します。
- 初期導入費：8,000万円。
- 年間費用：クラウド・ライセンス・保守・監視が2,000万円、通信費や制度改修対応が500万円。
- 5年TCO：8,000万円＋2,500万円×5年で2億500万円。
実際には、データ量の増加や追加メーター、障害対応に加えて、教育や契約終了時のデータ移行費も発生します。そのため、増加率を含む複数のケースを作ります。
クラウドやSaaSは、初期のサーバー費を抑えやすい一方で、継続費用が増える場合があります。費用は、メーター単位やデータ量、API、保存期間に応じて変わります。
Oracleの公式情報では、MDMSにVEEやアーカイブ、圧縮・パーティション、CIS連携などの機能が示されています。
2025年の発表では、AIによる異常検知とインメモリ処理により、約70%高速化したことが示されています。ストレージ要件では37%削減した実績値が紹介されています（出典：Oracle「Oracle AI Transforms Meter Data Management」、2025年）。
ただし、自社データで同じ効果が出るとは限りません。そのため、PoCで検証してから効果額を見積もります。
見積もりを取る際のポイント
機能名の一覧より、対象台数、計測間隔、ピーク受信量を同じ条件で提示してもらうと、見積もりを比べやすくなります。データ保持年数やVEEルールも、各社で同じ前提にそろえます。
連携先や移行範囲、可用性もそろえます。セキュリティや運用時間も、同じ条件にします。
標準機能と設定、追加開発を分けて回答してもらいます。第三者製品や保守も、別々に示してもらいます。
RFI・RFPで準備する資料
発注前には、現行構成やデータ、連携仕様をまとめて準備します。その資料には、次の内容を含めます。
- システム・データ：構成図、データ項目一覧、検針値のサンプル、イベント一覧。
- 台帳・業務：メーター台帳、契約・地点・顧客のキー、請求締めの業務カレンダー。
- 連携：ファイルの受け渡し形式やAPI仕様。
個人情報や営業秘密を含む場合は、匿名化しておきます。詳細データは、秘密保持契約の締結後に開示します。
サンプルには、正常値だけでなく欠損や重複、時刻ずれといった異常値も含めます。メーター交換前後のデータも入れます。
非機能要件の資料には、平常時とピーク時の処理量、許容遅延を記します。同時利用者数や障害検知時間も記載します。さらに、RPO・RTOや目標稼働率、バックアップ世代、ログ保存期間も示します。
暗号化方式や管理者権限、ネットワーク分離も記載します。電力や分散リソースと接続する場合は、責任分界も整理します。
経済産業省は2025年にERABに関するサイバーセキュリティガイドラインVer3.0を改定しました（出典：経済産業省「ERABに関するサイバーセキュリティガイドラインを改定」、2025年）。このガイドラインを参考に、IoT機器やゲートウェイを含む責任分界を、RFPに反映します。
複数社を比較する際の評価軸
候補会社は、案件の境界と将来の拡張性で比べます。評価軸をそろえ、スコア化して比較します。
- 実績・規模：国内の電力・送配電・小売実績、対象台数、最大処理量。
- 機能・連携：VEEの設定自由度、HES・CIS・SCADA・DERMSとの接続。
- 運用・費用：データ移行経験、24時間運用、セキュリティ監査、5年TCO、制度改修の契約条件。
パッケージは、VEEや台帳などの標準機能を使いやすく、導入期間を短縮できる可能性があります。また、SaaSはサーバー更新やパッチの負担を軽くできます。
SaaSは台数増加に合わせて拡張しやすい反面、データ所在や障害復旧、料金体系を確認します。解約時の返却やカスタマイズ制約も、あわせて確認します。
スクラッチは、独自の計量・料金ルールに対応しやすい方式です。ただし、制度変更や障害復旧、製品寿命までの責任を自社で負うことになります。そこで、コア機能をすべて自作する必要性を検討します。
見積もり後のリスクと対策
見積もり後のリスクは、性能、データ品質、ベンダー依存に分けて確認します。障害対応や契約条件は、個別に見ておきます。
- 性能：非機能要件を固め、本番ピークを想定した負荷試験を行います。
- 請求値の突合：CISとMDMSの名寄せを確認し、顧客・地点・メーターのキーを設計します。
- 欠損補完：ルールの未合意を防ぐため、VEEルールの承認者と版管理、異常系の受入条件を契約前に固めます。
- ベンダー依存：将来の拡張や交換を妨げない接続性を確認します。
- 障害・契約：障害時の一次対応者と復旧責任を明確にし、変更時の単価、追加連携の見積ルール、保守範囲も含めて判断します。
特定ベンダーの通信方式やデータ形式に依存すると、将来のメーター追加やHES交換が難しくなります。そのため、標準APIやスキーマ管理、原本データの保存を要件にします。データエクスポートや接続試験環境も、要件に加えます。
よくある質問（FAQ）
開発前には、製品名やクラウドの可否に加えて、データ品質や既存業務を確認します。将来の計測粒度や運用責任も、あわせて整理します。
スマートメーター管理システムはクラウドで開発できますか？
クラウドやSaaSで構築できます。ただし、すべての案件でパブリッククラウドが最適とは限りません。閉域網やデータ所在、暗号鍵、接続先のOT環境を確認します。
運用責任や障害時の切替、費用の増加条件も検討します。そのうえで、パブリッククラウド、プライベートクラウド、オンプレミスを組み合わせて選びます。
開発会社に相談する前に何を用意すればよいですか？
相談の前には、対象メーター数、現在と将来の計測間隔、HESとCISの製品名、連携方式を整理します。
請求締めやデータ保持年数、通信欠損率もまとめます。想定利用者や希望稼働時期も、あわせて整理します。完成した仕様書がなくても、相談は始められます。
現行業務の流れや困っている事象、代表的なデータサンプルがあれば、調査と要件定義についても相談できます。
パッケージとスクラッチ開発はどちらがよいですか？
標準的なVEEや台帳、連携、監査を早く安定させたい場合は、パッケージやSaaSが現実的です。
独自の計量・料金ルールや既存OTとの深い統合が競争力に直結する場合は、個別開発を組み合わせます。そのうえで、基盤部分まで自作する必要があるかを検討します。将来の制度改修や保守費用も含めて判断します。
スマートメーター管理システムの開発期間はどのくらいですか？
期間の目安は、要件定義のみで2〜4か月、小規模PoCで3〜6か月、標準機能中心の導入で6〜12か月です。複数基幹と高可用性を含む刷新は、12〜36か月以上になります。
実際の期間は、連携先数や既存データの品質、移行量によって変わります。受入試験や並行稼働、地域ごとの展開計画も、期間に影響します。
納期を短くしたい場合も、PoCと性能試験は削らず、対象範囲を段階化します。
まとめ
開発では、MDMSの機能に加えて、HESやCISとの境界を明確にします。請求や設備、分析との境界も、同じように整理します。さらに、VEEや計測粒度、メーター台数、ピーク処理も要件に含めます。
データ保持や通信欠損、請求締め、将来の5分値化も要件に落とし込みます。こうした要件が、開発の土台になります。
開発を成功させるための要点
進め方は、現状調査と非機能要件の定義から始めます。実データを使ったPoCとRFPを経て、設計・開発、異常系を含む試験、並行稼働、段階展開の順に進みます。
費用の幅は、要件定義で300万〜1,000万円、PoCで1,000万〜3,000万円、標準導入で3,000万〜1.5億円です。複雑な個別連携は1.5億〜5億円、大規模刷新は5億〜20億円超になります。正式な見積もりでは、5年TCOまで比べます。
最初に取り組むべき次の一歩
初期準備から試験、展開まで、次の順に取り組みます。
- 対象メーター数と将来計画、計測間隔、HES・CISの構成を1枚に整理します。請求締め、連携先、欠損データの扱いも加えます。
- 資料をもとに要件定義やPoCの見積もりを複数社から取り、VEEと異常系の共通テストを実施します。
- 現場の業務とデータを確認しながら、段階的に進めます。
この進め方によって、制度変更や再生可能エネルギー、蓄電池、EV、DRへの拡張にも対応しやすくなります。
▼全体ガイドの記事
・スマートメーター管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。