電力託送管理システム開発の発注/外注/依頼/委託方法について

電力託送管理システムの発注・外注・依頼では、料金計算機能だけでなく、30分電力量、契約、計画提出、精算、監査証跡までを一つの業務要件として整理することが重要です。制度改定や異常値の再計算に耐えられる設計を前提に、予算と責任分界を決める必要があります。

この記事では、一般送配電事業者・小売電気事業者・発電事業者・アグリゲーターが、電力託送管理システムをどのような形態で発注し、RFPや要件をどう整理し、請負・準委任などの契約をどう選ぶかを解説します。公開価格が少ない分野の費用相場、委託先の比較方法、見積で見落としやすい項目、FAQまでをまとめています。

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

電力託送管理システムの発注で最初に整理する全体像

電力託送管理システムは、発電事業者や小売電気事業者が送配電網を利用する際の契約・使用量・託送料金・請求・精算などを、正確かつ監査可能に処理する基幹システムです。発注前に「電気料金を計算するシステム」とだけ定義すると、必要な連携や例外処理が抜けやすくなります。

中心になるのは、事業者・需要家・供給地点特定番号・受電地点特定番号・契約・料金種別などのマスタ管理、30分電力量や確定使用量の取込、欠測・訂正データの品質検証、託送料金の計算、請求・精算、明細出力、再計算、遡及訂正です。さらに、広域機関システムへの計画提出、スイッチングや契約変更、帳票、監査ログも発注範囲に含めることがあります。

一方で、小売CRM、顧客向け請求、需給管理、スマートメーターのHES・MDMS、発電設備のSCADA・EMS、データレイクは別システムとして運用されている場合があります。対象範囲を機能名ではなく「どのデータを、どの部門が、いつ確定させ、どの外部へ渡すか」で区切ると、重複発注と責任の押し付け合いを防げます。

一般送配電事業者であれば、託送契約、料金計算、精算、災害時の情報抽出、制度改定への追従が中心になります。小売電気事業者であれば、託送料金を含めた顧客請求や需要予測との連携が重要です。発電事業者やアグリゲーターであれば、発電計画、受電地点、インバランス、複数拠点の実績管理が主な論点になります。

目的も「老朽化したシステムを刷新する」だけでは足りません。制度改定時の改修期間を短くする、月次精算の手作業を減らす、欠測や訂正の原因を追えるようにする、災害時に必要なデータを安全に抽出するなど、成果を測れる表現にします。目的が定まると、パッケージ導入か個別開発か、段階導入か一括刷新かを比較しやすくなります。

電力託送管理システムの発注形態はどれを選ぶべきですか？

結論として、制度対応や電力業務の標準機能を短期間で取り込みたい場合はパッケージ、既存システムとの接続や独自の料金・精算ルールを優先する場合は個別開発が候補になります。実務では、託送業務のコアをパッケージ、API・データ基盤・周辺画面をクラウドや個別開発で補うハイブリッド方式も有力です。

パッケージは、契約・料金計算・精算など、電力業務で共通しやすい機能を利用できるため、制度知識やテスト資産を活用しやすい方式です。三菱電機の公開情報（出典: 三菱電機「託送運用システム／調整力精算システム」、2026年確認）によれば、同社は複雑で煩雑な料金計算を伴う送配電事業者の託送業務を支援する「託送業務支援パッケージ」を公開しています。

ただし、標準機能があることと、自社業務にそのまま合うことは別です。料金制度の設定変更で対応できる範囲、個別改修の単価、ライセンス、保守の対象、データ移行、他社製品との連携方法を確認します。業務をパッケージに合わせる場合も、例外処理と制度改定時の運用を先に洗い出しておくことが大切です。

クラウド方式は、開発環境・バックアップ・監視を準備しやすく、データ量や利用拠点の増加に合わせて拡張しやすい特徴があります。HESやMDMSから取り込んだデータを検証し、託送業務アプリケーションへ渡すAPI層を設けると、システム間の直接接続を減らせます。将来の分析や災害時の抽出も、データ基盤の設計段階から考えられます。

一方で、重要なデータを扱うため、ネットワーク分離、認証、暗号化、鍵管理、ログ保存、バックアップ、障害時の復旧責任をRFPに記載します。クラウド費用は初期開発費と別に、ストレージ、転送量、監視、バックアップ、DR、サポートの月額を見積もります。安価な初期見積だけで判断すると、運用開始後の費用が膨らむことがあります。

