公開2023.09.26更新2026.10.11 82 人が閲覧（直近 30 日） AWS

SSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】

Q: SSM AgentのバージョンはWindowsでどう確認しますか？

PowerShellで & "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe" -version を実行すると表示されます。複数台を確認するなら、Fleet Managerのマネージドノード一覧にある「SSM Agent version」列を見るほうが早く済みます。

Q: amazon-ssm-agentプロセスとは何ですか？

SSM Agent本体の常駐プロセスです。Linuxでは amazon-ssm-agent 、Windowsでは amazon-ssm-agent.exe （サービス名AmazonSSMAgent）として動きます。Session Managerの接続中は、子プロセスとして ssm-session-worker も起動します。停止するとノードとの接続が失われ、コマンド実行やセッション接続ができなくなります。登録が即座に解除されたり、Fleet Managerの一覧から直ちに消えたりするわけではありません。

SSM Agent（AWS Systems Manager Agent）は、EC2インスタンスやオンプレミスのサーバーに常駐し、AWS Systems Manager から届いた指示を実行して結果を返すAWS製のソフトウェアです。Amazon Linux 2023やWindows Serverにはエージェントがプリインストールされた公式AMIがあり、エージェントの稼働・IAMロール・外向きの通信経路の3つが揃えば、SSH鍵や踏み台サーバーなしでコマンド実行やシェル接続ができます。この記事では、役割と前提条件、OS別のインストール・バージョン確認、自動更新、管理対象に出ないときの切り分けを、AWS公式ドキュメントとGitHubのリリースノートをもとに整理します。

まとめ：SSM Agentの要点

役割：Systems Manager のRun Command・Session Manager・Patch Manager・Inventoryなどを、ノード側で実際に動かすエージェント。エージェント側から443番で外向きに接続するため、インバウンドのポートを開ける必要がない。
前提は3つ：エージェントの稼働、IAM権限（AmazonSSMManagedInstanceCore を付けたインスタンスプロファイルかDHMC）、ssm・ssmmessages エンドポイントへの到達。
導入：Amazon Linux 2/2023・Ubuntu Server・Windows Server・SLES・AlmaLinux・macOSにはプリインストール済みのAMIがある。初回利用前に稼働状態を確認し、RHELなどはRPMを手動で入れる。
最新版：GitHubのリリースでは 3.3.5512.0（2026-10-08）。2〜4週間ごとに新版が出るため、Fleet Managerの「Auto update SSM Agent」で2週間ごとの自動更新を有効にしておく。
料金：エージェント自体は無料。EC2でのSession Manager・Run Commandも追加料金なし。ただしオンプレミスや他クラウドのノードでは2026-09-30から1セッション0.05ドル、Run Commandは1回0.002ドルかかる。
注意点：エージェントはroot（WindowsではSYSTEM）で動き、Session Managerの既定ユーザー ssm-user にはパスワードなしのsudoが付く。StartSession と SendCommand の権限はタグで絞る。

SSM Agentの役割と通信の仕組み

SSMはAWS Systems Managerの旧称「Amazon Simple Systems Manager」「Amazon EC2 Systems Manager」に由来する略称で、APIやCLIのコマンド名（aws ssm）、エージェント名に今も残っています。AWS公式ドキュメントの「Working with SSM Agent」によると、SSM AgentはEC2インスタンス、エッジデバイス、オンプレミスのサーバー、他社クラウドの仮想マシンで動き、Systems Managerからの要求を処理して、実行状況をサービス側へ返します。Systems Manager全体の機能構成と料金はAWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころで整理しています。

SSM Agentが動かすSystems Managerの機能

SSM Agent単体に機能があるわけではありません。Systems Managerの各機能の「実行役」です。エージェントが止まると、次の機能がそのノードで一斉に使えなくなります。

