資産評価レポート（未来明るく電力・領域A〜D）

プロジェクト名: 未来明るく電力 基幹システム 資産評価 PoC（古い資産の死活棚卸し） 対象: 領域A（料金・顧客情報 CIS）／領域B（送配電設備管理）／領域C（需給運用・給電）／領域D（電力取引・託送）／共通基盤 評価時点: 2026年7月4日（資産評価PoC）／証拠期間: 2026年4〜5月の実行ログ 作成: dele

目次

本レポートの読み方

本文に入る前に、この調査で何をしたのか、どの範囲を見たのか、判定の書き方が何を意味するのかを説明します。ここを読んでおくと、本文の数字や判断がどこから来たのかが分かります。

本調査（PoC）で行ったこと

本調査は、本格的なシステム刷新に着手する前に行った実証調査（PoC: Proof of Concept）です。deleが行ったのは次の3つです。

1. 未来明るく電力の基幹システムから、ソースコード一式・依存関係の手がかり(ソース/バッチ定義)・2026年4〜5月の実行ログ・機能仕様書をお預かりしました
2. それらを手がかりに、dele社内に本番へ触れない複製環境を用意し、提供されなかった情報はAIで依存グラフ上に復元・補完しました
3. その複製環境の上で、何が動いていて、何が休眠し、何が死んでいると推定されるかを、プログラム1本ずつ証拠に基づいて採点しました

本レポートの数字は、聞き取りの集計や机上の想定ではありません。実物のコードと実行ログを突き合わせて確かめた観測値と、それに基づく推定です。

「推定」と書いている理由

本レポートおよび本サイトのプログラムの死活の判定(現役・休眠・死亡)は、すべて 2026年7月4日時点の推定 です。そのため「推定現役 / 推定休眠 / 推定死亡」と書きます。この書き方には次の理由があります。

• 判定の根拠は、ご提供いただいた資料(ソースコード・依存の痕跡・2026年4〜5月の実行ログ・機能仕様書)の範囲内の証拠です。実際の本番環境で動いていることを確認したわけではありません
• 例えば「直近2ヶ月の実行ログに登場しない」ことは休眠の強い証拠です。ただし、年次処理・制度改正時のみ動く処理・災害時にしか起動しない縮退運用系が観測期間の外で動いた可能性は排除できません
• とりわけ電力事業には、年1回の料金改定バッチ・容量市場の年間約定処理・数年に一度の制度対応処理のように、動く回数は極端に少ないのに止めてはいけないプログラムがあります。これらを機械的に休眠・死亡とは判定しません

今後は、(1) 実行ログの継続観測と (2) 現場確認(段階的停止と影響観察) の2つで、この推定を確証に近づけていきます(第6章 次フェーズ計画を参照)。判定が更新された場合は、本サイトのプログラム別分析にも反映します。現場・ログで確認された事実は、推定判定を書き換えず「現場確認」として重ねて表示します。

最小限の用語

本文は、この8語さえ分かれば読み通せます。

数字の読み方

本レポートには「プログラム数」が、数え方の違いで複数出てきます。混同を避けるため、初めて出てくる箇所で必ず数え方を書いています。

• 依存グラフ 596本: 呼び出し関係に名前が登場する実体の総数。うちソース提供 397本(66.6%)、呼び出し痕跡から復元 199本(33.4%)
• 死活採点 397本: 実物のソースが提供され、5証拠で採点できた本数。復元199本は「存在・つながり・役割の推定」までにとどまるため、採点対象から除く

以降、単に「採点」と言うときは397本を指します。

経営層向けの要点

古いシステムをどうするかは、情報システム部門だけの技術課題ではありません。発送電分離・制度改正・災害への備えが同時に進むいま、事業を続けるためと、制度改正に早く対応するために、経営が判断すべき課題です。

まず、いまの状態を正確に示します。

いますぐ全系統が止まる兆候はありません。ただし、資産の状態には領域ごとの偏りがあり、放置すべきではない領域がはっきり見えています。

確定した数字

今回の資産評価PoCで観測・採点した値は次のとおりです(2026年7月4日時点の推定)。

採点した397本のうち、3本に1本弱で動いている証跡を確認できませんでした。これが「約1/3の削減余地」という言い方の裏付けです。ただし内訳は領域によって大きく異なります(第5章)。削減余地は請求系と共通基盤に偏っています。

古いシステムを放置したときの5つの経営リスク

古いシステムを放置したときのリスクは、「システムが古くて動かなくなる」というIT部門の問題にとどまりません。次の5つが、事業の継続と制度改正への対応を確実に難しくします。

問題は、保守に人や費用をかけること自体ではありません。**限られた人と予算が、本来注力すべき制度対応・災害への備え・DXではなく、一部の古いシステムの維持に固定されています。**これが経営課題の中身です。

どこが生きていて、どこに余地があるか

今回の採点を領域別に見ると、未来明るく電力の資産は2つにはっきり分かれます。

• 止められない領域は健全です: 需給運用・給電(領域C)の推定非稼働率は**1.9%**です。24時間365日の系統運用・給電指令を担う、一時も止められない領域です。ほぼ全プログラムが現役で、使われていないものがほとんどありません。ここは守って強くする対象で、減らす対象ではありません
• 請求系と基盤に余地が偏っています: 料金・顧客情報(領域A CIS)は41.6%、共通基盤は**42.5%**が非稼働です。制度改正のたびに得意分野別・料金メニュー別にプログラムを増やしてきた結果、使われなくなった資産が誰も止めないまま残っています

止められない領域(需給・給電)は、ほぼ全部が現役です。一方、古い請求系と、使われないまま残っている共通基盤に、全体の約1/3の削減余地があります。ここから安全に止めていきます。

本レポートの流れ

1. 直ちに全系統が壊れる兆候はありません
2. しかし、資産の状態には領域ごとの偏りがあります
3. 需給・給電(C)は健全です。請求系(A)と共通基盤に、使われていない資産が集まっています
4. その結果、維持コストが下がらず、人材が保守に固定され、制度対応が遅れています
5. 採点397本のうち128本(約1/3)で、動いている証跡を確認できませんでした
6. とりわけ推定死亡46本は根拠が明確で、安全に廃止へ着手できます
7. deleは、本番に触れない複製環境とAI解析で、これを短期間で可視化しました
8. 次フェーズでは他領域(発電・ERP等)へ広げ、段階的停止と影響観察で安全に整理していきます

本レポートの構成

1. 調査の対象範囲

本章の問い: 今回の資産評価は、未来明るく電力のどの範囲を、どの粒度で見たのか。

対象とした4領域＋共通基盤

未来明るく電力の基幹システムのうち、今回は業務の中核である次の4領域と全社共通基盤を対象にしました。発電設備制御・ERP(会計/人事/資材)・情報系(BI/データ基盤)は今回の対象外とし、次フェーズ(全社スクリーニング)で扱います。

各領域が扱う代表的なデータ(テーブル)は次のとおりです。

調査の粒度(依存グラフ596本)

今回つくった全体地図(依存グラフ)は、呼び出し関係に名前が登場する実体596本で構成されています。

• 採点(死活推定)は、実物のあるソース提供397本を対象にしました。復元199本は中身を確認できないため、「存在する / どことつながっている / どんな役割か」の推定までにとどめ、死活採点からは外しています
• 依存エッジ389本は、プログラム間の呼び出しと、プログラムとテーブルの間の読み書きを合わせた総数です

今回の対象外(次フェーズで扱う)

次の4つは今回の対象外です。全社スクリーニング(第2クール)で、同じ手法を広げて評価します。

なぜこの範囲から始めたか

領域A〜Dは、発送電分離後の未来明るく電力の送配電・小売・取引を支える中核です。同時に、メインフレーム時代(COBOL/JCL)からクライアントサーバー時代(VB6/.NET)までの古い資産が積み重なっている領域でもあります。ここを起点に選ぶと、(1)最も古い資産が多い請求系の実態を把握でき、(2)止められない給電系が本当に健全かを確認でき、(3)確立した手法をそのまま全社へ広げられます。いちばん見えていない中核を、証拠つきで見えるようにする。これが対象を選んだ理由です。

技術構成の実態(古い技術が積み重なっている)

今回対象とした資産の技術構成は、未来明るく電力が制度改正のたびに増改築を重ねてきた歴史をそのまま映しています。世代の異なる技術が積み重なり、それぞれに別のリスクがあります。

なお、言語別のコード規模や世代別の分布は、全社スクリーニング(第2クール)で全領域を横断集計してから数字にします。本PoCで確かめたかったのは量ではなく、どれが生きているか(死活)です。

2. 調査手法(本番に触れずに棚卸しする)

本章の問い: 稼働中の基幹システムに一切触れず・止めずに、どうやって「何が生きているか」を確かめたのか。

deleが行ったのは、数十年分積み上がって中身が分からなくなったシステムを、本番に触れずに解析し、中身を一覧にすることです。手順は次の3つです。

Step 1: 本番に触れない複製環境を用意する

提供いただいたソースと依存の手がかりだけを頼りに、本番と同じ構造のデータベースと実行環境を、dele社内に組み直しました。

• 本番の運用に影響が出ないよう、dele側に隔離した複製環境を用意しました。ここでなら、このプログラムを止めたらどうなるかを、業務に影響を出さずに何度でも試せます
• 電力の基幹系は24時間365日の給電・検針・託送を止められません。だからこそ本番に触れないことが絶対の条件で、複製環境がその土台になります

図面が一部欠けた数十年物の設備を、残っている図面と部品だけを手がかりに別の場所へ組み上げ、動く状態にしたということです。

Step 2: 欠けた設計図を、AIで依存グラフ上に復元する

提供資産だけでは、全体像は見えませんでした。

ここで疑問が出ます。対応するソースが提供されていないのに、なぜ「ある」と分かるのでしょうか。 理由は、プログラムが互いに名前で呼び合っているからです。提供されたソースやバッチ定義には「次に◯◯を実行せよ」「△△を呼び出せ」という命令が無数に書かれています。この呼び出される側の名前をAIですべて拾い集めた結果、重複を除いて596本のプログラム名が地図上に現れました。ところが、その名前に対応するソースが提供資産の中に見つかったのは397本(66.6%)だけでした。残る199本(33.4%)は、呼び出し命令に名前は載っているが、対応ソースは今回未提供という状態です。顧客環境に正本が存在しないという意味ではありません。

ここでAIを使いました。

• 提供された全ソースをAIに読み込ませ、「このプログラムは何を読み、何を計算し、どこに書き込むのか」を1本ずつ復元しました
• 対応ソースが未提供の199本は、呼び出し元の記述・バッチの実行順序・DBアクセスの痕跡を手がかりに、AIが役割とつながりを推定して依存グラフ上に補いました
• COBOLが参照する共通部品(コピーブック)やDBテーブルの構造も、コード中の定義文・SQL文から組み直しました

人手なら熟練の技術者が年単位を要する読解・復元を、短期間で終えました。COBOLとVB6を読める要員が減っている電力業界では、AIが読解を代わりに行うことが、この手法の要点です。

Step 3: 実行ログと突き合わせ、5つの証拠で採点する

再現した依存グラフと、2026年4〜5月の実行ログを突き合わせ、全プログラム・全テーブルのつながり(エッジ389本)を図にしました。担当者への聞き取りではなく、実物を全件調べた結果です。

そのうえで、ソース提供397本を1本ずつ5つの証拠で100点満点採点し、点数で推定現役/推定休眠/推定死亡の3つに分けました。判定は感覚ではなく、証拠に基づく点数です(採点ロジックの詳細は第3章)。

一般的な調査手法との違い

影響範囲を見通せなくする3種類の見えない依存

依存グラフを組み直す過程で、ソースコードを素直に読むだけでは追えない依存が3種類あることが分かりました。これらを可視化できたことが、死活推定の精度を支えています。

