仕様書がないシステムもAIで解析できる？ブラックボックス化したシステムの再構築方法

システムのブラックボックス化とは、システムの中身や仕組みを理解している人がいなくなり、どのように動いているのかが誰にもわからない状態のことです。長年使い続けてきた基幹システムでは、仕様書が残っていない、作った担当者がすでに退職しているといった理由から、改修も刷新もできずに困っている企業が少なくありません。

こうした仕様書がないシステムでも、近年は生成AIを使ってソースコードを解析し、仕様書や設計書を作り直せるようになってきました。結論からいえば、AIでシステムの処理内容を解析することは可能です。ただし、その処理がなぜ必要なのかという業務上の理由までは、人が補う必要があります。本記事では、ブラックボックス化の原因とリスク、AIで解析できることとできないこと、解消の進め方、そしてシステムの再構築方法までを解説します。

 

 

 

 

１．システムのブラックボックス化とは？

AIでの解析を考える前に、まずはシステムのブラックボックス化とはどのような状態なのかを整理しておきましょう。仕様書がないシステムで実際に何が起きているのかもあわせて解説します。

 

ブラックボックス化の意味

ブラックボックス化とは、もともと「中身の見えない黒い箱」を意味する言葉です。システムの場合は、入力すれば結果は出てくるものの、その間でどのような処理が行われているのかを誰も説明できない状態を指します。

システムのブラックボックス化は、ある日突然起こるものではありません。長年の運用の中で、担当者の交代や改修の積み重ねによって、少しずつ進んでいくのが特徴です。

 

仕様書がないシステムで起きていること

仕様書がないシステムでは、システムの中身を知る手がかりが、ソースコードと、使っている人の記憶しか残っていません。その結果、次のようなことが起こりがちです。

• 画面の項目や帳票の数字が、どのような計算で出ているのか説明できない
• 一部を修正したときに、ほかのどの機能に影響が出るのかがわからない
• 使われていない機能や画面が残っていても、消してよいのか判断できない
• 仕様書があっても、実際のシステムの動きと内容が合っていない

「動いているから触らない」という判断が続くほど、ブラックボックス化はさらに深刻になっていきます。

 

 

２．システムがブラックボックス化する原因

システムのブラックボックス化には、いくつかの典型的な原因があります。自社のシステムに当てはまるものがないか、確認しながら読み進めてください。

 

仕様書や設計書が更新されていない

最も大きな原因は、仕様書や設計書が整備されていない、または更新されていないことです。開発した当初は資料がそろっていても、改修のたびに資料を更新する作業は後回しにされがちです。その結果、資料と実際のシステムの内容がずれていき、やがて資料が役に立たなくなります。

 

担当者や開発会社が入れ替わり、知識が属人化している

システムの仕様が、特定の担当者の頭の中にしかない状態を「属人化」といいます。その担当者が異動や退職をすると、システムの知識も一緒に失われてしまいます。

開発会社の担当者の交代や、保守を依頼する開発会社の変更も同じです。引き継ぎが十分に行われないまま担当が替わると、システムの経緯を知る人がいなくなります。

 

場当たり的な改修が積み重なっている

業務の変化や現場の要望に合わせて、その場しのぎの改修を繰り返してきたシステムは、中身が複雑になっていきます。同じような処理があちこちに散らばっていたり、使われなくなった処理が残ったままになっていたりして、全体の構造を把握するのが難しくなります。

 

古い技術やプログラム言語で作られている

COBOLなどの古いプログラム言語や、現在はサポートが終了している技術で作られたシステムは、扱える技術者が年々少なくなっています。ソースコードが残っていても、読み解ける人がいなければ、実質的にはブラックボックスと変わりません。

 

 

３．ブラックボックス化したシステムを放置するリスク

ブラックボックス化したシステムは、普段は問題なく動いているため、対策が後回しにされがちです。しかし、放置を続けると次のようなリスクが大きくなっていきます。

 

障害が起きたときの復旧が遅れる

システムに障害が起きたとき、仕組みがわからなければ原因の特定に時間がかかります。どこを直せばよいのか、直したことでほかに影響が出ないかを判断できないため、復旧までの時間が長引き、その間は業務が止まってしまいます。

 