機能	SSM Agentがノード上で行うこと
Run Command	コマンド・スクリプトの実行と結果の返却
Session Manager	シェル接続・ポートフォワードの中継
Patch Manager	パッチのスキャンと適用
Inventory	導入ソフト・設定の収集
State Manager	関連付けの定期実行（エージェント更新など）

ssmmessagesへの外向き443番通信

エージェントはSystems Managerのエンドポイントへ外向きのHTTPS（443番）で自分から接続し、指示を受け取ります。そのため、この接続のためにノード側のセキュリティグループのインバウンドを開ける必要はありません。実行結果の返却には ssmmessages（Amazon Message Gateway Service）が使われます。2024年より前に開設されたリージョンでは、従来の ec2messages（Amazon Message Delivery Service）経由になる場合もあります。メッセージAPIの公式リファレンスによると、SSM Agent 3.3.40.0以降は ssmmessages が使えるときはそちらを優先し、2024年以降に開設されたリージョンは ssmmessages だけに対応します。

SSM Agentで管理する前提条件（IAM・通信・DHMC）

Fleet Managerの一覧にマネージドノードとして出るには、エージェントの稼働・IAM権限・エンドポイントへの到達の3つがすべて必要です。1つでも欠けると、エージェントが起動していても一覧には出ません。

IAMロールとAmazonSSMManagedInstanceCore

EC2では、AWS管理ポリシー AmazonSSMManagedInstanceCore を含むIAMロールをインスタンスプロファイルとして割り当てるのが基本です。オンプレミスや他クラウドのノードでは、後述のハイブリッドアクティベーションで指定するIAMサービスロールに同じポリシーを付けます。Session Managerのログを S3 や CloudWatch Logs に送る、KMSで暗号化するといった機能を使うときは、その分の権限を同じロールに足します。

VPCエンドポイントとec2messagesの扱い

インターネットに出られないプライベートサブネットでは、インターフェイス型のVPCエンドポイントを作ります。公式手順「VPCエンドポイントを使用してEC2インスタンスのセキュリティを向上させる」に載っている構成は次のとおりです。

エンドポイント	種類	要否
com.amazonaws.region.ssm	インターフェイス	必須
com.amazonaws.region.ssmmessages	インターフェイス	必須（Session Manager・Run Command）
com.amazonaws.region.ec2messages	インターフェイス	旧リージョン・3.3.40.0未満の版で必要
com.amazonaws.region.s3	ゲートウェイ	エージェント更新・パッチに必要
com.amazonaws.region.kms	インターフェイス	任意（暗号化を使う場合）
com.amazonaws.region.logs	インターフェイス	任意（CloudWatch Logsへ送る場合）

Patch Managerでは、S3に加えてOSのパッチ配布元への到達も必要です。エージェントの自動更新とPatch ManagerはAWS管理のS3バケットからもファイルを取得するため、S3への経路が無いと「管理対象には出るのに更新だけ失敗する」状態になります。インターフェイス型とゲートウェイ型の違いや料金の比較はVPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点で扱っています。

DHMCの利用条件とインスタンスプロファイルの省略

Default Host Management Configuration（DHMC）は、インスタンスごとにIAMロールを付けなくても、アカウントとリージョン単位でEC2を自動的にマネージドノードにする設定です。DHMCの公式ドキュメントに書かれた前提は次の2つです。

インスタンスがIMDSv2を使っていること（IMDSv1には対応しない）
SSM Agentが3.2.582.0以降であること

有効化はリージョンごとに行います。CLIでは、DHMC用のロール（既定名 AWSSystemsManagerDefaultEC2InstanceManagementRole）を service-role パスに作成し、信頼ポリシーで ssm.amazonaws.com による引き受けを許可して、AmazonSSMManagedEC2InstanceDefaultPolicy を付けます。そのうえで、次のアカウントIDを自分の値に置き換え、AWS CLIの対象リージョンを東京に設定してサービス設定を書き換えます。

