電力託送管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

電力託送管理システムの開発は、現状調査と要件定義から始めます。次に方式選定を行い、設計・開発とテスト・移行へ進みます。この流れをたどると、計算結果の突合と安定稼働につながります。

システムの全体像は、電力託送管理システム開発の完全ガイドもあわせてご覧ください。

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

電力託送管理システムの全体像

電力託送管理システムの主要5機能をハブ図で示した図解。
契約情報から外部提出まで、機能ごとの担当を分けて捉えられます。

電力託送管理システムは、発電事業者や小売電気事業者が送配電網を使う際の契約や料金、精算を支えるシステムです。

計量や申請、照会も管理の対象になります。また、小売の顧客管理・請求システムや、発電所を制御するSCADA・EMSとは隣接しています。

託送固有のルールと事業者間精算は、後から説明できる形で記録しておきます。

託送管理と小売・需給・計量管理の役割の違い

送配電網の利用契約から料金精算までを適切に分けるには、周辺システムとの役割をあらかじめ整理しておく必要があります。

  • 託送管理:送配電網の利用契約と、利用実績に基づく料金・精算
  • 小売CRM:需要家との契約や問い合わせの対応
  • 請求システム:顧客への請求と入金
  • 需給管理・MDMS:需給計画・実績と、計量データの蓄積・品質の管理

託送管理で扱うサービスには、接続供給や振替供給などがあります。さらに、発電量調整供給や需要抑制量調整供給も、対象候補になり得ます。

機能が重なる部分はあります。ただし、最初から一つの大きなシステムにまとめると、責任範囲とデータの正本が曖昧になりやすいです。

東京電力パワーグリッドは、サービス区分や約款、託送料金表を分けて案内しています。

インバランス料金や発電30分電力量の手続きも、それぞれ別に示しています(出典:東京電力パワーグリッド「電力小売託送サービス」、2026年8月確認)。

発注側が、自社の対象業務をサービス区分ごとに洗い出すと、必要な機能の漏れを減らせます。

主要機能の分け方(契約・計量・計算・精算・連携)

各機能は、契約情報の管理から外部提出までを一連の流れでつなぎます。計量データの検証や料金計算、精算も、その流れの中にあります。

  • マスタ管理:事業者、需要家、発電者、供給・受電地点特定番号、契約・料金種別の基礎情報
  • 計量・品質管理:スマートメーター、HES、MDMSなどから値を取り込み、単位、時刻、地点、重複、異常値を検証する仕組み
  • 契約・締め処理:異動や改定、遡及訂正、差額精算、締め処理の管理
  • 料金・精算:料金ルールの適用と、請求明細・事業者間精算結果の出力
  • 外部連携:提出方式に応じた送受信と、再送・受付確認の記録

計量値には、30分電力量や検針値、確定値があります。欠測値や訂正値も、扱う対象です。後から説明できるよう、元データや補正理由を残すことが欠かせません。承認者と再計算履歴も、同じように記録します。

料金・精算では、基本料金、従量料金、損失率のルールを組み合わせます。ほかに、接続送電サービス、発電側課金、インバランスのルールも加わります。

契約変更やスイッチングも、同じ仕組みの中で一貫して管理します。

広域機関システムとの連携方式には、ファイルアップロード、JX手順、Web-APIの3つがあります(出典:電力広域的運営推進機関「広域機関システムとの連携に関する規格・仕様等」、2025年7月更新)。

制度変更に備えた構成:ルールとデータ連携の分離

制度変更やデータ連携に備えるため、システム構成では次のように役割を分けます。

  • 業務処理:業務アプリと料金計算・精算エンジンの分離
  • データ・連携:マスタと履歴を扱うDBと、外部連携基盤の設置
  • 運用・保護:認証、権限、監査ログ、監視、バックアップ、災害対策の設計
  • 料金ルール:適用期間や対象区分、単価、計算順序・丸め・例外、改定前後の版の管理
  • 統合データ:MDMSとHESが別々の場合の、地点・契約・メーター・事業者の結びつけ

料金式は画面やバッチに埋め込まず、変更可能なルール層に切り出しておきます。

