レガシーシステムの刷新にAI技術を活用することは有用だが、その能力を最大限に引き出すには準備が必要だ。刷新を阻む根深い課題と、それを乗り越えるための7つの基本アプローチを解説する。
レガシーシステムを抱える企業は、その維持にまとまった予算を費やすことを余儀なくされており、事業成長の機会を奪っている。レガシーシステムを扱う開発チームも、保守に時間を取られることで生産性に影響を受けているのが実情だ。
AI（人工知能）技術はこの問題を魔法のように解決するわけではないが、うまく活用すれば開発チームは恩恵を享受できる。チームの生産性を向上させるだけではなく、レガシーシステムの刷新のペースを加速させることも可能だ。
生成AIは、ソースコードやログの解析、安全なリファクタリング案の提示、テストコードの生成、システム移行の草案作成といった作業をこなす。もちろん、最終的な判断は人が下さなければならない。目標とするアーキテクチャを定め、システムの振る舞いを検証し、いつリリースするのかを決定するのは人の役割だ。本連載は、AI技術を活用してレガシーシステムの刷新を進めるための具体的な方法を紹介する。
レガシーシステムがもたらす問題は、ソースコード自体の問題と、それを取り巻く開発・実行環境の問題の2種類に大別できる。
改修を重ねた結果、レガシーシステムのソースコードは変更の影響範囲が分かりづらく、予期しない動作が発生しやすい状態になっている。1つの部品に役割を詰め込み過ぎていたり、古い技術に依存していたりすることもある。テストやドキュメントがほとんど整備されていない場合も珍しくない。
ソースコードを取り巻く開発・実行環境も問題の温床になりやすい。レガシーな開発環境の再現は難しく、デプロイ（本番環境への展開）作業が複雑で、失敗を招く。可観測性（オブザーバビリティ）に欠け、コンプライアンス（法令順守）やセキュリティ対策が遅れがちになる。これらの問題は、単にソースコードを修正するだけで解決できるほど単純ではない。適切な手法を選択しつつ、刷新プロジェクト中もSLA（サービス品質保証）を維持する必要がある。同時に潜在的なリスクを管理し、関係部門との連携を図ることが重要だ。
不安定なシステムを扱う上で難関な作業は、ソースコード、システム設定、データの変更を正しい順序で実行し、システムを常に稼働させ続けることだ。そのためには、システム刷新における明確な要件定義、変更前のテスト、作業の分割、確実なデータ移行が求められる。全てを作り直したいという誘惑に駆られてはならない。開発チームは、安全策（ガードレール）とロールバックの仕組みを用意した上で、事業に大きなリスクを負わせることなく、段階的に刷新作業を進めるべきだ。
レガシーシステムを動かすソースコードの刷新は、単なる書き換え計画にとどまらない。リスクを抑え、業務を改善し、新たな事業戦略を可能にするための経営判断に直結する。
まずは、既存のアプリケーションを仕分けることから始めるのが定石だ。現状のアプリケーションを棚卸しし、価値、維持費、技術、ビジネスリスクの観点から各アプリケーションを評価する。その上で、「刷新や機能強化を進める」「類似システムとまとめる」「現状を維持する」「廃止する」のいずれかに分類する。こうして整理したアプリケーション一覧を基に、開発チームは予算やスケジュール、システム移行の計画に合わせて、各アプリケーションに最適な刷新アプローチを決定する。
以下は、レガシーシステム刷新で用いられる代表的な7つのアプローチだ。
安定したAPI（アプリケーションプログラミングインタフェース）やイベント（システム内部の出来事を通知する仕組み）でレガシーシステムを包み込み、レガシーシステムの中核部分に手を加えることなく、その周辺に新しい機能を構築できるようにする手法だ。これによって、新しいシステムや開発者は古いシステムに直接触れる必要がなくなり、より抜本的にレガシーシステムを変更するための計画を練る時間を稼ぐことができる。新機能は外部に実装し、古い機能は徐々に縮小させていく「ストラングラー（絞め殺し）パターン」を用いた移行と相性が良い。
ソースコードの変更を最小限に抑え、システムを新しいインフラに移行する（リフト＆シフト）手法だ。データセンターで稼働している仮想マシン（VM）をクラウドサービスに移行するケースがこれに当たる。信頼性の向上、費用の透明化、定型業務の自動化といった効果をすぐに得られるが、レガシーなソースコードとアーキテクチャは古いまま残る。刷新のスピード優先で、大規模な変更が過度のリスクを伴う場合に有効な選択肢だ。
小規模で的を絞った変更を加え、コンテナやマネージドデータベースといった、よりモダンなサービスに移行する手法だ。アプリケーションの設計を大幅に変えることなく、運用性とスケーラビリティを改善できる。ソースコードの変更を最小限に抑えつつ、クラウドサービスの利点を迅速に享受できる中間策だと言える。
外部から見たシステムの振る舞いを変えずに、保守性を向上させるためにソースコードの内部構造を整理する手法だ。巨大なモジュール（プログラム部品のまとまり）の分割、テストの追加、不要なソースコードの削除、ライブラリの更新などがこれに当たる。ビジネスロジック自体には価値があるものの、ソースコードが古くなってしまった場合に効果を発揮する。
スケーラビリティや回復力、開発速度といった新たな品質目標を達成するため、システムの設計思想そのものを変更する手法だ。モノリシック（巨大な一枚岩的）な構造から、それぞれの責任が明確なサービスの集合に移行したり、イベント駆動型アーキテクチャを採用したりすることが代表例だ。設計の観点からシステム刷新を主導するアプローチであり、長期的な俊敏性（アジリティ）を大きく引き出すことに期待できる。
特定の範囲と中核的な振る舞いを維持したまま、アプリケーションを一から書き直す手法だ。技術の選定やテスト手法を白紙の状態から検討できるため、開発速度を大幅に向上させることができる可能性がある。現在の実装がシステム修正の妨げになっている一方で、根幹にあるビジネスロジックが業務の現状と合致している場合に適する。
自社開発のシステムを廃止し、市販の製品やSaaS（Software as a Service）を導入する手法だ。必要な機能を備える製品やサービスが存在する場合、自社開発システムを運用するよりも費用とリスクを継続的に削減できる。人事、財務、CRM（顧客関係管理）といった汎用（はんよう）的な業務を実施するシステムに適している。ただし、システムのカスタマイズは限定的になるため、導入前に機能の適合性や既存システムとの連携性を十分に検証する必要がある。
これらのアプローチは、互いに排他的なものではない。まずカプセル化を実施してリスクを分散し、次にリホストやリプラットフォームで運用を安定させる。その後、特定の範囲を対象にリファクタリングやリアーキテクトを実施する。準備が整った段階で、再構築やリプレースに移行する。どのアプローチをどの順序で進めるかは、リスク許容度、人材の有無、DXの緊急性によってさまざまだ。
次回は、AI技術を活用した具体的な刷新方法と、その際の注意点を紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか
メインフレームを支える人材の高齢化が進み、企業の基幹IT運用に大きなリスクが迫っている。一方で、メインフレームは再評価の時を迎えている。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
