re:Invent 2025: MCPでECSとEKS向けAI駆動型開発者体験を構築する方法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Build AI-powered developer experiences with MCP on ECS and EKS (CNS358)
この動画では、Steve KendrexとGeorgeがModel Context Protocol(MCP)を使った開発者エクスペリエンスの構築について解説しています。LLMの制限とRAG、ツールの進化を説明した後、AnthropicによるMCPがどのようにAIエージェントとデータソース間の統合を標準化するかを紹介します。AWSはECSとEKS向けのローカルおよびホステッドMCPサーバーをリリースし、ツール、リソース、プロンプトの3つのコンポーネントを提供します。ホステッドMCPサーバーはSigV4認証を使用し、IAMパーミッション設定とMCPプロキシ経由での接続が必要です。EKS MCPサーバーはクラスター管理、Kubernetesリソース管理、ドキュメント検索、トラブルシューティングツールを提供し、ECS MCPサーバーはオペレーショナル、リソース管理、トラブルシューティングツールを備えています。デモではKiroを使用してクラスターステータス確認、アップグレード準備評価、新規クラスター作成、LoadBalancerのトラブルシューティングを実演し、さらにECSコンソールでのInspect with Amazon Q機能による統合トラブルシューティング体験を紹介しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション概要：Model Context Protocolを使った開発者エクスペリエンスの構築
こんにちは。私の名前はSteve Kendrexです。本日は私とGeorgeで、Model Context Protocolを使った開発者エクスペリエンスの構築についてのセッションをお届けします。MCPに馴染みがない方でも、素晴らしい入門編として、そして私たちのコンテナサービス、Elastic Container ServiceとElastic Kubernetes Serviceでの日常業務におけるMCPの使い方についてご理解いただけると思います。
いくつかのトピックを取り上げていきます。まず全般的に、GenAIエージェントとLLMがどのように進化してきたか、そしてなぜMCPがこれほど有用なポイントに到達したのかをカバーします。MCPについて少し紹介し、私たちAmazonがこれらのことをどのように考えているか、特にコンテナサービスがMCPを使うことでなぜ恩恵を受けるのかについて、おさらいをします。そして、本日皆さんにご利用いただけるようリリースしたECSとEKSのMCPサーバーについて詳しくお話しします。その後、これらのMCPサーバーを使って、コンソールやKiroなどお好みのIDEを通じて、今日できることをデモでお見せします。
それでは、Model Context Protocol、MCPについて少しお話ししましょう。全体的にどのようにしてここに至ったかについてお話しします。これはLLMの非常に基礎的な入門編になります。 私たちが何を構築し、どのように構築したかを正確にご理解いただくために、いくつかの基本的な制約についてカバーしたいと思います。
LLMの基本的な制約：入力と出力の問題
私が孫のために子供向けのギフトを買おうとしている祖母だと想像してください。それが私の基本的なタスクで、こういったタスクを手伝ってくれるはずのAIアシスタントについて聞いたことがあります。 私にはAIアシスタントがあり、LLMがあり、もしかしたらそれらは全く同じものだと思っているかもしれません。本当のところはよくわかりません。ただ質問ができるということだけは知っています。 それでは始めましょう。AWSとは何ですか、と聞くか、あるいは、クリスマスに子供向けの素敵なギフトのアイデアは何ですか、と言うかもしれません。 もちろん、私が使っているインターフェースは何であれ、戻ってきて、はい、これがあなたへの答えです、と言ってくれます。完璧で、まさに私たちが必要としているものです。
ここに制限があります。もう少し具体的にしてみましょう。私はこれらのエージェントを使うことにもう少し慣れてきて、かなり長い間使ってきたので、単に子供向けの素敵なギフトのアイデアは何ですかと聞くだけでなく、もっと先に進みたいと思います。今年最も人気のあるギフトは何ですか、とか、今年使われる必須の子供向けおもちゃは何ですか、と進んでいきます。例えば、私の子供たちはBlueyに夢中だったり、他の様々なおもちゃがあります。子供によってニーズが違うので、たくさんの選択肢があります。今年のベストSTEMトイを使いたいかもしれません。もちろんエージェントは戻ってきて、間に何もなく、まあ、 最良のシナリオでは、実は現在のデータにアクセスできないんです、と言うでしょうし、あるいは、答えを出しますが、その答えが完全に正しくないかもしれないということを私は知らないかもしれません。
もちろん、エージェントに特定のタスクを実行させようとする際には、他にも制限があります。エージェントに実際に何かをさせたい場合、エージェントには世界そのものに関する情報だけでなく、例えば私のAmazonの購入履歴を見て何を買ったか教えてほしいといった、特定のデータを提供してもらいたいわけです。もちろん、エージェントはその情報にアクセスできません。あるいは、エージェントに何かをさせたい場合、例えば具体的に私の代わりに何かを購入してほしいとしても、もちろん何も仲介するものがなければ、 エージェントとエージェントがそのアクションを実行することを許可するものがなければ、それを実行することはできません。 ここに、誰かがコードのバグを修正しようとしたメッセージがありますが、LLMはもちろん「それはできません」と言っています。LLMは、皆さんの中で少なくともある程度触ったことがある方ならご存知の通り、私たちが与える特定のコンテキストと、アクセスが許可されているものと同じくらい良いものでしかありません。
では、制限をまとめてみましょう。私たちには2つの根本的な問題があります。入力の問題と出力の問題です。LLMは理解しませんし、自分が何を知らないのかを知りません。なぜなら、LLMはある時点で訓練されており、訓練された時点以外の世界に存在するものについては何も知らないからです。もちろん、そのコンテキストを非常に詳細に提供することもできますし、これは多くの人がLLMが最初に人気になったときにやったことです。私たちは単に「世界はこうだと仮定してください。過去6ヶ月で世界はこうなったと仮定してください」といったことを言い、そうするとまあまあの仕事をしてくれましたが、それは疲れるものでしたし、しばしば間違えたり、「それは私の訓練データにないので仮定できません」などと言ったりすることもありました。
RAGとツールの導入：エージェントの進化と課題
そこで私たちは、このワークフローに対処するための多くの異なる方法を考え出しました。これがその一つです。 特にRAGは、LLMが大きくなった直後に人気になりました。RAGは、ナレッジベースを通じてエージェントにコンテキストを提供する方法でした。つまり、モデルの訓練から直接情報にアクセスするのではなく、AIアシスタントが プロンプトを受け取るわけです。例えば、今年のホリデーシーズンに子供向けの最も人気のあるSTEMギフトは何ですか、といったプロンプトを受け取り、それから まずそのナレッジベースにアクセスし、そのコンテキストをユーザーに代わってユーザーのプロンプトに注入します。つまり、RAGを調べに行き、ナレッジベースを調べに行き、その情報をプロンプトに引き込み、それがLLMに送られ、そして応答を得るわけです。
もちろん、これにはいくつかの制限があります。なぜなら、ナレッジベースは誰かによって維持されなければならないからです。更新されなければなりません。ナレッジベースに提供されるコンテキストと同じくらい良いものでしかありません。そしてもちろん、どれだけのことができるかについても制限があります。コンテキストウィンドウは非常に非常に大きくなり、プロンプトがどんどん大きくなり、ナレッジベース情報が注入されるようになりました。多くの場合、全体がユーザーに代わってプロンプトに注入されました。
そこで、動的な 検索と動的なコンテキストを行う他の方法があり、これがツールと呼ばれるものの導入につながりました。AIアシスタントが実際にあなたのためにアクションを提供できるようになったのです。 ツールを理解する最も一般的な方法は、ウェブ検索のようなものです。ウェブ検索は非常に強力なツールです。つまり、もちろん 私たちがプロンプトを入力すると、プロンプトが来て、ツールの説明がLLMに送られます。そしてLLMは「わかりました、何をする必要があるかわかりました」と言います。そして、そのLLMがエージェントと対話し、ツールを呼び出すメカニズムがあります。この場合、私たちは子供を幸せにするために最高のSTEMギフトが何かをインターネットで検索しに行きます。 そしてツールの結果を得て、LLMがその情報を統合してユーザーに返すわけです。
さて、この問題は少なくともシンプルなユースケースについては解決できたようですね。問題が出てくるのは、より複雑なユースケースを扱う場合です。例えば、私がエージェントだとして、もちろんクリスマスギフトのアイデアだけでなく、3つの異なることが必要だとしましょう。エージェントがデータベースにアクセスできる必要があります。エージェントはソースコードリポジトリにアクセスして、何か変更があったかどうかを知る必要があります。エージェントはCRMにデータを入力する必要があるかもしれません。以前の世界では、これを実現したい場合、これらすべての成果を達成したい場合、独自の統合を作成しなければならず、エージェントにこれらの異なるシステムへのアクセス方法を具体的に教えてトレーニングする必要がありました。何らかのメカニズムをトレーニングして構築し、正しいAPIを与え、これがこのツールの使い方ですよという正しい方法を与える必要があり、すべてが非常に、非常にカスタムなものでした。そして、それを切り替えたり同僚と共有したりしたい場合、これらすべての制限に対処しなければなりませんでした。再現性がなかったわけです。
これは、モデルとツールのインタラクションにおける問題のいくつかをまとめたものです。これはエンドツーエンドの問題です。モデルとツールの接続ごとにカスタムエンジニアリングが必要で、標準化されたコンテキスト共有がなく、時間の経過とともに知識が古くなっていきます。なぜなら、ここでの根本的な問題は、エージェントが一貫して呼び出しを行い、大量のトークンを消費し、新しい知識をいつどのように取得するかを知らない限り、非常に多くの場合、リアルタイムデータから切り離されたままだったからです。そしてもちろん、モデルは開発の性質上、本質的に新しいデータソースから制限されています。
Model Context Protocol（MCP）の登場：標準化された統合の実現
さて、ここからMCP、Model Context Protocolが登場します。これはAnthropicによって導入されました。Model Context Protocolは、ツールやデータソースを使用するAIアプリとエージェント間の統合のためのオープンスタンダードです。APIについて考えてみると、ウェブバックエンドがどのように動作するかを標準化しています。MCPは、AIがツールとどのようにインタラクションすべきかについて考える、効果的に似た方法です。このように考えてください。必ずしも100%正確ではありませんが、これらのツールがどのようにインタラクションするかを考える方法として有用です。
さて、MCPを使えば標準化された統合を実現できます。MCPとは何か、そしてそれがどのようにこれを実現するかについて少し説明し、その後、私たちのコンテナサービスがこれらのツールをどのように使用して良い結果を提供しているかを説明します。MCPについて話し始めると、異なる用語があります。MCPクライアントをホストするMCPホストがあります。
MCPクライアントについて考えると、それは単にMCPサーバーが実行されているもので、特にローカルのMCPサーバーインストールについて話している場合です。データベース用のMCPサーバーがあり、おそらくGit用のMCPサーバーがあり、CRM用のMCPサーバーがあります。これが意味するのは、データベースホスト、ソースコードリポジトリ、そしてCRMシステムが、そのMCPサーバーを所有し、一般的に言えば、所有し保守しているということです。左側のものは外部ソースとインタラクションする標準的な方法を持っているため、例えばCRMシステムを置き換えたい場合、左側のすべてを再調整することなく簡単に実行できます。
これが実質的にMCPがどのように動作するかということです。改めて、MCPサーバーのコアコンポーネントをご紹介します。まずMCPクライアントがあります。これについては既に説明しましたが、MCPを実行しているもので、実際には、通常はエージェントとして機能します。KiroがまさにこのMCPクライアントとして動作することになります。そしてMCPサーバーがあります。MCPサーバーには3つのコンポーネントがあります。ツール、これはMCPサーバーについて考えるときにほとんどの人が思い浮かべる最も一般的なものです。それからリソース、そしてプロンプトがあります。それでは、これらそれぞれについて、ざっくりとした概要レベルで説明していきます。
MCPツールは、私たちがモデル制御と呼んでいるものです。LLMがMCPサーバーを通じてツールの使用を制御しています。ツールは基本的にモデルがどのように機能するかの関数です。先ほどの例に戻って考えてみると、クリスマスプレゼントを購入する、あるいはエージェントに購入を手伝ってもらう、クリスマスプレゼントを購入する過程での例ですが、1つのツールはクリスマスギフトの価格検索かもしれません。さまざまな種類のクリスマスギフトやおもちゃなどの価格検索ですね。ウェブ検索かもしれませんし、非常に具体的な何か、非常にアクション可能な何かかもしれません。それが通常ツールです。皆さんの具体的なユースケースにおける他の例としては、データの取得、メッセージの検索、あるいはレコードの更新などがあるかもしれません。他にもさまざまなタイプのものがあります。繰り返しになりますが、ほとんどの人はMCPツールについてはよく理解されています。
MCPが使用する他のタイプのもの、他のカテゴリーがあります。MCPリソースはアプリケーション制御です。実際に実行しようとしているアプリケーション、サービスかもしれませんし、ウェブサービスかもしれませんし、データベースかもしれませんが、それはアプリケーションによって制御されます。そしてそれは実質的に、以前はナレッジベースだったもの、つまりファイルやデータベースレコードです。私の履歴や、過去に購入したときに重要だったコンテキスト、例えば購入履歴などがリソースの例になるかもしれません。
プロンプト、さてプロンプトは非常に興味深いものです。なぜなら、私たちは通常プロンプトをエージェントに入力するものとして考えますよね。それがプロンプトについての私たちの考え方です。MCPにおいては実質的に同じことなのですが、MCPプロンプトはユーザーがMCPリクエストとレスポンスを定義できる特定の機能です。このように考えてみてください。もし私がMCPを所有しているなら、こう言うかもしれません。ここに特定のプロンプトがあり、これが非常に良いリソースを提供することを私は知っています、と。ユーザーは私のMCP内でそれらのプロンプトを発見する能力を持ち、そのプロンプトを使用できます。つまり、よし素晴らしい、これがMCPが使用を提案しているプロンプトだ、でももちろん私はそのプロンプトを修正できます。好きなように変更できます。拡張することもできますし、追加することもできます。これらがMCPサーバーが持つ3つの異なるタイプのリソースです。
AWSコンテナサービスにおけるMCPの必要性
では、詳しく話していきましょう。全体的な話をしました。Model Context Protocolがなぜ必要なのか、そしてどのようにしてこの時点に至ったのかという歴史について、非常に駆け足で説明しました。コンテナサービスについて話しましょう。一般的に言って、もしあなたがこれを見ているなら、私たちのコンテナサービスについての一般的な知識を前提としています。Elastic Container Service、これは私たちのAWSネイティブなコンテナ化された非常にシンプルなコンテナオーケストレーター、そしてKubernetesサービス、これは私たちのKubernetes最適化されたコンテナオーケストレーターです。私たちはこれをクラウドでKubernetesを実行する最良の方法だと考えています。
なぜ私たちはAWSサービス向けのMCPサーバーをローンチしたのか、ですよね？これらのもの、特にECSのように非常に使いやすいと言っているものについて、なぜMCPサーバーが必要なのでしょうか？私たちは、Amazonが一般的にそうであるように、AIが人々の働き方、構築、出荷、そしてコードの監視の方法を変革していると信じています。
AIエージェントは開発者の生産性を変革しており、私たちのシステムには事実上新しいペルソナのユーザーが登場すると信じています。エージェントは一般的に私たちのコンソールを見るのがあまり得意ではありません。なぜなら、それらはエージェントが見るために構築されていないからです。彼らはCLIを使うのは得意ですが、だからといって私たちのAPIが提供するすべてのものを最適に活用できるわけではありません。彼らには、私たちのサービスから最大限のものを引き出すために設計されたインターフェースが必要なのです。
AIツールにはリアルタイムの認識が欠けています。例えば、最近の発表でECSがECS Expressモードをローンチしたとしましょう。私たちはそれを2週間前にローンチしました。それがLLMのコアデータベースセットに含まれている可能性は非常に低いです。今、私たちはドキュメントを用意しています。ドキュメントがあります。これらのエージェントはツールルックアップへのアクセス権を持っているので、検索することができ、ウェブ検索を使うことができ、ユーザーがexpressモードと呼ばれるものがあると言っているから、それを調べてみよう、expressモードが何かを見てみよう、expressモードが持つすべてのリソースをリストアップできる、そして発見して回答へと導くことができます。
しかし、それには2つの問題があります。1つ目は、一般的に言って、LLMは非常に堅牢な情報セットでうまく機能するため、特に古い機能を使って、自分が知っていることに固執する傾向があるということです。皆さんがECSとEKSを一緒に使う方法について研究し、書き、共有するのに時間を費やしてきたかもしれません。そのため、トレーニングセットには豊富なデータがあり、それを信頼し、新しい機能が見えていたとしても、それを使う方が優れた装備を持っているということになります。最適な使い方を知らないかもしれないんです。これは最も洗練されたエージェントでさえ抱える大きな問題です。
もう1つの制限もあります。それは、AWSが意図する使い方を正確に知る能力です。皆さんは試行錯誤を通じて、そしておそらくいくつかの非常に洗練されたガイダンスを通じて、私たちのツールを使う経験へと導かれますが、エージェントは実際にはその経験を持っていません。皆さんと同じように試行錯誤から学ぶ能力を実際には持っていないのです。ですから、私たちはそれを教える方法が必要で、これがその使い方ですよ、と言う必要があるのです。
つまりMCPには物事を修正する機会があるわけです。なぜなら、エージェントに最新の、まさに今この瞬間の情報を提供できるようになるからです。これらのAPIを使う代わりに、今リリースしたばかりのこのAPIセットを使ってください、と。このデプロイメントメカニズムを使う代わりに、こちらを使ってください、と。また、ユーザーに対してガイダンスを提供することもできます。トラブルシューティングの改善や運用の改善といったことができるんです。なぜなら、私たちには膨大な知識があって、それを皆さんに伝えるのは非常に難しいからです。コンテナオーケストレーターで起こりうるあらゆる問題への対処方法について、1000ページものマニュアルを読みたい人なんていませんよね。発生するかもしれないあらゆる問題について、そんなものを読む時間は誰にもありません。LLMは、適切な統合メカニズムを提供すれば、実際にこれをかなりうまくこなしてくれます。これがMCPサーバーが持つ機会なんです。
ローカルMCPサーバーのリリースとホステッド版への移行
そこで私たちはこれらの構築を始めました。そして、これらがどのように機能するかを詳しく説明していきます。まず最初にローカルで提供を始めました。MCPを使用する、あるいは改善する方法には2つの異なる種類があります。ローカルで実行することもできます。そして、今年の初めにAWS containers and serverless向けのMCPサーバーをリリースしました。つまり、ECS、EKS、Finch、そしてLambdaです。各MCPサーバーには独自のツールセットがあり、これらが何をするのかについては後ほど詳しく説明します。これらは本日GitHubリポジトリ、AWS Labs GitHubリポジトリからダウンロードできます。これらはローカルマシン上で実行するもので、始めたりテストしたりするのに最適な方法です。
しかし、スケールで実行し始めると、マシンをローカルで実行することにはいくつかの制限があります。そこで、それらに答えるため、そしてECSとEKSのホステッドMCPサーバーが実際にどのように機能するかについてより詳しく話すために、Georgeに引き継ぎます。彼がこれらについて詳しく説明します。では、George、お願いします。
ホステッドMCPサーバーの特徴とリクエストフロー
はい、ありがとうございます、Steve。ホステッドMCPサーバーをリリースした主な理由は3つ、いや4つあります。詳細については後ほど説明しますが、私たちが受けてきた主な機能の一つ、リクエストの一つは、特にエンタープライズ企業では、開発者にローカルでMCPサーバーをインストールして実行させることに抵抗があるということです。セキュリティチームは、ユーザーが何をしているのか完全に可視化したいと考えていました。ゼロデイ脆弱性が発生した場合、パッチを適用する能力を完全にコントロールしたいと考えていました。もう一つは、より広範な統合を望んでいたということです。
例えば、多くのサードパーティのSaaSプロバイダーがAIエージェントを構築していて、Amazon EKSやAmazon ECSクラスターと対話する能力が必要なんです。つまり、クラウド上で実行されホストされているMCPサーバーが必要だということです。最後の理由は、AWSが提供する優れた信頼性とスケーラビリティです。
2週間前、私たちはAmazon EKSとAmazon ECSの両方に対応した、フルマネージドでリモートホストされたMCPサービスをローンチしました。これらはプレビューで利用可能です。このプレゼンテーションの残りの部分では、これらそれぞれについて、提供される機能や使い始め方を含めて、もう少し深く掘り下げていきます。これによって、かなりクールな機能も実現されました。それは、EKSとECSのコンソールで問題をトラブルシューティングできるようになったということです。これについても掘り下げていきますし、最後にデモをご覧いただきます。
まずはAmazon EKS MCPサーバーから始めます。詳細に入る前に、AIアシスタントやAIツールをMCPサーバーで設定すると何ができるようになるのか、ハイレベルなアイデアをお伝えしたいと思います。基本的には、自然言語を使ってリソースとやり取りしたり管理したりできるようになります。例えば、AIアシスタントに入力するだけでいいんです。例えばKiroを使っているとしましょう。これはAWSのAIコーディングIDEですが、そこに「本番環境のEKSクラスターのステータスを見せて」と入力するだけです。
EKSリソースだけに限定されません。PodsやNamespacesのようなKubernetesリソースも管理したりやり取りしたりできます。ですから「実行中の状態にないすべてのPodsを見せて」といったことができます。自然言語で入力するだけです。kubectlは必要ありません。これは公式のKubernetes CLIですが、それも必要ないですし、kubeconfigのセットアップも必要ありません。入力するだけでレスポンスが得られます。また、MCPサーバーには、トラブルシューティングに役立つツールも用意しています。例えば、失敗状態でスタックしているPodがあるとしましょう。それを入力するだけです。「なぜnginx-ingress-controller Podが失敗しているのか」と。最後に強調したいのは、これらのツールは読み取り専用のツールだけではないということです。これらはリソースを作成することもできます。
リクエストフローを見てみましょう。これはAmazon EKSとAmazon ECSの両方に適用されます。これらはクラウドでホストされており、すべての商用リージョンで利用可能です。中国とGovCloudのリージョンを除くすべてのリージョンでプレビューとして利用できます。リソースがどこにあるかに応じて、お好みのリージョンを選択できます。MCPクライアントを設定したとしましょう。ここでのMCPクライアントはAIシステムです。Kiro、Cursor、Cline、あるいは任意のMCP互換ツールが使えます。それをセットアップしたら、プレゼンテーションの後半で設定方法をお見せしますが、リクエストがホストされたMCPサーバーに到達する方法は、つまりホストされたEKSまたはECS、これらはすべての商用リージョンで利用可能な別々のエンドポイントを持つ2つの別々のMCPサーバーですが、その間にあるプロキシを経由します。
さて、疑問が出てきます。なぜプロキシが必要なのでしょうか。EKSとECS MCPサーバーはどちらもAWSサービスであり、AWSサービスへの認証方法はIAMを通じて行われます。IAMが認証を行う方法は、SigV4署名と呼ばれるメカニズムを使用します。このSigV4署名のために、現在のMCPプロトコルはSigV4をネイティブにサポートしていないため、リクエストに署名してからホストされたMCPサーバーにリクエストを送る、この中間層が必要になります。リクエストがホストされたMCPサーバーに到達すると、使用しているツールに応じて、適切なダウンストリームのAWSサービスが呼び出されます。
Amazon EKS MCPサーバーの機能とツールセット
では、具体的な例をお見せしたいと思います。少し読みづらいかもしれませんが、デモでは拡大表示しますので、より見やすくなります。ここにあるのはKiroで、これはAWS AI搭載のコーディングアシスタントです。MCPサーバーを設定すると、左側に見えるように、これは一度だけ行う手順なのですが、すべてのツールがリストアップされます。EKSの場合、これがここのスクリーンショットですが、利用可能なツールがすべて表示されています。ユーザーとして、Steveが先ほど述べたように、ツールと直接やり取りするわけではありません。これらのツールはLLM用のものですが、 それらについて知っておくことは常に良いことです。設定を完了し、一度だけの手順を終えたら、チャットウィンドウに自然言語で入力するだけです。この場合は、「特定のEKSクラスターのステータスを表示して」と尋ねています。MCPクライアント、つまりLLMは、describe EKS resourceというツールについて知っており、それがレスポンスを返します。MCPサーバーで実現できることの概要をお見せしたかったのです。
では、詳細に入っていきましょう。 MCPサーバーの機能は、サポートしているツールという観点で定義できます。EKSの場合、ツールを4つの主要なカテゴリーに分類できます。1つ目はクラスター管理です。これらは、クラスターの作成、アドオンの作成、削除など、EKSリソースの管理を支援するツールです。これらの中には読み取り専用のツールもあります。つまり、例えば、ここの2つ目はリスト操作を行うだけで、すべてのEKSリソースをリストアップするだけです。1つ目のmanage EKS stackのようなツールもあり、これは実際にクラスターを作成します。ユーザーとして、実際にやり取りする必要はありませんが、知っておくことは常に良いことです。詳しく知りたい場合は、ユーザーガイドで、それが受け取るパラメータやどれが必須かなどをカバーしています。
次のツールセットは、Kubernetesリソース管理用です。 先ほどはEKSリソースについて話していました。今度は、podやserviceのようなKubernetesリソースがあります。それらを作成したり削除したりできます。YAMLを適用するツールもあります。マニフェストを生成するツールもあります。
3つ目のツールセットは、ドキュメントとトラブルシューティングです。ここでもう少し時間をかけたいと思います。Steveが先ほど知識ギャップについて言及しました。少し話を戻しましょう。最初にMCPサーバーのオープンソース版をローンチしたとき、search EKS documentationはありませんでした。開発中に分かったのは、Steveが言っていた知識ギャップです。どのLLMバージョンでも、特定のバージョンに行ってドキュメントを見ると、知識カットオフ日があると書かれています。基本的に、それはそのLLMがトレーニングされた日付です。つまり、知識カットオフ日以降に出た機能については、実際にはトレーニングされていないのです。ツールを使って情報を取得することはできるかもしれませんが、実際にはそれについてトレーニングされていません。新しいEKS機能のトラブルシューティングを試みていたときに、ギャップを見つけました。LLMが本当に良い仕事をしていないことが分かりました。そのため、このツールを構築したのです。
このツールが行うことは、バックエンドでAWSドキュメント全体のインデックスに接続されているということです。つまり、すべてのAWSドキュメント、すべてのAWS What's New投稿、すべてのAWSブログ投稿がそこにインデックス化されており、このツールはそのインデックスにアクセスして情報を取得することができます。これによって、このツールを通じて不足している情報をLLMに補強しているわけです。これが最初のツールです。2つ目はEKS troubleshooting guideです。これは実際に私たちがクラウドでホスティングしているナレッジベースです。このナレッジベースとは何かというと、基本的には何百万ものKubernetesクラスターを管理してきた中で得られたすべての知識を凝縮したものです。長年にわたって多くのKubernetesクラスターを管理してきました。社内には多くのランブックがあり、これらはすべて外部と共有でき、有用なランブックです。これらすべてのランブックがこのナレッジベースに追加されており、この特定のツールは実際にナレッジベースにアクセスして、トラブルシューティングに使用できるさまざまなランブックでLLMを補強しているのです。
このツールセットはトラブルシューティングに関連しています。通常、トラブルシューティングのランブックを見ると、最初の2つのステップの1つは、より多くのテレメトリーを取得することですよね。より多くのメトリクス、より多くのイベント、より多くのログを取得することです。これらのツールは、LLMが効果的に問題をトラブルシューティングできるように、必要なテレメトリーをLLMに提供しています。そして、セキュリティ用のツールもいくつかあります。 これは、多くの場合、問題がIAMパーミッションに関連している、またはそれが不足していることに気づいたため導入されました。このツールはそれを支援します。
EKS MCPサーバーの前提条件：IAMパーミッションとプロキシ設定
さて、これで機能について見てきました。それでは前提条件をいくつか見ていきましょう。 先ほど申し上げたように、EKSとECSですが、ECSについては後ほど少し詳しく説明します。EKS MCP serverはSigV4によって保護されています。IAMによって保護されています。設定する必要がある特定のパーミッションがあります。2つの主要なパーミッションは、EKS invoke MCPです。これは、ホストされているMCPサーバーエンドポイントに接続するために使用しているIAMエンティティ、つまりIAMユーザーまたはIAMロールに対して、invoke MCPパーミッションを持つことを許可するものです。これにより、MCPクライアントがlist呼び出しを行って、利用可能なすべてのツールについて理解できるようになります。次に、call read-only toolsという別のパーミッションがあり、これは読み取り専用ツールへのアクセスを許可しています。先ほど思い出していただきたいのですが、一部のツールはリソースの取得やリスト表示のような読み取り専用のアクションのみを実行しますが、クラスターの作成やPodの作成のように実際に変更を加えるツールもたくさんあります。このパーミッションは、読み取り専用ツールのみがパーミッションを持つことを保証しています。
そして最後の1つはprivileged toolsと呼ばれるものです。すべてのツールがMCPサーバーに接続できるようにしたい場合は、call privileged toolsも必要になります。ここで本当に強調したいことが1つあります。特に本番環境では、読み取り専用ツールだけから始めてください。LLMには独自のインテリジェンスがありますよね。ほとんどの場合、良い仕事をしてくれます。しかし時々ハルシネーションを起こすことがあります。私は、意図せずに削除したくなかったリソースを削除してしまうシナリオを経験したことがあります。ですから、少なくとも本番環境では、invoke MCPとcall read-onlyだけから始めることを強くお勧めします。開発環境やテスト環境ではcall privileged toolsを使用できますが、まずは最初の2つから始めることをお勧めします。
これらがMCPサーバーに接続するために必要な3つのパーミッションですが、MCPサーバーに接続すると、たくさんのツールがあります。 思い出していただきたいのですが、CloudWatchにアクセスしてログを取得するツールがありました。そのため、IAMアイデンティティに設定する必要がある追加のパーミッションがあります。AmazonEKSMCPReadOnlyAccessというマネージドポリシーがあります。IAMコンソールに移動して、ポリシーを検索し、その単語を入力するだけで、この事前に用意されたポリシーが利用可能であることがわかります。 これには、すべての読み取り専用ツールが必要とするパーミッションの完全なリストが含まれています。
適切なツールについては、現時点では事前に用意されたポリシーはありませんが、権限について詳しく知りたい場合は、EKSユーザーガイドに記載されています。それでは、MCPサーバーエンドポイントに接続するために使用するIAMプリンシパルに設定する必要があるすべての権限について見てきました。次に、プロキシについてお話しします。
少し前に説明しましたが、プロキシはMCPクライアントとMCPサーバーの間の仲介役で、あなたの代わりに、またはリクエストの代わりにSigV4署名を行います。プロキシは、見てみたい方はそのGitHubリポジトリで利用可能です。プロキシはPython package indexでも利用可能なので、インストールは非常に簡単です。uvxを使ってインストールできます。
良い点は、このプロキシはAWSファーストパーティでホストされているMCPサーバーに接続するために必要で、EKSやECSだけではないということです。リモートでホストされている他の多くのMCPサーバーが登場していますので、このプロキシを実行する必要がありますが、一度実行するだけで済みます。そして、興味のある異なるAWSホスト型MCPサーバーに接続するための異なるブロックを持つことができます。 他にどのような設定があるでしょうか。最初はprofileです。MCPプロキシはSigV4署名を行っており、署名を行うには認証情報が必要で、ここで指定したprofileから認証情報を取得します。これはAWSプロファイルを参照しています。
どのプロファイルを指定するかによって、リモートでホストされているMCPサーバーに接続するためのリクエストに署名するために、その認証情報を使用します。他にも知っておくべき興味深い点がいくつかあります。それはリージョナルエンドポイントです。先ほど述べたように、リモートでホストされているMCPサーバーはすべての商用リージョンで利用可能です。この場合、私たちはOregonリージョンに接続しているので、us-west-2を使用します。そして、ここのserversはeks-mcpです。
これは重要な注意点です。先ほど言ったように、LLMに望まない行動、特に変更を伴うような行動を取らせないようにする方法は2つあります。1つはIAMです。先ほど言ったように、IAM権限を作成する際には、call privilegeツールを持たないようにしてください。2つ目は、ここでread-only引数を指定すると、MCPクライアントはすべてのツールではなく、読み取り専用ツールのみにアクセスできるようになります。
Amazon ECS MCPサーバーとコンソール統合によるトラブルシューティング体験
さて、ここまではEKSについてお話ししてきました。では次にECSに移りましょう。私が話してきたことの多くはECSにも当てはまりますが、より詳しく見ていきましょう。ECS MCPサーバーを使うと、自然言語を使ってECSリソースを管理できるようになります。これらは単なる例です。つまり、これよりもずっと幅広いことができるのですが、イメージを掴んでいただくために挙げると、デプロイメントの監視ができます。コンテナやタスクの健全性を調査することができます。問題のトラブルシューティングができますし、ネットワーク構成のようなものも確認できます。
ECSではツールを3つの大きなカテゴリに分類しています。1つ目はオペレーショナルツールです。デプロイメントのステータスを取得したり、ネットワーク構成を取得したりといったことを支援する多くのツールがあります。これらは問題のトラブルシューティングを行う際に非常に重要です。リソース管理のためのツールもあります。タスク定義の詳細情報を取得するといったタスクのためのツールがあります。
トラブルシューティング用のツールもあります。ECSは、顧客が抱える最大の課題が何であるかを本当にうまく特定していると思いますし、私がこれまで見てきた中で最も一般的な問題のいくつかをトラブルシューティングするのに役立つツールを提供してくれています。パーミッションに関しては、EKS MCPサーバーとECSの間に重要な違いがあります。ECS MCPサーバーのツールはすべて読み取り専用ツールなので、3番目の特権ツールのようなパーミッションは見られません。
しかし、ECS MCPサーバーエンドポイントへの接続に使用するIAMプリンシパルに設定する必要がある2つの主要なパーミッションがこれらです。思い出していただくと、ネットワーク構成の取得のようなツールの一部は、実際にEC2 APIを呼び出しています。多くのツールがECS APIを呼び出しているので、IAMエンティティに設定する必要がある追加のパーミッションがあります。それらが何であるかを確認したい場合は、ユーザーガイドで詳しく学ぶことができます。
EKSと同様に、MCPプロキシを実行する必要があります。複数回実行する必要はありません。追加のブロックを持つだけで済みます。例えば、EKSとECS両方のMCPサーバーに接続する必要があるシナリオがある場合、代わりにECSを指す追加のブロックを持つだけで済みます。EKSとECSの主な違いは、ここのエンドポイントを見ていただくと、ECSで始まっているということです。
このECSはEKSと同様にリージョナルエンドポイントとして機能します。接続する際は、適切なECSリージョナルエンドポイントを指定します。ここでのサービスはecs-mcpとなり、プロファイルはSigV4署名を行うための認証情報を取得する場所です。さて、少し話題を変えまして、MCPサーバーで実現できた素晴らしいことの一つが、EKSとECSの両方のコンソールにおけるトラブルシューティング体験の大幅な改善です。デモでより詳しくお見せしますが、まず簡単に説明させてください。
EKSやECS AWS Management Consoleで問題やエラーを表示する多くの場所で、コンテキストに応じて「Inspect with Amazon Q」ボタンが表示されるようになりました。私たちが行ったのは、Amazon QとMCPサーバーツールを統合して、根本原因の問題を迅速にトリアージし、それらを解決する方法についての推奨事項を提供できるようにすることです。
イメージをお伝えすると、どれくらい見えるかわかりませんが、ハイレベルで言うと、これらはEKSコンソールのさまざまなポイントで、このInspect with Amazon Q統合が利用できる場所の一部です。例えば、Observabilityダッシュボードに移動すると、クラスターに関するさまざまな種類のヘルスの問題が表示されます。そこにInspect with Amazon Qボタンが表示されるようになりました。それをクリックすると、Amazon Qチャットパネルが開き、問題をトリアージして解決することができます。同様に、Upgrade InsightsやControl Plane Monitoring、Node Health Issuesなど、この統合が利用可能な他のポイントもあります。
ECSコンソールでも同様に、この統合を活用できる複数のポイントがあります。例えば、ここではデプロイメントを表示しています。このデプロイメントはロールバックされています。Rollback Successfulというステータスをクリックすると、Inspect with Amazon Qボタンが表示され、それを使用して理由や軽減方法について詳しく知ることができます。同様に、タスクの失敗についても、ステータスをクリックすると、その統合が利用可能です。
デモンストレーション：ホステッドMCPサーバーとAmazon Qによるトラブルシューティング
先ほど、ホストされたMCPサーバーに接続するためのリクエストフローがどのように機能するかについて説明し、見てきました。このQ統合により、コンソールからさまざまな問題をトラブルシューティングできる別のフローも利用できるようになりました。これはAIを活用したトラブルシューティング体験で、バックエンドではEKSとECS MCPサーバーが提供するさまざまなツールを使用しています。さて、それではデモに移りましょう。これは数日前に録画したものです。LLMとハルシネーションの問題があるので、ここでまともなものをお見せできるようにしたかったんです。録画ですが、本物です。
デモでは2つの主要なセクションから始めます。最初はホステッドMCPサーバーで、これにはEKSを使用しますが、ECSも機能や実現できることという点では非常に似ています。デモの2つ目のパートでは、コンソールでのトラブルシューティング体験をお見せしますが、そちらではAmazon ECSを使用します。まず前提条件から始めましょう。覚えていらっしゃると思いますが、実施する必要があることが2つあります。1つ目は、リモートでホストされているMCPエンドポイントに接続できるように、IAMエンティティに適切な権限を設定する必要があります。2つ目は、MCPクライアントの設定です。ここではKiroを使用していますが、これはAWS AI搭載のIDEです。MCPクライアントであるKiroがMCPサーバーに接続できるように、一度設定する必要があります。これらが2つの前提条件です。まずそれを見ていきましょう。
さて、IAMコンソールに入っています。ポリシーに移動しましょう。先ほど、Amazon EKS MCP Read-Only Accessという事前に用意されたマネージドポリシーがあると述べました。JSONをクリックすると、すべてのツールに必要な権限の完全なセットを確認できます。これらはすべて必要な読み取り専用権限です。 下部には、EKS MCPサーバー、つまりホステッドエンドポイントに接続するために必要だと述べた2つの主要な権限、InvokeMCPとCallReadOnlyToolが表示されています。その上には、他のすべての権限が表示されています。これらのツールは多数の呼び出しを行っています。例えば、一部のツールはEC2への呼び出しを行っています。一部はCloudWatchを呼び出しています。一部はSTSを呼び出しています。 ツールが必要とする権限の完全なセットを確認できます。すべてここにリストアップされています。
さて、今日のデモでは、 読み取りと書き込みの両方のツールを使用しますので、新しいポリシーを作成しましょう。ここではコンソールを使用していますので、ポリシーを作成できます。 JSONをクリックすると、ポリシーを入力できるようになります。現時点では何も入っていません。EKSユーザー ガイドのTools MCP Protocolに切り替えます。このページのStep 3に、読み取りと書き込みの両方に必要な権限の完全なセットがリストアップされています。参考までに、これらはツールが必要とするすべての権限です。それをポリシーエディターにコピーして、IAMポリシーの作成に使用できます。 先ほど述べたように、下部にEKS MCPに必要な3つの主要な権限が表示されています。
それでは、Nextをクリックしましょう。EKS MCP Server Write Policyという名前を付けます。すべての権限が正しいことを確認して、Create Policyをクリックできます。これでポリシーが作成されました。 次に、このポリシーをIAMプリンシパルにアタッチする必要があります。
このデモをシンプルにするために、IAMユーザーを作成します。新しいIAMユーザーを作成します。 目標は、先ほど作成したポリシーをこのユーザーにアタッチすることですので、EKS MCP Server Userという名前を付けます。 次に、前のステップで作成したポリシーを見つける必要があります。MCPで検索すると、下部に表示されます。それを選択します。 Nextをクリックします。すべて問題なければ、作成できます。これでユーザーが作成されました。
それでは、この特定のユーザーのためにアクセスキーとシークレットキーを作成する必要があります。特定のユーザーに移動して、Security Credentialsタブに行くと、この特定のユーザーのためにアクセスキーとシークレットキーを作成することができます。これを行っているのは、これらの認証情報を作成したら、それをローカルマシン、つまりMCPクライアントをセットアップしたマシンにコピーするためです。私の場合はMacBookを使っているので、アクセスキーをローカルマシンにコピーして、それをAWSプロファイルとして設定します。ここではKiro IDEを使っています。これで前提条件の最初のステップであるIAMパーミッションの作成が完了しました。
次のステップ、次に一度だけ行う必要があるステップは、AIコーディングアシスタントをMCPサーバーに接続するように設定することです。ここで、私が使用しているAIコーディングアシスタント、つまりMCPクライアントはKiroです。Kiroを見ると、現在MCPサーバーが何も設定されていないことがわかります。Open MCP Server Configをクリックできます。ご覧のように、MCPサーバーはありません。EKSユーザーガイドに行くと、MacとWindows用の手順があります。私はMacBookを使っているので、ここでMacのセクションをコピーします。これらはすべてECSにも適用されます。時間の都合上、今日はEKSについてのみお見せします。
それをコピーします。プロキシが見えますね。Oregonリージョンに接続するので、リージョンをus-west-2に更新します。これがOregonリージョンのエンドポイントだからです。私のプロファイルですが、覚えていらっしゃるかわかりませんが、デモでは見せませんでしたが、demo-profileというプロファイルがあり、これには先ほど作成したアクセスキーとシークレットキーが含まれています。そこで、そのプロファイルを使用するように更新し、リージョンをus-west-2に更新します。保存を押すと、左側にMCPが表示されるのがわかります。KiroがリモートでホストされているMCPサーバーに接続しようとしています。数秒かかります。SigV4を使って署名し、接続して、適切なパーミッションがあることを確認しています。
それが完了すると、20個のツールが見つかったことがわかります。20個のEKS MCPサーバーツールがあります。それらはすべてここにリストされています。ユーザーとして、これらを直接呼び出すことはありませんが、知っておくと良いでしょう。マウスを重ねると詳細な説明が表示されますが、これらの詳細についてもっと知りたい場合は、EKSユーザーガイドでも確認できます。さて、これで両方のステップが完了しましたね。ステップ1でIAMパーミッションを作成しました。そして今、MCPクライアントであるKiroをMCPサーバーに接続するように設定しました。
それでは使い始めましょう。簡単なことから試してみます。クラスターのステータスを表示することから始めましょう。Kiroのチャットウィンドウを開いて、プロンプトを入力します：Show me all EKS clusters and their status。私の環境には4つのEKSクラスターがあります。Kiroは自動的にMCPサーバーがあることを検出します。ツールの説明に基づいて、list_eks_resourcesというツールがあることを判断し、これがクラスターの詳細情報を取得するのに適したツールのようです。実際、左側にもリストされています。ご覧のように、list_eks_resourcesというツールがそこにあります。
私はKiroを自動承認しない設定にしています。すべてのツール呼び出しを自動承認するオプションもあるんですが、特に始めたばかりの時は、個別に承認して、理解しているツールや呼び出したいツールが実際に呼ばれているか確認するのが良いですね。それでは、このリクエストを承認します。いくつか他のツールも呼び出していますね。4つのクラスターがあることがわかりました。それぞれに対してdescribe呼び出しを実行していて、最終的に返ってくるのは4つのEKSクラスターについてのステータスです。それぞれのステータス、バージョン、作成日時、リージョン、そういった情報をすべて提供してくれます。
とても簡単でしたね。kubectlをセットアップする必要もありませんでした。AWS CLIもセットアップしていません。必要だったのはAWSプロファイル、IAMパーミッション、そして先ほどお見せしたMCPサーバーの設定だけです。それと自然言語だけで、EKSクラスターとやり取りして管理できるようになるんです。これは非常にシンプルなケースですね。では別の例を試してみましょう。
次にお見せしたいのは、これらのクラスターの1つ、ここでは2番目のEKS ECRクラスターに入っていきます。これはKubernetesバージョン1.31で動いています。Kubernetesを使ったことがある方ならご存知だと思いますが、バージョンアップグレードは簡単なことではありません。Kubernetesはバージョンのロールバックをサポートしていないので、ちょっと怖いところがありますよね。
バージョンをアップグレードすることを決める前に、すべてが問題なく見えること、そして何も壊れないことを確認したいですよね。そこで今回デモンストレーションするのは、バージョン131です。これは最新版ではありません。実際の最新バージョンは134です。私は131から132への移行を試みているんですが、その前に、準備ができていてアップグレードボタンを押しても大丈夫かどうか確認したいんです。
私のプロンプトは、下部を読んでいただくとわかりますが、「EKS ECRテストクラスターのアップグレード準備状況を評価してください。サポートステータス、アップグレードのタイムライン、そしてブロッキング問題があれば特定してください」と入力しただけです。それだけ入力してエンターを押しました。するとKiroは、MCPサーバーがサポートする20のツールの中に、このシナリオに役立つツールがあることを見つけ出します。insightsのようなツールがあって、アップグレード準備状況に関する情報を提供してくれます。Kiroは実際に考えながら、たくさんの呼び出しを行っているんです。
何かを見つけて、list EKSを実行しているので、見つけたリソースについてさらに詳しく学習しようとしています。ここで数秒待って、情報収集を完了させましょう。最後に、ここでレポートを生成します。上にスクロールして、完了するまで待ちます。このようなレポートが表示されています。ブロッキングイシューが1つ特定されました。クラスター上で実行しているアドオンの1つ、AWS GuardDutyエージェントが、アップグレードしようとしているバージョンと互換性のないバージョンになっていると言っています。これをフラグ付けして、修正する必要があると教えてくれています。もしこれを修正せずにアップグレードすると、クラスターが壊れた状態になってしまいます。
その後、すべて問題なさそうなチェックがたくさんあります。kube-proxyやクラスターヘルスの問題に関するいくつかの追加チェックがあり、それらはすべて成功しています。最後に、アップグレードボタンを押す前に実行する必要があるステップの推奨事項を提示してくれています。では、次の例として、新しいクラスターの作成をやってみましょう。
AWS CLIやeksctlを使ってクラスターを作成したことがある方はどのくらいいらっしゃるでしょうか。EKSクラスターの作成にはいくつかのステップが必要です。作成する必要がある前提条件がたくさんあります。VPCを作成し、サブネットを作成し、それらを作成した後、create clusterコールにそれらを渡す必要があります。今日クラスターを作成するには、やるべきことがたくさんあります。しかしここでは、シンプルなテキスト一行で、新しいEKSクラスターを作成すると言っているだけで、それだけです。すべての依存関係を把握して、バックエンドでCloudFormationを使用してクラスターを作成します。
本番環境のクラスターをこれで作成することはないかもしれませんが、試してみたいアイデアがあって、すぐにクラスターを作成したい場合、これは始めるのに最適な方法です。この特定のツールはバックエンドでCloudFormationを使用していますが、他のツールも使用できます。例えばTerraformを使いたい場合、プロンプトでTerraformを使って新しいEKSクラスターを作成するように指定すれば、LLMは通常、指定した内容を尊重します。しかし、何も指定しない場合、デフォルトではバックエンドでCloudFormationを使用するツールが使われます。
manage EKS stacksというツールがあります。実際にCloudFormationに行って、ここで使用されている特定のテンプレートを確認できます。テンプレートを作成してから、そのテンプレートのデプロイを開始します。クラスターの作成には依然として15分から20分ほどかかるので、しばらく時間がかかりますが、少なくとも開始することができます。ここでは、クラスターとクラスターに関連するすべての設定を作成するプロセスが開始されたことがわかります。
さて、それを待つつもりはありません。次に進みましょう、これが最後のシナリオです。これはトラブルシューティングのシナリオです。MCP demo clusterというクラスターがあり、そこにロードバランサーがあるのですが、壊れた状態になっています。このLoadBalancerサービス、つまりKubernetesのサービスオブジェクトですが、pending状態になっていて、外部IPを取得できません。自然言語で入力しているだけです、私のLoadBalancerはMCP demo cluster上のdefault namespaceにあり、pending状態でスタックしていて、外部IPが取得できません、トラブルシューティングを手伝ってもらえますか、と聞いています。ここで、先ほどお話ししたトラブルシューティングのランブックやトラブルシューティングツールのいくつかが使われています。では、Kiroがここで何をするか見てみましょう。
KiroはEKSトラブルシューティングガイドを呼び出します。Kiroはトラブルシューティングガイドというツールがあることを知っています。このエラーメッセージをクエリパラメータの一部としてその特定のツールに渡し、この問題に役立つランブックがあるかどうかを確認しようとしています。このサイクルを数回繰り返し、それからサービスオブジェクトに問題があることを発見したので、サービスオブジェクトについてもっと学ぶためにKubernetesリソースを読み取る別の呼び出しを行っています。それから、サービスに関連するイベントを取得しようとします。なぜなら明らかに障害が発生しているので、理解しようとしているわけです。つまり、ここで独自の情報収集を行っており、複数のツールを呼び出しています。ランブックを見て、ランブックで定義されているステップに従い、根本原因を見つけようとしています。もう数秒待ってみましょう。
さて、根本原因を見つけ出しました。そして修正手順も示しています。上にスクロールして戻しますので、読む時間を取ってください。しかし、見つかった主な問題はその特定のロードバランサーに関連付けられているサブネットの1つに、適切なKubernetesタグが関連付けられていなかったということです。つまり、それらのタグが欠落していると言っており、また、問題を修正して解決する方法についての手順も示してくれています。
さて、これがホストされたMCPサーバーからの最後のデモでした。EKSを使っただけです。先ほど言ったように、これらすべての機能、同様の機能はECSでも利用可能です。IAMパーミッションの設定やMCP設定を含め、セットアップに関しては同じ手順に従うことになります。では、ギアを切り替えて、AWSコンソールで有効にしたトラブルシューティング体験を見てみましょう。これについては、ECSのシナリオと、そこでどのようにトラブルシューティングを有効にしているかに焦点を当てます。
ここに特定のクラスターがあり、タスク定義がdelete in progress状態でスタックしています。この特定のタスク定義がスタックしています。そして、以前お気づきだったかもしれませんが、Inspect with Amazon Qというボタンがありました。ちょっと戻ってお見せできるか見てみます。このボタンは私たちが導入した新しいものです。ステータスメッセージをクリックすると、このInspect with Amazon Qが表示されます。これが、コンソールでAmazon Q Developerと統合したものです。
クリックすると、右側にQ chatパネルが自動的に開きます。そして、そこには問題に関するコンテキストと、Amazon Q Developerが問題を解決し、把握し、トラブルシューティングするために必要なすべての情報を含むプロンプトが事前に入力されています。ここでご覧いただけるように、Amazon Qは現在呼び出しを行っており、Amazon Qは裏側で使用する独自のツールセットを持っています。これにはEKSやECS MCPサーバーから利用可能なツールも含まれており、根本原因をリストアップしています。ここでの根本原因は、タスク定義が実行中のECSサービスによって使用されているということでした。そして、根本原因を指摘するだけでなく、推奨される解決方法についてのステップも示してくれます。良い点の一つは、自動的に緩和策を実行するのではなく、柔軟性を提供してくれることです。これにより、内容を読んで、それが正しい解決方法だと思えば、緩和策を実行することができます。
はい、それがレポートの残りの部分です。では、次のシナリオに移りましょう。ここでは、タスクが停止状態でスタックしており、失敗の原因はコンテナイメージをプルできないことです。先ほど述べたように、停止ステータスメッセージをクリックすると、Inspect with Amazon Qという新しい機能強化が表示されます。それをクリックすると、右側にAmazon Q chatパネルが自動的に開きます。そして、Amazon Q Developerが問題をトラブルシューティングできるように、コンテキストを含むプロンプトが事前に入力されています。
Amazon Q Developerは現在、ECSツールを含むさまざまなツールを呼び出しています。タスク定義について詳しく学ぼうとしています。タスクのヘルスデータを取得しようとしています。Amazon Q Developerはナレッジベースも持っており、知識を取得しています。ここでご覧いただけるように、途中で実際に呼び出しが失敗したため、自動的にリトライしています。サービスステータスの記述を試みましたが、数回失敗しましたが、3回目の試行で成功しました。そして最終的に根本原因にたどり着くことができました。根本原因は、確かネットワーク構成に関連していました。それに寄与した要因をリストアップし、その後、どのように解決できるかも示してくれます。
素晴らしいですね。それがECSコンソールでのトラブルシューティング体験に関して、お見せしたかった2つ目のシナリオでした。さて、これでデモとプレゼンテーションの終わりとなります。皆さん、お時間をいただき本当にありがとうございました。感謝いたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion