Amazon Web Services ブログ

AWS Transform custom: Learn-Scale-Improve フライホイールによるエンタープライズのコードモダナイゼーション

本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。

エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリポジトリを変換するだけなら容易です。AWS Transform custom でも、他の既存のツールでも、個別のリポジトリに対して十分に機能し、プロセスも確立されています。しかし、50 のリポジトリではどうでしょうか。100、200 ではどうでしょうか。エンタープライズ規模でモダナイゼーションを進めようとすると、コードを変換することは課題全体の一部にすぎません。人員の調整、ナレッジの蓄積、そしてポートフォリオ全体における品質の維持も重要になります。

本記事では、AWS Transform custom の大規模な自動化の仕組みが、インテリジェントな学習とスケール実行によって、エンタープライズにおける組織内連携の課題をどう解決するかをご紹介します。あるお客様は、モダナイゼーション全体の期間を 7-12 週間から 2.5 週間へと短縮し、デリバリー期間を 3-5 分の 1 に、総工数を 10-20 分の 1 に削減しました。そして何より、ご自身のモダナイゼーションの取り組みを今すぐ始めるための方法をお伝えします。

エンタープライズ規模における組織内連携の課題

エンタープライズのアーキテクトに直近の大規模モダナイゼーションについて尋ねると、きまって同じような話を耳にします。例えば、あるエンタープライズソフトウェア企業では、大規模なレガシーコードベースをモダンなプラットフォームへ移行する必要がありました。当初の見積りは、複数チームにまたがる調整作業を含めて 12 週間の集中的な作業でした。

コード変換そのものは数日で完了しました。しかし残りの数週間は、コード変換を取り巻く一連の作業に費やされました。具体的には、タイムゾーンをまたぐチームの調整、異なる経緯を持つコードベース間でのパターンの一貫性の確保、そして上流の変更が下流のシステムを壊さないよう依存関係を管理することです。各チームはミーティングやスプレッドシートでステータスを追跡し、シニア開発者の頭の中にしか存在しない暗黙知に頼っていました。

これがエンタープライズにおける組織内連携の課題です。1 つのリポジトリから数百のリポジトリへとスケールするとき、連携のオーバーヘッドは爆発的に増大します。リポジトリが 1 つ増えるごとに、そのリポジトリ自身の複雑さだけでなく、新たな連携箇所、エッジケース、そして想定外の調整要件が加わるのです。

見落とされがちな 70% のギャップ

エンタープライズの案件において、私たちはコード変換がモダナイゼーション作業全体の約 30% にすぎないことを確認してきました。残りの 70% には、テスト生成、検証、包括的なドキュメント作成、ビジネス分析、そして数百の作業項目にまたがる組織的な調整などが含まれます。

このギャップこそが、変換ツールによる生産性向上がなかなか実を結ばない理由です。ツールがコードの変更は処理できても、組織は連携、検証、ナレッジの蓄積に依然として苦労しています。変換作業は迅速に終わるのに、プロジェクト全体は数か月を要するという状況です。

実際に私たちが目にしてきたのは、従来のアプローチがエンタープライズ規模で機能しないという事実です。各リポジトリを独立した課題として扱ってしまうからです。チームはコードベース間で同じ作業を繰り返し、一貫性のない判断を下し、開発者が別のプロジェクトへ異動するたびに学びを失っていきます。組織のナレッジは再利用可能な資産とならず、個人の頭の中に閉じ込められたままです。

エンタープライズモダナイゼーションへの新しいアプローチ

AWS Transform custom は、エンタープライズモダナイゼーションに対して異なるアプローチをとります。同じ操作を何百回も繰り返すのではなく、すべての実行から学習し、そこで得た知見を次の変換の改善に活用します。

Learn-Scale-Improve フライホイール

この Learn-Scale-Improve(学習・スケール・改善)フライホイールのワークフローは、リスクを最小化しつつ学習効果を最大化するよう綿密に設計されたステップで進みます。まず小規模な Learn (学習) パイロットから始め、一括自動化を通じて Scale (スケール) し、計画的なレビューによって Improve (改善) する。このサイクルを繰り返すフライホイールによって、イテレーションのたびに前回よりも良い結果を生み出します (図 1)。

AWS Transform custom のイテレーション型変換ワークフロー。LEARN (対話型モードでのパイロット、変換定義の洗練) → SCALE (一括実行、夜間処理) → IMPROVE (レビューとナレッジアイテムの承認) の 3 ステージを示す図。矢印は、Learn から Scale へ組織のナレッジが流れ、Scale から Improve へ発見されたエッジケースが流れ、Improve から Learn へ変換定義の改善がフィードバックされるサイクルを表現している。
図 1: AWS Transform custom の変換ワークフローにおける Learn-Scale-Improve フライホイール