名称や地点コードの変換を片方だけで行うと、異動や訂正のたびに不整合が起こります。

そのため、正本マスタと連携IDを先に決めておきます。履歴の保持期間とエラーの戻し先も固めておきます。

データ分析や災害時の情報提供では、業務データと、公開・提供用データの出口を分けます。

ポイント

周辺システムとの役割を分けたうえで、契約・計量・料金・精算の機能をどこまで持つかを決めます。データの正本と責任範囲をはっきりさせておくと、後の改修で迷いにくくなります。

電力託送管理システムの開発の進め方

本番前の確認項目として、料金検証、データ訂正、データ移行、切替準備を並べたチェックリスト図。
料金の差分確認と切替時の照合を、同じ準備の中で扱います。

まず現状調査から始め、要件定義、方式選定、設計、実装、テストへ進みます。続けて移行、並行稼働、本番切替を行い、運用改善につなげます。

料金計算の正しさは、総合テストだけに頼らず確かめます。そのため、早い段階で業務ルールとテストデータを固めます。要件定義の段階から、旧・新システムに同じ入力を与え、結果を突合できる状態を作ります。

現状調査の範囲:業務・データ・責任分界

最初の1〜2か月は、担当者へのヒアリングだけで終わらせず、契約受付から監査までを時系列で見える形にします。

  • 業務フロー:契約受付・計量確定・料金計算、請求・入金・訂正、問い合わせ・監査までの流れ
  • 処理条件:入力元・担当・判断条件、出力先・締め時刻、例外・手作業、現行システムの記録
  • 責任分界:事業者ごとの用語と責任の整理、部署別一覧の一つのプロセス表への統合
  • データ量:地点・契約数、1日あたりの30分値件数、過去データ年数、ピーク時の取込件数
  • 機能範囲:計算締め時間や連携本数を踏まえた、必須機能と将来拡張の切り分け

欠測・重複・時刻ずれ・コード変換を「運用で対応する」と残すと、後工程の費用と納期が膨らみやすくなります。例外を後工程へ残さないよう、業務フローとデータ量を同じ表で管理し、欠測や重複の扱いもその場で決めます。

要件定義で先に決める料金ルールと異常時の処理

要件定義では、機能要件に加えて、料金ルールと異常時の判断を文書にしておきます。

  • 機能要件:契約、地点、計量、料金、精算、帳票、権限、外部連携の範囲
  • 計算ルール:基本・従量料金の順序、単位、端数、損失率、適用期間、改定、エラー、再計算の決まり
  • 根拠と承認:制度根拠と判断者、適用開始・終了日、テストケース、改定承認者を書き残す
  • 欠測・重複:30分値の補完・保留方針と、重複検知キーの決定
  • 再送・再計算:APIタイムアウト時の再送方法と、訂正値到着後の再計算期間

遡及訂正や差額精算も、ルール表に含めておきます。そのうえで、重大エラーと、確認後に処理を続けられる警告を分けます。

この区分があれば、24時間運用でも判断がぶれにくくなります。

パッケージ・クラウド・スクラッチの比較(フィット&ギャップ)

方式ごとに、業務との適合性と運用責任を比べます。あわせて、標準機能、設定変更、個別開発のどこで線を引くかを確認します。

  • パッケージ:電力業務の標準機能と制度対応の知見を使いやすく、標準運用に寄せると期間を短縮しやすい
  • クラウド:環境構築、バックアップ、監視、拡張のしやすさが特徴
  • スクラッチ:独自モデルに合わせやすい一方で、制度改定時の改修負担は大きくなります
  • ハイブリッド:計算・契約はパッケージで持ち、API、データレイク、分析、災害時情報提供はクラウドや個別開発で補う組み合わせ

クラウドでは、ネットワーク分離や暗号鍵、ログ保存の扱いを決めておきます。可用性や障害時の復旧責任も、誰が持つかを明確にします。

スクラッチでは、制度改定に備えて、改修とテスト資産を自社で維持する必要があります。

