Amazon Bedrock AgentCoreで障害調査お助け用Slackアプリを作成したらDevOpsAgentで良くね...？となった話
こんにちは！
クラウド事業本部 運用イノベーション部の大野です。
今回は、運用チームの課題解決のために Amazon Bedrock AgentCore を使って障害調査の初動対応お助け用Slackアプリを作成した話をご紹介します。
...が、モック完成後（もはや作っている最中から）にre:Invent2025で発表された「AWS DevOps Agent でいいじゃん...」となってしまったため、経緯も含めてお話しします。
Slackアプリを作った背景
運用において発生する以下の課題に対して、何かAIサービスを使った改善を行えないかな〜と思ったのがきっかけです。
- 人員不足によるアラート対応の負担増加（特に夜間時）
- 対応手順書を探す手間による対応遅延
運用を担当されている現場の多くで共感いただける課題感なのではないかと思います。
他にも解決すべき課題はありますが、ひとまずは上記2点に取り組むことにいたしました。
前提として、CloudWatchなどの監視ツールから発砲されたアラートがSlackに通知されるシステムがあり、そのSlack通知から担当者がアクションを起こす運用であるとします。
今回はアクションの起点であるSlack通知に焦点を当て、その通知の内容を自動で補完してくれるAIエージェントを作成することにしました。
通知が飛んできたらその内容をAIが読み取り、自動でナレッジベース内の該当する対応手順を教えてくれる...といったイメージです。
実を言うとこの時点でDevOps Agentの存在は認知しており、課題にマッチするソリューションの一つであることは分かっておりました。
しかし「謎の逆張り精神＋触ったことのないサービス触りたい」という思いが溢れてしまったため、今回は「Bedrock Agentcore」を採択しました。
Amazon Bedrock AgentCoreってなんだ？
AgentCoreは、2025年10月にGAとなった エンタープライズ向けのエージェント構築サービス です。
従来のBedrock Agentとの違いを簡単にまとめると...
| 項目 | Bedrock Agent | Bedrock AgentCore |
|---|---|---|
| アプローチ | コンソール GUI（ノーコード） | CLI / コードファースト |
| フレームワーク | AWS 固定 | 任意（Strands Agents, LangGraph 等） |
| Memory | Session Memory のみ | Session + Episodic Memory |
| Evaluation | なし | 13種類の組み込み評価機能 |
| 対象 | 簡易プロトタイプ | エンタープライズ本番運用 |
もちろん独自の手順書などを格納し、参照させることができるKnowledge basesも使用可能です。
また個人的には、Episodic Memory（過去の対応履歴から学習する機能）が運用用途には有用だと感じました。
構築したアーキテクチャ
今回のPoCでは以下の構成で構築しました。
構成概要
- Slack App：アラート通知を受け取るボット
- API Gateway + Lambda（2つ）：Slackイベント受信と非同期処理
- AgentCore Runtime：Strands Agentsフレームワークでエージェントを実行
- AgentCore Memory：Session Memory + Episodic Memory
- Knowledge Bases：ランブック検索用（S3 Vectors使用）
- Claude Sonnet 4：推論エンジン
動作フロー
- Slackでアラートメッセージを
@Bot付きで投稿 - API Gateway → Lambda（Receiver）がイベントを受信
- Lambda（Worker）を非同期呼び出し
- AgentがKnowledge Basesからランブックを検索
- 過去の類似対応をEpisodic Memoryから検索
- Claude Sonnet 4で対応手順を生成
- Slackスレッドに返信
実装のポイント
Lambda 2つ構成にした理由
Slackは Events API のレスポンスが 3秒以内 に返却されることを期待します。
3秒を超えるとリトライが発生し、重複応答の原因になります。（1敗）
そのため、以下の2つの Lambda関数を使用した非同期構成を採用しました。
| 関数名 | 役割 | タイムアウト |
|---|---|---|
slack-alert-receiver |
Slackイベント受信、即座に 200 返却 | 10秒 |
slack-alert-worker |
Agent処理、Slack への返信投稿 | 2分 |
東京リージョンでの Inference Profile ID
東京リージョン（ap-northeast-1）では、直接モデルIDではなく Inference Profile ID を使用する必要があります。
# 東京リージョンでは Inference Profile ID を使用
MODEL_ID = "apac.anthropic.claude-sonnet-4-20250514-v1:0"
bedrock_model = BedrockModel(
model_id=MODEL_ID,
region_name="ap-northeast-1",
)
Slack mrkdwn 形式への対応
Slackは標準Markdownをサポートしていないため、システムプロンプトで出力形式を指定しました。
## 出力フォーマット
出力は Slack に投稿されます。Slack の mrkdwn 形式で記述してください：
- 見出しは太字で表現: *【重要度】* のように * で囲む
- 強調は * で囲む: *重要*
- コードは ` で囲む: `df -h`
Episodic Memory Strategy の追加
agentcore configure で作成された Memory には、デフォルトで Episodic Memory Strategy が設定されていません。
過去の対応履歴を参照するには、手動で追加する必要があります。
AWSコンソールの Bedrock → AgentCore → Memory から既存の Memory を選択し、Strategiesセクションで「Episodes」を追加します。
S3 Vectors の採用
ベクトルストアには S3 Vectors を採用しました。
OpenSearch Serverless と比較すると...
| 項目 | S3 Vectors（採用） | OpenSearch Serverless |
|---|---|---|
| 最小月額コスト | $0（従量課金） | 約$175-350 |
| PoC 2週間コスト | $1〜3 | 約$40〜90 |
| クエリレイテンシ | 100-500ms | 10-50ms |
最初はあまり考えずにデフォルトのOpenSearchを使用していたのですが、利用料が跳ね上がったので慌ててS3 Vectorsに切り替えました。
100-500msのレイテンシは許容範囲だったため、コスト面で大きな恩恵を受けられますね。
動作検証結果
テストチャンネルで実際に動作確認を行いました。
@Bot CPU使用率が95%に達しました。サーバー: web-server-01
と投稿すると...
【重要度】 Critical
【アラート概要】
web-server-01のCPU使用率が95%に達している状況です。通常のCPU高騰アラートの発生条件（90%以上で5分間継続）を上回っており、サービスへの影響が懸念されます。
【推奨対応手順】
1. まず10分間待機 - 一時的なスパイクの可能性があります
2. 10分経過後もCPU使用率が高い場合：
- 上位者にメンションして共有
- お客様に該当のJSMチケットでCPU使用率が高騰している旨を連携
3. 対象サーバーにSSH接続
4. top コマンドでCPU使用率の高いプロセスを確認
5. ps aux --sort=-%cpu | head -20 で詳細確認
6. 問題のプロセスを特定し、必要に応じて対処
【エスカレーション条件】
• 30分以内に解消しない場合 → リーダーに報告
• サービス影響がある場合 → 即時エスカレーション
【注意事項】
95%という高いCPU使用率のため、通常の90%アラート手順よりも迅速な対応が必要です。サービスの応答性に影響が出ている可能性が高いため、お客様への早期連携を推奨します。
【参照ランブック】
01_cpu_high_alert.md - CPU使用率高騰アラート対応手順
のような対応手順が返ってきました！
スレッド内での追加質問にも、文脈を維持して回答してくれます。
想定通りの挙動をしてくれて万々歳です！
...DevOps Agentと向き合う
ここで一度冷静になり、DevOps Agentと向き合ってみましょう。
AWS DevOps Agentとは
AWS DevOps Agent とは、re:Invent 2025で発表された 自律型のオンコールエンジニア として機能する全く新しいAIエージェントサービスです。
Frontier Agentの1つとしてリリースされました。
主な機能
- 自律的なインシデントトリアージ：各種監視ツールなどと連携可能で、アラートが来た瞬間から調査を自動で開始
- 根本原因分析：CloudWatch、GitHub、GitLabなどのデータを自動で相関分析。
- プロアクティブな推奨：過去のインシデントパターンから改善提案
対応している連携先も豊富です
- 監視ツール：CloudWatch、Dynatrace、Datadog、New Relic、Splunk
- コードリポジトリ：GitHub、GitLab
- チケットシステム：ServiceNow、PagerDuty
- コミュニケーション：Slack
手動で作成したインシデント、もしくは連携先から起票されたインシデントチケットを元に、環境内のリソースを網羅的に調査して根本原因分析と推奨対応の提示まで行ってくれます。
また、独自のランブックを登録することも可能で、登録しておけばそのランブックから情報を参照して調査してくれます。
更にはMCPサーバーとの接続も可能という隙の無さとなっております...！
インシデント自動調査ツールという観点において、もうこれで良くね...？と思考停止してしまいそうです。（しました）
Agent Coreは完全敗北なのか？
AI × 運用という観点では、DevOps Agentがあまりにも優れているように見えます。
実際に非常に優秀ですし、今まで思い描いていた「あったらいいな」が詰め込まれたサービスです。
ではAgent Coreを含む他のAIエージェントはお払い箱になってしまったのかと言うと、今のところはそうではないと考えます。
理由としては大きく以下3点です。
- コスト
- DevOpsAgentは現在Preview版であり、GA後にどのような料金体系となるか不明です。
- しかしAWS環境を網羅的に調査する仕様上APIコール数が多くなったりと、利用料が高くなる可能性は考えられます。
- 柔軟性
- DevOpsに特化したエージェントであり非常に多機能ですが、実際の運用においてはそこまでの機能は不必要な場合も考えられます。
- コストの項目にも掛かってきますが、必要な特定機能のみを持たせたエージェントを独自に開発し運用した方が費用対効果は高くなる可能性はあります。
- ガバナンス要件
- 現状ではDevOpsAgentは「us-east-1（バージニア）」リージョンでしか使用できません。
- 他リージョンのリソースを参照して調査すること自体は可能ですが、日本国内でのデータ保管や処理の要件がある場合は利用が制限されます。
- 調査においてCloudWatch LogsやX-Ray、CloudTrailのトレースログにアクセスするため、それらに個人情報や機密データが含まれていた場合はUSリージョンに送信されるリスクがあります。
あくまで「今のところは」ですが、DevOpsAgentの利用においては上記のような制限もあります。
コストや柔軟性の点においては、AgentCoreなどの状況に応じて小回りの効くAIエージェントを選択すべきケースもありそうです。
まだPreview版の段階のためDevOpsAgentを本番利用することはないかと思われますが、利用の際には考慮いただいた方が良いかもしれません。
まとめ
Amazon Bedrock AgentCoreで障害調査お助け用Slackアプリを作成したらDevOpsAgentで良くね...？となった話でした！
今回は本筋からズレるので大幅に省略しましたが、今回作成したアプリについてまた細部が整えば全体の構成や設定について詳細に記載して、ブログに上げさせていただこうかと思っております。
まとめとして「DevOps Agent」と「Bedrock AgentCore」のどちらを選ぶかはユースケース次第です。
まだPreview段階のため結論を出すには尚早すぎますが、DevOpsにおけるAIエージェントの選択肢が排除されることは無いと考えられます。
が、あまりにもコストが高くならない限りは、多くの状況において「DevOps Agent」が第一の選択肢になるのではないかと思うぐらいには多機能で優秀なサービスです。
AWS肝入り（？）のFrontier Agentの1つとして今後もアップデートが期待されるサービスのため、まだ触られていない方は今の内に触り倒しておくことをオススメいたします！
私と同チームのメンバーも多数記事を公開しておりますので、ぜひご覧ください。
以上、大野でした！
参考リンク：
