deleは何をしたのか — ブラックボックスを可視化するまでの物語

(お客様経営層向け・デモ説明資料)

30秒でわかる要点

1. 危機の正体は「誰も全体を把握できていない」こと。 発送電分離・自由化・度重なる制度改正のたびに増改築を重ねた基幹システムは、どのプログラムが今も生きているのか誰も言い切れないブラックボックスになっていました。
2. 本番に一切触れず、AIで全体像を復元しました。 dele 社内の「分身環境」で資産を棚卸しし、失われていた依存関係を 596本 の地図として描き直しました。人手なら年単位かかる調査です。
3. 「止められない領域は健全、削減余地は約1/3」と、証拠つきで示しました。 プログラム1本ずつを5つの証拠で採点した結果、全社の推定非稼働率は32.2%(2026年7月4日時点の推定)。止められない需給・給電は健全に生きており、削減余地はレガシー請求系と塩漬け基盤に集中していました。

以下、この物語を順にご説明します。

第1章: 危機 — 「誰も全体を把握できない」基幹システム

未来明るく電力の基幹システムは、電力事業のバリューチェーン全体を支えています。検針・料金・収納の料金顧客系(領域A)、送配電設備の管理(領域B)、需要と供給を一致させ続ける需給・給電(領域C)、卸電力取引と託送(領域D)、そして全社を貫く共通基盤——。

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

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

継ぎ足し自体は、そのときどきの正しい判断でした。しかし棚卸しの機会がないまま積み上がった結果——

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

「このプログラムを止めたら何が起きるか」を、誰も自信を持って答えられない。 さらに COBOL 技術者は高齢化・退職が進み、ミドルウェアの EOL(サポート切れ)が迫る。制度改正への対応スピードが、レガシーの重みで落ちていく——これが経営課題でした。

第2章: 分身 — 本番に触れず、リスクゼロで実験できる場

dele がまず行ったのは、本番システムに一切触れずに、そっくりの「分身」を dele 社内に再現することでした。

送配電網に例えるなら、「配線図が一部欠けた設備を、残っている図面と部品だけを手がかりに別の場所へ組み上げ、実際に電気を流せる状態まで仕上げた」ということです。

この分身の価値は明快です。

本番システムに触れず・止めず・業務リスクゼロのまま、「このプログラムを止めたらどうなるか」という実験を何度でも行える。

止められない電力の基幹システムだからこそ、本番での検証は許されません。分身があるからこそ、大胆な削減判断を安全に検討できるのです。

第3章: 復元 — AIが失われた設計図を描き直した

分身の上で、dele は AI を使って資産の全体地図を復元しました。プログラム同士の呼び出し関係・テーブルの読み書きを解析し、依存グラフ596本として再構成しています。

ここで象徴的なのは、**その3分の1は「実物が手元に無かった」**という事実です。

つまり、提供された資産だけを眺めていては、全体像の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本の内訳は——

推定休眠・推定死亡をあわせた 128本 が、稼働の証跡を確認できなかったプログラムです。全社の 推定非稼働率は32.2%——およそ3本に1本に削減余地があると推定されました。

第5章: 結論 — 止められない領域は健全、削減余地は偏在している

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

この表は、経営判断に直結する2つのことを語っています。

ヒアリング中心の調査なら、言えるのは「たぶん使っていないと思います」までです。dele は——

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

——からこそ、「止められない領域は健全。レガシー請求系と塩漬け基盤に、全体の約1/3の削減余地がある」という推定を、1本ずつの証拠つきで示せます。

なお、これはお預かりした資料の範囲での推定であり、実稼働の確証ではありません。推定休眠・推定死亡としたものも即座に消すのではなく、停止前に必ずログで最終確認する安全弁を設けています。攻めの推定と、守りの手順の両方があって初めて、安心して身軽になれます。

次のフェーズに向けて — 推定を確証に近づける

今回見えたのは、5領域を横断した資産評価の全体像(2026年7月4日時点の推定)です。ここから先は、次の両輪で確度を高めます。

1. 推定休眠・推定死亡の裏付け深掘り — 実ログの継続観測・現場ヒアリング・段階的停止と影響観察によって、削減候補の推定を確証に近づけます
2. 健全領域の維持 — 領域C(需給・給電)のような健全な資産は、Keep(現状維持)を基本に無用なリスクを取らずに活かします

あわせて、今回の調査から得られた教訓も次に反映します。

• 提供資産だけでは全体像の3分の2しか見えないことが分かりました。残る33.4%をAIで復元できたからこそ、削減余地の推定が成立しています
• 実物が見つからなかった199本の存在は、「どれが正本か」を管理する仕組み(ソースコード管理の導入)の必要性を数字で裏付けています

より詳細な手法と領域別の結果は 資産評価レポート を、プログラム単位の確認は プログラム一覧 をご覧ください。 </content>