deploy-on-awsの検証
1. 実行環境・事前準備
| 項目 | 内容 |
|---|---|
| モデル | Claude Opus 4 |
| 検証対象 | deploy-on-aws |
| 検証日 | 2026年4月12日 |
筆者はMarketplace経由でプラグインをインストールし、初期セットアップはスムーズに完了しました。
検証用アプリケーションは「お問い合わせサイト」をテーマに、ユーザ認証機能・API・定期バッチ処理・DBを含むコードを用意しました。単純なAPIではなく、複数要素を持つ構成とすることで、deploy-on-aws の提案やIaC生成の傾向を確認しやすくする目的です。
アプリコード：48ファイル / 1,652行
2. Analyze → Recommend → Estimate
アプリケーションコードを配置したリポジトリ内でClaude Codeを起動し、deployと入力すると、deploy-on-awsのSkillsが呼び出されてワークフローの実行が開始されます。
Analyze → Recommend → Estimate が順に自動で実行され、3ステップの実行結果がまとめて出力されました。
Claudeの処理時間：38秒
ここでGenerate（IaC生成）を開始するための承認を求められるので、納得のいく構成になるまで、自然言語で要件の修正を指示することが可能です。要件を修正するたび、3ステップのうちRecommend → Estimateが再実行されて、同じ形式で新しい構成提案と見積もりが出力されます。
今回は、インプットした情報による構成提案の違いを確認するため、以下の通り3種類の条件でRecommend → Estimateを実行しました。
2-1 初期提案
- 条件：アプリケーションコードのみを与えて、要件は全く指示なし
- 結果：コードからアプリの概要を読み取り、アプリの実行基盤アーキテクチャが自動で提案された
| 項目 | 内容 | 補足 |
|---|---|---|
| フロントエンド | S3 + CloudFront | |
| バックエンド | App Runner | |
| DB | RDS PostgreSQL | single-AZ, db.t4g.micro |
| バッチ | Lambda + EventBridge Scheduler | |
| 月額見積り | 約 23ドル |
2-2 性能要件追加
- 条件：商用利用想定、アプリケーションコードに加えて性能要件を自然言語で指示
- 結果：性能要件に対して構成が再提案され、見積もりも再計算された（APIは60RPS・バッチは10万件／回のデータ処理想定）
| 項目 | 変更内容 | 補足 |
|---|---|---|
| バックエンド | App Runner → ECS Fargate + ALB | 通常時2タスク→CPU使用率とリクエスト数をトリガーに最大6台までスケール |
| DB | single-AZ → Multi-AZ | |
| バッチ | Lambda → ECS Fargate スケジュールタスク | 処理件数が多く、Lambdaの最大実行時間に収まらない可能性を自動で考慮 |
| ネットワーク | 2AZ の VPC構成を追加 | |
| 月額見積り | 約 23ドル → 約 208ドル |
2-3 運用観点追加
- 条件：次のような運用設計観点はほとんど提案されなかったため、運用観点の概要を複数指示
- 結果：IAM権限分離やログ集約設計など、運用観点の詳細もある程度補完した構成が提案された
-
IAM権限
アプリ担当者：アプリケーションコードの更新とアプリログの参照
インフラ担当者：AWSリソースの設定変更とシステムの監視 -
ログ集約
アプリ実行ログ：CloudWatch Logs
ALB アクセスログ：S3 + Athena
RDS スロークエリ：CloudWatch Logs -
監視
CloudWatch Logs / Alarms / Dashboard
X-Ray
Performance Insights
→ SNS 通知を追加 -
監査
CloudTrail → CloudWatch Logs
以上の通り、詳細を指定せずにdeploy-on-awsを実行すると、アプリ実行基盤を中心とした軽量な最小構成を提案されました。また、追加で詳細な要件を与えることで、可用性・性能・運用性を踏まえた商用寄りの構成を提案することも可能になると分かります。
補足
見積もりは概算額で表示され、利用量の前提や割引条件までは明示されませんでした。
なお、提案されたサービスのEOLや推奨設定は利用者が確認する必要があります。例えば「2-1 初期提案」ではApp Runner、「2-3 運用観点追加」ではX-Rayが提案されましたが、いずれも既に一部機能のサポート終了が発表されています。
※ App Runnerについては現在、"新規ワークロードでは提案しない" という注意書きがreferences へ追記されています。
3. Generate
Generateでは、前のステップで確定した構成をもとに、各リソースの詳細設定を含むIaCコードが自動生成されます。
IaC生成が終わるとサマリが出力され、承認の上でデプロイ開始のコマンドを実行するよう指示されます。ここでIaCのレビューと修正を実施することが推奨されています。
Claudeの処理時間：10分
今回はIaC生成のデフォルト設定に従って、CDKで生成されました。生成結果を見ると、単にインフラ定義を出力するだけでなく、アプリケーションをAWSにデプロイするための周辺要素も補完されています。
- Dockerなどの周辺ファイルが自動生成
- バッチ実行を想定した既存コードに対し、AWS上で起動するためのentrypoint、run.jsなどが追加
ただし、IaC生成後に表示されたサマリはファイル一覧などの概要であり、各リソースにどのような設定が適用されたかを確認するにはCDKのコードを読み解く必要がありました。
今回はSecurity Groupを確認したところ、商用利用を前提とするとやや粗い設定が見られました。例えば、全てのSecurity Groupに共通して、アウトバウンドが全許可になっています。また、RDSは本来ECS/Batchからの接続のみに制限すべきですが、VPC全体からの接続を許可している点も気になります。
例）Security Group の生成テンプレート
"SecurityGroupEgress": [
{
"CidrIp": "0.0.0.0/0",
"Description": "Allow all outbound traffic by default",
"IpProtocol": "-1"
}
]
例）RDS の設定ファイル
// RDS security group — allows inbound 5432 from the entire VPC CIDR.
const dbSg = new ec2.SecurityGroup(this, 'DbSg', {
vpc: props.vpc,
description: 'RDS PostgreSQL - inbound 5432 from VPC private subnets',
});
例）ECS の設定ファイル
const ecsServiceSg = new ec2.SecurityGroup(this, 'EcsServiceSg', {
vpc: props.vpc,
description: 'ECS backend - inbound 8080 from ALB only',
});
例）ECS Batch の設定ファイル
const batchSg = new ec2.SecurityGroup(this, 'BatchSg', {
vpc: props.vpc,
description: 'Batch task - egress only',
});
本来は丁寧にレビューすべきタイミングですが、deploy-on-awsの成果物がどこまでそのまま使えるかを評価するため、明らかなエラーのみ修正してデプロイに進みました。CDKコードが破綻していないことのチェックとしてcdk synthを実行したところ、複数のエラーが検出され修正が必要になりました。
修正に要したClaudeの処理時間：5分
修正後IaC：8,755ファイル / 1,980,927行
4. Deploy
デプロイの開始前には、いくつか必要な準備がありました。
-
AWS CLIの認証情報
AWS Loginを使用しました。試験用のAWS環境であり、破壊的行為等によるリスクが明らかにないため、今回は意図的に管理者権限を与えました。 -
cdk.jsonファイルの編集
構築フロー完了時に案内された内容に従い、GitHubリポジトリ情報、アラート通知先メールアドレス等を手動で設定しました。
Deployは自動実行ではなく、利用者がCLI上でコマンドを使って進めました。パイプラインごとに処理結果が出力されるため、進行状況は把握しやすい仕組みです。
パイプライン1つのデプロイ時間：2,3分～20分
デプロイが途中で失敗するケースが複数発生し、修正しながら進めた結果、作業開始から完了までに約2時間を要しました。
今回の検証では、AIエージェントによる自律的な再試行は行われず、利用者が原因に対処して再度デプロイする必要がありました。また、デプロイの失敗時は基本的に自動でロールバックされますが、ロールバックが正常に完了せず、手動でのリソース削除が必要な場面も発生しました。
参考までに、デプロイの失敗原因は大きく2種類でした。
-
AWSサービスの制約・利用条件（2件）
- Security Groupのdescriptionに使用できない文字形式が含まれていた
- PostgreSQLに指定したマイナーバージョンが、実際の環境では利用不可だった
-
リリースフローの考慮漏れ（1件）
- アプリケーション実態がない状態でECSを起動し、サーキットブレーカーによってタスク起動が失敗しつづけた
