アプリのデプロイで地味に心理的な面倒さが襲ってくるのが「リリース後の動作検証」です。AWS CDKで構築したスタックをデプロイした後、LambdaやStep Functionsなどのワークフローを実行し、SNSにメッセージが届いているかの確認やCloudWatch Logsでのエラー調査など、個人開発でちょっとしたツールを作った場合などでも、なんだかんだ最終チェックに時間を取られがちです。

今回は条件付きではありますが、AWS CLIをCursorに使わせることである程度調査を自動化させてみました。

デプロイ状況を確認してみる

複数のPJを個人で管理していると、時々デプロイ済みかマージしただけかがわからなくことがあります。スマホでマージして、pullし忘れているとかもありますね。

この辺りの調査からまずやらせてみます。Cursorにこのような指示を出してみました。

Git のログと CloudFormation の更新日をチェックして、main ブランチの更新がデプロイされているか知りたい

AWS CDKで管理されているPJにてプロンプトを入力すると、CursorはAWS CLIを使って調査してくれます。

aws cloudformation describe-stack-events \
  --stack-name PerformanceAnalyticsStack \
  --region us-west-2 \
  --max-items 10 \
  --query 'StackEvents[*].[Timestamp,ResourceStatus,ResourceType,LogicalResourceId]' \
  --output table

続いて Git のログと CloudFormation のイベントを突き合わせて、以下のような報告をしてくれました。

Git の最新コミット(main ブランチ)
コミットハッシュ: 171314bd2d77c01570a92bc85afb7b19a5f1b0df
日時: 2025-12-09 10:00:29 +0900 (JST) = 2025-12-09 01:00:29 UTC
コミットメッセージ: "gha to cci"
変更内容: GitHub Actions のワークフローファイル削除のみ(CDK スタックや Lambda 関数のコードには影響なし)

CloudFormation スタックの更新状況
スタック名: PerformanceAnalyticsStack
最終更新日時: 2025-12-09 00:33:40 UTC
作成日時: 2025-10-29 12:21:39 UTC
最新の更新内容: Lambda 関数(WeeklyAnalytics、DailyAnalytics)の更新

比較結果
最新のコミット(01:00:29 UTC)は、CloudFormation スタックの更新(00:33:40 UTC)より約27分後です。
ただし、この最新コミットは CI 設定の変更のみで、CDK スタックや Lambda 関数のコードには影響していません。

定期的にメンテしているPJでは不要かもしれませんが、年に１回デプロイするかしないか・・・のようなものでは、「あれ？どうだっけ？」となった時の相談相手に使えそうです。

実運用しているリソースの調査

簡単な調査が成功したので、続いて実際に動いているリソースの調査をしてみます。このスタックには週次と日次で Slack にレポートを投稿する Lambda 関数が含まれていて、動作が安定しているか知りたいという状況です。

まず Slack に投稿されたレポートを見せて、以下のように質問しました。

これってこのスタックが作成したレポート? S3 のデータを DL して分析してくれないかな?
## 📊 週次パフォーマンスレポート
**期間**: 12月15日 ～ 12月21日
### 🎯 主要指標
• **ページビュー**: 2,839 📈 +32.2%
• **ユニークビジター**: 1,702 📈 +27.0%
• **平均セッション時間**: 5:33 (-4:11)
• **直帰率**: 0.55% (-5.2%)

Cursor はまず CloudFormation の出力と Lambda の実行ログを確認して、このレポートがスタックから生成されたものかを検証してくれます。

このレポートは、この CDK スタックが作成したものです。根拠は以下の通りです。

確認ポイント
S3 バケット名の一致
CloudFormation スタックの出力: DUMY
レポートの保存先: s3://DUMMY_BUCKET_NAME/weekly-reports/2025/12/2025-12-21-weekly-report.md

レポート生成ロジックの一致
Lambda 関数: weekly-performance-analytics が毎週月曜日10時に実行
レポート生成時刻: 2025/12/21 10:00:36(JST) = 2025/12/21 01:00:36(UTC)
S3 への保存時刻: 2025-12-21 19:00:38(UTC) = 2025-12-22 04:00:38(JST)

さらに踏み込んで、以下のように依頼してみます。

直近3回分を DL して、中身を評価して。コードが想定しているようなレポートができているか知りたい。

すると Cursor は aws s3 cp で3ファイルをダウンロードして、内容を評価してくれました。

aws s3 cp s3://DUMMY_BUCKET_NAME/weekly-reports/2025/12/2025-12-21-weekly-report.md /tmp/report-2025-12-21.md --region us-west-2 && \
aws s3 cp s3://DUMMY_BUCKET_NAME/weekly-reports/2025/12/2025-12-14-weekly-report.md /tmp/report-2025-12-14.md --region us-west-2 && \
aws s3 cp s3://DUMMY_BUCKET_NAME/weekly-reports/2025/12/2025-12-07-weekly-report.md /tmp/report-2025-12-07.md --region us-west-2

意図した実装になっているかどうかに加えて、品質についても簡単にチェックしてくれました。Cursor の Autoモデルを使っていますが、GPTやcommpass-1などを使うと、より踏み込んだレポートが得られるかもしれません。

コードが想定する構造のレポートは生成されています。ただし、AI 生成部分(サマリー、洞察、推奨事項)の品質にばらつきがあり、特に12/14と12/21は汎用的な内容になっています。データ部分は正確で、構造も一貫しています。AI 生成部分の品質を安定させるための改善を推奨します。

実装後の動作チェック

そして本題ですね。Lambdaの実行と調査もやらせみましょう。Cursorに、以下のように指示を出してみました。

デプロイ後、Lambda を実行してみて。実行結果は S3 に保存されるので、それを取得して内容を評価して。

Cursor は CDKのデプロイを実施したのちに Lambda 関数を実行してくれます。もちろんその結果についても確認してくれました。

aws lambda invoke \
  --function-name weekly-performance-analytics \
  --region us-west-2 \
  --cli-binary-format raw-in-base64-out \
  --payload file:///tmp/lambda-payload.json \
  /tmp/lambda-response.json && cat /tmp/lambda-response.json | jq .

実行結果が意図した通りかどうか、statusCodeが200かそうでないかなどですね、を調査して成否を判定してくれます。その後 CloudWatch Logsも調査して、エラーログが出ているかどうかまで調べてくれました。エラーが起きている場合は、どこに問題が隠れていたかなどもレポートしてくれます。

まとめ

Cursor に AWS CLI を使わせることで、CDK スタックの調査がかなり楽になりました。コマンドでタスクを定義させることもできますが、「CloudWatch Logsにエラーログが出ていないか？」のような調査をコマンドで表現しようとすると、ちょっと大変な印象があります。そういう意味では、エージェントに任せる方が気軽かもしれません。

ただし注意点として、「Cursorが使うAWS CLIに、強い権限を与えない」ことは意識してください。意図せずAIエージェントがリソースの追加や削除、設定変更を行う可能性もあります。あとはSecrets Managerのデータを読もうとしたりするのもゾッとしますね。リスクを削減する意味では、AWS CLIのdefault profileはREADのみの権限に絞るなどの対策をしておく必要がありそうです。