はじめに

前回の記事では、AWS CDKを用いてALB→ECS(Fargate)構成を構築し、Spring Bootアプリをデプロイするまでの流れを試しました。

今回はその続きとして、Amazon ECS MCP Server を検証します。
今年は新しい MCP（Model Context Protocol）Server が次々と登場しており、その中のひとつが Amazon ECS MCP Server です。これは、Amazon ECS 環境を AI エージェントから操作できるようにする拡張機能で、今年5月に公開されたばかりのサービスです。

AWS公式ブログでは、新しいアプリケーションを対話的にデプロイしたり、既存クラスターの状態を問い合わせたりといったユースケースが紹介されています。今回はキャッチアップを兼ねて、実際に構築したECS環境で本機能を活用できるかどうかを試してみました。

1. ECS MCP Serverが提供する機能とは

ECS MCP Serverの概要は、以下の公式ブログやドキュメントで紹介されています。

ここでは内容をざっくりまとめてみます。

Amazon ECS MCP Serverは、Model Context Protocol (MCP) を使ってECSの操作をAIアシスタントから行えるようにする拡張機能です。コンソールやCLIを開かなくても、対話形式でECSの情報を確認したり、デプロイを実行したりできるのがポイントです。

MCP Serverにはいくつかのツールが用意されていて、用途に応じて使い分けられます。

ツール名	概要
containerize_app	開発中にDockerfileを作りたいときにガイドしてくれるツールです。
create_ecs_infrastructure	AWS CloudFormationを使ってECSのインフラを構築したいときに利用します。
get_deployment_status	デプロイの進行状況を手早くチェックしたいときに便利です。
ecs_resource_management	クラスター内のサービスやタスクを一覧化したり、リソース管理をサポートします。
ecs_troubleshooting_tool	ECSサービスやタスクで発生している問題を診断したいときに使います。
delete_ecs_infrastructure	もう不要になったECSのリソースをクリーンアップしたいときに役立ちます。

これらのツールを組み合わせることで、ECSの構築から運用、トラブルシューティング、廃止まで、幅広い操作をAIアシスタント経由で実行できるようにするというのが狙いのようですね。

2. 検証環境とセットアアップ

既存のECS(Fargate)構成

前回の記事で構築した構成がこちらです。実務で使うには考慮不足なところが多いシンプル構成ですが、ご承知おきください。

MCP Serverのセットアップ手順概要

今回は ecs-mcp-serverに加えて、cdk-mcp-serverとaws-documentation-mcp-serverも設定してみました。
手元の開発環境にMCP Serverをセットアップし、既存のECSクラスターに接続できるようにした流れをまとめます。

1) CursorでMCPを使えるようにする

普段使っているIDEはCursorなので、今回はそこにMCPを組み込んで使えるように設定しました。
まずは必要なCLIツールをインストールして環境を整えます。

# uvをインストール
brew install uv
uv --version
# → uv 0.7.19 (Homebrew 2025-07-02)

# Python 3.10をpyenv経由で入れる
pyenv install 3.10.0
pyenv versions
# * 3.10.0 が選択されていればOK
python --version
# → Python 3.10.0

MCPサーバーはPython 3.10以上が必要なので、このバージョンを選びました。

2) AWS CLIでアクセス確認

MCPサーバーからECSにアクセスできるよう、ローカルのAWS CLIでプロファイルが使える状態か確認しておきます。

aws s3 ls --profile hosso
2025-07-07 21:13:57 #################

このようにバケットが一覧表示されれば、認証周りはOKそうですね。

3) CursorにMCP設定を追加する

次に、mcp.json に設定を追記します。
今回はCDK用、AWSドキュメント用、ECS用の3種類を有効化しました。

mcp.json

