AIでレガシーシステムの仕様を読み解く：解析結果を設計の根拠に変える方法
仕様書が古い、処理の意味を知る担当者が少ない、ソースコードの量が多すぎる。こうした状況で、生成AIによるコード説明や仕様書作成は、調査の負担を軽くする手段として期待できます。
ただし、読みやすい説明ができても、それだけで新しいシステムを設計できるわけではありません。その間には、確認の段階が必要です。AIの活用を成果につなげるには、出力の量だけでなく、説明を裏付ける根拠と、まだ確認できていない範囲を管理する必要があります。
三つの問いを分けると、AIの役割が明確になる
レガシーシステムの調査では、少なくとも三つの問いを扱います。
問い | 主な確認材料 | AIを活用できる作業 |
コードには何が書かれているか | ソース、定義体、設定、依存先 | 処理の要約、条件の整理、関連資料の検索 |
本番では何が起きているか | ジョブ履歴、ログ、実データ、実行環境 | 記録の分類、仮説の作成、調査箇所の抽出 |
今後もその業務が必要か | 業務方針、利用状況、担当者への確認 | 論点の整理、選択肢や確認事項の草案 |
最初の問いに答えられても、残りが自動的に解決するわけではありません。実行時に選ばれるプログラム、外部の設定、月末だけの処理、担当者の手作業が結果を変える場合があります。また、コードに実装されている処理を将来も残すかどうかは、業務側が判断することです。
AIへの依頼も、この区別に合わせます。「仕様書を作る」だけでなく、「確認できる条件分岐を列挙する」「根拠のない業務上の推測は別欄へ出す」「未取得の依存先を記録する」と具体化すると、次の確認作業へつなげやすくなります。
もっともらしい説明に、根拠の所在を付ける
生成AIには、誤った内容を確信があるかのように提示する性質があり、NISTも生成AIのリスクとして整理しています。そのため運用では、説明が自然であることを正しさの証拠として扱わないようにします。
NIST：生成AI向けリスク管理プロファイル、2.2節(https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
解析結果には、少なくとも次の情報を持たせます。
項目 | 記録する内容 |
ルールID | 後から参照できる識別子 |
説明 | 入力条件、判断、処理結果 |
根拠 | ファイル名、版、該当箇所、関連定義 |
確認状態 | コードから確認、実行で確認、業務確認待ち、仮説 |
未確認事項 | 外部呼び出し、設定、データ条件など |
検証方法 | 再現用の入力、期待結果、確認担当者 |
参照先を行番号だけで記録すると、ソースが更新されたときにずれてしまいます。対象の版や取得日時をそろえ、可能であればコミットIDなどと一緒に保存します。AIが付けた参照先も、実在するか、その箇所が説明の裏付けになっているかを確認します。
仮の例として、変数名に「LIMIT」が含まれている処理を考えます。AIがそれを「与信限度額」と解釈しても、実際には画面に表示する最大件数かもしれません。変数名の印象だけで業務用語を当てはめず、代入元、比較対象、呼び出し側、実データをたどって意味を確認します。
静的解析と実行確認を組み合わせる
呼び出し関係やデータの参照箇所など、機械的に抽出できる情報には、対象言語に対応した解析ツールを使います。AIには、その結果を人が読みやすい形に整理したり、調査の仮説を立てたりする役割を任せます。
静的解析にも範囲と限界があります。たとえばCodeQLの公式資料は、ソースが手に入らないライブラリや、実行時に決まる呼び出し先などが、データフロー解析を難しくすると説明しています。解析結果を読むときは、何をモデル化できていて、何が対象外かを把握する必要があります。
ここでの例は、特定のツールがRPG、CL、Notesアプリを含むすべての環境を解析できることを示すものではありません。ツールが対応している言語、構文、生成コード、設定形式の範囲は、実際の資産で確認します。
実行確認では、代表的な入力を与え、どの条件分岐を通り、どのデータを変更したかを確かめます。ログに出ない処理もあるため、「ログに見当たらない」ことを「使われていない」と同じ意味に取らないよう注意します。月末や年次などの処理周期と、観測できた期間を合わせて記録します。
大量投入の前に、入力資料の範囲を整える
一つのプログラムだけを渡すと、共通部品や設定で決まる条件が抜けることがあります。逆に、大量の資料を整理せずに渡すと、AIが異なる版や環境の情報を混ぜて説明するおそれがあります。
対象の処理を起点に、必要な定義、呼び出し先、入出力、実行条件をそろえます。解析した資産の一覧と、まだ渡していない資産の一覧を残すと、説明が及ぶ範囲を把握できます。AIの回答に出てこなかったことは、その機能を廃止候補にする根拠にはなりません。
ソースや業務データを入力する前には、使用するAIサービスの利用条件、データの保存・学習利用の扱い、アクセス権を確認します。認証情報を除き、個人情報や顧客データは必要性に応じて加工します。解析に必要な関連性まで失わないよう、どの部分を置換したかも管理します。
これらの確認は、AI利用を特別扱いするためのものではありません。設計資料として使う入力の品質と取り扱いを確定するための作業です。
効果は「確認済みの成果」が増えたかで測る
生成された文書のページ数や、説明したプログラム数だけでは、移行調査がどれだけ進んだか分かりません。説明の修正に時間がかかったり、重要な例外処理が抜けていたりすれば、後続工程の負担が増えます。
まずは、正常系に加えて例外処理や外部連携を含む代表的な範囲で試します。人だけで調べた場合と比べる際も、資料の条件と完了基準をそろえます。確認済みルールの数、重要な見落とし、根拠を確認する時間、未解決事項、仕様変更後の更新のしやすさを見れば、導入効果を判断しやすくなります。
確認を終えたルールは、設計書だけでなく、受け入れ条件や回帰テストにも反映します。コードが変わったときに再確認する範囲が分かれば、今回の刷新後も使える知識になります。
株式会社Managetechは、AIを使った調査でも、根拠をたどれて、未確認の点を説明できることを重視します。AIによる説明、技術者による検証、業務担当者による判断を組み合わせ、その役割分担を先に決めておくことで、可視化した仕様をモダナイゼーションの推進に生かせます。
コメント