カスタム

AWS Transform custom とは

AWS Transform Custom は、エージェント AI を使用してソフトウェア、コード、ライブラリ、フレームワークの大規模なモダナイゼーションを実行し、技術的負債を削減します。言語バージョンのアップグレード、API とサービスの移行、フレームワークのアップグレードと移行、コードリファクタリング、組織固有の変換など、さまざまなシナリオを処理します。

継続的な学習を通じて、エージェントはすべての実行とデベロッパーのフィードバックから改善し、特別なオートメーションの専門知識を必要とせずに、高品質で反復可能な変換を提供します。

主な機能

AWS 変換カスタムには次の機能があります。

• 自然言語駆動型変換定義 - 自然言語、ドキュメント、コードサンプルを使用してカスタム変換を作成する

• 変換の実行 - 複数のコードベースに一貫して確実に変換を適用します。

• 継続的な学習 - すべての実行から変換品質を自動的に改善する

• AWSマネージド変換 - 一般的なシナリオでready-to-use AWS、検証済みの変換を使用します。

変換パターン

AWS 変換カスタムは、モダナイゼーションのニーズに対応するための多様な変換パターンをサポートしています。各パターンには、必要な変更の範囲と性質に基づいて異なる複雑さの特性があります。

パターン	説明	複雑さ	例
API とサービスの移行	機能を維持しながら API バージョンまたは同等のサービスを移行する	中	AWS SDK v1→v2 (Java、Python、JavaScript)、Boto2→Boto3、JUnit 4→5、javax→jakarta
言語バージョンのアップグレード	同じプログラミング言語の新しいバージョンへのアップグレード、新機能の採用、廃止された機能の置き換え	低～中	Java 8 → 17、Python 3.9 → 3.13、Node.js 12 → 22、TypeScript バージョンアップグレード
フレームワークのアップグレード	同じフレームワークの新しいバージョンにアップグレードし、重大な変更に対処する	中	Spring Boot 2.x→3.x、React 17→18、Angular アップグレード、Django アップグレード
フレームワークの移行	同様の目的を果たすまったく異なるフレームワークへの移行	高	Angular→React、Redux→Zustand、Vue.js→React
ライブラリと依存関係のアップグレード	同じ言語とフレームワークを維持しながら、サードパーティーライブラリを新しいバージョンにアップグレードする	低～中	Pandas 1.x→2.x、NumPy アップグレード、Hadoop/HBase/Hive ライブラリアップグレード、Lodash アップグレード
コードリファクタリングとパターンモダナイゼーション	外部機能を変更せずにコードパターンをモダナイズし、ベストプラクティスを採用する	低～中	Print→Logging フレームワーク、文字列連結→f-strings、型ヒントの採用、オブザーバビリティ計測
スクリプトおよびFile-by-File変換	ファイルの大部分が自己完結型である独立したスクリプトまたは設定ファイルの翻訳	低～中	AWS CDK → Terraform、Terraform → CloudFormation、Excel → Python ノートブック、Bash → PowerShell
アーキテクチャの移行	最小限のコード変更でハードウェアアーキテクチャまたはランタイム環境を移行する	やや高い	x86 →AWS Graviton (ARM)、オンプレミス →Lambda、従来のサーバー →コンテナ
Language-to-Language移行	あるプログラミング言語から別のプログラミング言語へのコードベースの翻訳	非常に高い	Java→Python、JavaScript→TypeScript、C→Rust、Python→Go
カスタムおよび組織固有の変換	独自の組織要件と特殊なモダナイゼーションのニーズ	可変	カスタム内部ライブラリ移行、組織固有のコーディング標準、独自のフレームワーク移行

注記

COBOL/メインフレーム言語の場合は、メインフレームの AWS 変換を使用します。.NET Framework を .NET Core にアップグレードするには、Windows の AWS 変換を検討してください。VMware への移行については AWS、 AWS Transform for VMware を検討してください。

AWS Transform カスタムの仕組み

AWS 変換カスタムは通常、複数のコードベースまたはモジュールが変換される大規模なプロジェクトで使用されます。チームは通常、次の 4 フェーズのワークフローに従います。

変換の定義 - エージェントに自然言語プロンプト、ドキュメント、コードサンプルを提供し、最初の変換定義を生成します。この定義は、チャットまたは直接編集によって繰り返し改良できます。 AWSマネージド変換を使用する場合、このフェーズはスキップできます。

パイロットまたはProof-of-Concept - サンプルコードベースで変換をテストし、結果に基づいて絞り込みます。この検証フェーズは、完全な変換のコストと労力を見積もるのに役立ちます。このフェーズでは、継続的な学習により品質が向上します。

スケーリングされた実行 - CLI を使用して自動一括実行を設定し、開発者が結果を確認して検証します。ウェブアプリケーションを使用して進行状況をモニタリングし、複数のリポジトリ間の変換を追跡します。

