[AI-Driven Modernization] AIエージェントに規律ある移行作業をさせる「AI Modernization Flow」を公開しました

みなさんこんにちは。ソリューションアーキテクトの大村です。

AWS Japanでは、AIを使ってアプリケーションのモダナイゼーションを進める取り組みを「AI-Driven Modernization」と呼び、お客様やパートナーの皆様と一緒に進めています。このブログでは、AI-Driven Modernizationの考え方と、その中核となるツールとしてAWS Samplesに公開した「AI Modernization Flow（AIMF）」をご紹介します。

AI Modernization Flowは、古い技術スタックで動いているシステムの移行作業を、KiroやClaude CodeといったAIエージェントに決められた手順で進めさせるためのワークフローです。

GitHubで公開しており（ https://github.com/aws-samples/sample-ai-modernization-flow ）、どなたでも手元のコードで試せます。

AI-Driven Modernizationとは

モダナイゼーションという言葉が指す範囲は広く、インフラのクラウド移行を指すこともあれば、業務の見直しを指すこともあります。私たちはAI-Driven Modernizationを「従来は過大な工数やコストで断念していたアプリケーションのモダナイゼーションをAIによって実現すること」と定義しています。

10年、20年と稼働してきた業務システムでは、言語ランタイムやフレームワーク、ライブラリが古くなっていきます。サポートが終了した技術スタックを使い続けると、保守できる人材の確保が難しくなり、変更のたびに時間とコストが膨らみます。それでもアプリケーションの改修を伴う移行は大がかりな開発プロジェクトになるため、多くのシステムで後回しにされてきました。

この前提が、AIによって変わりつつあります。人が数ヶ月かけていたコード解析も、AIなら数時間です。存在しない、あるいは古くなったドキュメントやテストも、AIがコードから作れます。これまで費用対効果が合わずに見送ってきた移行も、AIを使えば現実的な選択肢になります。

2つのアプローチ：RefactorとReimagine

AI-Driven Modernizationでは、移行のゴールに応じて2つのアプローチを使い分けます。

Refactor（技術スタックの最新化）：ビジネスロジックは変えずに、言語ランタイムやフレームワーク、ライブラリを新しくします。AIエージェントが既存コードを分析し、変換と検証を進めます。
Reimagine（再構築）：AIエージェントが既存コードから仕様書を起こし、その仕様をもとに新しいアーキテクチャで作り直します。

どちらの場合も、移行後に業務が同じように動くことを確かめる受け入れテストが欠かせません。この受け入れテストの自動化にもAIを使います。

今回公開したAI Modernization Flow は、このうちRefactorを担うツールです。

AIに「移行して」と頼むだけでは何が足りないのか

コーディングエージェントに「このアプリをJava 21に移行して」と頼めば、それらしいコードは返ってきます。しかし、私たちがお客様と一緒に試す中で、ビルドもテストも通ったのに一部の機能が動かない、AIが移行先で機能を勝手に削る、なぜこの実装にしたのか後から誰も説明できない、といった問題を繰り返し見てきました。作業の品質が担当者の移行スキルに大きく左右されることも分かりました。

なかでも見つけにくいのが、エラーを出さずに機能が失われる不具合（サイレント障害）です。たとえばWebフレームワークのStrutsを7系に上げたところ、新しく既定で有効になったセキュリティ設定のために、画面に表示されるはずの値が空になりました。例外は出ず、HTTPのステータスは200で、単体テストもすべて成功していましたが、実際は正しい実装を行えておらず、この検出には人による画面操作や自動E2Eテストの追加が必要でした。

このように、AIを活用した移行プロジェクトを成功させるには、AIに変換させる技術に加えて、移行プロジェクトの進め方を知っていることが必要です。両方の知見を持つ人はまだ多くありません。AI Modernization Flowは、移行プロジェクトの進め方とAIに守らせる作業規律を「型」としてAIエージェントに与え、使う人のスキルに左右されずに一定の品質で移行作業を進められるようにします。

AI Modernization Flow (AIMF) の特徴

分析から最終確認までをAIがガイドする

