翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS 継続的なモダナイゼーションを変革する
<a name="continuous-modernization"></a>

## AWS Transform Continuous Modernization とは
<a name="ct-what-is"></a>

AWS 継続的なモダナイゼーションを変換することで、ソースコードリポジトリの分析と修復が可能になります。GitHub 組織、GitLab グループ、Bitbucket ワークスペース、ローカルリポジトリを接続し、自動化された分析を実行して、コードベース全体の技術的負債、セキュリティの脆弱性、モダナイゼーションの機会、エージェントの準備状況を特定できます。

すべての分析と修復は、 認証情報 AWS アカウント を使用して で実行されます。ソースコードはお客様の管理下に置かれます。

**注記**  
Kiro Power またはエージェントプラグインから始めることをお勧めします。エージェントスキルは、インフラストラクチャのプロビジョニング、ソース設定、分析の実行、結果のトリアージ、修復など、継続的なモダナイゼーションのセットアップ、オンボーディング、継続的な使用を調整します。インストール手順については、「[デベロッパーツール](ct-developer-tools.md)」を参照してください。

## 主な機能
<a name="ct-key-capabilities"></a>

AWS 継続的なモダナイゼーションを変換すると、次の機能が提供されます。
+ **Tech Debt Analysis** — 古い依存関係、セキュリティの脆弱性、コード品質の問題、モダナイゼーションの機会がないかリポジトリをスキャンします。パッケージマニフェストまたは包括的なコードレベルの分析全体でクイックメタデータスキャンを実行します。環境に合わせた変換定義を使用して、カスタム分析基準を定義します。
+ **自律修復 — **検証済みのプルリクエストを大規模に生成します。各検出結果は、関連する変換定義を使用して自動修正できます。修復はブランチを作成し、GitHub、GitLab、Bitbucket 全体で PRs/MRs を自動的に開きます。
+ **レポート** — 重要度、リポジトリ、分析タイプ別に結果を示す HTML レポートを生成します。修復の進行状況と結果の解決を経時的に追跡します。
+ **継続的モニタリング** — Amazon EventBridge スケジューラを使用して定期的な分析をスケジュールします。毎日、毎週、またはカスタムの cron スケジュールを設定して、新しい問題がないかポートフォリオを継続的にモニタリングします。

## 分析タイプ
<a name="ct-analysis-types"></a>

AWS 継続的なモダナイゼーションの変換では、モダナイゼーションのニーズに対応するために、次の分析タイプがサポートされています。


| 型 | 説明 | 
| --- | --- | 
| rapid-techdebt-analysis | 古いバージョンと古い依存関係を識別するための、パッケージマニフェスト (pom.xml、package.json、requirements.txt) のメタデータのみの高速スキャン。ソースコードを分析しません。 | 
| tech-debt-comprehensive |  AWS Transform エージェントを使用した詳細なコードレベルの技術的負債分析。ソースコードを調べて、負債パターン、コード品質の問題、アーキテクチャの懸念、改善の機会を特定します。 | 
| security | セキュリティエージェントを使用した AWS セキュリティ脆弱性と CVE 検出。ソースコードと依存関係をスキャンして、既知の脆弱性、安全でないコーディングパターン、悪用可能な弱点がないかどうかを確認します。1 回限りのインフラストラクチャのセットアップが必要です。 | 
| agentic-readiness | AI とエージェントの統合の準備状況の評価。インフラストラクチャとプラットフォーム、アプリケーションアーキテクチャ、データ基盤、Identity/Security/Governance。 | 
| modernization-readiness | クラウドモダナイゼーションの機会の評価。インフラストラクチャ、アプリケーション、データ、セキュリティ、運用の各ディメンションにわたる準備状況を評価します。コンテナ化、サーバーレス移行、プラットフォームアップグレードの候補を特定します。 | 
| custom | 任意の変換定義 (TD) を分析として実行します。このタイプを使用して、独自の分析基準を定義したり、組み込みタイプでカバーされていない AWS マネージド変換を実行したりできます。 | 

## 重要な概念の理解
<a name="ct-key-concepts"></a>

### [Sources] (出典)
<a name="ct-concept-sources"></a>

ソースは、リポジトリの場所を継続的なモダナイゼーションに伝えます。サポートされているソースタイプ:
+ **GitHub** — 個人用アクセストークンを持つ組織 (クラシック)
+ **GitLab** — セルフホストインスタンスを含むグループまたはユーザー
+ **Bitbucket** — Workspaces (クラウド) またはプロジェクト (データセンター)
+ **Local** — git リポジトリを含む親ディレクトリ

