このシステム、動いているうちは絶対に触るな。
情報システム部門の現場で、このような言葉を耳にしたことはないでしょうか。あるいは、システムを安定稼働させるために、やむを得ずそう指示している状況かもしれません。
担当者が退職し、仕様書は20年前のまま更新されていない。ソースコードには「修正禁止」という謎のコメントだけが残されている。こうした「レガシーシステム」のブラックボックス化は、システム運用における深刻な課題となっています。
DX（デジタルトランスフォーメーション）やモダナイゼーション（近代化）の必要性は理解していても、内部構造が不明なシステムに手を入れるのは非常にリスクが高い行為です。
そこで今回は、この「触るのが怖い」システムと論理的に向き合うためのアプローチについて解説します。それは、生成AI（LLM：大規模言語モデル）を単なる「コードの書き手」としてではなく、複雑な仕様を紐解く「優秀な通訳者」として活用する手法です。
いきなりシステム全体を作り変える必要はありません。まずはAIの自然言語処理能力を活用し、ブラックボックスの中身を安全かつ効率的に可視化することから始めてみましょう。
はじめに：なぜ今、レガシー解析にLLMが注目されるのか
現場が抱えるシステム改修への「恐怖」は、システムそのものではなく、内部構造の「不可視性（見えないこと）」に起因しています。
「ブラックボックス化」したシステムの現状
基幹システムが長年の運用の中で「秘伝のタレ」のように機能追加を繰り返し、複雑怪奇な構造になっているケースは珍しくありません。
当時の開発ベンダーとの契約は終了し、仕様を把握していたベテラン社員も不在。残されているのは、全体像が把握できないスパゲッティコード（複雑に絡み合ったプログラム）のみという状況です。これでは、ビジネス要件に合わせて機能を追加しようにも、影響範囲の特定が困難です。「下手に触ってシステムが停止すれば大きな問題になる」というリスクが、システム刷新の足かせとなっています。
人間が解読する限界とAIの可能性
従来、こうしたシステムの解析には、エンジニアが多大な時間とコストをかけて一行ずつコードを読み解く「リバースエンジニアリング」という手法がとられてきました。しかし、何十万行にも及ぶコードを人間が手作業で読み解くには限界があります。変数の依存関係を追跡するだけでも膨大な労力がかかり、見落としも発生しやすくなります。
ここで実用的な解決策として注目されているのが、Transformerモデルなどを基盤として急速に進化を遂げたLLMと、それを活用したAIコーディングエージェントです。
ChatGPTやClaudeなどの最新モデルは、単にプログラミング言語を翻訳するだけでなく、「コードの意図」を論理的に理解し、熟練エンジニアのように推論する能力を備えています。
特に近年の技術進化において、以下の3点がレガシー解析の精度と効率を劇的に向上させました。
プロジェクト全体の文脈理解:
単一のファイルだけでなく、システム全体をコンテキスト（文脈）として読み込む機能が標準化されています。これにより、AIは複雑な依存関係や、複数ファイルにまたがる仕様の背景まで正確に把握できます。自律的な検証サイクル:
最新のAIエージェントは、自ら計画を立て、コードを解析し、その結果の妥当性を検証するループを回すことが可能です。「情報収集 → 実行 → 検証」というプロセスを自律的に行うことで、解析の精度が飛躍的に高まっています。適材適所のモデル連携:
処理速度に優れたモデルと、深い論理推論が得意なモデルを使い分ける最適化手法が確立されています。全体像の把握には推論特化型モデルを、個別の関数解説には高速モデルを用いることで、効率的な解析が実現します。
AIにとって、COBOLやJavaで書かれた数十年前のコードも、現代の言語と同じく自然言語処理の対象です。AIは疲労することなく膨大なコードを読み解き、「この処理は業務的にどのような意味を持つのか」を、人間が理解しやすい平易な言葉で説明してくれます。
もはやAIは単なる検索ツールではありません。失われた仕様を復元し、モダナイゼーションを効率的に進めるための「パートナー」として機能します。これが、レガシー解析にAIが不可欠となっている論理的な理由です。
Q1-Q3：LLMによる解析の「基礎と仕組み」
ここからは、LLMがどのようにレガシーコードを理解しているのか、その技術的な仕組みを分かりやすく紐解いていきましょう。
Q1: なぜAIは古い言語（COBOL等）を理解できるのですか？
「最新のAIが、なぜ数十年前の古い技術を理解できるのか」と疑問に思われるかもしれません。
その理由は、LLMの学習データにあります。AIは、GitHubなどの公開プラットフォームに存在する膨大なソースコードを事前に学習しています。その中には、世界中のエンジニアが過去数十年間にわたって蓄積してきた、あらゆる年代・言語のコード資産が含まれています。
COBOL、PL/I、Visual Basic 6.0といった現在では開発者が少なくなった言語であっても、AIはそれらの文法規則や構造、典型的な実装パターンを統計的に学習済みです。そのため、人間にとっては解読が困難なコードであっても、AIは既知のパターンとしてスムーズに解析できるのです。
Q2: 人間が読むのと比べて、何が決定的に違うのですか？
最大の違いは、圧倒的な「文脈（コンテキスト）の保持能力」と「推論速度」です。
人間が複雑なコードを読む際、「この変数は別の画面で入力された値で…」と、短期記憶（ワーキングメモリ）に情報を保持しながら読み進める必要があります。しかし、コードが長くなると人間の記憶力はすぐに限界を迎えます。
一方、最新のLLMは、数万行から数十万行に及ぶコード情報を一度にコンテキストとして保持できます。「この変数は、複数のファイルを跨いだ500行前の処理で定義されたもの」といった離れた関係性も、瞬時に結びつけることが可能です。
また、単に「if文（条件分岐）がある」と直訳するのではなく、「在庫が基準値を下回った場合に発注フラグを立てる処理です」というように、コードの背後にあるビジネスロジック（意図）を汲み取って説明できる点が、従来の静的解析ツールとの決定的な違いです。
Q3: 「コード解析」とは具体的に何をアウトプットする作業ですか？
AIにコードを読ませて終わりではありません。目的は、人間がシステムを理解し、安全に改修できる状態（ドキュメント化）にすることです。
具体的には、AIを活用して以下のようなアウトプットを生成します。
- 機能要約: 「このプログラムは、月末の請求計算を行うための処理です」といった、非エンジニアにも理解できる概要説明。
- 処理フロー図: 処理の分岐条件やデータの流れを、Mermaid記法（テキストから図を生成する形式）などで出力し、視覚的なフローチャートにする。
- ビジネスロジックの抽出: 「会員ランクがゴールド以上、かつ購入額が1万円以上の場合、送料を無料にする」といった、コードに埋め込まれた業務ルールを自然言語で抽出する。
- コードコメントの付与: ソースコードの各行や関数ごとに、処理内容を説明するコメントを追記し、可読性を向上させる。
これらは、次にシステムを改修するエンジニアにとって、ブラックボックスを安全に紐解くための正確な「地図」となります。
Q4-Q6：導入への不安を解消する「安全性とリスク」
企業システム、特に機密情報を扱うシステムでAIを活用する際は、セキュリティとリスク管理が不可欠です。ここでは、最新のセキュリティ基準に基づいた安全な運用方法を解説します。
Q4: 機密情報を含むコードをAIに読ませて大丈夫ですか？
これは情報セキュリティにおいて最も重要な確認事項です。一般向けの無料サービスや個人アカウントに社内の機密コードを入力することは、入力データがAIの再学習に利用されるリスクがあるため、厳格に避けるべきです。
業務で安全に利用するためには、以下の対策を講じることが鉄則となります。
- エンタープライズ向けプランやAPIの利用（学習利用のオプトアウト）:
ChatGPT EnterpriseやTeamプラン、Azure OpenAI、AWS Bedrockといった法人向け環境やAPI経由での利用では、入力データがAIの学習に使用されない仕様（オプトアウト）が標準となっています。企業導入ではこれらの環境利用が前提です。また、データレジデンシー（データの保存場所）が自社のコンプライアンス要件を満たしているかの確認も重要です。 - ローカルLLMの活用:
社内の閉域網（クローズドネットワーク）で動作するLLMを構築し、データが外部のインターネットに出ない環境を用意します。極めて機密性の高いコアシステムの解析では、このアプローチが有効です。
さらに、どの環境を利用する場合でも、コードをAIに渡す前に個人情報、IPアドレス、パスワードなどの機密情報をマスキング（伏せ字化）する前処理のルールを徹底することが推奨されます。
Q5: AIの解説が間違っている（ハルシネーション）可能性は？
はい、その可能性はゼロではありません。AIは確率モデルに基づいて次の単語を予測しているため、存在しない関数を提示したり、処理の解釈を誤ったりする「ハルシネーション（幻覚）」が発生することがあります。
最新の推論強化モデルなどでは論理的推論力が飛躍的に向上しており、精度は格段に高まっていますが、それでも100%完璧とは言えません。
そこで現在、実務において推奨されているのが「複数AIによるクロスチェック」という手法です。
例えば、あるAIモデルでコードの解説を生成し、その内容の妥当性を別のAIモデルに検証させるといった連携フローを構築することで、誤りを大幅に低減できます。
最終的な正誤確認は人間のエンジニアが行う必要がありますが、AI同士の相互検証を組み込むことで、人間が確認すべきエラーの発生率を劇的に下げることが可能です。
Q6: 解析だけでシステムが壊れることはありませんか？
ご安心ください。「解析」というプロセス自体は、コードのテキストデータを「読む」だけの作業（Read-only）です。システムを直接書き換えたり、プログラムを実行したりするわけではないため、解析によって本番環境が停止したり、データが破損したりすることはありません。
詳細な深掘り調査機能を用いて依存関係を調べる場合でも、AIが自律的に本番コードを修正することはありません。
推奨される安全な手順は、本番環境のソースコード一式をコピーし、ネットワークから隔離された安全なサンドボックス環境（検証用環境）でAIに読み込ませる方法です。この手順を踏めば、AIと何度対話を繰り返しても、稼働中のシステムに影響を与えることは物理的にあり得ません。
参考リンク
Q7-Q9：無理なく始める「スモールスタートの手順」
AI導入において、いきなり大規模なプロジェクトを立ち上げる必要はありません。まずは小規模な範囲で仮説検証（PoC）を行い、実証データに基づいて効果を確認することから始めましょう。
Q7: いきなり全面リプレースを目指すべきですか？
いいえ、それは推奨されません。長年稼働してきたシステムを一度に刷新する「ビッグバン移行」は、リスクが非常に高く、失敗する確率が高いことがデータからも示されています。
まずは「現状把握（As-Isの可視化）」に注力することをお勧めします。「移行」ではなく、システムの「理解」を最初のゴールに設定します。内部構造が論理的に把握できれば、「ここは既存のまま維持する」「ここはクラウドネイティブに移行する」といった、データに基づいた合理的な判断が可能になります。
Q8: どの部分から解析を試すのが効果的ですか？
膨大なプログラムのすべてを一度に解析する必要はありません。まずは以下のような、費用対効果が見込みやすい箇所から着手してみてください。
- 頻繁にエラーが発生する箇所: 修正の優先度が高いものの、複雑で手が出しにくい部分。
- 改修予定がある機能: 法改正やビジネス要件の変更に伴い、ロジックの変更が確定している部分。
- 最も複雑とされるプログラム: ここを可視化できれば、プロジェクト全体の実現可能性（フィージビリティ）が証明できる部分。
まずは1つのファイル、あるいは1つの関数といった最小単位から検証を始めるのが実践的です。
Q9: 解析結果をどのようにドキュメント化すべきですか？
WordやExcelで体裁の整った仕様書を新たに作成しようとすると、それだけで作成・維持の管理コストが膨張してしまいます。効率的なアプローチは、「コードそのものに説明を持たせる」ことです。
AIが生成した解説コメントを、ソースコード内に直接記述します。あるいは、コードと同じリポジトリ（保管場所）内に「README.md」のようなMarkdown形式で解説ファイルを同梱する手法も有効です。
これにより、コードとドキュメントが常に一体としてバージョン管理され、「仕様書の保存場所が分からない」「仕様書と実際のコードが乖離している」といった運用上の課題を未然に防ぐことができます。
まとめ：ブラックボックスを開ける鍵を手に入れる
レガシーシステムのモダナイゼーションにおいて、AIは万能の魔法ではありませんが、複雑な内部構造という暗闇を論理的に照らし出す、極めて強力なツールとなります。
「中身が分からないから手が出せない」という状態から、「構造が可視化されているため、具体的な対策が立案できる」という状態へ。この情報に基づく確実性の向上が、プロジェクトを前進させる最大の推進力となります。
まずは、手元にある「誰も触りたがらない古いコード」を1つ選び、セキュアな環境下でAIに解析させてみてください。「このようなビジネスロジックで動いていたのか」という実証的な体験が、システムのブラックボックス化という課題を解決する第一歩となるはずです。
コメント