スマートメーター管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

スマートメーター管理システムの開発は、メーターの検針値を集めるだけではなく、HESから受け取ったデータをVEEで検証・補正し、請求や託送、配電運用へ正確に渡すMDMSを中心に設計することが重要です。

本記事では、スマートメーター管理システムの全体像、現状調査からPoC、RFP、開発、並行稼働までの進め方、2026年時点の費用相場、見積もりで確認すべき項目を解説します。既存のCISや請求システムを止めずに更新したい電力小売・送配電・アグリゲーターの担当者が、最初に決めるべきことを整理できます。

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

スマートメーター管理システムの全体像

スマートメーター管理システムは、電力メーターから届く大量の時系列データを業務で使える品質に整える基盤です。一般にはMDMS（Meter Data Management System）を指しますが、実際のプロジェクトではメーター、通信網、HES、MDMS、CIS、分析基盤までをAMI全体として検討します。最初にレイヤーごとの役割を分けると、開発範囲と見積もりの抜け漏れを抑えられます。

AMIは、スマートメーターと通信、収集、データ活用を含む仕組み全体です。HES（Head End System）はメーターとの通信を管理して検針値やイベントを受信し、MDMSは受信データの保存、名寄せ、検証、補正、推定、公開を担います。CIS（顧客情報・料金システム）は契約や顧客、請求を管理します。したがって、MDMSだけを作る場合でも、HESからどの形式でデータを受け取り、CISへどの締め時刻にどの品質の値を渡すかを定義する必要があります。

開発対象を「メーターから請求まで」と一括で呼ぶと、通信回線やメーター交換、請求改修まで含むのかが曖昧になります。RFPでは、メーター本体・通信・HES・MDMS・CIS・顧客ポータル・分析の範囲を図にして、各境界の責任者と連携方式を明記することが大切です。

基本の流れは「スマートメーター、通信、HES、MDMS、料金・顧客・配電・分析システム」です。MDMSには、メーター・通信端末・設置場所・契約の台帳管理、受信データの重複排除、再送、欠損管理、30分値や15分値などの時系列保存、VEE、異常使用量の検知、請求用データの公開、監査ログ、権限管理が必要です。

VEEはValidation（検証）、Editing（補正）、Estimation（推定）の略で、請求や託送に使う値の信頼性を左右します。たとえば、前回値より急増した値を警告し、通信断の時間帯を前後の実績やルールに基づいて推定し、後から実測値が届いたら再計算します。このルールを画面上で変更できるのか、変更履歴を残せるのか、再処理した値をCISへ再送できるのかまで設計に含めます。

2026年時点では、30分値を保存できれば十分という前提を見直す必要があります。5分値や15分値の取得、双方向制御、IoTルート、共同検針、再生可能エネルギー・蓄電池・EVとの連携、DRやDERMSへのデータ提供を将来要件として置きます。ただし、第二世代の導入時期は電力会社や対象地域の計画で異なるため、「2026年1月から全国一斉に始まる」と断定せず、自社の導入計画と制度資料を確認します。

計測間隔が30分から5分になれば、1台あたりのデータ点数は単純計算で6倍になります。メーター台数が10万台で、1日24時間、5分間隔のデータを扱う場合、正常値だけでも1日あたり2,880万点です。イベント、再送、履歴、監査ログまで加わるため、保存領域だけでなく、ピーク受信、再処理、バックアップ、検索性能を同時に見積もる必要があります。

スマートメーター管理システム開発の進め方

開発は、いきなり製品を選んで画面を作るのではなく、現状のデータと業務を可視化してから段階的に進めます。特に請求締め、通信欠損、メーター交換、契約切替のような通常時以外の業務を早い段階で洗い出すと、後半の追加開発を抑えられます。おすすめは、調査、要件定義、PoC、提案比較、設計・開発、試験、並行稼働、段階展開の順です。

最初に、システム導入の目的を「検針業務の自動化」「請求の正確性向上」「停電や通信障害の把握」「DRのデータ活用」などに分けます。そのうえで、メーター台数、増設計画、通信方式、HESの製品とバージョン、CISや請求の連携方式、既存データの保存年数、ピーク時の受信量、欠損率を実測します。台数の現在値だけでなく、3年後、5年後の増加も前提にすることが重要です。

