【検証】会議室 PC への SSM エージェント導入前に、EC2 でハイブリッドアクティベーションを試してみた

【検証】会議室 PC への SSM エージェント導入前に、EC2 でハイブリッドアクティベーションを試してみた

AWS Systems Manager(SSM)のハイブリッドアクティベーションを使い、オンプレミスの Windows PC を SSM 管理下に置く一連の流れを、EC2 で疑似検証しました。IAM ロール設定の落とし穴や Fleet Manager での確認方法など、本番導入前に押さえておきたいつまずきポイントを紹介します。
2026.07.29

はじめに

社内の会議室に設置している PC(Windows)に対して、AWS コンソールから Chrome の自動更新スクリプトを実行できるようにしたい、という要件がありました。

対象 PC に SSM エージェントを導入し、AWS Systems Manager(以下 SSM)の管理下に置く必要があるのですが、いきなり本番の会議室 PC で作業するのはリスクがあるため、まずは EC2 インスタンスを使って、一連の流れを事前に検証しました。

なお、本記事の主眼は「ハイブリッドアクティベーションの作成から SSM 管理下に入るまでの一連の流れ・つまずきポイント」を確認することにあります。エージェントのインストーラー自体(EC2 インスタンス用か ssm-setup-cli か)の選定については、手順 6 で触れる程度に留めており、実際の本番導入では別途 ssm-setup-cli を使った検証を行う予定です。

前提:なぜ SSM エージェントが必要か

オンプレミス環境の PC は、AWS と専用線や VPN などの直接的なネットワーク接続を持たないケースを前提としています。そこで使われるのが SSM エージェント です。PC 側にエージェントを常駐させておくと、エージェントが AWS のエンドポイントと HTTPS 通信を行い、コマンドの有無を確認します。AWS 側は SSM の API 経由でコマンドをキューに登録するだけで、離れた場所にある PC へコマンドを届けられる、という仕組みです。

社内 PC のように EC2 インスタンスではない機器を SSM 管理下に置く場合は、ハイブリッドアクティベーション という仕組みを使います。今回は、この仕組みを EC2 インスタンス上で疑似的に再現して検証しました。

検証の方針

  • AWS 上の EC2 インスタンスのみで完結させる
  • ただし、本番作業になるべく近い手順を踏む(EC2 インスタンス用のインスタンスプロファイルという近道はあえて使わず、ハイブリッドアクティベーションの手順をそのまま踏襲)

