生成AIに古いコードを渡し、「新しい言語へ変換して」と頼めば、レガシーシステム刷新は一気に終わるのでしょうか。
小規模なプログラムなら、コードの説明、書き換え、テストの下書きまで短時間で進められます。しかし企業の基幹システムでは、コードを変換しただけでは移行になりません。
- 何十年分もの業務ルールがコードへ埋め込まれている
- 仕様書、チケット、運用手順と実装が一致していない
- データ構造と処理が密結合している
- 他システムとの依存関係を誰も把握していない
- 現行と同じ結果になることを証明するテストがない
- 本番切替に失敗したときの戻し方が決まっていない
こうした状態でコード生成だけを高速化すると、「動く新システム」ではなく、説明できない新しいレガシーシステムを作る危険があります。
AWS、Google、Microsoftが2026年に公開したレガシー刷新の事例を読むと、共通しているのはモデルの賢さではありません。先に現行システムの正解を作り、変更を小さく分け、生成物を追跡可能にし、現新比較で証明する設計です。
この記事では、生成AIでレガシーシステム刷新のどこを速くできるのか、何を人が判断すべきか、SIerが成果物として残すべき7つの受入条件を整理します。
最終更新：2026年10月3日
結論：AIで速くなるのは、刷新プロジェクトの一部分
生成AIは、次の仕事を速くできます。
- 古いコードの説明と文書化
- プログラム、データ、ジョブの依存関係調査
- 業務ルールと受入条件の下書き
- 言語・フレームワークの変換案作成
- テストケースと変換作業の生成
- ビルドエラーや非互換APIの修正候補作成
一方で、次の判断は自動的には決まりません。
- どの業務を残し、どの業務を変えるか
- 現行コードの挙動が正しい仕様なのか
- どの単位なら安全に切り離せるか
- データ移行中の整合性をどう保つか
- 性能、可用性、監査要件を満たしたか
- いつ旧システムを停止してよいか
つまり、AIによる刷新は「コード変換ツールの導入」ではなく、調査、設計、変換、検証、切替を証拠でつなぐプロジェクトとして扱う必要があります。
AWSは、AIより先に「正解の土台」を作る
AWSは2026年6月、メインフレーム刷新で汎用AIツールが失敗しやすい理由を三つ挙げています。
- 一つのアプリで使えた手順が、別のアプリでは通用しない
- ソースコードだけを見て、システム全体の文脈を理解できない
- 元コードから要件までの追跡経路が残らない
参考：AWS「Reimagine mainframe applications with traceability and speed」
AWS Transformのアプローチは、AIへすぐコードを書かせるのではなく、コードとデータを解析して決定論的な土台を作ることです。
- プログラム、エントリーポイント、データストアを棚卸しする
- 依存関係グラフを作る
- 不足ファイルや未対応言語を先に検出する
- コードを業務機能単位へ整理する
- 元コードへ追跡できる業務要件と受入条件を生成する
特に重要なのは、最初から全体を変換しないことです。業務機能を一つ選び、調査から本番検証まで通してから対象を広げます。
この考え方は、AWS製品を使わない案件にも応用できます。AIへ渡す前に、資産台帳、依存関係、業務機能、欠損情報を明らかにすることが、刷新の出発点です。
Google・Siemensは「通常のRAGだけでは足りない」と考えた
Siemensの産業用ソフトウェアには、長期間開発されてきた数億行規模のコードがあり、知識はコードだけでなく、Jira、Confluence、古いPDFなどへ分散していました。
Google Cloudとの取り組みでは、これらを単純にベクトル検索するのではなく、コード、モジュール、仕様書、チケット、業務要件の関係をKnowledge Fabricというグラフで表現しています。
参考：Google Cloud「How Siemens slices the elephant」
ここで使われているのは、次の三つの検索です。
- 構造的な関係をたどるグラフ検索
- 意味の近さを探すベクトル検索
- 固有名詞や正確な文字列を探す全文検索
既存コードを文章として平坦化すると、クラス、ファイル、モジュール、要件の関係が失われます。社内文書を探す通常のRAGと、システム変更の影響分析では、必要な文脈が違います。
また、Siemensは「巨大な一つの依頼」を複数の役割へ分けています。
- Search Agent：関連コードと資料を調査する
- User Story Agent：担当者から要件を聞き、受入条件を作る
- Architecture Impact Agent：変更の波及範囲を調べる
- Task Breakdown Agent：変更を小さな実装単位へ分割する
- Coding Agent：限定された文脈で実装する
各段階に人の確認を残し、調査なしにCoding Agentへ到達させません。
RAGの精度改善では、検索と生成を分けて評価する方法を整理しました。レガシー刷新では、さらにコード構造、依存関係、業務要件を検索対象へ加える必要があります。
Googleが示すもう一つの論点：コードとデータは一緒に動く
Google Cloudは、現実のメインフレーム刷新はCOBOLからJavaへの変換問題ではないと説明しています。
参考：Google Cloud「Real-world mainframe modernization with AI」
難しいのは、次のような条件です。
- 業務ロジックが独自データベースやレコード形式と結び付いている
- 一つの取引が多数のプログラム、ジョブ、外部接続を通る
- アプリケーション境界が明確でない
- 処理順序と条件分岐が複雑に連鎖している
コードだけを変換し、データモデル、バッチ順序、外部インターフェースを後回しにすると、局所的には動いても業務全体では結果が変わります。
Googleは、刷新後のシステムへ実際の本番トラフィックを流し、現行システムと新システムの出力を並べて比較するDual Runも紹介しています。
これは「テストが通った」より強い証拠です。実際の入力に対して、応答、メッセージ、データ変更が同じかを継続的に確認し、十分な同等性を示してから旧システムを停止します。
Microsoftは、一発変換ではなく「調査→計画→実行」に分ける
MicrosoftのGitHub Copilotによる.NETモダナイゼーションも、一つのプロンプトで完了させる構成ではありません。
参考：Microsoft「Modernize .NET Anywhere with GitHub Copilot」
公開されている流れは、次の三段階です。
- Assess：現在のバージョン、依存パッケージ、非互換、阻害要因を調べる
- Plan：作業順序と変更単位を計画する
- Execute：計画されたタスクを実行し、ビルドとテストで確かめる
Assessment、移行計画、実装タスクは、リポジトリ内の成果物として残ります。チームは実行前に範囲と順序をレビューでき、途中で新しい問題が見つかれば計画を更新できます。
公開実装を見る際には、名称の変更にも注意が必要です。旧dotnet/modernize-dotnetは非推奨となり、現在の更新先はmicrosoft/upgrade-agent-pluginsです。
2026年10月3日時点で新リポジトリは継続更新され、セキュリティ報告窓口もあります。一方、公開ツリーでは自動テストやCIワークフローを確認できませんでした。公開プラグインがあることと、自社アプリで安全に変換できることは別です。実案件では、対象アプリを使ったPoCと回帰試験が必要です。
レガシー刷新には四つの経路がある
すべてのシステムをクラウドネイティブへ書き直す必要はありません。業務価値と変更リスクに応じて経路を選びます。
| 経路 | 適する状況 | AIの主な役割 | 主なリスク |
|---|---|---|---|
| 延命・外部化 | 安定稼働し、変更が少ない | 文書化、API化支援 | 技術負債が残る |
| リプラットフォーム | 機能は維持し、実行基盤を変えたい | 設定変換、互換性調査 | 新基盤でも古い制約を引き継ぐ |
| 機能同等リファクタリング | 保守性を上げつつ挙動を守りたい | コード変換、テスト生成 | 隠れた挙動差を見落とす |
| リイマジン | 業務や顧客体験から変えたい | ルール抽出、要件化、再実装 | 範囲拡大と仕様誤認 |
安定した大量バッチは機能同等の変換、競争力に直結する顧客向け業務は再設計、変更予定のない周辺機能は延命というように、一つの企業内でも経路を分けます。
「AIが変換できる方式」から選ぶのではなく、業務として何を変えたいか、どこまで現行挙動を守るかから選ぶことが重要です。
AI変換を受け入れるための7条件
1. 資産台帳の完全性を確認できる
プログラム、ジョブ、データベース、ファイル、外部インターフェース、利用部門、稼働状況を一覧化します。
AIが解析できなかったファイル、対象外言語、動的呼び出し、生成コードも欠損として記録します。「解析結果にない」ことを「使われていない」と判断しません。
2. 業務ルールを元情報まで追跡できる
生成した要件や仕様には、元コード、設計書、チケット、担当者確認などの根拠をひも付けます。
コードの挙動と文書が矛盾する場合は、AIに正解を選ばせず、業務責任者が現行仕様、欠陥、廃止対象のどれかを判断します。
3. 依存関係とデータ系統が見える
プログラム間の呼び出しだけでなく、データの読み書き、バッチ順序、再送、排他、外部API、手作業を含めて影響範囲を確認します。
変更単位は、コード量ではなく、業務機能とデータ整合性を壊さない境界で決めます。
4. 機能同等性を自動比較できる
代表ケースだけでなく、境界値、例外、締め処理、再実行、障害復旧を含む入力と期待結果を用意します。
AIが生成したテストだけでは、AIが理解できなかった仕様を同じように見落とす可能性があります。過去の本番データ、既存試験、業務担当者の例外ケースを組み合わせます。
5. 非機能要件を別に検証する
結果が同じでも、処理時間、同時実行、可用性、監査、権限、データ保持、災害復旧が劣化すれば本番移行できません。
性能と運用性は、コードレビューだけでなく、本番相当の負荷と障害試験で確認します。
6. 並行稼働と切り戻しができる
現行と新システムを同じ入力で動かし、差分を記録します。差分を許容する場合は、理由と承認者を残します。
切替前に、データ同期、旧系への戻し方、二重処理の防止、戻せなくなる時点を確認します。
7. 判断者と証拠を残す
AI、開発者、SIer、業務部門、運用部門の責任を分けます。
最低限、次の成果物を版管理します。
- 資産・依存関係台帳
- 業務ルールと根拠の対応表
- 移行方式の判断記録
- Assessmentと移行計画
- 受入テストと現新比較結果
- 未解決差分とリスク受容
- 切替・切り戻し手順
90日で始める小規模な刷新実験
1〜30日：一つの業務機能を選ぶ
コード量ではなく、利用者、入力、出力、データ、担当者が分かる業務機能を選びます。
資産台帳と依存関係を作り、不明点を記録します。AIで文書化を進めても、確認できない部分を推測で埋めません。
31〜60日：調査と計画を成果物にする
AIにコードを書かせる前に、業務ルール、変更影響、移行方式、受入条件を作ります。
業務担当者、現行保守担当者、移行チームがレビューし、根拠へ戻れるかを確認します。計画が承認されるまでは本格変換へ進みません。
61〜90日：変換して現新比較する
限定された機能を変換し、自動テスト、本番相当データ、性能試験で確認します。可能であれば現行と新システムを並行実行し、差分を記録します。
次へ進む条件は「コードが生成できた」ではありません。
- 根拠付きの業務ルールを作れた
- 主要な依存関係を確認できた
- 現新比較の差分を説明できた
- 性能と運用要件を満たした
- 切り戻しを実行できた
これらを満たしてから、次の業務機能へ対象を広げます。
SIerの価値は、コード変換から「移行の証明」へ移る
AIによってコード変換の単価と時間が下がると、変換行数や投入人数だけでは差別化しにくくなります。
一方、顧客が本当に必要としているのは、次の説明です。
- 何が現行仕様なのか
- どこを変え、どこを守ったのか
- 業務とデータにどんな影響があるのか
- 新システムが同じ仕事をできる証拠は何か
- 障害時にどう戻せるのか
- 旧システムをいつ停止できるのか
SIerの成果物は、変換済みコードだけではなく、現行理解、移行判断、機能同等性、切替可能性を証明する証拠一式になります。
契約も、単純な変換行数より次の単位へ移ります。
- 調査済みの業務機能
- 根拠付きで抽出した業務ルール
- 受入条件を満たした移行単位
- 現新比較を通過したトランザクション
- 廃止できた旧資産と削減した運用負荷
ただし、AIで短縮できることを前提に固定価格化し、未知の依存関係を受託側だけへ負わせるのは危険です。調査段階と変換段階を分け、欠損や仕様矛盾が見つかったときの再見積り条件を合意します。
生成AI時代のSIerはどうなる？で述べた「変化を運営する会社」という方向は、レガシー刷新では「安全に移行できることを証明する会社」として具体化します。
製品・公開実装を選ぶときの注意
AWS TransformとGoogle Cloudのメインフレーム刷新機能は、特定クラウドと専門サービスを組み合わせた商用サービスです。公開ブログで紹介される効果は各社・顧客による事例であり、あらゆるシステムで同じ結果になる独立ベンチマークではありません。
MicrosoftのUpgrade Agentは公開リポジトリから導入できますが、対象は主に対応言語・フレームワークのアップグレードです。業務ルール抽出、データ移行、全社横断の依存関係分析まで自動的に解決するものではありません。
自社開発では、コード解析、グラフデータベース、RAG、コーディングエージェントを組み合わせられます。ただし、部品を所有できる代わりに、認証、評価、監査、モデル変更、可用性を自社で運用します。
選定時は、デモの変換速度より次を確認します。
- 対応言語、データストア、ジョブ、外部接続
- 解析できなかった資産の表示
- 元コードから生成物までの追跡性
- テスト生成だけでなく実行・比較できる範囲
- ソースコードと業務データの保存先
- モデル学習への利用条件
- 出力を別ツールへ持ち出せるか
- ベンダー変更時に残る成果物
コピペ用：刷新プロジェクト開始前チェック
現行理解
- [ ] 対象業務の責任者が決まっている
- [ ] プログラム、データ、ジョブ、外部接続を棚卸しした
- [ ] 解析対象外と欠損を記録した
- [ ] コードと文書の矛盾を判断する担当者がいる
移行設計
- [ ] 延命、リプラットフォーム、リファクタリング、再設計を比較した
- [ ] 業務機能単位で移行範囲を切った
- [ ] 業務ルールを元情報まで追跡できる
- [ ] データ移行とアプリ変更を同時に検討した
検証・切替
- [ ] AIが生成していない独立したテストケースがある
- [ ] 現新比較の方法と許容差を決めた
- [ ] 性能、可用性、セキュリティ、監査を試験する
- [ ] 並行稼働と切り戻しを実測する
- [ ] 旧システムを停止する条件が決まっている
契約・運営
- [ ] 調査と変換の契約範囲を分けた
- [ ] 不明な依存関係が見つかった場合の扱いを決めた
- [ ] AI・ベンダー・SIer・顧客の責任を分けた
- [ ] モデルやツール変更後の再検証条件がある
- [ ] 中止しても資産台帳と仕様を再利用できる
本番へ進める総合判断には、生成AI PoCの本番移行チェックリストも利用できます。変換後のレビューはAIコードレビューの設計方法、移行後の運用はAIエージェントに本番運用を任せてよいかで確認できます。
結論：刷新の速度は、コード生成より証拠の流れで決まる
生成AIは、長年放置されてきたコードを読み、文書化し、変換案を作る強力な道具です。しかし、コードを生成できることと、基幹業務を安全に移行できることは同じではありません。
成功する刷新は、次の順番で進みます。
- 現行資産と欠損を把握する
- 業務機能と依存関係を構造化する
- 元情報へ戻れる要件と受入条件を作る
- 変更を小さく分けて変換する
- 現新比較と非機能試験で証明する
- 切り戻せる状態で段階的に切り替える
AIに任せるのは、この流れの中で反復できる作業です。何が正しい仕様か、どの差分を受け入れるか、いつ本番責任を移すかは、人と組織が決めます。
生成AIでレガシー刷新を速くする鍵は、より大きなプロンプトではありません。現行から新システムまで、判断と証拠が途切れない移行設計です。
関連記事
- AIコーディング時代の社内開発基盤 — 刷新後のシステムを安全な標準経路へ載せ、継続運用する方法を整理しています。
- 生成AI時代のSIerはどうなる？ — コード生成が安くなる中で、SIerが何を価値にするかを整理しています。
- RAGの精度が上がらない7つの原因 — 文書検索の失敗を検索と生成に分けて改善します。
- AIコードレビューの設計方法 — AIが生成・変換した変更をリスクに応じて検証する方法です。
- 生成AI PoCの本番移行チェックリスト — 業務価値、品質、安全性、データ、運用、コストを35項目で確認できます。
- AIエージェントに本番運用を任せてよいか — 移行後の監視、障害調査、復旧を安全に自律化する設計です。
参考資料
以下は2026年10月3日に本文と公開状況を確認しました。
- AWS：Reimagine mainframe applications with traceability and speed
- AWS：Reimagining mainframe applications with AWS Transform and Claude Code
- Google Cloud：How Siemens slices the elephant
- Google Cloud：Real-world mainframe modernization with AI
- Microsoft .NET Blog：Modernize .NET Anywhere with GitHub Copilot
- Microsoft：Upgrade Agent Plugins
WRITTEN BY
コメント