ブラックボックス化したシステムの見える化｜AI構造解析という選択肢

「誰も中身を把握していないシステムが、毎日業務を動かしている」——そうした状況は、多くの企業で珍しくない。担当者の退職・異動で知見が失われ、仕様書は存在せず、触ることすらはばかられる"聖域"と化したシステム。これがシステムのブラックボックス化だ。

本記事では、ブラックボックス化が生む具体的なリスクを整理したうえで、AIを活用した構造解析・見える化の実践的な手法を解説する。

なぜシステムはブラックボックス化するのか

ブラックボックス化とは、「インプットとアウトプットは分かるが、中でどう処理されているかが誰も把握していない状態」を指す。業務の文脈でいえば、システムが正常に動いているうちはとくに問題が表面化しないため、放置されやすい。

主な原因は3つある。

属人化と担当者の退職

システムを一人の担当者が長年にわたって管理してきた場合、その人物の頭の中だけに仕様が存在する。ROUTE06が行った調査（2024年）によると、事業会社の約9割がレガシーシステムを保有しており、約8割が業務継承で支障が生じた経験があると回答している（出典：株式会社ROUTE06プレスリリース）。さらに設計書がすべて最新状態に更新されているのは4割未満という実態も明らかになっている。

担当者が退職した瞬間、そのシステムは完全なブラックボックスになる。

ドキュメントの未整備・陳腐化

開発当時は仕様書があったとしても、その後の改修・追加開発のたびにドキュメントが更新されるとは限らない。実態として、多くの企業では「コードが正」の状態が続き、文書との乖離が積み重なっていく。10年・20年と運用が続いたシステムでは、どこに何が書いてあるかも分からない状態になりがちだ。

複雑化と密結合

長年の改修によってシステムは肥大化し、機能同士が複雑に絡み合う。一部を変更すると予期せぬ箇所に影響が出るため、エンジニアは手を触れることを恐れる。こうして「動いているから触らない」という文化が定着し、ブラックボックスはさらに深くなる。

放置すると何が起きるか｜4つのリスク

ブラックボックス化したシステムを放置することは、単なる技術的な問題にとどまらない。経営上のリスクに直結する。

リスク1：障害対応が長期化する

原因を特定する手段がないため、システム障害が発生したときの影響範囲の把握と復旧に時間がかかる。「どこを直せばよいか分からない」という状態は、事業継続リスクに直結する。

リスク2：DXの起点が作れない

クラウド移行・API連携・データ活用——いずれも既存システムの構造把握が前提となる。ブラックボックスのまま新しい仕組みを導入しようとすれば、どこと連携すればいいか、どのデータがどこにあるかが分からず、プロジェクトが止まる。

リスク3：セキュリティリスクが潜在化する

古いシステムは、既知の脆弱性を抱えたまま動き続けていることがある。構造が把握されていなければ、脆弱性の有無すら確認できない。情報漏洩やランサムウェア被害のリスクが無自覚に積み上がっていく。

リスク4：12兆円の崖が示す経済損失

経済産業省が2018年に公表した「DXレポート」は、レガシーシステムの放置によって2025年以降に最大年間12兆円の経済損失が生じると試算した（出典：経済産業省「DXレポート」）。2025年を過ぎた現在も、この問題の本質は変わっていない。IT人材の不足・高齢化が進む中で、ブラックボックスを抱えたまま経営を続けることのコストは年々高くなっている。

システムの見える化とは何をすることか

「見える化」とは、ブラックボックスの内部構造を明文化し、関係者が共通認識を持てる状態にすることだ。具体的には以下の情報を整理・文書化することを指す。

従来、この作業は熟練エンジニアがソースコードを読み解き、ひとつひとつ手作業で整理するしかなかった。数百万行のコードを読むだけで数ヶ月——あるいはそれ以上——かかることも珍しくなかった。

AI構造解析という選択肢

近年、この状況を変えつつあるのがAIを活用した自動解析だ。LLM（大規模言語モデル）の進化により、ソースコードを機械的に解析して構造を抽出し、設計書・依存関係図・業務フローを自動生成する手法が実用段階に入っている。

静的解析＋AIによる構造把握

静的解析ツールはコードを実行せずに読み解き、関数・クラス・モジュール間の呼び出し関係をマッピングする。これにAIを組み合わせることで、ただのコード依存関係グラフにとどまらず、「この関数が何のために存在するか」「この処理は業務のどのステップに対応するか」という意味的な解釈まで可能になる。

野村総合研究所（NRI）は2025年3月に、AIを活用してレガシーシステムの全体構造を把握し、変更影響を分析する「現行可視化・影響分析サービス」を提供開始した（出典：NRIニュースリリース）。こうした動きは、大手SIerだけでなく中堅・専門ベンダーにも広がっている。

リバースエンジニアリングの自動化

リバースエンジニアリングとは、既存のソースコードや動作から仕様を逆算して文書化するプロセスだ。かつては人手に頼るしかなかったが、生成AIの活用により大幅に効率化されている。

SHIFTは、ソースコードを基に46種類のドキュメントを自動生成するサービスを提供しており、COBOL・Java・Python・Goなど18言語に対応している（出典：日本経済新聞）。クラス図・シーケンス図・データフロー図なども自動で出力されるため、手作業での解析に比べて圧倒的に短い期間で構造把握が可能になる。

マルチエージェントによる並列解析