{
  "mcpServers": {
    "awslabs.cdk-mcp-server": {
      "command": "uvx", 
      "args": ["awslabs.cdk-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"         // ログレベル設定
      },
      "disabled": false
    },
    "awslabs.aws-documentation-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",        // ログレベル設定
        "AWS_DOCUMENTATION_PARTITION": "aws" // 検索対象のAWSパーティション
      },
      "disabled": false
    },
    "awslabs.ecs-mcp-server": {
      "command": "uvx",
      "args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"],
      "env": {
        "AWS_PROFILE": "hosso",              // 利用するAWS CLIプロファイル名
        "AWS_REGION": "ap-northeast-1",      // ECSクラスターのリージョン
        "FASTMCP_LOG_LEVEL": "ERROR",        // ログレベル設定
        "FASTMCP_LOG_FILE": "/tmp/ecs-mcp-server.log", // ログ出力先ファイル
        "ALLOW_WRITE": "false",              // 書き込み操作を禁止（安全対策）
        "ALLOW_SENSITIVE_DATA": "true"       // 機密情報を取得可能にする
      }
    }
  }
}

基本的には公式ドキュメントの内容をそのままコピペしてますが、
設定内容のポイントをコメントで書き添えていますので、必要に応じて値を変更してみてください！

設定が反映されると、Cursorの「MCP Tools」にawslabs.ecs-mcp-server、awslabs.aws-documentation-mcp-server、awslabs.cdk-mcp-serverが表示され、有効化できるようになります。

必要に応じて、直接レポジトリクローンしてきて指定する方法も試してみてください。

これで準備は完了です！以降は、Cursor上からECSのクラスター情報をAI経由で取得したり、デプロイ状況を尋ねたりできるようになります。

3. 試してみたこと

ここからは、実際に構築済みのECSクラスターに対して、MCP Serverを経由してどんな操作ができるのかを試してみます。
今回の環境では、以下のクラスターとサービスが存在しています。

クラスター名: ecs-mcp-server-demo-dev-cluster
サービス名: ecs-mcp-server-demo-dev-service

MCP Serverにはさまざまなツールが用意されていますが、今回は既存環境の調査や運用で使えそうな以下の3つを試してみました。

ecs_resource_management
get_deployment_status
ecs_troubleshooting_tool

それぞれ、プロンプトを投げてみてどんな情報が返ってくるのかを確認してみます。

クラスターやサービスの情報を確認する

まずは、ECSのクラスターやサービス情報を取得できるか試します。

💡 対象アカウント内に存在するクラスター名等の情報が確認できました。

💡 クラスターを指定すると、紐づくサービス等の情報を確認できました。

💡　対象サービスに設定されているタスク定義の情報が返却され、コンテナ名やリソース指定などを確認できました。

ecs_resource_managementツールを使うことで、クラスターやタスク定義の基本的な情報がテキストでサクッと返ってくるのが分かりました！

デプロイ状況をチェックする

続いて、デプロイ状況を確認できるかを試します。

（ツール: get_deployment_status）

💡 現在進行中のデプロイ情報がテキストで返却され、タスクの状態や更新状況を素早く把握できます。

💡 デプロイのイベント履歴を簡単に参照できるため、エラーや遅延が発生していないかをチャット感覚でチェックできます。

トラブルシューティングに使えるか試す

最後に、ECSでありがちな「タスク起動エラー」を、MCP Serverを使ってどこまで診断できるかを試してみました。

今回はあえて失敗するような設定を仕込んで、タスクがSTOPPED状態になるケースを再現しています。

ケース①: タスク定義に存在しないコンテナ名を指定して、起動時に ResourceNotFoundException をわざと発生させてみました。

わざと誤ったコンテナ名を指定してタスクを起動しています。

💡 MCP Serverに調査を依頼したところ、「リソースが見つからない」というエラーを拾えました。

💡 STOPPED理由が明示されているので、コンソールを開かなくても原因をすぐ把握できます。

ケース②: タスク実行ロールに、ECRからイメージをPullするための権限を付けずにタスクを起動し、CannotPullContainerError を発生させました。

