

• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。

# 診断と修復
<a name="diagnose-and-remediate"></a>

Systems Manager の統合コンソールを使用すると、単一の診断オペレーションでフリート全体の問題を特定できます。組織の場合、単一のオートメーションオペレーションを使用して、すべてのターゲットまたは選択したターゲットのみに対して修復を試みることができます。組織の場合、委任されたアカウント管理者として、すべてのアカウントおよびリージョンにわたってターゲットを選択できます。単一のアカウントで作業している場合は、一度に 1 つのリージョンのターゲットを選択できます。

Systems Manager は、複数のタイプのデプロイ障害やドリフトした設定を診断することができ、それらをユーザーが修復するのに役立ちます。また、Systems Manager は、アカウント内または組織内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのうち、*マネージドノード*として扱うことができないインスタンスを特定することもできます。EC2 インスタンス診断プロセスでは、仮想プライベートクラウド (VPC)、ドメインネームサービス (DNS) 設定、または Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループの設定ミスに関連する問題を特定できます。

**注記**  
Systems Manager は、[ハイブリッドおよびマルチクラウド](operating-systems-and-machine-types.md#supported-machine-types)環境において、EC2 インスタンスとその他のマシンタイプの両方を*マネージドノード*としてサポートします。マネージドノードになるには、そのマシンに AWS Systems Manager Agent (SSM Agent) がインストールされており、Systems Manager がそのマシン上でアクションを実行するアクセス許可を持っている必要があります。  
EC2 インスタンスの場合、このアクセス許可は、AWS Identity and Access Management (IAM) ロールを使用してアカウントレベルで付与するか、またはインスタンスプロファイルを使用してインスタンスレベルで付与することができます。詳細については、「[Systems Manager に必要なインスタンスのアクセス許可を設定する](setup-instance-permissions.md)」を参照してください。  
非 EC2 マシンの場合、このアクセス許可は IAM サービスロールを使用して付与されます。詳細については、「[ハイブリッドおよびマルチクラウド環境で Systems Manager に必要な IAM サービスロールを作成する](hybrid-multicloud-service-role.md)」を参照してください。

**[開始する前に]**  
**[診断および修復]** 機能を使用してアンマネージド EC2 インスタンスを検出するには、まず、組織またはアカウントを Systems Manager の統合コンソールにオンボーディングする必要があります。このプロセス中に、これらのオペレーションに必要な IAM ロールとマネージドポリシーを作成するオプションを選択する必要があります。詳細については、「[組織用の Systems Manager 統合コンソールのセットアップ](systems-manager-setting-up-organizations.md)」を参照してください。

以下のトピックは、一般的なタイプのデプロイ障害、ドリフトした設定、およびアンマネージド EC2 インスタンスを特定して修正するのに役立ちます。

**Topics**
+ [失敗したデプロイの診断と修復](remediating-deployment-issues.md)
+ [ドリフトした設定の診断と修復](remediating-configuration-drift.md)
+ [Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復](remediating-unmanaged-instances.md)
+ [ランブックアクションの修復の影響タイプ](remediation-impact-type.md)
+ [Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)

# 失敗したデプロイの診断と修復
<a name="remediating-deployment-issues"></a>

Systems Manager は、次のタイプの失敗したデプロイを診断することができ、ユーザーによる修復を支援します。
+ 組織メンバーアカウントのコアセットアップ
+ 委任管理者アカウントのコアセットアップ
+ アカウントのコアセットアップ

次の手順を使用して、これらのタイプの問題の修復を試みます。

**失敗したデプロイを診断および修復する手順**

1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

1. ナビゲーションペインで、**[診断および修復]** を選択します。

1. **[デプロイ関連]** タブを選択します。

1. **[失敗したデプロイ]** セクションで、失敗したデプロイの検出結果のリストを確認します。

1. **[セットアップ手順]** 列で、検出結果の名前を選択して、問題に関する追加の詳細を確認します。例: **組織メンバーアカウントのコアセットアップ**。

1. その失敗したデプロイの詳細ページで、アカウントのリストと、各アカウント内でデプロイの失敗が発生したリージョンの数を確認できます。

1. アカウント ID を選択すると、そのアカウントにおける失敗の理由に関する情報が表示されます。

1. **[失敗したリージョン]** 領域で、**[ステータスの理由]** として提供された情報を調べます。この情報には、デプロイが失敗した理由が示されており、必要な設定変更についてのインサイトが得られる場合があります。

1. 設定を変更せずにデプロイを再試行する場合は、**[再デプロイ]** を選択します。

# ドリフトした設定の診断と修復
<a name="remediating-configuration-drift"></a>

Systems Manager は、次のタイプのドリフトした設定を診断することができ、ユーザーによる修復を支援します。
+ 組織メンバーアカウントのコアセットアップ
+ 委任管理者アカウントのコアセットアップ
+ アカウントのコアセットアップ

次の手順を使用して、これらのタイプのドリフトした設定の修復を試みます。

**ドリフトした設定を診断および修復する手順**

1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

1. ナビゲーションペインで、**[診断および修復]** を選択します。

1. **[デプロイ関連]** タブを選択します。

1. **[ドリフトしたデプロイ]** セクションで、失敗したデプロイの検出結果のリストを確認します。

   -または-

   新しい診断を実行するには、**[ドリフトの検出]** を選択します。

1. **[セットアップ手順]** 列で、検出結果の名前を選択して、問題に関する追加の詳細を確認します。例: **組織メンバーアカウントのコアセットアップ**。

1. その失敗したデプロイの詳細ページで、アカウントのリストと、各アカウント内で設定ドリフトが発生したリージョンの数を確認できます。

1. アカウント ID を選択すると、そのアカウントにおける設定ドリフトの理由に関する情報が表示されます。

1. **[ドリフトされたリソース]** 領域で、**[リソース]** 列にドリフトが発生したリソースの名前が報告されます。**[ドリフトタイプ]** 列には、リソースが変更されたか削除されたかが報告されます。

1. 目的の設定を再デプロイするには、**[再デプロイ]** を選択します。

# Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復
<a name="remediating-unmanaged-instances"></a>

Systems Manager を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを管理するのを支援するために、Systems Manager の統合コンソールを使用して次のことができます。

1. 手動による、またはスケジュールされた診断プロセスを実行して、現在 Systems Manager によって管理されていない、アカウントまたは組織内の EC2 インスタンスを特定します。

1. Systems Manager がインスタンスの管理を引き継ぐのを妨げているネットワークまたはその他の問題を特定します。

1. オートメーション実行を実行して問題を自動的に修復するか、手動で問題に対処するのに役立つ情報にアクセスします。

以下のトピックの情報を使用して、Systems Manager が EC2 インスタンスを管理することを妨げている問題を診断および修復できます。

## Systems Manager が「アンマネージド EC2 インスタンスの問題」リストで影響を受けるノードをカウントする方法
<a name="unmanaged-instance-scan-count"></a>

**[アンマネージド EC2 インスタンスの問題]** タブでアンマネージドとして報告されたノードの数は、診断スキャン時に以下のいずれかのステータス値を持っていたインスタンスの総数を表します。
+ `Running`
+ `Stopped`
+ `Stopping`

この数は、**[問題の概要]** 領域で **[影響を受けるノード]** として報告されます。次の図で、現在 Systems Manager によって管理されていない、影響を受けるノードの数は `40` です。

![\[[診断および修復] ページで影響を受けるノードの数が 40 であることを示している [問題の概要] 領域\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)


**[ノードインサイトの確認]** ページのアンマネージド EC2 インスタンスのレポートとは異なり、この EC2 インスタンスの数は動的ではありません。これは、最後に報告された診断スキャン時 (**[スキャン時刻]** の値として示されている) における検出結果を表しています。そのため、この報告された影響を受けるノードの数を最新の状態に保つために、アンマネージド EC2 インスタンスの診断スキャンを定期的に実行することをお勧めします。

**[ノードのインサイトを確認]** ページでのアンマネージドインスタンス数の詳細については、「[ノードインサイトの確認](review-node-insights.md)」トピックの「[アンマネージドインスタンスとは](review-node-insights.md#unmanaged-instance-definition)」を参照してください。

**Topics**
+ [Systems Manager が「アンマネージド EC2 インスタンスの問題」リストで影響を受けるノードをカウントする方法](#unmanaged-instance-scan-count)
+ [診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ](diagnosing-ec2-category-types.md)
+ [アンマネージド EC2 インスタンスに対する診断およびオプションの修復の実行](running-diagnosis-execution-ec2.md)
+ [アンマネージド EC2 インスタンスの定期スキャンのスケジュール](schedule-recurring-ec2-diagnosis.md)

# 診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ
<a name="diagnosing-ec2-category-types"></a>

このトピックでは、ユーザーが診断と修復を行う際に Systems Manager が支援できる EC2 管理の問題の主要なカテゴリと、各カテゴリの具体的な問題についてリストします。一部の問題については、Systems Manager が問題を特定することはできるが、自動修復を行うことはできない場合があるので注意してください。そのような場合、Systems Manager のコンソールで、問題を手動で解決するのに役立つ情報が提供されます。

診断プロセスでは、EC2 インスタンスが属する仮想プライベートクラウド (VPC) に応じて、各グループの EC2 インスタンスを一度に検査します。

**Topics**
+ [問題カテゴリ: セキュリティグループ設定と HTTPS 通信](#unmanaged-ec2-issue-security-groups)
+ [問題カテゴリ: DNS または DNS ホスト名の設定](#unmanaged-ec2-issue-dns-configuration)
+ [問題カテゴリ: VPC エンドポイント設定](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [問題カテゴリ: ネットワーク ACL 設定](#unmanaged-ec2-issue-nacl-configuration)

## 問題カテゴリ: セキュリティグループ設定と HTTPS 通信
<a name="unmanaged-ec2-issue-security-groups"></a>

診断オペレーションによって、SSM Agent が HTTPS 経由で Systems Manager サービスと通信できないことが検出される場合があります。そのような場合は、オートメーションランブックを実行することを選択できます。これにより、インスタンスにアタッチされているセキュリティグループの更新が試行されます。

**注記**  
場合によっては、Systems Manager がこれらの問題を自動的に修復できないことがありますが、影響を受けたセキュリティグループを手動で編集することは可能です。

**サポートされている問題タイプ**
+ **インスタンスセキュリティグループ**: ポート 443 でのアウトバウンドトラフィックは許可されません
+ **`ssm` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません
+ **`ssmmessages` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません
+ **`ec2messages` VPC エンドポイントのセキュリティグループ**: ポート 443 でのインバウンドトラフィックは許可されません

詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[エンドポイントセキュリティグループでイングレスルールを検証する](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules)」を参照してください。

## 問題カテゴリ: DNS または DNS ホスト名の設定
<a name="unmanaged-ec2-issue-dns-configuration"></a>

診断オペレーションによって、ドメインネームシステム (DNS) または DNS ホスト名が VPC に対して適切に設定されていないことが検出される場合があります。そのような場合は、オートメーションランブックを実行することを選択できます。これにより、影響を受けた VPC の `enableDnsSupport` 属性および `enableDnsHostnames` 属性の有効化が試行されます。

**サポートされている問題タイプ**
+ VPC では DNS サポートは無効化されています。
+ VPC では DNS ホスト名は無効化されています。

詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[VPC DNS 関連の属性を検証する](troubleshooting-ssm-agent.md#agent-ts-dns-attributes)」を参照してください。

## 問題カテゴリ: VPC エンドポイント設定
<a name="unmanaged-ec2-issue-vpc-endpoint-configuration"></a>

診断オペレーションによって、VPC エンドポイントが VPC に対して適切に設定されていないことが検出される場合があります。

SSM Agent に必要な VPC エンドポイントが存在しない場合、Systems Manager はオートメーションランブックを実行して VPC エンドポイントを作成し、それを関連する各リージョンアベイラビリティーゾーン (AZ) 内の 1 つのサブネットに関連付けようとします。VPC に必要なエンドポイントは存在するが、問題が見つかったサブネットに関連付けられていない場合、ランブックはその VPC エンドポイントを影響を受けたサブネットに関連付けます。

**注記**  
Systems Manager は、誤って設定された VPC エンドポイントのすべての問題の修復をサポートしているわけではありません。そのような場合、Systems Manager は、オートメーションランブックを実行する代わりに、ユーザーに対して手動修復手順を提供します。

**サポートされている問題タイプ**
+ PrivateLink 用の `ssm.region.amazonaws.com` エンドポイントが見つかりませんでした。
+ PrivateLink 用の `ssmmessages.region.amazonaws.com` エンドポイントが見つかりませんでした。
+ PrivateLink 用の `ec2messages.region.amazonaws.com` エンドポイントが見つかりませんでした。

**診断可能な問題タイプ**  
Systems Manager は、以下の問題タイプを診断できますが、現在、これらの問題の修復に使用できるランブックはありません。これらの問題について、設定を手動で編集することは可能です。
+ インスタンスのサブネットが `ssm.region.amazonaws.com` エンドポイントにアタッチされていません。
+ インスタンスのサブネットが `ssmmessages.region.amazonaws.com` エンドポイントにアタッチされていません。
+ インスタンスのサブネットが `ec2messages.region.amazonaws.com` エンドポイントにアタッチされていません。

詳細については、「[SSM Agent のトラブルシューティング](troubleshooting-ssm-agent.md)」トピックの「[VPC 設定を検証する](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration)」を参照してください。

## 問題カテゴリ: ネットワーク ACL 設定
<a name="unmanaged-ec2-issue-nacl-configuration"></a>

診断オペレーションにより、VPC のネットワークアクセス制御リスト (NACL) が適切に構成されておらず、Systems Manager 通信に必要なトラフィックがブロックされている可能性があることが判明するかもしれません。NACL はステートレスであるため、アウトバウンドとインバウンドの両方のルールで Systems Manager のトラフィックを許可する必要があります。

Systems Manager は NACL 設定の問題を特定し、手動での修正手順を提供します。

**サポートされている問題タイプ**
+ **インスタンスサブネットの NACL **: システムマネージャーエンドポイントへのポート 443 のアウトバウンド通信は許可されていません
+ **インスタンスサブネット NACL **: Systems Manager 応答のための一時的ポート (1024-65535) への着信トラフィックは許可されません

**診断可能な問題タイプ**  
Systems Manager は以下の NACL 構成の問題を診断できますが、手動での修正が必要です。
+ インスタンスのサブネット NACL は、Systems Manager エンドポイントへのアウトバウンド HTTPS (ポート 443) トラフィックをブロックします
+ インスタンスのサブネット NACL は、Systems Manager の応答に必要な一時ポートトラフィック (1024-65535) の受信をブロックします

詳細については、[「SSM エージェントのトラブルシューティング」](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html) および [「VPC 用のカスタムネットワーク ACL」](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports) を参照してください。

# アンマネージド EC2 インスタンスに対する診断およびオプションの修復の実行
<a name="running-diagnosis-execution-ec2"></a>

Systems Manager が EC2 インスタンスを管理するのを妨げている可能性があるネットワーク関連および VPC 関連の問題を診断するには、次の手順を使用します。

診断オペレーションでは、以下のタイプの問題を検出してグループ化できます。
+ **[ネットワーク設定の問題]** — EC2 インスタンスがクラウド内の Systems Manager サービスと通信するのを妨げている可能性があるネットワーク問題のタイプ。これらの問題では、修復オペレーションを使用できる場合があります。ネットワーク設定の問題の詳細については、「[診断可能なアンマネージド EC2 インスタンスの問題のカテゴリ](diagnosing-ec2-category-types.md)」を参照してください。
+ **[未確認の問題]** — EC2 インスタンスがクラウド内の Systems Manager サービスと通信できない理由を診断オペレーションによって判断できなかった場合の検出結果のリスト。

**アンマネージド EC2 インスタンスに対して診断および修復を実行する手順**

1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

1. ナビゲーションペインで、**[診断および修復]** を選択します。

1. **[アンマネージド EC2 インスタンスの問題]** タブを選択します。

1. **[問題の概要]** セクションで **[新しい診断の実行]** を選択します。

   -または-

   アンマネージド EC2 の問題を初めて診断する場合は、**[アンマネージド EC2 インスタンスの診断]** セクションで **[実行]** を選択します。
**ヒント**  
診断の実行中に **[進行状況を表示]** または **[実行を表示]** を選択すると、実行の現在の状態をモニタリングできます。詳細については、「[Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)」を参照してください。

1. 診断が完了したら、次の操作を実行します。
   + **[未確認の問題]** セクションで報告された問題については、**[詳細]** リンクを選択すると問題の解決方法を確認できます。
   + **[ネットワーク設定の問題]** セクションで報告された問題については、次のステップに進みます。

1. 検出結果タイプのリスト内で、特定の問題に対応する **[推奨事項]** 列のリンク (**[2 つの推奨事項]** など) を選択します。

1. 開いた **[推奨事項]** ペインで、使用可能な緩和策から選択します。
   + **[詳細]** — 問題を手動で解決する方法に関する情報を含むトピックを開きます。
   + **[ランブックの表示]** – EC2 インスタンスの問題を解決するために実行できるオートメーションランブックに関する情報と、ランブックが実行するアクションの*プレビュー*を生成するためのオプションを含むペインを開きます。次のステップに進みます。

1. ランブックペインで、次の操作を実行します。

   1. **[ドキュメントの説明]** で、コンテンツを確認します。コンテンツには、ランブックがアンマネージド EC2 インスタンスの問題を修復するために実行できるアクションの概要が示されています。**[ステップを表示]** を選択して、ランブックで実行される個々のアクションをプレビューします。

   1. **[ターゲット]** で、以下の作業を行います。
      + 組織の修復を管理している場合は、**[アカウント]** で、このランブックがすべてのアカウントをターゲットにするか、選択したアカウントのサブセットのみをターゲットにするかを指定します。
      + **[リージョン]** で、このランブックがアカウントまたは組織内のすべての AWS リージョンをターゲットにするか、選択したリージョンのサブセットのみをターゲットにするかを指定します。

   1. **[ランブックのプレビュー]** で、情報を慎重に確認します。この情報は、ランブックの実行を選択した場合の範囲と影響について説明しています。
**注記**  
ランブックの実行を選択すると、料金が発生します。続行するかどうかを決定する前に、プレビュー情報を注意深く確認してください。

      **[ランブックのプレビュー]** のコンテンツでは、次の情報が提供されます。
      + ランブックオペレーションが実行されるリージョンの数。
      + (組織のみ) オペレーションを実行する組織単位 (OU) の数。
      + 実行されるアクションのタイプと、各アクションの実行回数。

        アクションタイプには以下のものがあります。
        + **変異**: ランブックステップは、リソースの作成、変更、または削除を行うアクションを通じて、ターゲットに変更を加えます。
        + **非変異**: ランブックステップは、リソースに関するデータを取得しますが、データに変更を加えることはありません。このカテゴリには通常、`Describe*`、`List*`、`Get*`、および同様の読み取り専用 API アクションが含まれます。
        + **未確定**: 未確定ステップは、AWS Lambda、AWS Step Functions、または AWS Systems Manager Run Command など、他のオーケストレーションサービスによって処理される実行を呼び出します。未確定ステップは、サードパーティー API を呼び出すこともあります。Systems Manager Automation は、オーケストレーションプロセスやサードパーティー API の実行結果を認識できないため、それらのステップの結果は未確定になります。

   1. この時点で、次のいずれかのアクションを選択できます。
      + 停止して、ランブックを実行しない。
      + **[実行]** を選択して、既に選択したオプションを使用してランブックを実行する。

   オペレーションを実行することを選択した場合は、**[進行状況を表示]** または **[実行を表示]** を選択すると、実行の現在の状態をモニタリングできます。詳細については、「[Systems Manager での修復実行の進行状況と履歴の表示](diagnose-and-remediate-execution-history.md)」を参照してください。

# アンマネージド EC2 インスタンスの定期スキャンのスケジュール
<a name="schedule-recurring-ec2-diagnosis"></a>

さまざまな設定の問題によって Systems Manager が管理できない、アカウントまたは組織内の Amazon EC2 インスタンスに対して、オンデマンドスキャンを実行できます。定期的なスケジュールに従って自動的に実行されるように、このスキャンをスケジュールすることもできます。

**アンマネージド EC2 インスタンスの定期スキャンをスケジュールする手順**

1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

1. ナビゲーションペインで、**[診断および修復]** を選択します。

1. **[アンマネージド EC2 インスタンスの問題]** タブを選択します。

1. **[アンマネージド EC2 インスタンスの診断]** セクションで、**[定期診断のスケジュール]** をオンにします。

1. **[診断頻度]** で、診断を 1 日に 1 回実行するか、週に 1 回実行するかを選択します。

1. (オプション) **[開始時刻]** に、診断を開始する時刻を 24 時間形式で入力します。例えば、午後 8:15 の場合は **20:15** と入力します。

   入力する時刻は、現在のローカルタイムゾーンの時刻です。

   時刻を指定しない場合、診断スキャンは即時に実行されます。Systems Manager は、今後のスキャンも現在時刻に実行されるようにスケジュールします。時刻を指定すると、Systems Manager は指定された時刻まで待ってから診断スキャンを実行します。

1. **[実行]** を選択してください。診断は即時に実行されますが、指定したスケジュールでも実行されます。

# ランブックアクションの修復の影響タイプ
<a name="remediation-impact-type"></a>

Systems Manager は、特定のタイプの失敗したデプロイやドリフトした構成、および Systems Manager が EC2 インスタンスを管理するのを妨げている特定のタイプの設定の問題を検出する診断オペレーションを実行できます。診断の結果には、問題の解決を試みるために実行できるオートメーションランブックの推奨事項が含まれる場合があります。これらの診断オペレーションの詳細については、次のトピックを参照してください。
+ [失敗したデプロイの診断と修復](remediating-deployment-issues.md)
+ [ドリフトした設定の診断と修復](remediating-configuration-drift.md)
+ [Systems Manager でのアンマネージド Amazon EC2 インスタンスの診断と修復](remediating-unmanaged-instances.md)

Systems Manager は、影響を受けるリソースでオートメーションランブックを実行することで修正できる可能性のある問題を特定すると、*実行プレビュー*を提供します。実行プレビューでは、ランブックの実行によってターゲットにどのような*タイプ*の変更が加えられるかについての情報が提供されます。この情報には、診断によって特定された 3 つのタイプの変更それぞれの数が含まれます。

これらの変更タイプは以下のとおりです。
+ `Mutating`: ランブックステップは、リソースの作成、変更、または削除を行うアクションを通じて、ターゲットに変更を加えます。
+ `Non-Mutating`: ランブックステップは、リソースに関するデータを取得しますが、データに変更を加えることはありません。このカテゴリには通常、`Describe*`、`List*`、`Get*`、および同様の読み取り専用 API アクションが含まれます。
+ `Undetermined`: 未確定ステップは、AWS Lambda、AWS Step Functions、または AWS Systems Manager のツールである Run Command など、他のオーケストレーションサービスによって処理される実行を呼び出します。また、未確定ステップは、サードパーティー API を呼び出したり、Python や PowerShell スクリプトを実行したりする場合もあります。Systems Manager Automation は、オーケストレーションプロセスまたはサードパーティー API 実行の結果を検出できないため、それらを評価することができません。これらのステップの結果は、手動で確認して、その影響を判断する必要があります。

  サポートされているオートメーションアクションの影響タイプについては、次の表を参照してください。

## サポートされている修復アクションの影響タイプ
<a name="actions-and-impact-types"></a>

この表は、修復ランブックに含めることができるさまざまなアクションの影響タイプ (変異、非変異、未確定) を示しています。


| アクション¹ | 影響タイプ | 
| --- | --- | 
| aws:approve | 非変異 | 
| aws:assertAwsResourceProperty | 非変異 | 
| aws:branch | 非変異 | 
| aws:changeInstanceState | 変異 | 
| aws:copyImage | 変異 | 
| aws:createImage | 変異 | 
| aws:createStack | 変異 | 
| aws:createTags | 変異 | 
| aws:deleteImage | 変異 | 
| aws:deleteStack | 変異 | 
| aws:executeAutomation | 未定  | 
| aws:executeAwsApi | 未定 | 
| aws:executeScript | 未定 | 
| aws:executeStateMachine | 未定 | 
| aws:invokeLambdaFunction | 未定 | 
| aws:invokeWebhook | 未定 | 
| aws:loop | 可変。ループに含まれるアクションによって異なります。 | 
| aws:pause | 非変異 | 
| aws:runCommand  | 未定 | 
| aws:runInstances | 変異 | 
| aws:sleep | 非変異 | 
| aws:updateVariable | 変異 | 
| aws:waitForAwsResourceProperty | 非変異 | 

¹ オートメーションアクションの詳細については、「[Systems Manager Automation アクションのリファレンス](automation-actions.md)」を参照してください。

# Systems Manager での修復実行の進行状況と履歴の表示
<a name="diagnose-and-remediate-execution-history"></a>

Systems Manager の **[診断および修復]** 機能を使用して実行された、すべての進行中および完了済みの修復オペレーションのリストを表示できます。

実行履歴リストのデータによって、以下のタイプの情報が報告されます。
+ 実行のタイプ: `Diagnosis` または `Remediation`。
+ 実行ステータス: `Success` や `Failed` など。
+ 実行の開始時刻と終了時刻。

**修復の実行の進行状況と履歴を表示する手順**

1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。

1. ナビゲーションペインで、**[診断および修復]** を選択します。

1. **[実行の表示]** を選択します。
**ヒント**  
実行が進行中の場合は、**[進行状況を表示]** を選択して **[実行履歴]** ページを開くこともできます。

1. (オプション) 検索 (![\[The search icon\]](http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/images/search-icon.png)) ボックスに、**EC2** や **VPC** など、実行リストを絞り込むのに役立つフレーズを入力します。

1. (オプション) 実行に関する詳細を表示するには、**[実行名]** 列で **[AWS-DiagnoseUnmanagedEC2NetworkIssues]** などのオペレーション名を選択します。

   詳細ペインでは、オペレーション中に試行されたすべてのステップ、および実行におけるすべての入力と出力に関する情報を確認できます。