アマゾン ウェブ サービス ジャパン（AWSジャパン）は2026年10月6日、公式ブログで「AI Modernization Flow（AIMF）」を公開したと発表した。古い技術スタックで動くシステムの移行作業を、KiroやClaude CodeといったAIエージェントに決められた手順で進めさせるためのワークフローである。AWS SamplesとしてGitHubで公開されており、誰でも手元のコードで試せる。
AWSジャパンは、AIを使ってアプリケーションのモダナイゼーションを進める取り組みを「AI-Driven Modernization」と呼んでいる。従来は過大な工数やコストで断念していた移行をAIで実現することを目指し、AIMFはその中核ツールに位置付けられる。
「移行して」と頼むだけでは足りない、サイレント障害と説明不能な判断
公式ブログは、コーディングエージェントに「このアプリをJava 21に移行して」と頼めばそれらしいコードは返ってくると述べる。しかし顧客と試す中で、ビルドもテストも通ったのに一部の機能が動かない、AIが移行先で機能を勝手に削る、なぜこの実装にしたのか後から誰も説明できない、といった問題を繰り返し見てきたという。作業の品質が担当者の移行スキルに左右されることも分かった。
なかでも見つけにくいのが、エラーを出さずに機能が失われるサイレント障害である。ブログでは、Webフレームワークの「Struts」を7系に上げた際、新しく既定で有効になったセキュリティ設定のために画面の値が空になった例を挙げている。例外は出ず、HTTPステータスは200で、単体テストもすべて成功していたが、検出には人による画面操作や自動E2Eテストの追加が必要だった。
AIMFは、移行プロジェクトの進め方とAIに守らせる作業規律を「型」としてエージェントに与える。これにより、使う人のスキルに左右されずに一定の品質で移行作業を進められるようにすることを狙う。
分析から最終確認まで6段階、人が判断すべき場面で止まる
AIMFは移行作業を6つのPhaseで進める。Phase 0aで現行コードの構成と技術的負債を分析し、Phase 0bで移行先候補と規模・リスクをまとめて方針を決める。Phase 1で現新比較の方式と非機能要件の範囲を決め、Phase 2で作業計画と成功基準を確定する。Phase 3で段階的に移行しながら検証し、Phase 4で全機能を別の視点からも確かめる。
開始時に必要な情報は対象ソースコードの場所だけである。Phase 0aの分析にはAWS Transform customを使い、Phase 0bで止めれば移行先候補の比較、概算規模、主要なリスク、方針案が得られる。まずアセスメントだけを行い、移行に着手するかどうかや予算を判断する使い方ができる。
人の判断が必要な場面は、後戻りのコストに応じて3段階に分けている。ユニット内部の実装は検証が通ればAIがそのまま進める。一方、インターフェースやデータ形式の変更、機能の除外、Phaseの境界では、AIが作業を止めて選択肢と影響を示し、人の判断を求める。止まるかどうかはAI自身ではなく、あらかじめ決めた条件で判定する。
完了は検証スクリプトで判定、判断はADRとして記録
各工程の完了は、実際の動作結果で判定する。ビルドが成功しただけでは完了とせず、アプリケーションを動かして自動テストで動作を確かめた時点で完了とする。文章で書いたルールはAIが「守りました」と自己申告するだけで通ってしまうことがあるため、守らせたい規律はできるだけ検証スクリプトに置き換えているという。
設計判断はADR（Architecture Decision Record）として記録される。「なぜこの技術を選んだか」「なぜこの機能を対象外にしたか」を後から確認できる。作業内容はworklogに、現在の状態はsession-contextに記録され、担当者が交代しても、エージェントが途中で終了しても作業を再開できる。
構成は、移行の進め方を定めるMethod、移行ドメインごとの知見をまとめたPlaybook、AIに守らせる規律を実装したHarnessの3層である。Playbookは現時点で、Java 8/11からJava 21・Jakarta EEへのモダナイゼーション、.NET Frameworkからモダン.NETへの移行、C言語のSolaris x86からAmazon Linuxへの移植の3種類が用意されている。
Apache Roller約15万行を4日間で移行、保留項目もADRに残す
公式ブログは、OSSのブログ用CMS「Apache Roller」を移行した例を紹介している。Java 11、Java EE（javax）、Struts 2.5、Spring 5で構成された約15万行のアプリケーションを、Java 21、Jakarta EE 10、Struts 7、Spring 6、PostgreSQL 17の構成へ移行した。分析から最終確認までにかかった期間は、人とのやり取りを含めて4日間で、作業時間は日中のみだった。
移行完了報告には、成功基準ごとの確認方法と結果が記載される。既存の単体テストは157件が成功し、OAuth 1.0の除去に伴い1件を正当に減らした。javaxからjakartaへの全面移行は検証スクリプトで残存0件を確認し、主要画面はブラウザ操作のE2Eテストでユーザー登録からコメントまでを確認した。性能やリソースリーク、耐障害性は移行後の独立したタスクとして延期し、その判断はADRに記録された。
対応しているコーディングエージェントは現時点でKiroとClaude Codeである。ワークスペースでリポジトリをクローンしてインストールスクリプトを実行すると、エージェント用のルールと作業記録用のリポジトリが準備される。あとはエージェントにソースコードの場所を伝えて「Phase 0aからアセスメントを開始して」と指示すればよい。
企業への示唆
保守期限が迫るJavaや.NET Frameworkのシステムを抱える企業にとって、まず試す価値があるのはPhase 0のアセスメントである。公式ブログによれば、内部で使うAWS Transform customの分析は数十万行のコードでも1〜2時間程度で結果が出る。現行システムの技術的負債と移行規模が分かるため、移行計画や予算を検討する材料として使える。移行の着手判断とは切り離して、まず現状把握だけを行う使い方が現実的だ。
一方で、AWSジャパン自身がAIMFを「最適なモダナイゼーションが自動で完成する魔法の道具ではない」と明記している点は重く受け止めたい。移行先の技術スタックが自社に適切か、その後も保守し続けられるかは、アプリケーション開発の知識を持つ人が判断する必要がある。既存システムに詳しい担当者と新しい技術スタックに詳しいエンジニアが一緒に判断する体制が前提であり、内製チームかSIパートナーのどちらで担うかを先に決めておく必要がある。
また、AIMFの対象はアプリケーション自体の移行であり、クラウド環境の設計と構築は対象外である。従来のテストが手動中心だった場合、移行自体が速くても受け入れテストに時間がかかり効果が限定される点も指摘されている。E2Eテストの自動化をどこまで進めるかを、移行計画と並行して検討しておきたい。
ITトレンドでAIエージェントについてチェック！[【2026年最新】AIエージェント徹底比較！タイプ別おすすめツールと選び方ガイド]
Claude Codeの動向はこちらもチェック！[Claude Code、処理速度2.5倍の「高速モード」を提供開始――コスト増でも速さを選べる選択肢]
まとめ
AWSジャパンは2026年10月6日、AIエージェントに規律ある移行作業をさせる「AI Modernization Flow」をAWS SamplesとしてGitHubに公開した。移行を6つのPhaseで進め、人が判断すべき場面で止まり、完了を検証スクリプトで判定し、判断をADRに記録する点が特徴である。対応エージェントはKiroとClaude Codeで、Java、.NET、C言語の3つのPlaybookが用意されている。
約15万行のApache Rollerを4日間で移行した例が示されたが、AWSジャパンは自動で最適な移行が完成する道具ではないと強調している。まずPhase 0のアセスメントで現状を把握し、人が判断する体制と受け入れテストの自動化を整えたうえで、本格的なPoCや移行計画に進むのが現実的な使い方となる。
