AIによるソースコード解析・設計書の自動生成｜現行解析の進め方

ソースコード解析とは、プログラムのソースコードを読み解き、構造・処理の流れ・依存関係などを明らかにすることです。企業システムの文脈では、設計書が失われた・古くなった既存システムの仕様を、コードという“事実”から復元する目的で行われます。

従来も、コードを実行せずに構造やメトリクスを解析する静的解析ツールや、構造を図示するツールは存在しました。しかし従来型のソースコード解析ツールは、「どこに何があるか」は示せても、「この処理が何をしているのか」という意味までは教えてくれません。結局、出力された図や一覧を人が読み解く必要があり、大規模システムでは挫折しがちでした。

AIの登場で変わったのはここです。AIはコードを構造として解析するだけでなく、変数名や処理の流れから、処理の意味やプログラム上の実装意図を推論し、自然言語で説明します。「この機能はどのデータを更新し、どこから呼ばれているか」「この分岐はどのようなケースを想定した例外処理か」と日本語で問い、コードを根拠にした回答を得られます。人がコードを読み解く作業の多くを、AIが肩代わりできるようになりました。

両者の違いを整理すると、次のようになります。 

従来ツールが「読むための材料」を出すのに対し、AIは「読み解いた結果」まで出せます。この差が、レガシーシステムの解析を現実的なものにしました。 

企業の既存システムを対象にしたとき、AI解析で実務的にできることは大きく4つあります。

実務では、次のステップで進めるとスムーズです。

1. 対象と目的を決める：どのシステムを対象に・何のために解析するのか（影響分析か、設計書復元か、刷新準備か）を定める。目的によって、解析の深さと成果物が変わります。
2. 解析対象の素材を集める：ソースコード一式、残っている設計書、データ定義などを集約する。古い設計書も「当時の意図」を知る手がかりとして有用です。
3. AIで解析し、構造を可視化する：構造・依存関係を整理し、全体像を把握する。
4. 設計書・要約ドキュメントを生成する：目的に応じて、設計書の最新化・新規生成、要約ドキュメントの作成を行う。
5. 有識者レビューで検証する：生成された設計書を、業務・システムを知る担当者がレビューし、業務文脈を補う。AIはコードに書かれたことは読み解けますが、「なぜその業務ルールになったか」という背景は人が補完する必要があります。

ポイントは、ステップ5を省略しないことです。AI解析は読み解きの多くを担いますが、最終的な正しさの担保と業務文脈の付与は人の役割です。AIが下書きを作り、人が検証する分業によって、成果物の精度を保ったまま、調査にかかる時間を短縮できます。

→こうした解析から設計書生成までの一連の流れは、「LaKeel Blu」が得意とする領域です

AIによる解析・設計書生成が、実務のどんな場面で効くのかを具体的に見てみます。

ソースコード解析を支援するツールには、従来型の静的解析ツールから最新のAIを活用したサービスまで幅広い選択肢があります。企業の既存システムを解析する目的においては、以下の観点で選定することで導入の失敗を防ぐことができます。

• 対象言語・環境・規模に対応できるか：COBOL、RPG、PL/SQLなどのレガシー言語や、AS/400（IBM i）・メインフレームといった実行環境、大規模なコードベースへの対応範囲はサービスごとに異なるため、自社の既存システムに合うかを個別に確認します。
• 必要な成果物を出力できるか：設計書・構造図・一覧など、自社が必要とする形式に対応しているかを確認します。既存の設計書テンプレートに合わせられると、その後の運用がスムーズになります。
• 質問応答・対話ができるか：解析結果を読むだけでなく、「この処理の実装意図は何か？」といった疑問をその場でツールに問い合わせられると、調査効率が大きく向上します。
• 継続利用できるか：一度きりの解析で終わらず、システム改修のたびに設計書を最新化し続けられる仕組みになっていると、設計書と実態が乖離することを防げます。
• セキュリティを確保できるか：ソースコードは企業にとって重要な資産です。処理場所や、外部に学習利用されないかを確認します。
  

無料で使えるリバースエンジニアリングツールも存在しますが 、企業のシステムを対象にする場合は、規模・レガシー言語への対応・厳格なセキュリティ要件を満たすため、業務利用を前提としたエンタープライズ向けサービスを選定するのが現実的です。

AIによるソースコード解析は極めて強力な手段ですが、決して万能ではありません。導入効果を高めるためには、以下の注意点を押さえておく必要があります。 

• 業務背景までは分からない：コード上に記述されていない「なぜこの仕様にしたのか」という経緯や業務上の理由は、AIには判断できません。システムの全体像を正確に把握するには、有識者へのヒアリングによる補完が不可欠です。
• 生成結果の検証は必須：AIの出力には、もっともらしい誤り（ハルシネーション）が混入するリスクがあります。システムの根幹に関わる重要な設計書であるほど、最終的な内容の正確さは「人の目」によるレビューで担保する必要があります。
• 解析して終わりにしない：生成した設計書を更新し続ける運用フローを構築しなければ、再びドキュメントとコードの実態が乖離し、ブラックボックス化が再発します。継続的な保守サイクルを見据えた仕組みづくりが重要です。
  
  

つまり、AI解析は「人を不要にする」ものではなく、「人がやるべき判断に集中できるようにする」ものです。この前提に立って導入設計を行うことで、AIの真の価値を引き出すことができます。

こうしたAIによるソースコード解析・設計書生成を、要件定義などの上流工程と一体で提供しているのが、ラキールの製品「LaKeel Blu」です。現行解析エージェント（AIエージェント）が、既存システムのソースコードや設計書を解析し、構造・依存関係・処理の流れを体系的に整理し、実装の意図を読み解く手がかりまで示します。

具体的には、ソースコードから設計書を実態に合わせて最新化し、既存の設計書がない場合は新規生成も可能です。レガシーシステムの要約ドキュメントを生成して新規参入者の理解を助け、システムへの質問にはソースコードに基づいて回答します。さらに、可視化した現行仕様を土台に、要件定義を担うプロジェクトリードエージェントが「何を・なぜ刷新するか」を検討できるため、解析だけで終わることなく、刷新の要件定義から基本設計まで一気通貫で進められる点が特徴です。

ドキュメント整備というと、「いつかまとまった時間を取って、人手で書き起こすもの」と捉えられてきました。しかし、その“いつか”は来ないまま設計書は古び、システムはブラックボックス化していきます。AIによるソースコード解析が変えるのは、この前提です。設計書は人が記憶を頼りに作るものではなく、コードという事実から生成し、改修のたびに最新化し続けるものです。そう捉え直すことで、設計書と実態のずれは構造的に解消へ向かいます。

まずは、自社で「設計書と実態が合っていない」「コードを読める人がいない」システムを一つ選び、AI解析で構造の可視化と設計書の生成を始めてみてください。影響分析や刷新検討の足掛かりとなり、調査のたびに詳しい人を探し回るという非効率も解消されます。