aws ssm update-service-setting \
  --setting-id arn:aws:ssm:ap-northeast-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
  --setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole

有効化してから各インスタンスがロールの認証情報を使い始めるまで、最大30分かかります。インスタンスプロファイルが ssm:UpdateInstanceInformation を許可している場合は、その認証情報がDHMCより優先されます。DHMCの権限を使わせる場合は、インスタンスプロファイルからこの操作の許可を外します。DHMCで登録した情報はLinuxでは /var/lib/amazon/ssm、Windowsでは C:\ProgramData\Amazon に保存されます。ここを消すとDHMCの認証情報を取得できなくなり、インスタンスプロファイルを付けるかインスタンスを作り直すことになります。

SSM Agentのインストール手順（OS別）

プリインストール済みのAMI

AWSの一覧では、次のOSのAMIでSSM Agentが最初から入っている可能性が高いとされています。

Amazon Linux 2・Amazon Linux 2023（ECS・EKS最適化AMIを含む）
Ubuntu Server 18.04・20.04・22.04 LTS・24.04 LTS・25.04（Snapパッケージ）
Windows Server 2016・2019・2022（Nanoを除く）・2025、2016年11月以降に公開された2012 R2
SUSE Linux Enterprise Server 15.3以降、AlmaLinux、macOS 13〜15

同じページには「AMIに入っている版は最新とは限らない」とも書かれています。起動直後のエージェントは古い可能性があるので、後述の自動更新を必ずセットにします。Amazon Linux 2から2023への移行でAMIを作り直す場合の確認項目はAmazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しにまとめています。

RHEL・Ubuntuへの手動インストール手順

RHEL 8・9のようにエージェントが入っていないOSでは、リージョンのS3にあるRPMを直接指定してインストールします。東京リージョン（ap-northeast-1）の例です。ARM（Graviton）のインスタンスでは linux_amd64 を linux_arm64 に変えます。

# RHEL 8・9（x86_64）
sudo dnf install -y https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable --now amazon-ssm-agent

# Ubuntu Server（Snapで入れ直す場合）
sudo snap install amazon-ssm-agent --classic

初回起動時に自動で入れたいときは、EC2のユーザーデータの先頭に #!/bin/bash を書き、そのOSに対応するコマンドだけを続けます。ユーザーデータはrootで実行されるため、sudo は不要です。WindowsではSSM AgentのインストーラーをダウンロードしてPowerShellで実行し、サービス「AmazonSSMAgent」として常駐させます。

オンプレミス・他クラウドのサーバー登録手順

EC2以外のマシンは、IAMロールの代わりに「ハイブリッドアクティベーション」で登録します。コンソールかCLIでアクティベーションを作るとコードとIDが発行され、それを使って ssm-setup-cli がエージェントの導入と登録をまとめて行います。公式手順では、アクティベーションの有効期限は既定24時間・最長30日、登録できる台数は既定1台です。期限が切れても登録済みのノードには影響せず、追加で登録したいときに新しいアクティベーションを作り直します。

# Amazon Linux 2・RHEL 7.x・Oracle Linux の例（コードとIDはアクティベーション作成時の値）
mkdir /tmp/ssm
curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "ACTIVATION-CODE" -activation-id "ACTIVATION-ID" -region "ap-northeast-1"

登録したノードのIDは mi- で始まり、EC2の i- と区別されます。ハイブリッドノードは2026-06-30にAdvanced Instances Tierが廃止され、台数に関係なく登録料がかからなくなりました。代わりにSession ManagerとRun Commandが利用単位の課金になったので、詳細は後述の料金の章で確認してください。

SSM Agentの起動状態・バージョンの確認方法

起動状態の確認と起動コマンド

公式ドキュメントに載っているOS別のコマンドです。Ubuntuの公式AMIはSnap版なので、サービス名が他のLinuxと違います。

