Nx Plugin for AWSは、AWSが2026年9月8日にv1.0.0を公開した、Nx向けのオープンソースのプラグインです。API・Webサイト・認証・AIエージェントのコードと、それを動かすAWS CDKまたはTerraformのインフラを、コマンド1行ずつで生成できる仕組みです。この記事では、生成される範囲、ワークスペース作成からsandbox環境へのデプロイまでのコマンド、AIアシスタントから呼ぶMCPサーバーの設定を整理したうえで、生成されたコードを本番に出す前に確かめる項目と、採用・見送りの条件を公式ドキュメントに基づいて解説します。Nx本体の仕組みや他のモノレポツールとの比較は、Nx monorepoの機能と導入手順を解説した記事で扱っています。
まとめ：Nx Plugin for AWSで生成できる範囲と本番投入の線引き
Nx Plugin for AWSは「AWS上のアプリの初期構成を、毎回同じ形で生成する道具」です。生成物はReact・tRPC・FastAPI・CDKなどの素のコードで、プラグインは実行時の依存になりません。生成後は普通のコードとして自分たちで持つことになります。
手元で動かすまでは数コマンドで済みます。本番の前に必ず見るのは4点です。Checkovの既定の抑制ルール、sandbox用のexpressモードのままCIに載せていないか、削除保護や後片付けで残る資源、そしてnx migrateが追従しない変更の範囲。新規のPoCやAIエージェント付きの業務アプリには向き、既存のCDK資産が厚い組織が丸ごと乗り換える用途には向きません。
Nx Plugin for AWSの位置づけとv1.0.0で固まったジェネレーターの範囲
最初に、このプラグインが何を生成し、どこから先が利用者の責任になるのかを押さえます。
NxのジェネレーターでAPI・Webサイト・インフラをまとめて生成する仕組み
AWSの2026年9月8日の発表によると、このプラグインはモノレポ向けのビルドシステムNxを拡張し、ジェネレーターごとにアプリの一部とそれを動かすインフラを生成します。対象はAPI、Webサイト、データベース、Amazon Bedrock AgentCore上のAIエージェントとMCPサーバーです。インフラはCDKのコンストラクトかTerraformのモジュールから選び、AWS WAF、CloudWatchへのアクセスログ、X-Rayのトレースが初めから組み込まれます。ライセンスはApache 2.0で、プラグイン自体の料金はかかりません。
公式のConceptsページは、生成されたコードはすべて利用者のコードで、プラグインは実行時の依存ではないと明記しています。WebサイトとAPIを接続すると型が共有され、APIの契約を変えるとフロントエンドのビルドが止まる仕組みです。型共有の土台になるtRPC自体は、tRPCの型安全なAPI実装を解説した記事で確認できます。
2026年9月8日のv1.0.0で入った冪等化・Terraform対応・init
v1.0.0のリリース記事で挙げられた変更は、実務への影響が大きい順に次のとおりです。
- ジェネレーターの冪等化：再実行しても既存のコードを上書きしない
initジェネレーター：既存のNxリポジトリやNx以外のリポジトリへ後から導入できる- Terraform対応、DynamoDB・リレーショナルDB・AgentCore Gatewayのジェネレーター追加
- WAF、Cognitoの脅威保護、CSPの強制、APIアクセスログ、イメージスキャンの追加
- Nx 23.2・ESM・Biomeへの移行と、ローカル開発用の単一の
devターゲット
2026年10月10日時点のnpmの最新は1.0.6系で、npmレジストリのメタデータではnxを23.2.1の完全一致でpeer依存に指定しています。Nx本体だけを先に上げると食い違うため、更新は後述のnx migrateでまとめて行います。
generators.jsonに並ぶジェネレーターと言語・IaCの対応表
GitHubのgenerators.jsonには、2026年10月10日時点のmainブランチで74件が登録されています。内部のテスト用や接続用の派生を含む数なので、主要なものに絞ると次の表になります。
| 用途 | TypeScript | Python |
|---|---|---|
| API | ts#trpc-api・ts#smithy-api | py#fast-api |
| Webサイト | ts#react-website | なし |
| AIエージェント | ts#agent | py#agent |
| MCPサーバー | ts#mcp-server | py#mcp-server |
| データベース | ts#dynamodb・ts#rdb | py#dynamodb・py#rdb |
| インフラ | ts#infra（CDK） | terraform#project |
表の右下のTerraformは言語ではなくIaCの選択肢で、ワークスペース作成時にCDKかTerraformかを選びます。プロジェクト同士はconnectionジェネレーターでつなぎ、何と何を接続するかで生成される型付きクライアントが変わります。
ワークスペース作成からsandboxへのデプロイまでのCDK検証手順
ここからは公式のクイックスタートに沿って、pnpm create @aws/nx-workspaceによるワークスペース作成から、tRPCのAPIとReactのWebサイトをCDKでデプロイするまでを追います。
Node.js 22・uv・pnpmなど前提ツールの確認とワークスペースの作成
必須はGit、Node.js 22以上、uv 0.5.29以上（Python 3.14を入れる）の3つです。npmのメタデータではnode>=20.19.0ですが、ドキュメントの22以上に合わせます。pnpm 11以上が推奨で、ジェネレーターによってはDockerかFinch 1.6.0以上、Terraformを選ぶなら1.12以上が要ります。
# 前提ツールの版を確かめる
node --version
pnpm --version
uv python install 3.14
# ワークスペースを作る（途中でCDKかTerraformかを選ぶ）
pnpm create @aws/nx-workspace my-project
cd my-project作成したワークスペースには、AIアシスタント向けのMCP設定まで入っています。この点は後の章で触れます。
tRPCのAPI・Reactサイト・Cognito認証を生成して接続するコマンド
APIとWebサイトを生成し、Webサイトに認証を足してから、両者を接続します。--dry-runを付けると、書き込まずに生成されるファイルの一覧だけを確認できます。
pnpm nx g @aws/nx-plugin:ts#api demo-api --framework=trpc --no-interactive
pnpm nx g @aws/nx-plugin:ts#website demo-website --no-interactive
pnpm nx g @aws/nx-plugin:ts#website#auth --project=demo-website --no-interactive
pnpm nx g @aws/nx-plugin:connection --sourceProject=demo-website --targetProject=demo-api --no-interactive
# CDKのインフラプロジェクトを作る
pnpm nx g @aws/nx-plugin:ts#infra infra --no-interactive
# ローカルで起動する（http://localhost:4200）
pnpm dev認証はAmazon Cognitoのユーザープールで、Webサイトの生成とは別のジェネレーターです。生成直後のインフラにはAPIとWebサイトがまだ載っていないため、packages/infra/src/stacks/application-stack.tsにUserIdentity・DemoApi・DemoWebsiteの3つを書き足します。
CDKのdeploy-sandboxによる検証手順とus-east-1の扱い
デプロイの前に、対象のアカウントとリージョンでCDKのブートストラップが要ります。CloudFrontの前に置くWAFのWebACLはus-east-1に作られるため、東京リージョンへ出す場合もus-east-1を合わせてブートストラップする点が落とし穴です。
pnpm build
pnpm nx bootstrap infra
# デプロイ先が東京でも、WebACL用にus-east-1をブートストラップする
pnpm nx run infra:bootstrap --args="aws://123456789012/us-east-1"
pnpm nx deploy-sandbox infraブートストラップが作るIAMロールと、そのテンプレートの版の更新は、cdk bootstrapが作る5つのIAMロールを解説した記事にまとめています。CDKのスタックやコンストラクトの考え方から確かめたい場合は、AWS CDKの仕組みとTerraformとの違いを解説した記事が前提になります。
AIアシスタントからMCPサーバー経由でジェネレーターを呼ぶ設定と役割分担
このプラグインは、AIアシスタントにアプリを組ませる使い方を前面に出しています。設定は1か所で済みます。
@aws/nx-plugin-mcpの設定例とプリセットに含まれるプロジェクト設定
公式のBuilding with AIページが示すMCPサーバーの設定は次のとおりです。
{
"mcpServers": {
"nx-plugin-for-aws": {
"command": "npx",
"args": ["-y", "@aws/nx-plugin-mcp"]
}
}
}プリセットで作ったワークスペースには、Claude Code、Cursor、Kiro、Gemini CLI、GitHub Copilot、OpenAI Codex向けのプロジェクト単位のMCP設定が最初から入っています。グローバルに設定が要るのは、AIに新しいワークスペース自体を作らせる場合と、既存のリポジトリへ後から足す場合だけです。ENOENT npxで起動しないときは、commandをnpxのフルパスに置き換えます。
AIにインフラを書かせず決定的なジェネレーターに任せる分担の意味
AWS Open Source Blogの紹介記事は、AIがアプリを数分で立ち上げられても、実際の顧客に出せる品質に持っていくのが依然として難しい点だと書いています。そこでAIはインフラを一から書かず、毎回同じ結果を返すジェネレーターを呼び、アプリ固有のロジックに集中させるという分担です。
レビューする側から見ると、この分担には利点があります。AIが書いた部分と、ジェネレーターが書いた部分を分けて読めるからです。生成直後にコミットしておけば、以降の差分がAIや人の書き足した部分になります。同記事のBingo Industriesの事例は、マルチエージェントのチャットボットを3週間弱で初期の本番公開まで進めたという同社の自己申告で、規模の比較には使えません。
生成されたコードを本番前にレビューするときの設定の確認項目と順番
生成物はベストプラクティスに沿った初期値ですが、本番の要件を満たしているかは別の問題です。上から順に確かめます。
checkov.ymlの既定の抑制ルールとCheckovの実行結果の読み直し
CDKインフラのガイドによると、生成されたインフラにはCheckovのセキュリティ検査が組み込まれています。ただしcheckov.ymlでは一部のルールが既定で抑制されており、ガイド自身が用途に合わせて見直すよう勧めています。
# Checkovはuvx経由で動くため、uvが入っている必要がある
pnpm nx checkov infra
# 結果は dist/packages/infra/checkov に出力される見るべきは「失敗したルール」より「抑制されているルール」です。抑制にはsuppressRules(construct, ['CKV_AWS_XXX'], 'Reason')で理由を残す仕組みがあるので、理由の書かれていない抑制や、本番のデータを扱うバケット・テーブルに掛かった抑制を一件ずつ外せるか判断します。
sandboxのexpressモードとdeploy-ciへの切り替え・ステージの分割
同じガイドには、deploy-sandboxは既定でCloudFormationのexpressモードを使い、資源の設定が当たった時点で完了を返すと書かれています。反復の開発には速い一方、CI/CDや本番には向かないと明記されています。
| 場面 | 使うターゲット | 安定化の待機 |
|---|---|---|
| 個人の検証 | deploy-sandbox | 待たない（express） |
| 手動で任意のステージ | deploy | 待つ |
| CI/CDのパイプライン | deploy-ci | 待つ |
本番用のbetaやprodは、src/main.tsにApplicationStageを足し、ステージごとにアカウントとリージョンを指定して分けます。パイプラインでは開発用のassembleではなくbuildを通し、合成済みのcloud assemblyをdeploy-ciで各段に流します。sandboxと同じ手順のまま本番アカウントへ出している構成は、ここで見直す対象です。
Cognitoの削除保護やbootstrap-destroyなど後片付けで残る資源
検証環境を消すときに資源が残る箇所が、クイックスタートとガイドに散らばっています。Cognitoのユーザープールは削除保護が有効なので、destroy-sandboxのあとに手で消す作業が必要です。ステージ全体を消すときはinfra-sandbox/**と書き、/*だとus-east-1のWebACL用の入れ子スタックが漏れます。
逆に、本番では消えてはいけない資源についても、同じ場所での確認が必要です。Terraformを選んだ場合のbootstrap-destroyは状態ファイルのバケットごと消すため、運用手順書に載せるなら「全インフラを消したあとだけ」という条件を書き添えます。削除保護の有無はデータを持つ資源ごとに一覧にしておくと、レビューの漏れが減ります。
nx migrateでの追従と、手を入れたファイルが更新されない前提
生成後の改善は、公式のアップグレード手順で取り込みます。
pnpm nx migrate @aws/nx-plugin@latest
# package.json の変更を確かめてから入れる
pnpm install
pnpm nx migrate --run-migrations
pnpm build
# 確認できたら migrations.json を消してコミットするただし、移行は生成時の形から大きく外れていないファイルだけをパターンで書き換えます。手を入れたファイルは更新されず、手作業での対応が必要なものとして報告される仕組みです。デプロイ済みの資源を壊しうるインフラの変更には移行が用意されず、実験的と書かれたジェネレーターは移行なしに変わることもあります。手作業分はtools/ai-migrations/にAI向けのプロンプトとして置かれるので、適用後の差分も人が読みます。Nxのnpmパッケージは2025年8月にs1ngularityと呼ばれる改ざんを受けた経緯があり、s1ngularityの影響範囲と確認手順を解説した記事のとおり、版の固定とロックファイルの差分確認は省かないでください。
Nx Plugin for AWSを採用する条件と見送る場面の判断基準
結論として、ゼロから立ち上げるAWSのアプリでは採用してよく、既存の資産が厚い環境へ後から持ち込む用途では見送ります。
新規のPoCやAIエージェント付き業務アプリで採用してよい条件
採用してよいのは、新規のリポジトリで、TypeScriptかPythonを使い、CloudFront・API Gateway・Lambda・Cognitoを中心とした構成で足りる場合です。AgentCore上のエージェントやMCPサーバーを含むアプリでは、型付きの接続まで生成される分だけ手書きより早く形になります。AgentCoreの本番デプロイの詳細はAgentCoreのSDKとCLIでのデプロイ手順を解説した記事を参照してください。
条件がもう1つあります。生成されたコードを自分たちで読み、直し続けられる体制があることです。プラグインは初期構成を配るだけで、以降の保守はしてくれません。
既存のCDK資産やマルチアカウント運用がある組織で見送る場面
見送るのは、自社のCDKコンストラクト集やTerraformのモジュール群が既に整っている組織です。initで既存リポジトリへ入れることはできますが、生成されるコンストラクトと社内の標準が二重になり、どちらに合わせるかの議論から始まります。ESMやBiomeへの移行も同時に求められるため、既存のビルド設定との衝突も確認すべき問題です。AWS公式の別系統の道具と比べたい場合は、AWS Blocksの特徴とCDKとの違いを解説した記事も判断材料になります。
本番のアカウント設計、ステージの切り方、Checkovの抑制の見直しまで含めて新規アプリを立ち上げる場合は、AWSのインフラ構築支援に相談すると、生成物をそのまま使える範囲と作り直す範囲の線引きから見積もりの前提がそろいます。
よくある質問
Nx Plugin for AWSについて出やすい疑問を、公式ドキュメントとAWSの発表に基づいて整理します。
Nx Plugin for AWSは無料で使えますか？
プラグイン自体はApache 2.0ライセンスのオープンソースで、追加料金はかかりません。費用が発生するのは、生成したアプリがデプロイしたAWSの資源です。sandboxでもCloudFront、WAF、Cognito、Lambdaなどが作られるため、検証が終わったらdestroy-sandboxで消し、Cognitoのユーザープールは削除保護を外して手で消します。
Nx Plugin for AWSとAWS CDKの違いは何ですか？
CDKはインフラをコードで定義するためのフレームワークで、Nx Plugin for AWSはそのCDK（またはTerraform）のコードと、API・Webサイト・エージェントのアプリコードをまとめて生成する道具です。生成後のインフラは普通のCDKのコードなので、CDKの知識が無いと保守できません。役割は競合ではなく、生成元と生成物の関係です。
既存のリポジトリにNx Plugin for AWSを追加できますか？
できます。v1.0.0で入ったinitジェネレーターで、既存のNxワークスペースにも、Nxを使っていないリポジトリにも追加できます。ただしNx 23.2系やESMを前提にしているため、既存のビルド設定との衝突を確かめる時間を見込んでください。社内のCDK標準がある場合は、生成物との二重管理になります。
Terraformを選んだ場合も同じジェネレーターを使えますか？
v1.0.0で複数のジェネレーターがTerraformに対応し、ワークスペース作成時にCDKかTerraformかを選びます。インフラのプロジェクトはterraform#projectで作り、初回はpnpm nx bootstrap infraで状態ファイル用のS3バケットを作ります。デプロイはpnpm nx apply infraで、Terraformは1.12以上が推奨です。
生成されたコードはそのまま本番に使えますか？
そのままは勧めません。WAFやアクセスログなどの初期値は入っていますが、checkov.ymlの既定の抑制、sandbox用のexpressモード、ステージとアカウントの分割、削除保護の有無は、本番の要件に合わせて自分たちで確かめる部分です。公式の紹介記事も、本番品質への到達は依然として難しい点だとしています。
関連記事
- Nx monorepoとは｜2026年の機能・比較・導入手順と運用の落とし穴：プラグインの土台になるNx本体の機能と、他のモノレポツールとの比較を扱った記事
- AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い：生成されるインフラのコードを読むための前提知識をまとめた記事
- AWS Blocksとは？Blockの一覧・ローカル開発・CDKとの違いと採用判断：AWS公式の別系統の開発ツールを、採用判断の観点から整理した記事
- Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】：生成したエージェントのデプロイ先になるAgentCoreの使い方の記事
- 脆弱性「s1ngularity」とは？Nxを狙ったAI CLI悪用のサプライチェーン攻撃とCVE-2025-10894の確認・対応手順：Nxのnpmパッケージ改ざんの経緯と、依存の版を固定する理由の記事