AIMFは、移行作業を6つの段階(Phase)で進めます。

Phase 0a	分析	現行コードから構成を把握し、技術的負債を分析する
Phase 0b	移行判断の材料	移行先の候補と規模・リスクをまとめ、移行方針を決める
Phase 1	準備	現新比較の方式を決定し、非機能要件の検討範囲を決める
Phase 2	計画	作業計画を作り、成功基準を確定する
Phase 3	実施	作業計画に従って段階的に移行し、段階ごとに検証する
Phase 4	最終確認	全機能を検証し、別の視点からも確かめる

開始時に必要な情報は、対象のソースコードの場所だけです。移行先の技術スタックは、事前に指定することも、現行システムを分析した結果を見てから決めることもできます。Phase 0aの分析にはAWS Transform customを使います。複数のサブシステムのリポジトリを並列に分析した場合は Phase 0b で結果を統合することが可能です。

作業は途中で止めることもできます。Phase 0bで止めれば、移行先の候補と比較、概算規模、主要なリスク、移行方針の案が得られます。まずアセスメントだけを行い、移行に着手するかどうかや予算を判断する、という使い方ができます。

人が判断すべき場面で止まる

AIの判断をすべて人がレビューすると、承認待ちばかりで作業が進みません。AIMFは、後戻りにかかるコストに応じて判断を3段階に分けています。ユニット内部の実装は、検証が通ればAIがそのまま進めます。インターフェースやデータ形式の変更、機能の除外、Phaseの境界では、AIが作業を止めて選択肢と影響を示し、人の判断を求めます。止まるかどうかは、AI自身ではなく、あらかじめ決めた条件で判定します。

人に意思決定を求めるのは、ドメイン知識を伝承するための仕組みでもあります。移行をすべてAIに任せると、移行の過程で今後の保守担当者に業務の知識を引き継ぐ機会も失われます。既存システムに詳しい担当者と新しい技術スタックに詳しいエンジニアが一緒に判断し、その理由をADRに残すことで、知識は移行後の保守へ引き継がれます。

作業完了は検証スクリプトによるテストで判定する

各工程の完了は、実際の動作の結果を確認して判定します。例えばビルドが成功しただけでは完了とせず、アプリケーションを動かして自動テストによって動作を確かめた時点で完了とします。

文章で書いたルールは、AIが「守りました」と自己申告するだけで通ってしまうことがあります。そこでAIMFは、守らせたい規律をできるだけ検証スクリプトに置き換えています。先ほど例に出したサイレント障害に対しては、手を入れるべき箇所を台帳にまとめて未対応をゼロにすることと、利用者の操作の流れをブラウザで再現するテストを、完了の条件にしています。

判断と知見と作業内容を記録に残す

AIMFは、設計判断をADR（Architecture Decision Record）として記録します。「なぜこの技術を選んだか」「なぜこの機能を対象外にしたか」を後から確認できます。作業中に得られた知見をプラクティスとして記録し、以後の作業に活用します。作業内容の記録はworklogに、現在の作業状態はsession-contextに記録します。担当者が交代しても、日をまたいでも、またエージェントが途中で終了してしまった場合でも作業を再開できます。

3層の構成

AIMFは、移行の進め方を定めるMethod、移行ドメインごとの知見をまとめたPlaybook、AIに守らせる作業規律を実装したHarnessの3層でできています。Playbookは現在、次の3つを用意しています。

Javaモダナイゼーション（Java 8/11、javax名前空間からJava 21、Jakarta EEへ）
.NET Frameworkからモダン .NETへ
C言語のSolaris x86からAmazon Linuxへの移植

新しい移行ドメインに使う場合は、MethodとHarnessはそのままで、Playbookだけを追加します。お客様の開発標準や過去の移行で得た知見をPlaybookに加えていくほど、次の移行の質が上がります。

実際の移行記録から

AIMFを使うと、移行したコードとは別に、何を判断し、何を検証したかの記録が残ります。OSSのアプリケーションを移行した例を紹介します。

Apache Roller（Java）

