🧹 技術調査 - AWS Transform Continuous Modernization

本記事は 2026 年 6 月 17 日の preview 発表時点の情報に基づきます。preview 段階のため、仕様は変更される可能性があります。continuous modernization 固有の手順が未公開な箇所は、公式 User Guide の atx ct コマンドリファレンスや公式記載の機能から導いた運用案を「実装案」として明示します。

概要

AWS Transform – continuous modernization は、組織が保有するコードリポジトリ群の技術的負債を継続的に検出・優先順位付け・自律修復する AWS Transform の新機能（preview）です。

解決する課題

従来の技術的負債対応は、大規模な一括移行プロジェクトとして計画されがちでした。実施コストの高さと実施頻度の低さから、負債が蓄積し続けるジレンマがありました。AWS Transform – continuous modernization は「モダナイゼーションをプロジェクトではなく継続プロセスとして扱う」という思想に立ちます。ポリシー・ベースライン・修復キャンペーンという三層として整理できる仕組みで、技術的負債を組織横断で管理します。

AWS Transform 本体における位置づけ

AWS Transform は、インフラ移行・メインフレームモダナイゼーション・Windows アプリ近代化・コードモダナイゼーションをカバーするエンタープライズ向け変革支援サービスです。continuous modernization はその「コードモダナイゼーション」領域を拡張し、単発変換から常時稼働の自律修復へ進化させた機能に位置づきます。

特徴

スキャンと発見

• リポジトリを設定済みベースラインと照合して継続スキャンし、発見事項を数週間ではなく数時間で生成します（preview 段階の情報）。
• 組織全体の多数のリポジトリを横断して、どのリポジトリが組織標準から逸脱しているかを可視化します。
• ポートフォリオ俯瞰ダッシュボード・重大度/カテゴリ/リポジトリ別の詳細ビュー・接続済みリポジトリ一覧の 3 ビューを提供します。

ポリシーとベースライン

• OOTB（Out-of-the-Box）ポリシー: EOL（End of Life）依存パッケージの検出・非推奨フレームワークの検出をすぐに利用できます。
• カスタムポリシー: 組織固有の承認ライブラリ一覧・内部コーディング標準・プラットフォームチームが定義した技術的負債ポリシーを追加できます。

自律修復キャンペーン

• 発見事項に対して自律修復を設定すると、対象リポジトリへの Pull Request を自動生成します。
• Java バージョンアップグレード・AWS SDK 移行・ライブラリ更新などの組み込み変換テンプレートを提供します。
• カスタム変換パターンを追加して組織固有のリファクタリングも自動化できます。
• 修復は検証済み PR（validated PR）として生成されます。AWS Transform custom 側には実行フィードバックを知識として蓄積する continual learning の仕組みがあります。continuous modernization 側での反映範囲は preview 段階のため要確認です。

分析タイプ

公式の分析タイプは 6 種です。

2 つの動作モード（ブログのフレーミング）

• continuous モード: 日次更新・セキュリティパッチ・コーディング標準の適用をリポジトリ全体に継続的に適用します。実装上は EventBridge Scheduler による定期分析で実現します。
• campaign モード: フレームワーク移行やメジャーランタイムバージョンアップグレードなど、多数のアプリに及ぶ大規模な単発モダナイゼーション施策を対象とします。

AWS Security Agent 連携

AWS Security Agent と統合し、ソースコードレベルの脆弱性の検出と修復まで対応します。検出された脆弱性は技術的負債の所見と同じ優先度リスト・PR ワークフローに合流します。

アクセス方式

• Kiro Power / agent plugin（公式推奨）: Kiro IDE の AWS Transform Power、または awslabs/agent-plugins の plugins/aws-transform（Claude Code / Codex / Cursor 対応）。エージェントスキルが setup から修復までを会話的にオーケストレーションします。
• CLI（atx ct）: continuous modernization 専用のサブコマンド体系。
• MCP（Model Context Protocol）: awslabs/mcp で提供。
• AWS Transform Web アプリケーション: ポートフォリオ・所見の可視化。

関連技術との比較

Dependabot / Renovate はパッケージマネージャーの依存グラフを監視対象とするため、フレームワーク移行やコーディング標準の適用は対象外です。静的解析ツールはコード解析による発見に特化し、修復 PR の自動生成は別途ワークフローを必要とします。AWS Transform – continuous modernization はスキャン・優先順位付け・PR/MR 生成を単一プラットフォームで完結させる点で差異があります。

構造

公式記載の機能から論理構造を再構成しています。preview 段階のため内部実装の詳細は非公開であり、以下の図はブログ・ドキュメントに記載された機能群を論理コンポーネントとして整理したものです。

システムコンテキスト図

コンテナ図

接続層

分析層

所見層

修復層

提示層

外部インテグレーション

コンポーネント図

検出エンジンのドリルダウン

修復キャンペーンオーケストレータと PR 生成エンジンのドリルダウン