Learn (学習): 代表的な 2-3 個のリポジトリを対象に、インタラクティブモードで変換を実行するところから始めます。AI エージェントと直接やり取りしながら、各ステップでの判断にフィードバックを提供し、品質を検証します。エージェントが曖昧な箇所に遭遇すると質問を投げかけ、お客様がガイダンスを与えると、システムがそのコンテキストを記録します。パイロットの最後には、蓄積されたフィードバックを確認して変換定義を修正します。その結果として得られるのは、お客様の組織のナレッジが組み込まれた、スケール実行の準備が整った変換定義です。

Scale (スケール): 次に、自律モードへ切り替えて一括実行を行います。システムは数十、数百のリポジトリを一晩で、手動介入なしに処理し、パイロットで学習したパターンを適用します。ビルドコマンドやテストコマンドを使用して変換結果を検証し、ポートフォリオ全体の進捗状況をリアルタイムで追跡します。これまで数週間のチーム調整を要していた作業が、一晩で完了します。実行中、システムは新しいエッジケース、想定外のパターン、パイロットでは見えてこなかった最適化の機会などを発見事項として記録します。

Improve (改善): 一括実行のラウンドが終わるごとに、処理中にシステムが記録したナレッジアイテムをレビューします。これらの発見事項は、パイロットではカバーできなかったリポジトリ特有のパターンやエッジケースを浮き彫りにします。その中から価値のある学びを承認することで、次のイテレーションに向けて変換定義が改善されます。このレビューステップが品質管理の役割を担います。システムは自己改変せず、どの学びを取り込むかを決めるのは、変換定義のオーナーです。

Scale と Improve のサイクルは繰り返されます。一括実行のラウンドごとに得られたインサイトが、次のラウンドをさらに効果的にします。変換の成功率は向上し、手動介入は減少し、エッジケースのハンドリングもイテレーションを重ねるたびに改善されます。

このフライホイールは、エンタープライズが組織としてナレッジをどう蓄積し共有するかを大きく変えます。変換定義は単なる自動化スクリプトではありません。特定のモダナイゼーションシナリオに対して、自社がどう取り組むかを体系化した組織資産です。アーキテクトが変換戦略を定義すると、その戦略は再利用可能な定義としてレジストリに保存されます。チームがベストプラクティスを特定すると、それらは変換定義の中に埋め込まれ、すべてのリポジトリに自動的に適用されるようになります。従来であれば、シニア開発者がチームを離れれば、そのナレッジも一緒に消えてしまっていました。AWS Transform custom を利用すれば、その専門知識を変換定義やナレッジアイテムとして蓄積し、組織全体で使える形にできます。個人の専門性が、組織のケイパビリティへと昇華するのです。

エンタープライズのお客様によるモダナイゼーション事例

これらの生産性向上は理論上の予測ではなく、実際の本番環境での成果です。あるエンタープライズソフトウェア企業では、本番環境で稼働する大量の Control-M(訳註: BMC Software 社のワークロード自動化プラットフォーム)のワークフローを Apache Airflow へ移行する必要がありました。このモダナイゼーションには、技術的な精密さと、複雑かつ相互依存するコードベース全体における一貫性の両方が求められました。当初の見積りでは、複数チームでの集中的な調整に 12 週間を要するとされ、一貫性の欠如や統合失敗のリスクも抱えていました。

この企業は、AWS Transform custom を活用して Learn-Scale-Improve のイテレーション型ワークフローを実行しました。パイロットフェーズでは、代表的なリポジトリに対してインタラクティブモードでの変換を実行し、結果をレビューしたうえで変換定義を洗練させました。イテレーションを重ねるごとに、変換定義はエッジケースへの対応精度を高めていきました。その後、自律モードの一括実行へと移行し、ポートフォリオ全体の移行を 2.5 週間で完了しました。

検証の結果、対象となったすべてのワークフローで 100% の成功率を達成しました。エッジケースのハンドリングは従来のアプローチと比べて 60% 改善し、変換後のコードは業界の専門家が求めるコード品質基準を満たしながら、実行時のパフォーマンスも 19% 向上しました。この事例は、移行のスピードと本番品質の両立が可能であることを示しました。従来のアプローチと比較して、デリバリー期間を 3-5 分の 1 に、総工数は 10-20 分の 1 に削減しました。

ポートフォリオ全体の変換を始めましょう

AWS Transform custom の大規模な自動化の仕組みは、GitHub リポジトリでソリューションとして提供されています。Learn-Scale-Improve ワークフローに沿って、モダナイゼーションの取り組みを始めてみてください。

前提条件

開始前に、以下をご確認ください。

  • AWS Transform custom へのアクセスが有効化された AWS アカウント
  • 適切な認証情報で構成された AWS CLI
  • ローカルマシンまたは CI/CD 環境にインストールされた Git
  • AWS Transform custom の操作に必要な IAM 権限

実装の進め方

