Claude CodeのAWS Transformプラグインで.NETやCOBOLを移行する
AWS Transformプラグインを入れ、.NET Framework・COBOL・VMware・SQL Serverの移行を評価から計画、変換、検証まで承認付きで進める手順と、事前に押さえる前提・制約をまとめます。
AWS Transformプラグインは、Amazon Web Servicesが配布するClaude Code用プラグインです。.NET FrameworkからのモダナイズやCOBOLのJava化、VMwareからEC2への移行といった大きな作業を、「評価、計画、変換、検証」の順に区切って進めます。
導入そのものは2行のコマンドで終わります。手間がかかるのは入れる前で、MCPサーバーの起動に使うツールとAWSの認証を用意しておく必要があります。この記事では導入手順、移行の進み方、ワークロード別の対応範囲、事前に知っておきたい制約を扱います。
AWS Transformプラグインは何を任せられるのか
プラグインの中身は、aws-transformという1つのスキルと、aws-transform-mcpというMCPサーバーです。スキルは移行作業の手順書で、MCPサーバーはワークスペース、ジョブ、エージェント、人の承認待ちタスク、認証を扱うツールを提供します。
対象は次のとおりです。
対応するワークロード
.NET
.NET Framework、.NET Core、.NET 5〜7を.NET 8または.NET 10へ移します。
メインフレーム
COBOLを中心にしたz/OSの資産を、Javaなどのクラウドネイティブなサービスへ移します。
VMware
VMwareの仮想マシンをEC2へ移します。
データベース
SQL Server、Oracle、MySQLをAuroraへ移します。
言語・SDKの更新
Java、Python、Node.jsのバージョンとAWS SDKを引き上げます。
もう1つ、コードの技術的負債やセキュリティ上の問題を洗い出し、そのまま修正まで進める「継続的モダナイゼーション(continuous modernization)」の分析も含まれます。移行先を決めていない段階でも、リポジトリの棚卸しから始められます。
導入前に用意するもの
プラグインを入れる前に、手元の環境で次の3点を確認します。
| 項目 | 必要になる場面 | 用意するもの |
|---|---|---|
uv | 必要になる場面MCPサーバーをuvxで起動するため。必須 | 用意するものmacOSはbrew install uv |
| AWSの認証情報 | 必要になる場面AWS Transformを使うため。必須 | 用意するものSigV4用の認証情報、またはIAM Identity Centerのセッション |
AWS Transform CLI(atx) | 必要になる場面カスタム変換と継続的モダナイゼーションの実行時 | 用意するものインストールスクリプト |
uvが無いと、プラグインは入ってもMCPサーバーが起動しません。最初に確認しておくと、後の切り分けが楽になります。Linuxではcurl -LsSf https://astral.sh/uv/install.sh | shで入れられます。
AWS Transform CLIは、READMEではカスタム変換にだけ必要とされています。スキルの定義では、Java・Python・Node.jsの更新やSDKの移行もカスタム変換の側に入り、継続的モダナイゼーションのatx ctコマンドもこのCLIです。atxは次のコマンドで入れます。
curl -fsSL https://transform-cli.awsstatic.com/install.sh | bashプラグインを入れて最初の依頼を出す
Claude Codeのセッションで、マーケットプレイスを追加してから、プラグインを入れます。
/plugin marketplace add awslabs/agent-plugins
/plugin install aws-transform@agent-plugins-for-awsマーケットプレイス名はagent-plugins-for-awsです。同じリポジトリには、AWSが配布する別のプラグインも入っています。たとえばDeploy on AWSプラグインはアプリのデプロイ、aws-serverlessプラグインはLambdaの設計を担当します。AWS Transformは「既存の資産を移す」側です。
入れた後は、やりたいことをそのまま頼みます。マーケットプレイスのページには、次のような依頼文が例として載っています。
migrate .NET Framework to .NET 8assess this codebase for tech debtmodernize my mainframe COBOLmove VMware to EC2convert SQL Server to Auroraupgrade Java to version 21
スキルは最初に、依頼文の中の「.NET」「VMware」「SQL Server」「メインフレーム」「COBOL」といった語からワークロードを見分けて進路を決めます。ワークロード名が無い依頼は、技術的負債の分析に回されます。移行をしたいなら、依頼文にワークロード名を入れておきます。
評価、計画、変換、検証の4段階で進む
このプラグインは、手順を飛ばさないことを前提に作られています。スキルの定義には、次の順序が書かれています。
スキルが従う進行順
- 1
再開の確認
作業ディレクトリの
.atx/context.jsonを見て、前回の続きがあるかを調べます。 - 2
意図の確認
何をしたいのかを選択式で尋ねます。
- 3
発見と範囲の決定
ワークスペースの言語やフレームワークを調べ、移行する対象をあなたが選びます。ここが1つ目の承認です。
- 4
評価
ワークロードごとの評価を走らせます。評価を省いて要件を書き始めることはできません。
- 5
要件の承認とタスク生成
評価レポートをもとに要件を書き、あなたが承認します。ここが2つ目の承認です。承認後に
tasks.mdが作られます。 - 6
実行
変換を走らせ、差分を確認します。コードを変えるたびに、あなたの承認が要ります。
重要なのは、評価レポートが要件の元になる点です。発見の段階で見つけた候補をそのまま要件にはしません。要件がなければ、実行にも進めない構造です。
前回の続きから再開する
状態は作業ディレクトリの.atx/context.jsonに保存されます。評価が終わった時点などのフェーズごとに書き込まれるので、セッションを閉じても、次に同じディレクトリで頼めば「前回の続きから進めるか、最初からやり直すか」を聞かれます。最初からを選ぶと、.atx/context.json、.atx/discovery.json、.atx/assessment-report/、.atx/specs/が削除されます。
評価レポートや要件が.atx/に残るので、チームで共有したいときはこの中身が引き継ぎ資料になります。リポジトリにコミットするかどうかは、機密性を見て決めます。
依頼ごとにユーザーが決める
スキルには、エージェントからの確認や承認待ちを勝手に処理しないという規則があります。AWS Transform側のエージェントが入力を求めたら、内容をあなたに見せて、答えを待ち、その答えを中継します。ソースコードのアップロードも、共有方法を尋ねてから行います。
長い移行では、この待ちが何度も発生します。無人で最後まで流す用途より、担当者が節目ごとに判断する用途に向いた作りです。
ワークロード別の違い
同じプラグインでも、ワークロードによって進み方が違います。
.NET
.NET Framework 2.0〜4.8、.NET Core 1.x〜3.x、.NET 5〜7が対象です。移行先は.NET 8か.NET 10で、スキルの参照資料では.NET 10が推奨として示されます。VB.NET、WPF、Xamarin(.NET MAUIへ)、ASP.NET MVC 5(ASP.NET Coreへ)、WCF(gRPCまたはREST)、Web Forms(BlazorまたはRazor Pages)、Entity Framework 6(EF Coreへ)といった変換も表に載っています。
変換モードはautoとinteractiveの2種類です。autoは止まらずに最後まで走り、失敗した箇所は記録して飛ばします。interactiveはプロジェクトごとに一度止まり、計画の承認も求めます。参照資料の「向いている用途」では、autoは単純なプロジェクトや小さなソリューション、interactiveは中規模以上や複雑なアプリとされています。
メインフレーム(COBOL)
z/OSのCOBOLとコピーブック、JCL、CICS、VSAM、Db2、IMSなどが対象です。開始時の選択肢は、機能の境界を見つけてから再構築する「Assess and reimagine」、範囲が決まったアプリを再構築する「Reimagine」、機能一覧から選ぶ、既存ジョブへの接続の4つです。
COBOLをJavaへという一言で済む作業ではありません。コード分析、データ分析、ビジネスロジックの抽出、要件の生成と段階を踏みます。必ず最初に「Kick off modernization」として、接続の設定とソースコードの置き場所を決める手順が入ります。
VMwareとデータベース
VMwareからEC2への移行は、1つのジョブにつき移行先リージョンを1つしか選べません。複数リージョンへ移すなら、ジョブを分けます。実行中の移行ジョブを止めると再開できず、新しいジョブで最初からやり直すことになります。
SQL ServerやOracle、MySQLからAuroraへの移行は、データベースの専用エージェントが担当します。VMwareとデータベースとメインフレームは、技術的負債の分析と同じ流れには回されません。「分析して」と頼んでも、ワークロード名があればワークロード別の評価に進みます。
事前に知っておきたい制約
スキルの参照資料には、Known Limitationsが書かれています。移行の見積もりに影響するものを抜き出します。
| ワークロード | 手作業が残る部分 |
|---|---|
| .NET | 手作業が残る部分COM interopの参照、ネイティブDLLを呼ぶP/Invoke、GACの依存、WindowsサービスのBackgroundService化 |
| .NET | 手作業が残る部分Web FormsからBlazorへの変換は部分的で、複雑なコントロールは再設計が要る |
| メインフレーム | 手作業が残る部分アセンブラはAWS Transformのエージェントでは変換されない。PL/Iはビジネスロジック抽出、技術文書、データ分析のみ |
| メインフレーム | 手作業が残る部分CICSのBMS画面の変換、複雑なSORT/MERGEのJCLステップは手動の判断が残る |
| VMware | 手作業が残る部分物理サーバーは対象外。vMotion、DRS、HAに直接対応する機能はAWSに無く、設計し直す。Windows ServerやSQL Serverのライセンスの対応づけも手動で見直す |
この表の見方はシンプルです。自動変換が通っても、「手作業の残り」を先に数えておかないと、全体の工数を見誤ります。評価レポートが出た段階で、この表と突き合わせると、見積もりの抜けが見つかります。
料金と所要時間はClaudeに聞いても出ない
スキルには、ドル額、時間単価、所要時間の見込みを答えないという規則があります。「この分析は何時間かかるか」と尋ねても、具体的な数字は返ってきません。AWSの料金ページを見るよう案内されます。予算や期間の見積もりは、料金ページと評価レポートの規模から自分で組み立てます。
利用状況のテレメトリが送られる
継続的モダナイゼーションの経路では、スキルとCLIのatx ctが既定で利用状況のテレメトリを集めます。収集するのは、IDE名、AIエージェント名(Claude Codeなど)、実行モード(ローカルかリモートか)といった項目です。最初の応答で、セッションごとに一度、その旨の注意書きが出ます。
セッション中に「テレメトリを止めて」と頼むと、--telemetryを付けるのをやめ、すべてのatx ctコマンドにATX_DISABLE_TELEMETRY=trueを前置きするように切り替わります。組織のポリシーで外部送信を管理しているなら、導入前にここを確認します。
継続的モダナイゼーションで棚卸しから始める
移行先が決まっていない場合は、移行ではなく分析から入ります。ワークロードを名指ししない依頼のうち、「技術的負債」「セキュリティ脆弱性」「CVE」「どこから直すか」といった語は、継続的モダナイゼーションに回されます。
このリポジトリの技術的負債とCVEを分析して、直す順番を提案してこの経路では、実行場所をローカルとAWSのインフラのどちらにするか最初に選びます。スケジュール実行にも対応し、管理用のインフラを自分で用意しないaws-managedモードも用意されています。リポジトリを手で読み込んで問題を探させる使い方は想定されておらず、探索はCLIの分析に任せる設計です。
AWS認証は、分析や修正の前にaws sts get-caller-identityで確認されます。期限切れなら、長い処理を始める前に更新を求められます。実行中に失効して途中で止まるのを避けるための手順です。
別の移行記事との使い分け
Claude Codeでレガシーコードの移行を扱う方法は、AWS提供のプラグインだけではありません。Anthropic側のプラグインを使うやり方は、Claude Codeのcode-modernizationプラグインで古いコードを移行するで扱っています。
選び方の目安は、移行先がAWSかどうかです。AWSへの移行が前提で、変換エージェントとAWS側のジョブ管理を使いたいならAWS Transformプラグインが合います。移行先を問わずコードの現代化を進めたいなら、別のプラグインも比較の対象になります。
リポジトリのREADMEには、AWS Labsのプラグインやスキルの後継として「Agent Toolkit for AWS」が公開済みだという案内があります。本番ソフトウェアを作る場合はそちらを勧めると書かれており、このリポジトリのプラグインは引き続き動作し、貢献も受け付けるとされています。
まとめ
AWS Transformプラグインの要点は、変換の速さより、評価から要件、計画、実行を承認つきで区切る進め方にあります。入れる前にuvとAWS認証を用意し、移行後も残る手作業を制約の表で数えておけば、作業の抜けを減らせます。
移行先を決めかねているなら、継続的モダナイゼーションでリポジトリの現状を棚卸しするところから始められます。同じAWS向けのプラグインでも、デプロイやLambdaの設計は別のプラグインの領分なので、作業の段階で使い分けます。