モニタリングとレビュー - 継続的な学習により、変換の品質が自動的に向上します。以前の実行から抽出された教訓を確認して品質基準を満たしていることを確認し、役に立たない教訓をアーカイブします。

の重要な概念の理解

このセクションでは、 AWS 変換カスタムを使用するための主要な概念について説明します。

変換の定義

変換定義には、特定のコード変換を実行するために必要な手順と知識が含まれています。スキルとして表され、以下で構成されます。

• SKILL.md (必須) - コア変換ロジックと実行手順を含む YAML フロントマター (name および descriptionフィールド) を使用した Markdown の手順

• references/ folder (オプション) - 変換の実行中に必要に応じてロードされたドキュメント

• scripts/ folder (オプション) - 実行中に変換がダウンロードして実行するスクリプト

AWS Transform CLI は、実行、検査、または変更に必要なときに、変換定義を現在のディレクトリに自動的にダウンロードします。

重要

変換を公開する場合、ディレクトリには のみを含める必要があり、SKILL.mdオプションで references/フォルダ、 scripts/フォルダ、またはその両方を含める必要があります。他のファイルやサブディレクトリは許可されません。

注記

CLI バージョン 2.0 以降では、スキル形式が使用されます。既存の変換定義は CLI によって自動的に処理されます。

変換定義カテゴリ

変換定義には、その使用方法を示すカテゴリを含めることができます。

• analysis – コードを読み取り、検出結果を報告します。継続的なモダナイゼーションは、これらの変換定義をカスタム分析として実行します。

• remediation – コードを変更します。継続的なモダナイゼーションでは、これらの変換定義を使用して検出結果を修復します。

atx custom def publish または --categoryのオプションを使用してカテゴリを設定しますatx custom def save-draft。

atx custom def publish -n <transformation-name> --description "Description" --sd <directory> --category analysis
atx custom def publish -n <transformation-name> --description "Description" --sd <directory> --category remediation
atx custom def list    # The Category column shows each transformation definition's category

AWS Transform は、 カテゴリを使用して、変換定義を使用できる場所を決定します。

使用アイテム	許可される変換定義
カスタム分析 (--type custom)	analysis カテゴリを使用した独自の変換定義
による修復 --transformation-name	remediation カテゴリを含む独自の変換定義、または AWS マネージド変換

カスタム分析、スケジュール、または修復を送信する前に、 AWS Transform は変換定義のカテゴリをチェックします。

変換定義のカテゴリを変更するには、別の--category値で再度発行します。なしで新しいバージョンを発行する場合--category、新しいバージョンは以前のバージョンのカテゴリを保持します。

analysis 変換定義を実行する方法については、「」を参照してくださいカスタム分析。

注記

カテゴリはリソースタグとは異なります。リソースタグを管理するには、「」を参照してくださいタグコマンド。

分析用の変換定義を記述する

有用な検出結果を取得するには、何を探すか、各問題を分類する方法、何をしないかを記述するように変換定義を記述します。の以下のセクションをお勧めしますSKILL.md。

セクション	含める内容
序章	分析が検出した内容を示す 1 つまたは 2 つの文。読み取り専用であり、ファイルを変更してはならないことを記述します。
入力基準	分析が適用される場合。例えば、「リポジトリには pom.xmlまたは build.gradle ファイルが含まれています」。
スコープ	検査するファイルとディレクトリ、およびビルド出力やベンダーの依存関係など、スキップするファイルとディレクトリ。
レポートの内容	問題としてカウントされる特定のパターンまたは条件。ファイルパスと行番号を使用して、問題ごとに 1 つの検出結果を求めます。
カテゴリ	カテゴリ値の小さな固定セット、およびそれぞれに属する問題。
重要度の基準	問題の原因は high、medium、または ですlow。
終了条件	エージェントがそれを把握する方法: スコープ内のすべてのファイルが検査され、すべての検出結果にファイル、カテゴリ、重要度があり、ファイルは変更されませんでした。また、何も見つからないときに報告する内容についても説明します。

次の例では、まだ 17 より前の Java バージョンをターゲットとする Java プロジェクトを見つけます。

---
name: java-version-detector
description: Report where a repository still targets a Java version earlier than 17, in build files, Dockerfiles, toolchain files, and CI workflows. Analysis only - no code is modified.
---

# Java Version Detector

Find where the repository targets a Java version earlier than Java 17. This is a
read-only analysis: report findings, and do not modify any files.

## Entry Criteria

The repository contains a Java build file (`pom.xml`, `build.gradle`,
`build.gradle.kts`, or `gradle.properties`), or a file that selects a JDK
(`.java-version`, `.tool-versions`, `.sdkmanrc`, a `Dockerfile`, or a file under
`.github/workflows/`).

