![[アップデート] AWS Transform が Kiro Power として利用可能になったので使ってみた](https://images.ctfassets.net/ct0aopd36mqt/6sr6qXoJHrSGCktI3d56Hk/4504fc5f0b23d1e8430dfc948c18f606/aws-transform.png?w=3840&fm=webp)
[アップデート] AWS Transform が Kiro Power として利用可能になったので使ってみた
いわさです。
AWS Transform custom は、AI エージェントを使ってコードのバージョンアップグレードやフレームワーク移行、AWS SDK 移行などを自動化するサービスです。
これまで AWS Transform custom を利用するには、atx CLI[1](AWS Transform custom 専用のコマンドラインツール)を使ってターミナルから操作するか、Web コンソールを使う必要がありました。
先日、VS Code 拡張機能がリリースされて IDE 上からも操作できるようになりました。
ただし VS Code 拡張機能は Claude Code や Amazon Q などの外部 AI エージェントにプロンプトを渡す形式で、別途 AI エージェントのセットアップが必要でした。
今回のアップデートでは上記に加えて、AWS Transform が Kiro Power としても利用可能になりました。
Kiro Power は Kiro のエージェントに専門知識とワークフローを追加する仕組みです。
AWS Transform Power をインストールすると、Kiro のチャットから直接 atx コマンドによる変換を実行できるようになります。
VS Code 拡張機能と異なり、別途 AI エージェントを用意する必要がなく、Kiro のエージェントとクレジットだけで完結するのが特徴です。
なお、VS Code 拡張機能の送信先エージェントには Kiro(Kiro CLI)は含まれておらず、Claude Code や Amazon Q 等が対象でした。
なお、今回 Kiro Power として対応したのは AWS Transform custom のみです。
Windows モダナイゼーション(.NET)やメインフレーム変換など、AWS Transform の他の機能は対象外です。
マネジメントコンソールにも「CLI では AWS Transform Custom ワークロードのみがサポートされています」と記載されています。

AWS Transform custom is the first supported capability, with more playbooks on the way.
今回こちらを確認してみたので紹介します。
Power の内部構成を確認してみる
前述の AWS Transform Power の GitHub リポジトリを確認してみました。
MCP サーバーは含まれておらず、steering フォルダと POWER.md で構成されたステアリングファイルベースの Power となっていました。
Kiro エージェントに atx CLI の操作手順やワークフローを教える形で動作するようです。

Kiro Power と VS Code 拡張機能の違い
検証に入る前に、今回のアップデートで追加された 2 つの IDE 連携の違いを整理しておきます。
| 項目 | Kiro Power | VS Code 拡張機能 |
|---|---|---|
| 動作環境 | Kiro IDE | VS Code |
| AI エージェント | Kiro 内蔵(追加不要) | Claude Code / Amazon Q / GitHub Copilot / Cline / OpenAI Codex のいずれかが必要 |
| 仕組み | ステアリングファイルで Kiro エージェントに atx の操作手順を教える | SKILL.md で AI エージェントに atx の操作手順を教える |
| MCP サーバー | なし | なし |
| 実行モード | ローカル / リモート(AWS Batch/Fargate) | ローカルのみ |
| 大規模実行 | 最大 512 リポジトリ(リモートモード) | 1 リポジトリずつ |
VS Code 拡張機能の詳細は冒頭で紹介した記事をご覧ください。
AWS Transform Power を使ってみる
前提条件
AWS Transform Power を使うには、以下が必要です。
- Kiro IDE がインストール済みであること
- AWS CLI がインストール済みであること
- AWS 認証情報が設定済みであること(
AWSTransformCustomFullAccessポリシーが必要)
atx CLI(AWS Transform custom 専用のコマンドラインツール)は、未インストールの場合 Power が自動でインストールしてくれます。
認証情報の設定も含めた詳細は、以下のブログが参考になります。
AWS Transform Power のインストール
Kiro の Powers パネルを開くと、AVAILABLE の一覧に「AWS Transform」が表示されています。
選択すると説明と「+ Install」ボタンが表示されるので、クリックしてインストールします。

ローカルモードで Java バージョンアップグレードを実行する
ローカルに用意した簡単な Java 8 の Maven プロジェクトに対して、Java バージョンアップグレードを実行してみます。
AWS-managed transformations(AWS が事前に用意した変換レシピ)[2]には Java / Python / Node.js のバージョンアップグレードや AWS SDK 移行など、よくあるパターンが用意されています。
Kiro でサンプルプロジェクトを開いた状態で「コードをアップグレードしたい」と入力してみました。
すると Kiro がまずプロジェクトのファイル(pom.xml、App.java など)を読み取り、Java 8 であることを検出しました。
その上で「AWS Transform パワーがインストールされているので、これを使ってコードのアップグレードを進めましょう。」と判断し、自動的に Power がアクティベートされました。

Power がアクティベートされると、AWS Transform custom で出来ることの一覧と「What would you like to transform today?」という問いかけが表示されます。
続けて、Kiro エージェントが自動的に以下を実行してくれました。
- 前提条件のチェック(プラットフォーム、AWS CLI、AWS 認証情報、atx CLI)
- 利用可能な変換定義の一覧取得
- リポジトリの検査結果と変換定義の照合

atx CLI が未インストールだったのですが、Power が検出して自動でインストールしてくれました。
マッチレポートが表示され、AWS/java-version-upgrade が自動的に選択されました。

ローカルモードで実行する旨と、追加の設定確認が表示されます。
ターゲットバージョンは Java 21、ビルドシステムは Maven と自動検出されています。
さらに「JUnit 4 → JUnit 5 への移行なども含めますか?」と確認してくれました。
承認すると、Kiro エージェントが atx コマンドを実行して変換を開始します。
VS Code 拡張機能では Claude Code などの外部エージェントに処理を委譲していましたが、Kiro Power の場合は Kiro のエージェントが直接 atx コマンドを実行します。
そのため、Kiro のチャット画面内で変換の進捗を確認でき、途中の操作も Kiro のチャットで完結します。


変換結果の確認
変換が完了すると、変更内容のサマリーが表示されました。

今回はシンプルすぎるプロジェクトだったので、変更は pom.xml のみでソースコードの変更はありませんでした。
| 項目 | Before | After |
|---|---|---|
| maven.compiler.source/target | 1.8 | 21 |
| maven-compiler-plugin | 3.8.1 | 3.13.0 |
| maven-jar-plugin | 3.2.0 | 3.4.2 |
ソースコード(App.java、UserService.java、UserServiceTest.java)は Java 8 の Lambda、Stream、Optional を使っていましたが、そのまま Java 21 で互換性があるため変更なしとのことです。
テスト 2 件も全てパスしています。
今回の最小な規模で所要時間は約 18 分、消費クレジットは 4.34(Auto モード) でした。
リモートモードも試してみる
Kiro Power の特徴のひとつが、VS Code 拡張機能にはないリモートモードです。
リモートモードでは AWS Batch/Fargate を使って変換をクラウド上で実行できます。
10 リポジトリ以上の大規模な変換に向いており、最大 128 並列(1 セッションあたり最大 512 リポジトリ)で実行できるようです。
Remote mode: Runs transformations at scale via AWS Batch/Fargate containers. Best for 10+ repos or when the user prefers cloud execution. Infrastructure is auto-deployed with user consent.
リモートモードを指定して実行してみたところ、ローカルモードと同様の前提条件チェック(プラットフォーム、AWS CLI、atx CLI)に加えて、cdk --version のチェックが追加されていました。
リモートモードでは AWS Batch/Fargate のインフラを CDK でデプロイする必要があるため、AWS CDK もチェック対象になるようです。

さらに進めると、CloudFormation スタック(AtxInfrastructureStack)のデプロイ状況を確認し、未デプロイの場合はデプロイの確認を求められました。

デプロイされるリソースが表示されていますね。なるほど。
初回デプロイは約 5〜10 分かかるとのこと。
今回はインフラデプロイの確認手前まで試しましたが、実際のリモート実行までは行っていません。
リモートモードの実行については別途検証しているかもしれない。いつか...
さいごに
本日は AWS Transform が Kiro Power として利用可能になったアップデートを確認してみました。
VS Code 拡張機能と比べると、Kiro 単体で完結するのが一番の違いだと思います。
VS Code 拡張機能は Claude Code などの外部エージェントが必要で、そのセットアップやコマンド実行許可の操作が都度発生していましたが、Kiro Power ではそのあたりがシンプルになっています。
また、リモートモードで最大 512 リポジトリの大規模変換にも対応しているのは、VS Code 拡張機能にはない機能なので、エンタープライズ用途では大きなポイントかもしれないですね。
先日の Kiro CLI のヘッドレス対応や、今回の AWS Transform custom の Kiro Power 対応で、以前は Amazon Q Developer でしか実現できなかったことが徐々に Kiro でもカバーされてきた印象を受けます。
Kiro は Amazon Q Developer の後続として登場しましたが、当初はまだ Q Developer だけでしかできないことがいくつかありました。
そのギャップが少しずつ埋まってきているのかなと思います。