あえてECR Pullの権限を外したタスク定義を使って起動しています。

💡 タスクがSTOPPEDになり、MCP Server経由で調査を開始。

💡 イベントメッセージに「CannotPullContainerError」が出ているのがわかります。

💡 「ECRへのアクセス権限がない」ことまで推測でき、原因特定がかなり早くなります。また解決策まで提示してくれていることがわかります。

こうやってMCP Serverに聞くと、失敗したタスクのイベントメッセージやSTOPPED理由が返ってきます。
特にECR Pullの失敗時にはCannotPullContainerErrorがそのまま出るので、「あ、権限が足りないな」とすぐ気づけました。

チャット感覚で失敗理由だけパッと取れるのは、障害発生時の一次切り分けにかなり便利です。
実際に、この手の「権限抜け」や「コンテナ定義ミス」は案外起きがちなので、MCP経由で素早く確認できるのは大きな助けになると感じました。

ecs_troubleshooting_toolの利用を期待してトラブルシューティングを試してみたのですが、ツールの呼び出し時にエラーを繰り返しており、うまく機能しませんでした・・。(2025/8/3時点)

5. 使ってみて感じたこと

今回、ECS MCP Serverを既存のクラスターに接続して試してみたんですが、実際に触ってみて感じたことをまとめてみます。

Goodだと感じたこと

対話形式での操作は思った以上に楽
これまでAWSコンソールやCLIを開いて確認していた操作が、チャット感覚でポンポン聞けるのはすごく便利でした。
「このサービスの状況をざっくり見たい」「直近のデプロイ進捗どうなってる？」みたいな軽めの確認は、かなり時短になりますね。
トラブルシューティングの一次切り分けが早い
タスクがSTOPPEDになったとき、イベントログや理由をすぐに返してくれるのは助かります。いちいちCloudWatchログを開いてスクロールしなくても、「エラー内容だけ知りたい」がすぐ叶うので、障害の初動調査はかなりスピードアップしそうです。
操作履歴がそのまま共有できる
MCP経由だとやり取りがテキストで残るので、「このプロンプトでこれを確認したよ」とそのままチームに共有できます。スクショやCLIログを貼り付ける手間がないのは地味に嬉しいポイントでした。

改善の余地がありそうなこと

ツールが安定していないことがある
ecs_troubleshooting_toolを試したとき、呼び出しエラーが出ることが何度かありました。まだ初期サービスということもあって、安定性は今後に期待といった感じです。
できることはまだ限定的
現時点では情報取得や簡単な診断が中心で、例えばデプロイパラメータを変更したり、深いトラブルシュートを自動化したり…というところまでは踏み込めません。
CLIやコンソールの完全代替までは、もう少し時間がかかりそうです。
権限や設定ミスには注意が必要
ALLOW_WRITEやALLOW_SENSITIVE_DATAの設定を間違えると、本番環境で予期せぬ操作をしてしまうリスクもあります。プロファイルごとに権限をちゃんと管理したほうが安心ですね。

ECS MCP Serverはまだ発展途上な部分が多いですが、対話形式でAWSリソースを触れる体験はかなり面白かったです。
「今の状況だけサクッと知りたい」「原因だけパッと把握したい」みたいな場面では、もう十分に使える印象でした。

6. まとめ

いかがだったでしょうか。

今回は、ECS MCP Serverを既存のクラスターに接続して、どのように活用できそうかを試してみました。

今回はあくまで構築済みリソースに対する利用例でしたが、新規開発やコンテナ移行といったシナリオでも役立つ機能がまだまだありそうです。そういったケースでも検証してみたいですね。

また対話形式でECSの状態を確認できるのは新鮮味があって、特に軽めの調査や初動対応には良さそうと感じました。
現状は機能面や安定性に課題もありますが、今後の進化次第では日常運用の強力なサポートツールになりそうです。アップデートに期待したいですね。