改修の費用と期間が膨らむ

法改正への対応や業務の変更に合わせてシステムを改修する場合も、まずは影響範囲の調査から始める必要があります。この調査に時間がかかるため、小さな改修でも費用と期間が膨らみます。改修を依頼された開発会社が、リスクの大きさを理由に引き受けをためらうこともあります。

 

システムの刷新や開発会社の変更ができなくなる

新しいシステムに作り替えようとしても、現在のシステムが何をしているのかがわからなければ、新しいシステムの要件を決められません。保守を依頼する開発会社を変えたくても、引き継ぐ情報がないため、特定の開発会社に依存し続けることになります。

 

担当者がいなくなると業務が止まる

システムを理解している人が一人だけという状態では、その人が異動や退職をした時点で、システムに手を入れられる人がいなくなります。システムの不具合だけでなく、業務そのものが止まるおそれもあります。

 

 

４．自社のシステムがブラックボックス化しているかを確認するポイント

自社のシステムがどの程度ブラックボックス化しているかを確かめるために、次の項目をチェックしてみましょう。当てはまる項目が多いほど、ブラックボックス化が進んでいる可能性があります。

• 仕様書や設計書がない、または最後に更新されたのがいつかわからない
• システムについて質問できる人が、社内に一人しかいない（またはいない）
• システムを開発した担当者や開発会社が、すでに関わっていない
• 小さな改修でも、影響範囲の調査に長い時間がかかる
• 「触ると壊れそうだから」という理由で、改修を見送ったことがある
• 使われていない機能や画面が残っているが、消してよいか判断できない
• システムの外で、Excelなどを使った手作業が増えている

特に、システムについて質問できる人が一人しかいない場合は、その人がいるうちに対策を始めることが重要です。

 

 

５．仕様書がないシステムもAIで解析できる？

仕様書がないシステムでも、ソースコードが残っていれば、AIを使って処理の内容を解析することは可能です。ここでは、AIでできることと、AIだけではわからないこと、解析を始める前に準備しておくものを解説します。

 

AIでできること

生成AIは、大量のソースコードを短時間で読み込み、その内容を人が読める言葉で説明することが得意です。仕様書がないシステムの解析では、主に次のような作業に活用できます。

• 処理内容の説明：プログラムがどのような処理をしているのかを、プログラムを読めない人にもわかる言葉でまとめる
• 仕様書・設計書の作成：解析した内容をもとに、機能の一覧や画面ごとの処理、計算のルールなどを、仕様書や設計書の形にまとめる
• 影響範囲の整理：プログラム同士の呼び出し関係や、どのデータがどの処理で使われているかを洗い出し、修正したときの影響範囲を把握しやすくする
• データ項目の一覧化：データベースの定義やプログラムから、使われているデータの項目と意味を一覧にする

COBOLのように扱える人が少ない言語で書かれたプログラムでも、AIを使えば処理の内容を現代的な言葉で説明させることができます。

 

従来のリバースエンジニアリングとの違い

ソースコードから仕様を読み解く作業は、リバースエンジニアリングと呼ばれ、以前から行われてきました。従来は、経験のある技術者がプログラムを一つずつ読み解くか、プログラムの構造を図にする解析ツールを使う方法が中心でした。AIを活用した場合との主な違いは次のとおりです。

 

 

AIだけではわからないこと

AIは、プログラムが「何をしているか」を整理することはできますが、「なぜその処理が必要なのか」までは、ソースコードだけから正しく読み取れないことがあります。たとえば、次のような情報です。

• 特定の取引先だけ計算方法が違うなど、業務上の取り決めにもとづく処理の理由
• プログラムには残っているが、実際の業務ではもう使われていない機能
• 月末だけ手作業でデータを修正しているなど、システムの外で行われている運用のルール
• 法令や社内規程に対応するために追加された処理の背景

AIがまとめた仕様書は、あくまでたたき台です。業務を知る担当者や、システムに詳しい技術者が内容を確認し、業務上の意味を補ってはじめて、使える仕様書になります。また、AIの説明が誤っている可能性もあるため、重要な処理は実際のプログラムやデータで確かめることが大切です。

 

