この記事でわかること MCPサーバーはPythonやTypeScriptだけでなく、Spring AIを使えばJava(Spring Boot)でも構築できる MCPサーバー機能は、Spring AIの公式スターターを使えば簡単に既存のSpring Bootアプリに組み込める(サーバー設定はapplication.ymlのみ) 既存アプリがSpring SecurityのOAuth2 Resource Serverで認証していれば、MCPの認可に必要なメタデータ公開(RFC 9728)も含めてSpring Securityの標準機能で対応できる AIエージェントがCMDBの構成情報を自分で参照できるようになると、Atlassian MCPなど他のMCPとも組み合わさって、脆弱性対応やEOL対応といった業務がエージェントとの1つの会話で完結する はじめに こんにちは。KINTOテクノロジーズ(以下、KTC) プラットフォームグループ Platform Engineeringチームの山田です。普段は社内向けのCMDBを内製開発していて、ここ最近はCMDBと生成AIを組み合わせる取り組みを続けています。 CMDBそのものやSpring AIについては過去の記事で紹介しているので、あわせてご覧ください！(CMDBの記事は少し古いですが、雰囲気は伝わるかと思います) https://blog.kinto-technologies.com/posts/2023-12-14-CMDB/ https://blog.kinto-technologies.com/posts/2025-06-11-springAI/ 今回はその続きとして、CMDB本体(Spring Boot製)にMCPサーバー機能を追加し、AIエージェントから社内の構成情報を直接検索できるようにしました。 背景 Claude CodeなどのAIエージェントだけで業務を進める場面が、この1年で一気に増えてきていると思います。社内でも各種MCPサーバーやスキルなどの整備が進み、調査・実装・ドキュメント作成の多くをエージェントに任せられるようになっています。 一方で、困っていたのが、今回の主役であるCMDB (Configuration Management Database: 構成管理データベース) のデータです。CMDBは、プロダクト・チーム・GitHubリポジトリ・脆弱性・SBOMといった社内の構成情報を一元管理するデータベースで、KTCでは内製開発しています(詳しくは冒頭の過去記事をご覧ください)。せっかく構成情報を集約しているのに、これまでの参照手段はWebアプリだけでした。そのため、エージェントで作業をしていてCMDBのデータが必要になるたびに、以下の作業が発生していました。 CMDBのWebアプリを開いてキーワード検索する 検索結果のテキストをコピーして、エージェントのプロンプトに貼り付ける この間、エージェントの作業は止まり、人がWebアプリとエージェントの間でデータを受け渡すだけの作業に時間を取られます。せっかく構成情報を一元化したのに、AIエージェントからは参照できない状態でした。 この手作業での受け渡しをなくすため、CMDBをMCPサーバー化することにしました。 CMDBのMCPサーバーで何ができるようになったか 先に、できるようになったことの紹介です。 たとえば、あるライブラリに脆弱性が見つかったとします。SBOM・GitHubリポジトリ・プロダクト・チーム・ユーザーなどを管理するCMDBのMCPサーバーができたことで、こうした脆弱性対応をAIエージェントとの1つの会話の中で完結できるようになりました。具体的には、SBOM情報から脆弱性のあるバージョンのライブラリを使っているGitHubリポジトリを洗い出し、リポジトリに紐づくプロダクトと管理チーム・担当者を特定し、担当者向けのJiraチケットの起票、さらには脆弱性を解消するPRの作成まで進められます。 ①〜③と⑤がCMDBのMCPツール、④はAtlassian MCP、⑥はエージェント自身のコーディング機能です。 ポイントは、CMDBのMCPサーバー単体で完結するのではなく、他のMCPやエージェントの機能と組み合わさることで業務が一気通貫になることです。AIエージェントは、参照できるコンテキストが増えるほど、対応できる業務の幅が広がります。CMDBにはエージェントが持っていない社内の構成情報が集まっています。これまで人が都度補っていたこれらの情報をMCPで提供することで、エージェントに任せられる範囲そのものを広げることができました。 脆弱性対応の他にも、たとえばEOL(サポート期限)対応にも同じ要領で使えます。期限切れが近いコンポーネントとそれを使っているプロダクトをCMDBのMCPツールで洗い出し、担当チームの特定からJiraチケットの起票までを、そのまま1つの会話で進められます。 MCPサーバーの実装にSpring AIを選んだ理由 MCPサーバーの構築というと、PythonやTypeScriptのイメージが強いかと思います。公式SDKの充実度やFastMCPのようなフレームワークの存在もあり、実装記事もその2つに偏っている印象です。 ただ、今回MCPサーバー化したい対象は、Spring Bootで実装済みの既存アプリでした。別プロセスでPythonやTypeScriptのMCPサーバーを立ててAPIを中継させる構成も考えられますが、Spring AIを使って既存アプリにMCPサーバー機能を組み込めば、以下の資産をそのまま使い回せます。 REST APIのために実装してきたビジネスロジック(service層) Spring Securityを使った認証認可の仕組み ECSへのデプロイや監視などの運用の仕組み 唯一の不安は「Entra IDを使った既存の認証認可が、AIエージェント相手でも同じように使えるのか」でした。MCPの認可仕様はOAuth 2.1ベースで比較的新しく、検証するまでは正直手探りでしたが、結論から言うとSpring Securityの標準機能で対応できました(詳細は実装の節でお話しします)。 もしSpring Bootでアプリケーションを開発・運用しているチームであれば、MCPサーバーの構築にSpring AIを選ぶメリットは大きいと思います。 技術スタック Java 21 Spring Boot 4.0 Spring AI 2.0 (spring-ai-starter-mcp-server-webmvc) Spring Security (OAuth2 Resource Server) Microsoft Entra ID (認可サーバー) AWS (CloudFront + ALB + ECS など) システム構成 既存のCMDBバックエンド(Spring Boot)に、MCPエンドポイント /mcp を追加した構成です。MCPサーバーのために新しく追加したインフラはありません。なお、図はMCPサーバーに関係する部分に絞っており、フロントエンドの配信経路などは省略しています。 実装 ここからは実装内容を紹介します。なお、記事中のコードは一部、省略・編集しています。 依存関係の設定 build.gradleにSpring AIのBOMとMCPサーバー用スターターを追加します。追加する依存関係はこれだけです。 ext { set('springAiVersion', "2.0.0") } dependencies { implementation 'org.springframework.ai:spring-ai-starter-mcp-server-webmvc' } dependencyManagement { imports { mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}" } } サーバー設定はapplication.ymlのみ MCPサーバーとしての設定はapplication.ymlに書くだけで、Javaの設定クラスは1つも作っていません。あわせて、JWT検証(OAuth2 Resource Server)の設定も抜粋します。 spring: security: oauth2: resourceserver: jwt: issuer-uri: https://login.microsoftonline.com/${TENANT_ID}/v2.0 ai: mcp: server: name: cmdb-mcp version: 0.0.1 instructions: >- CMDB は KINTO Technologies (略: KTC) 社内の構成管理データベースのこと。 プロダクト・チーム・リポジトリ・脆弱性などの社内構成情報を検索できる。 protocol: STATELESS type: SYNC stateless: mcp-endpoint: /mcp annotation-scanner: enabled: true 設定のポイントを2つ紹介します。 1つ目は instructions です。ここに書いた文章はMCPの初期化時に一度だけエージェントへ渡されます。「CMDBとは何か」のような前提知識をここに置いておくと、各ツールのdescriptionで同じ説明を繰り返さずに済み、ツール定義のトークンを節約できます。 2つ目は annotation-scanner です。これを有効にすると、後述する @McpTool の付いたメソッドが自動でツールとして登録されるため、ツール登録用のBean定義も不要になります。 @McpToolでツールの実装 ツールは @McpTool を付けたメソッドとして実装します。プロダクト検索ツールを例に、実装の全体像を紹介します。 @Component public class ProductMcpTools { private final ProductService productService; public ProductMcpTools(ProductService productService) { this.productService = productService; } @McpTool( name = "searchProducts", description = """ プロダクトを検索します。一覧・絞り込み・詳細取得はすべてこのツール\ (productId 指定で1件の詳細、未指定で一覧)。""", annotations = @McpTool.McpAnnotations( readOnlyHint = true, destructiveHint = false, idempotentHint = true, openWorldHint = false)) public ProductSearchMcpResult searchProducts( @McpToolParam(description = "プロダクトID。指定すると1件の詳細を返す。一覧結果の productId を渡す", required = false) Integer productId, @McpToolParam(description = "プロダクトの所属部署(グループID)で絞り込み", required = false) String groupId, @McpToolParam(description = "true で削除済みプロダクトを検索。削除済みはこの指定時のみ取得可(既定: false)", required = false) Boolean deleteFlag) { SearchProductServiceParameter parameter = new SearchProductServiceParameter(); parameter.setProductId(productId); parameter.setGroupId(groupId); parameter.setDeleteFlag(Boolean.TRUE.equals(deleteFlag)); // 既存のREST API用serviceをそのまま呼び出す SearchProductServiceResult result = productService.searchProduct(parameter); return productId != null ? ProductSearchMcpResult.ofDetail(result) : ProductSearchMcpResult.ofList(result); } } このクラスの役割はControllerと同じです。引数を組み立てて既存のserviceを呼び、結果をエージェント向けに整形するだけで、ビジネスロジックは置きません。検索ロジック本体は、REST APIのために実装済みの ProductService をそのまま呼んでいます。 これだけでMCPサーバーのツールが実装できてしまいます。 今回実装した検索ツール12個のほとんどは、既存のservice層を変更することなく再利用できました。REST APIのために実装してきたservice層を、MCPツールからそのまま再利用できるのが、既存アプリに組み込む構成のいちばんのメリットだと思います。 ツール 概要 searchProducts プロダクトの一覧・詳細検索 searchGroups 部署(グループ)の一覧取得 searchTeams チームとメンバーの検索 searchUsers ユーザーの検索 searchDomains ドメインの検索 searchGithubRepositories GitHubリポジトリの検索 searchVulnerabilitySummaries 脆弱性サマリの横断検索 searchVulnerabilityDetails 脆弱性詳細の検索 searchSbom SBOM(ソフトウェア部品表)の検索 searchEol EOL(サポート期限)の検索 searchArn AWSリソース(ARN)の検索 searchSchedules 開発環境のコスト削減を目的とした、AWSリソース起動停止スケジュールの検索 実装にあたって、3点補足します。 1つ目はツールヒント(annotations)です。MCPの仕様では、ヒントが未指定のツールは readOnlyHint=false ・ destructiveHint=true 、つまり「破壊的な操作をするかもしれないツール」というデフォルトで扱われます。エージェントが検索ツールの利用をためらわないよう、読み取り専用であることをヒントで明示しています。 2つ目は引数の形です。引数は1つのオブジェクトにまとめず、フラットに並べています。Spring AIはメソッドの引数をそれぞれinputSchemaのプロパティに変換するため、REST APIのようにパラメータクラスへまとめると、エージェントから見えるJSONスキーマに余計な階層ができてしまいます。既存のパラメータクラスの流儀とは意図的に変えている部分です。 3つ目はレスポンスの件数です。CMDBは、SBOMのように件数が膨大なデータも持っています(執筆時点で50万件超)。こうしたデータをそのまま返すと、エージェントのコンテキストを圧迫し、MCPの結果サイズ上限にも引っかかります。件数の多いデータを扱うツールでは絞り込み条件を必須にし、1ページ50件のページングと総件数(totalCount)の返却をあわせて実装しています。ページを分けても、データが足りなければエージェントがpageを変えて自分でツールを呼び直してくれるため、複数回の呼び出しで必要なデータを集められます。 認証認可 一番不安だった認証認可ですが、結論としては自前の認可サーバーを実装する必要はなく、既存のEntra IDをそのまま認可サーバーとして使えました。MCPの認可仕様の登場人物と流れは以下のとおりです。 sequenceDiagram participant Agent as AIエージェント<br/>(Claude Code等) participant MCP as CMDBバックエンド<br/>(MCPサーバー) participant Entra as Microsoft Entra ID Agent->>MCP: ① POST /mcp(トークンなし) MCP-->>Agent: ② 401 + WWW-Authenticate<br/>(メタデータの場所を案内) Agent->>MCP: ③ GET /.well-known/oauth-protected-resource MCP-->>Agent: ④ メタデータ応答<br/>(認可サーバー = Entra ID の場所) Agent->>Entra: ⑤ 認可コードフロー(PKCE)<br/>ブラウザでSSOログイン Entra-->>Agent: ⑥ アクセストークン(JWT) Agent->>MCP: ⑦ Bearerトークン付きでツール実行 MCP->>MCP: ⑧ JWT検証(署名・issuer・有効期限) MCP-->>Agent: ⑨ 検索結果 重要なのが③④のProtected Resource Metadata (RFC 9728)です。MCPサーバーは /.well-known/oauth-protected-resource でメタデータを公開し、「このサーバーの認可サーバーはどこか」をエージェントに教えます。エージェントはこれを読んで、自動的にEntra IDのログイン画面(ブラウザのSSO)へユーザーを誘導してくれます。 Spring側の実装は、ほぼ標準機能の組み合わせで済みました。 JWT検証: Spring SecurityのOAuth2 Resource Server。application.ymlの issuer-uri の設定だけで、Entra IDが発行したJWTの検証が動きます メタデータの公開: Spring Securityが標準でRFC 9728をサポートしており( OAuth2ProtectedResourceMetadataFilter )、認可サーバーの場所などをJavaの設定コード数行のカスタマイズだけで公開できます 1点だけインフラ側の対応が必要でした。RFC 9728のメタデータはドメインルートの /.well-known/ 配下で公開する必要がありますが、バックエンドは /api のコンテキストパスで動いています。そこで、CloudFrontで /.well-known/oauth-protected-resource* へのリクエストをALB(オリジンパス /api )にルーティングして解決しました。 ちなみに、Spring AIのドキュメントには、MCPサーバーの認証認可をコミュニティモジュールの mcp-security で実現する方法も紹介されています。 なお、AIエージェントによってOAuth周りの実装には微妙に差があり、あるエージェントでは問題なく接続できても、別のエージェントではエラーになることがありました。MCPサーバーを社内に展開する場合は、利用が想定されるエージェントで早めに接続確認をしておくと安心です。 AOPによる利用状況ログ 社内展開後の利用状況を把握するため、ツール呼び出しのログも仕込みました。 @McpTool アノテーションを対象にしたAOPのアスペクトを1つ書くだけで、ツールクラスが今後増えても自動でログ対象になります。ログにはツール名・ユーザーID(JWTのクレームから取得)・検索条件を構造化フィールドとして出力し、ダッシュボードで「誰がどのツールをどんな条件で使っているか」を集計できるようにしています。 実行結果 最後に、社内情報のためお見せできる部分が少なくなってしまいますが、実際の使用感をご紹介します。 接続 (Claude Codeの場合) 以下のコマンドでClaude CodeにCMDBのMCPを登録します。 claude mcp add --transport http cmdb-mcp https://xxxxx/api/mcp \ --client-id xxx \ --callback-port 29352 サーバー一覧でCMDBのMCPを選択し、認証を開始します。 ブラウザで認証をします。 ツールを呼び出してみる 試しにSpring Bootで構築しているプロダクト一覧を出してみます。 「Spring Bootで構築しているプロダクトを洗い出して」と聞いてみると、CMDBのMCPサーバーにあるSBOM検索ツールを spring-boot-autoconfigure のコンポーネントを検索条件に入れて呼び出します。 こちらがレスポンスの一部になります。全部で31プロダクトがSpring Bootを採用しているそうです。多いですね。 次のステップ 更新系ツールへの拡張: 現在は検索専用ですが、登録・更新系のツールも要望があります。誤操作のリスクが検索とは段違いなので、権限制御や実行前の確認の仕組みとセットで検討していきたいと思います さいごに 今回は、Spring Boot製の社内CMDBをSpring AIでMCPサーバー化し、AIエージェントから社内の構成情報を検索できるようにした取り組みについてお話ししました。 MCPサーバーの構築はPythonやTypeScriptの情報が多いですが、既存のSpring Bootアプリを持っているなら、service層も認証もインフラもそのまま使い回せるSpring AIは十分有力な選択肢です。この記事が、JavaでのMCPサーバー構築を検討している方の参考になれば嬉しいです。 AIエージェントを中心とした働き方はまだまだ進化していくと思うので、キャッチアップと実践を繰り返しながら、Platform Engineeringチームとしてツールの整備を進めていきたいと思います。