修復キャンペーンオーケストレータ

PR 生成エンジン

ポリシー・ベースライン管理のドリルダウン

データ

preview 段階で公式 ER は未公開です。以下はブログ登場概念から妥当にモデル化したものです。公式ドキュメントでは中核概念が Source / Repository / Analysis / Finding / Remediation / TransformationDefinition として定義されています。本モデルの Campaign はブログ表現「remediation campaign」を一作業単位として表したもので、公式の Analysis と Remediation に対応します。

概念モデル

情報モデル

構築方法

continuous modernization は Kiro Power または agent plugin（エージェントスキル）経由の利用が公式推奨です。エージェントが setup・onboarding・source 接続・分析実行・所見トリアージ・修復までを会話的にオーケストレーションします。CLI を直接使う場合は専用の atx ct コマンド体系を使います（custom transformation 用の atx custom ... とは別系統です）。すべての分析・修復は利用者の AWS アカウント内で利用者のクレデンシャルを使って実行され、ソースコードは利用者の管理下にとどまります。

推奨セットアップ（Kiro Power / agent plugin）

agent plugin / Kiro Power には次のエージェントスキルが含まれます。

前提条件（CLI 利用時）

• Node.js 22 以降
• Git（有効な Git リポジトリ内での実行が必要）
• OS: Linux / macOS / WSL（Windows ネイティブは非対応）
• IAM: ユーザー/ロールに AWS Transform のマネージドポリシーをアタッチ

セキュリティ分析や EC2 / Batch 実行を使う場合、CloudFormation・IAM・S3・Secrets Manager・KMS・SSM 等への追加権限が必要です。

対応リージョン（AWS Transform CLI）

CLI のインストールと認証

# インストールスクリプトで一括インストール
curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash
atx --version

# 認証情報・リージョン
export AWS_REGION=ap-northeast-1
aws configure set region ap-northeast-1

continuous modernization サーバーの起動と source 接続

continuous modernization の操作は atx ct サブコマンドで行います。まずサーバーを起動し、source を接続します。

# continuous modernization サーバーを起動
atx ct server

# source を追加（GitHub 組織 / GitLab グループ / Bitbucket workspace / ローカル）
atx ct source add
atx ct source list

source は次の 4 タイプに対応します。

リポジトリの発見（discovery）

# source をスキャンしてリポジトリを列挙
atx ct discovery scan
atx ct discovery status

# 発見されたリポジトリを一覧（ラベルでチーム/優先度/移行ウェーブを整理可能）
atx ct repository list
atx ct repository update   # ラベル付与

利用方法

atx ct サブコマンド一覧

分析（analysis）の実行

分析タイプを --type で指定して実行します。所見は接続後数時間以内（hours, not weeks）で生成されます。

# リポジトリに対して分析を実行
atx ct analysis run --type tech-debt-quick
atx ct analysis list
atx ct analysis get

所見（findings）の確認とトリアージ

所見は重大度（high / medium / low）と状態（open / dismissed / obsolete）を持ちます。新規所見は open で始まり、誤検出は理由付きで dismiss し、再分析で解消済みは自動的に obsolete になります。自動修復可能な所見には対応する fix transform が紐づきます。

# 所見を一覧（repo / source / severity / type / status / analysis でフィルタ）
atx ct findings list --severity high --status open
atx ct findings get
atx ct findings update   # open / dismissed の状態更新
atx ct findings batch-update

修復（remediation）の作成

remediation は変換定義を適用して所見を修正します。3 つのモードがあります。

出力は source プロバイダーに依存し、GitHub は PR、GitLab は MR、Bitbucket は PR、Local はブランチを生成します。

# 所見または変換定義から修復を作成
atx ct remediation create
atx ct remediation status   # PR/MR リンクと進捗を確認
atx ct remediation retry    # 失敗した修復を再試行

変換定義（transformation definition）の確認

continuous modernization は custom 分析・修復で変換定義（TD）を利用します。利用可能な TD は custom 系コマンドで一覧します。

atx custom def list

代表的な AWS マネージド変換定義の抜粋です（公式カタログには 20 件以上が存在します）。

運用

状態監視

• atx ct status で source・リポジトリ・分析・所見・修復のシステム状態を確認できます。
• 所見は深刻度（high / medium / low）・カテゴリ・リポジトリ別に一覧化され、ポートフォリオ全体の負債状況を把握できます。
• Reporting スキルが重大度分布・修復進捗を示す HTML レポートを生成します。

compute オプション（分析・修復の実行基盤）

continuous modernization は分析・修復の実行に 3 つの compute オプションを持ちます。EC2 / Batch のセットアップは Kiro Power / agent plugin のエージェントスキルが基盤プロビジョニングを支援します。

継続的監視（スケジュール分析）

