「Deploy to AWS」と打つだけ——そんな未来が来た
AWSへのデプロイは、正直言って面倒くさい作業の連続です。
どのサービスを使うべきか調べて、コストを試算して、CloudFormationやCDKのコードを書いて、デプロイして——この一連の工程に何時間もかけた経験がある方は多いのではないでしょうか。特にAWSを使い始めたばかりの頃や、普段使わないサービスを選定するときは、公式ドキュメントと格闘するだけで疲弊してしまうこともあります。
そんな状況を大きく変えるかもしれない取り組みをAWSが発表しました。「Agent Plugins for AWS」——Claude CodeやCursorに組み込むことで、自然言語の指示だけでアーキテクチャ設計からデプロイまでを一気通貫で実行できるプラグイン群です。
実際にインストールして試してみたので、その仕組みと所感をご紹介します。
Agent Plugins for AWSとは何か
2026年3月、AWSはオープンソースリポジトリ「Agent Plugins for AWS」を公開しました。Claude CodeおよびCursorに対応しており、AWSデプロイに関連する専門知識をプラグインとしてパッケージ化したものです。
従来のAI開発では、LLMに対してAWSの設計指針を毎回プロンプトで渡す必要がありました。これは文脈の肥大化を招き、精度が安定しないという問題がありました。Agent Pluginsはこの課題を解決するアプローチとして、再利用可能でバージョン管理された「スキル」としてAWSの専門知識をエンコードします。
初回リリースに含まれるのは「deploy-on-aws」プラグイン。アプリケーションのコードを解析し、最適なAWSアーキテクチャを推奨し、コスト見積もりを提示し、IaCコードを生成し、デプロイを実行するまでの一連の流れを自動化します。
Cursorについては2026年2月17日にプラグインマーケットプレイスへの対応が発表されており、そちらからもインストール可能です。
4つのコンポーネント?プラグインの構造を理解する
Agent Plugins for AWSは単一の機能ではなく、複数の要素が組み合わさって動作します。
コンポーネント | 役割 |
|---|---|
Agent Skills | AWSのベストプラクティス・ワークフロー・コードレビュー・デプロイなどの手順をステップバイステップで定義。AIエージェントがこれを参照しながら作業を進める |
MCPサーバー | AWSの公式ドキュメント、リアルタイム価格情報、CloudFormationのベストプラクティスなどへの接続を提供。静的な知識ではなく動的な情報をAIが参照できる |
Hooks | ワークフローのトリガーや自動化、ガードレールとしての役割を担う。デプロイ前の検証チェックなどを自動実行できる |
References | AIが参照するドキュメント、設定情報、ナレッジベース。プラグインが賢く振る舞うための背景知識を提供する |
この構造が面白いのは、単なるプロンプトの詰め合わせではなく、外部のリアルタイム情報(MCPサーバー)と構造化されたワークフロー(Agent Skills)を組み合わせている点です。例えばコスト見積もりは、静的な知識ではなく、AWS Pricing MCPサーバーを通じて実際の最新価格データを参照して計算されます。
Model Context Protocol(MCP)はAnthropicが提唱した標準プロトコルで、AIモデルが外部ツールやデータソースと通信するための共通インターフェースです。Agent Plugins for AWSはこのMCPを活用することで、LLMの文脈にAWSの最新情報をリアルタイムで注入することができます。
実際にインストールしてみた
Claude Codeへのインストールはシンプルです。まずプラグインマーケットプレイスを追加し、次にdeploy-on-awsプラグインをインストールします。
# マーケットプレイスの追加
/plugin marketplace add awslabs/agent-plugins
# deploy-on-awsプラグインのインストール
/plugin install deploy-on-aws@awslabs-agent-plugins実際に実行するとこんな感じの出力が出てきます。
❯ /plugin marketplace add awslabs/agent-plugins
Fetching plugin registry from awslabs/agent-plugins...
✓ Marketplace registered successfully
Available plugins: deploy-on-aws, security-review (2 found)
❯ /plugin install deploy-on-aws@awslabs-agent-plugins
Resolving plugin manifest...
Loading Agent Skills:
✓ analyze-codebase
✓ recommend-architecture
✓ generate-iac
✓ deploy-to-aws
Connecting MCP servers:
✓ aws-knowledge-mcp-server (connected)
✓ aws-pricing-mcp-server (connected)
✓ aws-iac-mcp-server (connected)
Registering hooks... ✓
✓ deploy-on-aws installed successfully.
Tip: Open a project and type "Deploy this app to AWS" to get started.MCPサーバーへの接続が3つ同時に設定されるのが分かります。インストール自体は10秒もかかりませんでした。なお、MCPサーバーはインストール時に接続テストが走るため、aws configureでAWS CLIの認証設定が済んでいないとwarningが出ます(インストール自体は完了します)。
インストール後、Claude Codeの内部にAgent Skillsが組み込まれた状態になります。プラグインは以下のような自然言語フレーズに反応してスキルを発動させます。
フレーズ例 | 発動するスキル |
|---|---|
Deploy to AWS / Deploy this app to AWS | アーキテクチャ提案→コスト見積もり→IaC生成→デプロイの全フロー |
AWS architecture for this app | アーキテクチャ設計のみ(デプロイなし) |
Estimate AWS cost | コスト見積もりのみ |
Generate infrastructure | IaCコード(CDK/CloudFormation)の生成のみ |
Host on AWS / Run this on AWS | 全フローのトリガー |
プラグインのインストール自体はすぐに完了します。MCPサーバーとの接続には、事前にAWS CLIの認証情報(適切な権限を持つIAMロールまたはユーザー)が設定されている必要がある点は覚えておいてください。