## Scope

- Inspect build files, toolchain files, Dockerfiles, and CI workflow files.
- Skip build output (`build/`, `target/`) and vendored dependencies.

## What to Report

Report one finding for each place that selects a Java version earlier than 17:

1. A compile target, such as `maven.compiler.source`, `maven.compiler.release`,
   `java.version`, `sourceCompatibility`, or a Gradle toolchain `languageVersion`.
2. A Dockerfile base image that ships a JDK or JRE earlier than 17, such as
   `openjdk:8` or `amazoncorretto:11`.
3. A CI job or toolchain file that selects a JDK earlier than 17.

For each finding, include the file path, the line number, and the version you found.

## Categories

- `outdated-compile-target` - a build file compiles for an old Java version
- `outdated-runtime-image` - a Dockerfile uses an old JDK or JRE image
- `outdated-ci-jdk` - a CI workflow or toolchain file selects an old JDK

## Severity Criteria

- **high** - the project compiles for Java 8 or earlier
- **medium** - the project compiles for Java 9 through 16
- **low** - only the runtime image or CI uses an old JDK, and the compile target is 17 or later

## Exit Criteria

1. Every in-scope file has been inspected.
2. Every finding has a file path, line number, category, and severity from the lists above.
3. No file in the repository has been modified.
4. If nothing is found, state that the repository targets Java 17 or later.

この変換定義が をpom.xml設定したプロジェクトに対して実行されると<source>1.8</source>、 を修正AWS/java-version-upgradeとして、 outdated-compile-target カテゴリにhigh重要度の検出結果が生成されます。

分析変換定義を記述するためのヒント

• 読み取り専用にしておきます。分析でファイルを変更してはならないことを明示的に記述します。問題の修正は修復の仕事です。

• 何が問題としてカウントされるかを具体的に説明します。検索するファイル、設定、パターンに名前を付けます。あいまいな指示では、一貫性のない結果が生成されます。

• 問題ごとに 1 つの結果を求めます。各検出結果は、個別に確認および修正できるように、特定のファイルと行を指す必要があります。

• 変換定義で重要度とカテゴリを定義します。エージェントは、条件を使用して各検出結果を分類します。

• スコープに焦点を合わせます。カスタム分析は、変換定義の説明のみをレポートします。さまざまな種類の問題を見つけるには、個別の変換定義を記述するか、組み込みの分析タイプを使用します。

• 何も見つからない場合の対処方法を説明します。問題のないリポジトリは、検出結果を正しく生成しません。

• 変換定義に検出結果の手順を含めます。-g で設定を渡すか、分析を実行する--configurationと、 AWS Transform はデフォルトの手順ではなく設定を使用します。で「報告対象」セクションを保持するとSKILL.md、変換定義によって結果が生成されます。

発行する前に、問題が含まれていることがわかっているリポジトリで変換定義をテストします。でドラフトとして保存するかatx custom def save-draft、 でローカルで実行します atx ct analysis run (「」を参照カスタム分析)。

変換レジストリ

変換レジストリは、変換定義を保存および管理するための AWS アカウントの一元化されたリポジトリです。レジストリ内の変換は次のようになります。

• を使用して一覧表示 atx custom def list

• 複数のコードベースで実行される

• AWS アカウントの他のユーザーと共有されている

• バージョン管理

重要

変換定義はアカウント固有です。別の AWS アカウントで変換を使用する場合は、そのアカウントで個別に公開する必要があります。

ドラフト変換と公開変換

AWS 変換カスタムは、レジストリ内の変換に対して 2 つの状態をサポートします。

ドラフト変換は、進行中またはテストされていない変換定義です。これらは特定のバージョンとして保存され、その特定のバージョンを参照するユーザーが取得、更新、実行できます。ドラフトは、変換をチームと共有する前に、反復的な開発、テスト、改良に役立ちます。ドラフトは特定の会話にも関連付けられます。CLI を再起動する場合は、 atx --conversation-id {id}を使用して以前の CLI を復元できます。

公開された変換は、必要な IAM アクセス許可を持つ他のユーザーが実行できるように、アカウントの変換レジストリで使用できます。公開された変換は、 を使用して検出できますatx custom def list。

一般的なワークフローは次のとおりです。

1. 変換をローカルで作成する

2. テスト用のドラフトとして保存 (atx custom def save-draft)

3. 絞り込みと検証

4. 発行してチームと共有します (atx custom def publish)

変換をドラフトとして保存せずに直接公開することもできます。

リファレンスと教訓

AWS 変換カスタムは、次の 2 種類の知識を使用して変換品質を向上させます。