本記事は「 Build full-stack AWS applications in minutes with AI-powered scaffolding 」を翻訳したものです。 AI アシスタントを使えば、AWS 上で動くアプリケーションや Web サイトを数分で立ち上げられます。しかし、実際のお客様に提供できる本番相当のものにたどり着くのは、依然として難しい部分です。セキュリティ、可観測性、型安全性、そしてレジリエンスは、本番運用では譲れない要件です。AI アシスタントがこれらすべてを一度で正しく実装できることはまれで、その出力を本番品質まで固めるには、レビュー・修正・テストのサイクルを何度も繰り返す必要があります。 このギャップを埋めるため、私たちは Nx Plugin for AWS のバージョン 1.0 をリリースします。 本記事では、それが何であるか、なぜこのように作ったのか、そして、お客様である Bingo Industries がこれを使ってマルチエージェントのソリューションをアイデアから本番まで 3 週間未満で進めた事例を簡単にご紹介します。 Nx Plugin for AWS とは何か Nx は、単一のリポジトリの中でアプリケーションを構成する多数のプロジェクトを管理する、拡張可能なオープンソースのビルドシステムです。Nx は プラグイン によって拡張でき、Nx Plugin for AWS はそのひとつで、AWS 上にアプリケーションをスキャフォールディングするためのオープンソースのツールキットです。これは Nx ジェネレーター のライブラリで、各ジェネレーターはリクエストに応じてアプリケーションの一部（API、Web サイト、AI エージェント）を、それらを動かすためのクラウドインフラストラクチャとともに構築します。 各ジェネレーターは、動作しデプロイ可能なアプリケーションの一部を書き出します。それぞれの部品には、セキュリティ・可観測性・型安全性のベストプラクティスがあらかじめ組み込まれています。また各ジェネレーターは決定的（deterministic）です。つまり、毎回同じ結果を生成します。これにより、AI アシスタントが自ら考え出さなければならないものではなく、信頼できる土台としてジェネレーターの上に構築を進められます。AI アシスタントはこれらのジェネレーターを自分で実行できるため、価値のある部分、すなわちアプリケーションをあなたのものにするロジックに労力を割けるようになります。 上の図は Nx Plugin for AWS を視覚的に示したものです。ワークスペースを作成し、エージェントまたは CLI を使ってアプリケーションの各部品をスキャフォールディングします。 クイックスタート: フルスタックのエージェンティックアプリケーションを数分で まずはワークスペース、つまり空の Nx モノレポから始めます。ワークスペースを作成するには、ターミナルで次のコマンドを実行します。 pnpm create @aws/nx-workspace my-project --no-interactive この例では pnpm を使っていますが、お好みで npm 、 yarn 、 bun も使えます。デフォルトではインフラストラクチャは AWS Cloud Development Kit (CDK) で定義されますが、 Terraform をお好みの場合は上記のコマンドに --iac terraform を付けて実行できます。エージェントを構築するので、Amazon Bedrock を呼び出せる AWS 認証情報 が必要です。 ワークスペースを Kiro CLI などの AI コーディングエージェントで開き、アプリケーションの構築を依頼します。たとえば次のようにします。 Nx Plugin for AWS を使って、shadcn と Cognito 認証を備えた React の Web サイトを、AG-UI プロトコル経由で TypeScript の Strands エージェントに接続し、それをデプロイするためのインフラストラクチャからなるフルスタックアプリケーションを構築してください。 AI エージェントは、上記のコマンドで作成したすべてのワークスペースにあらかじめ設定されている Nx Plugin for AWS MCP サーバー を使用します。このプロンプトによって、 Strands エージェント、Amazon Cognito ログインを備えた React フロントエンド、 AG-UI プロトコル 経由でユーザーとエージェントがやり取りする CopilotKit のチャットインターフェイス、そしてプロジェクトをデプロイするために必要な AWS リソースを定義したインフラストラクチャプロジェクトが手に入ります。 Web サイトとエージェントを自分のマシン上でローカルに起動するには、次を実行します。 pnpm dev Web サイトとエージェントは、コードを編集するとどちらもホットリロードされます。ローカルでの変更に満足したら、エージェントに AWS へのデプロイを依頼できます。 ここでは Nx Plugin for AWS をエージェントで駆動しましたが、お好みで CLI を使ってアプリケーションを手作業で組み立てることもできます。ステップバイステップの例は後述しますが、 クイックスタートガイド もご覧ください。Nx と Nx Plugin for AWS の恩恵を受けるためにゼロから始める必要はなく、ドキュメントでは 既存プロジェクトへのプラグイン追加 についても解説しています。 なぜこれを作ったのか 私たちは AWS の PACE（Prototyping and AI Customer Engineering）チームの一員で、スピードと本番運用への備えという緊張関係に日々向き合っています。私たちは、まだ明確な答えのない問題や、これまで作られたことのない技術的にリスクのあるアイデアについて、お客様と一緒に取り組みます。各エンゲージメントの期間は 4〜6 週間で、目標はただひとつ、特定のアイデアが実現可能かどうかを証明することです。 プロトタイプの価値は、問題の最も難しい部分、つまり従うべき確立されたパターンが存在しない部分から生まれます。これほど短いタイムラインでは、私たちのエンジニアは本番運用に向けたハードニングではなく、お客様の中核的な課題に時間を使う必要があります。とはいえ、プロトタイプは使い捨てるのではなく本番まで持っていけるほうが、お客様にとってより役に立ちます。 AWS 上での構築は通常、Infrastructure as Code、バックエンドサービス、フロントエンド、そして多くの場合、同一プロジェクト内に複数の言語が混在することを意味します。私たちには、選んだ言語に依存せず、多数の可動部からなるプロジェクトを管理できるビルドシステムが必要でした。私たちのチームは Nx にたどり着き、まさにこの目的のために数年間使ってきました。Nx はプロジェクトごとに一貫したモノレポのワークフローを、技術選定にかかわらず提供してくれます。ただ、Nx にモノレポを任せてもなお、私たちは各エンゲージメントの冒頭でプロジェクトの土台を手作業で組み立てていました。私たちは、自分たちのベストプラクティスをあらかじめ組み込んだ形で土台をスキャフォールディングし、本番に近いところからスタートして、限られた期間をお客様の課題に効率よく使いたいと考えました。 ジェネレーターがテンプレートやライブラリに勝った理由 現在の形にたどり着くまでに、私たちはいくつかのアプローチを試しました。 最初は、各エンゲージメントの冒頭でフォークするスターターテンプレートから始めました。フォークは変更した瞬間にドリフト（乖離）します。テンプレート側で加えた修正はフォークには決して届かず、必要かどうかにかかわらずテンプレート全体を引き継ぐことになります。 次に、ライブラリベースのアプローチを試し、プロジェクト構造・アプリケーションコード・インフラストラクチャコードを、再利用可能で型付きのビルディングブロックとして定義しました。これはテンプレートの問題の多くを解決しました。必要な部品だけを使えて、ライブラリへの改善はそれを使うすべてのプロジェクトに取り込めます。しかし、いくつか制約もありました。エンジニアがライブラリの公開していない設定を必要とした瞬間に、手が止まってしまうのです。ライブラリがサポートする範囲を超えたカスタマイズには、分かりにくい回避策、ライブラリ周りのコピー＆ペースト、あるいはライブラリのオーナーが拡張してくれるのを待つことが必要でした。PACE エンゲージメントの 4〜6 週間というタイムラインでは、どの選択肢も現実的ではありませんでした。 最終的にしっくり来たのが Nx ジェネレーター でした。フォークするテンプレートや依存するライブラリではなく、ジェネレーターはコードを直接あなたのワークスペースに書き込みます。生成された瞬間からそのコードはあなたのものであり、扱うのにプラグイン固有の知識は一切必要ありません。ジェネレーターが想定していなかった何かを変更したくなったら、いつも通りにコードを編集できます。そして、テンプレートでは生成コードが取り残されていたのに対し、 Nx マイグレーション によって、私たちが提供する改善が、以前にスキャフォールディングしたワークスペースにも届きます。ジェネレーターはいつでも実行できるので、既存の Web サイトに認証を追加したり、数か月前に作った API にフロントエンドを接続したりできます。各ジェネレーターは意図的に自己完結していて明確に説明されているため、個々のファイルではなく、より高いレベルのビルディングブロックで考えられるようになります。手作業でも AI アシスタントを使う場合でも、単一のコマンドで組み立てられる、コンポーネント丸ごとの単位で考えられるのです。 Nx Plugin for AWS の仕組み まずワークスペースを作成し、次にジェネレーターを使ってアプリケーションを組み立て、必要なものを必要なときにだけ追加していきます。ジェネレーターは単なるファイルテンプレート以上のものです。新しいファイルを書き出すだけでなく、既存のファイルを変更し、依存関係を配線し、設定を更新します。 API・Web サイト・データベース・AI エージェント向けのコアジェネレーター ジェネレーターは、ほとんどの AWS アプリケーションが構成される主要なコンポーネントを、TypeScript と Python の両方でカバーします。たとえば次のとおりです。 tRPC 、 FastAPI 、 Smithy を使った API と、それらをデプロイするためのインフラストラクチャ オプションで Amazon Cognito 認証を備えた React の Web サイト Amazon DynamoDB と Amazon Aurora 上のデータベース エージェンティック AI: Strands Agents SDK を使ったエージェントと Model Context Protocol （MCP）サーバーの構築。いずれも Amazon Bedrock AgentCore 上にデプロイされます。 デフォルトでは、各ジェネレーターは本来なら自分で追加しなければならないベストプラクティスを備えて出荷されます。 API ハンドラーには、構造化ロギング・AWS X-Ray トレーシング・Amazon CloudWatch メトリクスのために AWS Lambda Powertools が配線済みで組み込まれます。 生成される DynamoDB テーブルは、自動キーローテーション付きのカスタマーマネージド KMS 暗号化、ポイントインタイムリカバリ、削除保護を使用します。 生成される Aurora データベースは IAM 認証を備えた Amazon RDS Proxy の背後に配置され、データベースのスキーマとマイグレーションは、TypeScript 向けには Prisma 、Python 向けには SQLModel と Alembic であらかじめ設定されます。 エージェントと MCP サーバーは AgentCore Observability が設定された状態で提供され、AgentCore Gateway には エージェントのセキュリティ制御のためのポリシー を書き始めるのに必要なものがすべて揃っています。 スタック全体にわたる型安全な接続 これらのコンポーネントを結びつけるのが connection ジェネレーターです。React の Web サイトと tRPC の API があるとします。connection ジェネレーターを実行すると、両者が型安全なクライアントで配線され、API の形状に対する変更が、本番での呼び出し失敗としてではなく、デプロイ前にフロントエンドの型エラーとして現れるようになります。React フロントエンドをエージェントに接続する場合も同様です。 AG-UI プロトコル （リッチでインタラクティブなエージェントの応答をフロントエンドへストリーミングするためのオープンスタンダード）で生成されたエージェントに対しては、応答のストリーミング、ツール呼び出しのレンダリング、状態管理を備えた CopilotKit のチャットインターフェイスを生成します。すべてのジェネレーターがローカル開発をサポートしており、 Nx continuous tasks を使えば、単一のコマンドで相互接続された各部品（Web サイト、その API、エージェント）が、あなたのマシン上でホットリロードしながら一斉に立ち上がるため、何もデプロイせずに変更をテストできます。 実際には、コンポーネントの選択とそれらの接続は AI に任せて駆動しますが、このアプローチにより、お好みならアプリケーション全体を視覚的にスキャフォールディングすることもできます。 このスクリーンショットは Nx Plugin for AWS の Graph Builder のものです。作りたいアプリケーションを図として描き、それをスキャフォールディングするためのコマンドをコピーできます。 あなたのコード、あなたのインフラストラクチャ選択 生成されるコードは主流のフレームワーク上に構築され、あなたのものになります。プラグインへのランタイム依存はなく、生成された内容を編集するのを妨げるものは何もありません。ジェネレーターは出発点であってコミットメントではありません。作りたいものに最も近いものを選び、そこから自分の方向へ進めてください。インフラストラクチャの定義方法も選べます。ジェネレーターは AWS Cloud Development Kit (AWS CDK) のコンストラクトか Terraform のモジュールのいずれかを生成するからです。 Nx マイグレーションで最新に保つ コードを所有することは通常、ライブラリが与えてくれていた唯一のもの、すなわち後から改善をきれいに取り込む手段を犠牲にすることを意味します。v1.0 では、Nx Plugin for AWS は Nx マイグレーション によってそのギャップを狭めます。私たちが新しいバージョンを出荷したら、 公開されたマイグレーションを適用 してワークスペースを更新できます。マイグレーションは、アプリケーションコードだけでなく、ジェネレーターが書いたすべてに届きます。たとえば、非推奨になった Vite の設定オプションを現行の API に置き換えたり、静的 Web サイトのアクセスログを Amazon Simple Storage Service (Amazon S3) バケットから CloudWatch へ移して、監視やアラームを設定できるようにしたりします。エージェントにプラグインのアップグレードを依頼することもできますし、CLI を使ってマイグレーションを駆動することもできます。 # Install the latest version and prepare migrations pnpm nx migrate @aws/nx-plugin@latest # Apply the migrations to your codebase pnpm nx migrate --run-migrations 変更に判断が必要で自動的に適用できない場合は、オプションのエージェンティックマイグレーションが、あなたを放置せずにコーディングエージェントを通じてその変更をガイドします。最新に保つことが、リリースノートやプルリクエストを手作業でレビューする作業ではなく、日常的なコマンドになります。 ステップバイステップの例: CLI を使ったスキャフォールディング ワークスペースを作成した後、最も手早く始めるには AI にジェネレーターを駆動させるのが良いですが、お好みで各ジェネレーターを CLI から手作業で呼び出すこともできます。このセクションでは、CLI コマンドといくつかの小さなコード編集で、複数言語のアプリケーションを構築する方法を順を追って説明します。 AWS 認証情報 に加えて、Python エージェント用に UV をインストールしておく必要があります。 # Create a new workspace with pnpm (yarn, bun and npm are also supported) pnpm create @aws/nx-workspace my-project --no-interactive cd my-project # Create a Python project and add an agent pnpm nx g @aws/nx-plugin:py#project backend --no-interactive pnpm nx g @aws/nx-plugin:py#agent --project backend --auth=cognito --protocol=ag-ui --no-interactive # Add a website with Cognito login pnpm nx g @aws/nx-plugin:ts#website website --no-interactive pnpm nx g @aws/nx-plugin:ts#website#auth --project website --no-interactive # Connect the website to the agent pnpm nx g @aws/nx-plugin:connection --source-project=website --target-project=backend --no-interactive # Create a CDK project to deploy to AWS pnpm nx g @aws/nx-plugin:ts#infra infra --no-interactive Terraform を使いたい場合は、ワークスペースの作成時に --iac=terraform を渡し、 ts#infra の代わりに terraform#project を使います。同じパターンがすべてのジェネレーターに当てはまります。エージェントを tRPC や FastAPI のバックエンドに差し替えれば、connection ジェネレーターは代わりにそのバックエンドへ Web サイトを配線します。 connection ジェネレーターはすでに CopilotKit がエージェントと安全に通信するよう配線済みなので、あとは React コンポーネントをインスタンス化するだけです。たとえばホームページで次のようにします。 // packages/website/src/routes/index.tsx import { createFileRoute } from '@tanstack/react-router'; import { BackendAgentChat } from '../components/backend-agent-chat'; export const Route = createFileRoute('/')({ component: RouteComponent, }); function RouteComponent() { return <BackendAgentChat />; } pnpm dev を実行すると、ローカルの Web サイトとエージェントを起動できます。 AWS 認証情報 が設定されていれば、エージェントは Amazon Bedrock 上の Strands のデフォルトモデルを使用します。ローカル開発サーバーを開いて、エージェントとのチャットを始められます。 準備ができたら、生成された CDK コンストラクトを自分のスタックに組み込みます。 // packages/infra/src/stacks/application-stack.ts import { Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { BackendAgent, UserIdentity, Website } from '@my-project/common-constructs'; export class ApplicationStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Create the Cognito resources const identity = new UserIdentity(this, 'Identity'); // Create the agent new BackendAgent(this, 'Agent', { identity, }); // Create the website new Website(this, 'Website'); } } 開発用スタックを AWS にデプロイするには、 pnpm nx deploy-sandbox infra を実行し、デプロイされたユーザープールに Amazon Cognito ユーザーを作成 し、CloudFront ディストリビューションの URL を開いてサインインし、デプロイしたアプリケーションを使用します。 終わったら AWS リソースをクリーンアップするために pnpm nx destroy-sandbox infra を実行し、Amazon Cognito と Amazon S3 のリソースを AWS マネジメントコンソールから削除します（これらはデータ損失を防ぐためにデフォルトでは保持されます）。 フロー全体の詳しいウォークスルー（テキストベースのエージェンティックなゲームの例の構築を含む）は、 Dungeon Adventure チュートリアル をご覧ください。 お客様事例: Bingo Industries のマルチエージェントソリューション オーストラリアのリサイクル・廃棄物管理企業である Bingo Industries は、Nx Plugin for AWS を使ってマルチエージェントアプリケーションを構築し、本番環境に投入しました。彼らが構築したアーキテクチャは次のとおりです。 以下は、彼ら自身の言葉による、何を構築したかの説明です。 Bingo のオペレーション・物流部門は、ビジネスがスムーズに機能することを支える中心的な役割を担っています。この部門には、24 時間常時高い可用性を維持しつつ、効率的にスケールできる必要のある幅広いアプリケーションが含まれます。これらのアプリケーションは、アロケーター、カスタマーサービス担当者、コンタクトセンタースタッフ、オペレーター、アナリストなど、多様なユーザーグループによって利用されており、全員が日々の業務でこれらのツールに頼っています。関わる業務が複雑なため、ユーザーは複数の画面を行き来し、さまざまなフィルター・クエリ・検索を使いこなすことが多く、そのプロセスは時間がかかり煩雑になりがちです。こうした課題を軽減し効率を高めるため、私たちは複数のデータソースやログの情報を活用してユーザーからの問い合わせに応答する、マルチエージェント AI ソリューションを実装することにしました。 マルチエージェント AI ソリューションをゼロから開発するアプローチは数多くありましたが、私たちは時間とリソースの制約に直面していました。この制約を乗り越えるため、私たちは Nx Plugin for AWS を選びました。これはまだ使ったことのない方々に強くおすすめできるツールです。このツールは AWS ベースのアプリケーションのための、加速されたスキャフォールディングの発射台として機能し、AI エージェントを素早く立ち上げるために必要なアプリケーションコードとクラウドインフラストラクチャを、それらを取り囲む API やフロントエンドとともに生成します。 この土台の上に、私たちはユーザーからの問い合わせに回答し、説明を提供できるマルチエージェントのチャットボットを開発しました。ひとつの巨大なエージェントがすべてをこなそうとするのではなく、このソリューションは各質問を適切なスペシャリストエージェントにルーティングします。これにより各エージェントの焦点が絞られ、その回答の信頼性が保たれます。一方で、基盤となる AWS の生成 AI サービスが、全体を結びつける言語理解を提供します。 このアプローチの大きな利点は、AG-UI（リッチでインタラクティブなエージェントの応答をフロントエンドへ直接ストリーミングする）や A2A（エージェント同士が直接呼び出し合えるようにする）といったプロトコルを含む、成熟しつつある新しいスタンダードを、それらが成熟するにつれて素早く採用できたことです。私たちのチームは、セットアップ・認証・配線をゼロから考え出す必要がなく、その土台があらかじめ整った形で手に入り、代わりにビジネスロジックに集中できました。また、すべてを一から考える必要がなく、AWS 推奨のプラクティスと AWS Well-Architected Framework に沿った強力な出発点も得られました。最初の本番ローンチに到達するまで、3 週間弱でした。 たとえば、トランザクションが失敗したとき、チャットボットはよくある障害シナリオの中から考えられる原因の診断を手助けでき、オペレーターは複数のシステムをまたいで手作業で状況を組み立てるよりも速く解決へたどり着けます。さらにユーザーは、プロンプトベースのレポートをリアルタイムに生成でき、分析や情報に基づいた意思決定を促進します。このプロジェクトを通じて協力的に支援してくれた AWS チームに感謝します。 — Alex To（Principal Engineer）、Balaji Ravichandran（Head of Engineering）、Bingo Industries Alex は Nx Plugin for AWS に多大な貢献を還元してくれており、私たちは彼の尽力に大いに感謝しています。生成されたコードは彼らが自由に変更できるものであったため、Bingo Industries はそれらの変更を手元に留めておくこともできましたが、代わりにそれらをアップストリームに貢献してくれ、彼らの改善は v1.0 を形作ったものの一部になっています。 自分たちのジェネレーターで拡張する アップストリームへの貢献はひとつの道にすぎず、多くのチームが必要とする道でもありません。私たちはジェネレーターを SDK として公開しているので、自分たちのニーズに合わせて拡張・適応できます。あなたの組織独自のベストプラクティスのパターンや好みのフレームワークを、私たちが自分たちのものをエンコードしたのとまったく同じようにエンコードできます。これにより、あなたのエンジニアと彼らの AI アシスタントが、チームをまたいで、同じ決定的でレビュー済みの土台から構築できるようになります。 Nx Plugin ジェネレーター を使って自分のプラグインをスキャフォールディングし、自分のジェネレーターを作り、それを MCP サーバー経由で公開してください。 コミュニティに参加する Nx Plugin for AWS は Apache 2.0 ライセンスのもと GitHub で公開されており、私たちは貢献を歓迎します。質問・バグ・アイデアがあれば issue や discussion を開いてください。 最初のプルリクエストに取りかかるには、 ジェネレーター貢献のチュートリアル に従ってください。 すべてのジェネレーターのガイドを含むドキュメントは awslabs.github.io/nx-plugin-for-aws にあります。 また、 CDK.dev Slack の #nx-plugin-for-aws チャンネルで、これを使って構築している他の人たちと一緒に私たちを見つけられます。 私たちがこれを作ったのは、自分たちに必要だったからであり、オープンに作ったのは、これが解決する問題が私たちのチームだけのものではないからです。あなたが AWS 上で構築していて、同じ土台を何度も書いている自分に気づくなら、ジェネレーターをより良くするお手伝いをぜひお願いしたいです。 オープンソースの上に築かれている Nx Plugin for AWS は、多くのオープンソースコミュニティの成果の上に成り立っています。 Nx : Nx Plugin for AWS が構築されている、拡張可能なモノレポのビルドシステム tRPC : TypeScript でのエンドツーエンドの型安全な API FastAPI と Pydantic : API とエージェントのジェネレーターの背後にある Python の Web フレームワークとデータバリデーションライブラリ Smithy : API をモデリングするためのプロトコル非依存のインターフェイス定義言語 React : Web サイトジェネレーターの背後にある UI ライブラリ Vite と Rolldown : TypeScript の Web サイトとバックエンドのビルド・バンドル用 Shadcn と CloudScape : Web サイトジェネレーターが設定できる UX フレームワーク TanStack : Web サイトのルーティングと API 向けの型安全なフック CopilotKit と AG-UI プロトコル : エージェントフロントエンド向けのチャットインターフェイスとストリーミングプロトコル A2A と a2a-sdk : 生成されたエージェントが互いを発見し委譲できるようにする、エージェント間プロトコルと SDK Strands Agents SDK と LangChain : エージェントジェネレーターが使用するエージェントフレームワーク Model Context Protocol : AI アシスタントがジェネレーターを駆動できるようにするスタンダード AWS CDK と Terraform : ジェネレーターが対象とする 2 つの Infrastructure as Code の選択肢 AWS Lambda Powertools : 生成される API ハンドラーの可観測性のデフォルト Prisma 、 ElectroDB 、 SQLModel 、 Alembic 、 PynamoDB : データベースジェネレーターの ORM とエンティティモデリングのレイヤー GritQL : ジェネレーターとマイグレーションによる堅牢なコード編集を支える Biome : ワークスペース全体での TypeScript のリンティングとフォーマット用 uv 、 ty 、 Ruff : Python のパッケージ管理・型チェック・リンティング・フォーマット用 これらをメンテナンスしてくださっているすべての方々に感謝します。