これらはソースにCALLが書かれていないため、静的解析だけでは途切れて見えます。deleはバッチ/JCL定義とDBアクセスの痕跡を突き合わせて、この途切れを補いました。**推定死亡の判定で「孤立している」と言うには、この3種類の見えない依存をすべて潰したうえで、なお誰ともつながっていないことを確認する必要があります。**孤立判定の確度は、この補完作業をどこまで徹底したかで決まります。

解析で見つかった例

料金計算(RY)系のあるCOBOLプログラム(数百行)をAIで解析したところ、処理の中身は、月次の料金明細ワークを全件ループしながら1件ずつ集計・更新するだけでした。**いまの技術なら1本のSQLに置き換えられます。**20年以上前の技術制約の中で数百行を使って書かれた処理が、いまでは数行で済みます。

このように簡単に置き換えられる資産が、古い請求系に多数あります。ここから2つのことが言えます。(a)モダナイズのコストは従来の見積もりより大幅に小さくなりうること、(b)COBOL要員に頼らずAIの助けで読解・変換できることです。**全面書き換えに数年かかるという前提そのものが、AI解析によって変わります。**これが次フェーズのモダナイズ方針の根拠の一つです。

提供資産のカバレッジ

依存グラフ596本のうち、対応ソースが提供されたのは397本(66.6%)です。残る199本(33.4%)は、呼び出しの記述に名前が登場する一方、対応ソースが今回は未提供でした。この199本は、次の手がかりから役割とつながりを推定して地図上に補いました。

• 呼び出し元の記述: どのプログラムから、どんな引数・文脈で呼ばれているか
• バッチ/JCLの実行順序: どのジョブ列の、どの位置で起動されるか
• DBアクセスの痕跡: 呼び出し前後で読み書きされるテーブルから、役割を推定

この「名前は残っているが実物がない」状態は、正本を一元管理する仕組みがないことの直接の証拠です。全社スクリーニングで対象を広げれば、同じように実物の所在が分からない資産がさらに出てくる可能性が高いと見ています(第6章 提言2)。

従来の全面書き換えとの違い

古いシステムの刷新というと全面書き換えを思い浮かべがちですが、deleのやり方は前提が違います。

要点は、残すと決めたものだけを改善するという順序です。まず動いていない資産を止め、次に残すと決めたものだけをAIの助けで速くモダナイズします。COBOL要員が減っている電力業界では、AIが読解を代わりに行うことが、モダナイズを現実的なコストと期間に収める条件になります。

本手法の限界と、その手当て

この手法には限界が3つあります。いずれも、知らないまま進めるのではなく、対処の方法をあらかじめ決めています。

3. 死活推定の採点方法(5つの証拠・100点満点)

本章の問い: 「生きている/休眠している/死んでいる」を、何を根拠に、どう判定したのか。

判定は感覚ではありません。プログラム1本ごとに5つの証拠を集めて100点満点で採点し、点数で3つに分けます。すべて2026年7月4日時点の推定で、稼働の確証ではありません。

5つの証拠と配点

証拠1(実データの動き)と証拠2(つながり)に配点を厚くしたのは、実際にデータが動いていて、かつ他とつながっていることが、稼働の最も強い証拠だからです。逆に、この2つがともに欠けるプログラムは、死亡の疑いが濃くなります。

各証拠の見方を、もう少し具体的に示します。

判定の閾値

採点の例

採点がどう働くかを、代表的な例で示します(プログラム名は本サイトの表記に合わせた架空名です)。

• RY0142(料金計算・従量本計算): 読み書きするRYOKIN・KENSHINに直近2ヶ月で実データが動き、収納(SU)・帳票(CH)から呼ばれ、月次JCLに登録されています。**推定現役(92点)**です
• KNB210(旧検針取込・特定料金メニュー向け): つながりは残っていますが、実行ログに一度も登場せず、読み書きの実データも動いていません。スマートメーター移行で役割を終えた疑いがあります。**推定休眠(34点)**です
• SB330S(設備台帳・旧様式変換): どのテーブルも読み書きせず、誰からも呼ばれず、実行契機もありません。同名の新版が別フォルダにある重複旧版です。**推定死亡(11点)**です