三菱電機は、複雑な料金計算を含む託送業務を支える、送配電事業者向けのパッケージを公開しています(出典:三菱電機「託送運用システム/調整力精算システム」、2026年8月確認)。

本番前の計算突合と移行リハーサル

本番切替に備えて、テストと移行では次の点を確かめます。

  • テスト工程:単体から総合までのテストに加えて、性能や障害復旧、セキュリティ、受入まで行う
  • 料金検証:通常ケースに加えて、月途中の契約変更、うるう日、時刻ずれのケース
  • データ訂正:欠測補完、計量値訂正、料金改定前後、再計算、取消、差額請求を試すこと
  • データ移行:全件移行か照会用アーカイブかの選択と、法定・監査上の保持期間の決定
  • 切替準備:コード、件数、金額、欠損、権限の照合と、本番前の複数回リハーサル

旧・新システムに同じ入力を与えて、結果の差分を追います。金額だけでなく、地点や契約まで見ます。単価や計算ステップも、差分の確認対象です。

切替当日は、失敗時の戻し方と、旧システムの参照期間を決めておきます。窓口と判断者も、あらかじめ定めておきます。こうした準備があれば、現場が止まるリスクを抑えられます。

ポイント

料金計算の正しさは、要件定義の段階から業務ルールとテストデータを固めて確かめます。旧・新システムの結果を突合できる状態かどうかを見ると、進め方の判断に迷いにくくなります。

電力託送管理システムの費用相場とコストの内訳

標準パッケージ、カスタマイズ、クラウド構成、大規模刷新の初期費用レンジを並べた4枚のパネル図。
カスタマイズとクラウド構成の費用レンジは一部重なります。

公的な価格表はありません。2026年7月時点の受託開発相場をもとにした概算で、料金計算や30分値処理、外部連携を考慮しています。さらに、24時間運用、移行、監査、セキュリティも含めています。RFPを作る前のレンジとして扱い、正式な見積もりとは分けてください。

方式別の初期費用の幅(3,000万円〜5億円以上)

導入方式と個別対応の範囲によって、初期費用と期間は次のように変わります。

  • 標準パッケージ:料金計算と帳票を標準機能に寄せ、連携を絞る場合は3,000万〜8,000万円、6〜12か月が目安です。
  • カスタマイズ:制度・業務対応、複数エリア、精算、移行、外部API、受入試験を加えると、5,000万〜1.5億円、9〜18か月程度です。
  • クラウド構成:業務アプリ・APIを含め、3,000万〜1億円、9〜18か月程度です。
  • 大規模刷新:スクラッチ開発などは1.5億〜5億円以上、24〜48か月になる場合があります。

クラウド利用料は、初期費用とは別に計上します。監視やバックアップ、災害対策も、同じ扱いで別計上になります。月額100万〜500万円程度と仮置きする場合があります。

相場は規模によって差があるため、画面数だけで比べることはできません(出典:SIA株式会社「受託開発の費用相場|人月単価と9つの決定要素」、2026年7月更新)。

費用を左右する主な工程:要件定義・連携・テスト・移行

見積もりでは、費用配分の目安と、作業量を増やす条件を合わせて見ます。

  • 要件定義・業務設計:初期費用の10〜20%が目安です。
  • 連携・データ移行:初期費用の15〜30%が目安となります。
  • テスト等:テスト・移行・教育は15〜25%が目安です。
  • インフラ等:監視・セキュリティを含め10〜20%が目安です。
  • その他:残りをアプリ、計算、帳票、管理画面、プロジェクト管理などへの配分

この配分は、託送特有の作業を見落とさないための概算で、個別案件の統計値ではありません。

費用は、地点・契約数や30分値件数によって変わります。計算ルール数と連携本数も、費用を左右します。移行年数や同時実行件数も加わります。RTOやRPO、並行稼働期間も、費用に響きます。

地点が少なくても、連携先が増えると試験も増えます。広域機関や複数の一般送配電事業者、MDMS、請求、会計との連携があると、試験はさらに増えます。

障害時の再送設計も、費用に影響します。業務を標準機能に合わせると、個別開発を抑えやすくなります。

初期費用と分けて見る保守費・制度改定費

