はじめに
未来明るく電力 基幹システム概要
未来明るく電力の基幹システム群がどのような業務を担い、どのように構成されているかをまとめた資料です。発送電分離・電力自由化・度重なる制度改正のたびに増改築を重ねた結果、いま何が起きているのか——その全体像を把握するための入口としてご覧ください。
1. 未来明るく電力の事業と基幹システムの役割
未来明るく電力(架空)は、発電から送配電、料金・顧客対応、卸電力取引・託送までを担う電力会社である。電力の安定供給という止められない使命を負いながら、同時に自由化市場での競争にもさらされている。
その事業を支えるのが、5つの領域にまたがる基幹システム群である。
検針から料金計算・収納、送配電設備の管理、需給計画と給電指令、卸電力取引JEPXとインバランス精算・託送業務まで——電力事業のバリューチェーン全体を、層状に積み重なったシステム群が支えている。
これらは一夜で作られたものではない。1990年代のメインフレーム時代から、2000年代のクライアント/サーバー化、そして自由化・発送電分離への対応まで、制度が変わるたびに「増築」を重ねてきた歴史的建造物である。
2. 5つの領域が担う業務
基幹システムは大きく 5つの領域 に整理できる。各領域は独立した業務を担いつつ、共通基盤を介して連携している。
| 領域 | 名称 | 主な業務 |
|---|---|---|
| 領域A | 料金・顧客情報(CIS) | 検針・料金計算・収納/消込・契約管理・顧客対応(CRM) |
| 領域B | 送配電設備管理 | 設備台帳・工事管理・保全計画・図面/GIS・停電管理 |
| 領域C | 需給運用・給電 | 需給計画・給電指令・系統運用・予備力管理 |
| 領域D | 電力取引・託送 | 卸電力取引(JEPX)・インバランス精算・託送業務・スイッチング |
| 共通 | 共通・全社基盤 | マスタ管理・帳票基盤・連携基盤(ESB)・認証/権限・バッチ基盤 |
領域A: 料金・顧客情報(CIS)
電力を「使った分だけ請求する」ための中核。検針管理(KN)で使用量を取り込み、料金計算(RY)が単価表・契約種別に基づいて請求額を算定し、収納・消込(SU)が入金を突き合わせる。契約管理(KY)・顧客対応CRM(CS)が顧客との関係を支える。
自由化で料金メニューが多様化し、スマートメーター/次世代検針への移行が進むなかで、最も増改築が激しく、最も古い COBOL 請求ロジックが残る領域でもある。代表テーブルは KENSHIN(検針実績)・KEIYAKU(契約マスタ)・RYOKIN(料金計算結果)・NYUKIN(入金明細)。
領域B: 送配電設備管理
電柱・変圧器・電線路といった膨大な設備を管理する。設備台帳(SB)・工事管理(KJ)・保全計画(HZ)・図面/GIS(GS)・停電管理(TD)から成る。レジリエンス(災害・停電への強さ)を支える基盤であり、SETSUBI(設備台帳)・KOUJI(工事管理)・TEIDEN(停電実績)などが中心。
領域C: 需給運用・給電
電力の需要と供給を一致させ続ける、文字どおり止められないミッションクリティカル領域。需給計画(JK)・給電指令(KD)・系統運用(KT)・予備力管理(YB)が、需給調整市場・容量市場の動向も踏まえながら系統を安定運用する。JUKYU(需給計画)・KYUDEN(給電指令log)が代表。
領域D: 電力取引・託送
自由化・発送電分離とともに新設・拡張されてきた比較的新しい領域。卸電力取引JEPX(TR)・インバランス精算(IB)・託送業務(TS)・スイッチング(SW)・需要予測(YS)が、市場取引と小売事業者間の託送料金精算を担う。TORIHIKI(取引約定)・IMBALANCE(インバランス)・TAKUSO(託送料金)が中心。
共通基盤: 全社を貫く土台
マスタ管理(MS)・帳票基盤(CH)・連携基盤ESB(RN)・認証/権限(NB)・バッチ基盤(BT)。すべての領域が依存するがゆえに、ここが古いと全社の俊敏性を縛る。制度改正時に「触りたくないが触らざるを得ない」ボトルネックになりやすい。
用語の詳細は 用語集 を参照。
3. なぜこうなったのか — レガシーの実態
基幹システムの複雑さは、未来明るく電力固有の事情ではなく、電力業界が歩んだ制度改正の歴史そのものが刻まれた結果である。
3.1 層状に積み重なった技術世代
制度が変わるたびに、既存システムを止めずに新しい層を「上に載せる」対応が繰り返された。結果、複数の技術世代が同居している。
| 世代 | 時期 | 主な技術 | 代表領域 |
|---|---|---|---|
| メインフレーム世代 | 1990年代〜 | COBOL / JCL | 領域A 請求系・共通バッチ |
| クライアント/サーバー世代 | 2000年代 | VB6 / VB.NET / C# | 領域B 設備・各種業務画面 |
| Web / 市場対応世代 | 自由化以降 | Java(一部Web)・PL/SQL | 領域D 取引・託送 |
下の世代を撤去できないまま上に積み増したため、同じ業務でも入口によって通るシステムが違うという状態が生まれた。
3.2 「どれが生きているのか誰も把握できない」
最大の課題はブラックボックス化である。
- 仕様書が失われた、または実装と乖離したプログラムが多数存在する
- 似た名前のコピーが複数あり、どれが本番で動いている版か不明
- 呼び出されている痕跡はあるのに、実物のソースが見つからないプログラムがある
つまり、手元の資産を眺めるだけでは全体像が見えない。「このプログラムを止めたら何が起きるか」を、誰も自信を持って答えられない。
3.3 EOL(サポート切れ)とCOBOL要員の高齢化
- メインフレームや周辺ミドルウェアの EOL(サポート終了) が迫り、セキュリティ・障害対応のリスクが積み上がる
- 請求系の中核を支える COBOL 技術者が高齢化・退職し、改修できる人材が枯渇しつつある
- 「読める人がいないから触れない」→「触れないから塩漬け」という悪循環に陥っている
なぜ塩漬けが危険なのか
塩漬けそのものが問題なのではない。問題は、制度改正(容量市場・需給調整市場・インバランス制度の見直し等)への対応スピードが、レガシーの重みで落ちていくことである。市場ルールの変更に俊敏に追随できないことは、そのまま事業リスクになる。
3.4 発送電分離・制度改正による「増築」
発送電分離、電力自由化、託送料金制度(レベニューキャップ)、容量市場・需給調整市場の創設——。これらの制度改正はいずれも、既存の請求・需給・取引ロジックへの追加対応を要求した。
そのたびに、止められない本番を守りながら継ぎ足す形で対応してきた結果が、今日の層状構造である。増築は正しい判断の連続だったが、棚卸しの機会がないまま積み上がった点に課題が残る。
4. システム構成の全体像
アーキテクチャ
図を読み込み中…
重要な特徴:
- 領域Cの需給・給電系は独立性が高く健全に保たれている(止められないため常にメンテされてきた)
- 領域Aの請求系・共通基盤には、使われていないまま残る資産が集中していると推定される
- 連携は共通基盤(ESB・マスタ・バッチ)を介するため、共通基盤の老朽化は全社に波及する
レガシー言語の分布
| 分類 | 主な言語 | 代表領域 |
|---|---|---|
| メインフレームバッチ | COBOL / JCL | 領域A 請求系・共通バッチ基盤 |
| クライアント/サーバー | VB6 / VB.NET / C# | 領域B 設備・各種業務画面 |
| Web / 市場対応 | Java(一部) | 領域D 取引・託送 |
| データ処理・運用 | PL/SQL / SQL Script / Shell | 全領域のバッチ・連携 |
5. この全体像から何がわかったか
dele は本番に触れない「分身環境」で資産を棚卸しし、依存グラフを再構成した上で、プログラム1本ずつを 5つの証拠 で死活採点した(2026年7月4日時点の推定、証拠期間は2026年4〜5月の実行ログ)。
- 依存グラフは 596本(うちソース提供 397本=66.6% / 呼び出し痕跡から復元 199本=33.4%)
- 死活採点した 397本 のうち、全社の推定非稼働率は 32.2%
- 止められない領域C(需給・給電)は非稼働率1.9%と健全。一方で、レガシー請求系(領域A)と塩漬けの共通基盤に削減余地が集中している
詳しい結果は PoC 成果報告レポート と、経営層向けの PoC ストーリー を参照。プログラム単位で確認したい場合は プログラム一覧 から辿れる。 </content> </invoke>