未来明るく電力システム資産可視化

(お客様の経営層向けの説明資料です)

30秒でわかる要点

問題は、誰も全体を把握できていないことでした。 発送電分離・自由化・たび重なる制度改正のたびに継ぎ足してきた基幹システムは、どのプログラムがいまも使われているのか、誰にも言えない状態になっていました。
本番に一切触れずに、AIで全体像を復元しました。 dele社内に用意した複製環境で資産を棚卸しし、失われていた依存関係を 596本 の図として描き直しました。人手でやれば年単位かかる調査です。
止められない領域はほぼ全部が現役で、減らせる余地は全体の約3分の1だと、証拠つきで示しました。 プログラム1本ずつを5つの証拠で採点した結果、**全社で動いていないと見られるのは32.2%**でした(2026年7月4日時点の推定)。止められない需給・給電はほぼ全部が現役で、減らせる余地は古い請求系と、使われていない共通基盤に集まっていました。

以下、順にご説明します。

第1章: 誰も全体を把握できていない基幹システム

未来明るく電力の基幹システムは、電力事業の全体を支えています。検針・料金・収納を扱う料金顧客系(領域A)、送配電設備の管理(領域B)、需要と供給を合わせ続ける需給・給電(領域C)、卸電力取引と託送(領域D)、そして全社が使う共通基盤です。

問題は、これらが一度に設計されたものではないことです。

発送電分離、電力自由化、託送料金制度、容量市場と需給調整市場。制度が変わるたびに、止められない本番を守りながら新しい部分を継ぎ足してきました。その結果、1990年代のCOBOL、2000年代のVB6と.NET、自由化以降のJavaが積み重なっています。

継ぎ足したこと自体は、そのときどきの正しい判断でした。ただ、棚卸しをする機会がないまま積み上がった結果、次の状態になっています。

仕様書が失われた、または実装と食い違うプログラムが多数
似た名前のコピーが複数あり、どれが本番稼働版か不明
呼ばれている痕跡はあるのに、実物のソースが見つからない

このプログラムを止めたら何が起きるかを、誰も自信を持って答えられません。 さらに、COBOL技術者の高齢化と退職が進み、ミドルウェアのサポート切れも近づいています。制度改正への対応が、古いシステムを抱えているせいで遅くなる。これが経営課題でした。

第2章: 本番に触れずに試せる複製環境

deleがまず行ったのは、本番システムに一切触れずに、同じ構成の複製をdele社内に用意することでした。

図面が一部欠けた設備を、残っている図面と部品だけを手がかりに別の場所へ組み上げ、実際に動かせる状態まで仕上げた、ということです。

この複製環境があると、次のことができます。

本番システムに触れず、止めず、業務に影響を出さないまま、このプログラムを止めたらどうなるかを何度でも試せます。

止められない電力の基幹システムでは、本番での検証はできません。複製環境があるので、思い切った削減も安全に検討できます。

第3章: AIで失われた設計図を描き直す

複製環境の上で、deleはAIを使って資産の全体像を復元しました。プログラム同士の呼び出し関係とテーブルの読み書きを解析し、依存グラフ596本として組み直しています。

このうち3分の1は、実物のソースが手元にありませんでした。

区分	本数	割合
実物のソースコードが提供されていた	397本	66.6%
名前は呼ばれているが、対応ソースが未提供	199本	33.4%

つまり、ご提供いただいた資産だけを見ていては、全体の3分の2しか見えません。多くの調査は、ここで「残りは分かりませんでした」と終わります。

deleはここにAIを使い、ソースが未提供の199本についても、呼び出している側のコードや実行手順の記述から、存在・役割・つながりを推定して図に描き戻しました。 つながりは389本の線として整理し、残っていた機能仕様書246点とも突き合わせています。

COBOLとVB6が積み重なった資産を読み解いて復元する作業は、熟練の技術者でも年単位かかります。AIを使うことで、これを大幅に短縮しました。

第4章: 1本ずつ5つの証拠で死活を推定する

全体像の上で、プログラム 397本 を1本ずつ、いまも使われているかどうかで採点しました。人の記憶や印象ではなく、証拠に基づく推定です。