Apache Rollerは、Javaで書かれたオープンソースのブログ用CMSです。Java 11、Java EE（javax）、Struts 2.5、Spring 5で構成された約15万行のアプリケーションを、Java 21、Jakarta EE 10、Struts 7、Spring 6、PostgreSQL 17の構成へ移行しました。分析から最終確認までにかかったのは、人とのやり取りを含めて4日間でした。作業時間は日中のみです。

移行の終わりに、AIは画像にあるような移行完了報告を作成します。表はその一部で、作業計画で決めた成功基準ごとに、何で確かめたかが書かれています。

成功基準	確認方法と結果
既存の単体テスト	157件成功。OAuth 1.0の除去に伴い1件を正当に減らした
javaxからjakartaへの全面移行	検証スクリプトで残存0件を確認
主要画面の動作	ブラウザ操作のE2Eテストで、ユーザー登録、ログイン、ブログ作成、記事投稿、画像のアップロード、コメントまでを確認
セキュリティ既定値によるサイレント障害がないこと	実際に見つかった複数の障害を修正し、再発を検出する検証スクリプトを追加
性能・リソースリーク・耐障害性	移行後の独立したタスクとして延期（人が判断し、ADRに記録）

報告には、完了した項目だけでなく、対応を保留した項目とその理由も書かれています。この場合は、メンテナンスが終了したXML-RPCやOpenIDといった古いプロトコルについては、AIが選択肢と影響を示し、人が「恒久的に除去する」と判断した経緯がADRに残りました。

これらの移行完了報告やADRは、お客様やプロジェクトの関係者に「何を判断し、どこまで確かめたか」を説明する材料として使えます。

AIMFでできること・できないこと

AIMFが向いているのは、ビジネスロジックを変えずに古くなった技術スタックを更新する移行(Refactor)です。既存コードを使わずに新しい言語やアーキテクチャで作り直す場合は、既存コードから仕様を生成して再開発を行うReimagineのアプローチが適しています。

Refactor型アプローチでは基本的にビジネスロジックを変更しないため、従来と同様のテストを行うことで品質を確認します。一方で、従来のテストが手動であった場合、移行作業自体がAIによって迅速に行えても、テストに多大な時間や工数を要してしまい、その効果が限定的になる場合があります。この課題を解決する方法としてWeb画面を操作する受入れテストを、Playwrightで自動化することが考えられます。

Reimagineの際のAIによる仕様生成、受け入れテストの自動化 (UAT Automation) についてはAWS担当営業へご相談ください。

現在のAIMFは、アプリケーション自体の移行を対象にしています。アプリケーションを稼働させるクラウド環境の設計と構築は、AIMFの対象外です。

ただし、クラウドへ移すときには、アプリケーション側の修正が必要になることがあります。たとえば、オンプレミスで動いていたWebアプリケーションをAmazon CloudFrontやApplication Load Balancerの配下で動かす場合、アプリケーションが出力するURLのパスや、セッション管理の仕組みを見直す必要があるかもしれません。こうした修正はAIMFのフローに明示されていませんが、アプリケーションの移行が完了した後に、クラウド環境に合わせた設計と修正をAIエージェントに指示すれば進められます。

性能試験や障害試験を行うかどうかは、Phase1で決める非機能要件の範囲によって変わります。性能や耐障害性を対象にすれば、その検証もAIMFの完了条件に加わります。ただし、本番に近い条件で性能や耐障害性を確かめるには、移行先のインフラ構成が決まっている必要があります。そのため、インフラの設計と合わせて、アプリケーション移行後のフェーズで計画するのがお勧めです。

AIMFは、使えば最適なモダナイゼーションが自動で完成する魔法の道具ではありません。AIの推奨に従えば動くものはできますが、その技術スタックがお客様のシステムにとって適切かどうか、その後もメンテナンスし続けられるかどうかは、アプリケーション開発の知識を持つ人が判断する必要があります。モダナイゼーションを実際に進めるには、プロジェクトとしての体制と予算も必要です。お客様の内製チーム、あるいはSIパートナーと一緒に進める体制を前提としています。

よくいただく質問