機能要件と非機能要件は分けて整理します。機能要件には台帳、収集、VEE、照会、再処理、通知、APIを含め、非機能要件には可用性、性能、拡張性、RPO・RTO、監査ログ、暗号化、アクセス制御、データ保持、障害時の切替を含めます。たとえば「大量データを処理できる」ではなく、「月次請求締めのピークで何分以内に何件を確定する」と書くと、提案各社を同じ条件で比較できます。

候補製品や開発会社を絞る前に、小規模PoCを実施します。数百から数千メーター分の実データまたは匿名化したデータを使い、正常値、欠損、重複、時刻ずれ、急増、メーター交換、通信再送を再現します。VEEのルールを設定して請求用データを作り、同じ入力に対して同じ結果が得られるか、ルール変更の履歴を追えるか、再処理に必要な時間が許容範囲かを確認します。

RFPには、対象範囲、データ項目、ピーク量、連携先、移行対象、試験データ、受入条件、SLA、保守時間、責任分界を記載します。見積価格だけでなく、標準機能と追加開発の境界、将来の5分値化への対応、APIや原本データの持ち出し方法、障害時の復旧手順を回答してもらいます。SiemensのGridscale X Meter Data Management SaaSは、公式情報で6〜9か月の実装目安を示していますが、自社の連携数や移行量で期間は変わるため、目安をそのまま納期とみなさないことが必要です。

設計では、データモデル、時系列データのパーティション、メッセージキュー、API、権限、監視、バックアップ、障害時の再送を決めます。頻繁に参照する直近データと、長期保管する履歴を同じ場所に置くのではなく、ホット・ウォーム・アーカイブに分けると、性能と保管費用を調整しやすくなります。原本データを再処理できる形で残すことも、制度変更やVEEルール変更への備えになります。

試験は、単体、連携、性能、障害復旧、セキュリティ、業務受入に分けます。通信断が数時間続いた場合、同じ検針値が複数回届いた場合、夏季ピークで受信量が増えた場合、メーターを交換した場合、契約が切り替わった場合、請求締め直前に遅延データが届いた場合をシナリオ化します。新旧システムを一定期間並行稼働させ、顧客・地点・メーターの名寄せと請求値を日次で突合してから、地域や契約種別ごとに段階展開します。

スマートメーター管理システムの費用相場

スマートメーター管理システムの費用は、メーター台数、計測間隔、連携先、VEEの複雑さ、可用性、移行範囲で大きく変わります。MDMS単体の定価や国内案件の公開見積は少ないため、次の金額は2026年時点の予算取り用の推定です。メーター本体、通信回線、HES、データセンター、24時間運用、CIS改修が別契約になる場合は、必ず総額を組み直します。

事前調査、RFI、要件定義だけであれば、300万〜1,000万円、期間は2〜4か月が一つの目安です。数百〜数千メーターで収集、簡易VEE、画面、1〜2連携を試す小規模PoCは1,000万〜3,000万円、3〜6か月程度です。PoCは本番導入の一部を作るだけではなく、性能と業務ルールを検証するための費用として捉えます。

パッケージやSaaSを導入し、標準連携とCIS接続、データ移行、試験、教育まで行う場合は3,000万〜1.5億円、6〜12か月程度が目安です。既存基幹との複雑な連携、高可用性、複数通信、独自VEE、長期履歴、監査を含む中規模の個別開発は1.5億〜5億円、12〜24か月程度です。広域のAMI・HES・MDMS・請求・設備・運用を一体で刷新する案件は、5億〜20億円を超え、18〜36か月以上になる可能性があります。

経済産業省の次世代スマートメーター導入に係るコスト再算定では、5分値データ取得の追加費用を938億円、15分値化を163億円、特定計量を86億円と試算しています（出典: 経済産業省「次世代スマートメーター導入に係るコストの再算定結果」）。これは全国規模でメーター、通信、HES、MDMSなどを含む費用であり、1社のMDMS開発費ではありません。大きな公的試算を自社案件の見積もりに直接当てはめないことが重要です。

