はじめに
リモートのサーバーの調査も、ローカルのClaude Codeからできたらいいのに、と思うことがありました。
調べてみたところ、AWS Systems Manager（SSM）を使えばできそうです。SSMを使うと、サーバー上のコマンドをリモートから実行できます。ローカルのClaude Codeが aws ssm のコマンドを実行する形で、サーバーを直接調査できる、というのが私の理解です。
この記事では、SSMの概要、設定の流れ、気をつけたい点を整理します。
SSM（AWS Systems Manager）とは
SSMは、AWS上やオンプレミスのサーバー（SSMでは「ノード」と呼びます）を、一元的に見て管理するためのサービスです。Run Command、Session Manager、Parameter Store などのツールがあります。
公式ドキュメントによると、サーバーにログインしなくても、リモートから安全にコマンドを実行できます。SSH接続を使う必要がなくなる、ということですね。
名前の由来も少し面白いです。以前は「Amazon Simple Systems Manager」や「Amazon EC2 Systems Manager」と呼ばれていました。略称の「SSM」はその名残で、SSM Agent、aws ssm コマンド、エンドポイント（ssm.region.amazonaws.com）などに、今も残っています。
SSMを使うには、サーバーを「マネージドノード」にする必要があります。SSM Agent がインストールされていて、SSMのサービスと通信できる状態のことです。ノードにはEC2のインスタンスだけでなく、オンプレミスなど、EC2以外のマシンも含まれます。
設定方法
設定は、サーバー側、権限、ローカル側の3つに分かれます。
- サーバーをマネージドノードにする。
SSM Agent が動いていて、SSMのサービスと通信できる状態にします。EC2の場合は、SSM用のIAMロールを用意して、インスタンスに付けます。ロールには、AmazonSSMManagedInstanceCore という管理ポリシーを含めます。 - 操作する側のIAM権限を用意する。
サーバーに入らずに、コマンドやスクリプトをリモートから実行できるRun Command という機能を使うならssm:SendCommandなどを許可します。対象のサーバーはタグで、実行できるSSMドキュメントはARNで、絞り込めます。ARNは、AWSのリソースを一意に識別するための名前で、arn:aws:ssm:us-east-1:111122223333:document/YourDocument のような形をしています。 - ローカルでAWS CLIを使えるようにする。
認証情報は、長期キーを持つIAMユーザーより、一時的な認証情報を使うのが無難です。 - コマンドを実行する。
Run Command で、サーバー上のコマンドをリモートから実行します。
対話的にシェルへ入りたい場合は、Session Manager を使います。公式ドキュメントに、aws ssm start-session --target <インスタンスID> という形の例があります。
Claude Codeからは、この aws ssm ... のコマンドを実行してもらう形になります。私の推測では、対話的な start-session より、コマンドを投げて結果を受け取る Run Command の方が、Claude Codeからは扱いやすいはずです。
懸念点
便利な反面、気をつけたい点が3つあります。
1. 権限は絞れるが、「読み取りだけ」まではIAMで保証できない
公式ドキュメントでは、Run Command で実行できるSSMドキュメントをARNで、対象のサーバーをタグで、絞り込めると説明されています。Session Manager も、自分で作ったセッション用ドキュメントだけを使えるよう、IAMで制限できます。
ただし、IAMが見ているのは「誰が、どのドキュメントを、どのサーバーに対して実行できるか」です。実行されるコマンドの中身が、読み取りかどうかまでは見ていないはずです。自由にシェルを使える状態だと、読み取り専用にはなりません。
現実的な対策は、df や tail など、読み取りのコマンドだけを固定で実行するカスタムドキュメントを作り、それだけを許可する方法が考えられます。
2. 出力はClaudeに渡る
サーバーにClaudeを入れなくても、コマンドの出力（ログや設定内容）は、ローカルのClaude Codeに渡ります。つまり、その内容が外部のAIサービスに送られる、ということです。送ってよい情報かどうかは、会社や顧客の規約も含めて、確認が必要です。
3. 自由度との引き換えになる
固定ドキュメント方式は、自由に使える状態より安全ですが、Claudeに自由に調査させるのは難しくなります。安全性と自由度は、トレードオフです。
なお、実行の記録は残しておくと安心です。Run Command は、コマンドの出力と、エラーのログを、CloudWatch Logs に送るよう設定できます。
サーバーに直接Claudeをいれてしまえばいいのでは
入れてよいかどうかは、会社や顧客の規約によるという大前提ですが、
入れずに済むなら、入れずにローカルのものを利用する方が管理しやすいと考えています。
- サーバーに認証情報を置かなくて済む
- サーバーから外部のAIサービスへ出る通信を、開けなくて済む
- 実行するコマンドを、手元で確認してから流せる
- サーバー側の変更が小さく、承認も取りやすいはず
- 個人のサブスクリプションで動かすと、他の人が使いたくなったときに不便
ただし、SSMの場合も「サーバーに何も入れない」わけではありません。SSM Agent は必要です。
FYI: SSH接続とSSMの違い
SSMは、インバウンドポートを開かず、踏み台ホストも使わずに、サーバーへ接続できる点がSSHと大きく違います。
| 項目 | SSH | SSM |
|---|---|---|
| インバウンドポート | SSHは既定で22番ポートを使う。EC2では、セキュリティグループで22番ポートの受信を許可する必要がある | 開かずに接続できる |
| 踏み台ホスト | プライベートサブネットのサーバーに入るために、踏み台ホストを経由する構成がある | 使う必要がなくなる |
| サーバー側の前提 | サーバー側でsshdが待ち受け、手元のsshクライアントから接続する | SSM Agent とSSMサービスへの通信 |
| 権限の管理 | 公開鍵認証が標準的で、EC2ではキーペアを使う | IAMで、実行できる操作や対象を制御できる |
おわりに
SSMを使えば、サーバーにClaudeを入れなくても、ローカルのClaude Codeからサーバーを調査できそうです。
一方で、権限の絞り方と、出力がClaudeに渡る点には、気をつける必要があります。まずは、読み取りだけの権限から試すのが良さそうです。