Q. オンプレミスで動いているシステムにも使えますか。
A. 使えます。AIMFはソースコードを分析して移行するため、現在の稼働環境は問いません。

Q. 社内の開発標準やコーディング規約を守らせられますか。
A. 守らせられます。規約や命名規則をMarkdownのファイルとして所定の場所に置くと、AIが参照しながら作業します。確実にルールを守らせるにはLint等を併用するよう指示してください。

Q. 移行後の品質を、お客様や社内にどう説明すればよいですか。
A. AIMFの作業内容については、移行完了報告、ADR、検証結果などが説明の材料になります。しかし移行したシステムの品質は、適切なテストを行うことでしか保証はできません。AIMFの中では実装にあたってのベースラインとして現行システムと新システムの動作比較（現新比較）テストの方針を確認し、その範囲でテストを計画・実施して作業を行います。それ以外の必要なテストについてはAIMFとは別に検討、実施が必要です。

Q. すぐに移行する予定はありませんが、何から始めればよいですか。
A. Phase 0のアセスメントのみの実行から始めるのがお勧めです。内部で使用しているAWS Transform custom の comprehensive code analysisによる分析は数十万行のコードでも1-2時間程度で結果が出ます。現行システムの技術的負債と移行の規模感が分かり、移行計画や予算を検討する材料になります。

利用方法

現時点で対応しているコーディングエージェントはKiroとClaude Codeです。ワークスペース（移行対象のソースコードを置くディレクトリの親）で次のコマンドを実行すると、AIエージェント用のルールと作業記録用のリポジトリが準備されます。

cd /path/to/workspace
git clone https://github.com/aws-samples/sample-ai-modernization-flow.git
./sample-ai-modernization-flow/install.sh --project myapp-1.0 ¥
   --playbook java-modernization --lang ja

あとはワークスペースでAIエージェントを起動し、ソースコードの場所を伝えて「Phase 0aからアセスメントを開始して」と指示します。プロジェクトの情報はAIが起動時のインタビューとソースコードの読み取りで埋めるので、設定ファイルを手で書く必要はありません。

ドキュメントは読者に合わせて用意しています。AIMFの考え方を知りたい方は「基本コンセプト」、全体像を知りたい方は「かんたん解説」から、実際に使う方は「使い方」からお読みください。

AWSと一緒に AI-Driven Modernization を始めましょう

このブログでは、AWS Japanが取り組むAI-Driven Modernizationと、技術スタックの更新を行うツールとしてAI Modernization Flowをご紹介しました。

AI Modernization Flow を実際に使うと、AIを使ったモダナイゼーションの進め方を具体的に体験できます。まずお手元のコードのアセスメントや移行方針の検討にご利用ください。そして一度AIMFを使って移行作業を行ってみてください。AIを使えばモダナイゼーションの作業は多大な時間と工数を要する一本道の作業ではなくなります。一度移行作業を試して知見をPlaybookに溜めた後、もう一度同じコードに対して移行作業を行っても良いのです。そうして得られた知見をもとに、本格的なPoCや、移行計画の立案に取り組んでみてください。

AWS Japanでは、AI-Driven Modernizationを進めるためのご相談を受け付けています。Refactor型モダナイゼーションではAIMFを使ったアセスメントおよびPoCを、そしてReimagineや受け入れテストの自動化についてもご相談いただけます。

保守期限が迫っているシステムがある、移行したいが規模が読めない、AIでどこまでできるのか試してみたい、といった方は、ぜひAWSの担当営業またはソリューションアーキテクトにご相談ください。SIパートナーの皆様からのご相談も歓迎します。

What’s next

AIMFはお客様からのフィードバックをもとに、Playbookの拡充やフローの改善を続けていきます。AIモデルの進化に合わせてフローも変わっていくため、利用する際はGitHubで最新の安定版をご確認ください。

ぜひ手元のコードで試してみてください。GitHubのIssue、またはAWSの担当者までフィードバックをお寄せください。

著者：大村幸敬（AWS Japan, Manager, Specialist Solutions Architect）

Amazon Web Services ブログ