• 定期分析は Amazon EventBridge Scheduler で設定します。日次・週次・カスタム cron で繰り返し分析を起動し、新規所見を継続的に監視できます。
• 自動修復と組み合わせることで、コードの健全性を継続的に維持できます。

修復の進捗追跡

• atx ct remediation status で各修復の状態と PR/MR リンクを確認できます。失敗した修復は atx ct remediation retry で再試行します。
• 所見の状態は再分析で自動更新され、解消済みは obsolete になります。

所見のトリアージ運用

公式記載の機能から導いた運用案として、以下のスクリーニングポリシーを推奨します。

high   → 即時修復（PR 生成 + CI 通過後にレビュー）
medium → 日次バッチで PR 生成、レビュアーに割り当て
low    → 記録のみ（次スプリントの積み残しキューに追加）

CI/CD パイプラインとの統合運用

• 公式に明確なのは EventBridge Scheduler による定期分析と、GitHub / GitLab / Bitbucket への PR/MR 生成です。
• CodePipeline・Jenkins・GitHub Actions 等の既存パイプラインからの起動は、atx ct を CI のシェルステップで呼ぶ実装案として扱います（以下は実装案）。

# GitHub Actions 統合例（公式記載の機能から導いた実装案）
name: transform-ct-scan
on:
  schedule:
    - cron: "0 0 * * *"
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Install AWS Transform CLI
        run: curl -fsSL https://transform-cli.awsstatic.com/install.sh | bash
      - name: Run continuous modernization analysis
        env:
          AWS_REGION: ap-northeast-1
        run: |
          aws configure set region $AWS_REGION
          atx ct analysis run --type tech-debt-quick

ベストプラクティス

「自動 PR を出す基準」と「マージしてよい基準」を分けて設計する

AI 自動修復の失敗事例の多くは、PR 生成の判断とマージの判断を同一視したことに起因します。この 2 つを分離して設計することが最も重要です。

PR 自動生成を許可しても、自動マージは段階的に解禁します。最初は「high のみ」から始め、実績を積んでから medium に拡大する段階適用が安全です。

何を技術的負債とみなすか（ベースライン・ポリシー設計）

• OOTB ポリシー（EOL 依存・非推奨フレームワーク・一般的な技術的負債）を起点に、組織固有ルールを追加してベースラインを拡張します。
• ベースラインは最初から厳格にしすぎず、現状のポートフォリオで達成可能なラインを起点に段階的に引き上げます。

修復の優先度付け

• high は例としてセキュリティ脆弱性や重要な移行・agentic readiness ブロッカー。即時対応。
• medium は重大な懸念。次スプリントで対応。
• low はアドバイザリー。技術的負債バックログとして積み上げ。
• コンテキスト感応型スコアリングを活用します。同じ欠如でも、書き込みを行うサービスでは high、読み取り専用では low になる場合があります。

PR レビュー担当の運用設計

• PR にはリポジトリのオーナーチームを必ずレビュアーとして割り当てます。AI が生成した変更でも「チームが理解・承認した変更」として扱う文化が重要です。
• 大規模（多数リポジトリ）では、変換カテゴリごとに専任チームをレビュアーに指定してレビュー負荷を分散します。

ロールアウトの段階適用

Phase 1 (Pilot)   : 1〜3 リポジトリで所見の品質を検証
Phase 2 (Low-Risk): 低重要度リポジトリに展開
Phase 3 (Scale)   : 全ポートフォリオへ展開、キャンペーンモードで大規模移行
Phase 4 (Steady)  : Continuous モードに移行し、モダナイゼーションを背景プロセス化

Preview 段階でのスコープ限定

• サポートされる分析タイプ・変換タイプと接続可能な source を確認してから本番リポジトリに適用します。
• Preview 期間中は変換品質・仕様が変更される可能性があるため、本番クリティカルなリポジトリは Pilot フェーズのみに限定し、GA 後にスコープを拡大する方針が安全です。

トラブルシューティング

まとめ

AWS Transform – continuous modernization は、技術的負債の検出から自律的な PR 生成までを継続プロセスとして回す preview 機能です。ポリシー・ベースライン・修復キャンペーンと専用 CLI（atx ct）で、組織横断のモダナイゼーションを背景プロセス化します。本番導入では「自動 PR を出す基準」と「マージしてよい基準」を分けて設計することが要点になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります！

参考リンク

• 公式ブログ
  • Proactively reduce tech debt autonomously with AWS Transform – continuous modernization (preview)
  • Top announcements of the AWS Summit in New York, 2026
  • New in AWS Transform: Analyze Your Code for Modernization and Agentic Readiness
  • Building a scalable code modernization solution with AWS Transform custom
• 公式ドキュメント
  • AWS Transform User Guide
  • AWS Transform 公式サイト
  • AWS CodeConnections セットアップガイド
• GitHub
  • awslabs/agent-plugins
  • awslabs/mcp
• 記事
  • AWS Summit New York 2026: New ways to make AI agents more effective at work