ログ、AWSリソース、GitHubを調べてSlackへ要約する仕組みを紹介しました。社内指標では平均調査時間が45〜60分から15分未満になったとしています。 原因候補の収集と実際の修復を分ける構成です。自社の障害データで要約の正確性や誤警報への対応を検証し、権限と観測を整えることが論点になります。 当番が調べ始めるまでの負担を減らす AWSは11月2日、Circle KのDevOps障害調査を支援する事例を公開しました。同社の担当者との共同執筆で、アラート後に必要な情報を集める工程を扱います。従来はログやサービスの状態、複数の道具を確認する初動に45〜60分かかっていました。Bedrockを使う構成では、それらを調べてSlackへ要約を返します。2026年4月にAgentCore版を本番導入し、社内の障害対応指標で平均調査時間が15分未満になったと説明しています。削減率は67〜75％としています。これは当該チームの測定であり、すべての障害の復旧時間や、他社での短縮効果を示す数値ではありません。 ログとコードの順序を組み立てる 最初の構成では、Grafanaの通知をキューとLambdaを経由してBedrock Flowsへ渡しました。AWSリソースの状態とOpenSearchのログを並行して確認し、その結果を基にGitHubを検索する順序です。原因の手掛かりを得てからコードを見ることで、広すぎる検索を避けます。最終段階では道具を持たないモデル呼び出しが、原因候補、根拠、担当、対応案をまとめます。対象は、当番が複数サービスの状況を横断して確認する運用チームと見られます。現在のAgentCore版では、同じ分析手順を単一のエージェントへまとめています。Gatewayが各情報源へのアクセスを仲介します。人がゼロから調査を始める代わりに、整理された根拠を確認して次の対応へ進める点に重点があります。 実データの絞り込みと権限が運用を左右する 原文は、ログの名前だけを渡すより、必要な行を先に取得して渡す方が良かったと説明しています。大量の情報を無制限に読ませるより、判断に必要な内容へ絞る設計です。また、情報量が増えるにつれ長い調査が必要になり、FlowsからAgentCore Runtimeへ移行しました。途中の状態を保って追加調査できることや、OpenTelemetryによる追跡を利点に挙げています。導入を検討する組織では、機密情報を含むログのアクセス範囲と記録の扱いが論点になります。モデルの応答費用だけでなく、検索、再調査、観測の費用も見積もる必要があると考えられます。要約が一定の形式で出ることと、原因が正しいことは別です。過去の障害で根拠と結論を照合し、誤った対応案を見つける検証が必要になると見られます。 自動修復は今後の計画として読む 現時点の仕組みは、可能性のある原因と修正案を示し、技術者が修正を実施します。簡単な再起動やロールバックなどを扱う自動修復は、DevOps Agentとの連携による今後の計画です。原文は各操作をSlackで人が承認する方針を示しています。したがって調査時間の短縮を、そのまま自動復旧の実績と読むことはできません。次の判断点は、原因候補が実際の解決につながった割合と、承認を含む運用の負担を確認することです。