初期費用とは別に、運用費、保守改修費、制度改定費も見積もります。

  • 運用費:クラウド、DB、監視、バックアップ、ライセンス、ヘルプデスクにかかる費用
  • 保守改修:障害・脆弱性・制度改定への改修費は、新規開発費の年15〜25%を仮置きする場合があります。
  • 制度改定:通常保守に含む範囲と、別見積もりの範囲を契約で分けます。
  • 監視体制:24時間365日監視、夜間再計算、休日の制度対応による体制費の増加

料金ルールの設定変更で済む範囲と、プログラム改修が必要な範囲は、契約書に分けて記載します。

重大障害の目標復旧時間やデータ復旧ポイントの設定も、保守体制費に影響します。改定や障害対応が追加契約になると、初期費用が安くても、5年間の総額は割高になることがあります。

初期費用や年額保守を並べて見たうえで、クラウド費や改定対応、追加開発単価も含めて比べます。

ポイント

初期費用は方式と対象範囲によって、3,000万円から5億円以上まで幅があります。運用費や保守改修費、制度改定費は初期費用と分けて、5年程度の総額で比べます。

見積もりを取る際のポイント

「託送管理システムを作りたい」とだけ伝えても、見積もりの前提は揃いません。そこで、対象業務やデータ量、計算ルールをRFPに記載します。外部連携や品質条件、移行範囲も、同じ文書に書きます。

各社に同じ前提で提案を依頼し、金額に加えて、標準機能、個別開発、除外リスクを比べます。

RFPに書く計算・データ・連携の前提

RFPでは、各社が同じ前提で見積もれるように、次の情報を具体的に書きます。

  • 業務・規模:事業者区分、対象エリア、サービス、地点・契約・メーター数
  • データ量:30分値の日次件数、ピーク時間、保持年数、ルール・帳票・利用者数
  • 外部連携:相手、方式、項目、頻度、形式の定義に加えて、API・認証・再送・重複排除の扱い
  • 品質・運用:処理時間、締め時刻、同時実行、可用性、RTO・RPOの記載
  • 移行条件:対象期間、除外データ、コード変換、照合、受入基準の指定

利用者の権限区分と障害時の代替手段も、RFPに盛り込みます。受付確認、バックアップ世代、監査ログの保存期間は、RFPの中で決めておきます。

旧システムの参照期間も、移行条件に含めます。前提が曖昧なままだと、各社の見積もりを比べられません。

開発会社の比較観点:電力業務と運用体制の証拠

実績の数だけでなく、電力業務の知識と稼働後の運用体制を、証拠をもとに比べます。

  • 業務知識:料金計算、制度改定、計量品質、外部仕様への対応の把握
  • 導入・運用:移行、並行稼働、障害復旧、保守要員、追加改修単価の比較
  • 同種実績:同じ事業区分・データ量で、計算や精算を担った経験の有無
  • デモ検証:欠測・訂正・改定・差額精算、API障害、権限、監査ログを使ったデモ
  • 制度対応:制度知識を補う担当者と、改定情報の取り込み頻度の契約上の定め

セキュリティや再委託の構造も比べ、会社名や導入件数は判断材料の一部にとどめます。

電力専用パッケージを扱う会社に限る必要はありません。

可能であれば、匿名化データを使った計算突合を評価します。

契約に定めるセキュリティと再委託の責任

託送管理で扱う情報を踏まえて、契約では次の安全管理と責任範囲を定めます。

  • 対象情報:契約、需要家、計量、設備、事業者間取引の情報
  • アクセス・記録:アクセス制御、特権ID、多要素認証、暗号化、監査ログの整備
  • 運用管理:脆弱性、バックアップ、環境分離、事故報告、データ返却・消去のルール
  • 行政への提供:災害時の提供目的、データ、承認、本人情報、履歴の設計

経済産業省は2025年6月、リスク管理や仕様確認、機器管理などを示す手引きを公表しました(出典:経済産業省「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年6月3日)。

制御系と直接接続しない場合でも、委託先・再委託先の責任分界は確認します。開発環境や運用端末、脆弱性対応も、確認対象になります。