解析を始める前に準備するもの

AIでの解析をスムーズに進めるために、次のものをできる限りそろえておきましょう。

• 本番で動いているものと同じ版のソースコード一式
• データベースの定義（テーブルや項目の一覧）
• 古くても残っている仕様書、操作マニュアル、改修の記録
• システムを使っている担当者や、過去に関わった技術者へのヒアリングの機会

特に重要なのは、ソースコードが本番で動いているものと同じ版かどうかです。手元のソースコードが古い版だと、解析結果が実際の動きと合わなくなります。

 

 

６．AIを活用したブラックボックス化の解消の進め方

AIを使えば解析の作業は効率化できますが、やみくもに始めても使える仕様書にはなりません。AIを活用してブラックボックス化を解消する一般的な進め方を、5つのステップで紹介します。

 

Step1：対象のシステムと優先順位を決める

まずは、どのシステムから解析するかを決めます。業務への影響が大きいシステムや、詳しい担当者がいなくなりそうなシステム、近いうちに改修や刷新を予定しているシステムを優先しましょう。

システム全体を一度に解析しようとせず、よく改修が発生する機能や、障害が起きたときの影響が大きい機能から着手するのが現実的です。

 

Step2：ソースコードと残っている資料を集める

対象が決まったら、ソースコードやデータベースの定義、古い資料など、解析の材料を集めます。ソースコードが社内にない場合は、開発を担当した開発会社に問い合わせましょう。

あわせて、システムを使っている担当者に、よく使う機能や、困っていること、システムの外で行っている作業をヒアリングしておくと、後の確認作業がスムーズになります。

 

Step3：AIで解析し、仕様書のたたき台を作る

集めた材料をもとに、AIでソースコードを解析し、処理内容の説明や機能の一覧、影響範囲の整理など、仕様書のたたき台を作成します。プログラムの量が多い場合は、機能のまとまりごとに分けて解析すると、内容を確認しやすくなります。

 

Step4：業務の担当者と技術者が確認し、足りない情報を補う

AIが作成したたたき台を、業務の担当者と技術者が一緒に確認します。業務の担当者は「この処理は実際の業務と合っているか」「なぜこの処理が必要なのか」を、技術者は「AIの説明がプログラムの動きと合っているか」を確かめます。

AIでは読み取れなかった業務上の理由や運用のルールを書き加え、使われていない機能があれば印を付けておきましょう。

 

Step5：仕様書を最新の状態に保つ仕組みをつくる

仕様書が完成しても、その後の改修で更新しなければ、再びブラックボックス化してしまいます。改修のたびに仕様書を更新するルールを決め、AIを使って変更内容を仕様書に反映する作業を効率化するなど、最新の状態を保てる仕組みを整えましょう。

 

 

７．ブラックボックス化したシステムの再構築方法

仕様を見える化できたら、次はシステムを今後どうするかを決めます。すぐに作り直すことだけが答えではありません。ここでは、判断の考え方と、再構築する場合の方法を解説します。

 

まずは見える化してから「延命・改修・再構築」を判断する

ブラックボックス化したシステムへの対応は、大きく分けて次の3つです。どれを選ぶかは、見える化で把握したシステムの状態と、今後の業務の見通しをもとに判断します。

 

 

見える化をせずにいきなり再構築を始めると、現在のシステムが担っている処理を新しいシステムに入れ忘れるおそれがあります。どの対応を選ぶ場合でも、まずは仕様を把握することが出発点です。

 

再構築する場合の主な手法

再構築にはいくつかの手法があります。現在の機能をそのまま保って別のプログラム言語に書き換える「リライト」、業務を見直して新しい設計で作り直す「リビルド」、パッケージやSaaSなどの既製品に置き換える「リプレイス」などです。システムの部分ごとに、適した手法を組み合わせるのが一般的です。

それぞれの手法の特徴や、AIを活用した刷新の進め方については、AIで古い基幹システムを刷新するAIモダナイゼーションの可能性と注意点で詳しく解説しています。

 

再構築では「今の仕様」ではなく「今の業務に必要なこと」を基準にする

