HPE Zerto、Amazon Bedrock上にオンプレミスのエージェント型トラブルシューティングシステムを構築

HPE Zerto は、顧客のオンプレミス環境内で動作しながら、推論レイヤーを Amazon Bedrock で駆動するエージェント型トラブルシューティングシステムを構築した。このシステムは、自然言語インターフェースをライブの災害復旧データ、製品ドキュメント、運用ツールと接続し、レジリエンスチームがダッシュボードやサポート資料を手作業で切り替えることなく問題を調査できるよう支援することを目指している。

AWS Machine Learning Blog の投稿で詳述されているこのアーキテクチャは、エンタープライズAIにとっての実務上の制約を反映している。モデルサービス自体はクラウドベースであっても、機密性の高い運用コンテキストとツール実行は顧客インフラにできるだけ近い場所にとどまる必要がある。HPE Zerto によれば、このシステムは Zerto 製品内の pod として展開され、既存の運用インターフェースからアクセスされる。

AI ビルダーやエンタープライズ技術チームにとって重要なのは、新しいチャットボットそのものよりも、HPE Zerto がその周囲に引いた境界である。エージェントは現在の環境状態を推論し、関連知識を取得できるが、そのアクセスはローカル API、検索システム、セキュリティ制御によって媒介される。この設計は、汎用モデルを無制限のオペレーターに変えることなく、障害や設定問題の際にAIアシスタントを有用にすることを意図している。

ライブ復旧データに接続されたマルチエージェント層

AWS Machine Learning Blog によると、このシステムは Strands Agents で構築されたエージェントを使用している。これらのエージェントはオンプレミスの pod として動作し、ローカルに保存された会話履歴、内部ツール、外部知識検索という3つの主要な情報源を利用できる。

内部ツールの経路は、ローカルの Model Context Protocol サーバーを通じて公開される。このサーバーは Zerto Manager API への構造化されたアクセスを提供し、エージェントが静的なドキュメントやユーザーによる障害説明だけに頼らず、顧客環境からのライブ情報を調査できるようにする。

外部経路では、Amazon Bedrock Knowledge Bases を使って公開ドキュメント、ランブック、その他の運用資料を取得する。この組み合わせが重要なのは、災害復旧システムのトラブルシューティングには通常、現在の状態と手順的コンテキストの両方が必要だからである。アラートは何が失敗しているかを示し、ランブックや製品ガイドはそれを安全に調査または修正する順序を説明する。

インターフェースは既存の Zerto ユーザー体験に埋め込まれている。HPE Zerto は、Server-Sent Events を使って調査の進捗をユーザーにストリーミングし、単一の最終応答を待つのではなく途中経過を表示すると述べている。想定ユースケースには、設定に関する質問への回答、健全性の問題の軽減支援、セットアップや機能採用の補助、リスク、サービスレベル契約への影響、復旧準備状況の要約などが含まれる。

ただし、これはモデルが復旧環境全体を独自に制御することを意味しない。ソースは、与えられたツールを通じて推論し、行動し、応答するよう設計されたシステムを説明している。したがって、展開の実際の安全性は、これらのツールの周囲に実装された権限、検証ロジック、アクションの境界に依存する。AWS の記事はこれをアーキテクチャレベルで議論しているが、本番性能レポートとして完全に定量化しているわけではない。

オンプレミス展開モデルが重要な理由

HPE Zerto の対象ユーザーは、ハイブリッドまたはマルチクラウド環境におけるサイバーレジリエンス、継続的データ保護、災害復旧を管理している。このような環境では、運用データに保護対象ワークロードの健全性、レプリケーション状態、アラート、イベント、サイト間の関係、復旧準備状況などが含まれる可能性がある。同社が挙げる課題は、これらの情報がインターフェースやドキュメントに分散しており、障害やサイバーインシデント時の判断を遅らせることだ。

エージェント層を顧客環境内で実行することは、この問題の一部に対処する。アシスタントは調査対象システムの隣に配置でき、セッション履歴はローカルに保存され、製品は使い慣れた管理 UI から引き続きアクセス可能である。企業にとっては、展開を簡素化し、運用コンテキストを別の外部アプリケーションに移す必要を減らせる可能性がある。

ただしモデル層は依然として Amazon Bedrock に依存している。AWS によれば、HPE Zerto は、ファウンデーションモデルへの制御されたアクセス、異なるモデルを評価する能力、ガードレール、可観測性、検索サービスとの統合を理由に同サービスを選択した。HPE Zerto はまた、Amazon Bedrock Guardrails を使って、プロンプトと生成出力にポリシー、コンプライアンス、セキュリティ制御を適用している。

このハイブリッド構成は、エンタープライズAIにますます重要な展開パターンを示している。つまり、データアクセスと実行は記録システムの近くに保ちつつ、推論とモデル選択には管理されたモデルプラットフォームを使うということだ。これは柔軟性をもたらす一方で、ローカル製品、モデルサービスへのネットワーク経路、検索品質、各エージェントに与えられる権限の間に依存関係も生む。