### リポジトリ
<a name="ct-concept-repositories"></a>

リポジトリは、スキャンソースによって検出されます。検出後、ソース、ラベル、またはその他の基準でフィルタリングしたり、組織 (チーム、優先度、移行ウェーブ) にラベルを適用したり、分析や修復のために特定のリポジトリをターゲットにしたりできます。

### 分析
<a name="ct-concept-analyses"></a>

分析は、特定の分析タイプを使用する 1 つ以上のリポジトリのスキャンです。各分析では、コードの問題を識別する検出結果が生成されます。分析はオンデマンドで実行することも、自動的に実行するようにスケジュールすることもできます。分析タイプには、rapid-techdebt-analysis、tech-debt-comprehensive、security、agentic-Readiness、モダナイゼーション-Readiness、Custom などがあります。各分析は、ステータス (保留中、実行中、完了、キャンセル、失敗) とスキャンしたリポジトリを追跡します。

### 検出結果
<a name="ct-concept-findings"></a>

結果は分析の結果です。各検出結果には、重要度 (高、中、低）、ステータス (オープン、却下、または廃止）、およびそれを修復できる修正変換 (自動修正可能な場合) が含まれます。新しい検出結果はオープンとして始まります。ユーザーは、理由のある検出結果を却下できます。再分析では、解決された検出結果は自動的に廃止としてマークされます。

### 修復
<a name="ct-concept-remediations"></a>

修正では、変換定義を適用して検出結果を修正します。3 つのモード: 検出結果ベース (各検出結果は独自の修正変換を使用）、TD オーバーライド (指定された検出結果の変換定義を上書き）、および直接 TD (検出結果なしでリポジトリに対して変換を実行）。出力はソースプロバイダー (GitHub PR、GitLab MR、Bitbucket PR、またはローカルブランチ) によって異なります。

### 変換定義
<a name="ct-concept-transformation-definitions"></a>

変換定義には、特定のコード変換を実行するために必要な手順と知識が含まれています。継続的なモダナイゼーションでは、カスタム分析 (`--type custom --transformation-name {{name}}`) と修復 () に変換定義を使用します`--transformation-name {{name}}`。で使用可能な変換定義を一覧表示します`atx custom def list`。

## AWS Transform の継続的なモダナイゼーションの仕組み
<a name="ct-how-it-works"></a>

AWS トランスフォームの継続的なモダナイゼーションは通常、複数のコードベースで継続的な分析と修復が必要な大規模なプロジェクトで使用されます。チームは通常、このワークフローに従います。

1. **Connect Sources** — GitHub 組織、GitLab グループ、Bitbucket ワークスペース、またはローカルディレクトリをソースとして追加します。認証トークンに適切なスコープを提供します。

1. **リポジトリの検出** — 検出スキャンを実行して、ソース内のすべてのリポジトリを列挙します。ラベルを使用して、チーム、優先度、または移行ウェーブ別にリポジトリを整理します。

1. **分析の実行** — ポートフォリオ全体で分析を実行します。迅速な結果を得るにはクイックスキャンを選択し、詳細な結果を得るには包括的な分析を選択します。セキュリティ分析には、1 回限りのインフラストラクチャ設定が必要です。

1. **結果のトリアージ** — 重要度、リポジトリ、分析タイプ別に結果を確認します。文書化された理由で誤検出を却下します。分析を再実行して、解決された問題を古いものとしてマークします。

1. **修復** — 検出結果を修正するための修復を作成します。継続的なモダナイゼーションにより、ブランチが自動的に作成され、修正されたプル/マージリクエストが開きます。修復ステータスを追跡し、失敗を再試行します。

1. **継続的分析の設定** — Amazon EventBridge スケジューラを使用して定期的な分析をスケジュールします。分析頻度 (毎日、毎週、またはカスタム cron) を設定して、ポートフォリオに新しい問題がないか継続的にモニタリングします。自動修復と組み合わせて、時間の経過とともにコードの状態を維持します。

### コンピューティングオプション
<a name="ct-compute-options"></a>

継続的なモダナイゼーションは、分析と修復を実行するための 3 つのコンピューティングオプションをサポートしています。Kiro Power and Agent プラグインのエージェントスキルは、各オプションにインフラストラクチャを設定するのに役立ちます。

**注記**  
コンピューティングオプションに関係なく、すべての分析と修復は認証情報 AWS アカウント を使用して で行われます。ソースコードはお客様の管理下に置かれます。

#### Local (デフォルト)
<a name="ct-compute-local"></a>

デフォルトでは、分析はローカルマシンで実行されます。このオプションでは、追加のインフラストラクチャは必要ありません。サーバーはローカルで実行され、ローカルコンピューティングリソースを使用して分析を実行します。ツール、小さなリポジトリ、または個々の使用を試すのに適しています。

#### Amazon EC2
<a name="ct-compute-ec2"></a>

の永続的な Amazon EC2 インスタンスで分析を実行します AWS アカウント。このオプションは、ローカルマシンからコンピューティングをオフロードし、より大きな分析をサポートし、定期的なスケジュール分析を可能にします。インスタンスは送信間で実行され続けます。

エージェントスキルは、以下を含む AWS CloudFormation スタックをプロビジョニングします。
+ Docker と継続的なモダナイゼーションコンテナを備えた Amazon EC2 インスタンス (Amazon Linux 2023)
+  AWS Transform、Amazon S3、KMS、Secrets Manager、およびセキュリティエージェントのアクセス許可を持つ IAM ロール AWS 
+ `AmazonSSMManagedInstanceCore` SSM 経由のシェルアクセス用 (SSH キーペアまたはインバウンドポートは不要)
+ インバウンドルールのないセキュリティグループ

IAM ユーザーまたはロールには、Amazon EC2 ライフサイクル管理、 AWS CloudFormation スタックオペレーション、IAM ロール作成、Amazon S3 バケットオペレーション、Secrets Manager シークレット管理、SSM コマンドのアクセス許可が必要です。

EC2 実行を設定するには、Kiro Power またはエージェントプラグインをインストールし (「」を参照[デベロッパーツール](ct-developer-tools.md))、*「継続的なモダナイゼーション分析のために EC2 インスタンスを設定する*」とエージェントに依頼します。エージェントはインフラストラクチャをプロビジョニングし、コンテナが正常であることを確認し、SSM を介して分析を送信します。SSH は必要ありません。

#### AWS バッチ (Fargate)
<a name="ct-compute-batch"></a>

サーバーレスコンピューティングのために、Fargate を使用して AWS Batch で分離ジョブとして分析を実行します。各分析は、永続的なインフラストラクチャを管理することなく、独自のコンテナで実行されます。複数のソースまたは分析タイプの並列分析に適しています。

このオプションは、 AWS 変換 CDK インフラストラクチャスタックを再利用します。エージェントスキルは、以下を含む必要なインフラストラクチャをデプロイします。
+ AWS バッチジョブキューとコンピューティング環境
+ 継続的モダナイゼーションコンテナイメージを使用したジョブ定義
+ バッチジョブ実行の IAM ロール
+ ジョブ送信用の Lambda 関数

バッチ実行を設定するには、Kiro Power またはエージェントプラグインをインストールし (「」を参照[デベロッパーツール](ct-developer-tools.md))、エージェントに*「Fargate で分析を実行する*」または*「継続的なモダナイゼーションのためにバッチ実行を設定する*」と尋ねます。エージェントは CDK スタックをデプロイし、ソース認証情報を Secrets Manager に保存して、分析ジョブを AWS Batch に送信します。

### セキュリティエージェントの設定
<a name="ct-security-agent-setup"></a>

`security` 分析タイプは、脆弱性と CVE 検出に AWS Security Agent サービスを使用します。他の分析タイプとは異なり、 では 1 回限りのインフラストラクチャ設定が必要です AWS アカウント。

setup コマンドは、以下を含む AWS CloudFormation スタックをプロビジョニングします。
+ ソースコードのアップロード用の Amazon S3 バケット
+ が引き受ける IAM ロール `securityagent.amazonaws.com`
+ セキュリティエージェントロールの マネージドポリシー

セットアップを実行するには、IAM ユーザーまたはロールに次の追加のアクセス許可が必要です。
+ `cloudformation:CreateStack`, `cloudformation:UpdateStack`, `cloudformation:DescribeStacks`
+ `iam:CreateRole`, `iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreatePolicy`
+ `s3:CreateBucket`, `s3:PutBucketEncryption`, `s3:PutBucketPublicAccessBlock`

次のコマンドを使用して、セキュリティエージェントのインフラストラクチャを管理します。

```
# Provision the security agent infrastructure
atx ct setup security-agent

# Check the status
atx ct setup security-agent --status

# Delete the infrastructure
atx ct setup security-agent --delete
```

セットアップが完了したら、他の分析タイプと同じ方法でセキュリティ分析を実行できます。