2026 年 8 月 31 日週、 Claude Fable 5.1 が AWS で利用可能になりました 。Anthropic によると、Claude Fable 5.1 は、コーディング、科学研究、エンタープライズワークフローにわたる高度なタスクに、最新鋭のインテリジェンスを提供します。Claude Fable 5.1 は、作業が何時間にもわたって続き、多数のアプリケーションを横断的に使用する、長時間かつ重要度の高い作業向けに構築されています。ソフトウェアプロジェクトのより多くの部分を単独で担当でき、長時間のセッションを通じて、コードベース全体にわたる機能、コードレビュー、パフォーマンス関連の作業を扱うことができます。 Anthropic は、Fable 5.1 を 対象モデル に指定しています。対象モデルとは、提供先を問わず、追加のデータ保持、安全性レビュー、アクセスポリシーが適用される Claude モデルのカテゴリです。Claude Fable 5.1 は、新しい aws_review データ保持モード により、最大 30 日間のデータ保持と、Amazon 担当者が行う人的レビューの対象となります。このモードでは、AWS はお客様のプロンプトと出力内容を AWS の境界内で人的な安全性レビュー用に保持します。 provider_data_share モードはレガシーモードであり、Amazon Bedrock はモデルプロバイダーとデータを共有しません。加えて、AWS と Anthropic のパートナーシップにより構築された エンタープライズフロンティアセーフガード (EFS) により、対象となるお客様は、自分の管理するクラウド環境にデータを保持したまま、対象モデルを使用できます。 Claude Fable 5.1 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 Amazon Bedrock の Claude Fable 5.1 モデルカード と「 Claude Platform on AWS 」を参照してください。  8 月 31 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Linux 2027 (AL2027) がパブリックプレビュー中 : AL2027 は Amazon Linux オペレーティングシステムの次期バージョンです。カーネル 7.1 以降で動作し、パフォーマンス、スケール、セキュリティを念頭に置いて AWS 上のクラウドネイティブワークロード専用に構築されています。AL2023 のベースラインに基づいて構築された AL2027 は、ウェブアプリケーション、データベース、コンテナ化されたマイクロサービス、AI/ML ワークロード、および大規模インフラストラクチャを実行する、安全かつ安定した AWS ネイティブなオペレーティングシステムを必要とするお客様向けに設計されています。 Amazon EC2 R9g および R9gd のメモリ最適化インスタンス : これらのインスタンスは AWS Graviton5 プロセッサを使用しており、Amazon EC2 で実行されるメモリを大量に消費するワークロードに最適な料金パフォーマンスを提供します。R9g および R9gd インスタンスは、AWS Graviton4 ベースの R8g および R8gd インスタンスと比較して最大 25% 優れたコンピューティングパフォーマンスを提供します。データベースでは最大 30%、ウェブアプリケーションでは最大 35%、機械学習では最大 35% 高速になります。詳細については、 Daniel のブログ記事 をお読みください。 コンテナイメージ関数用 AWS Lambda SnapStart : Lambda SnapStart はオプトイン機能です。リソースをプロビジョニングしたり、複雑なパフォーマンス最適化を実装したりしなくても、応答性が高くスケーラブルなアプリケーションを簡単に構築できます。 これまで、SnapStart はマネージドランタイム (Python、.NET、Java) でのみサポートされていました。今後は、SnapStart をコンテナイメージに使用して、ML 推論やインタラクティブ API などの遅延の影響を受けやすいワークロードの起動時間を数秒から 1 秒未満に短縮できます。 AWS Agent Registry の一般提供開始 : AWS Agent Registry は、組織内のエージェント、ツール、スキル、MCP サーバー、およびカスタムリソース用に、管理されたプライベートなカタログおよび検出レイヤーを提供します。プレビューで導入された機能 (手動および URL ベースのレコード作成、承認ワークフロー、セマンティック検索、キーワード検索、AWS CloudTrail 監査証跡) に加えて、今回 Registry には新しいエンタープライズ向けの機能が追加されました。詳細については、 AI ブログの記事 をご覧ください。 Amazon Redshift が Apache Iceberg v3 テーブルのサポートを開始 : Amazon Redshift のデータレイクにある Apache Iceberg v3 テーブルからの読み取りと書き込みが可能になります。今回のリリースにより、Amazon Redshift にはデフォルトの列値、行系統、および削除ベクトルのサポートが導入されます。Amazon Redshift の Graviton ベースのプロビジョニングクラスターとサーバーレスクラスターは、新しい v3 フォーマットをサポートしています。詳細については、「 Redshift の Apache Iceberg v3 の機能 」をご覧ください。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 2026 年のガートナーマジッククアドラントの戦略的クラウドプラットフォームサービス部門で AWS がリーダーに選出 : ガートナー社は 2026 年のマジッククアドラントの戦略的クラウドプラットフォームサービス部門で AWS を 16 年連続でリーダーに認定し、実行能力の軸で再び AWS を最高ランクに位置付けました。この評価は、インフラストラクチャと AI からセキュリティ、運用に至るまで、最も広範で奥深いクラウド機能セットを提供するという当社の取り組みが反映されたものであると考えており、お客様には安心して構築、革新、スケールに取り組んでいただけます。 AWS Certified AI Business Strategist : この新しい認定は、組織内の AI イニシアチブを評価し、支持し、拡大する専門家を対象としています。これには、チーム全体で導入を推進する基幹業務リーダー、顧客に AI の価値をわかりやすく説明する営業担当者、実験から本稼働までのクライアント戦略を導くコンサルタント、AI への投資をビジネスの成果へと結びつけるプログラムマネージャーなどが挙げられます。ベータ試験の登録は 2026 年 9 月 1 日に開始され、試験の配信は 9 月 29 日から開始されます。 エージェントセキュリティ: マシンスピードでの検知と対応 : 私たちは、セキュリティは AI の導入後ではなく、その前に進化すべきだと考えています。この信念のもと、私たちのチームは SANS Institute と協力して、2026 年発行の Cloud Security Exchange eBook に新たな章を設けました。本章では、エンタープライズ規模でエージェントワークロードを保護するための実践的なフレームワークについて説明しています。また、評価、試験運用、大規模運用を問わず、エージェンティック AI 導入のあらゆる成熟段階にあるセキュリティチームに対して、具体的なアーキテクチャパターン、実装ガイダンス、フレームワークを提供し、エージェントワークロードの保護についてもさらに深く掘り下げています。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント ( AWS re:Invent 、 AWS Summit 、 AWS Community Day など) を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 9 月 7 日週のニュースは以上です。9 月 14 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。