Bedrock AgentCoreでAWS障害調査とサポート起票を一つの対話へ統合

AWSは、CloudWatchログ、AWS文書、AWS re:Post、サポートケース作成を一つの対話画面へまとめるAWSサポート支援機能の構築例を公開しました。

要点

• Strandsエージェントで処理を組み、AWSサービスをMCP経由のツールとして接続します。
• ログ分析、公式情報検索、コミュニティ情報検索、ケース作成を連続して行えます。
• CloudFormationの単一スクリプトとAmplifyのWeb画面を含む例です。

今回のブログ記事で語られていること

AWS障害の調査では、CloudWatchで証拠を探し、公式文書とAWS re:Postを検索し、解決しなければ同じ情報をサポートケースへ転記します。サポート支援機能は、この流れを対話型エージェントへまとめ、利用者の質問から必要なツールを選び、証拠を集めて次の行動へつなげます。単なる文書検索ではなく、運用環境のログへ触れ、外部へケースを作る点が特徴です。

利便性と同時に、権限の強さへ注意が必要です。CloudWatchの全ログを読める権限には秘密情報や顧客データが含まれる可能性があり、サポートケース作成は外部共有を伴います。対象アカウント、ロググループ、期間、ケース種別を限定し、ケース送信前に収集した内容と添付情報を人が確認できる段階を設けます。AWS re:Postの回答は公式文書と同じ信頼度ではないため、出所を明示して扱います。

調査品質を評価する際は、既知障害、権限不足、無関係な大量ログ、時間帯のずれ、複数原因が重なる例を用意します。エージェントが見つけた相関を原因と断定しないか、参照したログ行と文書を利用者が再確認できるかが重要です。ケース作成を再試行した時に重複起票しない仕組みと、作成後のケースIDを会話へ戻す処理も確認してください。

単一スクリプトで展開できても、本番化には認証、ネットワーク、暗号化、ログ保持、モデル利用費、ツール障害時の切り分けが必要です。まず読み取り専用の調査支援として使い、回答の有用性と誤りを測ってから、承認付きのケース作成へ広げると安全です。

本番評価では、担当者が手作業で同じ障害を調べた結果と比較し、見逃した証拠、誤った推奨、解決までの時間を記録します。自動作成したケースがサポート側で理解できる情報量かも確認してください。

今回のブログ記事が関係する人

AWS運用担当、SRE、一次対応を標準化するサポートチーム、MCPツールの権限を管理する担当に関係します。

結局、今回のブログ記事をどう読むべきか

調査の画面切替を減らす実装例ですが、ログ閲覧と外部起票という強い操作を含みます。出所の確認、人の承認、重複防止を備えた段階導入が適切です。