このように、同じサブシステムの中でも1本ずつ点数が違います。だからこそ「領域まるごと残す/止める」ではなく、「この1本は止められる、この1本は残す」という粒度で経営判断ができます。プログラム1本ごとの採点内訳はプログラム別分析で確認できます。

採点の内訳がどう積み上がるかを、上記3例の証拠別の点数で示します(架空の例です)。

注目してほしいのは、SB330S(死亡)が仕様書だけは7点取っている点です。**仕様書は残っているのに、実物は動いていません。**これは同じ処理の旧版によくある形で、文書だけを見ると生きているように見えます。5つの証拠を合算するので、文書があることに惑わされずに死活を判定できます。

4. 結果(全体分布と非稼働率)

本章の問い: 採点397本は、全体としてどういう状態だったか。

全体分布

• 推定非稼働率 = 32.2%(推定休眠82＋推定死亡46＝128本 / 397本)
• 言い換えると、採点した3本のうち2本は現役ですが、残り1本は稼働の証跡を確認できませんでした

非稼働は領域によって偏っている

重要なのは、この32.2%が全領域に均等に散らばっているわけではないという点です。

• 給電系(領域C)はほぼ全部が現役です(非稼働率1.9%)。止められない領域は、無駄なく生きています
• 請求系(領域A CIS)と共通基盤に非稼働が集中しています(それぞれ41.6%・42.5%)

削減余地は請求系と共通基盤に偏っています。**止める場所と守る場所が、データではっきり分かれました。**これが今回いちばん大きな発見です。領域別の詳細は第5章で述べます。

変更の影響が集中する主要なハブ

依存グラフ上で、多くのプログラムから読み書きされるハブを特定しました。ここは変更したときの影響範囲が広く、モダナイズのときも慎重に扱う必要があります。

ハブへの変更の影響は、プログラム別分析の依存関係で1本ずつ確認できます。

処理パターンの分類

採点した397本を処理の型で分けると、古い請求系によくある5つのパターンになります。パターンごとに削減・統合のやり方が違います。

推定死亡と推定休眠は、**パターンA(得意分野別に増えた取込・変換)とパターンD(旧様式帳票)**に集中しています。制度・料金メニュー・様式が変わるたびに新しいプログラムを作り、旧版を止めずに残してきたためです。データがそれを裏付けています。

見えていなかったものを数字にする

今回の可視化で初めて数字になったものを整理します。

**3本に1本がソース未提供で、3本に1本弱が稼働証跡なしです。**この2つを解消しないと、制度対応の影響範囲も、維持する対象も確定できません。ソース未提供199本が正本管理の問題なのか、今回の提供範囲の問題なのかは、正本の照合で確かめます。

4-1. 推定死亡・推定休眠の内訳と根拠パターン

推定死亡46本・推定休眠82本が、なぜそう判定されたのかを根拠のパターン別に整理します。判定は単一の理由ではなく、複数の証拠が同時に欠けていることで決まっています。

推定死亡(46本)の代表的な根拠パターン

推定死亡46本は、上のパターンに複数同時に当てはまるものが大半です(例: 孤立していて、かつ実行ログにも登場しない)。根拠が重なっているので、廃止の確度が高くなります。ただし前述のとおり、廃止は段階的停止と影響観察で進めます。

代表的な推定死亡の例を、根拠パターンとともに示します(プログラム名は本サイト表記に合わせた架空名です)。

いずれも、作られたあと役割を終えたのに、誰も止めていないものです。**廃止しても失われる価値はありません。維持コストと、依存グラフが複雑になることだけが残っています。**これが推定死亡に共通する形です。

推定休眠(82本)の代表的な根拠パターン

推定休眠は、止めていいか判断できないので全部維持する、という状態を生みます。**維持コストは払い続けているのに、価値を生んでいるかが分かりません。**ここに整理の余地があります。休眠判定の確度を上げるには、実行ログの観測を続けて期間を延ばすのがいちばん効きます。

推定死亡・推定休眠の廃止・整理の進め方

1. プログラムの利用状態を分類する(完了。本PoCで推定として実施)
2. 推定死亡46本を優先候補として整理する(完了。本PoC)
3. 推定死亡から段階的停止＋影響観察で廃止に着手する(次フェーズ)
4. 推定休眠82本は実行ログの継続観測・現場確認で確度を高めてから段階的に整理する(次フェーズ)