deploy-on-awsプラグインの動作フロー!5ステップで完結
AWSが示している例では、Express.js + PostgreSQL + Reactのフルスタックアプリケーションを使ったデモシナリオが紹介されています。「Deploy this Express app to AWS」と入力するだけで、以下の5ステップが自動的に実行されます。

Step 1: Analyze(コードベース解析)
エージェントがコードベース全体をスキャンします。使用しているフレームワーク(Node.js 20.x)、データベース依存関係(PostgreSQL)、静的ファイルの場所(/publicディレクトリのReactビルド)、環境変数の使い方、想定トラフィック(1日約1000リクエスト)などを把握します。
既存のAWS環境へのアップデートであれば、稼働中のシステム負荷なども確認した上で提案内容を調整します。
Step 2: Recommend(AWSサービス推奨)
解析結果に基づいて、最適なAWSサービス構成を推奨します。
レイヤー | 推奨サービス | 選定理由 |
|---|---|---|
バックエンド | AWS App Runner | 自動スケーリング、マネージドコンテナ、運用コスト最小化 |
データベース | Amazon RDS PostgreSQL | マネージド、自動バックアップ、Multi-AZ対応 |
フロントエンド | CloudFront + S3 | グローバルCDNで低レイテンシ、静的ホスティングとして最安 |
認証情報管理 | AWS Secrets Manager | DBクレデンシャルの安全な管理、ローテーション自動化 |
Step 3: Estimate(コスト見積もり)
AWS Pricing MCPサーバーを通じてリアルタイムの価格データを参照し、想定される月額料金の見積もりを提示します。デプロイを実行する前にコストを把握できるのは、特に実務ではありがたい機能です。「思ったより高かった」という事態を事前に防げます。
Step 4: Generate(IaCコード生成)
見積もりを確認してデプロイを承認すると、以下のファイル群が自動生成されます。
生成ファイル | 内容 |
|---|---|
AWS CDK(TypeScript) | App Runner、RDS、CloudFront、Secrets Managerを定義したインフラコード |
Dockerfile | Expressアプリのコンテナ定義 |
DBマイグレーションスクリプト | PostgreSQLのスキーマ移行 |
環境設定ファイル | 本番環境向けの設定値 |
GitHub Actions workflow | CI/CDパイプライン定義 |
生成されたCDKコードのクオリティが気になるところです。実務利用を想定するなら、セキュリティグループの設定、VPCの設計、タグ戦略など、細かい部分でどれだけ最適化されたコードが出てくるかが重要になります。ここは実際にコードを精査してみたいと思っています。
Step 5: Deploy(デプロイ実行)
生成されたコードを確認・承認後、実際のデプロイが実行されます。
- AWS各サービスのプロビジョニング(CDK経由)
- コンテナのビルドとApp Runnerへのデプロイ
- RDSデータベースの作成とマイグレーション実行
- ReactビルドのS3アップロードとCloudFront設定
- クレデンシャルのSecrets Manager保存
デプロイ完了後、アプリケーションのURL、CloudWatchダッシュボードのリンク、コスト追跡の設定情報などが出力されます。AWSは「数時間かかっていた作業が10分以内に完了した」と紹介しています。
3つのMCPサーバーがリアルタイム情報を提供する
deploy-on-awsプラグインが使用するMCPサーバーは3種類あります。それぞれが異なる種類の情報を提供し、エージェントの判断精度を高めます。
MCPサーバー | 提供する情報 | GitHubリポジトリ |
|---|---|---|
AWS Knowledge | AWSの公式ドキュメント、アーキテクチャガイド、Well-Architectedフレームワークのベストプラクティス | |
AWS Pricing | 各サービスのリアルタイム料金データ。コスト見積もりの根拠となる | |
AWS IaC | AWS CDKおよびCloudFormationのベストプラクティス、推奨パターン |
MCPの仕組みを簡単に説明すると、LLMが直接インターネットにアクセスするのではなく、MCPサーバーという中間レイヤーを通じて外部情報を取得します。このアーキテクチャにより、情報の取得元と取得方法を制御しやすくなり、セキュリティ上のリスクを低減できます。
AWSのMCPサーバー群(awslabs/mcp)はAgent Pluginsとは独立したリポジトリで管理されており、プラグインを使わずに単体で利用することも可能です。例えば、既存のAI開発環境に「AWSの価格情報を参照できるツール」として組み込むといった使い方もできます。
本番デプロイは慎重に——今後試したいこと
今回、プラグインのインストールと基本的な動作確認までは試すことができました。ただし、実際にAWSにリソースをデプロイするフロー(Step 3以降)については、AWSアカウントの費用と権限管理の観点から本番環境での検証は行っていません。
今後、実際に試してみたいと思っていることをまとめておきます。
検証項目 | 確認したいこと |
|---|---|
サンプルアプリでのデプロイフロー | 5ステップの実際の動作速度と、各ステップでのエージェントの振る舞い |
コスト見積もりの精度 | Pricing MCPサーバーが返す見積もりと実際の請求額の乖離 |
生成CDKコードの品質 | セキュリティグループ、VPC設計、タグ戦略など実務要件への対応度 |
複数環境への展開 | dev / staging / prod の環境分離がどこまで自動化されるか |
既存システムへの適用 | 新規デプロイではなく既存構成の変更提案の品質 |
特に「生成されるCDKコードの品質」は実務上の関心が高いポイントです。自動生成コードをそのまま本番に使えるレベルなのか、それとも大幅な手直しが必要なのか——この点は実際に動かして確認しないとわかりません。RagateではAWSのSI案件を多数手がけているため、近いうちに検証環境で試してみる予定です。
使う上での注意事項とベストプラクティス
AWSも公式に注意事項を示しています。AI生成のインフラコードをそのまま使うことへの過信は禁物です。
注意事項 | 具体的なアクション |
|---|---|
コードレビューは必須 | デプロイ前に生成コードを確認。セキュリティ・コスト・耐障害性の観点でレビューする |
最小権限の原則 | AWS認証情報は必要最低限の権限のみ付与。広範なAdministratorAccessは避ける |
セキュリティスキャン | 生成されたIaCコードに対してCheckovやSteampipeなどのセキュリティスキャンを実施 |
プラグインの定期更新 | AWSのベストプラクティスは変化するため、プラグインを最新の状態に保つ |
開発者判断は不可欠 | プラグインはあくまで加速ツール。最終的な設計判断は人間が行う |
特に権限管理は重要です。「Deploy to AWS」という一言でデプロイが実行できるということは、裏返せば誤ったプロンプトや意図しない操作でリソースが作成されるリスクもあります。本番環境で使う場合は、CDKのchangesetを確認してから実行するなど、承認ステップを挟む運用を推奨します。
まとめ、AI駆動開発の新しいフロンティア
Agent Plugins for AWSが示す方向性は明確です。「専門知識をプラグイン化することで、AIエージェントを特定ドメインの専門家として機能させる」というアプローチです。
今回のdeploy-on-awsプラグインはその第一弾に過ぎず、AWSは今後も追加プラグインをリリースしていくと予告しています。セキュリティ診断、コスト最適化、既存アーキテクチャのレビューなど、様々なAWSワークフローがプラグイン化されていく可能性があります。
Ragateとしても、AWS案件でのAI活用を積極的に進めていく立場から、このプラグインエコシステムの動向は注視しています。「アーキテクチャ設計の叩き台を30秒で作る」「コスト見積もりをその場でFeel」といった使い方から始め、徐々に本番ワークフローへの組み込みを検討していきたいと思っています。
まずはプラグインをインストールして、開発環境のサンドボックスで動作を確認するところから始めてみてください。Claude CodeやCursorをすでに使っている方なら、インストールは数秒で完了します。















