re:Invent 2025: MCP GatewayでKubernetesマイクロサービスをAIエージェントに公開する実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Modernize containers for AI agents using AgentCore Gateway (CNS422)
この動画では、Roland BarciaとCarlos Santanaが、既存のKubernetesマイクロサービスをMCP Gatewayを通じてAIエージェントに公開する実装方法を解説しています。AgentCore RuntimeとIdentityを活用し、Cognitoで保護されたMCP Gatewayを構築。EKS Auto ModeやKarpenterを使用したインフラ管理、OpenAPI仕様からのMCPツール自動生成、Strandsエージェントの実装が示されます。ホーム保険会社のシナリオで、appointments、customer、technicianの3つのマイクロサービスをPython SDKとBoto3で統合し、冷蔵庫故障のクレーム処理から修理予約までを自動化するライブデモを実施。決定論的ロジックを持つレガシーシステムを、エージェント開発者がKubernetesの知識なしで活用できる実践的なアーキテクチャが紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
既存のコンテナ化アプリケーションをAgentに活用する課題
みなさん、こんにちは。私は Roland Barcia で、当社のスペシャリスト組織の世界的なディレクターです。私はすべてのスペシャリスト技術を統括しており、ここに Carlos Santana が参加しています。彼は自己紹介をしてくれますが、Carlos は Platform Engineer で Kubernetes のエキスパートであり、今日は素晴らしい機能をデモンストレーションするのをお手伝いしてくれます。
私たちは Agent を構築したいのです。なぜなら、人々はサポートケースと話すのが好きではないからです。時間がかかってしまいます。誰かに電話する代わりに、私は Agent を構築して、ホーム家電の問題に対処している人たちのような状況についていくつかのプロンプトを与えたいのです。 私たちは Agent を構築しようとしています。そして、私たちは多くのビジネスロジックを持っていることを知っていますが、それは既存のコンテナ化されたアプリケーション内に少し閉じ込められています。どうするのか？Platform Engineer で Kubernetes のエキスパートである Carlos と私は、これをどのように公開できるかをお見せします。実際には少し後でライブデモをお見せしますが、基本的には、それがどのように私を助けることができるかについていくつかの質問をすることができるようにしたいのです。ツールと既存のシステムのいくつかのプレビューが表示されます。これが私たちが構築しようとしているものです。
Claims、Appointment Services、Account Information のようなものがあります。これらはすべて、私が何年も前に構築した決定論的なロジックです。Carlos と私は、Kubernetes を使用した最新のマイクロサービスベースのシステム内で、これらすべてを何年もかけて一緒に構築しました。既存のアプリケーション、既存のレガシーアプリケーションを取得して、MCP または他のメカニズムを通じて公開することに関して、多くの機会と課題があります。異なるオプションがあり、あなたは今、非決定論的なロジックと決定論的なロジックを持っています。何年も何年も前に再利用されるように構築されたアプリケーションがあり、今、私はそれらを Agent の世界で活用したいのです。
どうするのか？明日、Wynn で午後 6 時に Architecture セッションがあり、MCP サーバーを作成して既存のアプリケーションを公開するための異なるオプション間の Architecture の問題についてさらに詳しく説明します。しかし、ここでは非常に具体的な方法に入るだけです。 既存のアセットを公開することは、既存の Agent を活用し、私たちが取り組もうとしている Architecture である Agent Core を使用して物事を自動化する素晴らしい方法です。
Agent Core と EKS capabilities の紹介
私は Agent Developer です。私は Python を書きます。私は Agent を書くのが好きです。Kubernetes のことは知りません。Java で書かれているかもしれない既存のマイクロサービス Architecture のことも知りません。しかし、私たちは Agent Core を使用しています。Agent Core には多くのコンポーネントがあり、今週は多くのセッションがあります。 私は主に Agent Core runtime 内で Agent を実行しています。Agent Core identity のようなものを使用して、使用したいものへのアクセス権があることを確認しています。Agent Core Gateway も使用したいので、Agent システムに持っているすべての素晴らしいツールにアクセスできます。会話を追跡するためにメモリを使用したいのです。これらのコンポーネントを使用しようとしており、Gateway 内に存在する評価やポリシーのようなリストされていない、または新しいアナウンスがあります。今日はそれらを表示しませんが、コードのいくつかに入ります。
もちろん EKS ですね。EKS は本当に素晴らしいです。EKS では Kubernetes は依然として非常に重要です。私たちは最高の Kubernetes プラットフォームの一つを持っていて、最も多くのインスタンスタイプと、たくさんの新しくてエキサイティングな機能があります。去年は auto mode がありました。今年はいくつかのアナウンスメントがあります。
私たちは EKS capabilities を立ち上げたばかりです。これは完全にマネージドされた Argo CD、Crossplane、そして AWS Controllers for Kubernetes（ACK）で、これらのコントローラーは Amazon EKS 上で実行されます。Custom Resource Definitions（CRD）を見ることができます。これにより、プラットフォームエンジニアリングチームはスケーリング、メンテナンス、またはこれらのコントローラーのパッチ適用について心配する必要がなくなります。Argo CD のようなものの中には CNCF の一部であるものもあります。私たちがそのコンピュートを管理し、あなたはそのコンピュートに対して料金を支払う必要がありません。あなたは GitOps でアプリケーションをデプロイすることに集中するだけで、それは ACK または Crossplane でインフラストラクチャをデプロイすることができます。Amazon VPC かもしれませんし、S3 バケットかもしれません。これが最近行った主要なアナウンスメントの一つです。
アーキテクチャ設計：MCP Gateway を通じたマイクロサービスの公開
別の機能は control plane のプロビジョニングです。私たちは事前プロビジョニングされた control plane を持っていて、大規模でオンデマンドの大きなクラスターを多くのノードで実現できます。もう一つは Amazon EKS MCP server hosted に関するもので、Qiro のようなものや Strands の私たちのエージェントを直接接続して、agentic DevOps で DevOps を行うことができます。では、私たちが構築しようとしているアーキテクチャは何でしょうか？すべての AI デモには chat インターフェースがあるので、シンプルな chat UI を持つことになります。そこでプロンプトを入力します。 既存のマイクロサービス API を Amazon EKS で持つことになります。それをゲートウェイを通じて公開し、AgentCore Identity を使用してこれらのサービスへのセキュアなアクセスを確保します。
次に、AgentCore runtime アプリケーションをデプロイします。Strands を SDK として使用してデプロイします。また、A2A でエージェント自体を公開します。これは AgentCore runtime の内部で行うことができるものです。 今日はそれは単に chat UI によって消費されていますが、将来的にはこのオーケストレーションが他のオーケストレーションの隣に存在することを想像することができます。ですから、私たちはそれに対しても準備ができていたいのです。もちろん、Bedrock を使用してモデルで推論を行います。これがアーキテクチャで、コードの一部を示すつもりです。
Carlos、あなたは私が使いたいマイクロサービスをたくさん持っています。あなたは私に Kubernetes を学ぶ必要がないと言いました。なぜなら、あなたは MCP でコードを通じていくつかの素晴らしいツールを与えてくれて、既存のシステムを公開してくれるからです。あなたはコードでそれをどのように行ったかを視聴者に示すつもりです。シナリオは、私たちの経営陣が、マイクロサービスのためにすべてを MCP で利用可能にする必要があると言ったということです。これらのシステムの中には数百のマイクロサービスを持つものもあります。私のチームが MCP サーバーとラッパーを書き、別のラッパーを書くのに時間を費やすなら、それは丸一年かかるでしょう。では、MCP gateway または AgentCore を活用しないのはなぜでしょうか？それが私たちが示すつもりのことで、EKS サーバーから EKS クラスター上で使用されているそれらのマイクロサービスの一部です。
EKS クラスターとマイクロサービスのデプロイメント実装
今日は、私がエージェント開発者の役割を担当します。自分のツールにアクセスして、それらを使いたいんです。エージェントを書いて、プロンプトを書いて、プロンプトエンジニアリングをしたい。Carlos、あなたはプラットフォームエンジニアで、既存のシステムを取得して、それらを私のツールとして利用可能にしていくんです。今日はそれをやるので、インフラストラクチャから始めていきます。 EKS クラスターを見せます。この場合、EKS Auto を使っていて、 マイクロサービスをデプロイするために多くのお客様が使っているプラクティスのいくつかがあります。Ingress を使って、Deployment を使って、Service アノテーションを使って、これらのマイクロサービスを非常に簡単にデプロイして、ロードバランサーを通して公開し、ゲートウェイを使ってそれらのマイクロサービスにアクセスしますが、契約があります。その契約は OpenAPI 仕様から来ています。
もっと深く掘り下げます。しかし AgentCore ランタイムの場合、Strands エージェントだけが私のサービスと通信していることを確認する必要があります。他のエージェントが MCP ゲートウェイと話しているのは望みません。AgentCore には Identity という別のサービス機能があり、プロバイダーとのトークン交換を処理して、MCP サーバーに接続できるようにします。それは実際にはオンザフライで 1 つの URL で作成されます。AgentCore Gateway の素晴らしいことの 1 つは、既存の MCP サーバーと通信でき、セマンティック検索ができるので、数百、数千のツールを検索して、必要なツールを確実に取得できることです。
Lambda 関数のような既存のアセットを公開することもでき、Swagger または OpenAPI 仕様で説明すれば、自動的に MCP サーバーに変換されます。それが唯一の方法ではありません。ユースケースによっては既存の MCP サーバーをコーディングしたい場合もありますが、この場合は、このエージェントコードを完成させる必要があります。エージェント開発者として、私は単に自分のツールを使いたいんです。Bedrock の LLM を使いたい。自分のエージェントランタイムを書きたい。それらにアクセスしたい。そして Identity を使って、これらのツールに安全にアクセスできることを確認したい。これらのものを組み合わせて、書いたコードと アプリケーションのいくつかを見せて、実際にこれをライブで見せます。デモがうまくいくといいんですが、では デモに切り替えましょう。準備はいいですか？ はい、行きましょう。少しコードを見ます。コードを見たい人はいますか？
EKS Auto Mode とマイクロサービスの OpenAPI 仕様の確認
コードを見せましょう。あなたがここにいる理由ですよね？これはコードトークです。 何があるか見せます。コンソールに行って、ホームをチェックします。EKS クラスターが準備できているか確認します。ご覧の通り、EKS クラスターがあり、設定されています。 これらのウィンドウをいくつか閉じましょう。バージョン 1.33 を使っていて、これはアップグレードしたい場合に何が起こるかを示すことができるものです。アップグレードインサイトをやります。これは私たちが発表した新しい機能で、ポップアップが出ているので、これは機能していることが良いことで、そこから確認できます。
それから EKS auto mode がありますよね？EKS auto mode が有効になっているのが見えますし、ここにコンピュートがあります。 これらのノードはノードプールから来ています。Auto mode を使っています。EKS は Karpenter と呼ばれるものを使っています。EKS クラスターで Karpenter を使っている人はいますか？ Karpenter は、保留中のポッドに基づいてノードを自動的にプロビジョニングする自動スケーリングです。そうすればノードを手動で管理する必要がありません。ノードを管理するはるかに簡単な方法です。
他に何があるかというと、これはバニラなやつで add-ons が付いてるんです。external DNS という名前のやつがあります。 これで基本的に、ingress を作成するときとか service を作成するときに、ドメイン名を追加できるようになります。external DNS は CNCF の一部です。最近追加したのが EKS community add-ons で、external DNS とか cert manager、Prometheus metrics みたいなやつですね。これらは EKS add-ons API を通してデプロイされる add-ons です。Helm charts を使ったり、スキャンして Kubernetes のバージョンと add-ons の互換性の問題をチェックしたりする必要がないんです。
今、多くのお客さんが self-managed Helm charts から EKS add-ons API を使ったこれらの community add-ons へ切り替えてるんです。ACK とか CloudFormation、Terraform、または API を扱うものとか CLI を使ってそれができます。これがうちのクラスタです。サポートしてる機能を見せることができます。追加できる機能がここにあります。Argo CD とか ACK、Curl みたいなやつですね。これで全部の概要が見えるんです。これは platform engineer として複数のクラスタのフリートを管理する必要がある私にとって、ここにあるのが本当に役に立つんです。 通常、ビジネスでは複数の EKS クラスタが pre-prod と prod にあって、これがあると本当に助かります。
もう一つ見せたいことがあります。upgrade insights を見てたんですが、バージョン 1.33 だったんですけど、upgrade insights があって、アップグレードの準備ができてるかどうか、または何か警告があるか、アップグレードをブロックするような何かがあるかを教えてくれるんです。 これがうちのクラスタです。コンソールに行ってみて、デプロイしてるマイクロサービスを見てみましょう。そうすればそのマイクロサービスのインフラストラクチャの例を見せることができます。このコードにアクセスできるようになります。基本的に 2 つのセクションに分かれてます。1 つは agents で、もう 1 つは infrastructure という名前です。Roland は agent フォルダで作業してて、私は infrastructure フォルダで作業してるんです。
infrastructure フォルダには manifests があります。例えば、Kubernetes リソースをデプロイする 2 つの主な方法、または 2 つの最も一般的な方法があります。Kustomize と Helm です。この場合、私は Kustomize を使ってます。ここに Roland が architecture で指摘したようなやつがあります。Appointments、Customer、Technician ですね。だから典型的な deployment があって、appointments を取得したり作成したりするための REST API を持つコンテナイメージがあります。service があって、それから ingress があります。これが見せたかったやつです。これが load balancer を expose する方法です。 これを作成すると、実際に load balancer が作成されて、この ingress は service を指してるんです。さっき見せた service ですね。それからホスト名の annotation を追加します。
これが kubectl でどんな感じに見えるか見てみましょう。kubectl って誰が呼んでますか？私はいつも QC って呼んでます。kubectl って呼んでますね。 それで Q だけ使う人は？get pods をやったら、ノードを見てみましょう。ここにノードがいくつあるんですか？時間をチェックしてみましょう。どんな感じですか？時間はたっぷりあります。
これらはノートです。 これらのノートは note group によってプロビジョニングされています。これをもう少し大きくできますか？ では、手を挙げてくれた方々のために説明すると、K は単に kubectl のエイリアスです。長年使ってきたので、私の脳が K に慣れているだけです。ノードプールがあり、これらは Karpenter プールです。Karpenter はここではポッドとして実行されていません。なぜなら auto mode だからです。Karpenter は EKS サービスによって管理されているので、インストールする必要がありません。Helm チャートもありません。auto mode で実行されるだけです。これらのインスタンスは管理されています。つまり、AMI のローテーションを処理します。CVE パッチングを処理します。すべてのノードは最大 21 日間実行でき、デフォルトは 14 日間ですが、ローテーションを処理します。これらは Bottlerocket を実行しており、これは EKS ワークロードを実行するために推奨される当社のコンテナ最適化オペレーティングシステムです。ファイルとプロセスのフットプリントが小さいため、より安全です。
これらはノードプールであり、ノードプールがあり、ペンディング状態のポッドがある場合、ノードクレームを作成します。ノードクレームを行い、これらはインスタンスのようなものです。これは Karpenter が EC2 Fleet API に直接アクセスしてできるだけ早くノードを取得するようなものです。その後、ノードが作成され、ポッドがスケジュールされます。Kubernetes スケジューラーがここに配置します。デプロイメントで何があるか見てみましょう。実は、すべてのポッドを表示してみましょう。ご覧のように、core DNS がありません。get pods を実行すると、core DNS がありません。auto mode を使用していない標準的な Kubernetes クラスターがあります。通常、CNI daemon set のようなものが見えます。core DNS のようなものが見えます。これらは今ノード内にあるものです。これらは心配する必要のないポッドです。
ここでは、私が示した external DNS が見えます。そして metric server があります。HPA があり、私たちが持っているように、これをメトリクスに基づいてスケーリングしたい場合、ポッドの数、HPA、horizontal pod autoscaler を使用します。この HPA を設定して、この CPU またはメモリ、またはカスタムメトリクスに基づいて、このポッド数を持ちたいと言い、ポッド数をスケールアップ、スケールアウト、またはスケールインします。これが metric server がある理由です。Guestbook は私が Argo CD からのデプロイメント機能をテストしていたものです。異なるリージョンのハブクラスターにある Argo CD から、このクラスターにデプロイしています。そこにあります。テストしていました。しかし、私が示したいのは、デプロイメント内にあるこれら 3 つのマイクロサービスです。 では、get deployments dash N development を実行すると、 3 つのデプロイメントがあります。これは通常、当社のビジネスが行うことです。 経営チームが「MCP servers を取得できますか？」と言ってきたとき、「この同じコードをもう一度ラップして Docker ファイルを作成し、MCP servers を作成しますか？そうすると 6 つのスポットがあります」と言っていました。当社の会計などを通じて発見したのは、AgentCore にはこの MCP Gateway の機能があるため、MCP servers をコーディングする必要がないということです。これらの API を取得し、ドキュメント、OpenAPI スキーマ、または Swagger を持つか、昔は Swagger と呼んでいましたが、今は OpenAPI spec V3 を持つことができます。その情報があれば、MCP Gateway にアクセス方法と利用可能なサービスを伝えて、それを MCP ツールに変換できます。
この例でこれを行いたい場合、私が示したように、ここに ingress があります。K get ingress を実行できます。そして ingress の場合、通常はホスト名と外部 DNS 名を出力します。 Route 53 で設定しました。通常、これは ingress を作成するときにホスト名を設定する最も簡単な方法です。このアプリケーションのドメイン名を入れたいというアノテーションを入れます。この場合、appointments dash development dot home insurance demo dot cloud native start dot com があります。これはデモに利用可能なドメイン名です。その後、customer があり、technicians があります。では、マイクロサービスの 1 つを選んで、その背後にあるものを見てみましょう。
では、ここを開いて docs と言います。 これが何か誰か教えてくれませんか？この UI を誰が認識していますか？誰が使ったことがありますか？記録している人のために、多くの人が手を挙げています。これは Swagger UI の一種で、今は OpenAPI UI と呼んでいます。これらは私のマイクロサービスであり、これは appointments になります。ホームインシュアランス会社では、appointments、claims、customers があります。顧客はポリシーに基づいてクレームを作成し、冷蔵庫がここのステージで水を流し続けているなど問題がある場合、誰かが来て修理する必要があります。
ここでテストしてみて、動作するか確認できます。自分の予定を一覧表示して、ここをクリックして実行するだけです。すると、自分のすべての予定が表示されます。これが、Agentic 導入前の現在のシステムで、カスタマーサービスとビジネス全体の誰もが API にアクセスしていた典型的な方法です。別の API、別の UI、標準的なフォームを通じてアクセスしていました。これらは agentic ではありません。これが私たちが確立した標準的な方法であり、デプロイするものを更新する必要があるたびに変更管理を経ています。それが私たちのプロセスであり、ほとんどの企業もデプロイするものの変更管理について同様のプロセスを持っています。
JSON を見たい場合は、ここをクリックして JSON を取得できます。これが REST API を説明する方法です。ご覧の通り、すべてのエンドポイントは get で、私は appointments をやっています。つまり、get an appointment、create an appointment、delete an appointment、list appointments のようなものです。これが、このドキュメントを作成する標準的な方法であり、多くのフレームワークがあります。Spring Boot、Express JS、私たちは FastAPI を使用しています。Swagger または OpenAPI 仕様を生成する方法があります。しかし、Kiro のような agentic IDE または CLI を使用することもできます。ソースコードを検査して、このファイルの OpenAPI 仕様を生成してくれ、または始めてくれと言うことができます。
しかし、それは私たちの要件であり、MCP gateway にはここにはないものがあることを示すつもりです。検索してみましょう、ここにあるかどうか見てみます。仕様で server を検索すると、URL を持つ server というフィールドがあります。MCP は、この JSON ファイルを MCP gateway に与えてこの API にアクセスするつもりですが、アドレスが必要です。つまり、REST API の場所を表現する方法の一つは、開発環境か本番環境かによって異なります。2 つのドメイン名を持っているか、パスベースのルーティングを持っているかもしれません。それはどのように呼び出すかを知っているでしょう。コードでこれを注入する方法を示すつもりです。ここまでは大丈夫です。
Python コードによる MCP Gateway と Target の自動作成
マイクロサービスが稼働している場合、Swagger ファイル、JSON ファイルが必要であり、URL を注入する必要があります。コードでそれを行うつもりです。そして、MCP gateway でこれをどのように公開できるか見てみましょう。Kiro に行きましょう。Kiro IDE を使用しています。実は、このコードのほぼすべてが Kiro で私と一緒に動作していて、このコードを作成していたので、彼はここで何が起こっているかを認識しています。見せてみましょう。このコードを取得すると、多くのテストファイルがあります。Kiro を使用していて、spec-driven development として、Kiro は最初に入力した要件が開発中に満たされていることを確認するために、これらのテストファイルをすべて作成しました。
この場合、MCP gateway Python フォルダソースに行くつもりです。そして、.py をセットアップしました。それから pip プロジェクトがあります。ですから、Python を使用してゲートウェイとこのインフラストラクチャを作成していますが、CDK のような他のインフラストラクチャアズコードツールを使用することもできます。この場合、CloudFormation、Terraform、CLI などについて話していました。何でもいいです。この場合、Boto3、つまり Python SDK を示すつもりです。見せてみましょう。ここに行って開きます。ターミナルがとても大きいので、少し小さくします。Pip プロジェクトは基本的にこのものへのエントリーポイントです。ですから、MCP gateway setup というエントリーポイントがあり、ソースセットアップ、setup Python コード、およびメイン関数を使用するつもりです。
このディレクトリに移動してみます。source ディレクトリで ls コマンドを実行すると、テストしていたすべてのものが見えます。MCP gateway を作成するための様々なピースも含まれています。setup.py ファイルが MCP gateway をセットアップしています。
コードを見ると、ここにメイン関数があります。 時間が限られているので、すべてをカバーする時間がないため、処理を速くするためのヘルパー関数がいくつかあります。 メイン関数を探してみます。 これがメイン関数です。このスクリプトを実行すると、2 つのパラメータを渡すよう求められます。REST API のドメイン名です。
これを実行するときに、ドメイン名を渡すことができます。この場合は cloudnativestart.com でした。また、環境も渡します。development namespace にデプロイするのか、それとも production namespace にデプロイするのかを指定します。多くのお客様は、これらの環境を別々の IaaS クラスタに持っています。pre-production クラスタと production クラスタを持っています。デモの目的では、namespace を使用しています。 これら 2 つのものを渡すと、Boto3 ライブラリを使い始めます。
最初にすることは MCP gateway を作成することです。MCP gateway を作成するには、MCP gateway サービス用の IAM ロールが必要です。 MCP gateway のインスタンスには、IAM ロールのような ID が必要です。ドキュメントにもそう書かれています。適切な IAM ポリシーを持つ IAM ロールを作成する関数があり、その IAM ロールを取得します。
次にすることは Cognito のセットアップを取得することです。これが MCP gateway を保護する方法です。Roland が agent を作成して MCP gateway にアクセスするとき、agent core から MCP gateway への受信トラフィックが発生します。この場合、Cognito を使ってそれを保護しています。 この関数がそれを作成し、すでに作成されているかどうかを確認します。デモの目的では、作成されていない場合は作成します。Cognito pool resource server ID と resource server name のようなものが必要です。これは基本的にスコープを処理します。読み取りアクセスと書き込みアクセスが必要な場合、スコープはここで定義されています。
それを作成して、戻ってくる情報を取得します。ユーザープール ID、クライアント ID、クライアントシークレット、Cognito のディスカバリー URL、Cognito サービスからトークンを取得するトークン URL、そしてトークンをリクエストするときにスコープが一致する必要があるリソースサーバー ID です。 メイン関数に戻りましょう。 ここはメイン関数が続く部分です。 Cognito が作成された後、ゲートウェイを作成します。
API があり、このゲートウェイに渡す必要があるのは 3 つのものです。ゲートウェイを最初に作成してから、ターゲットを追加することを覚えておいてください。必要な保護を使用してゲートウェイを作成してから、ターゲットの追加を開始します。ターゲットは異なるマイクロサービス、一度に 1 つの Swagger ファイルである可能性があります。この場合、3 つの Swagger ファイルまたは 3 つのマイクロサービスエンドポイントがあります。3 つのターゲットをそこに追加しようとしています。
情報には Cognito の詳細と、ゲートウェイインスタンスが実行するために使用する IAM ロールが含まれます。 次のものはアイデンティティプロバイダー名です。これは Agent Core のアイデンティティプロバイダーサービスを渡します。スライドで見たように、Agent Core のアイデンティティコンポーネントがあります。エージェントがそのトークンを取得できるようにするためのヘルパーのようなものと考えてください。トークンがコード内またはエンバイロンメント変数にクライアントシークレットを持ち、マシン間でそのトークン交換を行う代わりに、Identity がそれを行うことができます。 デコレーターがそのトークンを注入する方法を示す素晴らしい SDK があります。MCP を保護するためにアイデンティティを作成する必要があります。アイデンティティはサービスで、MCP ゲートウェイを保護するのを処理します。 MCP ゲートウェイは Cognito を保護しません。Cognito がアイデンティティを保護しています。
アイデンティティサービスはエージェント用のトークンを取得するのを処理するサービスですが、どこから取得するかを知る必要があります。適切なスコープでリクエストして Cognito から取得します。これが、ユーザー URL を渡している理由です。 認可エンドポイント、そしてトークンエンドポイント。アイデンティティサービスが Cognito を呼び出してトークンを取得します。
その情報を取得したら、Roland または Roland のチームに渡す必要がある情報があります。ゲートウェイ URL を渡す必要があります。ゲートウェイを作成すると、ターゲットがなくても、その URL を使い続けることができます。Roland は MCP SDK を使用して接続するときに MCP URL が必要になります。彼がエージェントを作成するときに接続します。また、アイデンティティプロバイダー名を彼に与える必要があります。Agent Core では、複数のエージェントと MCP ゲートウェイを開発するときに、異なるアイデンティティプロバイダーがある場合があるため、このスクリプトで作成したそのプロバイダーのどのインスタンスを選択するかを指定する必要があります。リソースサーバー ID は、スコープをリクエストするときに Cognito から取得されます。たとえば、そのゲートウェイの場合、正しいクレームを持つトークン、つまり正しいクレームを持つ JWT トークンを取得します。
それでは、スクリプトを実行して MCP gateway が作成できるか見てみましょう。 ここにはいろいろなスクリプトが入っています。 gateway をテストするスクリプトと接続をテストするスクリプトがあるのが見えますね。それは後で説明します。それから、JSON ファイルを保存するための S3 bucket も作成しています。gateway を作成してみましょう。一度実行して、その後もう一度実行します。 この場合、Cognito を作成して、identity service を作成して、MCP gateway を作成して、その情報を SSM Parameter Store に保存して Roland が使えるようにします。
ステータスに絵文字が付いているのは Quiro が好きだからなんですが、これはいいと思います。このテキスト出力をすべて説明してくれるので、とても便利だと思います。Quiro が私のために入れてくれました。これが Roland が使う gateway なので、彼に渡すつもりです。コンソールに行ってこの辺りを少し見てみましょう。 これは AgentCore landing zone、つまり最初に見るページです。左側に gateways があって、さっき作成した reinvent app gateway があります。 これが Roland に渡す MCP URL で、identity は、 Cognito を使った inbound identity と、どのように作成されるかの discovery URL です。ここまでは順調です。
では、3 つのマイクロサービス（appointments、technicians、claims）のターゲットを作成しましょう。 このセットアップの次のパートは Part B で、MCP gateway targets を作成します。gateway を一度作成してから targets を取得することができます。 ここのコードをコメントアウトしましょう。 それからもう一度実行します。これが実行する内容です。コードを見せます。appointments を description、customer、technician で作成します。claims は customer の中に入っています。つまり 3 つのサービスは appointments、customer、technician です。claim 情報は customer の中に policy と一緒に保存されています。
3 つのターゲットそれぞれについて処理します。 URL を構築します。覚えていますか、足りなかった URL です。JSON ファイルを fetch して、 この関数に URL を挿入して、アップロードして、S3 bucket にアップロードします。MCP gateway の仕組みは、この JSON ファイルを S3 bucket に入れて、gateway にこのファイルの S3 location を与えて target を作成するというものです。 これはヒットする API URL、パス、bucket 名で、その後 credential provider ARN で target を作成します。
これがやることは、REST API が保護されている場合（ほとんどの場合そうであるべきですが）、パラメータかもしれませんし、authorization header のような authorization header かもしれません。
Authorization header みたいなヘッダーがあって、そのバケットへの URL、ターゲットをどう呼びたいか、それの良い説明、そしてこのターゲットをアタッチすべき gateway ID があるといいですね。
このコードは実際に 3 回実行されます。ここで見られるように、3 回実行されて JSON コードを取得しました。 Jason が spec API を開いて、サーバーを挿入して、3 つのバケットに入れて、gateway を作成しました。 S3 bucket はここにあるはずです。ここにあるか確認してみましょう。Agent Core Gateway。そう、これらが このコードが作成した 3 つの JSON ファイルです。 それを取得して appointment を作成しました。Jason customer、Jason technician、Jason、そしてそれが target を作成するときに渡したものです。 これらの Jason ファイルの場所はここです。つまり JSON はここに位置していて、その後 target を作成できます。それを取得して expose します。Agent gateway をここで見ると、下部に technician、customer、appointment があります。 情報はそんなに多くはありませんが、status が表示されています。作成されるまでに約 1 分かかります。JSON と その JSON ファイルの S3 location と ID です。詳細情報はそんなに多くはありません。これをクリックすると REST API に認証する方法に進みます。
Identity Service と Cognito による認証・認可の実装
コードに戻りましょう。 時間はどうですか？大丈夫です。もう 1 つ見せたいのは S3 bucket、gateway、そして Roland に渡している情報で、それは SSM parameters です。 ここにあると思います。新しい画面を開きましょう。 Parameter store だと思います。 Parameter store を使うのは、それが configuration だからです。Secret みたいなものではありません。Secret があれば、Secret Manager に保存します。ちょっと後で見せます。Secret Manager は IAM policies を設定する必要があるときに使われます。identity service が client token、client secret を使っていて、その secret は Secret Manager に保存されているからです。
Identity service がトークン交換を行う必要があるときはいつでも、Secret Manager に行って、そこにある値を取得して、Cognito とのトークン交換を行います。MCP gateway が REST API に接続するときも同じことが起こります。例えば API key があれば、または authorization header があれば、これが この REST API にアクセスするように設定されていれば、credentials も Secret Manager に保存されます。Service には integration があります。Agent Core には Secret Manager との integration があって、それをあなたのために行います。それはやり方として便利で、また code からそれをトリガーするための SDK も提供しています。
コードを実行するとき、これが target を作成して identity を作成したときにバックグラウンドで起こったことです。これが Roland に与えている情報です。例えば、最も重要なのは MCP URL です。ここで見られるように、値は gateway bedrock agents West 2 と一致しています。私たちは West 2 Amazon AWS.com/MCP にいます。Roland は MCP client stream streamable HTTP endpoint を使ってそれに接続します。identity がトークンを取得したときのトークンを使って。これは情報を交換できる 1 つの方法です。複数の方法があります。既に知られているものであれば、code を通じてやりました。それはパラメーター渡しをより安全に処理するためです。
S3 バケットを見せたんですけど、そこに JSON を保存してるか Secret Manager に保存してるかっていう話ですね。Secret Manager にはいくつかの情報が入ることになります。というのも、私たちは inbound identity service もやってるからです。UI が Agent Core と通信したいときに、何でもかんでも Agent Core と通信できるわけじゃないんです。その接続を保護したいんですよ。 ここで見えるのが API キーとして保存されている情報で、そのサービスにアクセスする API キーですね。それから reinvent Cognito がここにあります。これを見せることができますか？これが client secrets で、ちなみにこれは削除するつもりなので、別に構わないんですけど。
これが client seeker です。もし Cognito でこの client seeker をローテーションするための自動化があれば、例えば新しいのを生成するとか、もし漏洩したら、実際にローテーションする自動化があって、Cognito に行って、client secrets を新しいのにローテーションして、Secrets Manager に戻ってきて、ここに入れることができます。次に Identity Service がこれを取得して、Agent の代わりに MCP Gateway にアクセスするための Cognito トークンと交換するときに、ここにあるわけです。
だから自動化はそこにあるんです。それが私たちがこれらのサービスをすべて提供する理由です。すべてが API を持ってて、CloudFormation、CLI、Terraform、CDK を使ってこのローテーションを実際に行えるように SDK も提供してます。企業によっては、顧客が 90 日ごと、または 6 ヶ月ごとにローテーションしたいというポリシーを持ってるところもあるので、これが Secrets Manager との統合です。 この情報が見えるんですけど、Identity Service についてすべての詳細を取得すれば、実はここで見せることができるんです。作成されたんです。 ここで見えるのが reinvent Cognito gateway provider です。これが私のコードが作成した provider で、これが client secret にアクセスする方法について裏側に保存されている情報で、ここにあります。ここに行ってクリックすれば、そこに行くので、これが統合です。 それから agent identity を使うことのセキュリティ面ですね。これで終わりだと思います、Roland。
Agent 開発とライブデモ：ホームインシュアランスアシスタントの実演
同じパラメータがあります。私のものを削除しておきますので、これは必要ないです。これも必要ないです。Agent を作成して、UI を見せてくれるんですね。Agent を見せるんです。 わかりました、Carlos、ありがとうございます。ここで私は agent project の中にいます。私はどちらかというと AWS ネイティブな開発者なので、Agent Core Runtime を使ってて、これはサーバーレスです。Agent Core Gateway と Agent Core Identity を使ってるんですけど、UI は実は ECS と Fargate で構築してるんです。彼は Kubernetes の人で、私は違うんで。私は単なる agent 開発者です。私たちのコアの非常にスケーラブルなビジネスロジックの多くは EKS クラスタ上にあります。
ここでコードの中に入ってるんですけど、私のプロジェクトの中にいます。便宜上、すべてを Carlos のラップトップに入れてますけど、実際には別々にやってます。Home insurance というのが私の agent です。最初にやったことは、Carlos が SSM パラメータをロードすることについて話してるのを見せたんです。彼はすでに見せてるので、これは基本的には SSM パラメータに行ってアクセスして、私が必要な情報を取得するコードです。基本的には gateway provider name、gateway resource server、それから彼が見せた MCP URL ですね。 これは AWS で SSM ストアからパラメータを取得するために AWS の API を使うために使う基本的なコードです。 次にやりたいことは、MCP client を取得することと、authorization token を取得することについてのコードを見せることです。 認証情報を保存したくないので、staple を作ったりしないので、Python でデコレータを使うんです。gateway client を作成するたびに、または gateway client にアクセスするたびに、refresh token を取得できるようにしたいんです。これはデコレータパターンを使ってやるのが良いパターンです。SDK API を呼び出して access token を取得するんです。この関数を呼び出すたびに、refresh token を取得することになります。これはセキュリティのベストプラクティスです。
では、ここでは URL を取得して、標準的な MCP クライアント SDK を使用して、Python Lambda 関数で実際に MCP クライアントを作成しようとしています。ストリーム可能な HTTP クライアントを使用してそれを作成しています。これはゲートウェイでホストされているリモート MCP サーバーだからです。デコレータで毎回リフレッシュされる認可ヘッダーと、いくつかのタイムアウトパラメータなどを取得します。 これが、エージェント開発者として私がコードで行う次のステップです。もちろん、モデルにアクセスできます。Anthropic の Claude Haiku 4.5 を使用していると思います。 そして、これはゲートウェイを停止することに関するクリーンアップコードです。では、ここで Part C があります。AI エージェントを作成して、それを A2A サーバーにしようとしています。ゲートウェイと ID のような AWS リソースにエージェントがアクセスできるようにしたいので、必要なヘッダーを取得します。Agent Core SDK トークンも取得します。セッション ID も取得するので、セッションを持つことになります。そして、agent context という小さなヘルパーを使用して、セッション ID が見つからない場合はそれを保存します。
Agent Core runtime を使用しているので、リクエストが来て、runtime がまだ実行中の場合、既にエージェントを取得したかどうかを確認します。それが消えると、エージェントを遅延作成します。 ここでは、agent context get agent を使用します。そこにない場合は、実際に先に進んで作成します。クライアントゲートウェイを開始します。クライアントゲートウェイを設定して、ツールのリストを取得します。ここに Strands エージェントがあります。Strands SDK を使用します。ゲートウェイから取得したゲートウェイツールのリストを提供して、モデルを提供して、システムプロンプトと説明を提供して、Strands エージェントを作成します。 その後、Strands エージェントを A2A サーバーとしてラップします。そうすることで、将来別のエージェントがこのエージェントを呼び出したい場合、それが設定されて、Agent Core runtime 内で実行されます。
では、これの一部を見せましょう。これは Carlos のマシンで初めてやっているので、 Agent Core runtime を見てみます。このコードをデプロイに展開しました。 このホームインシュランスエージェントがあり、バージョン 41 でデプロイされました。これを何度かデプロイしました。既に実行中のものがあります。2 週間のギャップがあったことがわかります。その週は顧客訪問のために出張していました。これは runtime で実行されています。サーバーレス runtime です。観測可能性に関するすべてのことを行います。 事前構築されています。それについて本当に興奮しています。また、UI は ECS Fargate で実行されています。デモのためにローカルで実行しようとしています。
では、戻ります。 Carlos の履歴をすべて取得しました。よし、UI を実行しましたね。 では、UI アプリケーションを実行しましょう。 大丈夫です。ローカルホスト 8000 ですね。既に開いていると思います。より大きい方だと思います。よし、クールです。接続されているかどうか確認するために更新してみます。デモゴートが中にいます。Wi-Fi デモゴート。よし、では。では、言ってみましょう。キャップスロックを上げてください。いや、ツールがあったんです。ツールにアクセスできますか？では、これは最初に見たビデオのようなもので、ツールにアクセスできるかどうか尋ねていて、予約、顧客に関する何かで戻ってくるはずですよね？3 つのマイクロサービス。では、 そこです。どこにあるのか？3 つのツール、3 つの異なるマイクロサービス：予約スケジューリング、技術者サービスなど。Carlos がサルサダンスをしていたと言おうとしています。具体的である必要があります。彼は冷蔵庫に衝突しました。水が至る所にあります。まだ水が至る所にあります。そしてボタンが機能しませんよね？はい、では、これは Carlos がサルサダンスをするときに起こることです。何が得られるか見てみましょう。 そして、あなたはユーザー Emily です。彼女は有効なポリシーを持っていると思います。見てみましょう。はい、ログインしたことに注意してください。 完璧だったと思います。019 でクレームを正常に作成しました。クレームが提出され、水が至る所にあるため、高緊急度としてマークされました。これは確実に高優先度の問題です。緊急サービス予約修理を予約してもらいたいですか？はい、Carlos の妻が気付く前に素早くスケジュールしてください。 ここで何が得られるか見てみましょう。UI からエージェントへ、MCP ゲートウェイへ、ECS クラスターへ、そして戻ってくる、つまり、LLM が中間にあるということですね。LLM、この情報、はい、エージェントがそれを LLM に送信していて、これらのエージェントは推論を持っています。つまり、複数回 LLM に行くことができ、単一の MCP 呼び出しだけではなく、複数の呼び出しで推論できるということです。まだ処理中です。では。 よし、では予約ですね。はい、では、予約時間などを設定しました。David Chang、では 2 時間後、12 月 2 日午後 9 時、かなり遅い技術者訪問です。
あなたの質問に懸念があるのが聞こえます。 冷蔵庫の緊急事態、保険請求、修理予約のスケジューリングの処理に非常に熟練していますが、残念ながら私の専門知識は Carlos のサルサダンスの習慣を管理することまで及びません。それは確実に私のホームインシュランスアシスタント機能の範囲外です。LLM はいくつかの提案を与えてくれます：ダンスインストラクターが必要です。多分キューバ人のような私を手に入れて、その後、もっと明確なスペースを手に入れることができます。多分冷蔵庫の近くで踊らないでください。多分あなたとあなたの妻のためのダンスレッスン、そして多分あなたの家電の周りの保護パッド。ですから、あなたのためのいくつかの良い推奨事項もあります。
いいですね。これがデモの一部です。コードの一部をお見せしましたが、これをサンプルに入れる予定です。QR コードが付いたスライドがあって、すべて揃っています。PowerPoint に戻しましょう。これは Ron がすでに再生したデモです。これはバックアップでした。Wi-Fi が機能しなかったので。 ビデオは必要ありませんでした。どうせ必要なかったと思いますけど。
では、学んだこととリソースについてです。既存のシステムと決定論的ロジックを公開する能力は確実にあります。MCP Gateway を使ってそのロジックを公開して、セキュリティを確保して、エージェントだけが適切なユーザーの代わりにそれを保護して行動できるようにしてください。Agenta はあなたにとって多くのモダナイゼーションを実現できます。 サンプルがあって、EKS 側と AgentCore の例の両方をやる予定で、それらを投稿します。ここにリソースがあります。写真を撮りたければ。 ここで、私たちが言及したリソースへのアクセスと、いくつかの便利なリンク、そしてコードが見られます。 チェックしてみてください。ここにあります。
いくつかのセッションについてです。友達に教えてください。明日もこれを繰り返すので、コードを見たければ。明日の 5 時 30 分に Wynn で RC 3:14 というセッションをやります。そのセッションは Redula という同僚と一緒にやる予定で、彼女と私はアーキテクチャの考慮事項などについてたくさん話します。Expo で私たちを見つけたら、質問ができます。これは録画されているので、録画を止めた後に質問を受け付けます。
他のセッションについてです。3:17 は Mandalay Bay ここで午後 4 時です。また私に会えます。EAS MCP についてのハンズオンワークショップをやっています。MCP について学んでいて、MCP EAS を使って ECS クラスタをトラブルシューティングしたり、分析したり、DevOps で管理したりする方法を学んでいるなら、後で Venetian Rock house で技術フィールドコミュニティと一部のお客様向けのイベントをホストしています。そこに立ち寄って、質問したり、それらのことについてチャットしたりしたければ、私たちもそこにいます。来ていただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion