【事例】レガシー改修で調査と下書きが速くなった現場の記録

長年運用されてきた「レガシーシステム」の改修は、IT現場において最も困難なミッションの一つです。ドキュメントは散逸し、当時の開発担当者は不在。稼働しているコードだけが「真実」であるものの、その中身はスパゲッティ化し、一部分を修正するだけでどこに影響が出るか予測できません。

こうした状況で、従来のような「手作業によるコードリーディング」と「人手によるExcelの仕様再整理」を行っていては、調査だけで数ヶ月を要し、開発コストは膨れ上がる一方です。しかし現在、LLM（大規模言語モデル）を活用することで、この「調査」と「下書き（新設計）」のプロセスを数倍から十数倍に高速化できる現場が増えています。

本記事では、レガシーシステム改修における調査と下書きを劇的に効率化した実務記録をベースに、具体的な手法とツール選定、そしてセキュリティ上の注意点を詳しく解説します。

1. レガシーシステム刷新の「壁」はどこにあるか

レガシー改修が遅延する最大の要因は、実装そのものではなく、その前段階の「理解」にあります。

1.1 属人化した仕様と「解読」に消える工数

多くの現場では、システムが「動いているから触らない」というブラックボックス状態に陥っています。独自のフレームワークや、すでにサポートが終了したライブラリに依存している場合、公式ドキュメントすらWeb上から消えていることも珍しくありません。この状態では、エンジニアがコード1行を理解するために、過去のログを漁り、関連するテーブル構造を推測するという「考古学」のような作業に大半の時間を費やすことになります。

1.2 調査フェーズの長期化がプロジェクトを停滞させる

調査に時間がかかると、ビジネスサイドからの「いつ終わるのか」というプレッシャーが強まり、不完全な理解のまま実装へ突き進むことになります。これが結果として、リリース後のバグ多発や、さらなる技術的負債を生む悪循環に繋がります。こうした「負債の連鎖」を断ち切るには、SaaSコストとオンプレ負債を断つアプローチと同様に、構造的な解体と再構築のスピードアップが不可欠です。

2. 調査と下書きを爆速化するモダンツール群の比較

レガシーコードの解析には、最新のAI支援ツールが極めて有効です。ただし、ツールによって得意分野が異なります。

2.1 GitHub Copilot / Cursor によるコード解析

エディタ一体型のツールは、現在開いているファイルの前後関係を把握するのに長けています。特に「Cursor」はリポジトリ全体をインデックス化できるため、「この関数を呼び出している箇所をすべてリストアップし、実行順序を整理して」といった指示に高い精度で応えます。

2.2 Gemini 2.5 Pro による巨大リポジトリの一括読み込み

Googleが提供する Gemini 2.5 Pro は、最大200万トークン（一般的な書籍数千冊分）という広大なコンテキストウィンドウを持っています。これにより、数万行に及ぶソースコード全体を一気に読み込ませ、システム全体のアーキテクチャ図（Mermaid形式など）を作成させたり、モジュール間の依存関係を網羅的に抽出させたりすることが可能です。これは従来、人間が数週間かけて行っていた作業です。

実名ツール比較表：エンジニア向けAI支援ツール

各ツールの特徴を以下の表にまとめました。料金や仕様は執筆時点の公式情報に基づきますが、詳細は各公式サイトをご確認ください。

3. 【実践】レガシーコードをAIで「仕様化」する4ステップ

実際に現場で行っている、AIを活用した調査・下書きの具体的なフローを紹介します。

3.1 STEP 1：環境構築とセキュリティ

まず、「入力したコードがAIの学習データに利用されない設定」になっているかを必ず確認してください。GitHub Copilot BusinessやChatGPT Enterprise、Google Cloud経由のGemini APIなどは、標準でオプトアウト（学習に利用しない）設定が可能ですが、個人向けの無料プランでは注意が必要です。

また、機密性の高い認証キーや個人情報がコード内にハードコードされている場合は、事前に削除またはマスク処理を行うのが鉄則です。

3.2 STEP 2：コードのチャンク化とAIへのコンテキスト投入

リポジトリが数GBに及ぶような大規模な場合は、すべてを一度に読み込ませるのではなく、機能単位（例：決済処理、ユーザー認証、バッチ処理）でフォルダを分け、関連するコード群をAIに渡します。Cursorであれば Ctrl + K で対象のシンボルを指定し、「このロジックを日本語の箇条書きで説明して」と指示するだけで、難解な独自処理の概要が掴めます。

3.3 STEP 3：関数の依存関係図・ER図の自動生成

