個人で運用しているサービスにAWS DevOps Agentを導入してみた

• URL: https://dev.classmethod.jp/articles/sakushi-devopsagent/
• 日付: 2026-05-31
• トピック: programming, cloud, ai-llm
• 出典Tier: Tier 3（classmethod / 一次体験・実装を含む技術ブログ）

要約

作詞支援ツール（Next.js+Lambda×14+DynamoDB+Cognito+Stripe）の個人サービスにAWS DevOps Agentを導入した実装・運用レポート。

導入構成：

• CloudWatchアラーム（Lambdaエラー、API Gateway 5xx、DynamoDBスロットリング）→ EventBridgeルール → Webhook中継Lambda → DevOps Agent

Webhook中継Lambdaの実装ポイント：

• EventBridgeの CloudWatch Alarm State Change をDevOps Agentのincident形式に変換
• x-amzn-event-timestamp + x-amzn-event-signature（HMAC-SHA256 base64）で署名
• 429/5xxのみリトライ（Lambdaの自動リトライに委ねる）
• 条件分岐でALARM状態のみフィルタ

検証結果：

• CloudWatchアラームを手動発火してテスト → 調査結果が詳細に生成
• 改善提案機能：実際の課題を相談すると、既存の改善案に+αした提案が得られた
• Slack連携：EventBridge検知→調査結果がSlackに自動通知（アラート→スレッド返信で調査結果）
• ただしSlack連携は一方向のみ（双方向チャットは非対応）

メリット：エラー確認から原因調査までが自動化、Claude Codeでは面倒だったAWSリソースからのデータ取得をDevOps Agentが担う