• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。
# Linux と Windows Server のパッチ適用オペレーションの違い
このトピックでは、AWS Systems Manager のツールである Patch Manager での Linux と Windows Server のパッチ適用における重要な違いについて説明します。
**注記**
Linux マネージドノードにパッチを適用するには、ノードが SSM Agent バージョン 2.0.834.0 以降実行されている必要があります。
新しいツールが Systems Manager に追加されるか、既存のツールが更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種ツールや機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「[SSM Agent への更新の自動化](ssm-agent-automatic-updates.md)」を参照してください。GitHub の「[SSM Agent リリースノート](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)」ページをサブスクライブすると、SSM Agent の更新に関する通知を受け取ることができます。
## 違い 1: パッチ評価
Patch Manager では、Windows マネージドノードと Linux マネージドノードで、どのパッチを提供するかを評価するプロセスが異なります。
**Linux**
Linux のパッチ適用では、Systems Manager はパッチベースライン ルールと承認済みおよび拒否済みパッチのリストを*各*マネージドノードで評価します。Systems Manager が各ノードでパッチ適用を評価する必要があるのは、マネージドノードに設定された複数のリポジトリから既知のパッチと更新のリストが取得されるためです。
**Server**
Windows のパッチ適用では、Systems Manager はパッチベースラインルールと承認済みおよび拒否済みパッチのリストを*サービス内で直接*評価します。これが可能なのは、Windows パッチが単一のリポジトリ (Windows Update) から取得されるためです。
## 違い 2: `Not Applicable` パッチ
Linux オペレーティングシステムには多数の使用可能なパッケージがあるため、Systems Manager では*該当なし*状態のパッチについて詳細をレポートしません。`Not Applicable` パッチとは、例えば、インスタンスに Apache がインストールされていない場合の Apache ソフトウェア用パッチなどです。Systems Manager は要約で多数の `Not Applicable` パッチをレポートしますが、マネージドノードで [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API を呼び出す場合、戻りデータには状態が `Not Applicable` のパッチは含まれません。この動作は、Windows とは異なります。
## 違い 3: SSM ドキュメントのサポート
`AWS-ApplyPatchBaseline` Systems Manager ドキュメント (SSM ドキュメント) では、Linux マネージドノードはサポートされていません。Linux、macOS、Windows Server マネージドノードにパッチベースラインを適用する上で推奨されている SSM ドキュメントは、`AWS-RunPatchBaseline` です。詳細については、「[マネージドノードへのパッチ適用のための SSM コマンドドキュメント](patch-manager-ssm-documents.md)」および「[パッチ適用のための SSM コマンドドキュメント: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)」を参照してください。
## 違い 4: アプリケーションパッチ
Patch Managerの主な目的は、オペレーティングシステムにパッチを適用することです。ただし、Patch Managerを使用して、マネージドノードの一部のアプリケーションにパッチを適用することもできます。
**Linux**
Linux オペレーティングシステムでは、Patch Manager は更新のために設定されたリポジトリを使用し、オペレーティングシステムとアプリケーションのパッチを区別しません。Patch Managerを使用して、更新を取得するリポジトリを定義できます。詳細については、「[代替パッチソースリポジトリを指定する方法 (Linux)](patch-manager-alternative-source-repository.md)」を参照してください。
**Server**
Windows Server マネージドノードでは、Microsoft Word 2016 や Microsoft Exchange Server 2016 など、Microsoft によってリリースされたアプリケーションに対して、*[Approved]* (承認済み)および *[Rejected]* (拒否された) パッチの例外を適用できます。詳細については、「[カスタムパッチベースラインの操作](patch-manager-manage-patch-baselines.md)」を参照してください。
## 違い 5: カスタムパッチベースラインでの拒否されたパッチリストのオプション
カスタムパッチベースラインを作成するときは、**拒否されたパッチリスト**に 1 つ、または複数のパッチを指定できます。Linux マネージドノードでは、パッチがベースラインで許可されている別のパッチの依存関係である場合に、それらのインストールを許可することも選択できます。
ただし、Windows Server はパッチ依存関係の概念をサポートしません。Windows Server 向けのカスタムベースラインの **[拒否されたパッチ]** リストにパッチを追加することはできますが、その結果は (1) 拒否されたパッチがマネージドノードに既にインストールされているかどうか、および (2) **[拒否されたパッチアクション]** にどのオプションを選択するかに応じて異なります。
Windows Server での拒否されたパッチオプションの詳細については、以下の表を参照してください。
| インストールステータス | オプション:「依存関係として許可する」 | オプション: 「ブロック」 |
| --- | --- | --- |
| パッチが既にインストールされている | 報告されるステータス: INSTALLED\$1OTHER | 報告されるステータス: INSTALLED\$1REJECTED |
| パッチがまだインストールされていない | パッチがスキップされた | パッチがスキップされた |
通常、Microsoft がリリースする Windows Server 用の各パッチには、インストールが正常に行われるために必要なすべての情報が含まれています。ただし、手動でインストールする必要がある前提条件パッケージが必要になる場合もあります。Patch Manager は、これらの前提条件に関する情報を報告しません。関連情報については、Microsoft ウェブサイトで「[Windows Update の問題のトラブルシューティング](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)」を参照してください。