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

2026.05.31
 はじめに先日、作詞支援ツールをリリースしたという記事を投稿しました。

https://dev.classmethod.jp/articles/sakushi-tech/
有難いことにこちらのサービスを愛用いただいているユーザーの方が多数いらっしゃるので

今後も安定したサービスを提供していくためにもAWS DevOps Agentを導入しました。
 導入するアーキテクチャ前回の記事で技術構成について詳しく解説しましたが、今回導入するのはサーバレス構成のシステムです。
作詞支援ツール
├─ フロントエンド
│   ├─ Next.js 16 (App Router) + TypeScript
│   ├─ kuroshiro.js（漢字→ひらがな変換）
│   ├─ 韻検索辞書（ローカルJSON → IndexedDB）
│   └─ Tailwind CSS（ダークテーマ基調）
│
├─ ホスティング
│   ├─ S3 + CloudFront（Static Export）
│   └─ Route 53
│
├─ バックエンド（API Gateway HTTP API）
│   ├─ Lambda (Python 3.12) × 14関数
│   ├─ DynamoDB (2テーブル, On-Demand)
│   └─ Cognito (Google OAuth 2.0)
│
└─ 外部サービス
    ├─ Anthropic API
    ├─ Stripe（サブスクリプション決済）
    └─ Slack Webhook（運用通知）
 DevOps Agentの導入CloudWatchアラームでLambdaエラーやAPI Gateway 5xx、DynamoDBスロットリングを監視しているので、DevOps Agentでこれらのアラームをトリガーにして自動調査をできるよう実装していきます。
 DevOps AgentをAWSコンソールから作成Agent SpaceをAWSコンソールから作成します。
AWSコンソール → DevOps Agent → エージェントスペースを作成

エージェントスペース名を入力し、応答言語を選択

新しいDevOpsエージェントロールを自動作成を選択して作成



機能 → Webhook を追加

画面を遷移して発行された Webhook URL と Secret を取得する
 Webhook中継基盤をSAMでデプロイ既存のCloudWatchアラームとDevOps Agentを繋ぐため、Webhook中継基盤を実装します。

今回のシステムで実装した項目は以下の通りです。
 SAMテンプレート（template.yaml）Parameters: EnableDevOpsAgent、DevOpsAgentWebhookUrl、DevOpsAgentWebhookSecret
Conditions: UseDevOpsAgent（フラグがtrueのときだけリソース作成）
Rules: EnableDevOpsAgent=true のときにURL/Secretが空ならデプロイ失敗させるバリデーション
Webhook中継Lambda: EventBridgeイベントをincident形式に変換し、HMAC署名付きでDevOps Agent Webhookに送信
EventBridgeルール: アラームのALARM状態変更のみをフィルタして中継Lambdaに転送
Lambda Permission: EventBridgeから中継Lambdaの呼び出しを許可
 Webhook中継Lambda（handler.py）EventBridgeの CloudWatch Alarm State Change イベントを受信
DevOps Agentのincident形式（eventType, incidentId, action, priority, title 等）にペイロードを変換
x-amzn-event-timestamp と x-amzn-event-signature（timestamp:body のHMAC-SHA256 base64）で署名
HTTPS POSTでWebhookに送信
429/5xxのみリトライ（Lambdaの自動リトライに委ねる）
 アラームからDevOps Agentへの流れCloudWatch Alarmの状態変更
  ↓
EventBridge ルール（ALARMのみフィルタ）
  ↓
Webhook中継Lambda
  ↓ HMAC署名付きHTTPS POST
DevOps Agent Generic Webhook
  ↓
Agentが自動で障害調査を開始
 実際に使ってみる導入が完了したので早速使っていきます。
 障害調査CloudWatchアラームを手動で発火してテストします。
aws cloudwatch set-alarm-state \
  --alarm-name "設定したCloudWatchアラーム" \
  --state-value ALARM \
  --state-reason "テスト: DevOps Agent連携確認" \
  --region ap-northeast-1
調査結果は右上のオペレーターアクセスから確認できるようです。



調査結果がこちら。

すごい……

現在の運用はSlackにエラー通知を飛ばして原因を確認というよくある障害対応の流れなのですが、これを使えばエラー確認から原因調査までの流れが自動で完了しそうです。
 改善提案さらに実際にサービスが直面している困りごとを相談してみます。





おぉ！

これまで検討していた改善案に+αしたような結果が得られました。

今まではClaude Codeとのやり取りの中で改善・運用をしているのですが、Claude Codeが欲しいと言ったデータを取得するのがかなり面倒でした。

このあたりをDevOps Agentがアカウントに紐づくリソースから情報を引っ張ってきて調査・提案をしてくれるのはボトルネックとなっていたデータ取得部分が解消され、改善スピードが一気に上がりそうです。
 Slack連携DevOps Agentで検知したアラートと調査結果をSlackでも確認できるように通知してみます。
 Slack連携の実装エージェントスペース → 機能 → コミュニケーション：統合を追加

Slack：登録 → Slackの認可ページでワークスペースを選択 → 許可

Slack を DevOps エージェントに登録する：次へ →  通知先のチャンネルIDを入力



以下のコマンドを通知先のSlackチャンネルで実行 → 追加
/invite @AWS DevOps Agent


これだけでアラーム発火時にDevOps Agentの調査結果（発見事項・根本原因分析・緩和策）がSlackに投稿されるようになります。
 Slackの通知テスト再びCloudWatchアラームを手動で発火してテストします。
aws cloudwatch set-alarm-state \
  --alarm-name "設定したCloudWatchアラーム" \
  --state-value ALARM \
  --state-reason "テスト: DevOps Agent連携確認" \
  --region ap-northeast-1
無事、SlackにDevOps Agent経由でアラートの通知が飛んできました。

アラート通知後、スレッドの返信で調査結果も届いています。

一点、Slack連携は一方向の通知のみなのでDevOps AgentのWebアプリのように会話形式での双方向のやり取りは標準で対応していないようです。

調査結果の深堀りやコスト・セキュリティ最適化の改善相談をSlack経由でDevOps Agentとチャットでやり取りできたらさらに便利になりそうなので実装できないか模索中です。
 まとめサーバーレスであまり障害が起こらないとは言え、作詞支援ツールに関しては私が個人で運用しているサービスなので何かあったら調査から復旧まですべて一人で行う必要があります。
実際にあった場面としては新機能のリリース後にLambdaの呼び出しで5xxエラーとなり、原因調査に少し時間がかかったことがありました。

原因さえ分かってしまえば復旧はすぐだったのですが、サービス影響を考えると焦って泥沼にハマり、思いのほか時間が溶けてしまうことはあるあるなのではないでしょうか。
障害発生時は緊急での対応が求められたり、夜間でも対応しなければならなかったりと身体・精神ともに負担がかかります。

自動で調査までしてくれるというのは単純に時短になるというだけではなく、私が思っていたよりも色んな角度から運用を楽にしてくれるように感じました。
DevOps Agentについては今後もしばらく運用してみて何か気づきや新たな発見ががあればまた記事にして共有します。