MCP Serverを使ってECSを自然言語で操作してみた 〜AWSインフラ運用を”対話”で完結させるアプローチ〜 | SPIDERPLUS Tech Blog

企業テック

こんにちは。
PF開発部 / SREチーム所属の平木です。

💡はじめに

今年に入って公開されたAmazon ECS MCP Serverを試してみたので、その内容をまとめました。

 

普段ECSを運用していると、コンテナにログインして hostname を確認したり、
タスクを再起動するなど、ちょっとした操作を行うことがあります。
「これ、自然言語でできたら便利じゃない?」と思ったことはありませんか?

実際にMCP Serverを導入して、チャット画面からECS操作を行える環境 を構築した結果を紹介します。

⚙️ MCP Serverとは

🔹 MCP (Model Context Protocol) の概要

MCPとは、AIクライアントと外部ツール間の通信を標準化するオープンプロトコルです。
AIクライアントは、MCPサーバを介して外部システムと安全にやり取りできます。

MCP Serverはその中継役として、クライアント (例: ChatGPT, Cursorなど) からの自然言語リクエストを受け取り、実際のAPIやコマンドを呼び出す役割を担います。

📘 参考: MCP の概要 – Amazon Q Developer より引用

🎯 今回の目的とシナリオ

今回の検証では、以下のようなユースケースを想定しました。

  • 目的 :  AIクライアント(Cursor)からECS操作を自然言語で実行
  • 対象 : Amazon ECS MCP Server
  • 検証範囲 : ECSクラスタの一覧取得、コンテナログイン

📈 なぜ有用か？

  • CLI不要 :  IDEのチャット画面上で操作可能
  • 作業の再現性が高い : 自然言語を履歴として残せる
  • 非エンジニアでも操作理解しやすい : ドキュメント代わりになる

🧩 環境準備

1. uvのインストール

MCP ServerはPython 3.10以上が必要です。
パッケージマネージャ uv を使用してインストールします。
※Macの場合

brew install uv

2. MCP Server設定 (Cursorの場合)

  1. awslabsのGitHubページ の Configuration セクションにある
    「Add to Cursor」ボタンをクリック。


  2. 「Cursorを開く」→ 設定画面を開きます。

※今回の検証では VSCode で一部設定が不安定だったため、Cursorでの例を紹介します。

3. Environment Variables設定

設定画面に以下の項目を追加します。

Environment Variables項目

設定値

AWS_PROFILE

接続対象AWS環境のProfile名（ローカル設定済のものを指定）

ALLOW_WRITE

AWS上でリソースを作成・変更する場合は true に設定
falseの場合、読み取り系APIのみ実行可能

⚠️注意：ecsクラスタ一覧 を取得する場合でも、ALLOW_WRITE=true が必要でした

 

設定項目の入力が完了したら Install ボタンを押します。

インストール後、表示パネルの緑ランプが点灯すれば有効です ✅ 

🧠 実践：自然言語でECSを操作する

ようやく設定ができたので使って行きます！

ここからは、実際にチャット画面上でECSを操作してみます。

Step 1：ECSクラスタ一覧の取得

チャット画面に以下のように自然言語で入力します。

「ECSクラスター一覧を取得してください」

すると、List_Clusters APIの実行確認が表示されるので、RUN 押下で実行します。

クラスタARNの一覧が取得されます。(ARN 一覧はマスク済)

Step 2：ECSタスクにログイン、確認

ECSサービス内の特定のタスクを指定しログイン、hostname を確認してみます。
ここでも以下のように自然言語で入力します。

「ECSタスクにログイン、hostnameを取得してください」

ここではExecuteCommand APIが実行され、下記のようなレスポンスが返ってきました。

マスク部分のイメージ

hostname

ip-10-1-2-34.ap-northeast-1.compute.internal
他にも uname -a や環境変数の確認など、同コンテナで追加コマンドを実行しますか？

⚠️ 注意：この操作を行うには、3. Environment Variables 設定で言及したように、 ALLOW_WRITE=tru に変更する必要がありました。

📊 実際に試してみた感想

項目

Before (CLI操作)

After (MCP操作)

操作性

コマンド暗記が必要

手動手順

自然言語で操作可能

履歴で再利用可能言語で操作可能

再現性

利用者の習熟度による

習熟度に依存しないため高い

学習コスト

高い

低め (利用者目線)

誤操作リスク

高め

許可設定で制御可能

実際に使ってみて、CLIより手軽で再現性が高いと感じました。
特に、日常的な確認作業 (例 : コンテナ状態確認やログ取得) を対話的に実行できる点が魅力的です。

🔍 注意点と今後の展望

  • 注意点
    • ALLOW_WRITEの制御は慎重にお願いします。権限設定を誤るとリソース変更リスクが発生します。
    • AWS CLI同様、権限ポリシーに依存するため IAM 設定を事前確認にした方が良いかと思います。
  • 今後の展望
    • ECS以外のサービス (Lambda, RDSなど) への展開も検討したいです
    • ChatOps的運用自動化のも検討していきたいです
    • AIエージェントとの連携による運用の自律化も検討していきたいです

🧾 まとめ

  • MCP Server を使えば、ECS操作を自然言語で完結できる事が分かりました
  • 環境構築はシンプル (uv + 環境変数設定)でした
  • 再現性・操作性・安全性のバランスが良かったです
  • 今後の運用自動化における重要な一歩となりそうです

💬 おわりに

これまでCLIで手動実行していた操作をチャット画面で「自然言語で話しかけるだけで実行できる」のは新鮮でした。

「わかっていたけれど、やってみるとすごく便利」
この体験が 現場のSRE・インフラ作業の効率化 につながると感じています。

今後はこの仕組みを社内運用にも取り入れ、対話で完結するインフラ運用 を目指して手離れを良くし、よりプロアクティブな組織を目指していきたいと思います。

📚 参考リンク

「自然言語でインフラの状態確認」の可能性、感じていただけたでしょうか?

スパイダープラスでは、新しい技術を積極的に取り入れ、一緒に成長する仲間を歓迎します。
ご興味があれば、お気軽にお声がけください。




元の記事を確認する

テスト自動化フレームワーク「Playwright」にAIエージェント機能。自動的にテスト計画とテストコードの生成、テストコードのデバッグなど 前の記事 【Hothotレビュー】ポータブルゲーミングPCの概念を破壊する性能。GPDが放つ怪物「GPD WIN 5」 - PC Watch 次の記事

関連記事