AWS Transform カスタムのご紹介：AI 活用によるコードモダナイゼーションで技術的負債を解消

技術的負債は、今日のエンタープライズ開発チームが直面する最も根強い課題の一つです。調査によると、企業は本来であれば新たな機能拡張に充てられるはずの IT 予算の 20％を、技術的負債への対応に費やしています。レガシーフレームワークのアップグレード、新しいランタイムバージョンへの移行、古いコードパターンのリファクタリングなど、こうした不可欠ながら反復的な作業は、本来であればイノベーションに充てられる貴重な開発者の時間を消費してしまいます。

2025 年 12 月 1 日、組織が大規模なモダナイゼーションに取り組む方法を根本的に変える新しいエージェント AWS Transform Custom を発表できたことをうれしく思います。このインテリジェントエージェントは、Java、Node.js、Python のアップグレード向けにあらかじめ用意された変換機能と、独自の変換を定義できる柔軟性を組み合わせています。特定の変換パターンを学習し、それをコードベース全体にわたって自動化することで、AWS Transform Custom を利用するお客様は、実行時間を最大 80% 削減したケースもあり、開発者はよりイノベーションに集中できるようになります。

ドキュメント、自然言語での説明、コードサンプルを利用して、独自の変換を定義できます。その後、サービスはこれらの特定パターンを数百から数千のリポジトリにわたり一貫して適用し、明示的なフィードバックだけでなく、変換プロジェクト内で開発者が行う手動修正といった暗黙的なシグナルも取り込みながら、その精度を高めていきます。

AWS Transform Custom は、さまざまなモダナイゼーションのニーズに対応できるよう、CLI と Web の両方のインターフェースを提供しています。CLI を利用すると、自然言語での対話を通じて変換を定義し、ローカルのコードベースに対してインタラクティブまたは自律的に実行できます。また、コードモダナイゼーションのパイプラインやワークフローに統合することもでき、機械駆動の自動化に最適です。一方、Web インターフェースは包括的なキャンペーン管理機能を提供し、チームが複数のリポジトリにわたる変換の進捗を大規模に追跡・調整できるよう支援します。

言語およびフレームワークのモダナイゼーション
AWS Transform は、追加情報を提供する必要なくランタイムのアップグレードをサポートします。単に必要な構文の変更だけでなく、新しいバージョンに伴う微妙な動作の違いや最適化の機会も理解しています。同じインテリジェントなアプローチは、Node.js、Python、Java のランタイムアップグレードにも適用され、さらに x86 プロセッサから AWS Graviton へのワークロード移行など、インフラレベルの移行にも拡張されます。

また、フレームワークのモダナイゼーションも高度にサポートします。組織が Spring Boot アプリケーションを最新の機能やセキュリティパッチに対応させる必要がある場合、AWS Transform Custom は単にバージョン番号を更新するだけでなく、依存関係の変更、設定の更新、API の変更が連鎖的に及ぼす影響まで理解します。

Angular から React への移行のような大規模な変化に直面しているチームに対しても、AWS Transform Custom は、コンポーネントの変換パターン、状態管理の変換、ルーティングロジックの変換など、移行を成功させるためのパターンを学習できます。

インフラおよびエンタープライズ規模の変革
クラウド環境ではサービスが常に進化しているため、API や SDK の変化に対応する課題は特に深刻になります。AWS Transform Custom は、Java、Python、JavaScript など、企業で使用される幅広いプログラミング言語における AWS SDK の更新をサポートします。このサービスは、API 変更の機械的な側面だけでなく、新しい SDK バージョンで利用可能なベストプラクティスや最適化の機会も把握しています。

コードとしてのインフラストラクチャの変換は、特に組織がさまざまなツール戦略を評価する際に、もう一つの重要な機能です。標準化を目的として AWS Cloud Development Kit (AWS CDK) のテンプレートを Terraform に変換する場合や、新しいサービス機能に対応するために AWS CloudFormationの設定を更新する場合でも、AWS Transform Custom はこれらのツールの宣言的な性質を理解し、インフラ定義の意図と構造を維持できます。

これらの一般的なシナリオに加え、AWS Transform カスタムは、長年の開発で蓄積された組織固有のコードパターンにも優れた対応力を発揮します。すべての企業には、それぞれ独自のアーキテクチャ規約、ユーティリティライブラリ、コーディング標準があり、これらは時間とともに進化させる必要があります。これらのカスタムパターンを学習し、体系的にリファクタリングを支援することで、組織の知見とベストプラクティスがアプリケーションポートフォリオ全体に一貫して適用されるようにします。

AWS Transform カスタムは、エンタープライズ開発のワークフローを考慮して設計されており、センターオブエクセレンスチームやシステムインテグレーターが組織全体の変換を定義・実行できる一方で、アプリケーション開発者は変換されたコードのレビューや統合に専念できます。その後、DevOps エンジニアは、既存の継続的インテグレーション・継続的デリバリー（CI/CD）パイプラインやソース管理システムとの統合を設定できます。また、AWS Lambda 関数に特に有用な Java、Node.js、Python のランタイム更新向けの事前構築済み変換や、チームがすぐに活用できるよう AWS SDK のモダナイゼーション向け変換も含まれています。