OS	状態確認	起動
Amazon Linux 2/2023・RHEL・SLES	sudo systemctl status amazon-ssm-agent	sudo systemctl start amazon-ssm-agent
Ubuntu（Snap版）	systemctl status（サービス名は下記）	sudo snap start amazon-ssm-agent
Windows Server	Get-Service AmazonSSMAgent	Start-Service AmazonSSMAgent
macOS	ログを確認（専用コマンドなし）	sudo launchctl start com.amazon.aws.ssm

Ubuntu（Snap版）のサービス名は snap.amazon-ssm-agent.amazon-ssm-agent.service です。sudo systemctl status amazon-ssm-agent と打つと「見つからない」と返り、未インストールと誤解しやすい箇所です。

バージョン確認コマンド（Linux・Windows）

Fleet Managerのマネージドノード一覧の「SSM Agent version」列で全台をまとめて確認できます。ノードにログインして確かめる場合は、公式の確認方法に沿って次のコマンドを使います。

# Amazon Linux 2/2023・RHEL
yum info amazon-ssm-agent      # RHEL 8以降は dnf info amazon-ssm-agent でも可

# Debian
apt list amazon-ssm-agent

# Ubuntu（Snap版）
sudo snap list amazon-ssm-agent

# Windows Server（PowerShell）
& "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe" -version

Windowsの出力は SSM Agent version: 3.x.x.x の形式です。複数台をまとめて調べるなら、Fleet Managerの一覧かRun Commandでの一斉実行が早く済みます。

SSM Agentを自動更新する設定

SSM Agentは更新の頻度が高く、GitHubのリリース一覧では 3.3.5068.0（2026-08-05）、3.3.5226.0（08-20）、3.3.5390.0（09-17）、3.3.5512.0（10-08）と2〜4週間おきに新版が出ています。更新内容にはセキュリティ修正も含まれます。リリースノートでは、3.3.5226.0に「Windowsのdomainjoinプラグインのパラメータにおけるシェルインジェクションの修正」、3.3.1957.0にオーケストレーション用ディレクトリのパストラバーサル対策が記載されています。古い版を放置すると、新機能が使えないだけでなく、既知の脆弱性も残ります。

公式が推奨する方法は、Fleet Managerの設定1つで全ノードを自動更新する方法です。

Systems Managerコンソールで「Fleet Manager」を開く
「設定（Settings）」タブを開く
「Agent auto update」の「Auto update SSM Agent」を選ぶ

有効にすると、Systems Managerが2週間ごとに新しい版を確認し、新版があればSSMドキュメント AWS-UpdateSSMAgent で更新します。実体はState Managerの関連付けなので、実行履歴はState ManagerとRun Commandに残ります。更新先の版を固定したいときは「Edit」の「Parameters」で版番号を指定し、止めたいときは「Delete」で関連付けを消します。

検証用のノードだけ先に上げたい、更新を業務時間外に寄せたいといった本番の要件には、タグで対象を絞った関連付けをCLIで作ります。次の例は毎週日曜2時（UTC）にタグ付きのノードだけを更新します。--apply-only-at-cron-interval を付けないと、関連付けを作った直後にも1回実行されます。

aws ssm create-association \
  --targets Key=tag:UpdateGroup,Values=staging \
  --name AWS-UpdateSSMAgent \
  --schedule-expression "cron(0 2 ? * SUN *)" \
  --apply-only-at-cron-interval

Bottlerocket OSは AWS-UpdateSSMAgent では更新できず、コントロールコンテナ側で更新されます。EKSでBottlerocketを使っている場合、この設定の対象外になる点に注意してください。

Session Managerによる踏み台不要の接続手順

SSM Agentが入っていれば、Session Managerで22番ポートを閉じたまま、SSH鍵も踏み台サーバーも持たずにシェルを開けます。接続元のPCにはAWS CLIとSession Managerプラグインを入れます。ノード側のSSM Agentは、シェル接続なら2.3.68.0以降、次のポートフォワード例なら2.3.672.0以降が条件です。

