AI に古いコードを読ませる — レガシー保守の新しい入り口

古い言語のコードが LLM の学習データに豊富

COBOL / Perl / VB6 / Fortran は、過去 30〜50 年で大量のコードがネットに公開されている。LLM の学習コーパスに古い言語が十分含まれているため、出力品質が安定する。これは新しい技術(Qwik など 2024 年以降登場)とは逆の現象。

長いコンテキストを扱える

2024〜2025 年で AI のコンテキスト長が大幅に伸びた(Claude Opus 4.7 は 1M トークン対応)。「10 万行の COBOL モジュールを一度に AI に見せて、仕様を抽出させる」が現実的に。

エージェント実行が安定

Claude Code / Cursor / GitHub Copilot Workspace などで、「ファイルを横断してコードを読み、修正案を出し、テストを走らせる」一連の作業を AI が自律的にこなせるようになった。手作業の 5〜10 倍の速度で進む。

仕様書なしのコードに耐性が高い

レガシーコードは「コードしか残っていない」のが普通だが、AI はコードから仕様を逆算するのが得意。「これは何のためのモジュール?」を聞くと、業務ルールまで含めて説明してくれる。

典型的な使い方

「この COBOL モジュールが何をしているか、業務的に説明してください」と AI に投げる。業務ルール、データの流れ、エラー処理まで構造的に説明してくれる。

効果

1 日かけて読んでいた数百行のコードが、10 分で理解できる。コード→仕様の「考古学的作業」がほぼ消える。

精度の目安

業務ロジック中心のコードなら8〜9 割の精度。AI が誤読しやすいのは「コメントと実装が乖離している」「グローバル変数で挙動が変わる」ような箇所。怪しい部分は人間が再確認する。

注意点

業界固有の用語(保険の「保有」「失効」など)は AI が一般的な意味で解釈してしまうことがある。業務側の人と AI 解釈を突き合わせるのが重要。

典型的な使い方

関数(SUBROUTINE / SUB プログラム)に対して、「典型的な入力パターンとエッジケースをカバーするテストを生成して」と AI に頼む。COBOL / Perl / VB6 のいずれでも、AI はそれっぽいテストを書ける。

効果

テストゼロのコードを修正する怖さが消える。「修正前後で挙動が変わっていないか」を機械的に確認できる土台が手に入る。

注意点

AI が生成するテストは「今の挙動を正解として固定する」もの。実装にバグがあれば、バグごと固定してしまう。「テストが通ればOK」ではなく、テスト内容を人間が読むのが大事。

回帰テスト基盤として

レガシーコードに AI でテストを後付けし、それを「移植時の回帰テスト」として使う流れが現代的。Vitest / Playwright のようなモダンテストフレームワークと組み合わせる。

下訳としての AI

AI が「COBOL モジュールを Java で同等の動きに翻訳する」下訳をする。人間が見直して、Java らしいコードに直す。「下訳 8 割、人間 2 割」の役割分担が現実的。

並行運用パターン

新旧コードを同時に動かして結果を比較する「シャドウラン」設計。AI で書いた新版が、レガシー版と同じ結果を出すかを本番データで毎日検証する。違いが出たら新版を修正。

移植速度

100 万行の COBOL システムの Java 移植が、従来 5〜10 年だったのが 2〜4 年に短縮されているプロジェクト事例も。完全自動化はまだ難しいが、人月の削減効果は確実。

注意点

AI が出した Java コードは「動くが Java らしくない」ことがある。「動く」と「保守しやすい」は別問題。人間のレビューと再構成が、最終品質を決める。

典型的な使い方

「このコードに SQL インジェクション や XSS の可能性がある箇所を全部リストアップして」と AI に頼む。古い言語のコードでも、典型的な脆弱性パターンを高い精度で検出できる。

レガシー特有のリスク

古いコードにはハードコードされたパスワード、平文のクレデンシャル、検証なしの SQL 連結が普通に残っている。AI で一括スキャンすると驚くほど見つかる。

注意点

AI が「これは脆弱性」と指摘したものが実際にはコンテキスト上問題ない場合もある。偽陽性のフィルタリングに人間の判断が要る。とはいえ、レビュー対象を絞ってくれるだけで作業効率は大幅に上がる。

継続的な監査体制

「コミットがあるたびに AI でセキュリティスキャン」を CI に組み込む運用も現実的に。レガシーシステムを「動いているまま安全に保つ」仕組みが、AI で初めて実現できるようになった。

AI の解説を鵜呑みにする

AI はもっともらしく嘘をつく(ハルシネーション)。「この関数は X をしている」と説明されても、実際に動かして確認するクセを失わない。とくに業務ロジックの解釈は誤りやすい。

テスト内容を読まない

AI が生成したテストが通っても、「テスト自体が間違っている」可能性がある。assertEquals(0, calc()) のような無意味なテストを通しているだけ、というケースもある。生成テストは必ず読む。

移植時の挙動ずれ

COBOL の10 進数演算と Java の浮動小数点では結果が変わる。移植後の AI 生成コードが「動くが計算結果が違う」事故は珍しくない。BigDecimal を使うなどの明示が必要。

セキュリティ上の不安

古いコードを外部 AI サービスに送信することに、社内規定や顧客契約で制約があるケースがある。オンプレ LLM(Ollama / vLLM / Azure OpenAI のプライベートデプロイなど)を検討する。

過信して本番リリース

「AI が大丈夫と言ったから」で本番に出すと、想定外の事故が起きる。シャドウラン期間を必ず設ける。金融・医療・公共系は特に慎重に。

業務知識を AI に丸投げ

AI はコードを読めても、「20 年前にこの業務はどう動いていたか」のような文脈は知らない。業務担当者・元担当者・社内ベテランの知識と組み合わせて初めて、移植の意味が完成する。

「AI を使ったレガシー保守」が新しい職種に

「COBOL が書ける」だけでなく、「AI と組み合わせて COBOL システムを効率よく保守できる」人材の需要が伸びている。両方できる人は、レガシー単独の人より給与で 1.3〜1.5 倍。

少人数で大規模システムを回す

従来 30 人必要だった保守チームが、AI 補助で 10〜15 人で回るケースが出てきた。少数精鋭で高給のチーム編成にシフトする企業も。

移植プロジェクトの活発化

「コストが見合わないから現状維持」だった案件が、AI で移植コストが半減することで動き始めている。移植プロジェクトのコンサル / アーキテクト需要が増えている。

学習コストの低下

これから COBOL / Perl を学ぶ人にとって、AI が師匠の代わりになる。Stack Overflow に答えがない質問でも、AI が解説してくれる。新規参入が現実的になってきた。