開始方法
AWS Transform は、事前構築済みおよびカスタムの変換機能を通じて、複雑なコード変換を管理可能にします。まずは、既存の変換を利用してよくあるモダナイゼーションの課題に対応する方法を見てみましょう。今回は、ランタイムのサポート終了（EOL）に伴う AWS Lambda 関数のアップグレードです。

この例では、Python 3.8 がサポート終了（EOL）となりセキュリティ更新が提供されなくなったため、Python 3.8 の Lambda 関数を Python 3.13 に移行する方法を示します。このデモでは CLI を使用しますが、Web インターフェースの強力なキャンペーン管理機能もぜひ試してみてください。

まず、 atx custom def list コマンドを使用して、利用可能な変換定義を確認します。必要に応じて、コマンドを直接実行する代わりにatxと入力するだけで、会話型インターフェースからこの機能にアクセスすることもできます。

このコマンドは、AWS 管理のデフォルト変換に加え、組織内でユーザーが作成した既存のカスタム変換も含め、利用可能なすべての変換を表示します。AWS 管理の変換は AWS/ プレフィックスで識別され、AWS によって管理および更新されていることを示します。結果には、Java ランタイムのモダナイゼーション向けの AWS/java-version-upgrade、Python の AWS SDK 利用更新向けの AWS/python-boto2-to-boto3-migration、Node.js ランタイム更新向けの AWS/nodejs-version-upgrade など、いくつかのオプションが表示されます。

Python 3.8 から 3.13 への移行には、AWS/python-version-upgrade 変換を使用します。

移行は、atx custom def exec コマンドを使用して実行します。コマンドおよびそのすべてのオプションの詳細については、ドキュメントを参照してください。ここでは、変換名を指定して自分のプロジェクトリポジトリに対して実行します。検証のために、pytest を追加してユニットテストを実行します。さらに重要な点として、–configuration入力の additionalPlanContext セクションを使用して、アップグレード先の Python バージョンを指定します。参考までに、デモ用のコマンドはこちらです（わかりやすいように複数行に分けてインデントしています）：

atx custom def exec 
-p /mnt/c/Users/vasudeve/Documents/Work/Projects/ATX/lambda/todoapilambda 
-n AWS/python-version-upgrade
-C "pytest" 
--configuration 
    "additionalPlanContext=アップグレード先の Python バージョンは Python 3.13" 
-x-t 

その後、AWS Transform が移行プロセスを開始します。このツールは Lambda 関数コードを分析し、Python 3.8 固有のパターンを特定し、Python 3.13 互換性のために必要な変更を自動的に適用します。これには、非推奨機能の構文の更新、インポート文の修正、バージョン特有の動作の調整が含まれます。

実行後、AWS Transform は包括的なサマリーを提供します。内容には、requirements.txt の依存関係が Python 3.13 対応のパッケージバージョンに更新された報告、非推奨構文が現在の等価表現に置き換えられた事例、AWS Lambda デプロイ用のランタイム設定の更新メモ、移行を検証するための推奨テストケースなどが含まれます。また、移行の成功を証明する証拠も提供されます。

移行後のコードはローカルブランチに存在するため、内容を確認して問題なければマージできます。あるいは、フィードバックを継続的に提供して何度も反復し、移行が完全に完了し、自分の期待に沿ったものになるまで調整することも可能です。

この自動化プロセスにより、通常であれば数時間かかる手作業が、コード品質を維持しながら新しい Python ランタイムとの互換性を保つ、効率的で一貫したアップグレードに変わります。

新しいカスタム変換の作成
AWS 管理の変換は一般的なシナリオに効果的に対応しますが、組織固有のニーズに合わせたカスタム変換を作成することも可能です。AWS Transform が組織固有の要件からどのように学習するかを確認するために、カスタム変換の作成方法を見てみましょう。

atxと入力して atx cli を初期化し、プロセスを開始します。

最初に尋ねられるのは、既存の変換を使用するか、新しい変換を作成するかです。私は新しい変換を作成することを選択します。ここから先は、すべてのやり取りがコマンドではなく自然言語で行われる点に注目してください。新しいものと入力しましたが、新しいものを作成したいと入力しても、まったく同じように理解されます。

その後、どのような変換を行いたいかについて、さらに情報を提供するよう求められます。このデモでは Angular アプリケーションを移行するため、Angular 16から19へのアプリケーション移行 と入力します。すると、CLI がこの種類の移行に利用可能なすべての変換を検索します。私の場合、チームですでにいくつかの Angular 移行が作成され利用可能になっているため、それらが表示されます。ただし、Angular 16 から 19 への移行という私の具体的な要求に完全に一致するものはないと警告されます。次に、一覧に表示されている既存の変換のいずれかを選択するか、カスタム変換を作成するかを尋ねられます。