スクラッチ開発は、独自の料金モデル、既存のデータ構造、複雑な承認フローに合わせやすい方式です。その反面、制度改定のたびに改修と回帰テストを自社または委託先が担い、担当者の退職やベンダー変更で保守が難しくなるリスクがあります。設計書、計算式の仕様、テストケース、運用手順を成果物として残す契約が欠かせません。

ハイブリッドでは、料金計算や契約管理を業務パッケージに寄せ、データ連携、分析、災害時の情報抽出、利用者向け画面を個別に構築するように役割を分けます。方式を選ぶ際は、機能の多さだけでなく、マスタの正本、エラーの戻し先、再計算の起点、障害時の連絡先を図にして比較します。

RFPと要件整理には何を書けばよいですか？

RFPは、開発会社に機能一覧を渡すだけの資料ではありません。事業区分、対象エリア、現行システム、データ量、制度対応、可用性、移行、運用、セキュリティ、見積条件を同じ前提で比較するための共通文書です。未確定の項目は無理に決めず、提案で確認したい論点として明記します。

要件定義では、契約の新規・変更・終了、供給地点の異動、計量値の確定、欠測の補正、料金計算、請求、入金、再計算、差額精算、取消を業務シナリオにします。各シナリオについて、入力データ、処理期限、担当者、承認者、出力、エラー時の処理、再実行の方法を記載します。

特に、地点番号や事業者コード、契約期間、料金種別、30分値、検針日、確定フラグ、訂正理由、計算バージョン、精算状態は、項目定義と履歴の持ち方まで確認します。単純な上書きではなく、いつ、誰が、どのデータを、どの制度バージョンで変更したかを追跡できる構造が必要です。

外部連携は「API連携あり」と書くだけでは比較できません。HES・MDMS、料金・請求、会計、需給管理、広域機関システム、顧客・事業者ポータルなど、接続先ごとに方式、データ項目、送受信頻度、再送、重複排除、エラー通知、認証、保守担当を整理します。電力広域的運営推進機関の公開仕様（出典: 「広域機関システムとの連携に関する規格・仕様等」、2025年7月更新）によれば、計画提出にはファイルアップロード、JX手順、Web-APIが提供されています。採用方式と仕様変更への追従方法をRFPで確認します。

性能要件は、対象地点数、契約数、1日あたりの30分値件数、ピーク時の取込件数、月次計算の締切、同時利用者数、帳票出力時間で示します。例えば「大量データに対応」ではなく、「全対象期間の計算を締め日の何時までに完了し、異常データを何分以内に検知する」と書くと、テストと受入基準につながります。

電力託送に関わるデータは、契約情報、使用量、設備・地点情報などを含むため、業務機能と同時にセキュリティ要件を定義します。権限を役職だけでなく事業者、エリア、データ種別、操作種別で分け、特権IDの管理、操作ログ、脆弱性対応、バックアップ、復旧訓練、インシデント報告、再委託先の管理まで対象にします。

経済産業省の公開情報（出典: 経済産業省・資源エネルギー庁「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」、2025年）によれば、電力事業者の具体的な対策を支援する手引きが公表されています。託送管理が制御系と直接接続しない場合でも、委託先・再委託先、脆弱性の連絡、資産管理、終了時のデータ返却をRFPと契約に落とし込む根拠になります。

受入基準は、画面が表示されることではなく、業務結果を検証できる形にします。旧システムと新システムへ同じ入力を与えた計算突合、制度改定前後の結果、欠測・訂正・取消・再計算、異常終了からの再実行、権限別のログ、性能、バックアップからの復旧を試験項目に含めます。差異が出た場合に理由を説明できることまで確認すると、稼働後の精算トラブルを抑えられます。

請負と準委任はどのように使い分けますか？

契約形態は、作業の不確実性と成果物の定義に合わせて選びます。要件が固まり、完成させる機能・品質・納期・受入基準を合意できる部分は請負、要件整理や専門家支援のように作業時間と役割を定めて進める部分は準委任が基本的な考え方です。電力託送では、全工程を一つの契約に詰め込まず、フェーズごとに分ける方法が現実的です。

請負契約に向くのは、基本設計以降の機能開発、確定した連携アダプター、帳票、データ移行ツール、テスト環境などです。契約書や個別仕様書には、成果物、納期、検収条件、瑕疵や不具合への対応、変更管理、再委託、知的財産権、ソースコードや設計書の引渡しを記載します。

