Amazon Bedrockを利用したAIエージェントによるセルフサービスAWS Health分析で実用的なヘルスインサイトを見つける
この投稿では、Model Context Protocol(MCP)を介して公開されたAIエージェントを使用してセルフサービスのヘルスイベント分析を提供する、オープンソースソリューションであるChaplin(Customer Health and Planned Lifecycle Intelligence Nexus)の構築方法を紹介します。
典型的な月曜日の朝、エンタープライズ運用チームは、50以上のアカウントにわたるAmazon Linux 2のサポート終了、RDSバージョンの非推奨、EC2インスタンスのリタイアメントに関する複数のAWS Health通知を受け取ります。セルフサービス分析がないと、チームは本番システムに影響を与えるイベント、即時対応が必要なイベントと長期計画が必要なイベント、および各イベントカテゴリのビジネスへの影響を迅速に特定する方法がありません。また、運用チームはテクニカルアカウントマネージャー(TAM)がヘルスイベントを解釈するのを待つ時間を費やし、重要な運用上の決定に遅れが生じます。その結果、イノベーションではなく事後対応に時間を費やすことになります。
この投稿では、Chaplin(Customer Health and Planned Lifecycle Intelligence Nexus)と呼ばれる、Model Context Protocol(MCP)を介して公開されたAIエージェントを使用してセルフサービスのヘルスイベント分析を提供するオープンソースソリューションの構築方法を紹介します。Chaplinを使用すると、チームはMCP互換のAIアシスタントから自然言語で質問し、AWSサポートに依存することなく、正確でコンテキストに応じた回答を得ることができます。詳細なデプロイ手順は、Chaplin AWS Health Agentic Assistant GitHubリポジトリで入手できます。
課題:リアクティブなヘルスイベント管理
AWSで本番ワークロードを実行しているエンタープライズは、数十から数百のアカウントにわたって、サービス変更、メンテナンスウィンドウ、セキュリティパッチ、運用通知などのヘルスイベントの絶え間ないストリームを管理しています。AWS Healthは、AWS Health APIとAmazon EventBridgeを通じて包括的なイベントデータを提供しますが、リアクティブな管理アプローチにはギャップがあります。チームはヘルスイベントの解釈と影響分析をTAMに依存しており、意思決定にボトルネックが生じています。事前定義されたスキーマを持つビジネスインテリジェンスダッシュボードは、動的な質問に適応したり、運用チームがその場で必要とするコンテキストインサイトを提供したりすることはできません。
DevOpsおよびクラウド運用チームは、複数のアカウントとリージョンに散在する数千のヘルスイベントを手動で分類し優先順位付けするためにかなりの時間を費やしています。分析のための集中ロケーションがないと、全体的な影響を評価したり、チーム間の対応を調整したり、移行の計画や問題が重大になる前のメンテナンスのスケジュールなどの積極的な機会を特定したりすることが困難です。
対象となるHealthイベントは、まもなくAWS Transformテンプレートに直接リンクされ、顧客がイベントに直接対応できるようになります。Chaplinは、これらの実用的なイベントを環境に合わせて表示し、優先順位付けすることができます。
ソリューションの概要:Chaplinによるセルフサービス分析
Chaplinは、Amazon Bedrockを利用したエージェントAIを使用してセルフサービスのヘルスイベント分析を実装し、Model Context Protocol(MCP)を介して提供します。Chaplinは、事前定義されたダッシュボードスキーマの代わりに、MCP互換クライアントが利用できるAI駆動ツールを公開します。チームは、Claude CodeやKiro CLIなどのAIアシスタントから直接Chaplinと対話し、自然言語で質問します。たとえば、チームメンバーは、今後60日間のRDSライフサイクルイベントを尋ねたり、緊急度で優先順位付けされた未処理のEC2イベントの要約を要求したり、本番環境に影響を与えるセキュリティパッチを照会したり、優先度の高いアプリケーションに影響を与える可能性のあるメンテナンスウィンドウを確認したりできます。
チームは、情報に基づいた意思決定を行い、是正計画を作成するために必要なすべての情報を得るまでクエリを続けることができます。このアプローチにより、DevOps、セキュリティ、運用チームは、ボトルネックを作成することなく、ヘルスイベントを独立して分析し、移行を計画し、運用への影響を評価できます。ChaplinはMCPを使用するため、チームはワークフロー内の他のMCP対応ツール(JIRA、GitHub、ServiceNowなど)と組み合わせて、エージェント体験でアクションを実行することもできます。
さらに、MCPは、AWSデータとメタデータをリソースタグ、環境分類、所有権情報などのビジネスまたはアプリケーションレベルのコンテキストに直接関連付けることを可能にし、組織的な関連性でヘルスイベント分析を豊かにします。
エージェントAIが構造化データと非構造化データを統合する方法
Chaplinは、エンタープライズデータ分析における基本的な課題である構造化データと非構造化データの処理を効果的に組み合わせるために、マルチエージェントアーキテクチャを採用しています。従来のRetrieval-Augmented Generation(RAG)システムと生成AIアプローチは、数値操作と集計を処理する際に本質的に非決定論的であるという重要な制限に直面しています。RAGの基盤であるベクトル類似性検索は、意味的に類似したコンテンツを取得しますが、数学的な正確性を保証することはできません。カウント、合計、またはデータの集計を求められた場合、RAGベースのシステムは幻覚を起こす可能性があります(たとえば、実際の数が958であるにもかかわらず、190個のサポート終了関連のヘルスイベントを報告するなど)。この非決定論は、検索メカニズム(完全一致ではなく意味的類似性によってドキュメントをランク付けする)と言語モデルの生成プロセス(正確な値を計算するのではなく、可能性の高いトークンを予測する)の両方の確率的性質に起因します。
AWS Healthイベントは、まさにこの課題を提示します。各イベントには、イベントタイプ、サービス名、影響を受けるリソース、タイムスタンプ、重大度レベル、アカウントIDなどの構造化メタデータが含まれており、正確なフィルタリングと集計が必要です。また、各イベントには、問題の自然言語による説明、影響評価、推奨アクションを含む非構造化記述が含まれており、意味理解とコンテキスト分析が必要です。
インテリジェントクエリ処理
Chaplinに質問すると、3つの専門化されたコンポーネントが連携して動作します。自然言語から構造化クエリへのエージェントは、平易な英語の質問をヘルスイベントメタデータに対する正確な構造化データクエリに変換します。これは、イベントのスキーマ(イベントタイプ、影響を受けるアカウント、開始時間など)を理解し、意図に一致するフィルターを構築します。「本番アカウントのEC2リタイアメントを表示」のような質問は、キーワードマッチングではなく、正確なフィールドフィルターを使用した構造化クエリになります。
コンテキスト影響分析エージェントは、非構造化ヘルスイベント記述を、顧客メタデータ(本番環境と非本番環境、ビジネスユニット、アプリケーションティア、所有権情報)と組み合わせて処理します。このエージェントはシステムレベルの推論を実行し、イベントの内容だけでなく、特定のインフラストラクチャと組織コンテキストにとって何を意味するかを解釈します。
パターンベース分類エンジンは、ルールベースのパターンマッチングを使用してヘルスイベントを分類します。これにより、日常的な分類のためのAI処理コストが排除され、高い精度が維持されます。このコスト最適化レイヤーにより、ソリューションは大規模に実用的になります。
コスト最適化されたAIアーキテクチャ
Chaplinは、選択的なAI強化を通じてインテリジェントなコスト最適化を実装します。このシステムは、パターンファーストの処理アプローチを採用し、ルールベースの分類がAIコストを発生させることなくほとんどのイベントを処理します。フィルター付きの30日、60日、120日の事前構築されたサマリービューは、チームが重要なアラートを迅速に特定するのに役立ちます。現在の実装では、Amazon BedrockとClaudeは、コンテキスト分析を必要とする非構造化データのみを処理します。しかし、このソリューションはLLMに依存せず、Amazon Bedrock、OpenAI、Anthropic、またはOllamaのようなローカルモデルなど、複数のモデルプロバイダーをサポートしており、要件とコスト制約に基づいて柔軟性を提供します。インテリジェントキャッシングは冗長なAI処理を削減し、構造化クエリの精度はAWS Health APIスキーマを使用してAI推論コストをかけずに正確な数値分析を実現します。
アーキテクチャの概要
次の図は、完全なChaplinアーキテクチャを示しています。これは、ヘルスイベントが複数のAWSアカウントから一元化されたデータパイプラインを経由し、Amazon Bedrock上に構築されたAIエージェントを搭載したMCPサーバーに流れ込み、最終的にMCP互換のAIアシスタントに到達し、チームが自然言語でデータと対話する様子を示しています。各層は図の後に詳しく説明されています。
アーキテクチャは、インテリジェントなヘルスイベント分析を提供するために連携する3つの主要な層で構成されています。
- データ層 – 収集層(マルチアカウント)
データ層は、AWS組織全体からヘルスイベントを収集し、分析のために一元化します。各メンバーアカウントでは、AWS Health APIがヘルスイベントのソースとして機能します。Amazon EventBridgeはリアルタイムキャプチャのためのイベント駆動型トリガーを提供し、AWS Lambdaコレクター関数は最小権限で構成されたクロスアカウントIAMロールを使用してイベントを取得します。
これらのイベントは集中管理アカウントに流れ、Amazon Simple Storage Service (Amazon S3) データレイクが収集されたヘルスイベントをアカウント、日付、イベントタイプでインテリジェントにパーティション分割して保存します。新しいイベントが到着すると、S3イベント通知がAWS Lambda関数をトリガーし、JSONヘルスイベントを処理してAmazon DynamoDBにロードし、高速クエリを可能にします。
このマルチアカウントアーキテクチャは、2つのデプロイモデルをサポートします。
オプション1:AWS Organizations APIを使用した、アカウント全体への集中型自動デプロイ。
オプション2:セキュリティ制限のある組織向けの個別アカウントデプロイ。
- ミドル層 – MCPサーバーとインテリジェンス層
ミドル層は、生のヘルスイベントデータが実用的なインテリジェンスに変換され、MCPサーバーを介して公開される場所です。Amazon DynamoDBは、構造化ヘルスイベントメタデータのプライマリデータストアとして機能し、イベントタイプ、重大度、日付、アカウントのインデックスにより高速クエリに最適化されています。これにより、パターンベースの分類とAI分析の両方に対するリアルタイムアクセスが可能になります。
パターンベースのイベント分類器は、最初のインテリジェンス層を提供します。このルールベースの分類エンジンは、イベントタイプの正規表現パターンを使用して、イベントを5つのビジネスカテゴリ(移行要件、セキュリティとコンプライアンス、メンテナンスとアップデート、コスト影響イベント、運用通知)にマッピングします。ほとんどのイベントは予測可能なパターンに従うため、このアプローチはAIコストを発生させることなく、効率的なパターンマッチングを通じてイベントの大部分を処理します。
より深い分析が必要なイベントについては、Amazon Bedrock上に構築されたAI駆動分析エンジンが引き継ぎます。このエンジンは、AWSが開発したオープンソースのエージェントフレームワークであるStrands Agentsフレームワークを、大規模言語モデルとしてClaude 4.5 Sonnetとともに使用します。これは任意のLLMに切り替えることができます。3つの専門エージェントが分析のさまざまな側面を処理します。SQLクエリエージェントは自然言語クエリを構造化DynamoDBクエリに変換して正確な数値分析を実行し、影響分析エージェントは顧客メタデータ(環境、ビジネスユニット、所有権など)に対して非構造化イベント記述を評価し、DBQueryBuilderエージェントは多次元集計のための最適化されたデータベースクエリを生成します。これらの機能はすべて、互換性のあるクライアントが呼び出すことができるMCPツールとして公開されます。
- プレゼンテーション層 – MCPクライアント – AIアシスタント統合
プレゼンテーション層は、Claude CodeやKiro CLIなどのMCP互換AIアシスタントで構成されています。カスタムフロントエンドの代わりに、Chaplinはその機能をMCPツールとして公開し、これらのクライアントがネイティブに使用します。ユーザーは既存の開発環境で自然言語を通じて対話し、AIアシスタントはChaplinのMCPサーバーへの呼び出しを調整してヘルスイベントデータを取得し、AI駆動分析を実行し、コンテキスト化された結果を表示します。これらすべてが、開発タスクにすでに使用している同じ会話インターフェース内で行われます。
セキュリティは、認証と認可のためにAWS Identity and Access Management(AWS IAM)に依存しています。MCPクライアントはAWS認証情報を読み取り専用でマウントし、アクセスは最小権限の原則に従ったIAMロールを通じて制御されます。