# シェル接続
aws ssm start-session --target i-1234567890abcdef0

# ポートフォワード（ノードの8080番を手元の18080番へ）
aws ssm start-session --target i-1234567890abcdef0 \
  --document-name AWS-StartPortForwardingSession \
  --parameters "portNumber=8080,localPortNumber=18080"

誰がいつ接続したかはCloudTrailの StartSession イベントに記録され、通常のシェルセッションの操作内容は、ログ保存を設定するとS3やCloudWatch Logsへ保存できます。ただし、ポートフォワードやSSH経由のセッションでは、Session Managerによる操作内容の記録はできません。ポートフォワードの用途として、EC2上のブラウザ版VS Codeを外部に公開せずに開く手順をcode-serverの使い方：導入・認証・拡張機能・HTTPS公開の手順で紹介しています。踏み台サーバーを残すべきケースや多段SSHとの比較は踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】で扱っています。

観点	Session Manager	踏み台サーバー
インバウンド22番	不要	踏み台側で必要
SSH鍵の配布	不要（IAMで認可）	必要
追加サーバー	不要	踏み台の運用・パッチが必要
接続の記録	CloudTrail・S3・CloudWatch Logs	自前で設計
EC2での料金	追加料金なし	踏み台のインスタンス代

EC2への運用アクセスならSession Managerを第一候補にします。踏み台サーバーを残すのは、Session Managerの対象にできない機器やAWS外のネットワーク要件がある場合です。

SSM Agentの料金（2026年の改定）

SSM Agent自体は無料です。料金がかかるのは、エージェントを通じて使うSystems Managerの機能です。Systems Managerの料金ページによると、2026年にハイブリッド・マルチクラウドノードの課金体系が変わりました。

対象	Session Manager	Run Command
EC2インスタンス	追加料金なし	追加料金なし
ハイブリッド・マルチクラウドノード（2026-09-30以降）	0.05ドル／セッション	0.002ドル／実行

ハイブリッドノードは2026-06-30にAdvanced Instances Tierが廃止され、登録料とノード単位の料金はなくなりました。6月30日から9月30日までの移行期間は非課金で、9月30日から上の単価が適用されています。料金ページの試算例では、200台で1台あたり月4回のRun Commandと1回のセッションを使うと月11.6ドルです。オンプレミスへ頻繁にSession Managerで入る運用なら、接続回数を見積もりに含めます。Patch ManagerもハイブリッドノードではRun Command経由の処理が課金対象になります。

SSM Agentの権限設計で見落としやすい点

SSM Agentでは、IAMの権限がそのままサーバーの管理者権限になります。導入時に次の3点を確認してください。

root権限で動くエージェントとSendCommandの絞り込み

公式ドキュメントのとおり、SSM AgentはLinuxではroot、WindowsではSYSTEMの権限で動きます。そのため、ssm:SendCommand と ssm:StartSession を許可されたIAMプリンシパルは、事実上そのノードの管理者です。"Resource": "*" のまま全員に配るのは避け、ssm:resourceTag/Environment のようなタグ条件で、検証環境と本番環境の操作者を分けてください。誰がどのノードに入ったかの追跡には、CloudTrailの証跡設計も合わせて見直します（CloudTrailとは？証跡設計と料金実額）。

ssm-userのパスワードなしsudo権限の削除

Session Managerで接続すると、既定では ssm-user というローカルユーザーでログインします。SSM Agent 2.3.50.0以降は、このユーザーを作るときにLinuxでは /etc/sudoers.d/ssm-agent-users へ ssm-user ALL=(ALL) NOPASSWD:ALL を書き込みます。Windowsでは管理者グループに追加します。シェルに入れる人全員にroot権限を渡したくない場合は、公式手順どおりこのファイルを書き換えます。