推定死亡・推定休眠それぞれの一覧は、プログラム別分析で判定カテゴリごとに絞り込めます。

5. 領域別の評価

本章の問い: どの領域に、どれだけの削減余地があるのか。守るべきはどこか。

領域別サマリー

採点397本を領域別に見ると、非稼働率は1.9%〜42.5%と20倍以上の開きがあります。削減余地は請求系(A)と共通基盤に偏っていて、給電系(C)は健全です。

以下、領域ごとに所見を述べます。

領域A 料金・顧客情報(CIS): 非稼働率41.6%

**削減余地がいちばん大きい領域です。**検針(KN)から料金計算(RY)、収納・消込(SU)、請求(帳票CH)までの一連を担う請求系の中核で、同時に古い資産がいちばん多い領域でもあります。

領域Aは削減余地が最大で、同時に制度改正への対応をいちばん遅くしている領域でもあります。ここを整理して新しくすると、料金改定への対応にかかる期間が短くなります。

サブシステム別に見ると、非稼働の偏りと処置の方針は次のように整理できます。

今後の方向: 得意分野別・料金メニュー別に増えた取込・計算処理を、定義で動く1つの基盤にまとめます。料金改定の作業を「プログラムの新規開発」から「定義ファイルの追加・変更」に変えると、制度対応にかかる期間を大きく短縮できます。ただし料金計算・収納の中核は止まったときの影響が大きいので、並行稼働と差分検証で慎重に進めます。

領域B 送配電設備管理: 非稼働率35.7%

設備台帳(SB)・工事管理(KJ)・保全計画(HZ)・図面/GIS(GS)・停電管理(TD)を担います。設備を長く使うのに合わせてシステムも長く動かしてきたため、旧様式変換の残置が多くなっています。

サブシステム別の傾向は次のとおりです。

今後の方向: 設備は長く使うので、台帳とGISは長く正確に保つことを最優先にします。旧様式変換の残りをRetireで取り除いて見通しを良くし、停電管理(TD)は災害対応のために監視と冗長化を強化します。

領域C 需給運用・給電: 非稼働率1.9%(健全)

需給計画(JK)・給電指令(KD)・系統運用(KT)・予備力管理(YB)を担う領域です。24時間365日、一時も止められません。

止められない領域がほぼ全部現役だという根拠が、この1.9%です。ここに削減の話を持ち込む必要はありません。

領域D 電力取引・託送: 非稼働率21.2%

卸電力取引JEPX(TR)・インバランス精算(IB)・託送業務(TS)・スイッチング(SW)・需要予測(YS)を担います。電力自由化・市場制度の整備に合わせて比較的新しく作った部分が多く、非稼働率は中程度です。

共通基盤 全社基盤: 非稼働率42.5%(整理の効果が全社に及ぶ)

マスタ管理(MS)・帳票基盤(CH)・連携基盤ESB(RN)・認証/権限(NB)・バッチ基盤(BT)を担います。全領域が依存する土台ですが、非稼働率はいちばん高い領域です。

サブシステム別の傾向は次のとおりです。

今後の方向: 共通基盤は全領域が依存する土台です。まず周辺の使われていないユーティリティから取り除き、ハブ本体は包んで守ります。マスタ管理のコード体系を統一して呼称と供給地点を名寄せすると、領域をまたいだデータの突き合わせが正確になり、経営情報を出すまでの時間も短くなります。

6. 経営提言と次フェーズ・ロードマップ

本章の問い: この評価結果を受けて、経営として何を、どの順番で実行するか。

処置方針の5分類(Disposition)

全プログラムを、次の5つの処置方針に振り分けて実行します。まとめて刷新するのではなく、1本ずつ最適な扱いを選ぶのが要点です。

処置方針は、止まったときの影響と変化の頻度の2つで大きく分けられます。