さらに進んだアプローチとして、複数のAIエージェントが並列でシステムの異なる側面を解析し、統合的なドキュメントを生成するマルチエージェント方式がある。たとえば、「データベース構造を解析するエージェント」「APIの呼び出し関係を解析するエージェント」「業務フローとのマッピングを行うエージェント」が同時に動き、最終的に一つの整合したシステム仕様書として出力される。

人間一人のエンジニアが順番に確認していく従来手法と比べると、解析にかかる期間は大幅に短縮される。

📋 SysDockで、ブラックボックスを解析する

仕様書がない・担当者がいない——そんな状況のシステム解析に対応するのが SysDock だ。AIマルチエージェントがソースコードと既存ドキュメントを自動解析し、システム全体の構造図・依存関係・業務フローマッピングを生成する。

「どこから手をつければ良いか分からない」という状態から、具体的な見える化まで伴走支援する。

👉 SysDockの詳細を見る（AIマルチエージェントによる自動解析、¥15万〜）

見える化を進める実践ステップ

AI解析を導入するにしても、まずは段階を踏んで進めることが重要だ。以下のステップを参考にしてほしい。

Step 1：対象システムの棚卸し

社内に存在するシステムをリストアップし、それぞれの「ブラックボックス度」を評価する。担当者の有無・設計書の有無・最終改修日・使用言語などを整理するだけでも、優先すべき対象が見えてくる。

Step 2：解析手法の選定

対象システムの規模・言語・緊急度に応じて、以下のどの手法を組み合わせるかを決める。

• コード静的解析：依存関係・呼び出し関係の自動マッピング
• AIリバースエンジニアリング：仕様書の自動生成
• ヒアリング：業務担当者へのインタビューでコードに現れない知識を補完
• 動的解析：実際に動かしながらデータフローを追跡

Step 3：成果物の定義と検証

何を最終的な「見える化」の成果物とするかを事前に定義する。システム構成図・業務フロー図・データディクショナリーなど、その後の活用目的（刷新計画・障害対応・引き継ぎ資料）に合わせて優先度を決める。

AI生成の成果物は、業務知識を持つ人間が確認・修正する工程を必ず組み込む。AIは構造を抽出するが、業務の文脈は人間が補完するという役割分担が品質を担保する。

Step 4：継続的な更新の仕組みづくり

一度見える化しても、その後の改修でドキュメントが陳腐化すれば意味がない。システム変更時に自動でドキュメントを更新する仕組みや、定期的な解析サイクルを設計段階から組み込むことが、長期的な見える化の維持につながる。

AI解析を選ぶ際に確認すべきポイント

AI構造解析サービスやツールを選定する際は、以下の観点で評価するとよい。

対応言語の範囲 COBOLなど旧来のレガシー言語に対応しているかどうかは、製造業・金融・公共系のシステムでは特に重要だ。対応言語が限定的なツールでは、主要機能が解析できないケースがある。

出力されるドキュメントの種類 構成図・シーケンス図・クラス図・データフロー図など、後工程で必要になる形式が出力されるかを確認する。エンジニア向けの技術図面だけでなく、業務担当者が読める業務フロー表現があると活用範囲が広がる。

既存環境への非侵襲性 解析のためにシステム環境に手を加える必要があるかどうかも確認が必要だ。ソースコードの読み取りだけで完結するか、エージェントを本番環境に接続する必要があるかによってリスクが変わる。

伴走支援の有無 AI解析の結果を受け取るだけでなく、それをどう解釈して次の打ち手につなげるかという部分の支援があるかどうかも重要だ。ツールだけ渡されても、活用できなければ意味がない。

まとめ

ブラックボックス化したシステムは、障害対応の遅延・DXの停滞・セキュリティリスクという形で、静かに経営コストを押し上げる。問題が表面化するのは往々にして最悪のタイミング——キーパーソンの退職直後、システム障害の発生直後——だ。

AIを活用した構造解析は、従来は数ヶ月・数百万円かかっていた見える化を、より短期間・低コストで実現する手段として実用段階に入っている。全面刷新ではなく「まず把握する」という一歩目として、AI解析の導入を検討することが現実的な選択肢になっている。

ブラックボックスを抱えたまま進めないDXより、まず構造を明らかにしてから描くロードマップの方が、確実に前に進める。

📋 SysDock——仕様書ゼロからでも解析できる

SysDockはAIマルチエージェントがソースコードを自動解析し、システム構成・依存関係・業務フローを可視化する。担当者不在・ドキュメントなしの状態から着手でき、現状把握から次の打ち手の立案まで支援する。

👉 SysDockの詳細・お問い合わせはこちら（¥15万〜）

姉妹サービスの関連記事

GenbaCompassの姉妹サービスでも、現場改善に役立つ記事を公開している。

• レガシーシステムのリスクと対策
• 属人化のリスクと損失額

現場改善に役立つ関連アプリ

GenbaCompassでは、SysDock以外にも現場のDXを支援するアプリを提供している。併せてチェックしてみてほしい。

参考文献

• 株式会社ROUTE06「事業会社の約9割がレガシーシステムを保有、約8割が業務継承で支障が出た経験あり」プレスリリース
• 経済産業省「DXレポート〜ITシステム『2025年の崖』の克服とDXの本格的な展開〜」（2018年）
• 野村総合研究所「現行可視化・影響分析サービス」ニュースリリース（2025年3月）
• 日本経済新聞「SHIFT、AIで旧来システムの仕様を可視化 ドキュメント自動生成」
• ワークフロー総研「ブラックボックス化とは？ビジネスにおける意味や解消方法」
• AI Front Trend「レガシーシステム分析が変わる！AI活用でSIerの業務効率化する手法とは」