ポイント

同じ前提で各社に提案を依頼し、対象業務、データ量、計算ルール、外部連携、移行範囲をそろえて比べます。金額だけでなく、標準機能や個別開発、除外リスクも並べて判断します。

よくある質問(FAQ)

費用と期間は、対象業務やデータ量、制度対応によって変わります。既存システムの状態も影響するため、ここに示す数字は企画段階で使う初期計画の目安として見てください。

電力託送管理システムの開発費用はいくらですか?

費用は導入方式によって大きく違います。方式ごとの目安を並べると、自社の計画に近い規模感がつかめます。

  • 標準パッケージ:料金計算と帳票を標準機能に寄せ、周辺連携を絞る場合は3,000万〜8,000万円です。
  • カスタマイズ:移行・外部連携を含めると5,000万〜1.5億円程度です。
  • クラウド:クラウド基盤と業務アプリは3,000万〜1億円が目安です。
  • 大規模刷新:スクラッチ開発などは1.5億〜5億円以上が目安です。

公的な一律価格はないため、個別に見積もりを取る必要があります。地点数や30分値、料金ルール、連携本数、移行年数、可用性などの条件をそろえて比べます。

パッケージとスクラッチ開発はどちらが向いていますか?

標準業務に合わせて制度対応や保守知見を活用するなら、パッケージが向いています。

独自料金・精算、既存基幹との深い統合、特殊な事業モデルには、スクラッチやハイブリッドが候補です。

最初から方式を決めつけず、標準機能、設定変更、個別開発を比べます。5年程度の保守・改定費も見ておくと、判断しやすくなります。

開発期間はどのくらいかかりますか?

期間は、方式と対象範囲によって異なります。

  • 標準パッケージ:標準導入なら6〜12か月が目安です。
  • カスタマイズ・複数連携:外部連携を含めて9〜18か月が目安です。
  • 大規模刷新:基幹刷新や並行稼働を含む場合、24〜48か月が目安です。

対象業務や料金ルールを早く確定すると、期間の短縮につながります。テストデータや移行方針、受入基準も、早めに決めておくと効果があります。一方、要件が曖昧なまま実装を急ぐと、再計算や移行のやり直しで長期化します。

セキュリティ要件はどこまで見積もりに入れますか?

初期見積もりには、安全対策や委託先管理、終了時の処理まで含めます。

  • 技術対策:認証・認可、ネットワーク分離、暗号化、ログ、脆弱性対応
  • 運用対策:バックアップ、監視、インシデント報告、再委託先管理の取り決め
  • 終了時:データ返却・消去と、証跡の保管方法を契約で定めること
  • 供給網:制御系に接続しない場合の、開発環境、運用端末、外部サービスの確認

経産省の2025年の手引きなどを参照し、責任分界と証跡の保管方法を契約書に記載します。

まとめ

電力託送管理システムは、料金計算だけでなく、契約・計量・精算も支える基幹業務基盤です。事業者区分に応じて業務範囲を定め、30分値や訂正データを管理します。

広域機関などと連携しながら、制度改定や災害・障害に備えます。

開発で優先する三つのポイント

現行業務、データ、責任分界は、要件定義の早い段階で見える形にします。

料金ルールは版ごとに管理します。欠測や訂正、再計算などをテストできるようにし、差額精算も対象に含めます。

初期費用だけでなく、制度改定や監視、障害復旧まで含めた総保有コストで、方式と発注先を比べます。クラウドや追加開発、セキュリティや再委託の費用も、同じ比較に入れます。

現状調査と概算RFPから始める順番

まず前提を整理し、先行調査や各社の提案評価へと段階的に進みます。

  • 業務・規模:対象エリア、事業者区分、契約・地点数、30分値件数、料金ルールのまとめ
  • 追加条件:外部連携、過去データ、可用性、移行方針の記載
  • 先行発注:現状調査と要件定義だけを先に発注する方法
  • 提案確認:複数社への同条件での依頼と、計算突合、移行リハーサル、制度改定、障害復旧の確認

この順に進めると、実装後の追加費用や手戻りを抑えやすくなります。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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