電力託送管理システムの発注は、まず現行業務とデータを整理し、発注範囲と方式を決めるところから始まります。そのうえでRFPに要件と責任範囲を書き、契約、費用、委託先の順に進めると、制度改定や精算に対応しやすくなります。
▼全体ガイドの記事
・電力託送管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
電力託送管理システムの発注で最初に整理する全体像
電力託送管理システムは、発電事業者や小売電気事業者が送配電網を利用する際の契約・使用量・託送料金・請求・精算を、正確かつ監査可能に処理する基幹システムです。発注範囲を料金計算だけと見てしまうと、必要な連携や例外処理が抜けやすくなります。
託送管理と周辺システムの境界
発注側は、契約から精算までの業務と周辺機能を分けて、託送管理の範囲を整理します。
- マスタ管理：事業者、需要家、地点、契約、料金種別の管理
- 使用量処理：30分電力量や確定使用量の取込みと、欠測・訂正の検証
- 料金・精算：託送料金の計算、請求、精算、明細出力、再計算、遡及訂正
- 周辺業務：計画提出、スイッチングや契約変更、帳票、監査ログを含む場合があります
小売CRMや顧客請求、需給管理のほか、HES・MDMS、SCADA・EMS、データレイクが別システムになっている場合もあります。データを確定する部門と外部への受け渡し時点まで決めておくと、重複発注や責任の押し付け合いを防げます。
事業区分と発注目的の明確化
事業区分によって優先する機能は異なります。そこで、自社に必要な業務を次のように確認します。
- 一般送配電事業者：託送契約、料金計算、精算、災害時の抽出、制度改定を重視します。
- 小売電気事業者：託送料金を含む顧客請求と需要予測との連携が重要です。
- 発電事業者・アグリゲーター：発電計画、受電地点、インバランス、複数拠点の実績を扱います。
刷新そのものに加えて、改修期間や月次精算の手作業を減らすなど、目的は測れる形にしておきます。欠測の原因追跡や災害時の安全なデータ抽出も、目的の候補になります。目的が定まると、パッケージか個別開発か、段階導入か一括刷新かを比べやすくなります。
電力託送管理システムの発注形態の選び方
制度対応や標準機能を早く取り込みたい場合はパッケージが、独自ルールや既存接続を優先する場合は個別開発が候補になります。また、コア業務をパッケージにし、APIや周辺機能を個別開発するハイブリッド方式もあります。
託送業務支援パッケージの導入
パッケージは共通機能や制度知識、テスト資産を活用しやすい一方で、自社業務への適合性も確かめる必要があります。
三菱電機の公開情報（出典：三菱電機「託送運用システム／調整力精算システム」、2026年確認）によれば、同社は、複雑な料金計算を伴う送配電事業者の業務を支援する託送業務支援パッケージを公開しています。
標準機能が自社業務に合うとは限りません。そのため、適合性は次の項目で見ておきます。
- 設定と改修：料金制度の設定範囲と、個別改修の単価
- 契約条件：ライセンスと保守対象
- 移行・連携：データ移行と、他社製品との接続方法
- 例外運用：業務を合わせる場合の例外処理と、制度改定時の運用の洗い出し
クラウド基盤とAPIの組み合わせ
クラウドとAPIは、拡張性や連携を支える仕組みです。だからこそ、基盤、セキュリティ、運用費を合わせて設計します。
- 基盤：開発環境、バックアップ、監視の準備と、データ量や拠点の増加への対応
- APIとデータ活用：HES・MDMSのデータを検証して業務アプリへ渡し、直接接続を減らす。分析や災害時の抽出も検討する。
- セキュリティ：ネットワーク分離、認証、暗号化、鍵管理、ログ保存をRFPに記載
- 運用費と責任：復旧責任を定めたうえで、ストレージ、転送量、監視、バックアップ、DR、サポートの月額費を初期費と分けて示す
初期費用だけで判断すると、運用開始後に費用が膨らむことがあります。
スクラッチ開発とハイブリッドの比較
独自性と標準機能の使い方を比べたうえで、保守や運用の責任も含めて方式を選びます。
- スクラッチ開発：独自の料金モデル、データ構造、承認フローに合わせやすい一方、制度改定時の改修と回帰テストが必要です。
- 保守資産：退職やベンダー変更に備えて、設計書、計算仕様、テストケース、運用手順を納品物にする
- ハイブリッド：料金計算と契約管理はパッケージに寄せ、連携、分析、災害時抽出、利用者画面を個別に構築する
- 比較軸：マスタの正本、エラーの戻し先、再計算の起点、障害時の連絡先を図で示す
RFPと要件整理の記載内容
RFPは、機能一覧を渡す資料ではなく、各社が同じ前提で提案できるようにするための資料です。事業区分や対象エリア、現行システム、データ量に加えて、制度対応、可用性、移行、運用、セキュリティ、見積条件まで、共通の前提としてそろえます。未確定の項目は無理に決めず、提案段階で確認したい論点として明記します。
業務ルールとデータ項目の具体化
業務シナリオには、新規・変更・終了、地点異動、料金計算を含めます。また、計量値確定、欠測補正、請求、入金も入れます。再計算や差額精算、取消も対象に入れます。
各シナリオでは、入力データと期限、担当と承認者を定めます。出力、エラー処理、再実行方法も、あわせて決めておきます。データ項目は、定義と履歴の持ち方まで確認しておきます。
- 識別・契約：地点番号、事業者コード、契約期間、料金種別の整理
- 計量・精算：30分値、検針日、確定フラグ、精算状態の定義
- 変更履歴：訂正理由や計算バージョンを記録し、変更者と制度版を追跡する
変更は、いつ誰がどのデータをどの制度版で変更したかを追える構造で扱います。
外部連携と性能要件の数値化
外部連携と性能は、接続先や業務量を具体的にしたうえで比べます。RFPには次の条件を記載します。
- 接続条件：方式、項目、頻度、再送、重複排除、エラー通知、認証、保守担当の定義
- 接続先：HES・MDMS、料金・請求、会計、需給管理、広域機関、各種ポータルの洗い出し
- 処理規模：地点数、契約数、1日あたりの30分値件数、ピーク時の取込件数
- 性能基準：月次計算の締切、同時利用者数、帳票出力時間、異常検知までの時間を定める
電力広域的運営推進機関の公開仕様（出典：「広域機関システムとの連携に関する規格・仕様等」、2025年7月更新）によれば、計画提出にはファイルアップロード、JX手順、Web-APIが提供されています。そのうえで、採用する方式と仕様変更への追従方法を確認します。
求める性能は、「大量データに対応」と書くより、締め日の計算完了時刻まで定めるほうが具体的です。具体化すると、テストと受入基準につながります。
セキュリティと受入基準の定義
契約、使用量、設備・地点情報を扱うため、業務要件、セキュリティ、受入条件を合わせて定義します。
- 権限管理：役職に加えて、事業者、エリア、データ、操作ごとに区分する
- 運用対策：特権IDの管理、操作ログ、脆弱性対応、バックアップ、復旧訓練、インシデント報告
- 委託先管理：再委託先や資産管理、脆弱性連絡、終了時のデータ返却を、RFPと契約に定める
- 業務試験：同じ入力で旧新計算を突合し、制度改定の前後で結果を検証する
- 異常系試験：欠測、訂正、取消、再計算、異常終了後の再実行、権限別ログ、性能、バックアップからの復旧の確認
経済産業省の公開情報（出典：経済産業省・資源エネルギー庁「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年）によれば、電力事業者向けの対策手引きが公表されています。託送管理が制御系と直結しない場合でも、この手引きは委託先管理を検討する根拠になります。
試験では、差異の理由まで説明できるかを確かめ、精算トラブルを抑えます。
請負と準委任の使い分け
契約は、作業の不確実性と成果物に合わせて選びます。機能や品質、納期、受入基準を合意できる部分は請負、要件整理や専門家支援は準委任が基本です。全工程を一契約に詰め込むより、フェーズごとに分けるほうが現実的です。
完成責任を明確にできる開発の請負
請負に向くのは、基本設計以降の機能開発、確定した連携アダプター、帳票、データ移行ツール、テスト環境です。契約書や仕様書には、次の項目を定めます。
- 成果と検収：成果物、納期、検収条件、瑕疵や不具合への対応
- 変更と委託：変更管理と再委託の扱い
- 権利と引渡し：知的財産権、ソースコード、設計書の引渡し
制度の解釈や現行業務が未整理のままだと、前提の抜けが後から変更要求になります。そのため、要件定義や移行を除外したうえで追加請求する構造になっていないかを確認します。
請負の範囲と、発注者が準備するデータ、判断、承認は分けて記載します。
要件定義と専門人材支援の準委任
準委任は、助言や専門作業を進める段階で使いやすい契約です。そのため、作業内容と契約条件を具体化しておきます。
- 対象業務：現行調査、制度整理、RFP作成、方式検討、ベンダー評価、進行管理
- 先行支援：電力業務とITの人材が不足する場合、要件定義を先行して外注できます。
- 契約条件：時間、体制、役割、会議、報告、成果物品質、情報管理、指揮命令系統の定め
- 責任範囲：完成保証が必要な機能は請負に分け、変更、再委託、障害費用を条項ごとに確認する
安全かどうかは、契約形態の名称よりも、責任の所在を条項ごとに確認して判断します。
要件定義・開発・運用の段階発注
不確実性が高い案件は、調査から運用保守までを段階に分けて発注します。各段階は、次の順で進めます。
- 現状調査と要件定義を行います。
- 方式を選び、基本設計を進めます。
- 開発、移行、試験の順に実施します。
- 運用保守へ引き継ぎます。
各段階の終了条件、次へ進む判断、納品物の利用権、見積の再提示の方法を決めておくと、大規模な手戻りを抑えられます。
段階発注は複数社を比べる機会を増やせる一方、引継ぎが弱いと情報が失われます。そのため、業務ルール表やデータ定義、連携一覧、課題、決定事項、テスト方針を正式に引き継ぎます。
要件定義の会社と開発の会社を分ける場合は、設計の責任をどこで分けるか、説明責任とあわせて確認します。
電力託送管理システムの費用相場
電力託送管理システム単体の公的な価格表や統一された公開相場は確認できません。
ここで示すのは、一般的な受託開発の相場に託送特有の要件を加えた、予算検討用の推定です。想定しているのは、30分値の大量処理、料金計算、連携などです。監査、24時間運用、移行、災害対策なども含めています。正式な見積ではなく、RFP前の仮置きとして使ってください。
方式別の初期費用と期間の目安
方式別の費用と期間は、導入範囲によって変わります。ここでは、予算検討の起点になる幅を示します。
- 標準パッケージ：3,000万〜8,000万円、期間は6〜12か月が目安
- カスタマイズ導入：5,000万〜1.5億円、期間は9〜18か月程度
- クラウドと業務アプリ：3,000万〜1億円、期間は9〜18か月程度
- 大規模刷新・スクラッチ：1.5億〜5億円以上、期間は24〜48か月に及ぶ場合があります
標準導入の幅は、連携先や移行を限定した場合のものです。カスタマイズでは、複数エリア、API、精算、受入試験などが加わります。
大規模刷新では、複数システムの移行、並行稼働、高可用性、DRを含む場合があります。地点数、契約数、連携本数、過去データの年数、RTO・RPOによって費用は変わります。
SIA株式会社の整理（出典：「受託開発費の相場と9つの決定要素」、2026年7月更新）によれば、開発費は人月単価と工数をもとに算出されます。また、難易度や役割、要件の不確実性も影響します。託送管理では画面数より、計算ルール、例外処理、データ品質、外部仕様、試験の深さが費用を左右します。
工程ごとの見積の内訳
費用の偏りを把握できるよう、工程別の費目と構成比を確認します。
- 要件定義・業務設計：初期費用の10〜20%が目安です。
- 連携・データ移行：15〜30%が目安です。
- テスト・移行・教育：15〜25%が目安です。
- インフラ・監視・セキュリティ：10〜20%が目安です。
見積には、アーキテクチャと基本設計、アプリ開発を記載してもらいます。そのうえで、料金計算・精算、外部連携、データ移行を分けて記載してもらいます。インフラ、セキュリティ、テストも、項目を立てて示してもらいます。教育、切替、運用設計は、別の項目として記載してもらいます。
保守改修費は、新規開発費の年15〜25%程度を仮置きします。制度改定を通常保守に含めるか、個別見積にするかも確認します。
クラウド費は、利用料と監視を月額と年額に分けて把握します。ログ・バックアップ、サポート、脆弱性診断、DR環境も、同じように分けて確認します。初期費用だけで比べず、5年程度の総保有コストで判断します。
費用を抑えるための対象範囲と品質の切り分け
料金計算の正確性や監査ログは削らず、導入範囲を分けて費用を調整します。段階導入では、次の順に機能を配置できます。
- 第1段階に契約、使用量、計算、精算、連携、監査を含めます。
- 分析ダッシュボードや高度な予測は第2段階へ回します。
対象エリア、帳票、画面、移行年数、分析機能についても、分けて検討します。
制度ルールを個別プログラムに埋め込まず、料金種別、計算式、適用期間、係数を設定と版管理で扱うと、改修費を抑えやすくなります。標準に合わせる業務と、競争力や法令対応のために残す独自機能を分け、変更に強い構造を選びます。
委託先選定と見積比較の確認ポイント
委託先は、知名度や最安値だけで決めず、共通の評価表で比べます。評価では、電力業務の実績や料金計算、制度対応を確認します。連携、移行、復旧、セキュリティ、保守、再委託についても、同じ評価表の項目として確認します。公開実績があっても、自社と同じ事業区分、データ量、制度範囲を担当したかを確かめます。
電力業務と制度対応の実績の確認
実績は、業務範囲や案件規模、制度変更への対応力に分けて確認します。
- 担当実績：料金計算、計画提出・精算連携、移行規模、並行稼働、障害体制を尋ねる
- 案件規模：非開示案件でも、地点・契約数、データ粒度、利用者数、保守時間帯を確認する
- 制度変更：法令や約款の検知、影響分析、仕様・試験への反映、発注者承認の担当
- 追加費用：設定と改修の範囲、緊急単価、リリース前の計算突合
見積の前提条件・除外項目・単価の統一
見積を比べるときは、範囲や条件を横並びにします。次の項目は、同じ様式で提示してもらいます。
- 対象規模：地点・契約数、データ期間と粒度
- 開発範囲：連携本数、画面・帳票数、移行対象、試験範囲
- 運用品質：性能、可用性、保守時間、クラウド費
移行や総合試験が別料金になっている会社もあります。前提条件と除外項目を同じ様式にそろえ、合計額の違いを確かめます。
極端に低い価格の場合は、要件定義、移行、障害対応に抜けがないかを確認します。また、管理、セキュリティ、教育、切替についても同じように見ます。高い見積には、ライセンス、冗長化、24時間監視、制度改定試験が含まれる場合があります。そこで、同じ品質と範囲にそろえて比べます。
再委託・属人化・障害対応のリスク
提案とSLAで、委託体制、知識継承、障害時の流れを具体化します。
- 役割分担：元請、開発、クラウド、運用会社、再委託先と、それぞれの責任者
- 知識継承：設計書、テスト資産、運用手順、教育記録を組織で維持
- 障害対応：監視対象と検知時間、切り分け、エスカレーション、復旧目標、再送、再計算、報告、再発防止
料金計算の仕様を理解する人、制度改定の判断者、障害時の一次対応者を明確にします。担当者個人の経験だけに頼らない体制が必要です。
経済産業省・資源エネルギー庁の手引き（出典：2025年）でも、委託先を含むサプライチェーン管理が重視されています。そのため、アクセス権、脆弱性情報、インシデント報告、契約終了時のアカウント停止とデータ返却も確認します。
よくある質問
発注では、費用、制度対応、システム境界、契約責任、運用体制がよく問われます。発注前に確認したい疑問に答えます。
電力託送管理システムの開発費用は最初にいくら用意すればよいですか？
標準導入は3,000万〜8,000万円、カスタマイズや複数連携は5,000万〜1.5億円が予算検討の起点です。基幹刷新や大規模スクラッチは1.5億〜5億円以上です。
この金額は正式な価格ではなく、一般的な受託開発の相場と託送の要件から推定した幅です。見積もる前に、地点数、データ量、移行、可用性、制度範囲を整理しておきます。
パッケージとスクラッチ開発はどちらがよいですか？
制度対応や標準業務を早く安定させたい場合はパッケージ、独自ルールや既存資産との連携を優先する場合はスクラッチが候補になります。
発注方法としては、コア業務をパッケージにし、APIやデータ基盤、独自画面を個別に開発する方法も比べます。そのうえで、標準、設定変更、個別開発の境界を確認します。
RFPがなくても開発会社へ相談できますか？
相談はできます。現行業務、対象データ、困っている作業、既存システム、予算、期限をまとめておくと、提案の質が上がります。
完成版のRFPを作れない場合は、要件定義を準委任で先行発注できます。その場合の成果物は、業務ルール表、データ定義、連携一覧、概算見積、開発RFPです。
委託先を選ぶときに最も重視すべきことは何ですか？
電力業務と開発の両方を理解し、制度変更や障害時にも説明できる体制かどうかを重視します。
料金計算の実績に加えて、計算突合、移行、連携について質問します。さらに、セキュリティ、再委託、保守、復旧訓練についても尋ねます。そのうえで、設計書やテスト資産を残せるかどうかを、同じ前提で比べます。
まとめ
方式を先に決めるより、契約、使用量、料金計算の範囲を整理するほうが先になります。精算、連携、移行、監査、災害対応についても、範囲を整理します。30分値の品質や欠測、訂正、再計算も、RFPと受入基準に含めます。制度ルールの版管理と、広域機関システムとの連携も、発注前に確認する項目です。
発注前の比較表と責任分界
見積は初期費用だけでなく、総保有コストで比べます。要件定義、連携、移行、試験の費用を含めて見ます。加えて、教育、クラウド、監視を確認します。保守、制度改定、復旧の扱いも確認します。
委託先には、同種業務の実績、再委託、制度変更への対応、RTO・RPO、成果物、契約終了時の引継ぎを確認します。
現行業務とデータの洗い出し
現行システム、事業者・地点・契約マスタ、30分値を一覧にします。料金ルール、連携、手作業、例外処理、障害対応も、同じ一覧に加えます。
要件定義を先行発注するか、複数社に同じRFPを提示して、制度変更と障害に強い提案を選びます。運用と将来の変更まで支える委託先が、発注の成功につながります。
▼全体ガイドの記事
・電力託送管理システム開発の完全ガイド
▼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を創業。