技術的負債は、放置すれば利息のように膨らみ続けます。とくに生成AIによるコーディングが普及し、変更のペースが上がるほど、古い依存関係や非推奨フレームワークが残ったまま新しいコードが積み上がり、負債の蓄積が加速しやすくなります。こうした課題に対して、AWSは「AWS Transform – 継続的モダナイズ（Continuous Modernization、プレビュー）」を発表しました。技術的負債の検出と修正を、周期的なプロジェクトから常時稼働の自律プラクティスへと転換する新機能です。
本記事では、AWS Transform 全体の位置づけ、継続的モダナイズの仕組み、検出・解消の具体的アプローチ、プレビュー段階の制限事項、そして開発リーダーやアーキテクトが検討できる観点を、AWS News Blog（2026年6月17日公開）とFAQ・料金ページなどの一次情報をもとに整理します。
AWS Transformとは何か、従来のモダナイズアプローチとの違い
AWS Transform は、専門エージェントに支えられた協調型のエンタープライズIT トランスフォーメーション・ワークベンチとして位置づけられています。クラウド移行、アプリケーションモダナイズ、技術的負債管理を対象とし、変換タイプごとに専門エージェントを備えている点が特徴です。共有ワークスペースと自然言語チャットを通じて、チームでの協働作業を前提に設計されています。
対象とするワークロードは幅広く、VMware やベアメタルなどのインフラ、メインフレームや Windows アプリケーション、.NET と SQL Server を含むフルスタック Windows、さらに任意の言語・フレームワーク・組織固有のプログラミングパターンを扱うカスタムコード変換まで及びます。沿革としては、2025年12月に組織全体のモダナイズを加速する「AWS Transform custom」が発表され、それ以前から .NET モダナイズ向けの提供も行われてきました。
従来のモダナイズは、手動でのコードリライトや単発のマイグレーションプロジェクトが中心でした。プロジェクト期間中は負債を解消できても、終了した瞬間から再び負債は溜まり始めます。継続的モダナイズは、この「断続的なパッチ当て」から「ポートフォリオの継続的なモダナイズ」へと発想を切り替える点が、これまでのアプローチとの大きな違いです。
継続的モダナイズの仕組みと自律化の流れ
継続的モダナイズは、AWS の公式定義では大規模に継続的・自律的な技術的負債の分析と修正を行う新機能とされています。コード変換を周期的なプロジェクトとして扱うのではなく、常時稼働の自律的なプラクティスへと転換し、開発パイプラインを CI/CD から CM（Continuous Modernization）へと発展させる構想です。ワークフローは大きく2段階で構成されます。
第1段階は継続的分析です。コードリポジトリを設定可能なベースラインに照らして自動的にスキャンし、findings を生成します。AWS の主張によると、この分析は数週間ではなく数時間で完了し、コードから直接得られる ground truth にもとづいて、技術的負債の状況を常に最新のビューで可視化できるとされています。第2段階は自律的修正です。findings を特定し優先順位を付けたうえで自律修正を設定すると、影響を受ける各リポジトリに対して自動でPull Request が作成され、所有チームへ通知が届きます。チームはそのPR をレビューしてマージするか、自分たちの方法で修正するかを選べます。
この仕組みにより、ステータスの逐次確認や手動でのコンプライアンス追跡が不要になります。プラットフォームチームは、個別の進捗を追いかけることなく、技術的負債の全体像を常時把握できるようになります。修正の最終判断はあくまで所有チームに委ねられているため、自律化と人間によるコントロールのバランスが取られている点も実務上は重要です。
技術的負債をプロアクティブに検出・解消する具体的アプローチ
検出の面では、標準提供のポリシーで複数の負債を洗い出します。具体的には、End of life（EOL）に達した依存関係、非推奨フレームワーク、そして AWS Security Agent との連携を通じたセキュリティ脆弱性が対象です。さらに、非推奨ライブラリやコーディング標準といった組織固有のカスタムパターンも定義でき、自社の事情に合わせた検出が可能です。
技術的負債分析は、FAQ によると comprehensive、quick、security、agentic readiness、modernization readiness の5種類が用意されています。これらは AWS の FAQ に記載された分類であり、用途に応じて使い分ける想定です。分析結果はHTML レポートとして出力でき、EventBridge を用いることで分析を定期的にスケジュール実行できます。これにより、負債の発生を待ってから対処するのではなく、プロアクティブに状況を把握し続けられます。
解消の面では、標準の修正トランスフォーメーションとしてJava のバージョンアップグレード、SDK マイグレーション、ライブラリアップデートが提供されます。加えて、組織固有のパターンに向けたカスタムトランスフォーメーションも作成できます。検出から優先順位付け、そして自動でのPull Request 作成までを一連の流れで扱えるため、技術的負債を見つけて終わりにせず、実際の修正提案まで自律的につなげられる点がこのアプローチの核心です。
プレビュー段階での主要機能と制限事項、対象環境
アクセス手段は複数用意されています。AWS Transform Web アプリケーション、AWS Transform Kiro Power、MCP およびコーディングエージェント連携用の skills、そして CLI です。接続元としては GitHub およびローカル環境が言及されており、既存の開発フローへ組み込みやすい構成になっています。対応するランタイムの例としては、FAQ に Java 8 から21、Python 3.9 から3.12、Node.js 18 から22、AWS SDK v1 から v2 などが挙げられています。ただし、継続的モダナイズの標準修正として明示されているのは Java のバージョンアップや SDK マイグレーション、ライブラリ更新であり、ランタイム例は AWS Transform 全体のものとして捉えるのが正確です。
料金については、プレビュー中は分析・修正の実行が AWS Transform custom の agent-minute 相当で課金されます。参考単価は1分あたり0.035ドルで、最小課金単位は1分、サーバーサイドの実働のみが課金対象です。GA 時には別料金を発表する予定とされています。
注意したいのは、未公表の事項を断定しないことです。継続的モダナイズの対応リージョンは、公式ブログ・FAQ・料金ページのいずれにも明記されておらず、現時点で公式に明示されていません。GA の時期も同様に未公表です。また、各種の効果数値はあくまで AWS Transform 全般や第三者事例として発表されたものであり、本機能固有の検証値ではありません。導入を検討する際は、これらを本機能の保証値とみなさず、プレビューならではの仕様変更の可能性も織り込んでおくことが大切です。
活用シーンとRagateとして検討できる観点
活用シーンとしては、まずレガシーランタイムの継続的な更新が挙げられます。Java や Python、Node.js のバージョンアップ、EOL に達した依存関係や非推奨フレームワークの解消を、Pull Request という形で継続的に提案させられます。次に、AWS Security Agent 連携によるセキュリティ負債の継続的な解消です。脆弱性を一度きりの棚卸しではなく、常時のプラクティスとして扱えます。さらに、AI コーディングエージェントが変更ペースを上げるほど技術的負債が速く蓄積するという課題に対し、検出・優先順位付け・修正を継続的かつ大規模に回せる点も大きな価値です。
Ragate はクラウド移行・モダナイズや AX、デジタル PMI などを支援する立場です。継続的モダナイズの「技術的負債を常時可視化し、自律的に修正提案まで進める」という考え方は、顧客への提案や社内開発の両面で検討の余地があります。たとえば、移行後に負債が再び溜まりやすい局面で、継続的分析を定期実行して状況を見える化し、修正提案の取捨選択を支援するといった関与の仕方が考えられます。現時点ではプレビュー段階であり、対応リージョンや GA 時期も未公表のため、まずは小さく検証しながら適用範囲を見極める進め方が現実的でしょう。
技術的負債は、解消した後も再び蓄積し続けるものです。だからこそ、単発のプロジェクトではなく継続的なプラクティスとして扱う発想が求められます。継続的モダナイズはその方向性を体現する機能であり、プレビューの制限事項を正しく理解したうえで、自社の負債管理にどう組み込めるかを検討する価値は十分にあります。
