生成AIの活用は、コード補完から、仕様復元・コード変換・テストなど複数工程を支援する段階へ広がりつつあります。本ページでは、AIでレガシーシステムを刷新する方法と、AIを活用しやすい基盤へ移行する考え方を解説します。
AIモダナイゼーションは、生成AIで現行資産の解析・仕様復元・コード変換・テストを支援しつつ、移行後もAIを活用しやすいシステム基盤へ刷新する取り組みです。AIの出力はそのまま本番へ反映せず、業務担当者や技術者が現行挙動やテスト結果と照合します。刷新範囲や品質基準、責任者を明確にし、人が最終判断を担うことが前提です。
AIモダナイゼーションには、現時点で公的に統一された一つの定義があるわけではありません。本記事では、生成AIやAIエージェントを使って、老朽化したシステムの調査・仕様復元・コード変換・テストなどを効率化し、将来のAI活用にも適したシステムへ刷新する取り組みとして整理します。
AIモダナイゼーションは、単に古いコードをAIで変換する取り組みではありません。刷新工程の効率化と、移行後のAI活用を見据えた基盤整備の両方を検討します。
また、生成された仕様やコードが正しいとは限りません。AIの出力をそのまま本番へ反映するのではなく、業務担当者と技術者が確認し、現行システムの挙動やテスト結果と照合することが前提です。
現行資産の解析、仕様書の復元、コード変換、テストケース生成などを支援させる
データ、API、アクセス制御、ログ、監視を整え、AIを業務へ組み込みやすくする
刷新範囲、品質基準、目標構成、本番切り替えの責任者を明確にする
生成AIを活用できる範囲は、コード変換だけではありません。現行調査からテスト、移行後の運用準備まで、工程ごとに支援できる作業があります。
表は横にスクロールできます
| 工程 | 生成AIが支援できること | 人が確認・判断すること |
|---|---|---|
| 現行資産の解析 | コードの要約、依存関係の抽出、データ入出力や外部接続箇所の整理 | 実際の業務フロー、例外時の運用、担当者の暗黙知との一致 |
| 仕様復元 | ソースコードから仕様書のたたき台を作り、既存文書との差分候補を抽出 | 業務上の意味、現行システムの挙動、欠落している仕様の確認 |
| 移行方針・コード変換 | 移行方式の比較支援、言語変換、API定義、クラウド向けコードの生成 | 残す機能、廃止する機能、刷新範囲、目標アーキテクチャの決定 |
| テスト・品質確認 | 単体テスト候補の生成、変換前後の差分説明、レビュー観点の抽出 | 受入条件、性能、可用性、セキュリティ、監査、復旧要件への適合 |
| 移行・運用準備 | 移行手順や運用文書のたたき台作成、変更履歴や判断材料の整理 | 切り替え判断、切り戻し条件、監視・障害対応・保守体制の確立 |
生成AIが出力するのは、検証前の分析結果です。コードだけでは、障害時の手作業、担当者が経験的に判断している条件、使われていないように見えて実際には必要な処理まで把握できないことがあります。業務担当者への確認、稼働ログの分析、現行テストとの照合を組み合わせる必要があります。
生成AIの活用は、単発のコード生成から、複数のAIエージェントが解析・変換・検証を分担する形へ進みつつあります。一方で、商用システムでは人の説明責任が残ります。
2026年7月、富士通は、複数のAIとモダナイゼーションの専門エンジニアを組み合わせる「Fujitsu AIドリブンモダナイゼーションサービス」の国内提供を開始しました。同社は、AIエージェントによる工程のオーケストレーションと、Human-in-the-loopによる最終判断を組み合わせています。
NTT DATAも、AIを既存工程の補助として導入するだけでなく、AIを前提に開発プロセスを組み直す「AI-Native開発」の考え方を示しています。AIが担う範囲が広がっても、最終的なアカウンタビリティは人に残るとしています。
富士通は、同サービスによって工程期間を約40％短縮できると発表しています。ただし、これは同社サービスについて示された効果です。対象言語、資産規模、現行資料の状態、品質基準によって結果は変わるため、自社のコードを使ったPoCで再現性を確認する必要があります。
ブラックボックス化したレガシーシステムでは、設計書の欠落や実装との乖離が移行を妨げます。NTT DATAは、COBOLソースコードから設計書を復元する工程に複数のLLMを活用しています。
NTT DATAは、COBOLで構築された勘定系商用システムを対象に、複数のLLMを使ってソースコードから設計書を復元する取り組みを紹介しています。設計書が欠けているシステムでも外部仕様を把握しやすくし、ブラックボックス化した資産の理解を支援するものです。
AIに仕様を復元させるだけでなく、COBOLの有識者が成果物を評価する工程を残している点が重要です。仕様復元のスピードと、専門家による品質確認を組み合わせる考え方が参考になります。
東京海上日動システムズとAWSは、レガシーなJavaアプリケーションをAWS Lambda中心のサーバーレス構成へ再設計するプロセスで、生成AIを活用しました。
タスクを細かく分け、REST APIの定義、データベーススキーマの更新案、バックエンドとフロントエンドのコード生成などを段階的に進めました。生成AIの出力は人がレビューし、必要に応じて修正や追加指示を行っています。
95％という数値は、小規模な検証用アプリケーションで、生成AIが作ったコードが動作した割合です。コード変換の精度、工数削減率、大規模な本番システムの自動化率を示す数値ではありません。
AIツールを先に選ぶのではなく、刷新の目的、対象資産、評価基準、人の承認点を整理してから段階的に進めます。
保守期限への対応、運用費の削減、変更速度の向上、クラウド移行、データ活用など、優先する成果を明確にします。そのうえで、現行機能を「残す」「変える」「廃止する」に分けます。
ソースコードだけでなく、ジョブ、データベース、外部インターフェース、運用手順、障害履歴まで洗い出します。どの資産が、誰の、どの業務につながっているかを整理します。
ソースコードや顧客データを扱う場合は、外部送信、学習利用、保存期間、利用リージョン、アクセス権限、ログ管理の条件を確認します。
単純なプログラムだけでなく、複雑な業務ロジック、外部連携、例外処理を含む資産も一部選びます。実際の難所を含めることで、本番適用時の精度と作業量を判断しやすくなります。
仕様復元の正確性、専門家による修正量、ビルド成功率、テスト通過率、現行システムとの一致度、性能・セキュリティへの適合、レビューを含む総工数を確認します。
AIに任せる工程と、人が確認する工程を明確にします。コーディング規約、テスト方針、セキュリティ上の禁止事項、受入条件を文章にし、AIとレビュー担当者が同じ基準を参照できるようにします。
機能や業務単位で切り替え、問題が起きた場合に戻せる手順を用意します。データ移行の照合、並行稼働、監視、障害対応、生成物の説明、担当者への知識移管まで計画に含めます。
AIツールの名称だけで選ぶと、調査後の設計や本番移行を別会社へ引き継ぐことになり、責任範囲が曖昧になる場合があります。対応範囲と品質保証の方法まで比較してください。
自社に必要なのが仕様の可視化までなのか、コード変換までなのか、クラウドネイティブ化までなのかによって、適した会社は変わります。複数社へ同じ対象範囲と評価指標を提示し、調査から本番移行・運用までの責任範囲を比較することが大切です。
本記事では、生成AIで現行資産の解析・仕様復元・コード変換・テストを支援することと、移行後のシステムをAIが活用しやすい基盤へ刷新することの両方を含む取り組みとして整理しています。
生成AIだけで完結させるのは現実的ではありません。コードから読み取れない業務ルールや例外運用があるため、業務担当者と技術者による確認が必要です。目標構成、品質基準、本番切り替えの判断も人が担います。
ソースコードから仕様書のたたき台を作ったり、依存関係やデータの入出力を整理したりする用途で活用できます。ただし、生成結果は現行システムの挙動や有識者の知識と照合する必要があります。
利用環境と契約条件によって異なります。外部送信の有無、モデルの学習への利用、データの保存期間、利用リージョン、アクセス制御、操作ログ、専用環境の可否を事前に確認してください。
生成率だけでなく、仕様復元の正確性、専門家による修正量、ビルド成功率、テスト通過率、現行システムとの一致度、非機能要件への適合、レビューを含む総工数を確認します。
対応言語やAIツールだけでなく、現行分析の範囲、専門家による品質保証、セキュリティ条件、PoCの評価方法、本番切り替え、移行後の保守・運用まで比較してください。
AIモダナイゼーションは、レガシー資産の解析や変換を効率化しながら、将来のAI活用にも適したシステムへ刷新する取り組みです。ただし、AIが業務上の正しさや刷新の目的まで自動で決めてくれるわけではありません。まずは現行資産と課題を可視化し、限定したPoCで精度、修正工数、セキュリティ、費用対効果を確かめることが重要です。
仕様復元までを依頼するのか、クラウドネイティブ化や本番移行まで任せるのかによって、必要な支援会社は変わります。対象資産、目標、セキュリティ条件、PoCの評価指標をそろえ、複数社の提案を比較しましょう。
本メディアでは、マイグレーション・モダナイゼーションサービスの提供内容や対応領域を企業ごとに調査しています。AIを活用した現行分析、コード変換、クラウド移行など、自社の目的に合った支援会社の比較にご活用ください。
ここではマイグレーションサービスのプロジェクト実績が100件以上の信頼できる会社を厳選。その中で「レガシーシステムのオープン化」「AWSへの移行」「大規模システムの移行」という3つの目的別におすすめの会社を紹介します。
【選定基準】
「マイグレーションサービス」とGoogle検索し表示される10社のうち、公式HPでマイグレーションサービスの移行実績が100件以上の3社をピックアップしました。（2025年8月20日時点）
※1.2.参照元：FPTジャパンホールディングス公式HP（https://fptsoftware.jp/resource-center/connect/connect-legacy-modernization）2025年8月20日時点
※3.4.参照元：TIS公式HP（https://www.tis.jp/service_solution/aws/migration/）2025年8月20日時点
※5.参照元：日立製作所公式HP（https://www.hitachi-sis.co.jp/service/system/migration/index.html）