Claude CodeでDeploy on AWSプラグインを使う — 構成提案から見積もり・IaCデプロイまで
AWS提供のDeploy on AWSプラグインを入れ、コードの分析から構成提案、月額見積もり、CDK/CloudFormation生成、承認付きデプロイまで進める手順と、既定の選び方・安全確認・兄弟プラグインとの切り分けをまとめます。
Deploy on AWSは、Amazon Web Servicesが配布するClaude Code用プラグインです。「AWSにデプロイして」と頼むと、コードベースを分析し、AWSのサービスを選び、月額コストを示し、IaC(Infrastructure as Code)を書き、確認を取ってからデプロイするところまで案内します。
導入は2行のコマンドで済みます。難しいのは入れた後で、何が既定で選ばれ、どこで承認を挟み、どこまで任せてよいかを把握しておく必要があります。この記事では導入手順から既定の選定ルール、安全確認、同じリポジトリの別プラグインとの使い分けまでを扱います。
Deploy on AWSプラグインは何を肩代わりするのか
プラグインの中身は「deploy」スキルと、3つのMCPサーバーです。スキルは「コードをAWSに載せる」という作業を5段階の手順としてClaudeに与えます。
deployスキルが進める5段階
- 1
Analyze(分析)
コードベースを走査し、フレームワーク、データベース、依存関係を読み取ります。
- 2
Recommend(推奨)
使うAWSサービスを選び、理由を簡潔に添えます。
- 3
Estimate(見積もり)
先に月額コストを見せます。IaCを書く前に出すのが決まりです。
- 4
Generate(生成)
CDKまたはCloudFormationを書きます。セキュリティの既定値を適用します。
- 5
Deploy(実行)
セキュリティチェックを通したうえで、ユーザーの確認を取って実行します。
見積もりがコード生成より前に来る点が設計の核です。金額を見てから構成を直せるので、デプロイ後に請求を見て驚く順序を避けられます。
プラグインにはもう1つ、aws-architecture-diagram スキルも入っています。AWS公式アイコン付きの構成図をdraw.ioのXMLとして生成するもので、デプロイとは独立して「構成図を作って」と頼めます。この図のために、ファイルを編集・書き込みした後に検証スクリプトを走らせるフック(PostToolUse)も同梱されています。
マーケットプレイスのページによると、デプロイ用の既定はdevサイズです。本番向けの冗長構成(マルチAZなど)が欲しいときは、依頼文に「production-ready」と書きます。
導入手順 — マーケットプレイス追加からプラグイン有効化まで
Deploy on AWSはClaude Codeの公式マーケットプレイスではなく、AWSの agent-plugins リポジトリが持つ独自のマーケットプレイスから入れます。そのため、先にマーケットプレイスの登録が必要です。
前提を確かめる
リポジトリのREADMEは、要件として次の2点を挙げています。
- Claude Code 2.1.29以上
- 適切な認証情報で設定したAWS CLI
deploy-on-awsプラグイン自身のREADMEには、図の検証に使うPython 3.9以上と defusedxml(pip3 install defusedxml>=0.7.1)も前提として載っています。draw.ioデスクトップはPNG・SVG・PDFに書き出すときだけ必要で、任意です。構成図を使わないなら、実質はClaude CodeとAWS CLIの用意だけで足ります。
あわせて、MCPサーバーのうち2つは uvx で起動する設定です。手元にuvが無いと起動に失敗するので、先に入れておくと詰まりにくくなります。
2つのコマンドで入れる
/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-aws1行目で agent-plugins-for-aws というマーケットプレイスを登録し、2行目でその中の deploy-on-aws を入れます。Claude Codeのドキュメントによれば、セッション内の /plugin install はすぐには入れず、/plugin パネルでそのプラグインの詳細を開き、スコープを選んでから確定する流れです。
インストール後に「Reload needed」と出たら /reload-plugins で反映します。シェルから入れるなら claude plugin install deploy-on-aws@agent-plugins-for-aws が使えます。チームで共有したいときは、スコープをプロジェクトにして .claude/settings.json に記録する方法もあります。ただし設定を共有しても、各メンバーの手元でのインストールは別途必要です。詳しくはプラグインのマーケットプレイス運用ガイドとreload-pluginsコマンドの解説にあります。
動いているかを確認する
/plugin のパネルでdeploy-on-awsが有効になっていることを確かめます。同梱のMCPサーバーの役割は後述します。
一言から始めて、承認で止める使い方
deployスキルは自然文で起動します。READMEとスキル定義が挙げるトリガーは次の6つです。
| トリガー語 | 想定する依頼 |
|---|---|
| deploy to AWS | 想定する依頼AWSへのデプロイ全体 |
| host on AWS | 想定する依頼公開用ホスティング |
| run this on AWS | 想定する依頼既存コードのAWS実行 |
| AWS architecture | 想定する依頼構成の提案 |
| estimate AWS cost | 想定する依頼費用見積もり |
| generate infrastructure | 想定する依頼IaCの生成 |
トリガー語は英語で列挙されています。日本語で頼んでスキルが起動しないときは、「deploy to AWS」のように英語を一言添えてみてください。インストール直後に「Reload needed」の表示が残っているなら、/reload-plugins も試します。
見積もりだけ先に欲しいとき
「このプロジェクトをAWSに載せたら月いくらか」だけを知りたい場面もあります。そのときは見積もりの依頼に絞ります。
このリポジトリを AWS に載せた場合の構成と月額の見積もりだけ出して。
IaC の生成とデプロイはまだ実行しないで。estimate AWS costスキルは「見積もりをIaCの前に出す」原則を持つので、依頼文で止める位置を明示すれば、分析・推奨・見積もりまでで手を止めやすくなります。これは依頼文での制御であって、実行を技術的に禁じる仕組みではありません。確実に止めたいときは次の節の権限設定を併用してください。
本番向けにしたいとき
依頼文に「production-ready」を入れると、devサイズの最小構成ではなく、マルチAZなどの冗長構成が選ばれます。スキル定義には、ステートフルなサービスをマルチAZにする、VPCフローログやALBのアクセスログを有効にする、パブリック向けWebアプリにはAWS WAFを付ける、といった本番向けの追加項目が列挙されています。GuardDutyは「推奨するが自動では有効にしない」扱いです。
何が既定で選ばれるのか
迷ったときの最大の手がかりは、スキルが持つ既定表です。「LambdaとFargateのどちらにするか」のような問いは、スキルが自分で決める設計になっています。
| アプリの種類 | 既定の選択 | 上書きの合図 |
|---|---|---|
| Django・Rails・Express・FastAPIなどのWebアプリ | 既定の選択Fargate + ALB | 上書きの合図「serverless」でLambda + API Gateway |
| 静的サイト・SPA | 既定の選択Amplify Hosting | 上書きの合図「S3」でS3 + CloudFront |
| バックグラウンドワーカー | 既定の選択Fargate | 上書きの合図15分未満の短いタスクはLambda |
| 定期ジョブ | 既定の選択EventBridge + Lambda | 上書きの合図長時間ならEventBridge + Fargate |
| PostgreSQL・MySQL | 既定の選択Aurora Serverless v2 | 上書きの合図「simple RDS」でRDS |
| NoSQL | 既定の選択DynamoDB | 上書きの合図なし |
IaCの既定はCDK(TypeScript)です。ただし、リポジトリに cdk.json や terraform/ が既にあれば、既存の選択に合わせると書かれています。依頼文に「terraform」「cloudformation」「sam」と入れれば切り替わります。
WebフレームワークがLambdaではなくFargateになる理由は、DjangoやRailsのように長時間動くプロセスを前提にしたフレームワークは、Lambdaだとアダプターが要り、コールドスタートの遅延も出るからだと説明されています。
一方で、AWS App Runnerは新規構成に勧めない扱いです。スキル定義はApp Runnerを「メンテナンスモード」とし、代わりにECS Express Modeを使うよう指示しています。Heroku・Render・Railwayから移すアプリや「managed platform」を求められた場合は、Elastic Beanstalkに回します。
3つのMCPサーバーの役割分担
プラグインに同梱されるMCPサーバーは、判断の根拠をどこから持ってくるかを分けています。
同梱されるMCPサーバー
awsknowledge
AWSのドキュメントとアーキテクチャのガイダンス。サービス選定が用途に合うかの検証に使います。HTTP接続です。
awspricing
AWSの料金データ。サービスごとの単価を引き、月額見積もりを組み立てます。
uvxで起動します。awsiac
CDK・CloudFormationのベストプラクティス。IAMポリシーのパターンやセキュリティ用のコンストラクトを参照します。
uvxで起動します。
awsiac は、単体のMCPサーバーとしてaws-iac-mcp-serverの使い方で扱っているものと同じ系統です。プラグインはこのサーバーを、IaCを書く工程の参照元として組み込んでいます。テンプレートの検証を単独で回したいなら、そちらを直接入れる選択肢もあります。
デプロイ前に走る安全確認と、足しておきたい歯止め
deployスキルは、安全側の既定値をIaCに自動で適用します。参照資料にあるチェックリストの主な項目は次のとおりです。
- S3バケットは非公開にし、パブリックアクセスをすべてブロックする
- 保存データの暗号化(devはSSE-S3、本番はKMSの顧客管理キー)
- HTTPSを強制し、TLS 1.2以上にする
- CloudFrontからS3へはOrigin Access Controlを使う
- IAMは最小権限で、ワイルドカードを避ける
- Fargateやデータベースはプライベートサブネットに置く
デプロイ前の工程では、秘密情報の混入検出(git-secrets、truffleHog、detect-secretsなど)を行い、検出されたらデプロイを止めます。続けて単体テストや静的解析の実行、IaCのセキュリティスキャン(checkov、cfn-nag、cdk-nag、tfsec)を行います。
ここで注意したいのは、これが「スキルの手順書に書かれた指示」である点です。Claudeがその通りに実行する前提ですが、AWS側で実行を強制するガードレールではありません。READMEの冒頭にも、生成物とコストは必ず人が見直すよう警告があります。
Claude Code側に承認ゲートを置く
そこで、デプロイ系のコマンドはClaude Codeの権限設定で止めておくと安全です。次は .claude/settings.json の一例です(この記事の提案で、プラグインの同梱設定ではありません)。
{
"permissions": {
"ask": [
"Bash(cdk deploy *)",
"Bash(aws cloudformation deploy *)"
],
"deny": [
"Bash(cdk destroy *)",
"Bash(aws cloudformation delete-stack *)"
]
}
}ask に入れたコマンドは、実行のたびに許可を求められます。deny は一致する呼び出しを拒否します。権限ルールの構文は、* をサブコマンドの後ろに置くのがルールです。詳細はClaude Codeの権限設定にあります。CDK全般の権限設計はClaude CodeでAWS CDKスタックを書くが詳しく、同じ考え方がそのまま使えます。
認証情報は、デプロイ専用のIAMロールかプロファイルを用意し、権限をそこに絞ってください。リポジトリのBest practicesも、AWS認証情報は最小権限で設定するよう勧めています。個人の管理者権限のまま走らせると、スキルが守る最小権限の設計と矛盾します。
CLAUDE.mdに判断基準を書いておく
スキルは「迷ったら聞く」設計ですが、自分のチームの基準を持たせると質問が減り、結果も揃います。たとえば次のような断片です。
## AWS デプロイの方針
- リージョンは ap-northeast-1。他のリージョンを選ぶ前に必ず確認する
- IaC は CDK(TypeScript)。cdk deploy の前に cdk diff の結果を見せる
- 見積もりが月 100 ドルを超える構成は、実行前に代替案も 1 つ示す
- 本番アカウント向けのデプロイは実行せず、コマンドの提示で止めるこれは公式のサンプルではなく、運用ルールの書き方の一例です。CLAUDE.mdは指示であって強制ではないので、重要な禁止事項は上の権限設定でも二重に止めておくのが無難です。
同じリポジトリの兄弟プラグインとどう使い分けるか
agent-plugins のマーケットプレイスにはdeploy-on-aws以外にも複数のプラグインがあります。名前が似ていて迷いやすいので、役割を並べます。
| プラグイン | 守備範囲 | 向く場面 |
|---|---|---|
| deploy-on-aws | 守備範囲構成提案・見積もり・IaC・デプロイ | 向く場面何を使うか自体が未定のアプリを載せる |
| aws-serverless | 守備範囲Lambda・API Gateway・EventBridge・Step Functions、SAMとCDKのデプロイ | 向く場面サーバーレスと決めて作り込む |
| aws-amplify | 守備範囲Amplify Gen 2で認証・データ・ストレージ・関数を組む | 向く場面フルスタックをAmplifyで作る |
| databases-on-aws | 守備範囲スキーマ設計・クエリ・移行・マルチテナント | 向く場面データベースの設計に集中する |
| migration-to-aws | 守備範囲GCPからAWSへの移行(探索・マッピング・コスト・計画) | 向く場面他クラウドから移す |
境界は「構成を決める側」か「決めた構成を深く作る側」かで考えると整理しやすくなります。deploy-on-awsは前者で、構成を自分で決め、その後の実装を細かく詰めたいならaws-serverlessやaws-amplifyに移る流れが自然です。
たとえば、LambdaのSAM開発を軸にするならClaude CodeでAWS Lambda(SAM)を開発する手順のほうが、ローカル実行と検証の運用を細かく扱っています。deploy-on-awsは、そこへ至る前の「そもそもLambdaかFargateか」の判断にも使える、という位置関係です。
AWSのサービスをClaudeから直接操作したい場合は、プラグインではなくリモートのMCPサーバーという選択肢もあります。接続の方法はClaudeとAWS MCPサーバーの連携にまとまっています。
つまずきやすい点
MCPサーバーがネットワーク制限で起動しない
awspricing と awsiac は uvx 経由で最新版を取得して起動するため、パッケージの取得が許可されていない環境では失敗します。awsknowledge も外向きのHTTP通信が通ることが前提です。社内プロキシや閉域の開発環境で使うときは、先にこの経路を確かめてください。
請求が想定を超える
NAT Gatewayは時間課金とデータ処理量課金の両方がかかります。スキルの既定ではFargateのタスクをプライベートサブネットに置き、NAT Gateway経由で外に出る構成なので、devでも固定費が発生します。見積もりの内訳にNAT Gatewayが入っているかを確認しましょう。
後継の動き
リポジトリのREADMEには、Agent Toolkit for AWSがMCPサーバー・プラグイン・スキルの後継として公開済みだという告知があります。本番ソフトウェアを作る場合は、そちらを推奨する記述です。同じREADMEは、このリポジトリも引き続き動作し、貢献を受け付けるとも書いています。今後の移行先は公式の告知を追ってください。
まとめ
このプラグインの価値は、構成がまだ決まっていない段階で「何を使うか」と「月いくらか」を先に出させる点にあります。一方、READMEは本番ソフトウェアには後継のAgent Toolkit for AWSを勧めています。判断と見積もりまでをこのプラグインに任せ、作り込みは後継か兄弟プラグインに渡す、という線引きが現実的です。
使い始める前に、デプロイ系のコマンドを ask に、破壊系を deny に置いておけば、任せる範囲を自分で決められます。