ただし、料金制度の解釈や現行業務が未整理のまま請負にすると、前提の抜けが変更要求として積み上がります。見積を安く見せるために要件定義や移行を除外し、後から追加請求する構造になっていないかを確認します。請負にする範囲と、発注者が準備するデータ・判断・承認を分けて書くことが重要です。

準委任は、現行業務の調査、制度ルールの整理、RFP作成支援、アーキテクチャ検討、ベンダー評価、プロジェクト管理など、成果物だけでなく専門的な作業や助言そのものに価値がある段階で使いやすい契約です。発注者側に電力業務とITの両方を理解する人材が不足している場合、要件定義だけを先行して外注する方法もあります。

準委任では、作業時間、体制、役割、会議体、報告、成果物の品質、情報管理、指揮命令系統を明確にします。完成した機能の保証を期待するなら、その部分だけ請負へ切り出します。契約形態の名称だけで安全性を判断せず、要件変更の扱い、責任の所在、再委託、障害対応の費用を条項単位で確認します。

不確実性が高い場合は、現状調査と要件定義を第1段階、方式選定と基本設計を第2段階、開発・移行・試験を第3段階、運用保守を第4段階として発注します。各段階の終了条件、次段階へ進む判断、成果物の利用権、見積の再提示方法を定めておくと、大規模な手戻りを抑えられます。

段階発注は、発注者が複数社を比較する機会を増やせる反面、フェーズ間の引継ぎが弱いと情報が失われます。業務ルール表、データ項目定義、連携一覧、課題・決定事項、テスト方針を次の工程へ正式に引き継ぐことを契約条件にします。要件定義会社と開発会社を分ける場合は、設計の責任分界と説明責任を特に確認します。

電力託送管理システムの費用相場はいくらですか？

電力託送管理システム単体の公的な価格表や統一された公開相場は確認できません。そのため、以下は一般的な受託開発相場に、30分値の大量処理、料金計算、複数の外部連携、監査、24時間運用、データ移行、災害対策などの要件を加味した予算検討用の推定です。正式な見積ではなく、RFP前の仮置きとして利用してください。

既存パッケージの標準導入は3,000万〜8,000万円、期間は6〜12か月が一つの目安です。料金計算や帳票を標準機能に寄せ、連携先と移行範囲を限定した場合のレンジです。パッケージに制度・業務カスタマイズ、複数エリア、外部API、精算、受入試験を加えると、5,000万〜1.5億円、9〜18か月程度を見込みます。

クラウド基盤と業務アプリケーション、APIを組み合わせる場合は3,000万〜1億円、9〜18か月程度が仮置きの目安です。大規模なスクラッチ開発や基幹刷新、複数システムの移行、並行稼働、高可用性、DRまで含める場合は1.5億〜5億円以上、24〜48か月に及ぶことがあります。対象地点数、契約数、連携本数、過去データの年数、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を成果物として作る方法があります。

最も重視すべきなのは、電力業務とシステム開発の両方を理解し、制度変更や障害時にも説明責任を果たせる体制です。料金計算の実績だけでなく、計算突合、データ移行、外部連携、セキュリティ、再委託、保守、復旧訓練まで質問し、同じ前提で複数社を比較してください。担当者の経験を設計書とテスト資産に残せる会社が、長期運用で安心しやすい委託先です。

まとめ

電力託送管理システムの発注では、パッケージ・クラウド・スクラッチの方式を先に決めるのではなく、託送契約、使用量、料金計算、請求・精算、外部連携、移行、監査、災害時対応の範囲を整理します。特に30分値の品質、欠測・訂正・再計算、制度ルールのバージョン管理、広域機関システムとの連携を、RFPと受入基準に落とし込むことが重要です。

見積は、初期費用だけでなく、要件定義、連携、移行、試験、教育、クラウド、監視、保守、制度改定、障害復旧を含めた総保有コストで比較します。委託先には、同種の電力業務実績、担当範囲、再委託構造、制度変更の対応方法、RTO・RPO、成果物、契約終了時の引継ぎを確認します。

最初の一歩は、現行システム、事業者・地点・契約マスタ、30分値、料金ルール、外部連携、手作業、例外処理、障害対応を一覧にすることです。そのうえで要件定義を先行発注するか、複数社へ同じRFPを提示し、制度変更と障害に強い提案を選びます。安い開発会社を探すだけでなく、将来の変更と運用まで支えられるパートナーを選ぶことが、電力託送管理システムの発注成功につながります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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