証拠と主張は依然としてベンダー報告ベース

入手可能な証拠は、HPE Zerto のアーキテクチャを中心に書かれた AWS Machine Learning Blog のケーススタディである。記述されたコンポーネントと展開アプローチは確認できるが、トラブルシューティング精度、応答遅延、顧客採用率、サポートチケット件数の削減、復旧時間の測定可能な改善について独立した検証は示していない。

したがって、より速く、より情報に基づいた復旧判断や運用負荷の軽減に関する主張は、独立に検証された結果ではなく、システムの意図された成果として読むべきである。ソースはまた、本番でどのファウンデーションモデルが使われているか、モデルルーティングがどう管理されているか、またエージェントがオペレーターに推奨を返すのではなく直接アクションを取ることがどの程度許可されるのかを明示していない。

Intuit の Intuit EWOK Agent に関する別の AWS Machine Learning Blog 投稿は、関連する参照点ではあるが、HPE Zerto についての追加証拠ではない。Intuit は、平易な言葉のフェイルオーバー要求を検証済みワークフローに変換するエージェントを説明しており、決定論的な実行システムがインフラ変更を行う。Intuit は、そのシステムを8か月使用してきたと述べ、対応する復旧ワークフローは約20分で完了できると報告しているが、これらは Intuit 自身の別プラットフォームに関する主張である。

両事例に共通するより広い設計原則は、AIモデルに意図の解釈と限定された能力の中からの選択を任せ、決定論的システムがポリシーを強制し影響の大きい操作を実行する、というものだ。このパターンは特定のベンチマークよりも移植性が高いが、それでも組織は自らのデータ品質、障害モード、変更管理要件に照らして検証する必要がある。

ビルダーと企業購入者への示唆

ビルダーにとって、HPE Zerto のアプローチは、グラウンディングをプロンプト作成の作業ではなく統合の問題として浮き彫りにする。エージェントは、現在の製品状態への信頼できるアクセス、定義されたツールスキーマ、関連ドキュメント、そして会話ですでに利用可能な情報を繰り返し求めないための十分なセッションコンテキストを必要とする。ローカル MCP サーバーは構造化されたインターフェースを提供できるが、認証、認可、ロギング、API 互換性の重要な制御点にもなる。

企業購入者にとって重要な評価ポイントは運用面である。システムは古いアラートと現在の状態を区別できるか。提案の出典を引用または表示できるか。管理者はロールや環境ごとにツールを制限できるか。モデルが利用不可の場合、検索結果が不完全な場合、または要求された修復がデータ損失リスクを高める可能性がある場合はどうなるか。AWS の記事はアーキテクチャを示しているが、こうした調達やガバナンスの問いすべてには答えていない。

このシステムの価値が最も高くなるのは、情報密度が高く、オペレーターの経験差が大きい現場だろう。自然言語レイヤーは、特に経験の浅い管理者にとって、コンテキストを集めたり症状を説明したりする時間を短縮できる。しかし災害復旧では、有用な説明と安全な実行は同じではない。診断から修復への移行には、明示的な権限、確認手順、監査証跡、そして人間のオペレーターへの確実なフォールバックが必要である。

今後注目すべき点

次に注目すべき有意なシグナルは、アーキテクチャ説明を超えた展開の証拠である。HPE Zerto は、アシスタントが一般提供されているか、どの製品版や環境が対応しているか、そして顧客がモデル選択やツール権限を設定できるかを明確にするかもしれない。

ビルダーはまた、応答精度、検索品質、誤った提案、インシデント調査で節約された時間、提案されたアクションをユーザーが受け入れる率・拒否する率に関する公開測定値も注視すべきだ。そうした指標があれば、単に会話インターフェースを追加しただけでなく、運用作業を改善しているかどうかが分かる。

プラットフォーム側では、モデルの柔軟性が引き続き重要な試金石となる。HPE Zerto は、Amazon Bedrock により品質、遅延、コストに基づいてファウンデーションモデルを評価できると述べている。実世界での比較、展開ガイダンス、データレジデンシーやネットワーク障害時の挙動に関するより明確な情報があれば、その柔軟性が実用上の利点をもたらすかを企業は評価しやすくなる。

Creati.ai の視点

HPE Zerto のシステムは、エンタープライズのエージェント型AIがどこで具体化しているかを示す有用な例である。既存の運用製品の内部で、ライブ状態に接続され、すでに環境を統治している API と制御によって制約されている。設計の最も優れた点は、会話型推論レイヤーと製品の基盤となる運用インターフェースを分離していることだ。

より難しい問題は、その証明である。災害復旧では、エージェントはアラートを説明できるかどうかだけでなく、その指示が最新で、監査可能で、プレッシャー下でも安全かどうかで評価されなければならない。HPE Zerto かその顧客が成果データを公開するまでは、この発表は、信頼できる展開パターンであり評価すべきアーキテクチャとして理解するのが最善であり、エージェントが復旧運用を解決した証拠ではまだない。