• 停止リスク高 × 変化頻度高 → Modernize最優先(料金CIS中核)
• 停止リスク高 × 変化頻度低 → Keep/Wrap(給電系・停電管理)
• 停止リスク低 × 変化頻度低 → Retire(推定死亡)
• 停止リスク低 × 変化頻度高 → Refactor→Modernize(共通ユーティリティ)

提言1: 推定死亡46本の廃止に着手する

最も確度が高く、最初に着手する施策です。

• 対象: 推定死亡46本(孤立・空・重複旧版・実行ログ無ヒットが重なるもの)
• 方式: 即削除ではなく 段階的停止＋影響観察。まず本番からの参照を切り、一定期間問題が出ないことを確認してから廃止を確定します。問題が出れば即座に戻します
• 効果: 管理対象が確実に減り、依存グラフの見通しが良くなります。止められる所から止める、最初の一歩です
• 優先順位: 共通基盤・料金CISの推定死亡から着手します(整理の効果が全社に及び、かつ止めたときのリスクが低いためです)

提言2: 構成管理(正本の一元化)を導入する

**復元199本(全体の1/3)は、実物のありかが分かりません。**これが制度改正への対応を遅らせている根本の課題です。

• 対象: 本番稼働バイナリと提供ソースの照合による正本の確定、バージョン管理(Git等)の導入、物理ディレクトリ退避による重複旧版のアーカイブ化
• 効果: 「本番で動いているのはどれか」に即答できる状態をつくります。制度改正のたびにソース探しから始める無駄がなくなります
• 位置づけ: 廃止・モダナイズの前提になる整備です。これがないと、残すと決めたものの改修すら安全に始められません

提言1の実行手順(Phase 0)

推定死亡の廃止は、リスクを抑えるため次の順で進めます。

1. 対象確定: 推定死亡46本のうち、共通基盤・料金CISの「孤立＋実行ログ無ヒット＋重複旧版」が重なるものを最初のまとまりとして選びます(止めたときのリスクが最も小さいためです)
2. 見えない依存の再確認: ファイル経由・共有テーブル・Shell/JCL経由の3種類の見えない依存を再点検し、本当に誰ともつながっていないことを確認します
3. 参照の切り離し: 本番からの起動・参照を停止します(削除ではなく無効化です)
4. 影響観察: 一定期間(月次処理を1〜2サイクル含む)、業務・後続処理に問題が出ないか観察します
5. 廃止確定 or 復帰: 問題がなければ廃止を確定してアーカイブ化します。問題が出れば即座に復帰させ、休眠へ再分類します

この段階的停止と影響観察は、止められない基幹システムでは必ず必要な手順です。判定を過信せず、いつでも戻せる状態を保ったまま止めます。

提言3: 全社スクリーニング(第2クール)を実行する

今回の手法(複製環境・依存グラフ・5証拠採点)は、そのまま他の領域にも使えます。

• 対象: 今回は対象外とした発電設備制御・ERP・情報系・次世代検針基盤の内部
• 進め方: まず全領域を広く簡易採点し、削減余地とリスクをヒートマップで可視化します。問題が出た領域を精密採点(A〜Dと同等)する2段階で進めます
• 効果: 領域A〜Dでつくった仕組みを再利用するので、2回目以降はより短期間・低コスト・高精度で進みます。全社の削減余地を経営が一覧できます

ヒートマップは領域ヒートマップ、全社の把握状況は全社システム資産マップで継続的に更新します。

次フェーズの進め方(安全に止めて、置き換える)

現行システムを一括で置き換えるのではなく、領域単位で切り出し、旧環境と新環境を並行稼働させながら出力の一致を検証する段階的な移行を基本にします。電力の基幹系は止められないため、この安全第一の方式が前提になります。

1. 領域(またはサブシステム)ごとに切り出す
2. 旧環境と新環境を並行稼働させる
3. 入出力結果を比較する(差分検証)
4. 差異を検証し、問題なければ段階的に切り替える(段階移行・安全な切替)
5. 問題が発生した場合は即座に旧環境へ戻す(ロールバック可能)

ロードマップ

処置方針別・領域別の実行計画はロードマップ、制度対応の観点はコンプライアンスで継続的に管理します。

