本稿では、AWS re:Invent 2025 で開催された、[NEW LAUNCH] Retire technical debt at scale with automated code transformation [REPEAT] (DVT338-R) の参加レポートになります。
結局、帰国の日まで時差ボケが治らない。
内村でございます。
アメリカはネバダ州のラスベガスで開催されていた AWS re:Invent 2025 に参加してきました。
今回のワークショップは、新サービス「AWS Transform Custom」です。
AWS Transform Custom とは？を私なりに解釈し、使いどころを纏めています。
技術的負債に課題を抱えておられる方のお役に立てば幸いです。
内容についての諸注意
当記事は 2025年12月時点で調査した製品、サービス内容を記載しています。 最新の情報に関しては各種公式サイト、マニュアル等をご確認下さい。
当記事作成の際には十分注意しておりますが、内容に公式と相違がある場合は公式を優先とさせていただきます。
当記事内の試算およびそれに準ずる内容は、本資料の説明のために用いるものであり、不利益が生じた場合、一切の責任は負いかねますので予めご了承ください。
AWS Transform Custom とは？
AWS Transform は、アプリケーションコードを自動的に変換することで、言語・ランタイム・SDK などのアップグレードを支援するサービスです。
その中でも AWS Transform Custom は、共通パターンはもちろん、自社固有の技術的負債パターン も学習して自動変換してくれるエージェントという位置づけでした。
ただし現在、AWS Transform Customは US East (N. Virginia)リージョンのみ で利用可能です。ご注意ください。
技術的負債の現実
導入パートでは、Technical Debt（技術的負債）がどれだけ組織に効いているか、いくつかの数字が提示されました。
- IT 予算の「20-30%」が技術的負債の対応に使われている
- 開発者の「20-30%」の時間が、負債対応に消えている
- 世界全体では「2.4 兆ドル/年」規模のインパクトがあると試算されている
そして負債が積み上がることで次のような問題が起きる、と整理されていました。
- セキュリティ／コンプライアンスリスク（古いライブラリ・フレームワークに起因）
- メンテナンス負荷の増大（誰も触れないブラックボックス化）
- パフォーマンス劣化・コスト増（スケールしないアーキテクチャ）
- M&A などによるスタックの乱立・分断（ビジネスユニットごとに別技術）
「気付いたら、負債の山に埋もれて機能追加が困難になる・時間がかかる」
ここに AWS Transform Custom が効いてくる、という流れです。
実際のお客様事例
スライドでは、複数のお客様事例が挙げられていました。
Air Canada
数万クラスの関数が古いランタイムに残っており、人手でのアップグレードは膨大な工数
Twitch（Amazon 内部のサブシディアリ）
AWS SDK for Java V1 を使ったコードベースが 900 以上あり、V2 への移行は「11 開発者年」レベルの見積り
長年オンプレ ERP を提供しているベンダー
顧客が 25 年以上かけて独自カスタマイズしてきた結果、お客様ごとにコードベースがバラバラでアップグレードが困難
こうした似たようなパターンの負債が、大量のコードベースに散らばっているケースで、AWS Transform Custom を使っているとのことでした。
AWS Transform Custom の特徴
汎用コード変換エージェント
AWS Transform Custom はおおまかに以下のように捉えています。
自然言語で「こう変換して」と説明しつつ、API ドキュメントや Before/After のコードなども渡していくと、対象コードを読み込んでパターンを学習し、何度も繰り返し同じ変換をやってくれるエージェント
資料内 1 〜 4 の箇所を分解してみます。
- まず変換したいタスク（e.g. SDK v1 → v2 への書き換え）を、 SME（熟練エンジニア）がエージェントに説明します
- API ドキュメントや Before/After のコード差分なども渡すことができ、それをもとに「Transformation 定義」を作成
- その後、サンプルコードに対して変換を実行し、「ここは間違っている」「このパターンもカバーしてほしい」とフィードバック
- ある程度精度が上がったら、アプリケーションチームに配布し、各チームが自分のリポジトリに対して実行
実行時に開発者が追加でフィードバックすると、その知見も Transformation 定義側に吸い上げられ、次に走るときにはより賢くなる、という学習ループが組まれています。
Out-of-the-box で使える変換
AWS Transform Custom には、AWS があらかじめベンチマーク＆チューニングした「Out-of-the-box Transformation」も用意されています。
ワークショップでは、AWS-Managed Transformations という内容で紹介されました。
例は以下です。
- 言語／ランタイムのアップグレード
- Java ランタイムのアップグレード
- Python ランタイムのアップグレード
- Node.js ランタイムのアップグレード
- AWS SDK のアップグレード
- Java / Python / Node.js などの AWS SDK v1 → v2 への移行
- 早期アクセスの変換
- x86 から Graviton への移行サポート など
これらは AWS 内部コードや OSS リポジトリ『数万単位』を使って検証しており、すぐに実戦投入できる品質 を目指しているとのことでした。
Agent Minutes ベースの料金モデル
AWS Transform Custom の料金は、AWS Transform Custom Agent minutes（エージェント分）に応じた従量課金モデルです。
代表的なケースとして次のような例が紹介されています。
- SDK 更新（Node.js、約 3,000 行のコード） ⇒ 約 20 Agent minutes で、料金はおよそ 0.70 USD
- Java 言語バージョン更新（約 17,000 行） ⇒ 約 72 Agent minutes で、料金はおよそ 2.52 USD
- Python ランタイムのアップグレード（約 4,000 行） ⇒ 約 37 Agent minutes で、料金はおよそ 1.30 USD
ご注意いただきたいのは、Agent Minutes は「エージェントが実際に作業している時間」のみカウントされ、ローカルでのビルドやテスト実行時間は含まれません。
あくまで『サンプルケース』ではありますが、 Lambda 関数や中規模アプリケーションのランタイム／SDK 更新をキャンペーン的に一気に進めるのに十分現実的なコスト感だと感じました。
ただし、複数のエージェントが並行作業する場合、合計 Agent Minutes は実際の経過時間より多くなる可能性があることはご留意ください。
ハンズオンで試したこと
今回のハンズオンでは、複数のサンプル Python アプリケーションを題材に、次のような体験をしました。
- 事前に用意された環境（VS Code Server + CLI）にログイン
- AWS-Managed Transformations を使った以下などの変換を実行
- ランタイムアップグレード
- ロギングパターンの統一
- 自分でシンプルな「Custom Transformation」を定義（特定のログフォーマットを新フォーマットに書き換える… といったパターン）
- 実行結果の差分を確認し「このパターンも変換対象に入れたい」といったフィードバックをエージェントに与える
- 修正した Transformation を再実行し、改善具合を確認
特に面白かったのは、以下の点です。
- Transformation 定義自体は YAML や AST の知識がなくても、「中堅エンジニアに口頭で説明する」ような感覚で対話的に作っていける
- 一度定義してしまえば、同じ変換を別リポジトリに対して再利用できる
ベストプラクティスとして語られていたこと
セッション中、スピーカーから強調されていたベストプラクティスは大きく 2 つです。
いきなり全社展開しない、まずはパイロットから
- 代表的な 5〜10 リポジトリを選んでパイロット実行する
- その結果から見積もる
- 変換精度（どの程度手作業が残るか）
- 想定コスト（Agent Minutes）
- 問題なさそうであれば、対象リポジトリを徐々に広げていく
既存のワークフローに組み込む
- Transform Custom は CLI ベースで、依存関係は以下の程度
- サポートプラットフォーム: Linux, macOS, WSL
- Node.js 20以降
- Git
- インターネット接続（特定のAWSエンドポイントへのアクセス）
- 既存の CI/CD パイプライン、あるいはバッチサーバーのワークフローにそのまま組み込めるように設計されている
- 開発者が個々にツールをセットアップする必要はなく、コンテナ化された実行環境を渡すことも可能
特に、
「このツールを使うために開発プロセスを変えてほしいとは思っていない」
というコメントが印象的でした。
まとめ
AWS Transform Custom は、「技術的負債の典型パターン」を学習しながら、大量のコードベースに対して自動変換をかけられる新サービスです。
Out-of-the-box (AWS-Managed Transformations) の変換に加え、「自社固有のパターンもエージェントに教え込める」 のがポイントかと思いました。
料金は Agent Minutes ベースで、公式の料金例を見る限り、Lambda 関数や中規模アプリケーションのアップグレードであれば数ドル前後から始められる、AWS らしい検証しやすい従量課金です。
技術的負債はゼロにはなりません。
しかし、「発生するなら、賢く・まとめて片付けたい」という現場の願いに、AWS Transform Custom はかなり寄り添ってくれるサービスだと感じました。
現場からは以上です。
