30秒サマリー
- HPE ZertoがAmazon Bedrockを活用したオンプレミス向けエージェント型トラブルシューティングシステムの構築事例をAWS公式ブログで公開
- オーケストレーターと複数サブエージェントの階層構造により、DR環境の障害原因特定から対処まで自然言語で対応
- 2026年第2四半期のリリース以降、HPE Zertoの顧客の20%超がすでに利用中と報告
何が起きたか
AWS Machine Learning Blogは、HPE ZertoがAmazon Bedrockを基盤としたエージェント型トラブルシューティングシステムを構築した事例を、AWSとHPE Zertoの共同執筆ブログ記事として公開した。同システムはハイブリッド・マルチクラウド環境のデータ保護・ディザスタリカバリ（DR）チームを対象に、障害調査や根本原因の特定、対処の優先順位付けを自然言語で実行できるよう設計されている。
アーキテクチャは「UIレイヤー」「エージェントレイヤー」「インテリジェンスレイヤー」「オブザーバビリティレイヤー」の4層で構成される。エージェント部分はStrands Agents SDKを用いてオンプレミスのZVM（Zerto Manager）アプライアンス内で動作し、モデル推論とナレッジベースクエリのみがHTTPS経由でAWSへ送信される。モデル推論にはAmazon Bedrock、ドキュメント検索にはAmazon Bedrock Knowledge Bases（RAG）、コンテンツ制御にはAmazon Bedrock Guardrailsを採用している。
エージェントの構成は、オーケストレーターエージェントが司令塔となり、ZVMエージェントとVRAエージェントの2つのサブエージェントを必要に応じて呼び出す階層構造を取る。各サブエージェントは独自のコンテキスト・システムプロンプト・ツールセットを持ち、ログ解析や環境データの収集を担当する。評価にはPyTestとStrands Agents Evals SDKを使用し、基本クエリ評価・マルチターン評価・動的テスト評価の3種類を継続的に実施しているという。
原文によれば、同システムは2026年第2四半期にリリースされ、HPE Zertoの顧客の20%超がすでに利用中とされている。ただし原文の取得段階で本文の末尾が途切れており、より詳細な数値などは確認できていない。
原典ハイライト
DR環境は「エアギャップ環境・低レイテンシ要件・データレジデンシー規制」の制約があるため、エージェントランタイム全体をオンプレミスで動作させ、AWS側に送るのは推論リクエストとナレッジベースクエリのみに限定した設計が採用された。また、オーケストレーターが深い調査が必要と判断した場合のみ専用サブエージェントに処理を委譲し、親エージェントのコンテキストをログの生データで汚染しない構造が強調されている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
本事例が示す重要な点は、厳格なデータ主権・低レイテンシ要件を持つDR基盤においても、クラウドのAIサービスを「推論のみ外部委託」する形で活用できることを実証した点にある。エージェントの評価を「レスポンス品質・ツール選択の軌跡・レイテンシ・トークン消費量」の4軸で継続計測する手法は、AIエージェントの本番運用品質管理の実践例として参照価値が高い。
日本企業への示唆
オンプレミスや規制産業向けのシステムを扱う日本企業にとって、「AIエージェントはすべてクラウドで動かす」という先入観を見直す契機になる。DR・BCPシステムの担当者は、エージェントランタイムをオンプレミスに残し推論のみクラウドAPIを呼ぶ「ハイブリッド配置」の設計パターンを検討すべきだろう。また、複数のサブエージェントへの委譲とコンテキスト圧縮の手法は、ログ量が膨大な製造・金融・インフラ系の障害対応自動化にも応用が利く。エージェント評価のフレームワークを内製する際の参考事例としても活用できる。
背景・経緯
HPE Zertoはサイバーレジリエンス・ディザスタリカバリ・継続的データ保護ソフトウェアを提供している。DR運用チームは複数サイト・大量の保護ワークロードにまたがる監視・SLA管理・障害調査を手動で行うことが多く、情報がアラート・イベント・ドキュメントに分散しているため対応に時間がかかるという課題を抱えていた。Amazon Bedrockの採用理由として、セキュリティ・ガバナンス対応、複数モデルの柔軟な選択、AWSサービスとの統合のしやすさが挙げられている。