AWS Transform custom は、Java のアップグレード (例: 8 から 17、17 から 21)、Python の移行 (例: 3.7 から 3.11)、Node.js のアップデート (例: 14 から 20)、AWS SDK の移行 (例: boto2 から boto3、SDK v1 から v2) など、多様な変換をサポートしています。これらの AWS マネージドな変換に加えて、組織固有の標準、独自のフレームワーク移行、各環境特有のアーキテクチャパターンに対応するカスタム変換定義を作成することもできます。

AWS Transform custom は、既存の開発プロセスに自然に統合できます。CLI は Jenkins、GitLab CI、GitHub Actions といった CI/CD パイプラインと連携します。変換結果はローカルの Git ブランチとして生成され、お客様の標準的なコードレビュー・マージプロセスに沿って流れていきます。Web インターフェイスでは、チーム横断での進捗状況を一元的に可視化できます。検証コマンドは変換処理中に自動的に実行され、変更が完了したと見なされる前にコードが正常にビルドされ、テストが通過していることを保証します。変換処理の終了時に検証条件を満たさない場合、その変換は失敗として扱われます。

スケール実行までの道のりを加速するため、AWS は本番環境で利用できるスタート地点となるオープンソースのサンプルリポジトリを提供しています。複数のリポジトリと変換定義に対して同時に変換を実行するためのものです。aws-transform-custom-samples の scaled-execution リポジトリには、一括実行をオーケストレーションするスクリプト、リポジトリのキューイングを管理する仕組み、ポートフォリオ全体のステータス追跡を扱うスクリプトが含まれています。オーケストレーションをゼロから構築するのではなく、サンプルをクローンし、ご自身のリポジトリリストと変換定義で設定すれば、すぐにスケール変換の実行を始められます。

まとめ

エンタープライズ規模でのモダナイゼーションには、コード変換ツール以上のものが必要です。本当の課題は、チーム間の連携、実行からの学習、そしてナレッジを組織資産として蓄積することにあります。AWS Transform custom の Learn-Scale-Improve ワークフローは、これらの課題に対して、実行のたびに品質を高める継続的学習、暗黙知を再利用可能な資産へと変える組織ナレッジの捕捉、そして数百のリポジトリに一貫して適用できる一括自動化で応えます。次に重大なセキュリティ脆弱性が発見され、リポジトリ全体のフレームワーク更新が必要になったときも、新しいランタイムのバージョンでパフォーマンスを改善できるようになったときも、すでに効果を検証済みの変換定義を使って、数か月ではなく数日単位で対応できるようになります。

実際のお客様は、デリバリー期間を 3-5 分の 1、総工数を 10-20 分の 1 に削減し、モダナイゼーションを数か月から数週間に圧縮しています。これは願望ではなく、AWS Transform custom を活用している組織が本番環境で実現している成果です。

今すぐ変換を始めましょう

まずは 2-3 個の代表的なリポジトリを対象に Learn-Scale-Improve ワークフローを実施し、変換定義を洗練させたうえで、ポートフォリオ全体へと展開してください。

AWS Transform custom の大規模な自動化の仕組みをさらに深く知るには、以下のリソースをご覧ください。

  • AWS Transform custom ドキュメント: 全機能、API リファレンス、統合ガイドを網羅した技術ドキュメント: AWS Transform custom
  • Scaled Execution サンプルリポジトリ: 複数のリポジトリと変換定義に対して変換を実行するためのオープンソーススクリプト: aws-transform-custom-samples
  • Transformation Registry: AWS マネージドな変換の発見と、カスタム定義の作成: aws-transform-custom-samples

取り組みを開始するには、AWS アカウントチームにお問い合わせいただくか、AWS Transform custom のドキュメントをご参照ください。

著者について

meghan-author

Meghan Kothari

Meghan Kothari は、Customer Experience and Business Trends チームのシニアテクニカルプロダクトマネージャーです。AWS のリーダーシップと連携し、Agentic AI を活用したアプリケーション開発とモダナイゼーションにおける進化するトレンドを発見するための戦略的な Deep Dive に取り組んでいます。ソリューションアーキテクトおよびフルスタック開発者としての経歴により、開発者体験の形成に貢献する独自の実践的な視点を持っています。

Venu-author

Venugopalan Vasudevan

Venugopalan Vasudevan (Venu) は、AWS のプリンシパルスペシャリストソリューションアーキテクトであり、AWS Transform に焦点を当てた Agentic AI の取り組みを主導しています。お客様が AI を活用した開発者向けソリューションおよびモダナイゼーションソリューションを採用しスケールさせ、イノベーションとビジネス成果を加速できるよう支援しています。

grilli-author

Rodney Grilli

Rodney Grilli は、AWS のプリンシパルテクノロジストであり、Agentic AI サービスを活用した製品およびコードのモダナイゼーションを専門としています。お客様が製品ポートフォリオをモダナイズし、AI-Native Enterprise への変革を加速できるソリューションを構築しています。