AgentCore 上のマルチエージェント

セッションノート

課題

障害発生時の従来のワークフロー

• クラウドリソースの状態を確認
• 障害が発生
• インシデント履歴を表示
• 設定を確認
• アラートを確認
• 作業指示を割り当て
• ログを分析
• 根本原因を仮定
• 解決策を検索
• メトリクスを確認
• 依存関係を分析
• 最近の更新を表示
• コールチェーンを検索
• 運用保守マニュアルを表示
• サービスダッシュボードを照会
• 緩和策を実行
• 同僚に通知
• 異常なメトリクスを照会
• マニュアルを読む
• 復旧状況を監視 中核的な課題
• 迅速な損失軽減
• 障害の分離
• 許容可能な時間内に問題を解決
• 障害を分離境界内に限定して他のサービスへの連鎖的影響を防ぎ、障害の影響範囲を縮小
• サービスがユーザーの期待と SLAs を満たすことを保証

ソリューションの進化

• シングルエージェントからマルチエージェントソリューションへの進化 理想的なソリューション システム通知とアラート
• アラームメトリクス: 5xx 率が 30% 超
• アラームの詳細: サービス、エンドポイント、トリガー時刻 補足的な根本原因分析 主な調査結果: API エラー率 100%、DB にエラーなし、S3 バケットポリシーが更新された。
• 即時対応: S3 バケットポリシーの Deny を確認
• 信頼度: 90% 自動運用を確認
• メッセージ: システムが崇敬された。
• RCA: S3 バケットポリシーが Deny に設定されていた
• MTTR: 5 分
• 障害復旧時間を数時間から数分へ短縮 SRE エキスパートの業務範囲
• 過去一時間で User Service のエラー率が 5% に達したのはなぜか？
• 過去一時間に RDS MySQL インスタンスで接続上限超過が 12 件発生したため
• 現在のシステムを把握
• サービス間の相関関係を特定
• ログを分析
• 監査ログを分析
• 設定を分析
• メトリクスを分析 二つの問いを検討

1. システムの複雑性が高く、トラブルシューティングのワークフローが長く、ログ量が多い場合、単一のエージェントで円滑に処理できるか？

2. SRE エキスパートの経験をエージェントに複製して Q&A 方式を置き換え、エージェントが自律的に意思決定して行動できるようにすることは可能か？

マルチエージェントアーキテクチャ設計

• 「Planner」がワークフローを作成
• 「Executor」は割り当てられたタスクの実行を担当
• 「Evaluator」は各ステップの結果が有益かどうかを評価し、その後の計画のために「Planner」へ戻す役割を担当
• 結果も返す前に「Evaluator」によるレビューが必要
• 「Planner」は「Evaluator」からのフィードバックに基づいてプロセスを調整可能 マルチエージェント対シングルエージェント

1. より複雑なタスクに適している

2. 責任と権限の境界がより明確

3. コンテキストエンジニアリングがより容易

4. スケーリングがより容易 AgentCore のベストプラクティス エージェント専用ランタイム環境の概要

• 「試用」から「導入」への課題
• PoC から本番環境への導入に伴う課題
• パフォーマンス
• 弾力性
• セキュリティ
• ビジネス価値の創出
• コンプライアンス

エージェントランタイム環境 v1.0

• インターフェイスとプロトコル（MCP/A2A）
• エージェントのデプロイ
• エージェントフレームワーク
• 大規模言語モデル
• メモリ
• プロンプト
• ツール／リソース
• ガードレール
• オブザーバビリティ
• 評価 エージェントランタイム環境 v2.0
• インターフェイスとプロトコル（MCP/A2A）
• エージェントのデプロイ
• Amazon Bedrock
• AgentCore
• エージェントフレームワーク
• 大規模言語モデルランタイム
• メモリ
• プロンプト
• ツール／リソース
• アイデンティティツール
• ガードレール
• ゲートウェイ
• オブザーバビリティ
• 評価 特化型
• Amazon Q Agents フルマネージド
• Amazon Bedrock Agents DIY
• OSS フレームワーク、Strands Agents SDK