最大の変動要因は、メーター台数とデータ粒度です。たとえば10万台で30分値なら1日あたり480万点、5分値なら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ルール、連携先、移行範囲、可用性、セキュリティ、運用時間を同じ条件で提示し、標準機能、設定、追加開発、第三者製品、保守を分けて回答してもらいます。

発注前に、現行システム構成図、データ項目一覧、サンプルの検針値、イベント一覧、メーター台帳、契約・地点・顧客のキー、請求締めの業務カレンダー、連携ファイルやAPI仕様を準備します。個人情報や営業秘密が含まれる場合は匿名化し、秘密保持契約の締結後に詳細データを開示します。データサンプルには、正常値だけでなく欠損、重複、時刻ずれ、異常値、メーター交換前後のデータを含めます。

非機能要件の資料には、平常時とピーク時の処理量、許容遅延、同時利用者数、障害検知時間、RPO・RTO、目標稼働率、バックアップ世代、ログ保存期間、暗号化方式、管理者権限、ネットワーク分離を書きます。電力や分散リソースと接続する場合は、経済産業省が2025年に改定したERABに関するサイバーセキュリティガイドラインVer3.0も確認し、IoT機器やゲートウェイを含む責任分界をRFPへ反映します（出典: 経済産業省「ERABに関するサイバーセキュリティガイドラインを改定」、2025年）。

候補会社は、価格の安い順ではなく、案件の境界と将来の拡張性で比較します。国内の電力・送配電・小売実績、対象メーター台数、最大処理量、VEEの設定自由度、HES・CIS・SCADA・DERMSとの接続、データ移行経験、24時間運用、セキュリティ監査、5年TCO、制度改修の契約条件をスコア化します。

パッケージはVEEや台帳などの標準機能を使いやすく、導入期間を短縮できる可能性があります。SaaSはサーバー更新やパッチの負担を軽くし、台数の増加に合わせて拡張しやすい一方、データ所在、障害時の復旧、料金体系、解約時のデータ返却、カスタマイズの制約を確認します。スクラッチは独自の計量・料金ルールに対応しやすい反面、制度変更、障害復旧、製品寿命まで自社責任になりやすいため、コア機能をすべて自作する必要性を慎重に検討します。

代表的な失敗は、非機能要件を後回しにして本番ピークで処理が遅れること、CISとMDMSの名寄せが合わず請求値の突合に時間がかかること、欠損補完のルールを業務部門と合意しないまま開発することです。対策として、実データに近い負荷試験、顧客・地点・メーターのキー設計、VEEルールの承認者と版管理、異常系の受入条件を契約前に固めます。

もう一つのリスクは、特定ベンダーの通信方式やデータ形式に依存して、将来のメーター追加やHES交換が難しくなることです。標準API、スキーマ管理、原本データの保存、データエクスポート、接続試験用の環境を要件に入れ、障害時の一次対応者と復旧責任を明確にします。見積もりの安さだけで選ばず、変更時の単価、追加連携の見積ルール、保守範囲まで含めて判断します。

よくある質問（FAQ）

ここでは、開発を始める前に特に質問されやすい論点をまとめます。製品名やクラウドの可否だけでなく、データ品質、既存業務、将来の計測粒度、運用責任を合わせて確認することが回答のポイントです。

クラウドやSaaSで構築できますが、すべての案件でパブリッククラウドが最適とは限りません。閉域網、データの所在、暗号鍵、接続先のOT環境、運用責任、障害時の切替、費用の増加条件を確認し、パブリッククラウド、プライベートクラウド、オンプレミスの組み合わせを選びます。

対象メーター数、現在と将来の計測間隔、HESとCISの製品名、連携方式、請求締め、データ保持年数、通信欠損率、想定する利用者、希望する稼働時期を整理します。完成した仕様書がなくても、現行業務の流れと困っている事象、代表的なデータサンプルがあれば、調査・要件定義の相談を始められます。

標準的なVEE、台帳、連携、監査を早く安定させたい場合は、パッケージやSaaSを中心に検討する方法が現実的です。独自の計量・料金ルールや既存OTとの深い統合が競争力に直結する場合は個別開発を組み合わせますが、MDMSの基盤部分まで全面的に自作する必要があるか、将来の制度改修と保守費用を含めて判断します。

要件定義のみなら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への拡張にも対応しやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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