2026年10月に、AWSが「AWS Transform」でAzure向けに作られた.NETアプリのコードをAWS向けに自動変換する機能を一般提供（誰でも使える正式版）にしたと発表しました。「Azureで動いているシステムをAWSに移したい」と考えている発注者にとっては気になるニュースです。
「うちのシステムはAzureで動いているけど、AWSに乗り換えたい。AIが自動で変換してくれるなら、費用もかなり下がるのかな？」
先に結論をお伝えします。乗り換えの選択肢と手順は増えましたが、「自動で全部移れる」「費用が大幅に下がる」という話ではありません。今動いているシステムを急いで移す必要もありません。発注者が今やるべきことは、「自社のシステムがどのAzureの機能に依存しているか」と「移行するかどうかの判断材料」を開発会社と揃えておくことです。
この記事では、発表内容（執筆時点：2026年10月23日）を事実として整理したうえで、発注者にとって何が変わり、何が変わらないのか、開発会社に何を確認すればよいかを解説します。
ニュースの要点：何が発表されたのか
AWSは2026年10月16日付のお知らせで、AWS Transformの「.NETモダナイゼーションエージェント」について、Azure SDKからAWS SDKへのアプリケーションコード変換を一般提供したと発表しました。
📰 出典：AWS「AWS Transform、Azure から AWS へのクラウドネイティブコード変換を発表」
📰 出典：Publickey「AWS TransformがAzureからAWSへの移行をサポート。Azure FunctionsのコードをAWS Lambdaに変換など」（2026年10月20日）
発表の内容を、噛み砕いて整理すると次のとおりです。
| 項目 | 内容（執筆時点・AWS発表より） |
|---|---|
| 対象 | AzureのサービスをAzure SDKで使っている.NETアプリ |
| 変換できるもの | Azure Functions → AWS Lambda、Azure Blob Storage → Amazon S3、Azure Queue Storage → Amazon SQS |
| まだプレビューのもの | Azure Cosmos DB → Amazon DynamoDB（正式版ではない） |
| 進め方 | コード内のAzure利用箇所を検出 → 評価レポートと移行計画で変換案を提示 → 利用者が採用・調整 → 変換 → 変換後の内容を検証 |
| 利用できる地域 | 東京を含む8リージョン |
| 料金・利用条件 | 発表ページには記載なし（ユーザーガイドで確認が必要） |
また、Publickeyの記事によると、AWSの対応サービスに置き換えられない部分は、ToDoコメントや仮のコード、次の作業を書いた説明ファイルとして残されるとのことです。つまり、変換の対象になるのはアプリのプログラムの一部（Azureのサービスを呼び出している部分）であり、全部が自動で終わるわけではないと読み取れます。
発注者にとって何が変わるか／変わらないか
ここからは、事実ではなく筆者の見解です。
変わりそうなこと
- 乗り換えの下調べがしやすくなる：「どこがAzureに依存しているか」を検出し、評価レポートと移行計画にまとめてくれるため、移行の見積もりの材料が早く揃う可能性があります。
- 開発会社の作業の一部が減る可能性：Azure SDKの呼び出しをAWS向けに書き換える定型作業は、ツールで下書きができるようになります。
変わらないこと
- 動作確認・データ移行・切り替えの作業は残る：コードが変換されても、データの引っ越し、権限やネットワークの設定、本番での切り替え手順、負荷や費用の確認は別の作業です。
- 「変換後のコードが正しいか」を確認する責任は人にある：発表でも、変換後に変更が反映されたかを検証する工程が含まれています。AIやツールが出した結果を、誰がどこまで確認するかは契約で決めておく必要があります。
- クラウドの料金体系が変わるわけではない：AzureとAWSでは課金の単位や割引の仕組みが異なります。「コードが移せた＝安くなる」ではありません。
- 対象外の部分は手作業：今回の発表で触れられているのは.NETアプリと上記の一部サービスです。Cosmos DBはプレビュー段階で、それ以外のAzureサービスへの対応は発表ページからは確認できません。自社のシステムが対象に入るかは、開発会社に確認が必要です。
「ツールが出たから乗り換え費用が半分になる」といった期待は禁物です。費用が下がるかどうかは、システムの作りと移行の範囲次第です。
今やるべきこと／様子見でいいこと
今やっておきたいこと（低コストでできる）
- 自社のシステムが動いているクラウドと、使っているサービスの一覧を開発会社に出してもらう（Azure Functions、Blob Storage、Cosmos DBなど）。
- 乗り換えを検討しているなら、目的を言葉にする：費用を下げたいのか、別システムとの連携が目的か、契約上の都合かで、答えが変わります。
- 移行の「評価」だけを先に依頼できるか聞く：いきなり移行を発注せず、対象範囲と費用感を出してもらう段階を挟む方が安全です。
様子見でいいこと
- 稼働中のAzure上のシステムを、このニュースだけを理由に急いで移す必要はありません。
- Cosmos DBからDynamoDBへの変換はプレビュー段階です。該当する場合は、正式版になってから検討しても遅くありません。
発注者がやることチェックリスト
- ☐ 自社のシステムがAzure・AWS・その他のどこで動いているか把握している
- ☐ 乗り換えを検討する理由（費用・機能・契約・連携など）を一文で書けている
- ☐ 使っているクラウドのサービス名（Functions、Blob Storage、Cosmos DBなど）の一覧が手元にある
- ☐ 保守契約の範囲に「クラウド移行」が含まれるか確認した
- ☐ 移行する場合の目標時期と、システムを止められる時間帯を社内で決めている
- ☐ 移行後の月額費用の上限を考えている
開発会社への質問例
そのまま使える質問です。
- 「うちのシステムはAzureのどのサービスを使っていますか？今回のAWS Transformの変換対象に入りますか？」
- 「AWSに移す場合、自動変換でどこまで進み、人の作業はどこが残りますか？」
- 「変換後のコードの確認やテストは、どなたがどの範囲まで行いますか？費用に含まれますか？」
- 「移行後のAWSの月額費用は、現在のAzureの費用と比べてどうなる見込みですか？試算の前提も教えてください」
- 「移行の評価だけを先に依頼する場合、期間と費用はどのくらいですか？」
- 「AIやツールを使って作業する場合、当社のソースコードや資料はどこに保存・送信されますか？」
- 「移行中に障害が出た場合の連絡先と、元に戻す手順はありますか？」
まとめ：選択肢が増えたことは歓迎、でも判断は冷静に
AWS Transformの新機能は、Azureで作られた.NETアプリをAWSへ移す際の作業を助けるものです。ただし、自動変換できるのは一部のサービスで、検証・データ移行・切り替えといった作業は残ります。
- 稼働中のシステムを、このニュースだけで急いで移す必要はない
- 「自動変換＝大幅な費用削減」とは限らない
- まず、使っているクラウドのサービス一覧と、乗り換えの目的を整理する
- 変換結果の確認と責任の範囲を、契約で決めておく
クラウドの乗り換えは、技術だけでなく費用・期間・体制の判断が必要です。迷ったときは、まず現状の整理から始めてみてください。
あわせて読みたい関連記事
