刷新が6週間になった発表で
60%削減は別の数字です

刷新提案書にAWSの事例が載り始めた方へ

基幹システムの刷新やクラウド移行の提案を受けていて、その資料に「AIで数年の作業を数週間に」「移行コストを60%削減」といったAWSの事例が引用されている段階の方に向けて書いています。

数字が嘘だという話ではありません。同じ発表に載っている2種類の数字が、測っているものが違うのに並べて書かれるという話です。分けて読めば、提案書のどこを確認すべきかが決まります。

何が発表されたのか

AWS Transformとは、AWSが2025年に一般提供を始めた、AIエージェントを使ってシステムの移行とモダナイゼーションを進めるサービスです。VMware環境の移行、IBMメインフレームのCOBOLアプリケーションの刷新、.NETアプリケーションのアップグレードの3つから始まり、対象を広げています。

AWSは2026年8月12日、このサービスの一般提供から1年の成果をブログで公開しました（原文は同年5月）。@ITが9月9日に日本語で報じています。

発表の数字を、期間側と費用側に分けて並べます。各行の太字が何を測った数字かです。

期間の行は、AIエージェントがコードを解析し、変換し、テストを支援した速さです。費用の行は、移行先がAWSになったことで計算資源とライセンスの支払いが減った割合です。AIを使わずにクラウドへ移行しても、費用の行の数字は出ます。

期間の数字は「何年も」との比較です

6週間という数字の比較相手は「従来は何年もかかっていた」です。どの企業の、何年何か月かは書かれていません。ADPの事例も「数年ではなく数週間」で、Signaturitは「当初6〜8か月を見込んでいた作業」との比較です。

比較の基準が見込みなのか実績なのかで、倍率は大きく変わります。IBMの事例で9か月と3日という数字を扱ったとき、同じ案件の別の資料には「典型的な約30日との比較で90%短縮」という数字もありました。計画見込みとの比較と、類似作業の実績との比較で、75倍と10倍の差が出ています。

期間の数字が本物であることと、自社で同じ倍率が出ることは別です。AWSの発表でも事例は1社ずつです。倍率を提案書に転記されたら、どの工程を測ったか、人の検証はどこに入るかを聞く手順は変わりません。

費用の数字はクラウド移行の数字です

35%、45%、60%という削減率は、AWSの発表では「これらのお客様による評価では、AWSに移行することでコンピューティングが平均35%、ライセンスが45%節約され、クラウドに移行することでコストを60%削減できる」と書かれています。

主語はAIではなく、AWSへの移行です。オンプレミスのサーバーとソフトウェアライセンスの費用が、クラウドの利用料に置き換わったときの差です。VMware環境の移行では、この差が大きく出ます。

提案書では、この60%が「AIモダナイゼーションで60%削減」と書き換えられることがあります。読む側が確認するのは、削減の対象が何かです。

• 計算資源とライセンス。移行先がクラウドになれば、AIを使わなくても変わる部分
• 移行作業の工数。AIが変換とテストを担うことで減る部分。発表では160万時間、810人年という集計で示されています
• 移行後の運用と改修の工数。発表には出ていません。刷新後のシステムを誰が保守するかは、別の見積もりです

AWSが顧客から求められた2つのこと

発表の後半に、AWSが1年で学んだ4つの知見があります。製品の設計方針の話ですが、発注側に直接効くのは2つです。

刷新は開発者だけで完結しない

AWSは「エンタープライズモダナイゼーションはマルチプレイヤーです」と書いています。アーキテクトが目標状態を定義し、開発者が実行し、リーダーがレビューと承認を行う。ボトルネックはAIの速さではなく、オーケストレーション、ガバナンス、チーム間の連携だと述べています。だからサービス側に、移行元から移行先までの追跡可能性と、誰が実行しても同じ結果になる一貫性を持たせた、と。

発注側から見ると、これは自社の側に置くべき役割の一覧です。目標状態を定義する人、承認する人が自社にいなければ、AIがどれだけ速くても止まります。900人月の見積もりの差が「分かっていない範囲の値段」だった話と同じで、AIは要件を決める人の代わりにはなりません。

人が介入できることと、同じ結果が出ること

もうひとつ、顧客が求めたものとしてAWSが挙げているのは、必要に応じて人が作業に介入できることと、精度と再現性が必要な場合に決定論的な手法を選べることです。メインフレームの刷新では、決定論的な分析とAIによる生成を組み合わせる設計になっています。Windowsの刷新では、自律的な流れを止めずに専門家がいつでも介入して一歩下がれる、と書かれています。

AIに全部任せたい、という顧客の声ではありません。同じ入力なら同じ出力が返ってくる部分と、AIが判断する部分を分けたいという声です。この区別は、AIが読んでいない範囲を報告しない問題と、AIが良かれと思って直した箇所が暗黙仕様だった問題の両方に関わります。生成の部分が大きいほど、検収で確かめる範囲は広がります。

日本の発注側で変わらないこと

事例はIBM系メインフレーム、VMware、.NETです。国産メインフレームの話は出てきません。富士通や日立の独自スタックでは公開情報が薄く、AIの効きが落ちることはメインフレーム撤退の回に書きました。AWSの発表がその見方を変える材料にはなりません。

変換とテストが速くなったあと、自動化率の裏で誰が残りを担うか、テストの分母を現行側に置くか移行先に置くかという確認も変わりません。速くなった工程の外側に、発注側の判断が残ります。

数字の出どころと限界

この記事の数字は、AWSが2026年8月12日に日本語で公開したブログ「1年間の経験。45億行のコード。160万時間の節約。そして私たちが学んだこと。」（原文は2026年5月14日公開）と、@ITの2026年9月9日の記事に基づきます。45億行超、160万時間超、6週間、35%・45%・60%、40%と4倍（@ITでは4分の1）、CSL・ADP・Signaturitの事例、810人年、4つの知見はAWSのブログの記載です。

期間の数字の比較相手となる「従来」の具体的な年月、各事例の対象規模の詳細、移行後の運用工数は公開されていません。AWSの発表は自社サービスの成果報告であり、第三者による検証は付いていません。この記事の「期間側・費用側」の分け方は、発表の記述から発注側の確認項目として整理したもので、AWSの区分そのものではありません。

自社のレガシー環境でAIをどこまで使えるか、現状調査から整理したい場合はお問い合わせからご相談ください。削減率ではなく、現行仕様の残り具合と、移行後に誰が保守するかを確かめるところから入ります。