再構築では、現在のシステムの仕様をそのまま新しいシステムに引き継ぎたくなります。しかし、ブラックボックス化したシステムには、すでに使われていない機能や、過去の事情で残った不要な処理が含まれていることが少なくありません。

解析で作成した仕様書は、「今のシステムが何をしているか」を知るための資料です。新しいシステムの要件は、「今の業務に何が必要か」を基準に、現場の担当者と一緒に見直しながら決めましょう。不要な機能を引き継がなければ、新しいシステムをシンプルにでき、開発の費用も抑えやすくなります。

 

再びブラックボックス化させないために

仕様書を整備したり、システムを再構築したりしても、運用の仕方が変わらなければ、数年後には再びブラックボックス化してしまいます。再発を防ぐために、次の3つを習慣にしましょう。

• 改修のたびに仕様書を更新する：改修の作業の中に、仕様書の更新を必ず含めます。AIを使えば、変更したソースコードから仕様書の更新案を作る作業も効率化できます。
• システムを複数人で理解する：一人の担当者に任せきりにせず、少なくとも二人以上がシステムの仕組みを説明できる状態を保ちます。
• 開発会社とのやり取りを記録に残す：改修の依頼内容や、開発会社からの説明を記録し、社内で共有します。開発会社を変更するときの引き継ぎ資料にもなります。

特に、AIを使って開発したシステムは、開発が速い分、仕様書の整備が後回しになりやすく、新たなブラックボックスを生みやすい点に注意が必要です。AIで作ったシステムの保守体制の考え方については、AIで作ったシステムを誰が保守するかを解説した記事で紹介しています。

 

 

８．仕様書がないシステムの解析に関するよくある質問

最後に、仕様書がないシステムの解析や再構築について、よく寄せられる質問にお答えします。

 

ソースコードが手元にない場合はどうすればよいですか？

まずは、システムを開発した開発会社に問い合わせましょう。開発時の契約によっては、ソースコードを受け取る権利が定められていることがあります。契約書を確認し、ソースコードの扱いがどう決められているかを把握しておくことが大切です。ソースコードが入手できない場合は、画面の操作や帳票、データベースの内容から仕様を推測し、新しいシステムの要件を整理する方法もあります。

 

ソースコードを外部のAIサービスに読み込ませても大丈夫ですか？

ソースコードには、業務のノウハウや、場合によってはパスワードなどの情報が含まれていることがあります。外部のAIサービスを使う場合は、入力したデータがAIの学習に使われない設定になっているか、データがどのように保管されるかを、利用規約や契約内容で確認しましょう。社内の情報管理のルールに沿って、利用してよいサービスを決めておくことも大切です。

 

解析や再構築には、どのくらいの費用がかかりますか？

システムの規模や、残っている資料の量、再構築の手法によって大きく異なるため、一概にはいえません。AIを活用すれば、解析や仕様書の作成にかかる作業を減らしやすくなりますが、業務の担当者による確認や、新しいシステムの要件を決める作業は残ります。システムの再構築にかかる費用の考え方や、AIを活用して費用を抑える方法については、システム刷新の費用とAI活用で開発費用を抑える方法で解説しています。

 

 

９．まとめ：AIで仕様を見える化し、業務に合ったシステムへ再構築する

システムのブラックボックス化は、仕様書の更新不足や担当者の交代、場当たり的な改修の積み重ねによって、少しずつ進んでいきます。放置すると、障害の復旧の遅れや改修の費用の増大を招き、システムの刷新さえ難しくなります。

仕様書がないシステムでも、ソースコードが残っていれば、AIを使って処理の内容を解析し、仕様書のたたき台を作ることができます。ただし、処理が必要な業務上の理由や、システムの外で行われている運用のルールは、AIだけではわかりません。業務の担当者と技術者が確認して補うことで、はじめて使える仕様書になります。見える化ができたら、延命・改修・再構築のどれを選ぶかを判断し、再構築する場合は今の業務に必要なことを基準に進めましょう。

ブラックボックス化したシステムの解析や再構築を検討している場合は、業務分析から基幹システムの構築、運用・改善まで伴走するシステム開発サービスもご検討ください。実際にシステムを導入した企業の取り組みは、A.N.Sの導入事例で紹介しています。