cd /etc/sudoers.d
echo "#User rules for ssm-user" | sudo tee ssm-agent-users

あわせて、Session Managerの設定で「Run As」を有効にし、IAMユーザーやロールのタグに応じたOSユーザーでログインさせると、操作者ごとに権限を分けられます。

認証情報の優先順位の落とし穴

SSM AgentはAWS SDKの既定の順序で認証情報を探します。技術詳細のページによると、Linuxではrootとして動くため、/root/.aws/credentials や環境変数にアクセスキーがあると、インスタンスプロファイルより先にそちらが使われます。作業のためにrootでAWS CLIを設定した結果、権限の足りないキーでエージェントが動き、ノードが管理対象から外れるという事故が起きます。サーバー上にアクセスキーを置かないことが根本的な対策で、アプリケーションの設定値はAWS Parameter Storeから読む形に寄せます。

管理対象に出てこないときの切り分け

「エージェントは動いているのにFleet Managerに出てこない」ときは、まずノード上で ssm-cli を実行します。SSM Agent 3.1.501.0以降に同梱されている診断コマンドで、IMDSへの到達、各エンドポイントへの接続、認証情報の取得元などを表にして返します。

# Linux・macOS
sudo ssm-cli get-diagnostics --output table

# Windows（PowerShell。C:\Program Files\Amazon\SSM で実行）
.\ssm-cli.exe get-diagnostics --output table

結果が「Failed」になった項目から順に、次を確認します。

IAM：インスタンスプロファイルに AmazonSSMManagedInstanceCore があるか。DHMCを使う場合はIMDSv2とエージェント3.2.582.0以降か。
通信：ssm・ssmmessages に443番で届くか。VPCエンドポイントのセキュリティグループで、インスタンスからの443番を許可しているか。
メタデータ：インスタンスメタデータのアドレス 169.254.169.254 へ届くか。ファイアウォールやプロキシ設定で塞いでいないか。
認証情報の上書き：/root/.aws/credentials や環境変数が残っていないか。
ログ：Linuxは /var/log/amazon/ssm/amazon-ssm-agent.log と errors.log、Windowsは %PROGRAMDATA%\Amazon\SSM\Logs\。

Systems Managerはノードの状態を5分ごとに確認するため、権限や経路を直してからコンソールに反映されるまで数分かかります。

大量のEC2をSystems Managerで管理する体制づくりや、閉域網でのVPCエンドポイント設計から相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援も参考にしてください。

よくある質問

SSMとは何の略ですか？

AWS Systems Managerの旧称「Amazon Simple Systems Manager（SSM）」に由来する略称です。サービス名が変わった後も、CLIの aws ssm、IAMのアクション名 ssm:、エージェント名などにSSMが残っています。SSM AgentはSystems Managerの指示をノード上で実行するエージェントです。

SSM Agentは無料で使えますか？

SSM Agent自体は無料です。EC2でのSession Manager・Run Command・Patch Managerにも追加料金はかかりません。オンプレミスや他クラウドのハイブリッドノードでは、2026年9月30日からSession Managerが1セッション0.05ドル、Run Commandが1回0.002ドルで課金されます。

SSM AgentのバージョンはWindowsでどう確認しますか？

PowerShellで & "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe" -version を実行すると表示されます。複数台を確認するなら、Fleet Managerのマネージドノード一覧にある「SSM Agent version」列を見るほうが早く済みます。

amazon-ssm-agentプロセスとは何ですか？

SSM Agent本体の常駐プロセスです。Linuxでは amazon-ssm-agent、Windowsでは amazon-ssm-agent.exe（サービス名AmazonSSMAgent）として動きます。Session Managerの接続中は、子プロセスとして ssm-session-worker も起動します。停止するとノードとの接続が失われ、コマンド実行やセッション接続ができなくなります。登録が即座に解除されたり、Fleet Managerの一覧から直ちに消えたりするわけではありません。