自然言語を使い続け、create a new one と入力して、カスタム変換を作成することを選択します。繰り返しになりますが、自分の意図を明確に示していれば、この表現はどのようなバリエーションでも構いません。続いて、変換プランをカスタマイズするのに役立つドキュメント、サンプルコード、移行ガイドなどがあるかどうかを含め、いくつかの質問がされます。

このデモでは、AWS Transform が提供する適切なデフォルトのみを利用します。これらの詳細はわかりません と入力します。ベストプラクティスに従ってください。 と入力すると、CLI から、Angular 16 から Angular 19 への移行のための包括的なトランスフォーメーション定義を作成する旨の応答があります。もちろん、私は事前学習済みのデータを利用して、ベストプラクティスに基づく結果を生成しました。通常通り、この段階では可能な限り多くの情報や関連データを提供することが、より良い結果を得るための推奨事項です。ただし、すべてのデータを事前に揃えておく必要はありません。カスタム変換定義の作成プロセスを進める中で、いつでもデータを追加で提供できます。

変換定義はマークアップファイルとして生成され、サマリーとともに、プレマイグレーション準備、処理と分割、静的依存関係分析、特定の変換ルールの検索と適用、段階的な移行と反復的検証などのフェーズごとに論理的にグループ化された包括的な実装手順のシーケンスが含まれます。

興味深いことに、AWS Transform は問題を最小限に抑えるために、直接 16 から 19 へ移行するのではなく、アプリケーションを段階的に 17 → 18 → 19 へ移行するステップを作成するというベストプラクティスを選択しています。

プランには、各フェーズを確実に完了できることを確認するためのさまざまなテストおよび検証の段階が含まれている点に注意してください。最後には、最終検証フェーズも含まれており、移行を成功として受け入れるためにアプリケーションのすべての側面に対して実施される包括的なテストの終了基準がリスト化されています。

変換定義が作成された後、AWS Transform は次に何を行いたいかを尋ねます。変換定義を確認または修正することができ、このプロセスを何度でも繰り返して、納得のいく定義に仕上げることができます。この変換定義をすでに Angular コードベースに適用することも選択できます。ただし、まずはこの変換を自分だけでなくチームメンバーも利用できるようにして、将来再利用できるようにしたいと思います。そこで、私はこの変換をレジストリに公開するためにオプション 4 を選択します。

このカスタム変換には名前と目的の説明が必要で、ユーザーがレジストリを閲覧する際に表示されます。AWS Transform はこれらをコンテキストから自動的に抽出し、先に進む前に変更したいかどうかを尋ねてくれます。デフォルトの Angular-16から19への移行 は妥当で目的も明確に示されているため、提案を受け入れ、はい、良さそうですと答えて公開することにしました。

変換定義が作成され公開されたので、任意のコードリポジトリに対して何度でも使用して実行できます。それでは、この変換を Angular 16 で書かれたプロジェクトのコードリポジトリに適用してみましょう。続くプロンプトでオプション 1 を選択すると、CLI は移行したいアプリケーションのファイルシステム上のパスと、必要に応じて使用するビルドコマンドの入力を求めます。

情報を提供すると、AWS Transform はコードベースを解析し、先ほど作成した定義に基づいて、詳細な段階的変換プランを作成します。処理が完了すると、このコードベースに作成した変換定義を適用するための詳細な移行プランを含む JSON ファイルが作成されます。変換定義の作成プロセスと同様に、このプランも必要に応じて確認・反復することができ、フィードバックを提供したり、特定の要件に合わせて調整したりできます。

プランを承認する準備ができたら、自然言語で AWS Transform に対して移行プロセスを開始できることを伝えられます。よさそうだと入力して次に進むと、シェル上でプランの実行状況を確認しながら、コードベースに段階的に変更が加えられていきます。

所要時間はアプリケーションの複雑さによって異なります。私の場合、完了するまでに数分かかりました。完了すると、変換のサマリーと、プランの最終検証フェーズに含まれていた各終了基準のステータス、さらに報告されたステータスを裏付けるすべての証拠が提供されます。たとえば、「アプリケーションビルド — プロダクション」の基準は合格と記載されており、提供された証拠には、段階的な Git コミット、プロダクションビルドの完了にかかった時間、バンドルサイズ、ビルド出力メッセージ、作成されたすべての出力ファイルの詳細などが含まれています。

まとめ
AWS Transform は、組織がコードのモダナイゼーションや技術的負債に取り組む方法における根本的な変化を示しています。このサービスは、かつてはチームごとに分散していた作業を統合されたインテリジェントな機能に変換し、ナレッジサイロを解消するとともに、ベストプラクティスや組織の知識を組織全体でスケーラブルな資産として活用できるようにします。これにより、モダナイゼーションの取り組みを加速させるとともに、開発者は反復的な保守やモダナイゼーション作業に時間を費やすのではなく、イノベーションやビジネス価値の創出により多くの時間を割けるようになります。

知っておくべきこと

AWS Transform カスタムは、現在一般提供されています。最初の変換キャンペーンを開始するには はじめにガイド を参照するか、カスタム変換定義の設定方法について詳しく知るには ドキュメントをご覧ください。

原文はこちらです。