リファレンスは、変換定義の references/フォルダに保存されているユーザー提供のドキュメントです。リファレンスはテキストファイルのみをサポートし (すべてのファイルの合計は最大 10MB)、通常、ドキュメント、API 仕様、移行ガイド、コードサンプルが含まれています。リファレンスは、変換の実行中に必要に応じてロードされます。インタラクティブモードで変換定義を作成または更新するときに参照を追加します。

教訓は、変換の以前の実行から自動的に抽出されます。継続的な学習システムは、実行の軌跡、開発者のフィードバック、変換中に発生したコード修正からそれらを生成します。関連する教訓をカテゴリにグループ化して、まとめて確認できるようにします。事前に提供するリファレンスとは異なり、異なるコードベース間で変換を実行すると時間の経過とともに教訓が蓄積され、システムはそれらを自動的に適用して将来の実行を改善します。を使用して、教訓をインタラクティブに確認および管理しますatx custom def learnings。

ビルドおよび検証コマンド

ビルドまたは検証コマンドは、変換プロセス中にコードを検証する方法を指定するオプションのパラメータです。このコマンドは、コードの整合性を確保するために、変換中のさまざまな時点で実行されます。

継続的な学習を通じて変換品質を向上させるには、結果を検証し、検証が失敗した場合に問題を返すコマンドを提供することが非常に重要です。ビルドまたは検証が必要ない場合は、入力から を省略します。

例と詳細なガイダンスについては、「 ワークフロー」セクションの「ビルドおよび検証コマンド」を参照してください。

継続的な学習

継続的学習は、すべての変換実行からのフィードバックを自動的にキャプチャし、時間の経過とともに変換の品質を向上させるシステムです。システムは以下を通じて情報を収集します。

• 明示的なフィードバック - インタラクティブモードで提供されるコメントとコードの修正

• 暗黙的な観測 - コードの変換とデバッグ中にエージェントが遭遇する問題

継続的な学習システムはこの情報を処理して、将来の変換を改善するために変換定義に追加する教訓を作成します。変換が完了すると、システムは学習プロセスを自動的に実行するため、追加の入力は必要ありません。

重要

教訓は変換固有であり、異なる変換や異なる顧客アカウント間で共有されることはありません。

教訓の管理

システムは教訓を自動的に生成しますが、今後の実行に適用される教訓を制御できます。atx custom def learnings コマンドは、変換が蓄積した教訓を確認してキュレートするためのインタラクティブなターミナルセッションを開きます。

このセッションでは、次のことができます。

• カテゴリ別にグループ化された教訓を参照し、各カテゴリに含まれるアクティブな教訓の数を確認します。

• 教訓を開いて、教訓本文、その影響、それを参照した以前の実行の数など、その詳細をすべてお読みください。

• システムが今後の実行に適用できないように教訓をアーカイブし、必要に応じて後で復元します。

• 不要になったアーカイブされた教訓を完全に削除します。

手順については、「継続的な学習」を参照してください。

クライアント側のスキル

クライアント側のスキルは、変換の実行中にエージェントを拡張する追加機能です。実行する変換を定義する変換定義とは異なり、クライアント側のスキルは、変換中にエージェントが組み込み機能と一緒に使用できる補足ツール、スクリプト、および指示を提供します。

クライアント側のスキルは、プロジェクトレベルおよびユーザーレベルのディレクトリから検出されます。リポジトリに固有の標準を適用する場合はプロジェクトレベルに、すべてのプロジェクトに適用される場合はユーザーレベルでスキルを配置します。プロジェクトレベルのスキルは、コードリポジトリパスが指定されている場合にのみ使用できます。詳細な設定と使用状況については、「」を参照してくださいクライアント側のスキル。

カスタム変換コマンドの概要

カスタム変換で使用できるコマンドをいくつか示します。コマンドの完全なリストは、AWS 「変換カスタム変換コマンドリファレンス」にあります。

• atx custom

  • カスタム変換インタラクティブエクスペリエンスを実行し、変換の作成、検出、実行、および改良を可能にします。

  • これは のデフォルトのコマンドですatx。

  • --trust-all-tools (-t) はオプションであり、エージェントによってリクエストされたすべてのツールリクエストを暗黙的に許可します。特に本番環境では注意が必要です。信頼設定ファイルを使用して、特定のツールとコマンドのツール信頼を設定できます。

• atx custom --help | atx custom -h

  • ヘルプメニューを表示します。

  • 各コマンドには、 などのヘルプメニューも含まれていますatx custom def exec --help。

• atx --version | atx -v

  • バージョンを表示します。

  • バージョン番号はリリースごとに変わります。

• atx custom def list

  • 変換レジストリで使用できる変換のリストを出力します。

• atx custom def exec

  • 変換を実行します。

• atx custom def learnings

  • インタラクティブセッションを開き、変換が以前の実行から学んだ教訓を表示および管理します

• atx mcp

  • MCP サーバー設定の管理に使用されます