AIに「以下のコードから、データ更新のフローをMermaid形式のシーケンス図で出力して」と指示します。出力されたMermaidコードを、NotionやGitHubのMarkdownプレビューに貼り付けるだけで、可視化された図が完成します。これにより、コードを1行ずつ追う必要がなくなり、設計上のボトルネックや「死んだコード（到達不能な処理）」を視覚的に特定できます。

このプロセスは、Excelと紙の限界を突破する業務DXで推奨される「データの可視化と自動化」の考え方と共通しています。

3.4 STEP 4：新環境への移行コード（下書き）の自動生成

既存仕様が固まったら、いよいよ下書きです。「このPHPの決済ロジックを、TypeScript（NestJS）で書き直して。ただし、バリデーションルールはそのまま維持すること」といった指示を出します。AIが生成したコードはそのままでは動かないことが多いですが、ゼロから型定義を行う手間が省け、「下書き」としての品質は手書きを凌駕します。

レガシーコード種別 × AI解析・リファクタリング手法 × 典型的落とし穴 早見表

前のセクションでレガシーコードをAIで「仕様化」する4ステップを解説しましたが、実際には「レガシーコードの種類によってAIの解析精度と使えるツールが異なる」という現実があります。COBOLの基幹システムとJavaで書かれた10年前のWebアプリでは、AIに渡せるコンテキスト量もリファクタリングの難易度も全く異なります。以下の表は、レガシーコードの種類別に最適なAI活用手法と落とし穴をまとめたものです。

この表で最も過信が危険なのが「COBOL解析でのAI仕様書生成の精度」です。AIはCOBOLコードを読んで「それらしい仕様書」を生成しますが、業種固有の業務ルール（銀行の営業日計算・決算処理の特殊ルール等）は学習データに含まれていないため、表面的には正しそうに見えて実は誤っている仕様書を生成することがあります。COBOL解析で生成した仕様書は、必ず「その業務を10年以上担当している業務担当者（業務SE）」のレビューを経てから正式仕様として採用することが必須です。

4. 現場で直面した「AI活用」の落とし穴と回避策

ツールを使えばすべて解決、というわけにはいきません。いくつかの注意点があります。

4.1 ハルシネーションを見抜くクロスチェック

AIは、存在しないライブラリのメソッドを提案したり、古い言語仕様を誤解したりすることがあります。これに対処するには、以下の「ダブルチェック」が有効です。

• 単体テストの同時生成: 下書きコードと同時に、そのコードが正しく動作することを証明するテストコードを生成させ、実行環境で実際に走らせる。
• 複数のAIでの比較: Geminiで出力した仕様書をChatGPTに読み込ませ、「この仕様書に論理的な矛盾はないか」と問いかける。

4.2 コード量制限と「文脈の欠落」への対処法

ファイル数が多いと、AIが一部の依存ファイルを読み飛ばすことがあります。これを防ぐには、各ファイルの冒頭に「// このファイルは〇〇処理を担当する」というコメントをAIに書かせ、ファイル間の関連性を明示的に定義する手法（メタドキュメンテーション）が有効です。

5. システム負債を解消した後の「持続可能な開発体制」

レガシー改修の真のゴールは、改修を終わらせることではなく、「二度とレガシー化させない体制」を作ることです。

5.1 技術的負債を可視化し続ける仕組み

コードの複雑度を静的解析ツール（SonarQubeなど）で測定し、一定の基準を超えたらアラートを出す仕組みを構築します。また、改修した後のクリーンなコードを維持するために、SFA・CRM・MA・Webの違いと全体設計で語られるような「責務の分離」を意識したアーキテクチャ設計を徹底することが重要です。

5.2 生成AIを「恒常的なドキュメント更新者」にする

一度作成した仕様書は、コードの変更に合わせて更新されなければなりません。CI/CDパイプラインの中に「コードの変更差分を読み取り、README.mdやドキュメントを自動更新する」AIスクリプトを組み込むことで、ドキュメントの鮮度を永続的に保つことが可能です。

6. まとめ：スピードと安全性を両立したレガシー改修へ

レガシー改修における「調査」と「下書き」の高速化は、もはやエンジニアの努力根性だけでは限界があります。GeminiやCursorといった最新のAIツールを正しく使いこなし、セキュリティを担保した上で解析を自動化することは、IT実務者にとって必須のスキルと言えるでしょう。

重要なのは、AIを「信じ込む」のではなく、「優秀な下書き作成者」として使い倒し、人間はより高度な判断——業務要件の整合性や、将来的な拡張性の設計——に注力することです。このシフトこそが、停滞していたプロジェクトを加速させる唯一の道です。