「ドキュメントが更新されていない」「当時の実装を知るエンジニアは既に退職している」。
大規模なレガシーシステムのマイグレーションやリファクタリングの現場では、このような状況がよく見られます。まるで、地図を持たずに地雷原を歩くような感覚に陥ることがありますよね？
多くのプロジェクトにおいて、失敗の原因は技術的な難易度そのものではなく、初期段階での「現状把握の甘さ」に起因する傾向があります。見えない依存関係、隠れた密結合などが移行フェーズの後半で火を噴き、スケジュールを大幅に遅延させるのです。
ここで多くの人が期待を寄せるのが、生成AI（Generative AI）です。「AIにコードを読ませれば、すぐに完璧な設計図ができるのではないか？」と考えるかもしれません。
結論から言えば、それは半分正解で、半分は危険な誤解です。
AIは魔法の杖ではありません。しかし、適切なワークフローの中に組み込み、まずはプロトタイプとして動かして検証することで、人間では数ヶ月かかる調査工数を劇的に圧縮し、見落としがちなリスクをあぶり出すことができます。
今回は、「AIを活用したアプリケーション相関図の自動生成と移行リスク検出」の具体的なワークフローを、エンジニアリングとプロジェクトマネジメントの両面から解説します。単に図を描くだけでなく、それをどう移行計画の精度向上につなげるか、ビジネスへの最短距離を描く視点で見ていきましょう。
なぜ「手動の現行調査」は移行プロジェクトを破綻させるのか
まず、なぜ「現行調査の自動化」が必要なのか、その背景を整理しておきましょう。これは単なる効率化の話ではなく、プロジェクトの成功、ひいてはビジネスの継続性に関わる重要な問題です。
属人化した知識とドキュメント乖離の罠
10年以上稼働しているシステムにおいて、設計書と実際のコードが完全に一致しているケースは稀でしょう。修正パッチ、緊急対応、機能追加の積み重ねにより、コードは複雑化しています。
手動調査の最大のリスクは、「認知バイアス」と「見落とし」です。
人間がコードを読むとき、どうしても「こう動くはずだ」という予測の下で読んでしまいます。変数名が getUserInfo ならユーザー情報を取得するだけだと思い込みますが、実際にはその中でログ出力を行い、さらに別のマイクロサービスへ通知を送っているかもしれません。こうした「副作用（Side Effects）」の見落としは、手動レビューでは防ぎきれないことがあります。
さらに、ベテランエンジニアの頭の中にしかない「暗黙知」も問題です。「このフラグが1の時は、こちらのテーブルを参照する」といったロジックがドキュメント化されていない場合、担当者が不在になった時点でその機能はブラックボックス化します。
AI導入による調査工数削減の試算
AIを導入するメリットは、圧倒的な処理速度と網羅性です。大規模な金融系システムの移行プロジェクトなどでは、約50万行のレガシーコード（COBOLとJavaの混合）の影響調査が必要になるケースがあります。
従来の手法であれば、エンジニアが数ヶ月かけて調査を行う計画が立てられます。しかし、AIパイプラインを活用した予備調査を導入することで、最初の相関図生成と主要なリスク箇所の特定を短期間で完了させることが可能です。
もちろん、その後の人間による詳細検証は必要ですが、トータルの調査工数は大幅に削減されます。これは、AIが「コードの構造解析」という作業を肩代わりし、人間が「ビジネスロジックの正当性確認」という高度な判断に集中できるためです。
AIツールの導入を提案する際は、単に「便利だから」ではなく、経営者視点で「リスク回避コスト」と「工数削減によるROI（投資対効果）」を示すことが重要です。
目指すべきゴール：動的な相関図による常時可視化
目指すのは、一度作って終わりの静的なドキュメントではありません。コードベースが変更されるたびに自動的に更新され、常に最新の状態を反映する「Living Documentation（生きたドキュメント）」です。
静的解析ツール（Static Analysis Tools）は構文上の依存関係は示してくれますが、「なぜその依存関係があるのか」という文脈までは教えてくれません。生成AIの強みは、コードのコメントや変数名、処理の流れから「意味的なつながり」を推論できる点にあります。
次章からは、この「意味的な相関図」を作成するための具体的なステップに入っていきましょう。準備はいいですか？
Step 1: 解析対象の定義とデータプリプロセス
AIプロジェクトにおいて「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」は絶対の原則です。精度の高い相関図を得るためには、AIに入力するデータの質を担保する必要があります。
ソースコード、DBスキーマ、ログの収集範囲
まず、解析対象となる資産を明確に定義します。ソースコードだけでは不十分です。
- ソースコード: 全量。ただし、ライブラリやフレームワークのコードは除外（または参照のみ）とし、自社開発部分に焦点を当てます。
- データベーススキーマ: DDL（Data Definition Language）文。テーブル間のリレーションや制約条件は、アプリケーションの構造を理解する上で不可欠です。
- 設定ファイル: プロパティファイル、YAML、XMLなど。これらには外部システムとの接続情報や環境依存のパラメータが含まれており、依存関係の特定に重要です。
- アクセスログ（可能であれば）: 実際にどの機能が頻繁に使われているかを知ることで、静的な解析に動的な重み付けを加えることができます。
これらを単にzipで固めてAIに投げるのではなく、構造化されたテキストデータとして準備します。
AIに読み込ませるためのコンテキスト整理術
大規模なコードベースは、LLM（大規模言語モデル）のコンテキストウィンドウ（入力可能な文字数制限）を超過することがあります。そのため、ファイルを適切な粒度で分割し、メタデータを付与する工夫が必要です。
各ファイルの冒頭に以下のようなメタデータヘッダーを自動挿入するスクリプトを使用することが効果的です。
File: src/main/java/com/example/OrderService.java
Module: OrderManagement
Type: Service Class
Dependencies: [UserRepository, InventoryService]
Summary: 注文処理のメインロジック。在庫確認と決済処理をオーケストレーションする。
このように、コード本体の前に「このファイルは何者か」という要約情報を（別の軽量なAIモデルで生成して）付与しておくことで、メインの解析AIが依存関係を理解する助けになります。これを「階層的サマライゼーション」と呼びます。
ノイズ除去とセキュリティ・マスキングのルール
企業利用において最も懸念されるのがセキュリティです。ソースコードには、APIキーやパスワード、個人情報が含まれている可能性があります。
AIにデータを渡す前に、以下のプリプロセスを必ず実施してください。
- 機密情報のマスキング: 正規表現や専用ツール（例: Microsoft Presidio）を用いて、パスワード文字列、IPアドレス、メールアドレスなどを
<MASKED_PASSWORD>のようなプレースホルダーに置換します。 - コメントアウトされたコードの削除: 過去の遺産であるコメントアウトされたコードは、AIを混乱させるノイズになります。これらは解析前に削除します。
- テストコードの分離: テストコードは依存関係が複雑になりがちですが、本番の構成とは異なります。テストコードは別の解析対象として分けるべきです。
安全性を担保した上で、クリーンなデータを準備すること。これが成功の第一歩です。
Step 2: AIによる依存関係の抽出と相関図生成フロー
データが準備できたら、AIを使って依存関係を抽出します。ソースコードという「事実」から、人間が見落としがちなつながりをあぶり出すには、適切な「プロンプトエンジニアリング」が不可欠です。まずはプロトタイプとして小さなモジュールで試し、仮説を即座に形にして検証するアプローチをおすすめします。
コンポーネント間通信の自動特定プロンプト
漫然と「このコードを解説して」と頼んでも、アーキテクチャ設計に使える精度の相関図は得られません。抽出したい情報の粒度と形式を具体的に指定する必要があります。
効果的なプロンプトの構成例を紹介します。
役割: あなたは経験豊富なソフトウェアアーキテクトです。
タスク: 提供されたソースコードから、コンポーネント間の依存関係を網羅的に抽出してください。
抽出対象:
- クラス/モジュール間の呼び出し関係（Import/Includeだけでなく実利用箇所）
- APIエンドポイントへのリクエスト（HTTPメソッドとパス）
- データベーステーブルへのアクセス（テーブル名とCRUD操作の種類）
- 外部システム/ミドルウェアへの通信
制約事項: 構文上の依存だけでなく、ビジネスロジック上の「データの流れ」を重視してください。
出力形式: 後述するMermaid記法、または構造化データ（JSON）
このように、役割とタスク、そして「何を見つけ出してほしいか」を明確に指示します。特に「データの流れ」を意識させることで、単なる import 文の解析を超えた、実質的な結合度（Coupling）を可視化できます。
APIコールとDBアクセスのマッピング手法
特に難易度が高いのが、Web API呼び出しやSQL実行部分の解析です。
これらはコード上で単なる「文字列」として扱われていることが多く、従来の静的解析ツールでは追跡が困難なポイントでした。
最新のLLMには、以下のような高度な推論を求めます。
- 動的SQLの文脈解析: 文字列結合やORM（Object-Relational Mapping）経由で生成されるSQL文の構造を推測し、どのテーブルのどのカラムにアクセスしているかを特定する。
- APIパスの再構築: 設定ファイル（
.envやconfig）からベースURLを読み取り、コード内の相対パスと結合して、通信先のサービスを特定する。
例えば、「String sql = "SELECT * FROM " + tableName;」のようなコードがあった場合、AIは前後の文脈から tableName 変数に代入されうる値を推論しようとします。これは、コードのセマンティクス（意味）を理解できるAIならではの強みです。
Graphviz/Mermaid記法への変換と可視化
抽出された依存関係は、エンジニア以外も理解できる視覚的な図にする必要があります。ここでは、テキストベースでダイアグラムを定義できる Mermaid.js や Graphviz (DOT言語) への変換が推奨されます。
AIに対して、抽出結果を直接 Mermaid 記法で出力するように指示します。
graph TD
A[OrderService] -->|Save Order| B[(Orders DB)]
A -->|Check Stock| C[InventoryService]
A -->|Charge Payment| D[PaymentGateway]
C -->|Update Stock| B
style A fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px
出力されたMermaidのコードは、対応するMarkdownエディタやドキュメントツール、AIチャットツールのプレビュー画面で直接レンダリングして確認できます。
特にドキュメントツールを活用する場合、単なる図の共有にとどまらない展開が可能です。例えばNotionの最新環境では、生成した相関図をページに埋め込むだけでなく、標準のプレゼンテーション機能（ベータ版）を利用して、そのままスライド形式の報告資料に変換できます。さらに、強化されたNotion AIなどのエージェント機能と連携させることで、抽出したアーキテクチャ図と外部ツール（Slackなど）での議論履歴を合成し、システム移行の企画書やミーティングノートを自動構成するといった高度な情報整理も実現します。
また、AIに「外部システムは青色、DBは黄色で塗りつぶして」「矢印にはデータの種類を記載して」といったスタイルの指示を加えることで、即座にステークホルダーとの会議で使用できるレベルの視覚資料を生成させることが可能です。
Step 3: 移行リスクの自動検出とヒートマップ化
図ができたら終わりではありません。生成された相関図の上に、「移行リスク」というレイヤーを重ね合わせます。ここからが、ビジネスへの最短距離を描くための真骨頂です。
「変更影響度が高い箇所」のスコアリング
システム移行において、リスクが高いコンポーネントとはどのようなものでしょうか？
- 依存度が高い（被参照数が多い）: 多くの場所から呼ばれている共通モジュール。ここを変更すると影響範囲が大きくなる。
- 複雑度が高い: 条件分岐やネストが深く、サイクロマティック複雑度が高いコード。
- 変更頻度が高い: Gitのログと照らし合わせ、頻繁に修正が入っている不安定な箇所。
これらの指標をAIに計算（あるいはツールから取得してAIに統合）させ、各コンポーネントに「リスクスコア」を付与します。
循環参照とスパゲッティコードの特定
AIは構造的なパターンの認識に優れています。「コンポーネントAがBを呼び、BがCを呼び、CがAを呼んでいる」といった循環参照（Circular Dependency）は、移行時の切り離しを困難にする典型的な問題です。
プロンプトで「循環参照や、責任範囲が曖昧な神クラス（God Class）を特定し、その理由を説明してください」と指示することで、リファクタリングが必要な箇所を指摘させることができます。
廃止予定ライブラリ・APIへの依存検知
レガシー移行では、古いライブラリやAPIの廃止対応も重要です。
AIに「現在の技術スタック（例: Java 17, Spring Boot 3）において、非推奨または廃止予定のライブラリを使用している箇所を警告してください」と指示します。
これにより、単なる構造図ではなく、「どこに問題が潜んでいるか」を示すヒートマップとしての相関図が完成します。リスクが高いと判断されたモジュールは、移行計画において特別な注意が必要な場所です。
Step 4: 人間による検証とAIハルシネーション対策
AIの力を活用してきましたが、AIは時として、もっともらしい嘘（ハルシネーション）をつきます。特にレガシーコードの解析においては、変数の意味を誤解釈したり、存在しない呼び出し関係を捏造したりするリスクが常に存在します。
AI生成結果のレビュー・チェックリスト
生成された相関図やリスクレポートは、必ず人間のエキスパートによるレビューを通す必要があります。これを Human-in-the-loop (HITL) と呼び、品質保証の要となるプロセスです。
レビュー時のチェックポイントは以下の通りです。
- 存在しない依存関係: AIが変数名の類似性から、実際には関係ないモジュールを結びつけていないか？
- 欠落している依存関係: リフレクション（Reflection）や動的ロード、設定ファイル経由の呼び出しなど、静的解析で見落としやすいパターンが抜けていないか？
- ビジネス文脈の誤解: 技術的な接続は正しくても、実際のビジネスプロセスとしてあり得ないデータの流れになっていないか？
現場エンジニアの暗黙知との突き合わせ
このフェーズは、経験豊富なエンジニアや有識者を巻き込む絶好の機会です。
「AIがこんな図を出してきたんですが、違和感ありませんか？」と尋ねることで、彼らの頭の中にある暗黙知を引き出しやすくなります。ゼロから「図を描いてください」と頼むよりも、具体的な（たとえ不完全でも）プロトタイプがある方が、人間の専門家は指摘を行いやすく、協力が得やすいものです。
誤検知の修正と学習ループの構築
人間が見つけた間違いは、単に修正して終わりではありません。次の解析フェーズにおける精度向上のための重要な資産となります。
ここで有効なのが、修正後の正解データをAIへの指示に含めるアプローチです。一般的に「Few-Shotプロンプティング」と呼ばれる手法ですが、現在のAI活用においては、大量の例や複雑な指示を与えるよりも、通常パターンと例外（境界ケース）を含む2〜3個の厳選された例を示すことが最も効果的です。
さらに、以下の点を意識することで解析精度を飛躍的に高めることができます。
- 高度な推論モード（適応型思考）の活用: 従来は正解データとともに「なぜその依存関係が存在するのか」という推論の過程を手動で例示するChain-of-Thought（CoT）プロンプトが主流でした。しかし現在では、ClaudeやGeminiなどの環境において、問題の複雑度に応じて推論の深さを自動で判断・配分する「適応型思考」機能が標準化されつつあります。計算リソースを多めに割り当てる推論モードを活用し、AIに自律的な仮説検証と問題分解を促すことで、論理的な構造の理解度が劇的に向上します。
- 構造化出力の徹底: JSON Modeなどを活用し、修正データのフォーマットを厳密に定義することで、AIの解釈ブレを防ぎます。出力形式を統一した例を提示することで、結果の安定性が増します。
この「生成 → 検証 → フィードバック」のアジャイルなサイクルを回すことで、AIはプロジェクト特有のコード規約やアーキテクチャパターンに適応し、パートナーとしての信頼性を高めていくのです。
Step 5: 移行計画（WBS）への統合とステークホルダー共有
最後に、可視化されたリスクと相関図を、実際のプロジェクト計画（WBS: Work Breakdown Structure）に落とし込みます。
リスクベースの移行順序策定
ヒートマップで「高リスク」と判定されたモジュールをどう扱うか。戦略は大きく2つです。
- 先行対処（Shift Left）: 最もリスクの高い部分をプロジェクト初期にPoC（概念実証）として切り出し、技術的な不確実性を先に潰す。
- 封じ込め（Strangler Fig）: リスクが高すぎて触れない部分は、周囲から徐々に新しいシステムに置き換え、最後に残った部分を対処する。
相関図があることで、依存関係の少ない機能から切り出す計画が立てやすくなります。
工数見積もりの精緻化とバッファ設定
「やってみないとわからない」という見積もりは、経営層には通用しません。
AIによる解析結果を基に、「このモジュールは依存先が15個あり、循環参照も含まれているため、通常の1.5倍の工数を見積もる」といった論理的な説明が可能になります。
定量的なデータに基づいた見積もりは、プロジェクトの予算確保やスケジュール交渉において非常に役立ちます。
経営層・現場への説明用レポート作成
技術的な詳細に疎いステークホルダーに対しては、Mermaidで作った詳細な図ではなく、AIに要約させた「経営層向けサマリー」を提示しましょう。
「現在のシステム構造は複雑化しており（図示）、特に決済機能周辺にリスクが集中しています。ここを重点的にテストすることで、移行後のリスクを低減します」
このように視覚的かつ論理的に説明することで、プロジェクトへの深い理解と協力を得ることができます。
まとめ
AIを活用したアプリケーション相関図の自動生成は、リスクを可視化し、根拠に基づいた意思決定を行うための極めて実践的な「アプローチ」です。
- データプリプロセスで解析の質を高め、
- プロンプトエンジニアリングで隠れた依存関係をあぶり出し、
- リスクヒートマップで注力すべきポイントを特定し、
- 人間の知見で精度を担保し、
- 移行計画へと落とし込む。
このワークフローを実践し、まずは動くプロトタイプから検証を重ねることで、移行プロジェクトの成功率は飛躍的に高まります。
AI技術は日々進化しています。最新のツールを駆使し、地図を持った安全で確実な旅になることを願っています。皆さんの現場でも、ぜひ今日から試してみてください。
コメント