検証環境

  • AMI:Microsoft Windows Server 2025 Base(Windows_Server-2025-English-Full-Base-2026.07.15
  • SSM エージェントバージョン:v3.3.4851.0
  • リージョン:ap-northeast-1(東京)
  • サブネット:パブリックサブネット(RDP 接続のためパブリック IP を付与)

検証手順

1. EC2 インスタンスを起動(IAM ロールなし)

Windows Server 2025 の EC2 インスタンスを、IAM インスタンスプロファイルをあえてアタッチせずに起動しました。これにより、会議室 PC と同じ「SSM 未接続」の状態を再現しています。

2. リモートデスクトップで接続

Mac から接続する場合、Microsoft のリモートデスクトップクライアントアプリを使います。以前は「Microsoft Remote Desktop」という名前でしたが、現在は「Windows App」に名称変更されています。Microsoft アカウントは不要で、App Store でインストールできます。

3. デフォルトの SSM エージェントをアンインストール

EC2 インスタンスの Windows AMI には標準で SSM エージェントが入っているため、一度アンインストールし、「未導入」の状態を再現します。以下、管理者権限の PowerShell で実行します。

Get-Service AmazonSSMAgent | Stop-Service
$app = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*SSM Agent*" }
$app.Uninstall()

SSM エージェントをアンインストールしている画面

正しく削除されているか確認します。以下のコマンドでサービスが取得できない(見つからない)ことを確認できれば、アンインストール成功です。

Get-Service AmazonSSMAgent

サービスが見つからないことを確認した画面

4. ハイブリッドアクティベーション用の IAM ロールを作成

AmazonSSMManagedInstanceCore ポリシーを付けたロールを作成します。

つまずきポイント: IAM ロール作成のユースケースで「EC2」を選ぶと、信頼ポリシーが ec2.amazonaws.com を信頼する内容になり、ハイブリッドアクティベーションの作成時に以下のエラーが出ました。

Nonexistent role or missing ssm service principal in trust policy

信頼ポリシー不足によるエラーメッセージ画面

信頼関係を以下のように修正して解決しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ssm.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

5. ハイブリッドアクティベーションの作成

Systems Manager →「ハイブリッドアクティベーション」から作成し、アクティベーションコード・ID を取得します(再表示できないので必ずメモしてください)。

ハイブリッドアクティベーションの作成画面

6. SSM エージェントを再インストール(ハイブリッド方式)

今回はあくまで EC2 インスタンスの疑似検証環境だったため、以下のように EC2 インスタンス用インストーラーを使って簡易的に再現しました。

New-Item -ItemType Directory -Force -Path "C:\SSMTemp"
cd C:\SSMTemp
Invoke-WebRequest https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/windows_amd64/AmazonSSMAgentSetup.exe -OutFile AmazonSSMAgentSetup.exe

Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @(
  "/S",
  "/v/qn",
  "REGION=ap-northeast-1",
  "CODE=<アクティベーションコード>",
  "ID=<アクティベーションID>"
) -Wait

ログ(C:\ProgramData\Amazon\SSM\Logs\amazon-ssm-agent.log)を確認すると、正常に登録され、オンプレミス機器として認識されていることを確認できました。

Successfully registered のログを確認した画面

(このログは「アクティベーション経由での登録に成功し、オンプレミス機器としてアイデンティティを取得した」ことを示しています。)

つまずきポイント: Fleet Manager(SSM 管理下のノード一覧を確認できる AWS コンソールの画面)で確認する際、EC2 インスタンスの一覧(i- から始まる ID)ではなく、マネージドインスタンスの一覧(mi- から始まる ID) を見る必要があります。最初は EC2 インスタンス一覧の方を確認していたため、登録が反映されていないと誤解していました。

Fleet Manager でノードがオンラインになっている画面

7. Run Command でスクリプトを実行

仕組みの確認としてダミースクリプトを実行しました。

Write-Output "Computer name: $env:COMPUTERNAME"
Write-Output "This is a dummy verification run."

Systems Manager →「Run Command」→ AWS-RunPowerShellScript を選択し、対象ノードを指定して実行しました。ステータスが Success になり、コンピューター名が出力されることを確認できました。

Run Command の実行結果画面

まとめ

  • ハイブリッドアクティベーション用のロールは、信頼ポリシーに ssm.amazonaws.com が必要
  • Fleet Manager では mi- から始まる ID で確認する
  • Win32_Product によるアンインストールは手軽だが、本番運用では副作用に注意が必要
  • SSM エージェントのアンインストールは、EC2 インスタンスの AMI に元々入っているものを取り除くための検証環境特有の手順であり、本番の未導入 PC に対しては不要(ハイブリッドアクティベーションの作成からそのまま進められる)
  • 今回の検証では簡便さのため EC2 インスタンス用インストーラーを流用しましたが、本番の非 EC2 環境(会議室 PC 等)では、AWS 公式に推奨されている ssm-setup-cli を使ったインストール手順に置き換える必要があります

本番の会議室 PC でいきなり作業するのではなく、EC2 インスタンスで一連の流れを先に検証したことで、IAM ロールの信頼ポリシーの落とし穴や、Fleet Manager での確認方法の違いなど、実際につまずきそうなポイントを事前に洗い出すことができました。次は本番の会議室 PC への導入を進めていきます。

なお、今回の手順はあくまで検証環境限定のものです。本番環境では、アクティベーションコード・ID の安全な受け渡し(Secrets Manager の利用など)や、IAM ポリシーの最小権限化といった、セキュリティ要件に応じた追加対策を検討してください。

参考

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事