電力託送管理システムは、契約・計量データ、料金計算と精算、外部連携と監査を管理し、託送業務の正確性と監査可能性を支えるシステムです。
主要機能から導入後の運用まで、発注側が確認しておきたい点を流れに沿って並べています。詳細は下の関連記事で扱っています。
▼関連記事一覧
・電力託送管理システム開発の進め方
・電力託送管理システム開発でおすすめの開発会社6選と選び方
・電力託送管理システム開発の見積相場・費用
・電力託送管理システム開発の発注・外注・委託方法
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
電力託送管理システムの概要
電力託送管理システムは、電力を送り届けるための契約と実績を管理し、託送料金や精算を正しく処理する業務基盤です。
一般送配電事業者が中心に使うシステムという印象を持たれがちですが、小売電気事業者や発電事業者、アグリゲーターも、契約・使用量・計画・請求をつなぐ範囲で関わります。
システムを使う事業者ごとの役割
利用者の事業区分によって、託送管理システムで扱う情報と連携先が変わります。
- 一般送配電事業者：託送契約、地点の状態、利用実績、料金、精算を管理します。
- 小売電気事業者：受け取った使用量と料金の情報を、顧客管理や請求とつなぎます。
- 発電事業者・アグリゲーター：発電計画と実績、インバランスのデータを、計画提出と精算に使います。
託送管理システムは、小売CRMや需給管理などのシステムとは役割が異なります。送配電網の利用に関わる契約や料金、精算を扱うのに対し、他のシステムは顧客接点や需給予測、計量データ収集などを担います。そのため、導入計画では各システムの正本をあらかじめ決めておきます。
一般的な請求システムでは代替しにくい理由
一般的な請求システムでは扱いにくい要件として、料金条件の組み合わせと計量値の訂正があります。託送の料金と訂正には、次の3点が求められます。
- 料金条件：契約の種類、基本・従量料金、損失、接続送電サービス、発電側課金などを、制度や約款に沿って計算します。
- 訂正への対応：30分値の欠測や値の変更があったときに、過去期間を再計算して差額を精算します。
- 計算根拠：入力値と適用ルールを示して、結果を説明できる状態にしておきます。
制度改定や約款変更により、計算式や料金単価、対象期間などが変わる可能性があります。ルールがプログラムに埋め込まれていると、改修のたびに影響範囲が広がります。
料金ルールの版管理や承認履歴を持てる設計が、長期運用のコストとリスクを左右します。
電力託送管理システムの主要機能と構成
受け取ったデータは、マスタ管理から照会・帳票までの5つの機能を通って処理されます。機能は、データの発生から計算結果、訂正、承認、出力までの流れに沿って並んでいます。
- マスタ管理：事業者や地点、契約の情報を管理します。
- 計量データ処理：受け取った30分電力量を検証し、欠測や訂正に対応します。
- 料金計算・精算：契約条件に応じた計算を行い、その結果で精算を進めます。
- 外部連携：関係するシステムや外部機関と、データをやり取りします。
- 照会・帳票・監査・運用：業務データや変更履歴、稼働状況を確認でき、出力も行えます。
契約・地点・計量データの対応づけ
地点や契約は履歴を残し、請求時点の状態を後から再現できる形で管理します。そのために、マスタの登録、異動の履歴、契約の整合性の確認を行います。
- 管理するマスタ：事業者、需要家、供給地点特定番号、受電地点特定番号を登録します。契約、料金種別、電圧区分、適用期間も含みます。
- 異動履歴：地点や契約の変更について、開始日、終了日、変更理由、承認者を残します。
- 契約の整合性：同じ地点で有効な契約が重なっていないかを検証します。
スマートメーターやHES、MDMSなどから届く30分電力量は、受信から確定まで段階を分けて扱います。重複の排除や欠測の判定、補正も、その段階に含まれます。
欠測をゼロとして計算するか、推定値を使うか、後日の確定値で再計算するかは、業務ルールとして決めておく必要があります。データ品質の状態を残しておけば、請求担当者が数字の違いを追いやすくなります。
料金計算・精算と再計算の管理
料金計算では、契約と期間に合うルールを適用し、結果の根拠を後から照会できるようにします。そのために、適用条件、計算の記録、明細の提示の3点を押さえておきます。
- 適用条件：基本・従量料金、損失率、接続送電サービス、発電側課金などを含みます。
- 記録する根拠：入力の版、料金ルール、計算日時、担当者、エラーの内容を残します。
- 明細の提示：請求と精算の内容を書き出し、照会時には根拠も示します。
計量値の訂正や約款の遡及適用が起きたときは、対象範囲を限定して再計算します。全期間を無条件に再計算すると、処理時間が延びます。さらに、確定済みの帳票や会計連携との整合性も崩れます。
再計算に伴って差額を請求するか返金するかに加え、再計算の承認者や、連携済みデータの訂正方法も決めておく必要があります。
外部連携・帳票・監査証跡の一体設計
連携先と計画提出の方式に応じて、接続時の制御と変更時の確認方法を決めておきます。広域機関システムの提出方式は3つです（出典: 電力広域的運営推進機関「広域機関システムとの連携に関する規格・仕様等」、2025年7月更新）。
- 主な連携先：計量データ、顧客・請求、会計、需給、設備・停電、広域機関。
- 計画提出方式：ファイルアップロード、JX手順、Web-API。
- 連携制御：再送や重複送信の扱い、受信確認、エラー通知、仕様改定時のテストを決めます。
画面には、契約・地点・計量値の照会と計算結果を置きます。未処理エラー、再計算の依頼、承認状況も、同じ画面から確認できるようにします。管理者、請求担当、運用担当、外部委託先のあいだで権限を分けたうえで、誰がいつ変更したかを監査ログに残します。
個人情報や契約情報を扱う場合は、画面のマスキング、ログの保管期間、エクスポートの制御、バックアップの暗号化まで要件に含めます。
パッケージ・クラウド・スクラッチの選び方
最適な方式は、標準業務への適合度、制度改定の頻度、既存システムとの連携、対象データ量、セキュリティ要件、保守体制を合わせて判断します。
方式の比較には、初期費用に加えて、5年程度の保守・改修・クラウド利用・移行費を含む総保有コストを使います。
標準化できる範囲が広いときのパッケージ
業務を標準機能に合わせられるなら、パッケージで導入期間を抑えやすくなります。使える機能と導入面の利点を、分けて見ておきます。
- 活用できる機能：契約管理、料金計算、精算、帳票などを使えます。
- 導入面の利点：ゼロから設計するより短い期間で入れられ、制度対応の知見も生かせます。
カスタマイズが増えるほど、更新は難しくなり、標準機能の利点も薄れます。そのため、設定変更の範囲や追加開発の単価、更新時の互換性などを事前に確かめておきます。
ライセンス数や制度改定の保守範囲も、契約の前に確かめておきます。データモデルやエラー処理を自社仕様に寄せすぎないことも、長く使ううえで大切です。
拡張性と運用設計を重視するときのクラウド
クラウドは、データ量や処理負荷の変化に合わせて拡張しやすいのが特徴です。
- 拡張しやすい対象：計量データ、繁忙期の計算、開発環境、バックアップが当てはまります。
- 構成の工夫：連携基盤とAPIを分けておけば、必要な時間帯だけ計算処理を広げられます。
可用性や障害復旧は、クラウド事業者に任せきりにせず、自社側でも設計します。ネットワーク分離や鍵管理、特権アクセスなどは、その設計に含めます。障害時の責任分界も、どこまでを誰が受け持つかを決めておきます。
月額費用は、処理量や保存期間、監視範囲によって変わります。冗長化やバックアップの世代数も、費用を動かす要因です。そのため、試算には通常時だけでなく、再計算や障害復旧時のピークも含めます。
独自要件とスクラッチ・ハイブリッドの境界
独自要件に合わせる方式と、標準機能を組み合わせる方式は、保守の責任も含めて比べます。
- スクラッチ：独自の料金・精算、既存基幹、特殊な承認業務に合わせやすい方式です。
- ハイブリッド：契約と料金はパッケージで、データレイク、API、災害時の抽出はクラウドや個別開発で組みます。
制度改定のたびに改修範囲を判断し、テストデータと保守要員を確保しておく必要があります。加えて、ルール表と計算式を成果物として残します。テストケースや障害対応手順も残します。
方式の境界では、地点・契約・メーターの識別子と、データの正本を明確にしておきます。エラーの返却先や再送の責任者も、あわせて決めます。そうしないと、障害時に複数のシステムが互いに原因を求め合う状態になりかねません。
電力託送管理システム開発の進め方
開発は、契約や計量から精算、提出までの業務を一つの流れとして捉えるところから始めます。画面や機能の一覧は、その流れを踏まえて作ります。
進め方は、現状調査、制度ルールの整理、方式選定の順に準備します。その後は、要件定義と設計・開発を経て、試験、移行リハーサル、並行稼働と進み、本番切替で締めくくります。各段階で判断の基準を決めておくと、次の段階へ進む条件がはっきりします。
現状調査での業務・データ・責任範囲の洗い出し
現状調査では、利用する事業区分と業務の担当範囲を、一つずつ洗い出します。
- 利用する立場：一般送配電、小売、発電、アグリゲーターのうちどれにあたるかを決めます。
- 対象業務：契約受付、地点異動、計量、確定を含みます。料金、請求・精算、計画提出、問い合わせ、訂正も含まれます。
- 業務ごとの情報：入力元、期限、判断者、出力先、例外処理を書き残します。
既存の計量データ管理と託送業務を別々に発注する計画では、注意が必要です。というのも、地点・契約・メーターの対応関係が一致しないと、正しい計算ロジックでも結果が合わないからです。
要件定義の前に、データ辞書と連携項目を洗い出しておきます。コード変換や欠測・重複・遅延の扱いも、あわせて決めておきます。
要件定義での制度ルールと例外処理の固定
制度や約款の内容は、通常時と例外時の条件を含めて、ルール表にまとめます。
- 料金条件：種別、適用期間、計算単位、丸め、税を定めます。損失、訂正、遡及、締め、再計算の扱いも含みます。
- ルールの管理：根拠資料と適用の開始日・終了日、設定変更か改修かを残しておくと、将来の制度改定に対応しやすくなります。
処理性能は数値で定義し、対象地点数や契約数、同時利用者数を確かめます。さらに、1日あたりの30分データ件数と締め処理の許容時間も見ます。
再計算の対象期間や、障害時の復旧時間と復旧時点も、要件として決めておきます。可用性と監査性は受入条件に含め、セキュリティと運用性も加えます。
計算突合・移行リハーサル・並行稼働の実施
テストでは、通常時だけでなく、託送業務の例外ケースも旧新システムで突き合わせます。
- 試験の種類：単体、結合、総合、性能を行います。障害復旧、セキュリティ、受入も含みます。
- 確認ケース：代表月、繁忙期、欠測、訂正を含みます。契約・料金変更、遡及、重複受信も確かめます。
- 差異の調査：ずれが出たときは、丸め、期間、単価、データ品質、コード変換を調べます。
移行では、過去データの対象年数や、地点・契約の履歴、確定済みの計算結果を区分します。帳票、添付資料、監査ログも分けて扱います。
全履歴を移すのか、参照用に保管するのか、再計算に必要な最小限のデータだけを残すのかを決めます。
本番切替の前には、移行リハーサルを複数回行います。そのうえで、締め処理の時間と連携の停止時間、切戻しの条件、問い合わせ体制を確認します。
▶ 詳細はこちら：電力託送管理システム開発の進め方
電力託送管理システムの費用相場と内訳
電力託送管理システム単体の公的な定価や統一された相場はありません。そのため、次に示すのは2026年7月時点の一般的な受託開発相場をもとにした推定です。
推定には、大量データ連携や計算突合、24時間運用を加味しています。監査・セキュリティ要件も含めています。正式な見積ではなく、RFPの規模感をそろえるための目安です。
初期費用の幅：3,000万円から5億円以上まで
予算を検討するときは、開発方式ごとの費用幅を次のとおり目安にします。
- 標準パッケージ：3,000万〜8,000万円程度。
- カスタマイズ導入：5,000万〜1.5億円程度。
- クラウド基盤と業務アプリ・API：3,000万〜1億円程度。
- 大規模スクラッチ・基幹刷新：1.5億〜5億円以上の場合があります。
一般的な受託開発では、中規模が2,000万〜6,000万円、大規模が6,000万〜1.5億円超です（出典: 2026年7月更新の受託開発相場資料、2026年）。
託送案件では、連携数と移行範囲によって、一般的な相場を上回ることもあります。
期間の目安は、標準導入で6〜12か月、カスタマイズを含む案件で9〜18か月、複数の既存システムを統合する案件で24〜48か月です。期間を短くしたい場合は、対象業務を絞って段階的に導入する方法があります。
計算突合や移行リハーサルを省いて期間を縮めると、本番後の訂正費用や業務停止のリスクが増えます。
工程別の内訳による見積の確認
工程ごとの仮の比率を使うと、見積項目の漏れに気づきやすくなります。各区分の比率は、初期費用の総額に対する割合です。
- 要件定義・業務設計：初期費用の10〜20%。
- 連携・データ移行：15〜30%。
- テスト・切替・教育：15〜25%。
- インフラ・監視・セキュリティ：10〜20%。
- 残りの費用：アプリ設計・開発、管理、ドキュメント作成など。
比率は案件によって変わるため、一つの正解として固定しないことが大切です。
費用は、対象地点・契約数や30分データ件数によって変わります。外部連携本数や過去データの移行年数も、費用を左右します。同時実行件数や計算ルール数も影響します。可用性やRTO・RPO、監査ログの保存期間、並行稼働の期間も、費用に関わります。
画面数だけで比べると、計算、データ品質、連携処理の部分が見積から漏れやすくなります。
保守・クラウド・制度改定費の別途見積
初期費用以外にも、運用や制度対応の費用がかかります。保守の範囲によって、負担も変わります。運用に関わる費用は、基盤、運用対応、変更対応、保守改修の4つに分かれます。
- 基盤・ライセンス：クラウド利用、監視、バックアップ、ライセンス。
- 運用対応：問い合わせ、障害、脆弱性、教育。
- 変更対応：制度改定、追加連携。
- 保守改修：新規開発費の年15〜25%程度を仮置きできます。
見積書では、標準保守の対象時間、障害の重要度ごとの受付・復旧目標、料金ルール変更の件数を確かめます。
テストデータ作成、リリース作業、夜間・休日対応も、別に確かめておきます。特に、初期見積が安くても、改修単価や保守範囲が不明確だと、制度変更の時期に予算が膨らむおそれがあります。
▶ 詳細はこちら：電力託送管理システム開発の見積相場・費用
発注・外注・委託の進め方
発注先を探す前に、RFPへ条件を整理しておきます。まず業務範囲と計算ルール、連携仕様を書きます。性能とセキュリティ、移行を加えます。運用と受入基準も、あわせて書きます。
すべてを確定できない場合でも、未確定の項目と決定の期限、前提とする条件を書いておけば、各社の見積条件をそろえやすくなります。
RFPに書く計算・データ・障害の条件
RFPでは、計算、データ、連携の条件を分けて示します。
- 計算：料金種別・単価、基本・従量料金、損失、丸め、税の条件を示します。期間、再計算、差額精算、帳票も含めます。
- データ：地点・契約・メーターの識別子、30分値の形式、確定の時期、欠測・重複・遅延・訂正の扱い、保存年数。
- 連携：方式、頻度、件数、タイムアウトを示します。再送、重複防止、受信確認、エラー通知の扱いも書きます。
非機能要件には、締め処理の完了時刻やピーク時の処理量、同時利用者数を含めます。稼働時間やRTO・RPOも定めます。
また、監査ログや権限、暗号化について定めます。バックアップ、脆弱性対応、障害報告も対象に入れます。
納品物は、ソースコードに加えて、ルール一覧やデータ辞書を明示します。テスト結果、移行・運用・切戻しの手順、教育資料まで、あわせて書いておきます。
業務の確定度による請負と準委任の使い分け
業務がどこまで確定しているかで契約の形態を選ぶと、発注する範囲がはっきりします。
- 請負：要件・成果物が明確な設計、開発、テストに適する場合があります。
- 準委任：作業範囲と体制を決めて進める契約で、成果を固定しにくい制度解釈、現状調査、要件整理、既存データの分析に向く場合があります。
実務では、要件定義だけを先に発注し、成果物と概算を確かめてから設計・開発へ進む段階契約も有効です。
要件定義の成果物が、次の工程の見積にどう使われるかも決めておきます。途中で中止する場合の引き継ぎや知的財産、データの返却も、契約に明記します。再委託と責任分界も、同じ契約書に書きます。
再委託・セキュリティ・終了時の条件
2025年に経済産業省は、電力制御システムのサプライチェーン・セキュリティ対策を支援する手引きを公表しました（出典: 経済産業省「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年）。託送管理システムのRFPと契約にも、次の管理を含めます。
- 委託先管理：誰に業務を任せ、どこまで再委託されているかを管理します。
- セキュリティ：脆弱性、資産、アクセス、監視の各項目を管理します。
- インシデント報告：事故が起きたときに、どの条件で報告するかを定めます。
運用を終えるときや、ベンダーを変えるときに備えて、データの返却形式とバックアップの受け渡し方法を決めておきます。
ソースコードや設定、テスト資産の扱いを確かめます。アカウントの削除や秘密情報の破棄、移行支援の範囲も含めます。
再委託先が海外や複数の階層に及ぶ場合は、アクセスできるデータと作業場所を具体的に決めます。監査権限と事故時の連絡経路も、具体的に決めます。
▶ 詳細はこちら：電力託送管理システム開発の発注・外注・委託方法
開発会社・サービスの選び方
発注先は、知名度や初期見積の額だけで選ばず、託送業務の理解や料金計算の正確性で比べます。外部仕様への追従力、移行と並行稼働、障害時の復旧体制も評価対象になります。
公開されている実績があっても、自社と同じ事業区分、対象データ量、料金ルール、運用時間に対応した実績とは限りません。そのため、提案の時点で証跡を確かめます。
電力業務と制度改定の経験の確認
候補先の実績は、担当した範囲と制度改定時の対応方法まで具体的に確かめます。「電力会社向け」という表現は、その確認の入口として見ます。
- 業務経験：託送契約、計量、料金、精算が中心です。計画提出、スイッチング、発電側課金、災害時の抽出も見ます。
- 制度改定：単価や期間の変更が設定で済んだか、改修が必要だったか、旧新の結果をどう突き合わせたかを見ます。
候補先には、匿名化したサンプルデータを使った計算のデモや、欠測・訂正・遡及を含むテスト方針の提示を求めます。
実績の件数だけでなく、結果を説明できるかを見ます。障害時の再実行方法や担当者の継続性、ドキュメントの品質も評価します。こうした点を見ておくと、導入後の属人化を防ぎやすくなります。
連携・データ品質・セキュリティの評価
候補先には、連携の構成と運用上の優先順位を、図で説明できるかを確かめます。
- 連携先：MDMS、HES、顧客・請求、需給、会計、設備・停電情報。
- 連携設計：API・ファイル・JX手順のどれを使うか、正本、再送、エラー、仕様改定時の試験。
- 業務継続：締め時刻と障害時の優先順位を、設計の段階から組めるかを見ます。
セキュリティでは、ネットワーク分離や認証・認可、特権IDを評価します。暗号化も、同じ観点で確かめます。
脆弱性管理やログ監視、バックアップも見ます。インシデント対応と再委託管理も含めます。
サプライチェーンの確認は、質問票への回答だけで終わらせず、資産一覧、更新手順、脆弱性の報告期限、緊急パッチの検証環境まで確かめます。
保守・復旧・将来の変更に強い体制
提案先の保守体制は、運用中の変更や障害への対応方法と合わせて確かめます。
- 継続業務：制度・単価の更新、データ訂正、仕様変更、障害、問い合わせ。
- 受付・監視：24時間監視の要否、締め時間帯の体制、一次・二次対応の担当。
- 障害時の業務：計算停止、前回確定値での暫定運用、復旧後の再計算を、設計と契約に反映します。
選定の際には、保守担当者の人数と交代時の引き継ぎを見ます。制度改定にかかるリードタイムや、追加改修の見積方法も確かめます。テスト環境、ナレッジの保管場所、終了時の移行支援も、あわせて見ておきます。
自社側にも、業務、データ、セキュリティの責任者を置きます。そのうえで、委託先に任せる範囲と社内で判断する範囲を分けておきます。
▶ 詳細はこちら：電力託送管理システム開発でおすすめの開発会社6選と選び方
導入後の運用と災害時の情報提供
本番稼働の後も、電力託送管理システムの運用は続きます。運用には日次のデータ取込や月次の確定・請求、異常値の確認が含まれ、制度改定への対応や利用者の権限の見直しも組み込みます。バックアップの検証と障害訓練も、運用に組み込みます。
運用KPIには、取込成功率や未処理エラー件数、締め処理の完了時刻、再計算件数、問い合わせの解決時間などを選びます。いずれも、業務の安定性が分かる指標です。
日常運用でのデータ品質と計算根拠の確認
日常運用では、取込データの状態と計算根拠を記録し、異常が起きたときの処理をたどれるようにします。
- 取込確認：件数、期間、欠測、重複、遅延、コード不一致を自動で検知します。
- 異常処理：画面で状況を見て、再送、補正、保留、推定、確定のどの処理をしたかを記録します。
- 計算照会：契約条件、使用量、ルール、計算式、訂正履歴を追えるようにします。
制度改定の際は、改定前後のルールを同じ環境で比較し、代表ケースと境界ケースをテストします。
改定日をまたぐ契約や過去期間の再計算を確かめます。料金単価の変更と丸めの差異も含めます。そのうえで、業務責任者の承認を得て、本番の設定を変更します。
設定変更だけで対応できる範囲と、開発やリリースが必要な範囲は、運用手順に明記しておきます。
災害時に提供する情報と権限の事前定義
電気事業法第34条第1項に基づき、災害時などに自治体等が一般送配電事業者等へ電力データの提供を求められる制度があります（出典: 経済産業省「自治体防災業務における電力データ利活用マニュアル」、2024年）。緊急時用の抽出機能では、次の項目を平常時とは分けて決めておきます。
- 対象情報：停電エリア、通電状況、地点情報。
- 提供手続き：緊急時の承認、目的、対象データ、利用者を決めます。
- 提供記録：誰が何を渡したかを、履歴として残します。
- 情報保護：抽出範囲と代替承認者、緊急アカウントの期限を決めます。暗号化、ログ、削除・保管の方法も含めます。
災害時は処理の速さが求められる一方で、個人情報や契約情報の出力には歯止めが必要です。
平常時に訓練を行い、停電や通信障害が重なった場合でも、最低限の情報提供を続けられるようにします。
電力託送管理システムに関するよくある質問
最後に、導入検討時によく寄せられる質問に答えます。費用や方式の判断は、事業区分や地点・契約数によって変わります。既存システムや制度の範囲も関わるため、自社の条件に置き換えて考えることが大切です。
電力託送管理システムの開発費用はいくらですか？
予算検討用の推定では、標準パッケージ導入は3,000万〜8,000万円程度です。カスタマイズを含む導入は5,000万〜1.5億円程度、クラウド基盤と業務アプリの構築は3,000万〜1億円程度です。
大規模なスクラッチや基幹刷新は、1.5億〜5億円以上になることがあります。対象地点数や連携本数、移行年数の条件をそろえたRFPで、見積を比べます。可用性や制度対応の条件も含めます。
クラウドで電力託送管理システムを構築できますか？
構築はできます。ただし、クラウドを採用するだけで、安全性や可用性が保証されるわけではありません。
ネットワーク分離や認証、暗号化を設計します。ログやバックアップ、災害復旧も、あわせて決めます。障害時の責任分界とデータの保存場所も決め、通常時と再計算時の処理量を試算します。
規制や社内基準に照らして、クラウドに置くデータと閉域環境に残すデータを分ける方法もあります。
パッケージとスクラッチはどちらが良いですか？
標準業務に合わせられ、制度ルールを設定で変えられて、既存システムとの連携も限られるなら、パッケージが候補になります。
独自の料金・精算、複雑な履歴、既存基幹との密接な連携が、競争力や業務継続に直結するなら、スクラッチやハイブリッドを検討します。
標準機能と個別開発の境界は、フィット＆ギャップで確かめます。そのうえで、5年程度の保守・改修費も含めて判断します。
開発会社やサービスを選ぶときの最重要ポイントは何ですか？
最重要なのは、託送業務と料金計算を理解し、計量データの品質や制度改定まで説明できることです。外部連携、移行、障害復旧についても、説明できることが大切です。
候補先には、同じ事業区分やデータ量の実績を確かめます。計算突合の方法や、再計算と訂正の扱いも見ます。保守体制、再委託の構造、制度改定時の責任分界についても確かめます。
価格だけでなく、運用が始まったあとに自社で判断できるドキュメントと体制が残るかも評価します。
まとめ
電力託送管理システムは、契約・地点マスタや30分電力量、料金計算を結ぶ基幹システムです。精算や計画提出のほか、帳票、監査、災害時の情報提供も扱います。
機能を増やすことより、制度改定やデータ訂正が起きても、計算結果の根拠を説明し、必要な処理を安全に再実行できる状態を作ることが大切です。
導入前に押さえる3つの要点
第一に、自社の事業区分と業務範囲を定めたうえで、小売CRMや需給管理との境界を決めます。計量データ管理や設備保全も含めます。
第二に、料金ルールや30分データ、欠測・訂正・遡及の扱いをRFPに落とし込みます。計画提出、移行、性能、セキュリティも含めます。
第三に、パッケージやクラウド、スクラッチを、初期費用だけでなく総保有コストで比べます。総保有コストでは、制度改定や保守、障害復旧、データ返却も含めます。
最初に作成する資料
最初の一歩は、現行業務フローやシステム関連図を集めることです。データ項目一覧、料金ルール一覧、例外処理一覧も、あわせて集めます。過去の計算結果や連携仕様、運用体制も集めておくと、後の検討が進めやすくなります。
資料をもとに、対象範囲や優先順位、段階導入の単位を整理します。予算の上限と候補先への質問も、あわせて書き出します。これらがそろえば、開発会社やサービスの提案を同じ条件で比べやすくなり、導入後の手戻りも抑えられます。
▼関連記事一覧
・電力託送管理システム開発の進め方
・電力託送管理システム開発でおすすめの開発会社6選と選び方
・電力託送管理システム開発の見積相場・費用
・電力託送管理システム開発の発注・外注・委託方法
▼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を創業。