AWS DevOps Agentの障害調査から修復まで自動化｜変更前に人が承認する構成

AWSは2026年10月7日、AWS DevOps Agentが調査した障害について、Amazon BedrockとAWS Lambda Durable Functionsを組み合わせて修復案を作成する実装例を公開しました。障害の検知と原因調査から、具体的な変更提案までをつなぐ構成です。

処理はAWS DevOps Agentの調査完了イベントから始まります。Amazon EventBridgeが処理を起動し、Bedrockが原因情報を分析します。エージェントが実行できる操作は、あらかじめ許可されたLambda関数の一覧に制限されます。

【障害調査と修復実行を分ける理由】ログや設定を読み取る診断と、本番インフラの設定を変更する修復では影響範囲が異なります。AIが原因候補を提示できても、誤診断による変更は障害を拡大させる可能性があります。そのため、調査は自動化しつつ変更前に人が判断する構成には実務上の意味があります。

【イベントから承認までの処理】AWS DevOps Agentによる調査の完了を起点に、EventBridgeが後続処理を起動します。Bedrockが調査結果を基に修復案を組み立て、許可されたLambdaツールを使う構成です。重要なのは、モデルが任意のコマンドを実行できる状態にせず、操作の入口を限定することです。

【Durable Functionsの役割】承認待ちが長引く場合、単純な短時間の関数実行だけでは処理状態を維持しにくくなります。Durable Functionsを使う設計では、修復案を提示した後に処理を待機させ、担当者の応答を受けて再開するワークフローを構成できます。

【タイムアウト変更の例をどう読むか】紹介されたデモではLambdaのタイムアウトを3秒から30秒へ延ばす提案が示されます。ただしタイムアウトを延ばせば根本原因が解消するとは限りません。処理の遅延、外部APIの応答、再試行の増加などを確認し、変更後の監視項目を決める必要があります。

【承認画面に必要な情報】担当者が判断するには、対象リソース、現在値と変更後の値、変更理由、想定される副作用、元に戻す方法を明示することが重要です。『AIが推奨した』という説明だけでは、インフラ変更を承認する根拠として十分ではありません。

【本番導入の検証方法】既知の障害シナリオを使い、原因分析の正確さ、修復案の妥当性、承認までの時間、失敗時の復旧手順を測定します。実行権限を最小化し、変更履歴を監査できる状態にしたうえで、段階的に自動化範囲を広げることが望まれます。

【仕組みと背景】障害対応を自動化する場合、原因の分析と設定変更の実行を同じ権限で扱わないことが重要です。

【導入時の課題】Lambda Durable Functionsを使う構成では、担当者の承認待ちの間も処理状態を保持できます。

【検証と今後】自動修復の実装には、操作の許可リスト、変更前の確認、ロールバック、監査ログが欠かせません。

【今後の注目点】技術の新しさだけでなく、既存の作業へ無理なく組み込めるか、導入費用に見合う効果があるか、利用者が結果を検証できるかが普及を左右します。実際の運用事例と継続的な評価が、今後の判断材料になります。

ログの確認など読み取り専用の操作は自動実行できますが、設定変更などインフラに影響する操作では処理を一時停止し、担当者の承認を待ちます。Lambda Durable Functionsは承認待ちの間も処理状態を保持できます。

記事のデモでは、タイムアウトが短すぎるLambda関数について、3秒から30秒への設定変更を提案します。担当者が変更対象と値を確認し、承認した後に実行される流れです。

この例は自動修復の実装パターンであり、すべての障害を安全に直せる完成済みサービスではありません。誤った原因分析や修復案も考えられるため、変更権限の制限、監査ログ、ロールバック設計が欠かせません。