意思決定のタイムライン

経営として、どこから止めるかを決めるための時間軸は次のとおりです。

評価指標(KPI)

削減・整理は、本数を減らすこと自体が目的ではありません。維持コスト、制度改正への対応力、災害への備えがどれだけ良くなったかを測ります。

主なリスクと対策

止める話と守る話を分ける

本レポートの提言は削減に力点がありますが、電力事業では削減と同じ重さで守ることも決める必要があります。2つを混ぜると、守るべき系統に削減の理屈を持ち込む事故が起きます。

とりわけ災害・広域停電のときに動く縮退運用系や停電管理(TD)は、平常時の実行ログに現れにくいものです。これらを死活採点だけで判断せず、災害時にしか動かないが欠かせないという電力特有の性質を織り込んで救済します。災害への備えは削減とは逆方向の投資ですが、削減で生まれた費用と人の余裕をここに回すのが本筋です。

体制

付録

A. 採点集計の詳細

領域別の採点内訳(再掲)です。すべて2026年7月4日時点の推定です。

B. 依存構造の主要指標

C. 判定ロジックの前提

判定は机上のリスト突合ではなく、次の前提のもとで行いました。

• 提供ソース・依存の手がかりをもとに、本番に触れない複製環境をdele側で再現
• 仕様書欠落等の欠損情報は、AIによるソースコード解析で依存グラフ上に補完(復元199本)
• 2026年4〜5月の実行ログと突き合わせ、依存グラフ(596本・389エッジ)を構築
• ソース提供397本を、5証拠100点満点で採点し3分類

関連ページ

本レポートの数字・判定は、次のページで1本単位まで掘り下げられます。

分類ごとの判定基準は次のとおりです。

D. 判定の確度と次フェーズでの確認事項

• 推定死亡は静的解析・実行ログ突合の上では確度が高いものの、プログラム間に人間の運用手順が挟まることで、依存グラフ上は孤立して見えるケースがありえます
• そのため、廃止は即時削除ではなく段階的停止＋影響観察の方式で行い、問題があれば即座に復帰できる状態を保ちます
• 推定休眠は実行ログとの突合を続け、次フェーズで確度を高めたうえで段階的に整理します
• 年次・制度改正時・災害時にしか動かない、頻度は低いが欠かせない処理は、実行契機(スケジューラ/JCL登録)の有無で救済し、機械的に休眠・死亡とは判定しません

E. 処置方針(Disposition)の判断基準・詳細

第6章の5分類を、判断基準と進め方の観点で詳しく示します。

F. 全社スクリーニング(第2クール)の進め方

領域A〜Dでつくった仕組み(複製環境・依存グラフ・5証拠採点)を、そのまま他の領域へ広げます。手順は2段階です。

2回目以降は仕組みが揃った状態から始められるので、初回より短期間・低コスト・高精度で進みます。

G. カバレッジ

判定の前提となる提供資産のカバレッジ(ソース提供66.6%／AI復元33.4%、実行ログの証拠期間、領域別非稼働率等)は、本サイトの全社システム資産マップおよびプログラム別分析を参照してください。プログラム1本ごとの採点内訳・依存関係・仕様書プレビューは、各プログラム詳細ページで確認できます。

結び

本件は、老朽化への対応だけの話ではありません。発送電分離・容量市場/需給調整市場・インバランス制度・スマートメーター・災害への備えが同時に進むいま、限られた人と予算を制度対応・事業継続・成長分野へ配分し直すための経営判断です。

止められない領域(需給・給電)は、ほぼ全部が現役でした。その状態を守りながら、古い請求系と、使われないまま残っている共通基盤にある約1/3の削減余地から、証拠に基づいて安全に止めていきます。これが本レポートの提言です。

本レポートは、未来明るく電力 基幹システム 資産評価PoCの成果として、dele が作成したものです。判定はすべて2026年7月4日時点・証拠期間(2026年4〜5月)の範囲内での推定であり、稼働の確証ではありません。実態・数値・認識に相違があれば、ご指摘ください。現場・ログで確認された事実は「現場確認」として本サイトに継続反映します。