AWS Transform Customとは
はじめに
ベンジャミンのクワバラです。re:Invent2025に参加してきました。新サービスが多く発表されていた中で、個人的に気になったAWSサービスをブログにまとめていきます。まずは「AWS Transform Custom」を紹介していきます。
AWS Transform Customとは？
AWS Transformというサービスは既に存在していましたが、新たな機能としてAWS Transform Customがリリースされました。
AWSドキュメントのWhat is AWS Transform custom?を抜粋すると以下とあります。（機械翻訳しています）
AWS Transform Customは、エージェント型AIを活用し、ソフトウェア、コード、ライブラリ、フレームワークの大規模なモダナイゼーションを実施し、技術的負債の削減を実現します。言語バージョンのアップグレード、APIおよびサービスの移行、フレームワークのアップグレードと移行、コードのリファクタリング、組織固有の変革など、多様なシナリオに対応します。
エージェントは継続的な学習を通じて、あらゆる実行と開発者のフィードバックから改善し、専門的な自動化の専門知識を必要とせずに、高品質で繰り返し可能な変換を実現します。AWS Transform Customはプログラム言語のアップグレードだけではなく、フレームワークの移行にも対応しているようです。
AWS Transform Customの機能
AWS Transform カスタムは次の機能を提供します。
- 自然言語による変換定義
ドキュメントやコードサンプルを使い、自然言語でカスタム変換を定義 - AWSマネージド変換
AWSが用意している検証済みのテンプレート - 一貫した変換の実行
複数のコードに対してカステム定義を一貫して定義 - 継続的な学習
実行結果とユーザからのフィードバックを学習し、カスタム変換の品質を向上
この4つの機能のうち、まずは1か2の機能を選びます。例えばPythonアプリケーションのバージョンをアップグレードしたい場合はAWSマネージド変換のテンプレートが用意されているので2を利用。
AWSマネージド変換のテンプレートが用意されていない場合（例えばPHPアプリケーション）は1の自然言語による変換定義を選択し、情報をインプットしてあげる必要があります。
使い始めた後は3の一貫性や4の品質向上によって組織に最適化されていくという流れを想定しています。
「AWSマネージド変換」と「自然言語による変換」の詳細
AWSドキュメントから抜粋しました。（情報は2026/1時点）
Noの列は整理しやすいように追加しています。
| No | パターン | 説明 | 複雑 | 例 |
|---|---|---|---|---|
| 1 | APIとサービスの移行 | 機能性を維持しながら API バージョンまたは同等のサービス間で移行する | 中くらい | AWS SDK v1→v2 (Java、Python、JavaScript)、Boto2→Boto3、JUnit 4→5、javax→jakarta |
| 2 | 言語バージョンのアップグレード | 同じプログラミング言語の新しいバージョンにアップグレードし、新しい機能を採用し、廃止された機能を置き換える | 低中 | Java 8→17、Python 3.9→3.13、Node.js 12→22、TypeScriptのバージョンアップ |
| 3 | フレームワークのアップグレード | 同じフレームワークの新しいバージョンにアップグレードし、重大な変更に対処する | 中くらい | Spring Boot 2.x→3.x、React 17→18、Angularのアップグレード、Djangoのアップグレード |
| 4 | フレームワークの移行 | 同様の目的を果たす全く異なるフレームワークへの移行 | 高い | Angular→React、Redux→Zustand、Vue.js→React |
| 5 | ライブラリと依存関係のアップグレード | 同じ言語とフレームワークを維持しながら、サードパーティのライブラリを新しいバージョンにアップグレードする | 低中 | Pandas 1.x→2.x、NumPy のアップグレード、Hadoop/HBase/Hive ライブラリのアップグレード、Lodash のアップグレード |
| 6 | コードリファクタリングとパターンの近代化 | 外部機能を変更せずにコードパターンを最新化し、ベストプラクティスを採用する | 低中 | 印刷→ログ記録フレームワーク、文字列連結→f文字列、型ヒントの採用、可観測性計測 |
| 7 | スクリプトとファイルごとの翻訳 | 独立したスクリプトや設定ファイル（ファイルがほとんど自己完結的）を翻訳する | 低中 | AWS CDK→Terraform、Terraform→CloudFormation、Excel→Pythonノートブック、Bash→PowerShell |
| 8 | アーキテクチャの移行 | 最小限のコード変更でハードウェア アーキテクチャまたはランタイム環境間の移行 | 中高 | x86→AWS Graviton（ARM）、オンプレミス→Lambda、従来型サーバー→コンテナ |
| 9 | 言語間の移行 | あるプログラミング言語から別のプログラミング言語へのコードベースの変換 | 非常に高い | Java→Python、JavaScript→TypeScript、C→Rust、Python→Go |
| 10 | カスタムおよび組織固有の変換 | 独自の組織要件と特殊な近代化ニーズ | 様々 | カスタム内部ライブラリの移行、組織固有のコーディング標準、独自のフレームワークの移行 |
No.1とNo.2はAWSマネージド変換で実現可能で、それ以外（No.3以降）は自然言語による変換になります。AWS SDKもAWSマネージド変換がサポートしているのが嬉しいですね。
コーディングAIツールとAWS Transform Customの選択
バージョンアップであれば、Claude CodeやAWS Kiroなど開発者や組織が使い慣れているコーディングAIツールを利用する場合との使い分けが気になりませんか・・？私は気になりました。
調べるとAWS Transform Customはエンタープライズの大規模利用を想定しているようで、以下のような課題を解決する組織での利用を想定した設計になっているようです。ただ、小規模な利用であれば使い慣れたツールでも問題ないと考えます。
- 開発者ごとに結果が異なり、組織全体のコーディング規約を強制するのが難しい
- 人間が都度指示・確認する必要があり、数千回繰り返す作業には向かない
- 個々の開発者が得た学び(例:APIの非互換性回避策)が組織内で共有されず、サイロ化する
コスト
コストはAWS公式の情報を元にAIにまとめてもらいました。(2026/1時点のコストです。)
従量課金で非常に安く始めることができそうです。
まとめ
プログラム言語のアップグレード作業は既存システムの定期的なチェック、関係者アナウンス、バージョンアップやテストといった作業が発生して非常に対応コストがかかっていました。AWS Transform Customを導入することでそれらの作業が自動化され、コストカットかつ空いた時間を他の作業に充てることが期待できそうです。影響が少ないところから導入を検討していきたいです。
今回のブログではAWS Transform Customの紹介に留めましたが、次回のブログで実際に動かしてみた結果を紹介できればと考えています。