この採点は、お預かりした資料(ソース・DBデータ・2026年4〜5月の実行ログなど)の範囲で判断した 2026年7月4日時点の推定 です。実際に動いているかどうかを確認したものではありません。判定は「推定現役 / 推定休眠 / 推定死亡」と書きます。

証拠	確かめること
① 実データの動き	読み書きする帳簿に、実際にデータが動いた形跡があるか
② つながり	他のプログラムと呼び合っているか、孤立しているか
③ 実行のきっかけ	日次/月次/随時の実行契機が運用に組み込まれているか
④ 仕事量	帳簿の読み書きをどれだけしているか
⑤ 仕様書	設計意図が文書として残っているか

合計点で 50点以上を推定現役、20〜49点を推定休眠、20点未満を推定死亡 の3つに分けました。採点した397本の内訳は次のとおりです。

判定	本数
推定現役	269本
推定休眠	82本
推定死亡	46本

推定休眠と推定死亡を合わせた 128本 が、使われている形跡を確認できなかったプログラムです。全社で 動いていないと見られるのは32.2% で、およそ3本に1本を減らせると推定されます。

第5章: 止められない領域は現役で、減らせる余地は偏っている

いちばん重要な発見は、減らせる余地が全社に均等にあるのではなく、特定の領域に偏っていることでした。

領域	採点本数	推定現役	推定休眠	推定死亡	推定非稼働率
領域A 料金・顧客(CIS)	154本	90	40	24	41.6%
領域B 送配電設備	98本	63	24	11	35.7%
領域C 需給・給電	53本	52	1	0	1.9%
領域D 電力取引・託送	52本	41	7	4	21.2%
共通基盤	40本	23	10	7	42.5%

この表から、経営判断に直接効く2つのことが分かります。

発見1: 止められない領域は、ほぼ全部が現役

需要と供給を合わせ続ける 領域C(需給・給電)で、動いていないと見られるのは1.9%だけでした。止められない領域は、常に手が入っていて現役のまま保たれています。ここは無理に手を入れる必要がありません。

発見2: 減らせる余地は、古い請求系と使われていない共通基盤に集まっている

一方、領域A(料金CIS)は41.6%、共通基盤は42.5% と、古いCOBOLの請求系と全社の基盤に動いていないプログラムが集まっています。自由化で料金メニューが増えるたびに変換処理を足し、使わなくなった後もそのまま残してきたためだと見られます。ここから安全に止め始めるのがいちばん効果的です。

ヒアリング中心の調査では、「たぶん使っていないと思います」までしか言えません。deleは次の順で進めました。

分身を作り(第2章)
AIで失われた設計図まで復元して全体像を描き(第3章)
1本ずつ証拠を集めて採点した(第4章)

そのため、止められない領域はほぼ全部が現役で、古い請求系と使われていない共通基盤に全体の約3分の1の削減余地があるという推定を、1本ずつの証拠つきで示せます。

これはお預かりした資料の範囲での推定で、実際に動いているかどうかを確認したものではありません。推定休眠や推定死亡としたものも、すぐには消しません。止める前に必ずログで最終確認します。推定で当たりを付ける手順と、止める前に確認する手順の両方があって初めて、安心して減らせます。

次のフェーズ: 推定の裏を取る

今回分かったのは、5領域にまたがる資産評価の全体像です(2026年7月4日時点の推定)。ここから先は、次の2つで確度を上げます。

推定休眠・推定死亡の裏付け。実行ログの観測を続け、現場に確認し、段階的に止めて影響を見ることで、削減候補の推定を確かなものにします
現役の領域の維持。領域C(需給・給電)のようにほぼ全部が現役の領域は、現状維持を基本にして、余計なリスクを取りません

あわせて、今回の調査で分かったことも次に反映します。

ご提供いただいた資産だけでは、全体の3分の2しか見えませんでした。残りの33.4%をAIで復元できたので、削減余地を推定できました
ソースが未提供だった199本については、正本と置き場所を照合する必要があります。どれが正本かを管理する仕組みが働いているかを確認します

詳しい手法と領域ごとの結果は資産評価レポートを、プログラム1本ずつの確認はプログラム一覧をご覧ください。 </content>