公開：2026年10月8日, 最終更新：2026年10月8日
30秒サマリー
- AWS公式ブログが、DevOps AgentのインシデントRCA完了後に自動修復を実行するワークフローの実装手順を詳説
- EventBridge・Lambda Durable Functions・Bedrockを組み合わせ、読み取り操作は自動実行、インフラ変更は人間承認待ちで一時停止
- MTTRの短縮とオンコールエンジニアの反復作業削減を目的とし、サンプルコードはGitHubで公開
何が起きたか
AWSは公式機械学習ブログにて、AWS DevOps Agentが生成したインシデント調査結果（RCA）を起点に、自動修復ワークフローを構築する実装方法を解説した。
ワークフローは、DevOps AgentがインシデントのRCAを完了するとAmazon EventBridgeにイベントを送出し、Lambda関数がその調査サマリーを受け取る。続いてAWS Lambda Durable Functionsを使ったオーケストレーター関数がAmazon Bedrockを呼び出し、利用可能な修復ツール（事前承認済みLambda関数のアローリスト）を検索して具体的な修復アクションを提案する仕組みだ。重要な設計上の判断として、読み取り専用の操作は自動で実行されるが、インフラ状態を変更する「ミューテーション操作」はワークフローを一時停止し、人間の承認シグナルを待ってから再開する。Lambda Durable Functionsはこの待機中にコンピュートリソースを消費せず、承認を受けた時点で処理を再開できる点が特徴として説明されている。
ブログ内では、Lambdaタイムアウト値が3秒に設定されていたことで発生したタイムアウトエラーをAWS DevOps Agentが調査し、Bedrockが「30秒への変更」を提案するシナリオを実際のスクリーンショットを交えて解説している。ソリューションのデプロイはAWS CDKを用いて行われ、サンプルコードはGitHub上に公開されている。
原典ハイライト
「オンコールエンジニアが関与する時点では、システムがすでに関連設定を収集し、根本原因と利用可能な修復アクションを照合し、ワンクリック承認の準備が整った事前検証済み変更セットを用意している」とブログは説明している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
このアーキテクチャが示す重要な点は、AIエージェントによる調査と自動修復の間に「承認ゲート」を設けることで、自律性と安全性を両立させるパターンを具体的に示した点にある。読み取り操作と書き込み操作を明確に分離し、書き込み前に人間が介入できる設計は、本番環境への自律AIエージェント導入における実用的なリスク管理モデルとなっている。Bedrock呼び出しとツール実行を繰り返す「エージェントループ」により、一度の承認で複数ステップの修復を完結させられる点もMTTR短縮に直結する。
日本企業への示唆
AWSをメインクラウド基盤として運用する日本企業のSRE・インフラ担当チームにとって、今回の実装パターンはすぐに自社環境へ適用を検討できる具体的な参考情報となる。特に深夜帯のオンコール対応コスト削減を経営課題として持つ組織は、承認フロー付き自動修復ワークフローのプロトタイプとしてサンプルコードを活用できる。導入に際しては、アローリストに含める修復ツールの設計（どの操作まで自動化するかの境界線策定）が運用上の要となるため、初期段階では読み取り専用操作の自動化から段階的に適用範囲を拡張するアプローチが現実的だ。また、承認シグナルのJSONペイロードに任意の情報を含められる設計は、既存のインシデント管理ツール（例：PagerDutyやSlack）との統合ポイントとして活用できる可能性がある。
背景・経緯
AWS DevOps Agentはメトリクス・ログ・アプリケーショントポロジを相関分析してインシデントのRCAと推奨アクションを提供するAI自律エージェントだが、本番リソースを直接変更しない「観察・報告モード」で運用されるのが一般的とされている。今回のブログ記事は、このRCA結果を受け取った後の「修復実行」ステップを補完する実装パターンを解説するものであり、DevOps Agent自体の新機能発表ではなく、周辺ワークフローの構築方法についての技術解説記事として位置付けられる。
